昇腾 950 跑出 99.8%，这个数字能外推多远

lgf228

73人浏览 · 2026-10-26 03:31:27

lgf228 · 2026-10-26 03:31:27 发布

📋 目录

一、先把 99.8% 的完整坐标写出来
二、同一个 99.8% 掩盖了什么
三、DeepInfer 里的昇腾：支持，与验证之间隔着什么
四、为什么这行字的分量仍然很重
四点五、昇腾这条线的整体进度条
五、还有几个数字需要单独纠正
六、对企业决策的实际含义
七、结语

一、先把 99.8% 的完整坐标写出来

这个数字被反复引用，但很少有人把它测量的条件一起引用。

DeepGEMM-Ascend 是 DeepSeek 在 2026 年 9 月 30 日开源的矩阵乘算子库昇腾版。首次发布的基准跑在 Ascend 950DT 上，用 CANN 9.20，测量时 L2 是冷的，测试形状和用例取自 DeepGEMM 自带的测试套件。

官方发布的密集型 GEMM 数据是这样的：

精度	实测算力	硬件上限	利用率	矩阵形状	耗时
BF16 × BF16	431 TFLOPS	432 TFLOPS	99.8%	M=4096, N=7168, K=16384	2229.9 μs
FP8 × FP8	861 TFLOPS	865 TFLOPS	99.5%	同上	1117 μs 稍多
FP4 × FP4	1701 TFLOPS	1730 TFLOPS	98.3%	同上	565.6 μs

这三个比例彼此之间还有一层交叉验证关系：1701 : 861 : 431 ≈ 4:2:1，这是张量架构的典型比例，间接说明这些数字内部是自洽的，不是各自凑出来的。

还有一组面向推理的 FP8 形状数据，其中一个 128×32768×512 的形状耗时 10.4 微秒、带宽 1829 GB/s；另一个 128×7168×16384 的形状耗时 54.8 微秒、带宽 2456 GB/s。

到这里为止，99.8% 是一个非常硬的数据。但它测的是矩阵乘这一个算子的一种精度一种形状。

二、同一个 99.8% 掩盖了什么

DeepSeek 这次开源的昇腾侧算子栈是一整套，共六个组件：

组件	作用	官方公布的实测	相对硬件上限
DeepGEMM-Ascend	矩阵乘	431 TFLOPS (BF16)	99.8%
FlashMLA-Ascend	稀疏注意力	prefill 410 TFLOPS / decode 360 TFLOPS	95% / 83%
DeepEP-Ascend	专家并行通信	dispatch 带宽 373–375 GB/s (EP8)	90%–95%
TileKernels	向量、访存、量化、路由算子	未单独公布	—
DeepSelect	TopK 选择	未单独公布	—
TileLang	算子编译语言层	未单独公布	—

把这张表和上一张表放在一起看，会发现一个有意思的分布：越靠近单个算子的峰值，利用率越高；越靠近系统级的东西，利用率越低。

注意力 decode 只有 83%，是所有公布数据里最低的。而 decode 恰恰是推理服务里最吃带宽、持续时间最长的一段。

通信侧的差距更值得看。DeepEP-Ascend 公布的性能表显示：

专家并行规模	dispatch 带宽 (GB/s)	combine 带宽 (GB/s)
EP8	373–375	345–347
EP128	313–320	272–278

按区间中点算，从 EP8 扩到 EP128，每 rank 的 dispatch 带宽下降约 15.4%，combine 带宽下降约 20.5%。

这个衰减幅度接近五分之一。MoE 模型在万亿参数级别上，跨节点通信是硬约束——扩展性打折，是比单点算力更致命的问题，因为单点算力可以用更多卡补，通信效率衰减补不了。

而且官方对这张表有明确限定：测量环境使用了手动配置了额外设置的测试 HDK。这句话的意思是，别人照着做可能拿不到同样的数。

用一个算子的峰值占用率去推断"昇腾跑 DeepSeek 没问题"，和用一个灯塔的亮度去推断整座港口的吞吐量，是同一类错误。

三、DeepInfer 里的昇腾：支持，与验证之间隔着什么

回到 DeepInfer 本身。昇腾在支持列表里的位置，确实是这次开源最有分量的信号之一。

README 的硬件支持列表写得很清楚：

NVIDIA SM100 GPUs
Huawei Ascend 950 NPUs

