华为与DeepSeek的共生关系

正值中国国庆假期前夕，DeepSeek发布了对 TileLang、DeepGEMM、DeepEP、TileKernels、FlashMLA 和 DeepSelect 的 Ascend 支持。

双方都无法单打独斗。尽管华为拥有 Pangu，却缺乏能够证明其芯片具备训练或推理能力的前沿实验室；而 DeepSeek 拥有模型，却无法获得所需的算力。

双方恰好互补：华为提供硬件及原生软件栈，DeepSeek 则带来使这些硬件能为其模型所用的工作负载与工程能力。9月30日 DeepSeek 代码库中发布的 Ascend 支持，正是这种合作的产物，而交换的媒介则是内核开发语言。

到2028年，甚至可能在2027年，DeepSeek 很可能会主要使用华为的软件栈，尤其是在构建完全国产化生态系统的外部与内部压力之下。正如我们在本文及后续文章中所展示的，华为生态系统已经相当成熟且发展完善，其深厚的基础源自 Ascend 时代，而 DeepSeek 的工程师们则在此之上进一步构建。

在本文中，我们首先将考察 Ascend 950PR 的架构，并对其计算与内存性能进行基准测试。随后，我们将深入探讨 DeepSeek 的软件发布，从 TileLang 的编译器能力，到针对硬件的内核优化，以及机架级通信。

最后，我们将分析 DeepSeek-V4.1-Flash 的执行概况。

Ascend 950

我们曾在之前的文章中深入研究过 CANN 以及 Ascend 950 的架构。自那以来，更多有趣的细节陆续披露。

从芯片层面来看，950PR/DT 已经出现了多种变体，其核心数量、HBM 堆栈高度及缓存大小各不相同。其中一些很可能是虚拟化的或仅用于测试。

这是因为只有部分晶圆和 HBM 堆栈能够达到目标规格，既有明显的缺陷，也有功耗与性能方面的参数不足，因此华为会将计算与内存分别分级，将较弱的内存与较弱的计算搭配使用，而不像英伟达那样只对计算进行分级。

这并非新鲜事，910B 同样存在 910B1、910B2、910B3、910B4 等多种变体。在接下来的微基准测试中，我们选用了一颗 Ascend 950PR_9579，配备28个立方体核心和128 GiB HBM。

root@cb3bb851f93f:/workspace# npu-smi info
+-------------------------------------------------------------------------------------------------+
| npu-smi 25.7.rc1.6                               Version: 25.7.rc1.6                            |
+--------+------------------+---------------+-----------------------------------------------------+
| NPU ID | Name             | Health        | Power(W)    Temp(C)           Hugepages-Usage(page) |
|        |                  | Bus-Id        | NPU Util(%) Memory-Usage(MB)  HBM-Usage(MB)         |
+========+==================+===============+=====================================================+
| 0      | Ascend950PR      | OK            | 203.3       56                0     / 0             |
|        |                  | 0000:12:00.0  | 0           0    / 0          5242  / 131072        |
+========+==================+===============+=====================================================+
+---------------------------+---------------+-----------------------------------------------------+
| NPU ID                    | Process id    | Process name             | Process memory(MB)       |
+===========================+===============+=====================================================+
| No running processes found in NPU 0                                                             |
+===========================+===============+=====================================================+

指针遍历测试每次启动时读取16 KiB的整数有效载荷，在18个区块内保持在约134纳秒，到56时上升至182纳秒，随后在64时跃升至391纳秒。

这与超过56个向量核心的第二波性能特征相符。

接着，我们在每个Cube核心和向量核心上分别运行一个标量指针遍历探测，并在整个128 MiB链中记录相同地址上的加载时序，得到如下图表。

每个单元格的颜色表示两个核心地址访问模式之间的平均绝对差异，从而形成了与解码后芯片对应的两组。

进一步地，我们通过计时一个向量核心的指针遍历时，让另一个核心同时执行内存流量或仅使用寄存器的工作；额外的性能下降揭示了哪些子系统共享资源，支持诸如{0,2,4}和{1,3,5}这样的分组。

混合的Cube/向量启动则确定了每个子系统所包含的一个Cube核心和两个向量核心，我们将它们在同一分组内绘制出来，但物理位置仍为示意性标注。

NPU中的CPU

每颗950PR都配备数量可变的Linx816 AArch64 ELF AICPU。其MIDR编号表明，这些核心很可能与麒麟9000S/9010中的中间核心相同。这些AICPU核心的指令集为：

fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid
asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve
asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2
frint svei8mm svebf16 i8mm bf16 dgh rng ecv

对于该SKU，配置了7个AICPU核心，其中6个可见，5个正在执行。除了设备控制之外，它还能提供CPU算子支持，例如KV元数据。当D2H开销占据大部分时间时，AICPU能够有效分担短时任务。

在DSA方面，一个小型调度步骤会读取当前的序列长度，并将索引器任务分配给加速器核心。随后，Cube/Vector核心计算INT8索引分数，并选出前2,048个索引。

这些规划、索引选择和gather步骤在vLLM-ascend实现中由AICPU执行，我们将其性能与在主机CPU上运行的结果进行了对比。

由于其计算性能有限，AICPU仅适用于开销占主导的短时任务，以及数据在NPU端产生并被消耗的任务。

微基准测试

Ascend 950PR专为预填充和推荐场景设计，其内存带宽和核心数量均低于其更强大的兄弟型号950DT。

以下结果并非DeepSeek的贡献，而是基于原生torch.matmul在Ascend上的实现，解析为aclnnMatmul_MatMulV3Common_MatMulV3。我们比较了来自多个开源模型的1,055种BF16 GEMM形状。

华为的最佳内核达到了理论峰值的99.7%，这表明DeepSeek通过DeepGEMM实现的99+%利用率并不是提升利用率的唯一途径，华为工程师同样做出了出色的工作。

这种优势主要体现在计算密集型任务中。在下图所示的形状范围内，Ascend的中位实际/可达到利用率是41.5%，而H100为46.8%。部分Nvidia的结果受到功耗限制，未达到最高SM频率：平均功耗约为690–698 W，而上限为700 W；采样得到的SM频率中位数为1335–1470 MHz，低于最高值1830 MHz。

华为的功耗约为599–600 W，频率为1500–1550 MHz，而其参考频率为1650 MHz。

Ascend的MXU设计可能有助于实现较高的利用率。Ascend在专用的L0A/L0B缓冲区中流水线化矩阵操作数，并在L0C中进行累加，从而实现数据搬移、计算和结果处理的重叠。

华为认为，更大的L0C有助于更灵活的分块与复用。

当然，在绝对数值上，950PR仍落后于H100，其性能介于A100和MI300X之间。

内存带宽

在测量HBM内存带宽时，我们发现，在小消息尺寸下，950PR的有效带宽及其带宽利用率均超过H100；而在大消息尺寸下，其带宽利用率几乎与H100持平。

曲线中出现了一个下降拐点，这是因为Ascend切换了复制方法，改用Vector核心的TensorMove内核，该内核有更高的启动开销，因此稍大的复制任务反而耗时更长。

对于超大规模的复制，这一额外开销变得相对较小，带宽又重新回升。

需要注意的是，高FLOPs利用率和高带宽利用率并不必然转化为高MFU/MBU。训练过程，尤其是使用FSDP时，需要进行集体通信、检查点保存以及数据搬运，这些操作往往难以充分重叠。

正如我们在Jalepeno文章中所提到的，基准测试中的“芯片”只是一种社会约定。多个裸片可以通过封装整合成更大的“芯片”。因此，能效或TCO才是更合适的比较指标。

但对于中国而言，电力成本远低于美国，我们将在后续文章中分析Ascend的TCO性能。

硬件设定了上限，而软件则决定了能否真正达到这一上限。尽管华为的硬件可能落后约5年（相对于A100），但其软件却处于行业前沿。

DeepSeek开源项目

在获得Ascend支持的6个仓库中（TileLang、DeepGEMM、DeepEP、TileKernels、FlashMLA、DeepSelect），截至发稿时只有TileLang可以正常使用，且CANN 9.2.0尚未发布。

Deepseek需要CANN 9.2.0，该版本是在发稿后才发布的；同时还需要C++20编译器，而CANN 9.2.0-beta.2并未提供。HDK将于10月15日发布。

这发生在DeepSeek于2025年举办的开源周之后，当时这些仓库的部分内容仅在Nvidia的支持下对外发布。

从上述结果可以看出，华为已经能够很好地执行各类运算；而合作的意义在于使应用程序的其余部分及其配套工作更加高效和可复用。

双向工程协作

华为的架构设计已经开始影响DeepSeek软件的数据组织方式。早期的FlashMLA KV缓存布局将量化值及其缩放因子存储在独立区域。在Ascend平台上，获取一个token时需要分别传输其值和缩放因子。

