The Huawei-DeepSeek Symbiosis

What it adds beyond the summary

The summary names the benchmarks and the six repos but omits the one fact that decides whether an engineer can touch this today: as of writing, only TileLang is actually usable. The other five repos (DeepGEMM, DeepEP, TileKernels, FlashMLA, DeepSelect) need CANN 9.2.0, which was not released at publication, and a C++20 compiler that CANN 9.2.0-beta.2 does not provide. The HDK was slated for October 15. So the September 30 2026 release is largely a declaration of intent, not a working stack.

Evidence

Compute, from stock torch.matmul resolving to aclnnMatmul_MatMulV3Common_MatMulV3 across 1,055 BF16 GEMM shapes from open models:

• Huawei's best kernels reach 99.7% of the roofline ceiling, so DeepGEMM's 99+% is not the only path to high utilization.
• On compute-bound shapes below the ridge, the 950PR's median achieved/attainable fraction is 41.5% versus H100's 46.8%. The comparison is not clean: the H100 was power-limited at a median ~690-698 W of its 700 W cap and clocked at 1335-1470 MHz against a 1830 MHz max, while the 950PR ran ~599-600 W at 1500-1550 MHz against a 1650 MHz reference.
• In absolute terms the 950PR sits between A100 and MI300X. SemiAnalysis frames Huawei's hardware as roughly five years behind the A100, with the software at the frontier.

Memory: the 950PR's effective HBM bandwidth and utilization beat H100 at small per-buffer message sizes and nearly match it at large sizes, with a dip where Ascend switches to a Vector-core TensorMove kernel that has higher startup cost.

The specific 950PR tested is an Ascend950PR_9579 with 28 cube cores and 128 GiB HBM, carrying 7 configured AICPU cores (6 visible, 5 executing). Huawei bins both compute and memory into SKUs, pairing weaker memory with weaker compute, unlike Nvidia which bins compute only.

Profile of one rank of DeepSeek-V4.1-Flash on a 32-chip 950DT SuperPod: Stream 19 is occupied 88.8% of the steady-state window but contributes 72.6% of summed device time because other streams overlap it. A first-order scenario doubling cube throughput, holding overlap and idle constant, gives a 1.32× step improvement. The authors flag this as a composition estimate, not a silicon prediction.

Co-design details the summary skips

• FlashMLA's KV-cache layout was changed to store quantized values and their scaling factors together rather than in separate regions, cutting the number of MTE transfer requests on Ascend.
• The Ascend L0C accumulator cannot rescale in place, so DeepSeek keeps the running attention output in Vector UB and pulls partial sums from L0C for rescaling. Hopper holds the accumulator in registers; Blackwell loads and stores between tensor memory and registers.
• TileLang's Ascend 950 backend is merged into the main repo, not a separate adapter. Its AutoSchedule cuts single-operation execution time by up to 40% on the 950PR for smaller sizes.
• DeepEP-Ascend is a port of DeepEP V2.5 with the same Python API over URMA and HCCL. Huawei's Ascend team proposed it under deepseek-ai in July 2025, a DeepEP maintainer declined, and it now ships under DeepSeek's own organization. Its docs name HBM contention between combine processing and URMA communication, with Huawei firmware fixes planned.

Limits

This is a SemiAnalysis newsletter analysis with vendor-released profiles, not a reproducible benchmark suite. The authors state the GEMM test is warm-cache, simple and naive, that mixed task-type names (MIX_AIC, MIX_AIV) are not exclusive utilization measurements, and that the May 2026 Liang Wenfeng transcript it quotes (four Huawei cards to match one Nvidia card, Huawei ~two years behind on hardware) is unverified. Most optimizations target supernodes. On x86 hosts, vLLM-Ascend_0.26.0rc1 has no DeepGEMM support, a hardcoded-ARM-header dependency in memfabric_hybrid that blocks startup, skipped CPU-binding for non-ARM CPUs, and no NPU+x86 CI.