DeepSeek V4 + 昇腾：国产大模型推理的全栈验证

KADC 2026 系列分析 · 第 4 篇 · 端到端验证链 / 国产推理算力

---

为什么 DeepSeek V4 是昇腾的终极测试

谈国产算力适配大模型推理，最常见的说法是"支持主流模型"。但"主流"两个字太含混——DeepSeek V4 的出现，终于给了一个硬标准：如果你能完整跑通 V4 的推理，那几乎就没有你跑不了的模型。

原因很简单：DeepSeek V4 是目前最极端的 MoE 推理负载，没有之一。

先看架构参数。V4 总参数量 1.6T，激活参数 49B，61 层 Transformer，hidden dimension 7,168。384 个路由专家加 1 个共享专家，共 385 个 FFN 模块。每个 token 只激活 topK=6 个路由专家——激活率仅 1.56%。专家中间维度 3,072。注意力头 128 个，头维度 512。上下文窗口 1M tokens。

这套参数对推理系统施加的压力是全方位的：

算子兼容性。 MoE 的 Expert Dispatch 和 Expert Combine 是非标准算子，不同硬件的实现路径差异大。加上 V4 独特的 CSA（4× 压缩）和 HCA（128× 压缩）注意力机制，标准算子库不一定覆盖。

EP 通信效率。 384 路由专家意味着 Expert Parallelism 需要大规模 All-to-All 通信。每个 token 要 dispatch 给 6 个专家、再从 6 个专家 combine 回来。单包大小只有 7-14KB，但频次随专家数呈平方级增长。这对互联带宽和通信延迟极其敏感。

KV Cache 容量和带宽。 1M tokens 上下文 + 128 个注意力头 + 512 头维度，KV Cache 的存储需求是天文数字。V4 采用了 BF16（RoPE 部分）+ FP8（其余部分）混合精度存储来压缩，索引器甚至降到 FP4——这说明 V4 团队自己在设计时就已经把 KV Cache 压力推到了极限。

长序列 Attention 计算。 滑动窗口 128 固然减轻了全局 attention 的压力，但 1M tokens 的序列管理、前缀缓存、以及 attention kernel 的内存访问模式，仍然是工程挑战。

一言以蔽之：DeepSeek V4 是一把尺子。昇腾在这把尺子上的刻度，就是国产推理算力的真实水位。

---

一、算子层：TileLang 的跨平台验证

适配任何新硬件，第一道关卡永远是算子。

算子层的核心问题是：大模型推理用到的上百个算子，能不能在新硬件上跑起来？跑起来之后，性能够不够？开发成本高不高？

昇腾的算子生态主要有两条路径：Triton 前端和 TileLang 前端。前者已有 600+ 算子，后者 300+。但这次 KADC 上最值得关注的信息，来自北京大学杨智团队的 TileLang 验证结果。

TileLang 的跨平台机制

TileLang 是一个 Tile 级编程抽象的算子框架。它的核心思路是：把算子分解为 Tile 级操作——可以理解为一块一块的数据操作——Tile 大小可以按硬件特性调整。底层 codegen（代码生成器）针对不同硬件生成不同的微架构指令。

这意味着什么？一个 TileLang 算子源码，可以同时在 NVIDIA GPU 和昇腾 NPU 上运行。不同硬件的差异被 codegen 层屏蔽了，开发者只需要维护一套代码。

杨智团队的验证结论是：TileLang 在 DeepSeek V4 算子实践中表现"高开发效率与高性能"，Developer 模式下不同平台的算子仅有少量代码存在区别。

这个结论很重要，但需要准确理解它说了什么、没说什么。

它说的是：用 TileLang 写 DeepSeek V4 需要的核心算子，昇腾上的适配成本很低，性能也达到了可用水平。这是经过实际验证的——不是华为自述，是北大团队的独立报告。

