0
0

昇腾软件栈与开发者生态：CANN、TorchNPU、MindSpore、MindSpeed 与 Mi

2026-10-17
硬件、算子与编译

这篇文章回答一个核心问题：开发者写下一个 PyTorch 模型之后，它究竟如何穿过昇腾软件栈，最终在 NPU 上执行？

整理日期：2026-09-10。

1. 衡量 AI 芯片“好不好用”，不能只看芯片

AI 芯片的最终使用者之一是开发者。对开发者而言，“好用”意味着：常见模型能直接跑、缺失算子少、框架迁移成本低、性能问题可定位、第三方工具可接入、版本兼容关系清晰。

因此一个完整 AI 平台至少需要同时解决：

  • 硬件抽象：如何管理 Device、Stream、Event、Memory、Kernel。
  • 算子执行：常见 NN/Transformer 算子如何高性能执行。
  • 图执行：如何做图优化、融合、内存复用和任务下发。
  • 框架适配：PyTorch/MindSpore 等如何调用 NPU。
  • 分布式通信：多卡训练与推理如何做集合通信。
  • 训练/推理系统：如何做并行、调度、KV Cache、Continuous Batching、PD 分离等。
  • 工具链：Profiling、Debug、Compiler、Dump、运维如何完成。

这也是为什么“生态”不是芯片之外的附属品，而是把理论算力变成可用算力的转换层。

2. CANN 是昇腾软件栈的核心底座

CANN（Compute Architecture for Neural Networks）是面向昇腾 AI 处理器的异构计算平台。可以把它类比为一个广义的软件平台层，而不是简单把它理解成“昇腾版 CUDA”。

CANN 中包含多个不同职责的子系统：

组件 职责 可类比概念
Runtime 设备、内存、Stream、Event、任务调度等运行时能力 CUDA Runtime/Driver 的一部分职责
GE Graph Engine，负责计算图编译、优化与执行控制 图编译器 + 图执行器
AOL / ops 硬件亲和、高性能算子实现 cuDNN/cuBLAS/专用算子库的部分角色
HCCL 多 NPU 集合通信与点对点通信 NCCL
Ascend C 面向 NPU Kernel 的编程接口 CUDA C++ Kernel 编程层，但架构不同
BiSheng 编译 Ascend C / AI Core Device 代码 nvcc/device compiler 的部分角色
调试与性能工具 Profiling、Dump、内存分析、调优 Nsight/Profiler 等工具链角色

CANN 8.5 开始进行了明显的组件解耦，例如 ops、HCCL、HIXL 等可以独立升级。CANN 9.0 的公开版本继续列出了 GE、Runtime、HCCL、ops、PTO ISA 等组件。

**重要认知：**CANN 不是一个单库，而是一整套“编译 + Runtime + 图 + 算子 + 通信 + 工具”的系统软件栈。

3. GE：为什么图引擎仍然重要

GE（Graph Engine）是计算图编译与执行控制中心。典型能力包括：

  • 图优化；
  • 多 Stream 并行；
  • 内存复用；
  • 模型下沉；
  • 不同前端框架/模型格式的图接入。

在 eager/single-op 模式中，算子逐个下发，开发体验灵活，但会带来 Kernel launch、Python 调度和同步等开销。图模式将更大的计算区域捕获后统一优化和执行，因此可以进一步做融合、调度与内存规划。

这与现代 PyTorch 里的 torch.compile、Dynamo/Inductor、CUDA Graph 等方向有相似的系统动机：减少框架层动态开销，让编译器获得更大的优化视野。

4. TorchNPU：昇腾接入 PyTorch 的关键适配层

你原笔记中的“python-adapter”建议统一改成 TorchNPU。

TorchNPU 是 Ascend for PyTorch 社区的核心适配插件，使 PyTorch 能直接调用昇腾 NPU。其作用不仅是把 .cuda() 改成 .npu()，还涉及：

  • PyTorch Operator → Ascend Operator 映射；
  • Device/Memory/Stream 接入；
  • Distributed 与 HCCL 集成；
  • DTensor、FSDP2 等分布式能力适配；
  • Graph Mode、NPUGraph 等执行优化；
  • Profiling、WatchDog、内存管理等系统能力。

因此更准确的链路是：

PyTorch Model
↓
PyTorch Dispatcher / torch.compile / Distributed
↓
TorchNPU
↓
CANN GE / Runtime / Operators / HCCL
↓
Ascend NPU

这解释了为什么“兼容 PyTorch”并不等于“模拟 CUDA API”。一条更可持续的路线是直接进入 PyTorch 的扩展与硬件后端机制，让上游框架本身能够识别 NPU。

5. MindSpore、MindSpeed、MindIE 分别是什么

这三个名字非常容易混淆。

组件 定位 典型使用者
MindSpore 完整 AI 框架，可用于训练、微调和推理 希望使用华为自研框架的模型开发者
MindSpeed / MindSpeed LLM 大模型训练加速与适配体系，围绕并行、内存、通信和模型适配提升训练效率 预训练、后训练、大规模分布式训练团队
MindIE 面向昇腾的大模型推理系统/套件 在线 Serving、批量推理、生产部署