构建时切换一个环境变量即可：NVIDIA 侧 DEEPINFER_ACCELERATOR=nvidia（配 CUDA 13），昇腾侧 DEEPINFER_ACCELERATOR=ascend（配 CANN 9.2）。

DeepSeek 与华为的合作不是一天形成的。此前 DeepSeek 已经开源了面向昇腾的一整套组件，官方说明里明确提到华为为该项目提供了大量技术支持，两家公司还基于昇腾 950 代联合优化了 128 芯片超节点架构。有报道说华为昇腾已支持 90 多个主流第三方开源项目。

还有一组更具体的采购侧信息：彭博社报道 DeepSeek 计划为内蒙古新数据中心采购至少 16 万颗昇腾 950DT 芯片，路透社报道了 DeepSeek 与华为在昇腾编程工具上的协作。

**所以"昇腾 950 官方在跑"这个说法，在战略层面是站得住的。**但从"DeepInfer 支持昇腾"到"DeepInfer 在昇腾上跑出了什么性能"，中间隔着三道坎。

**第一道坎：两个关键特性只对英伟达开放。**README 里 batch-invariant inference 和 deterministic sampling 两项都明确标注 NVIDIA only。昇腾路径拿到的是功能子集。

这有实际后果。如果你的场景既要结果可复现（Agent 工具调用、代码生成、离线评测都算），又要用国产卡，这两件事目前不能同时成立。

**第二道坎：官方跑分全在英伟达硬件上完成。**prefill 用 4 张 SM100、decode 用 64 张，且各自在一个 scale-up 域内。DeepInfer 没有公布任何昇腾 950 的实机吞吐数据。

**第三道坎：没有第三方复现。**截至发稿，公开材料里找不到第三方在昇腾 950 上复现 DeepInfer 的数据，DeepSeek 也没说明验证规模。

还有一个常被忽略的细节：**"兼容昇腾"只写到厂商名称这一层。**具体支持哪些芯片型号、覆盖哪些部署环境，官方说明没有列出，不能从"兼容英伟达与华为昇腾"推出对单卡或特定集群的适配结论。

还有一处反直觉的事实值得说：**消费级 Blackwell 也不行。**RTX 5090 虽然同属 Blackwell 架构，但计算能力是 12.0（SM120），而 DeepInfer 目标是数据中心向的 SM100。同为"Blackwell"，架构不同。

这条链上，DeepInfer 的昇腾线目前站在第二格到第三格之间：能编译、能跑（理论上），官方跑分覆盖的是英伟达，昇腾实测是空白。

**"支持"是一行字，"验证"是一整套数据。**把前者读成后者，是这次开源传播里最需要警惕的一处过度解读。

还有一个反向的提醒：**不要因为"昇腾没数据"就推断"昇腾不行"。**目前的状态是证据不足，不是结论不利。DeepGEMM-Ascend 的 99.8% 是硬数据，说明底层软件适配的质量很高；服务层没有数据，可能只是因为公开可用的昇腾 950 整机集群稀缺、或者第三方还没有动力去做这个复现。

**正确的信息状态是"未验证"，不是"不达标"。**这个区别在决策上很关键——未验证意味着要等、要自己测、要做小规模验证；不达标意味着要放弃。两者的动作完全不同。

四、为什么这行字的分量仍然很重

说完边界，还是得说清这件事的分量，否则会读出相反的结论。

**第一，这是"一等公民"而不是"能跑就行"。**DeepInfer 的设计结构里，昇腾不是事后加的兼容分支。TileKernels 会自动在 NVIDIA 与华为后端之间选择，同时暴露同一套 Python API；DeepGEMM-Ascend 设计成与原版 API 完全兼容，使用同一个 deep_gemm 包，调用代码不需要重写；DeepEP-Ascend 的公开 buffer 接口与 NVIDIA 实现对齐。

这些设计的意义是：**同一份业务代码换硬件不用重写。**这正是过去国产算力最大的隐性成本——不是芯片不行，是软件栈要推倒重来。

**第二，它是可迁移性的第一个硬证据。**有第三方分析梳理得很清楚：如果硬件的内部数据表示不统一，换芯片就不只是换指令。FlashMLA 的稀疏注意力 kernel 里，一个 Cube core 加两个 Vector core 协同完成矩阵运算、数据搬运和低精度到计算格式的转换，KV cache 与修正因子在内存中相邻存放以减少拷贝。移植到另一种芯片，需要的不是改写同样的计算，而是按芯片结构重新设计数据的布局和流动方式。