它没说的是：所有 V4 用到的算子都已经覆盖。600+ Triton + 300+ TileLang，覆盖了"主流模型关键算子样例"，但"关键算子"不等于"全部算子"。长尾算子——尤其是一些特殊的 normalization、量化、或 V4 独有的 CSA/HCA 注意力机制中的细节算子——可能还需要逐个验证。

已验证 vs 待验证

对于 MoE 推理最核心的算子——Expert Dispatch、Expert Combine、Attention kernel——可以认为已验证。这些是 TileLang 明确展示的场景。

但对于 Triton 前端的算子，情况更复杂。目前已知 Triton 算子在昇腾上的性能是 Ascend C（昇腾原生算子）的 0.6-0.9 倍。这个范围不小——0.6 倍意味着几乎慢一倍，0.9 倍则接近原生。具体到 V4 推理，哪些算子落在 0.6 哪些落在 0.9，目前没有公开的逐算子基准数据。

---

二、框架层：PyTorch 生态对齐

算子层解决"能不能跑"的问题，框架层解决"迁移成本有多高"的问题。

这里的数字是：2300+ API 与 PyTorch 社区对齐。

数字背后的含义

2300+ API 对齐意味着什么？意味着大部分用 PyTorch 写的模型代码，理论上可以 zero-shot 迁移到昇腾上运行——import torch 改成 import torch_npu，大部分代码不需要修改。

但"对齐"这个词需要拆开看。API 签名对齐（函数名、参数、返回值一致）和性能对齐（同样的 API 在不同硬件上跑出相似的性能）是两件事。2300+ API 对齐说的是前者，不保证后者。

举个具体例子：torch.nn.functional.scaled_dot_product_attention 这个 API 在昇腾上可能签名完全一致，但内部实现路径不同——NVIDIA 走 FlashAttention kernel，昇腾走自己的 attention kernel——两者的性能特征、内存占用、数值精度可能都有差异。

更实质的指标是这几个：

40+ 模型图模式入图。 图模式（torch.compile 等）是把 PyTorch 的动态图编译成静态计算图以提升性能。40+ 模型能成功入图，说明昇腾的图编译器已经覆盖了主流模型结构。

20+ 模型 FSDP2 开箱即用。 FSDP2（Fully Sharded Data Parallel v2）是 PyTorch 的分布式训练/推理方案。20+ 主流大模型能开箱即用，说明分布式推理的框架适配已基本到位。

verl 的信号

verl 是目前最活跃的开源 RL 训练框架之一，用于 RLHF、GRPO 等训练后处理。昇腾与 verl 深度合作，实现了 fully async 模式，RL 训练效率提升 2 倍。

这个信号的含金量在于：它说明昇腾的适配不只是推理，训练后处理（RLHF/GRPO）也开始跑通了。而 RL 训练对框架的要求比纯推理更高——它涉及生成、奖励模型、策略更新的复杂循环，任何一个环节断链都不行。

8+ 强化学习社区合作，累计合入 10000+ 行代码。这是实实在在的开源贡献量，不是口头的"兼容"承诺。

---

三、推理引擎层：vLLM + SGLang + xLLM

框架层是基础设施，推理引擎才是用户直接交互的层。这一层的适配质量，直接决定了推理体验。

昇腾在这一层同时拿下了三个推理引擎：vLLM、SGLang、xLLM。这不是随机选择，三个引擎分别覆盖了推理场景的不同需求。

vLLM：原生合入

vLLM 是当前通用 LLM 推理的事实标准。昇腾是唯一自主创新硬件厂商原生合入 vLLM 主干代码。

"原生合入"和"适配层"有本质区别。适配层是事后 patch——硬件厂商维护一个 fork，用户需要用特定的分支或安装额外的 patch 包。原生合入意味着昇腾是 vLLM 的一等公民，主仓的每一次更新都会包含昇腾的适配代码。

具体性能数据：长序列场景首 Token 时延降低 30%。这个数字需要有上下文——降低 30% 是相对什么？如果是相对昇腾之前的实现，那说明原生合入后的优化效果显著；如果是相对 NVIDIA GPU，那这个数字就更惊人。从 KADC 的表述来看，更可能是前者。

