正在加载，请稍候
DeepSeek 把矩阵乘、专家并行通信、注意力等核心算子补齐到昇腾 950。国产算力评估的第一道墙被推倒，接下来要算的是迁移成本、双栈运维与有效吞吐三笔账。
2026 年 9 月 30 日，DeepGEMM 仓库的 News 栏多了一行：面向华为 NPU 的版本已可用，配套还单独开了一个昇腾专用仓库。这行更新不显眼，但它补的是训练与推理里最吃性能的几块。对正在做国产算力评估的团队，它改变的不是「能不能跑」，而是「值不值得跑」。
过去这些库基本只有英伟达一条路线，这次逐个给出了昇腾侧的对等实现：
| 组件 | 在训练与推理里管什么 | 昇腾侧状态 |
|---|---|---|
| 矩阵乘核心库 | FP8 / FP4 / BF16 的 GEMM，含融合 MoE 通信 | 独立开源了专用仓库 |
| 专家并行通信库 | MoE 的 all-to-all dispatch 与 combine，支持 FP8 | 提供昇腾实现 |
| 算子编译后端 | 张量算子的描述与代码生成 | 补齐昇腾后端 |
| 注意力计算 | 长上下文下的注意力核 | 提供昇腾实现 |
| 稀疏选择 | MoE 里的专家路由挑选 | 提供昇腾实现 |
| 通用算子集 | 其余基础 kernel | 提供昇腾实现 |
官方口径里还有一句更值得盯：已与华为协同完成 128 卡超节点的计算与通信联合优化（当天事件可对照站内的 10 月 1 日早报）。清单说明「有对等实现」，这句话说明「已经在集群尺度上调过」。
一个单卡 demo 只能证明「这块芯片能算」。上到生产环境，决定成本的是另外三件事：关键路径的算子覆盖率、卡间通信效率、以及长上下文下的注意力开销。
这也是 128 卡超节点那句话的分量所在。规模上去之后，瓶颈会从单卡的算术吞吐，转到卡与卡之间的数据搬运。专门做专家并行 all-to-all 的那个通信库被同步搬到昇腾，说明要补的正是这块。它的定位写得很直白——为 MoE 的 dispatch / combine 提供高吞吐、低时延的 all-to-all kernel。通信不补齐，单卡再快也堆不到大集群。
生态缺件是过去评估国产卡最先撞上的墙，现在主流算子有了对标实现，第一道墙被推倒。接下来要算的是三笔账：
一个常见的坑：把在一家硬件上调好的并行切分和 batch 参数，原样搬到另一家。拓扑不同、内存层级不同，同一组参数往往跑不出同样的结果。正确做法是重做一遍小规模 benchmark 矩阵，而不是改两行环境变量就上线。另一个坑是只看榜单分数——不同评测集对通信的权重完全不一样，榜单好看不等于你的业务链路好看。
延伸阅读：落地阶段的实际账，可对照站内桌面端 AI 架构的工程账本与「95% 的试点进不了生产」那篇卡点复盘；把平台差异集中收进适配层的做法，这篇团队能力建设复盘讲得更细。
这不是「替代」问题，而是「关键路径是否已有对等实现」的问题。推理侧的成熟度通常高于训练侧；训练侧还要看框架适配、稳定性与长周期任务的表现。算子补齐把评估成本降下来了，但不等于可以直接平替。
不一定。成本取决于你把多少业务纳入双栈。只对「必须可切换」的业务做双栈，其余保持单栈，增量是可控的。
需要。即便你不写 kernel，推理框架、量化方案、并行策略最终都会落到这几套库上。它们的成熟度，直接决定你的方案能不能落地。
评估成本下降。过去卡在生态缺件，连验证都难做；现在可以先做小规模对照跑分，再决定是否上量，试错成本比一年前低得多。
如果你的模型要在国产卡与英伟达路线之间做对照评估，蓝曜炬辉可以协助先把算子依赖、双栈运维与有效吞吐这三笔账算清，再决定是否上量。预约一次架构评估，我们把评估清单先发给你。