AIREITER一个公开的 GitHub 仓库，很容易让人误以为整套硬件栈已经触手可得。DeepSeek 的昇腾相关工作确实有实用价值，但它并不是“一条命令就能替代 NVIDIA 集群”的方案：目前发布内容主要围绕昇腾 950 内核展开，并且依赖 CANN、torch_npu 以及兼容的硬件环境。
先说结论：开放的是组件，不是一套开箱即用的昇腾集群
DeepSeek 已经公开了面向昇腾的代码，其中包括 DeepGEMM-Ascend。这是一个采用 MIT 许可证的内核库，保留了 DeepGEMM 的 API 形态，同时将目标硬件切换为华为 NPU。仓库的首个版本支持昇腾 950 设备，并将 CANN 9.20、torch_npu、Python 3.10 及以上版本、C++20 工具链和 TileLang 列为环境组成部分。
对于已经拥有兼容昇腾资源的团队来说，这些内容足以用于查看代码、编译、跑基准测试，并将部分内核接入现有系统。但它还不是一套完整的训练或生产环境。
拥有昇腾设备的实验室、云服务商和企业团队现在就可以开始评估。只有 NVIDIA 硬件的开发者可以研究这些代码，或者使用 DeepSeek 面向 NVIDIA 的项目，但无法在 H100 或消费级 GeForce 显卡上运行这些昇腾内核。
DeepSeek 实际发布了什么
DeepSeek 的 open-infra-index 按层次整理了其基础设施项目。原始索引大多面向 NVIDIA/Hopper：FlashMLA 是用于 Hopper GPU 的 MLA 解码内核，DeepEP 是专家并行通信库，DeepGEMM 是 FP8 GEMM 库，DualPipe 和 EPLB 负责分布式并行，3FS/Smallpond 则面向数据访问。
昇腾版本并没有一次性替换所有层，而是先将部分计算路径切换到新的硬件目标上。目前最明确的公开成果是 DeepGEMM-Ascend，覆盖以下内容：
- BF16、FP8 和 FP4 GEMM；
- MQA logits；
- 分组 GEMM 和 MegaMoE 路径；
- mHC prenorm 内核；以及
- 面向昇腾的 JIT 编译和布局变换。
项目表示其 API 与 DeepGEMM 兼容。这对模型工程师很有价值，但并不意味着 CUDA 二进制可以直接迁移。昇腾的矩阵布局、缩放因子打包方式、编译器、运行时以及设备管理 API，仍然都需要单独适配。
组件对照：面向 NVIDIA 的技术栈如何映射到昇腾
下表对照的是功能角色，并不意味着两边采用了完全相同的实现。所谓对应组件，只是承担相近的任务；它们可能使用不同的 API、通信互联或内核策略。
| 层次 | 已确认的昇腾代码或依赖 | 面向 NVIDIA 的对应方案 | 边界 |
|---|---|---|---|
| 矩阵乘法 | DeepGEMM-Ascend | DeepGEMM 加 CUDA/Tensor Core 内核 | 承担相同的 GEMM 角色，但底层硬件原语和数据布局不同 |
| MoE 分组计算 | DeepGEMM-Ascend 中的 M-Grouped GEMM 和 MegaMoE | DeepGEMM 的 MoE 布局加自定义 CUDA 内核 | 融合专家计算，但具体形状和限制取决于平台 |
| 专家分发 | 本次发布中没有明确的完整 DeepSeek 昇腾分发库；需要使用昇腾集合通信和算子集成 | DeepEP 配合 NVLink/RDMA | 解决的是相似的系统问题，但仓库之间不能互换 |
| 注意力/logits | DeepGEMM-Ascend 中的 MQA logits | 面向 Hopper 的 FlashMLA | 负载类型相近，但 FlashMLA 明确面向 Hopper |
| PyTorch 设备桥接 | TorchNPU（torch_npu） | PyTorch CUDA 后端、CUDA 运行时和 cuBLAS | TorchNPU 调用的是昇腾 NPU，并不会模拟 CUDA |
| 编译器/算子工具链 | CANN 以及 Ascend C/Bisheng 工具 | CUDA Toolkit、NVCC、PTX、cuBLAS、Triton | Python 代码看起来可能很熟悉，但设备契约已经改变 |
| 分布式运行时 | TorchNPU 集合通信，加华为及算子部署工具 | NCCL、支持 CUDA 感知的网络以及 NVIDIA 集群软件 | 互联、驱动、集合通信和框架版本仍然各自独立 |
| 存储/数据路径 | 这里没有确认到 DeepSeek 面向昇腾的专用存储组件；存储由运营方提供 | DeepSeek 的 3FS/Smallpond，加运营方自己的存储栈 | 这次内核发布不包含配套的存储集群 |
简单说，每个昇腾对应组件都在填补某个系统角色，但它并没有抹平 NVIDIA 软件生态的差异。
计算内核：DeepGEMM-Ascend 对比 DeepGEMM
DeepGEMM-Ascend 是本次发布中最具体的桥梁。其 README 将它描述为构建在昇腾 MAD 原语之上的轻量抽象层，用来隐藏分形布局、对齐约束、地址计算和底层参数。同时，它还使用了稀疏数据加载、基于协程的流水线等昇腾专属技术。
官方给出的依赖要求非常明确：昇腾 950 系列硬件、CANN 9.20、torch_npu、Python 3.10 或更高版本、兼容 C++20 的标准库、TileLang，以及包含 Tree-sitter 在内的构建依赖。文档中的安装流程包括先执行 git clone --recursive，再运行 pip install . --no-build-isolation。
仓库报告称，在昇腾 950DT 测试环境中，密集 GEMM 的利用率最高可达到标称硬件上限的 99.8%。其中一个 BF16 测试为 431 TFLOPS，对应 432 TFLOPS 的硬件上限；FP8 测试则为 861，对应 865。这些结果针对的是特定形状下的内核表现，不能直接等同于 DeepSeek 的端到端吞吐，也不能据此证明其性能已经与 NVIDIA 集群持平。
MoE 执行：MegaMoE 与专家分发
DeepSeek 的 open-infra-index 说明，其 V3/R1 系统使用了专家并行基础设施。因此，真正关键的不只是单次矩阵乘法有多快，还包括 token 路由、专家计算，以及跨 rank 汇总结果的效率。
DeepGEMM-Ascend 的 MegaMoE 基准测试将专家并行分发、两次分组 GEMM、SwiGLU 和合并操作融合在一起。其报告配置为 EP8、top-k 6、一个共享专家，并对八个 rank 的结果取平均。在 384 个专家、16,384 个 token 的场景下，README 针对其中一个隐藏层/中间层配置报告了 846.3 TFLOPS；在另一个列出的测试案例中，通信带宽为 103.3 GB/s。
对应的 NVIDIA 方案是 DeepEP，加上 DeepGEMM 的 MoE 布局，以及外围的 NCCL/NVLink/RDMA 环境。两者解决的是相似的架构问题，但如果 token 数量、专家路由、精度、rank 数量和网络条件不一致，就不能直接跨厂商比较这些数字。
模型专用内核：MQA logits 与 mHC prenorm
如果只把这次发布概括成“GEMM 移植”，很容易忽略其中的模型专用内核。DeepGEMM-Ascend README 将 MQA logits 基准标注为 DeepSeek Lightning Indexer 路径的一部分，并列出了 FP8 和 FP4 的 prefill、decode 测试。对于文档中给定的形状，FP4 decode 的耗时为 124.2 微秒，FP8 则为 150.9 微秒。
同一份 README 还将 HC prenorm 内核标注为 DeepSeek mHC 模块使用的内核，即 Manifold-Constrained Hyper-Connections。在文档给定的 N 和 K 参数下，M=8,192 时列出的内存带宽最高达到 3,463 GB/s。这些数字体现的是针对特定工作负载的优化，并不意味着所有模型算子或服务路径都已覆盖。
框架与运行时：CANN、TorchNPU 对比 CUDA
华为的 TorchNPU 仓库 将 TorchNPU 定义为面向昇腾 NPU 的 PyTorch 适配器。其功能列表包括原生和自定义 PyTorch API、FSDP2、DTensor、集合通信、图捕获、性能分析、WatchDog 监控以及内存管理功能。
NVIDIA 侧的概念对应物是 PyTorch 加 CUDA 运行时和相关库。但在实际部署中，差异相当明显：昇腾环境需要匹配的 CANN 版本、驱动、固件、Python 版本、PyTorch 版本和 TorchNPU 版本。TorchNPU 文档中的示例安装的是 CANN 9.1.0、PyTorch 2.12.0 和 torch-npu 2.12.0，而 DeepGEMM-Ascend 单独记录的则是 CANN 9.20。版本不一致意味着，安装时应以每个仓库自己的兼容性矩阵为准，不要把不同指南中的命令拼在一起使用。
华为自己的 CANN 文档将 CANN 描述为连接框架与昇腾硬件的软件层，覆盖运行时和算子开发路径。实际来看，CANN 更接近平台基础，而不是某一个 CUDA 库。PyTorch 模型或许仍能保留熟悉的 Python 语法，但底层依然需要昇腾专用内核、图执行行为和调试流程。
这次发布没有覆盖什么
DeepSeek 原始的开放基础设施索引还包括 3FS、Smallpond 等存储和系统级项目，并介绍了 DualPipe、EPLB 以及一套推理系统架构。这些项目都是重要的参考，但不能把面向昇腾的内核发布理解成对它们的完整移植。
一套生产集群仍然需要硬件准备、驱动和固件、CANN 安装、互联配置、分布式运行时支持、可观测性、检查点、故障恢复，以及训练或服务编排系统。华为云的 DeepSeek 部署指南 展示了实例、网络、子网和安全组等基础设施内容；这些服务是部署前提，但并不属于 DeepGEMM-Ascend 本身。
这一边界对于训练场景尤其重要。公开内核可以解决某个性能瓶颈，但不能证明仅凭公开仓库就能复现大规模前沿模型训练。
现在谁能使用这套技术栈
| 用户或组织 | 现在能用吗？ | 需要什么 | 实际判断 |
|---|---|---|---|
| 拥有昇腾 950 硬件的团队 | 可以，但仅限受支持的内核 | Linux 环境、匹配的驱动/固件、CANN 9.20、TorchNPU、编译器，以及兼容的 Python/PyTorch 环境 | 最适合率先尝试 |
| 拥有昇腾资源的华为云或企业运营方 | 有可能 | 受支持的实例/集群，以及准确的软件版本矩阵和部署能力 | 适合受控评估和服务部署 |
| 使用较旧昇腾硬件的研究实验室 | 不能自动认为可以 | 需要确认设备支持情况；首个 DeepGEMM-Ascend 版本是在昇腾 950 系列上开发和验证的 | 不要默认兼容 910B/910C |
| 只有 NVIDIA 工作站的用户 | 不能运行这些昇腾内核 | 文档明确要求昇腾硬件 | 改用面向 NVIDIA 的 DeepSeek 仓库 |
| 没有加速器资源的普通 PyTorch 开发者 | 无法进行有意义的实际运行 | 可以查看代码、研究 API，但无法复现硬件基准测试 | 能读文档不等于能运行 |
| 想要开箱即用的前沿模型训练替代方案的团队 | 目前没有公开证据支持 | 还需要完整集群、系统集成和生产验证，不能只依赖这些内核仓库 | 应当把它视为基础设施项目，而不是一次 pip 安装 |
从依赖要求也能看出实际边界：在目前记录的版本中，这套软件仍然绑定昇腾 950 硬件、CANN 和 torch_npu。这比“兼容各种加速器”的说法要窄得多。
这些公开数据能证明什么，又不能证明什么
99.8% 的密集 GEMM 利用率，说明列出的昇腾内核在特定形状下能够高效使用测试设备。MegaMoE 表格则进一步说明，DeepSeek 处理的不只是孤立的矩阵乘法，也包括融合后的专家并行工作负载。
但这两类结果都无法回答采购或训练团队最终关心的问题：
- 完整模型的端到端 token 吞吐是多少？
- 在目标 batch size 下，每个 token 的成本是多少？
- 长时间运行和重启后的稳定性如何？
- 哪些算子会退回到优化程度较低的路径？
- 互联、内存和功耗与计划采用的 NVIDIA 集群相比如何？
- 脱离原始测试环境后，是否还能复现相同结果？
DeepSeek 已经发布了较为完整的昇腾内核工作，包括配置细节和部分性能表格。这些内容降低了已经进入昇腾生态的团队的软件门槛，但硬件和版本门槛依然存在。
常见问题
DeepSeek 的昇腾基础设施是完全开源的吗？
不是。DeepGEMM-Ascend 及相关文档已经公开，但这些材料并没有提供一套包含全部依赖和运维流程、可以直接使用的 DeepSeek 训练集群。
可以在 NVIDIA GPU 上运行 DeepGEMM-Ascend 吗？
不可以。它面向昇腾 950 硬件。NVIDIA 用户应当使用 DeepSeek 面向 NVIDIA 的项目。
这是否证明 DeepSeek 正在使用昇腾训练前沿模型？
不能。这只能证明 DeepSeek 发布了昇腾内核，并对部分工作负载进行了基准测试，不能证明已经公开了一套端到端的前沿模型训练复现方案。
如果你已经拥有受支持的昇腾资源，并且能够自行处理 CANN/TorchNPU 的兼容性问题，现在就可以开始使用这套技术栈。对于只有 NVIDIA 硬件的用户，应当把它视为技术参考，而不是可以直接运行的后端。