华为昇腾950PR架构解析与DeepSeek生态协同
The Huawei-DeepSeek Symbiosis
国内AI从业者必读，不仅拆解了昇腾950PR的真实微架构与性能边界，更揭示了DeepSeek适配国产算力的工程细节，对理解本土算力替代路径极具参考价值。
Right before China’s national day holidays, DeepSeek released Ascend support for TileLang, DeepGEMM, DeepEP, TileKernels, FlashMLA, and DeepSelect.
在中国国庆假期前夕，DeepSeek 发布了针对 TileLang、DeepGEMM、DeepEP、TileKernels、FlashMLA 和 DeepSelect 的 Ascend 支持。
Neither can do this alone. Although they have Pangu, Huawei has no frontier lab to prove their chip can train or infer models, DeepSeek has models but cannot buy the compute it needs. Each supplies exactly what the other lacks: Huawei provides the hardware and native software stack; DeepSeek brings the workloads and engineering needed to make that hardware useful for its models. September 30’s release of Ascend support in DeepSeek repositories is an artifact of this trade, where the exchange runs through the kernel-authoring language.
任何一方都无法单独完成此事。尽管华为拥有盘古大模型，但其缺乏前沿实验室来证明其芯片能够训练或推理模型；DeepSeek 拥有模型，但无法购买所需的算力。双方恰好互补：华为提供硬件和原生软件栈；DeepSeek 带来使其硬件对其模型产生实际价值所需的工作负载和工程能力。9 月 30 日 DeepSeek 仓库中发布的 Ascend 支持正是这种交换的产物，而该交换通过内核编写语言进行。
Source: SemiAnalysis - Note that the diagram is a simulation.
来源：SemiAnalysis - 请注意，该图表为模拟图。
In 2028 or even 2027, DeepSeek will likely be primarily using Huawei’s stack, especially with the external and internal pressure to build a fully domestic chinese ecosystem. As we show here and in future articles, the Huawei ecosystem is already mature and well developed, with strong foundations from the Ascend time and DeepSeek engineers building further ontop.
到 2028 年甚至 2027 年，DeepSeek 很可能将主要使用华为的堆栈，尤其是在构建完全本土化中国生态系统的外部与内部压力下。正如我们在本文及后续文章中所示，华为生态系统已经成熟且发展良好，拥有来自 Ascend 时代的坚实基础，以及 DeepSeek 工程师在此基础上进行的进一步构建。
In this article, we’ll first examine Ascend 950PR’s architecture and benchmark its compute and memory performance. We then explore DeepSeek’s software releases, from TileLang’s compiler capabilities to hardware-specific kernel optimizations and rack-scale communication. Finally, we analyze DeepSeek-V4.1-Flash’s execution profile.
在本文中，我们将首先考察 Ascend 950PR 的架构，并对其计算和内存性能进行基准测试。随后，我们将探讨 DeepSeek 的软件发布内容，从 TileLang 的编译器功能到特定硬件的内核优化以及机架级通信。最后，我们将分析 DeepSeek-V4.1-Flash 的执行概况。
Ascend 950
We deep-dived into CANN and the Ascend 950 architecture in our DeepSeek V4 Pro article. Since then, more interesting details have been revealed.
我们在 DeepSeek V4 Pro 一文中深入探讨了 CANN 和 Ascend 950 架构。此后，更多有趣的细节得以披露。
Source: SemiAnalysis
来源：SemiAnalysis
Starting from the chip, many variants of 950PR/DT have appeared with varying core counts, HBM stack height, and cache sizes. Some are likely either virtualised/simulated, or for testing only. This is because only a fraction of dies and HBM stacks meet the target spec, due to both outright defects and parametric shortfalls in power and performance, so Huawei bins both compute and memory into multiple SKUs and pairs weaker memory with weaker compute, rather than binning only compute as Nvidia does.
从芯片层面来看，出现了许多不同核心数量、HBM 堆叠高度和缓存大小的 950PR/DT 变体。其中一些可能是虚拟化的/模拟的，或者仅用于测试。这是因为由于 outright defects（ outright 缺陷）以及在功耗和性能方面的参数性不足，只有一部分晶圆和 HBM 堆叠符合目标规格，因此华为将计算和内存分别归类为多个 SKU，并将较弱的内存与较弱的计算配对，而不是像英伟达那样仅对计算部分进行分类。
Source: SemiAnalysis
来源：SemiAnalysis
This isn’t new, 910B also has variants such as 910B1, 910B2, 910B3, 910B4. For the following microbenchmarks, we use an Ascend 950PR_9579, with 28 cube cores and 128 GiB HBM.
这并非新鲜事，910B 也有诸如 910B1、910B2、910B3、910B4 等变体。对于以下的微基准测试，我们使用的是 Ascend 950PR_9579，具有 28 个 Cube 核心和 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 |
+===========================+===============+=====================================================+Running point chases reading 16 KiB of integer payload per launch, it stays near 134ns through 18 blocks, rises to 182ns at 56, then jumps to 391ns at 64. This is consistent with a second wave beyond 56 Vector cores.
在运行点查读取每次启动16 KiB整数负载时，性能在前18个块中保持在约134ns，在56个块时上升至182ns，随后在64个块时跃升至391ns。这与56个Vector核心之后出现第二波次的情况一致。
Source: SemiAnalysis
来源：SemiAnalysis
Then by running a scalar pointer-chase probe separately on every Cube and Vector core, recording load timings at matching addresses throughout a 128 MiB chain, we get the following graph. Each cell’s color represents the mean absolute difference between two cores' address profiles, producing two groups that match the decoded dies.
随后，通过在每个Cube和Vector核心上单独运行标量指针查探探针，并在128 MiB链的匹配地址处记录加载时序，我们得到了以下图表。每个单元格的颜色代表两个核心地址配置文件之间的平均绝对差值，从而产生两组与解码后的裸片相匹配的结果。
Source: SemiAnalysis
来源：SemiAnalysis
Going further, by timing a Vector core’s pointer chase while another core runs either memory traffic or register-only work; the extra slowdown reveals which subsystems share resources, supporting groups such as {0,2,4} and {1,3,5}. Mixed Cube/Vector launches identify each subsystem’s one Cube and two Vectors, which we draw together within those groups, with physical positions remaining schematic.
进一步地，通过测量一个Vector核心的指针查探时间，同时让另一个核心运行内存流量或仅寄存器工作；额外的延迟揭示了哪些子系统共享资源，支持了如{0,2,4}和{1,3,5}这样的分组。混合Cube/Vector启动识别出每个子系统的1个Cube和2个Vector，我们将它们绘制在这些组内，物理位置仍为示意图。
Source: SemiAnalysis
来源：SemiAnalysis
CPU within the NPU
NPU内的CPU
Each 950PR comes with a variable number of Linx816 AArch64 ELF AICPUs. The MIDR numbers imply these cores are likely the same as the middle cores in the Kirin 9000S/9010. These AICPU cores have instruction set:
每个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 ecvFor this SKU, there are 7 configured, 6 visible, and 5 executing AICPU cores. Other than device control it can provide CPU-operator support, such as KV metadata. The AICPU helps out for short work where D2H overhead take up most of the time.
对于此SKU，配置了7个，可见6个，执行5个AICPU核心。除了设备控制外，它还能提供CPU算子支持，例如KV元数据。AICPU有助于处理那些D2H（Device-to-Host）开销占据大部分时间的短任务。
For DSA, a small scheduling step reads the current sequence lengths and assigns indexer work to accelerator cores. Cube/Vector cores then compute INT8 indexer scores and select the top 2,048 indices. These planning, index selection, and gather steps are ran on AICPUs in vLLM-ascend implementation, and we compare their performance to running on the host CPU.
对于DSA，一个小规模的调度步骤读取当前的序列长度，并将索引器工作分配给加速器核心。Cube/Vector核心随后计算INT8索引器得分并选出前2,048个索引。这些规划、索引选择和收集步骤在vLLM-ascend实现中由AICPU运行，我们将它们的性能与在主CPU上运行的情况进行比较。
Source: SemiAnalysis
来源：SemiAnalysis
Due to their limited compute performance, AICPU is only good for short work where overhead dominates, and work where data starts and is consumed at the NPU.
由于其计算性能有限，AICPU仅适用于开销占主导地位的短任务，以及数据在NPU内部开始并被消耗的任务。
Microbenchmarks
微基准测试
Ascend 950PR is designed for prefill and recommendation. It gets lower memory bandwidth and core than its bigger brother the 950DT.
Ascend 950PR专为预填充和推荐设计。其内存带宽和核心数低于其大哥950DT。
The results below are not from DeepSeek’s contributions but from stock torch.matmul on ascend resolving to aclnnMatmul_MatMulV3Common_MatMulV3. We compared 1,055 BF16 GEMM shapes from several open-sourced models. Huawei’s best kernels hits 99.7% of the ceiling, showing DeepSeek’s 99+% from DeepGEMM isn’t the only way to maximize utilization. Huawei engineers did good work too.
以下结果并非来自 DeepSeek 的贡献，而是源于 Ascend 上 stock torch.matmul 解析为 aclnnMatmul_MatMulV3Common_MatMulV3。我们对比了来自多个开源模型的 1,055 种 BF16 GEMM 形状。华为的最佳内核达到了理论上限的 99.7%，表明 DeepSeek 通过 DeepGEMM 实现的 99%+ 利用率最大化并非唯一途径。华为工程师也做得很好。
Source: SemiAnalysis
来源：SemiAnalysis
The advantage is concentrated in compute-bound work. On the shapes below Ascend’s ridge, its median achieved/attainable fraction is 41.5% versus H100’s 46.8%. Some of Nvidia’s results were power-limited and did not hit maximum SM clock: median power around 690-698 W out of a 700 W limit, and median sampled SM clocks at 1335-1470 MHz, below the max of 1830 MHz. Huawei approximated 599-600 W, at 1500-1550 MHz against its 1650 MHz reference.
优势集中在计算密集型工作中。在 Ascend 脊线以下的形状中，其已实现/可达比例的中位数为 41.5%，而 H100 为 46.8%。部分 Nvidia 的结果受功耗限制，未达到最大 SM 时钟频率：在 700 W 的限制下，中位功耗约为 690-698 W，采样的 SM 时钟频率中位数为 1335-1470 MHz，低于 1830 MHz 的最大值。华为近似达到 599-600 W，时钟频率为 1500-1550 MHz，而其参考值为 1650 MHz。
Ascend’s MXU design may contribute to some of this high utilization, Ascend stages matrix operands in dedicated L0A/L0B buffers and accumulators in L0C, with overlapping movement, computation and result handling. Huawei associates the enlarged L0C with more flexible tiling and reuse.
Ascend 的 MXU 设计可能促成了部分高利用率。Ascend 将矩阵操作数暂存于专用的 L0A/L0B 缓冲区，累加器位于 L0C，并实现了数据传输、计算和结果处理的并行重叠。华为将扩大的 L0C 与更灵活的分块（tiling）和复用联系起来。
But of course, 950PR’s falls behind on absolute values, sitting somewhere between A100 and MI300X.
但当然，950PR 在绝对数值上落后，处于 A100 和 MI300X 之间。
Source: SemiAnalysis
来源：SemiAnalysis
MemBW
内存带宽 (MemBW)
Measuring HBM memory bandwidth, we see 950PR’s effective bandwidth and bandwidth utilization surpassing H100 at small message size per buffers, and nearly matching H100 in bandwidth utilization at large message sizes.
在测量 HBM 内存带宽时，我们看到在小消息尺寸（每缓冲区）下，950PR 的有效带宽和带宽利用率超过了 H100，而在大消息尺寸下，其带宽利用率几乎与 H100 持平。
Source: SemiAnalysis
来源：SemiAnalysis
A dip appears in the curve as Ascend switches copy methods to a Vector-core TensorMove kernel that has more startup cost, so a slightly larger copy suddenly takes longer. For very large copies, that extra cost becomes relatively small, so bandwidth rises again.
当 Ascend 切换复制方法到具有更高启动成本的 Vector-core TensorMove 内核时，曲线上出现了一个低谷，因此稍大一点的复制突然需要更长时间。对于非常大的复制操作，该额外成本变得相对较小，因此带宽再次上升。
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力