DeepSeek Open-Sources Six Core Ascend Components: A One-to-One Match with Its NVIDIA Stack

DeepSeek Ships Its Entire Ascend Foundation Layer

DeepSeek^Ad's official WeChat account announced the open-sourcing of a complete suite of low-level components targeting Huawei's Ascend platform — six repositories in total, each with a direct counterpart in its previously released NVIDIA stack. As reported by IT之家, the list includes TileLang, DeepGEMM Ascend, DeepEP Ascend, TileKernels, FlashMLA, and DeepSelect, all hosted on GitHub under the permissive MIT license.

What makes this significant isn't the number of new repos — it's that the same lab has ported the exact same battle-tested low-level building blocks onto Ascend hardware. One key detail from the report: Huawei's team provided "wholehearted and full support," with both sides collaborating on a 128-GPU supernode solution based on the Ascend 950.

Six Components, Each with a Specific Job Across the Training Stack

These six repositories aren't padding — each one maps to a real workload encountered during model training. The centerpiece is TileLang. According to DeepSeek, it's simpler to program than CUDA, significantly improving developer productivity and simplifying code logic. It's already mature on the NVIDIA side, currently powering most operator implementations in DeepSeek V4-series model training.

The Ascend version wraps Ascend's AscendC low-level instructions behind a high-level programming interface without sacrificing hardware performance. In plain terms: instead of fighting the hardware to write a high-performance kernel, you write shorter high-level code and let the compiler handle the hardware-level execution.

The other five components each handle a specific concern: DeepGEMM accelerates general matrix multiplication, DeepEP handles large-scale cross-device communication, TileKernels provides standard vector compute and memory access operators, FlashMLA delivers sparse attention operators for long-context efficiency, and DeepSelect handles efficient data selection. TileLang ties them all together — fast compute, fast communication, writable operators. A complete training stack needs all three, and they're all here.

---

MoE (Mixture of Experts) architecture is the key context for understanding why these components exist. DeepSeek's flagship models use sparse MoE: only a small fraction of experts are activated per forward pass, enabling massive parameter scaling without proportional compute growth. This creates two engineering challenges: tokens must be routed across devices (handled by DeepEP's Dispatch/Combine), and attention must handle sparse patterns over very long contexts (handled by FlashMLA). The matrix multiplications accelerated by DeepGEMM — GEMM, or General Matrix Multiply — are the most compute-intensive operations in every Transformer forward and backward pass. The six components together cover the "operator compute → attention → communication → data selection" pipeline end-to-end. Remove any one piece and you have a bottleneck.

---

Compatibility Is the Real Story

The README for DeepGEMM Ascend opens with a first release date of 2026.09.30, targeting Ascend 950 devices with operators aimed at near-peak hardware performance. The genuinely noteworthy part is compatibility: it's fully API-compatible with the original DeepGEMM, supports BF16, FP8, and FP4 matrix multiplication as well as attention-related operators, and uses the same package name as the original. Install this package and your existing workflow requires zero code changes — you're running the same API against Ascend hardware.

DeepSelect, which provides the TopK operator used by sparse attention and samplers, also has an Ascend release. The official claim is 2–20× faster than native PyTorch TopK. The commit message is unambiguous: "TopK Kernels for Huawei Ascend NPU, 2026.09.30 release."

---

BF16, FP8, and FP4 are floating-point formats with decreasing precision and increasing throughput. BF16 (Brain Float 16) is the current standard for large model training, balancing accuracy and speed. FP8 has become common with newer chips like the H100/H200 and Ascend 910C, offering roughly 2× the throughput of BF16. FP4 is a more aggressive quantization format used mainly for inference acceleration. DeepGEMM Ascend supporting all three means it covers standard mixed-precision training, low-precision inference, and aggressive quantization training alike. The KV Cache format change (one of FlashMLA's breaking changes) exists precisely because FP8/FP4 storage layouts differ from BF16 — leaving the old format in place would cause computation errors when reading the cache during decoding, making a backward-incompatible upgrade necessary.

---

Performance Numbers: Watch the Units Before Drawing Conclusions

In the FlashMLA repository, the Ascend 950 achieves 410 TFLOPS on sparse attention prefill — 95% of the hardware's theoretical peak — and 360 TFLOPS on decode, or 83%. These numbers come from DeepSeek itself; no third-party benchmarks exist yet. They are reported here as stated.

The comparison framing deserves extra scrutiny. DeepSeek also cites a number for the NVIDIA B200 — 1350 TFLOPS for sparse prefill. Don't rush to divide. The B200 figure is an absolute throughput number; the Ascend 95% is a utilization rate relative to that chip's own peak. The two metrics are not on the same scale. Dividing them directly tells you nothing useful.

Cross-device communication is handled by DeepEP Ascend for MoE Dispatch and Combine — routing tokens to the right expert on the right device and collecting the results. It uses Ascend's communication library and runtime, compiled via TileLang. The Performance section of that repository is refreshingly honest: Dispatch on Ascend 950 can reach 90–95% of the physical payload bandwidth ceiling, but only when EP scale stays at or below 32. Larger EP scales and Combine are still being optimized — Combine carries local reduction overhead and HBM contention. That candor in the README is more credible than a page of clean numbers.

This also maps directly to the 128-GPU supernode goal — the communication layer needs to work at that scale, which corresponds to the EP128 row in the performance table.

---

TFLOPS (trillions of floating-point operations per second) is the standard unit for AI chip throughput, but theoretical peak and achievable throughput typically diverge significantly due to memory bandwidth limits, pipeline stalls, and communication latency. Hitting 95% of theoretical peak on prefill at the operator level is genuinely high utilization, suggesting TileLang's AscendC abstraction is efficient. That said: prefill is compute-bound and relatively straightforward to maximize. Decode is memory-bandwidth-bound, and behind that 83% figure the actual bottleneck may have already shifted from compute to HBM bandwidth. The two numbers aren't directly comparable — it's not accurate to read decode as simply "worse than prefill."

---

A Few Things Worth Keeping in Perspective

First, an official warning: this FlashMLA release includes breaking changes. Support for the Hopper architecture and earlier models (including V3, V3.2, and V4.0) has been dropped, and the FP8 and FP4 KV Cache formats have changed. The new version is not backward-compatible. The Breaking Change Notice in the README exists for a reason — don't just overwrite your existing installation.

Second, what's been open-sourced is operators and libraries — not models. Seeing "DeepSeek on Ascend" and concluding that Ascend can now run the full DeepSeek model family conflates two separate things. What you have are hardware-optimized building blocks, not a directly callable DeepSeek service.

Third, the components need a matching environment. DeepGEMM Ascend's requirements include Ascend 950-series hardware, the CANN 9.20 toolkit, torch_npu, Python 3.10+, and C++20 format support. The barrier is real. For most developers, this is something to watch rather than immediately adopt.

How to Read This

Judging the broader implications for the chip industry is hard to do cleanly right now, but three things can be stated with confidence: DeepSeek is treating Ascend as a first-class supported platform, not an afterthought port. All performance claims currently come from DeepSeek itself, with no third-party validation. And DeepEP's Combine operation and larger EP scales are, by DeepSeek's own admission, not yet fully optimized.

The bottom line: teams working on AI infrastructure who have Ascend hardware should pay close attention and wait for third-party benchmarks before drawing firm conclusions. For everyone else, knowing this happened is enough — there's no reason to rush out and swap your hardware.