API 可以统一，内核不行——但至少现在上层 API 统一了，这是从"各厂商自己维护一个分支"到"一套 API 两种后端"的关键一步。

**第三，vLLM 的行为给出了另一个视角。**DeepSeek 开源后不到五天，vLLM 就宣布通过集成 DeepSeek 开源的 kernel 并深度优化 prefill 与 decode，在官方 decode 配置、batch 8 到 256 全区间匹配了 DeepInfer 的性能曲线，工程博客把差距量化为 6% 以内。

这说明两件事：DeepSeek 的算子价值确实高，高到通用框架四天内就吸收了；同时，昇腾这条线上，通用框架的追赶路径可能比 DeepInfer 自己更快——因为 vLLM 没有"昇腾功能子集"这个包袱，它本来就有跨厂商支持的传统。

四点五、昇腾这条线的整体进度条

把这次开源涉及昇腾的部分放到一起看，能画出一条比较清楚的进度条：

环节	状态	证据
算子层（矩阵乘、注意力、通信、TopK、编译）	已开源并有实测数据	9/30 DeepGEMM-Ascend 等六件套，BF16 99.8% / FP8 99.5%
引擎层（调度、并行、投机解码）	已开源，有官方跑分	10/20 DeepInfer，官方基准全在 SM100
服务化层（KV 缓存、P/D 分离、副本均衡）	未开源	README 三项 not included，昇腾侧同样没有
确定性能力（批不变、确定性采样）	昇腾侧缺失	README 标注 NVIDIA only
端到端第三方复现	空白	未找到昇腾 950 上复现 DeepInfer 的公开数据
大规模生产负载数据	空白	有 16 万颗采购规划报道，无部署完成度数据

这张表的价值在于它把"昇腾已经很强"和"昇腾可以放心用"这两件事分开了。前者在算子层是成立的，后者在服务层还差三步。

一个容易被忽略但很关键的观察：**官方基准全在英伟达上跑，这不只是数据缺失，它意味着昇腾侧连"基准可比"这件事都还没开始。**要做出可比的数据，需要在昇腾 950 上跑同样的 4 卡 prefill / 64 卡 decode 配置、同样的 EP64DP64 拓扑、同样的 131K 上下文和 nextn=3。这些都需要昇腾 950 的整机集群，而这样的集群目前在公开范围内是稀缺的。

所以更准确的表述是：不是昇腾跑不出来，而是还没有人在公开场合把它跑出来过。

另外值得记一条工程细节。DeepGEMM-Ascend 的 JIT 缓存行为对日常使用影响最大：DG_JIT_CACHE_DIR 取一个目录或冒号分隔的目录列表，查找时从前到后遍历、首个命中即胜出，未命中则编译进第一个路径，默认是 $HOME/.dj。另一个坑是——每个 DG_JIT_ 变量在未设置时都会回退到对应的全局 DJ_JIT_ 变量，而这个值在 JIT runtime 首次创建时就被快照了。runtime 存在之后再改这个变量，不会有任何效果。

这条细节的意义超出算子库本身：它说明昇腾路径上的 JIT 行为与 NVIDIA 路径不完全一致，同一份代码在两个后端上的调优参数不可直接照搬。第三方分析也提醒过，昇腾路径的 scaling factor 处理要遵循 UE8M0 packing rule，这与 NVIDIA 路径不同。

五、还有几个数字需要单独纠正

这一轮开源的中文传播里，混进了几个不属于同一件事的数据，一并纠正。

**"FlashMLA 达到 410 TFLOPS"被当成 DeepInfer 的成绩。**这来自 DeepGEMM-Ascend 那个 9 月 30 日的算子项目，不是 10 月 20 日开源的推理框架的引擎跑分。

**"昇腾版 DeepGEMM 在昇腾 950DT 上实现密集矩阵乘法 99.8% 的硬件极限利用率"被当成整模型性能。**上面已经拆过：单算子、单精度、单形状。

**“昇腾 950 与 SM100 完全等价”。**两个特性只对英伟达开放、官方跑分全在英伟达，这个"等价"没有依据。

**“DeepSeek 开源了全栈国产化推理方案”。**开源的六件套是算子层与框架层，加上 DeepInfer 这个引擎。DeepInfer README 里明确没给的三样——KV 缓存系统、Prefill/Decode 分离、跨副本负载均衡——在昇腾上同样没有。

还有几个数字按栏目规矩列出来，不予引用：