而新实现则将两者合并存放，从而减少了内存传输引擎（MTE）的传输请求数量。

从高性能内核到可复用的内核工程

Ascend 950后端已合并至TileLang主仓库，不再仅以华为的适配器形式存在。它为Ascend的执行模型增加了原生编译、调度、同步及运行时集成功能。

TileLang 使 Ascend 内核的编写更加简便，但开发者仍需考虑硬件特性。他们需要选择计算方式、分块大小以及数据存储位置。编译器则负责处理 Cube 核心、Vector 核心之间的大部分协调工作，以及数据传输。

深入考察其实现，并对比其与 CANN 和 Triton-ascend 的性能表现，在某些情况下 TileLang 能够与 CANN 持平甚至超越；不过，最佳实现方案会随规模变化而调整。

这是一项在缓存已预热条件下的简单且朴素的基准测试。

AutoSchedule 利用数据依赖关系和预估的执行时间来规划哪些操作可以重叠执行。它还会在可用片上内存范围内决定使用多少缓冲区槽位，以便在当前分块被处理的同时加载后续数据。

当默认调度方案不适用时，开发者也可以对这些决策进行引导。

在 950PR 上，AutoSchedule 对于较小规模的运算尤其有效，可将单个操作的执行时间缩短多达 40%。

编译器还会插入同步机制，使各操作等待所需的数据，并移除因其他依赖关系而变得不必要的等待。它还会检查条件分支，避免在某个分支可能永远不会执行的情况下误判操作已完成。

这样一来，程序员无需自行管理过多的同步逻辑。

DeepEP

华为已加入英伟达的行列，共同推动大规模扩展型 AI 系统的商业化。其 Ascend 超节点通过紧密耦合的加速器互联技术，将多机架间的连接从 910 CloudMatrix384 扩展至 950 SuperPod，从而实现 wideEP 级别的横向扩展。

在 9 月 30 日发布的版本中，华为还在 950DT 超级集群上提供了基于 URMA 的 EP16 分发/归约基准测试。

华为的分发流程由三个顺序算子（预处理/URMA/后处理）组成，而 GB300 则是一次融合调用；此外，华为的后处理还包括接收完成阶段——我们的测量中包含了这一部分，但也包含了专家层面的扩展操作，而 GB300 的结果并未涵盖这部分内容。

DeepEP-Ascend 是 DeepEP V2.5 的移植版本，保留了相同的 Python API，底层调用了 URMA 和 HCCL。2025 年 7 月，华为的 Ascend 团队曾以 deepseek-ai名义提出 DeepEP-Ascend，但 DeepEP 的维护者予以拒绝。

如今，DeepEP-Ascend 已由 DeepSeek 自行发布并维护。

Ascend 的 Cube 和 Vector 两条独立执行路径为通信与计算的重叠提供了机会，但这种重叠并非免费。复杂的计算也可能需要向量处理和数据搬运，而通信则会争夺共享内存带宽。

因此，在不妨碍并行计算的前提下，能够隐藏多少通信开销存在权衡。

这种资源平衡问题并非 DeepSeek 所独有。华为的 Kimi K3 配方 明确限制了向量的使用,以预留并发工作的资源，并根据需要重叠的任务来选择专用 CCU 还是基于 Vector 的通信方式。

单纯提升单个操作的速度并不足够，其资源需求也必须相互匹配。

DeepEP-Ascend 的文档指出了归约处理与 URMA 通信在 HBM 资源上的竞争，并表示华为计划通过固件优化来缓解这一问题。这正是协同设计的实践体现：模型揭示瓶颈，实现加以适配，平台的研发重点则针对剩余问题作出响应。

一切尽在计划之中

在 5 月一份未经核实的 DeepSeek 投资者会议记录中，梁文峰表示：

“关于中美之间在芯片领域的差距，我认为软件生态系统的差距终将消失。但在硬件方面，我们面临两大劣势：需要四张华为加速卡才能抵得上一张英伟达卡，而且华为在硬件上市方面也大约落后两年。”

四个月后，生态系统差距确实有所缩小。同一份记录还提到了 TileLang，以及帮助华为完善其生态系统的努力。

DSv4.1 Flash 优化

DeepSeek 与华为合作的另一项内容是，DeepSeek 向华为提供权重参数，支持 Day-0 优化版本的发布，例如 DeepSeek V4 和 V4.1。

Ascend 的累加器设计决定了注意力机制的不同实现方式。Cube 的 L0C 缓冲区无法就地对累积输出进行缩放，而若将缩放后的结果回写到 L0C，则需要代价高昂的单位矩阵乘法。