SGLang：原生合入

SGLang 是目前最快的开源推理框架之一，尤其在 structured generation（结构化生成）场景下表现出色。昇腾是唯一自主创新非 GPU 硬件厂商原生合入 SGLang 主仓。

SGLang 的性能优势来自其对推理过程的深度优化——radix attention、continuous batching 的精细调度、以及对 KV Cache 的高效管理。昇腾能原生合入 SGLang，说明这些优化逻辑已经能在昇腾的硬件特性上正确运行。

xLLM：全模态

xLLM 是中国团队的开源大模型推理引擎，定位是"如同操作系统般连接底层芯片与上层大模型应用"。它的特点是原生支持文本、图像、视频全模态，并且深度适配昇腾超节点技术。

xLLM 的意义在于：它不是在通用推理框架上加一个昇腾后端，而是从一开始就考虑了昇腾超节点的互联特性。未来将深度适配昇腾 950 超节点——这是一个面向未来的布局。

三个引擎同时适配意味着什么？

• vLLM 适合通用 LLM 服务部署，用户基数最大
• SGLang 适合追求极致延迟和吞吐的场景
• xLLM 适合多模态和超节点场景

昇腾不是选边站，而是全面覆盖。这降低了用户的选择成本——不管你用哪个推理引擎，昇腾都是可选平台。

---

四、EP 通信优化：MoE 推理的核心瓶颈

前面三层（算子、框架、推理引擎）解决的还是"能不能跑"和"好不好用"的问题。EP 通信优化解决的是"能不能跑得快"的问题——而这恰恰是 MoE 推理最大的性能瓶颈。

DeepSeek V4 的 EP 挑战

Expert Parallelism（专家并行）是 MoE 模型推理的核心分布式策略。384 个路由专家分布在多张卡上，每个 token 需要被 dispatch 到其 topK=6 个专家所在的卡上，计算完后再 combine 回来。

这个过程需要 All-to-All 通信。问题在于：

1. 单包极小。 每个 token 发给单个专家的数据包只有 7-14KB（取决于 hidden dim 和 batch 配置）。这么小的包，传统的 TCP/IP 网络协议栈效率极低——协议头开销占比大，中断处理频繁。

2. 频次极高。 如果一个 batch 有 B 个 token，每个 token 要发 6 个包、收 6 个包。384 张卡之间，每个 step 的通信次数是 B × 6 × 2（dispatch + combine）。

3. 延迟敏感。 MoE 的 dispatch 和 combine 是在推理的 forward pass 中间发生的，不像数据并行可以和计算重叠。通信延迟直接加到推理延迟上。

昇腾的解决方案

从 KADC 发布的信息看，昇腾的 EP 通信方案有几个关键设计：

Scale Up 域完成 EP 通信。 不经过传统网络（RoCE/InfiniBand），直接在超节点内部的 Scale Up 互联上完成。这避免了协议栈开销，降低了延迟。

Load&Store 语义处理小包。 7-14KB 的小包不走 DMA（DMA 对小包有启动开销），而是用 Load&Store 语义——本质上就是 CPU-like 的内存访问，由硬件直接完成。这大幅降低了小包通信的延迟。

DMA 处理大包。 当 batch size 大、包 size 超过阈值时，切换到 DMA 模式，利用硬件 DMA 引擎实现高带宽传输。

CCU 硬化集合通信。 CCU（集合通信单元）把集合通信操作（AllReduce、All-to-All 等）硬化到芯片中，减少 CPU 参与度。这对 MoE 的高频集合通信尤其重要。

SSU + UB 直连 KV Cache。 SSU（共享存储单元）和 UB（统一缓冲区）直连 KV Cache，带宽提升据称可达"一个数量级"。

从 CloudMatrix 384 到昇腾 950

目前已有的验证数据来自 CloudMatrix 384（基于昇腾 910C）：