MindSpeed

MindSpeed 更接近“训练系统加速层”，而不是新的基础框架。当前 MindSpeed LLM 已与 Megatron Core、FSDP2 等训练后端形成适配关系，目标是让大模型训练在昇腾硬件上获得更好的并行效率、显存利用与通信效率。

MindIE

MindIE LLM 已开源，公开能力包括 Continuous Batching、PagedAttention、FlashDecoding 等大模型推理特性。它的定位不是“模型格式转换工具”，而是完整的 LLM 推理与 Serving 系统。

因此可以把它和 vLLM、SGLang 放到同一大类里比较，但具体架构、调度器、Kernel、模型支持和生态成熟度不同。

6. 第三方生态：不要把所有项目都叫“训练加速库”

原始笔记里把 FSDP2、Megatron、DeepSpeed、verl、AReaL、LLaMA-Factory 放在一类，这是不够准确的。

项目 更准确分类
FSDP2 PyTorch 原生分布式参数分片训练能力
Megatron Core 大模型分布式训练与并行基础库
DeepSpeed 微软开源的大规模训练与推理优化系统
verl 面向 LLM 强化学习后训练的分布式框架
AReaL 强化学习/Agentic RL 后训练系统
LLaMA-Factory 面向模型微调、训练配置与数据流程的应用型训练框架
vLLM 高吞吐 LLM 推理与 Serving 引擎
SGLang 高性能 LLM/多模态 Serving 与 Agent Runtime

昇腾生态真正需要做的是让这些上层系统通过 TorchNPU、CANN 和高性能 Kernel 获得可靠的 NPU 后端。

7. vLLM 与 SGLang 在昇腾上的接入方式

vLLM

vLLM Ascend 已明确采用 hardware plugin 机制，将 Ascend NPU 后端从 vLLM 核心框架中解耦。这个模式很值得关注，因为它代表 AI Infra 生态正在从“fork 一套专用版本”走向“上游框架 + 硬件插件”。

SGLang

SGLang 当前已经具备 Ascend NPU 支持，昇腾侧也有相关适配、Kernel 和工程仓库。与其简单写“原生支持”，更准确的说法是：SGLang 的硬件生态已经包含 Ascend 后端，但具体版本仍需按 SGLang、CANN、TorchNPU、Triton-Ascend 的兼容矩阵部署。

8. 为什么版本矩阵是 NPU 生态的核心工程问题

AI 软件栈不是普通 Python 包组合。一个可工作的环境通常要求：

Driver / Firmware
↕
CANN
↕
TorchNPU
↕
PyTorch
↕
vLLM / SGLang / MindSpeed / verl
↕
模型与自定义 Kernel

任何一层 ABI、Operator Schema、Compiler IR、Kernel API 或依赖版本变化，都可能造成兼容问题。

例如当前 TorchNPU 官方兼容表会明确绑定 PyTorch 与 CANN 版本；vLLM Ascend 也强调应把 vLLM、vLLM Ascend、PyTorch、TorchNPU、CANN、Triton-Ascend 当成一个完整兼容集合，而不是随意组合版本。

这类“版本工程”本身就是 AI Infra 的重要能力。

9. “昇腾全面开源开放”应该怎样准确理解

华为在 2026 年公开表述 CANN 已全面开源，并且 CANN 社区当前可看到 GE、Runtime、HCCL、Operator、Transformer 加速库等大量项目。

但技术笔记里不建议直接写：“昇腾目前比 NVIDIA 更开源。”

原因是“开放程度”至少包含：

  • Runtime 源码；
  • Kernel 编程接口；
  • 编译器核心；
  • 虚拟 ISA/IR；
  • 数学/神经网络库源码；
  • 通信库；
  • 驱动；
  • 硬件 ISA；
  • 框架上游贡献程度；
  • 社区治理方式。

不同平台在不同层面的开放程度不同，没有一个简单的二元答案。

同样，“毕昇编译器是目前唯一闭源组件”也不建议直接作为事实写入。公开资料能够确认 BiSheng 工具及其功能，但是否、哪些内部编译器模块完整开放，应按具体仓库和版本逐项核实。

10. 从 AI Infra 视角学习这套软件栈

建议沿着一条模型请求实际执行路径学习：

用户请求
→ vLLM / SGLang / MindIE Scheduler
→ PyTorch / TorchNPU
→ Graph / Operator Dispatch
→ AOL / Custom Kernel
→ CANN Runtime
→ NPU
→ HCCL / UnifiedBus
→ 其他 NPU

每遇到性能问题，都问四个问题：

  1. 算子慢，还是调度慢？
  2. 算力瓶颈，还是 HBM / 网络带宽瓶颈？
  3. 单卡慢，还是多卡扩展效率差？
  4. 框架层、编译层、Runtime 层还是硬件层？

能够沿这条路径定位问题，就从“会使用昇腾”进入了“理解昇腾 AI Infra”。

参考资料