DeepSeek 因此将运行中的输出累加器保存在 Vector UB 中，并在需要缩放和累积时从 L0C 传输部分和。Hopper 将累加器保存在寄存器中，而 Blackwell 则支持张量内存与寄存器之间的加载与存储，从而避免了这一特定限制。

性能剖析

华为还发布了 DeepSeek-V4.1-Flash 在一个由 32 片 Ascend 950DT 组成的部署实例上的单个节点性能剖析报告，同时涵盖了其宿主线程的情况。

6 月，我们曾报道过 DeepSeek V4 Pro 的类似剖析报告。

许多组件如 AICPU 的使用以及部分层被分配到不同流等，都呈现出相似之处。

执行顺序为：40层目标模型层、目标LM头、3个DSpark起草块、起草LM头，以及5轮采样。主要计算在Stream 19上进行；起草部分则在Stream 173上运行。

来自DSv4 Pro轨迹的V2 MC²内核——即融合了计算与通信的内核——再次出现，不过这次是V3版本。这也是为什么每步仅出现4次由AI CPU启动的HCCL操作，而专家调度却多达43次。

这些正是目标和起草词汇表头的hcom_allGather和hcom_alltoallv：先收集隐藏状态，再执行LM头的GEMM运算，随后交换logits。

起草块只运行一次，用于生成起草位置的基础logits。随后的马尔可夫头通过采样和嵌入反馈来建模标记之间的依赖关系，不会为每个候选序列重新运行Transformer块。

每一步的末尾也从MoE和注意力机制转变为一系列小型投影与采样操作的串行链。

如前几篇文章所述，推测解码是一种无损方法，用于预测起草标记并以单次遍历对其进行验证，从而摊薄权重加载的开销。在上述解码步骤图中，我们可以看到DSpark起草标记的速度远快于验证步骤。

DSv4.1 Flash也是首个使用Engram的DeepSeek模型，但晚于Qwen和美团Longcat。

由于Engram以标记ID作为输入，因此数据获取可以异步进行，并与第0层的计算重叠。这使得在不损失性能的情况下，可以将数据卸载到DRAM，但如果卸载到PCIe 4.0 SSD，则会降低性能。

更多详情请参阅我们的Engram分析：

在稳态窗口内汇总各内核的持续时间时，Stream 19占用了窗口的88.8%，但由于其他流与其重叠，其对总设备时间的贡献仅为72.6%。在中间时段，显著的MIX_AIV和AI_VECTOR_CORE 区间不仅包含调度与合并操作，还涉及量化过程。

Ascend通过MIX_AIC、MIX_AIV、AI_CORE和AI_VECTOR_CORE分别暴露了独立调度的立方体路径和向量路径。每个事件都有任务类型，因此持续时间统计可以按类型划分。

即使混合类型的任务仍需跨越多个物理单元才能完成，其名称也无法将内核的累计运行时间直接转化为仅针对立方体或仅针对向量的利用率测量值。

在一个一阶场景中，若将立方体吞吐量翻倍而其他设备工作保持不变，每步的性能可提升至1.32倍。该场景假设测量到的流间重叠保持恒定，空闲时间亦不变。

这是一个组合性场景，而非对新硬件的预测：混合任务类型并非排他的利用率度量指标，带宽、依赖关系及调度方式都可能改变最终结果。

同样，量化融合仍是一项潜在优化，其吸引力在于重复出现的生产者—消费者边界，以及它在向量桶中所占的较大份额——该桶同时也承载着融合后的通信操作。

生态系统的缺口

然而，一个问题在于，这种合作关系可能对DeepSeek极为有利，却未必能让Ascend对其他用户同样易用。

对于DeepSeek而言，构建编译器、维护内核以及调试厂商特定行为等工作，虽然只是暂时性的，但也与其模型研究和产品开发形成竞争。

而对于其他用户来说，当硬件配置与DeepSeek的需求不一致时，可能会遇到诸多问题。大多数优化都集中在超节点层面，而且截至vLLM-Ascend_0.26.0rc1，在x86主机上使用Ascend仍存在不少问题：

• x86主机上不支持DeepGEMM
• vLLM-Ascend依赖于包含硬编码ARM头文件的memfabric_hybrid，导致无法正常启动；vLLM-Ascend无法开箱即用。
• vLLM-Ascend对非ARM CPU进行了CPU绑定处理
• 缺乏NPU + x86的CI环境，部分构建流程需要打补丁