DeepSeek 把算子开源到了昇腾上，这件事意味着什么

一、先说结论

一句话：2026 年 9 月 29、30 这两天，DeepSeek 旗下两个新建的昇腾专属仓库——DeepGEMM-Ascend 与 DeepEP-Ascend——先后建仓、首发，DeepSelect 也在同期发布了昇腾内核；而作为基础设施的 DeepJIT，其实早在 9 月初就已经是 CUDA 与昇腾双后端了。整个过程没有发布会，没有新闻稿，就是在代码托管平台上建仓、发版本、改说明文档。

这批东西处在什么位置，先说清楚。模型像是端上来的一道菜，算子库、通信库这些是厨房里的锅铲和刀具。这里的"灶"，指的是昇腾 NPU 这块硬件本身；而"厨具"——算子、通信、编译这几类软件库——过去 DeepSeek 自研的这一批，基本只按英伟达的规格打造，现在有人按昇腾那口灶的尺寸，也打了一套。得说明一句：昇腾平台本身早有 CANN、Ascend C 这些基础软件栈，这里说的是 DeepSeek 自己开源的那一批算子，之前只随英伟达那条线走。

二、具体开源了哪四件东西

一件一段，说清各自是干什么用的。

1. DeepGEMM-Ascend：管矩阵乘的算子库

矩阵乘，说人话就是"一大批数字成批相乘再相加"，是大模型里最吃算力的动作。GPU 那边早有一个叫 DeepGEMM 的库负责这件事，昇腾这一版就是它的"移植"。官方说明写得很明确：DeepGEMM Ascend 和 DeepGEMM 使用相同的包名，也完全兼容 DeepGEMM 的 API——你装了这一个包，就能沿用原来的接口和开发流程，不用重写调用方式。

它支持几档精度的矩阵乘（BF16、FP8、FP4），也支持 MQA logits、MegaMoE 这类算子。它做的事，是把昇腾平台上一堆琐碎细节——分形矩阵怎么摆、对齐有什么限制、地址怎么算——包了一层薄壳藏起来，让上层开发者不用直接跟这些打交道。同时也用了昇腾自己的一些优化手段，比如稀疏数据加载、基于协程的流水线。

门槛得说清楚：要跑它，得有昇腾 NPU，官方写明是在 Ascend 950 系列上开发和验证的，还要配 CANN 9.20 这一整套工具。（这个版本号，DeepGEMM-Ascend 原文写 9.20，DeepEP-Ascend 原文写 9.2.0，两个仓原文写法不同，指的是同一套工具链。）这不是笔记本上能随手试的东西。

性能方面官方也给了数据：在 Ascend 950DT 上（CANN 9.20），稠密的矩阵乘最高能跑到硬件极限的 99.8%。这组数字同样来自官方 README，本文作者没有对应设备，未做独立验证；而且请注意，它和下面 DeepEP 那组不是同一套测试条件，两者别混着看。

2. DeepEP-Ascend：管通信的库

大模型如果按"专家"切开（术语叫混合专家，MoE），不同机器上负责的专家之间要来回传数据，这个库管的就是这件事。官方的说法是：它提供 MoE 里 dispatch/combine 的专家并行（EP）all-to-all 操作，也支持流水线并行、面向上下文和数据并行的集合通信等。一句话概括——它是机器之间"递数据"的那条管子。

这里有一句关键：它的公开 buffer API 与英伟达版 DeepEP 对齐。但要说准——接口名称与结构对齐，昇腾侧却有专属的模式与参数限制。官方原文写明：支持的模式和流行为是昇腾特有的；EP 必须开 do_expand=True 和 allow_multiple_reduction=True，do_handle_copy 须保持关闭；显式的 RDMA 服务等级和 QP 数量则不支持。所以"对齐"讲的是接口的样子，不是用法照搬。

性能上，官方 README 给了一组实测数据（测于 Ascend 950DT + CANN 9.2.0）：dispatch 大约在 313–375 GB/s，combine 大约在 272–347 GB/s，规模越大数字越低——从 EP8 一路到 EP128，是往下走的。官方还补充，专家并行规模不超过 32 时，持续 dispatch 能到有效载荷带宽上限的约 90–95%。官方同时说明，更大的 EP 规模与 combine 目前仍在优化中——也就是说，规模越大数字越往下走，一部分是物理带宽的规律，一部分也有成熟度还在打磨的原因。

