DeepSeek Opens Six Ascend Kernel Repos, Co-Designs With Huawei

DeepSeek dropped Ascend-ready builds of six kernel repositories on September 30, 2026, the day before China's national holidays, and SemiAnalysis has now published a detailed teardown of what the two sides are actually doing together.

The repos are TileLang, DeepGEMM, DeepEP, TileKernels, FlashMLA and DeepSelect. Only TileLang was usable at the article's writing; the others depend on CANN 9.2.0 and C++20 compiler support. On the tested Ascend 950PR, SemiAnalysis reports Huawei's own kernels hit 99.7% of the GEMM ceiling, "showing DeepSeek's 99+% from DeepGEMM isn't the only way to maximize utilization." In absolute performance the chip lands between A100 and MI300X, with memory-bandwidth utilization that rivals H100 at large message sizes.

The co-design examples carry the technical story. "Earlier FlashMLA KV-cache layouts stored quantized values and their scaling factors in separate regions," which on Ascend forced separate fetches for a token's values and scales; the new layout places them together to cut requests to the memory-transfer engine. For the Cube L0C accumulator, which cannot rescale in place like Hopper or Blackwell, "DeepSeek instead keeps the running output accumulator in Vector UB, transferring partial sums from L0C when needed for rescaling and accumulation." TileLang's AutoSchedule plans overlap and buffer allocation from data dependencies and reduces execution time by up to 40% for smaller operations.

The report frames the broader bargain plainly: "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." And it ventures a timeline: "In 2028 or even 2027, DeepSeek will likely be primarily using Huawei's stack."

The current optimizations are tied to Huawei supernodes. In vLLM-Ascend 0.26.0rc1 there is no DeepGEMM support on x86 hosts, a dependency on memfabric_hybrid containing hardcoded ARM headers, and no NPU + x86 CI. That bounds who else can run this stack today.