流传数字	不引用的理由
“昇腾 950 推理性能已追平英伟达”	无任何第三方在昇腾 950 上复现 DeepInfer 的端到端数据
“DeepInfer 在昇腾上达到 99.8% 利用率”	把 DeepGEMM-Ascend 的单算子数据与引擎跑分混为一谈
“昇腾生态已全面取代 CUDA”	官方自己说这套软件不能复现 CUDA 更广泛的库、工具链和应用支持广度
“DeepEP-Ascend 扩展性无衰减”	官方自己的表显示 EP8→EP128 dispatch 降约 15.4%、combine 降约 20.5%
“128 芯片昇腾超节点推理性能数据”	官方说明联合优化了通信与计算，但未公布可引用的端到端推理吞吐
“昇腾 950 已被大规模商用部署”	有 16 万颗的采购规划报道，但无部署完成度与生产负载数据

最后一行特别值得注意它的方向：**采购 16 万颗，说明 DeepSeek 是在真金白银地用它；而没有生产负载数据，说明这些卡究竟跑出了什么性能，外部目前无从判断。**这两件事同时成立，不矛盾。

六、对企业决策的实际含义

把前面这些落到一个要选型的团队身上。

**第一步，先看你的场景对昇腾的硬需求来自哪里。**如果来自合规（政企、金融的信创要求），那这是准入门槛而不是性能选择，讨论的起点就不是"昇腾够不够快"，而是"哪些环节必须在国产卡上"。如果来自成本，那就要拿本文第二节那张表去算——单算子 99.8% 与通信侧 20% 的衰减，合起来才是端到端的真实图景。

**第二步，明确"能跑"和"够用"之间的距离。**DeepInfer 的昇腾路径拿到的是功能子集（无批不变推理、无确定性采样），且官方跑分未覆盖。这两条对不同业务的杀伤力完全不同：

你的业务特征	昇腾功能子集的影响	优先级
离线批量处理（数据标注、合成数据、批量评测）	无影响，只要吞吐够	可以优先试
长文档分析、代码库理解	无影响，SWA 重放是引擎侧能力	可以试
Agent 工具调用需要结果可复现	直接不可用	必须换方案
需要跨批次结果一致（评测基线）	直接不可用	必须换方案

第三步，别把昇腾当成"英伟达打七折"的替代品去规划。更现实的定位是：把昇腾用在对结果一致性不敏感、但对吞吐和数据合规敏感的那部分负载上，把需要严格可复现的部分留在英伟达侧或 API 侧。

第四步，等第三方复现数据。这是最省事的策略。昇腾这条线目前最大的信息缺口不是性能数字，而是根本没有任何第三方实测。等第一批独立的端到端复现数据出来，再决定投入规模，比现在基于战略信号做大规模迁移要稳妥得多。

这四步的顺序不能颠倒：

关键是第三步和第四步的先后：**先算清楚自己需要什么，再等数据。**如果一开始就把昇腾当成"英伟达打七折"来做预算，等来的第三方数据会告诉你落差在哪，但你已经按错误的前提投了钱。

对领码 SPARK 融合平台的映射

这一节最该说的不是技术，而是这件事暴露出的一个治理缺口：硬件的差异会变成数据的合规差异。

其一，模型部署位置要成为治理对象。同一个 Agent，模型跑在英伟达集群还是昇腾集群上，数据的物理边界就不同了。这意味着"数据出域"这件事不能再只看"数据发给了哪个 API"，还要看模型在哪个域上运行、这次调用的推理侧落在哪里。领码的 iPaaS 接入层与治理中心要能把"这次调用触达了哪些算力域"记下来。

**其二，权限要跟着数据走，而且要跨域。**这条在硬件异构的场景下更容易被忽略：传统权限长在应用系统边界上，但模型部署在哪个集群，决定了数据最终落在谁的机房里。全域守卫要解决的是——同一个用户在英伟达侧和昇腾侧的授权范围，可能因为合规要求不同而不同，这个差异必须能被表达、被执行、被追溯。

**其三，能力子集要能被策略捕获。**昇腾路径没有批不变推理，这意味着"结果可复现"这个要求在昇腾侧无法满足。如果治理中心能把这个要求表达成一条策略（比如"标记为需复现的任务不得路由到不支持确定性的算力域"），那么这类差异就从运维的手工判断变成了系统的自动拦截。

一句话：**异构算力不是纯技术选型，它是合规边界的物理化。**平台要做的，是让这条边界可声明、可执行、可审计。