这几个数字都来自官方 README，本文作者没有对应设备，未做独立验证。更要紧的是它们的测试条件：这组数字是官方在一块内部原型硬件（PoC HDK）上测的——README 自己写了，该配置并非公开发布的版本，官方还提醒，用早期 PoC 版本可能观测到更低的带宽；华为该型号（Atlas 850E）的商用版本，官方口径是 2026 年 10 月 15 日前后公开，具体何时能拿到、以什么形式发布，还得看华为那边的发布安排。换句话说，这组数字是在一块今天还买不到的机器上、还经过额外手工配置测出来的，不是你在市售设备上立刻能复现的产品数字。

3. DeepSelect：TopK 算子加采样器

TopK 这个词，说白了就是"从一大堆数里挑出最大的那几个"。在稀疏注意力里，它的作用是先筛掉不重要的部分，只留下值得算的，省下算力。官方说明它用于 DeepSeek V3.2、V4、V4.1 这几代模型的稀疏注意力（叫 DSA），并且同时支持英伟达 CUDA 和华为昇腾两条路线。官方称它相比原生的实现有 2–20 倍加速（同样来自官方 README，未独立验证）。

它对主要场景做了针对性优化：一个是"闪电索引"场景，官方说主要针对 topk=512 来调，也就是 V4 用的那个值。仓库里还有一个采样器的场景，负责从模型输出的概率里"抽签"选出下一个词。这里必须分清：昇腾侧目前只支持 bf16；采样器用的是 fp32，眼下只有 CUDA 那一版支持。也就是说，昇腾版是功能子集，不是逐个算子对等地搬过去；昇腾侧对应的是闪电索引里的 TopK（bf16），采样器那部分暂时落在英伟达这边。

4. DeepJIT：运行时编译的地基

这一件不像前面三件那样直接面向"跑模型的人"，它是给写代码的人用的基础设施。官方说它是一个轻量的运行时库，让写 C++/Python 扩展的人能在程序跑起来之后，现场把一个算子编译出来、缓存编译结果、加载到设备、再启动它。

它最值得注意的一点是：CUDA 和昇腾两个后端，用的是同一套编译、加载、启动的流程——写代码的人只要换一个后端类型，走的就是另一块芯片。此外它还支持把编译好的缓存放到共享文件系统上，让不同用户、进程、机器复用。回头看时间线，它是这批里建仓最早的一个（9 月 8 日），先于其余三件。

三、为什么这是件事

先看对照。GPU 那一边，DeepGEMM 从 2025 年 2 月建仓，攒到近八千颗星；DeepEP 超过一万颗星。这次昇腾这一版，官方自己说是"移植"和"与 NVIDIA 版对齐"。也就是说，它不是另起一套，而是尽量把接口做成一致的。

"同一包名、接口兼容"到底意味着什么？对已经在用这两个库写代码的团队来说，迁移到昇腾平台时，最实在的一块成本——把上一层的调用代码重写一遍——理论上可以省掉，因为调用的样子是一样的。

但这话得说住。接口一致，讲的是"叫法一样"，不等于性能一样，也不代表所有算子都有一一对应；昇腾版目前是功能子集。比如多头注意力的那个库 FlashMLA（GPU 版超过一万三千颗星），目前暂未见到昇腾版本，官方也没有说过会做。所以准确的表述是：这次补上的是计算、通信、采样、编译这几块，是"四个零件放到昇腾上"，不是"整套东西都搬过去了"。

四、华为这边是什么态度

昇腾这边不是被动接收。据昇腾社区官网（本稿采集日 2026-10-04），官网有一个官方的 DeepSeek 专区（https://www.hiascend.com/developer/deepseek），页面上写着"昇腾已支持 DeepSeek 系列模型，更有丰富官方技术文章，欢迎体验"，专区里放了模型权重获取、官方技术文章、故障案例和讨论区。

据同一来源（昇腾社区官网，2026-10-04 采集），几处细节能看出对接的深度：

• 官方技术文章里有一篇《DeepSeek-V4 适配安装常见问题》（2026/09/24），说明 V4 已经在昇腾一侧做过适配；
• 官方故障案例库里有《多机无法拉起 DeepSeek-R1 模型，服务器 NPU 通信问题》这类条目，是真实跑起来之后才会遇到的坑；
• 昇腾文档（MindIE 3.1.0）里写：当专家并行数超过 32 时，DeepSeek-V3、DeepSeek-R1 会自动启用 Grouped MatMul 融合算子，用来提升计算性能；
• 昇腾侧还有一个 clangd-ascend，是 DeepSeek 开源的代码补全与检查工具。

把这些和上面四个仓库连起来看：一边是 DeepSeek 把计算相关的零件按昇腾的规格补上，另一边是昇腾把模型适配和踩坑记录整理成官方资料。从公开时间线看，双方动作接近、彼此呼应，但官方并未对这种"协同"作任何定性——是巧合还是有意的配合，公开资料里看不出来，本文不下判断。