• 384 张 910C 组成的集群
• DeepSeek-R1 推理验证（注：R1 基于 V3 架构，比 V4 简单）
• EP320 配置（320 个专家并行）
• decode 性能：1,943 tok/s/NPU

这个数据来自 arXiv 论文（2506.12708），是独立可查证的。

昇腾 950 超节点声称支持 EP8192（8192 卡）。如果互联带宽翻倍、加上 SSU KV Cache 的带宽提升，推理性能理论上会大幅高于 CloudMatrix 384 的水平。

但"理论上"和"已验证"之间，隔着实际的交付和测试。

---

五、诚实评估：已验证 vs 待验证

把前面的分析整理成一张表：

这张表应该贴在每一个讨论"国产算力是否可用"的会议室里。

---

六、判断

已确认的结论

DeepSeek V4 可以在昇腾上跑推理。 这不是一个 demo 级别的验证——从算子层（TileLang）到框架层（PyTorch）到推理引擎层（vLLM/SGLang/xLLM），全栈适配已完成。多个独立方的验证（北大团队、vLLM 社区、SGLang 社区）交叉佐证了这一点。

这是一个里程碑。不是因为它证明了昇腾"天下无敌"，而是因为它证明了一个最低限度的可用性：最极端的 MoE 推理负载，昇腾接住了。

开源社区的原生支持说明适配质量达到了社区接受标准。 vLLM 和 SGLang 的维护者不会接受一个性能糟糕或 bug 遍地的后端合入主仓。原生合入本身就是质量信号。

待验证的关键问题

8192 卡超节点的实际推理性能。 CloudMatrix 384 的 1,943 tok/s/NPU 是在 EP320 配置下取得的。EP8192 意味着专家并行度提升 25 倍，通信复杂度指数级增长。超节点内部的互联拓扑是否真的能撑住 EP8192 的 All-to-All 通信，这是昇腾 950 必须用实际数据回答的问题。

SSU + UB 直连 KV Cache 的实际带宽。 华为声称"一个数量级"的带宽提升，但没有公开独立测试数据。如果这个提升是真实的，1M tokens 上下文的 KV Cache 访问延迟将大幅降低，这对长序列推理至关重要。但"一个数量级"如果只是理论峰值与实际工作负载的差距，实际提升可能大打折扣。

Triton 算子 0.6-0.9× 的性能差距在 V4 推理中的实际影响。 如果 V4 推理的关键路径上的算子恰好落在 0.6× 那一端，整体推理性能可能会显著低于 GPU。如果落在 0.9× 那一端，差距就很小。这需要逐算子的基准数据来回答。

关键判断

如果 CloudMatrix 384 的 1,943 tok/s/NPU 数据可靠（目前看来是，因为有论文支撑），那么 950 超节点的推理性能有望大幅提升——互联带宽翻倍、SSU KV Cache、更多卡参与并行，理论上 decode 性能可能翻倍甚至更多。

但"有望"不等于"已验证"。

昇腾 950 的实际交付和大规模验证是下一个关键节点。在这个节点到来之前，所有关于 EP8192 和超节点推理性能的讨论都是推测。

对决策者的建议

对于关注国产推理算力的技术决策者和投资人：

昇腾已从"不能用"变为"能用"。 这是最重要的结论。DeepSeek V4 的全栈推理验证证明了这一点。如果你在评估国产算力是否可以作为推理方案的备选，答案是：可以作为备选。

但"能用"不等于"能在成本和性能上与 GPU 竞争"。 这是下一个要验证的问题。成本不只是硬件采购成本——还包括软件适配成本、运维成本、生态成熟度带来的隐性成本。性能不只是峰值吞吐——还包括长尾延迟的稳定性、不同 batch size 下的效率、以及多模态场景的扩展性。

关注昇腾 950 的交付时间表和第一批用户的实测数据。 那将是"能用"到"好用"的分水岭。

---

本文是 KADC 2026 系列分析第 4 篇。前三篇分别讨论了昇腾超节点架构、CloudMatrix 384 验证、和 CANN 算子生态。本系列持续更新中。