DeepSeek released DeepGEMM-Ascend on September 30, 2026, bringing its matrix library to Huawei Ascend 950, according to the project’s release notes. TileLang also announced an official Ascend 950 backend that same day. Together, they offer familiar library interfaces and a higher-level way to write accelerator kernels, though deployment still requires the matching Huawei software environment.
The useful question for developers is how much of an application can stay familiar when its accelerator changes. There are two routes here: call an optimized library, or write a custom kernel through TileLang. Those routes solve different amounts of the migration problem.
DeepGEMM preserves the interface; data preparation still matters
In its library documentation, DeepSeek describes the Ascend package as API-compatible with DeepGEMM, supporting BF16, FP8 and FP4 matrix operations while giving Huawei explicit credit for engineering support.
There is a specific migration detail worth checking: as detailed in the kernel interface note, quantization scaling factors use a different representation from NVIDIA’s implementation. Pairs of UE8M0 factors along K are packed into an int16 and stored in MN-major order.
That distinction gives application teams a concrete review point. A familiar function signature does not establish that previously prepared tensors have the right representation for another backend. Check the conversion boundary before interpreting a numerical mismatch as a kernel failure. Preserve a reference result and compare the same inputs after the required preparation.
TileLang’s new backend is distinct from the older adapter
The main TileLang repository dates official Ascend 950 support to September 30, with native code generation, automatic scheduling and synchronization, and SIMD/SIMT vector programming. In the Ascend 950 backend acknowledgements, the project identifies DeepSeek developers as the primary initial contributors and thanks Huawei for its collaboration.
An earlier, separate TileLang-Ascend adapter became open source on September 29, 2025; its README lists A2 and A3 as tested devices. This week’s announcement adds a specific new backend in the main project. Describing all Ascend support as newly created would lose that distinction.
The new backend reuses TileLang’s frontend while adding Ascend-specific compilation. Under the project’s division of programming responsibilities, developers still choose shapes, types, tile sizes and block counts, while the compiler handles task scheduling, buffer rotation and synchronization. That structure leaves performance-sensitive choices visible while eliminating low-level coordination boilerplate.
Fusion shows the programming benefit
The backend guide’s quick-start GEMM-plus-ReLU example illustrates this division by dispatching matrix multiplication to Cube cores and activation to Vector cores. Direct transfers move result tiles between those stages, allowing the epilogue to execute within the same kernel. The example uses BF16 inputs and FP32 accumulation and output, requiring dimensions divisible by its tile sizes.
For a team evaluating custom operators, this is a useful starting point: verify the published example, then replace its dimensions and epilogue with the actual workload. Include edge shapes in the next stage of testing. A demonstration that explicitly excludes partial tiles cannot establish correctness for arbitrary dimensions.
TileLang specifically powers DeepGEMM-Ascend’s mHC prenorm kernel, though DeepGEMM’s project acknowledgements clarify that this is not a library-wide implementation.
The 99.8% result has a defined scope
In its published performance benchmarks, DeepSeek reports 431 TFLOPS against a stated 432-TFLOPS limit for a BF16 dense GEMM with M = 4096, N = 7168 and K = 16384. That 99.8% figure was measured under specific conditions—an Ascend 950DT, CANN 9.20, bench_msprof, and cold L2 cache—describing that isolated kernel case.
Whole-model improvements depend on where time was spent before the change. Consider a hypothetical workload in which GEMM accounts for 60% of execution time. Even doubling that part would reduce total time to 0.60 ÷ 2 + 0.40 = 0.70 of the original, or about a 1.43× overall speedup. This is an illustrative calculation, not a measured DeepGEMM result.
The same reasoning applies to fusion: fewer launches may help, but the benefit depends on launch overhead, data movement and the amount of work fused. Measure those components before using a kernel headline to forecast serving capacity.
Start with the exact environment and a reference output
DeepGEMM’s documented setup requirements mandate Ascend 950, CANN 9.20, torch_npu, Python 3.10 or later, and C++20 support. TileLang’s Ascend installation guide additionally requires compatible driver and runtime tooling, though it permits compiling with CUDA disabled.
Evaluate one representative operator first. Record software versions, matrix dimensions, precision, numerical tolerance and input preparation. Separate compilation time from repeated execution. Then run the complete application with identical batching and quality requirements; report both throughput and latency.
For mixture-of-experts workloads, communication is another substantial variable. Klaus Fischer’s EyesTech coverage of DeepEP-Ascend explains the accompanying dispatch libraries and the reproducibility constraints documented for their benchmark setup.
DeepGEMM-Ascend is released under the MIT license. Teams can inspect and adapt the implementation subject to its notice requirements. The immediate engineering opportunity is to measure whether familiar interfaces and compiler-managed coordination reduce porting work on a real Ascend deployment. A reproducible application-level result would establish how much that opportunity translates into usable capacity.