五、谁能用上

分人群说，别一概而论。但有一个前提得先摆出来：能吃上这波的前提，是手上有 Ascend 950 这一级的设备；而按官方口径，支撑这批性能指标的商用硬件（Atlas 850E 的商用版本）要到 2026 年 10 月 15 日前后才公开。所以在本文写作时，严格说还没有公开可买的设备能完整复现这套东西——这一点会直接影响下面几类人"现在到底能不能用"。

手上已经有昇腾机器、又在跑 DeepSeek 系模型的团队——最直接（在有 950 级设备的前提下）。接口名称对齐意味着改动相对小，可以先去四个仓库的说明文档里对一遍自己用到的算子和参数限制。

在做国产化替换、之前卡在"算子这层得自己重写"的团队——也有价值。现在有官方版本摆在这儿，至少多了一条可参考的路，不用从零摸索。

普通开发者和学员——说实在的，暂时多半用不上。它需要昇腾 NPU 和整套工具链，多数人手上没有这种设备。但这类工作值得读一读，尤其是 DeepSelect 仓库里那篇中文的深入分析文章，能让人看清"一个算子从需求到落地"大概长什么样。

做研究、写论文的人——可以关注"同一份接口适配两个后端"这件事本身。把编译、缓存、加载做成一套通用流程，是这次几个项目里比较有想法的地方。

六、想深入的人从哪儿进去

• 四个仓库（都在 GitHub 的 deepseek-ai 组织下）：
• DeepGEMM-Ascend：https://github.com/deepseek-ai/DeepGEMM-Ascend
• DeepEP-Ascend：https://github.com/deepseek-ai/DeepEP-Ascend
• DeepSelect：https://github.com/deepseek-ai/DeepSelect
• DeepJIT：https://github.com/deepseek-ai/DeepJIT

事实和性能数字以各仓 README 为准；多数仓的 README 是中英双语的。

• 先看这篇：DeepSelect 仓库里带了一篇中文的算法与实现分析（docs/DeepSelect-deep-dive.zh.md），讲一个算子怎么从需求走到实现，值得一读。
• 华为侧：昇腾社区官网的 DeepSeek 专区 https://www.hiascend.com/developer/deepseek ，那里有模型适配文章和故障案例。
• 想要动手的人，按各仓说明文档走，本文不转述任何安装步骤——那些东西随版本变，写出来容易过期。

七、现在还不能断言什么

写这种题，最怕把"几个开源仓库"读成"大局已定"。把边界交代清楚：

不能说"DeepSeek 转向了昇腾"，也不能说"弃用 CUDA""对标英伟达"。官方从头到尾没有这种表述。它做的是：在原来的英伟达路线之外，补上昇腾这一条，两边并存。这是补充，不是替换。

性能数字都是官方的，而且测试条件特殊。上面那些带宽和加速比，出处都是官方 README，没有第三方复现，本文作者也没有设备实测。尤其 DeepEP 那组带宽，测在内部原型硬件上、非公开发布的配置，官方自己提醒过早期版本可能更低——它可以作为参考，不能当作市售产品的能力结论。

"能用"到什么程度，暂无权威数据。V4 在昇腾上的适配覆盖多广、生产环境下稳不稳、和 GPU 那边差距多大——目前没有权威的横向对比数据，谁都别急着下判断。而且昇腾版是功能子集（如 DeepSelect 只支持 bf16），这种"部分支持"的边界，要落到具体场景里才看得清。

验证硬件本身还没公开发售。这批东西要完整跑起来需要 Ascend 950 级设备，其商用版本官方计划 2026 年 10 月 15 日前后公开；在那之前，绝大多数人没有条件复现官方数字。

后面会不会有更多算子跟进，官方没说。会不会出 FlashMLA 的昇腾版、会不会有别的，现在无从预判。

商用之前记得自己确认许可。其中 DeepEP-Ascend 仓库的许可字段是空的，这类细节在正式采用前要自己核对一遍。

所以更准的说法是：DeepSeek 把四个计算相关的开源项目补上了昇腾版本，接口尽量和 GPU 那边对齐；华为一侧也把模型适配和资料准备好了。剩下的——跑得怎么样、覆盖多广、跟英伟达那边差多少——要等真实使用和独立测试出来再谈。现在能确认的是"东西放出来了"，不是"事情做成了"。

关于本文：这篇是依据公开资料的一次独立观察，我和 DeepSeek、华为两边都没有隶属或利益关系，不是替谁发的官方通稿，文中的判断也只代表个人理解。