DeepSeek and Huawei open-source Ascend tooling to cut NVIDIA software reliance

In early October 2026, DeepSeek and Huawei jointly open-sourced a set of software tools for the Ascend ecosystem. According to Tom's Hardware — drawing on a September 30 Reuters report — the release includes libraries for AI computation and chip-to-chip communication, plus Ascend support for the high-level programming language TileLang. The goal is explicit: reduce reliance on Nvidia's software ecosystem, the CUDA stack, and cut the porting cost for developers training and deploying large models on domestic compute.

Two jobs: saturate one chip, connect many

To see what these tools fix, start with the two hard requirements of running large models across many accelerators: getting computation efficiency up on each chip, and moving data between chips fast enough that processors never sit idle. The second is routinely underestimated — large-model training and inference are, at many stages, communication-bound rather than compute-bound, and no number of chips helps if the data cannot get there. The companies say this is exactly where they optimized together.

The work landed on a supernode system: per the same report, the two companies optimized computation and communication on a supernode built around 128 Ascend 950 chips. The supernode idea is to treat many accelerators as one logical unit over high-speed interconnect, cutting hops and shortening data paths; the software's job is to let higher-level code stop caring which card the data actually lives on.

Mixture-of-experts models sharpen the communication problem. Both training and inference route each token to different "experts" and then combine the results, a back-and-forth pattern the industry calls all-to-all. It is communication-intensive by nature: experts sit on different chips, so data has to travel. That is precisely why DeepSeek open-sourced a communication library alongside its compute library rather than shipping a single kernel collection.

What was released: two libraries and a language

On the compute side there is DeepGEMM-Ascend, which handles matrix multiplication and other calculations used in DeepSeek's models. It supports BF16, FP8 and FP4 formats and reuses the same programming interfaces as the existing DeepGEMM library — which matters a great deal for migration, because developers moving workloads to Ascend do not have to learn a new API. Matrix multiplication is the core operator in deep learning, where nearly every linear layer ends up, so a library's efficiency largely sets a model's throughput ceiling. A word on the three formats. BF16, FP8 and FP4 describe how many bits represent the numbers being computed: fewer bits mean more operations in the same time and less data to move, but a higher risk of numerical error. Much of the inference-side speedup in recent years has come from migrating to lower precision, at the cost of engineering around that loss of accuracy — so a kernel library offering all three lets developers weigh speed against accuracy according to how much a given task matters.

On the communication side there is DeepEP-Ascend, which handles communication for training and inference, including routing data to the different experts in a mixture-of-experts model and combining their outputs. Both libraries, the company says, were developed and tested on Ascend 950 hardware — which says more about maturity than a feature list does, because communication library performance depends heavily on the specific interconnect topology and hardware characteristics, and an implementation written away from real silicon rarely performs.

The third piece is TileLang, which offers a higher-level programming layer for writing optimized kernels. DeepSeek describes it as providing "a simpler programming model" than Nvidia's CUDA, aimed at improving development efficiency and simplifying code. The language already supported Nvidia and other hardware, with earlier adapters available for Ascend processors; the September 30 update adds native support for Ascend 950, including code generation, automatic scheduling and synchronization.

One easily confused point: these tools build on Huawei's existing CANN software platform, which provides the underlying infrastructure for running AI workloads on Ascend and plays a role similar to Nvidia's CUDA. CUDA is hard to displace not because of the compiler alone but because years of mature tooling, libraries and developer habits add up to a whole ecosystem — and the value of a multi-platform language like TileLang is precisely that its support for several platforms keeps it useful for Nvidia GPUs too, rather than locking anyone to one vendor.

Seen against the wider cadence

One detail on timing: the tooling surfaced two weeks after Huawei unveiled its next generation of AI processors and supernode systems. Huawei said then that it expected its AI systems to be widely used for model training in 2027. Put the two together and the hardware roadmap and the software toolchain are advancing as a pair — when the chips change generation, the programming layer and kernel libraries have to follow, or the new hardware's capability never reaches developers.

The partnership did not start here either. DeepSeek's V4 model already shipped with support for Huawei's Ascend chips when it appeared in preview form in April; per the report, Huawei said its Ascend 950 supernodes fully supported the V4 models and that its chips were used for part of the lighter V4-Flash model's training. With this open-source release, the collaboration shifts position from "getting the model to run" to "making it pleasant for developers to write against".

One more thing worth noting is that this is a separate matter from what DeepSeek is doing on its own model line, though the direction matches: when V4.1-Flash launched, the company also said it would work with the open-source community on inference support for it. One opens up a deployment path on the model side, the other lowers the programming and communication barrier on the hardware side — both are filling in a toolchain.

Why it is called filling in the software stack

Against the backdrop of hardware constraints, this step is unavoidable. A working chip is only the first door; day-to-day developer experience depends on whether the compiler, kernel libraries, communication libraries and programming language are pleasant to use. If writing is awkward, tuning is guesswork and moving hardware means rewriting, even excellent peak performance gets abandoned. Conversely, an ecosystem can only grow once migration means swapping a set of interfaces while the code structure stays put.

There is also the role open source itself plays. Building a hardware ecosystem is rarely something a vendor can finish alone: kernel libraries have to cover the many shapes and precisions real workloads use, communication libraries have to fit various interconnect topologies, and compilers have to cope with however developers actually write their code. Putting that in an open-source community lets third parties audit, benchmark and contribute ports, saving the vendor duplicate work — and by the same token lets users judge for themselves whether a stack is production-ready instead of relying on the vendor's own numbers.

So the significance of this release is not the performance level it reaches immediately but the position it fills. A compute library, a communication library and a programming language are exactly the shortest path for putting hardware capability into developers' hands; open-sourcing those three lowers the entry fee on that path. What is worth watching next is how mature these libraries prove in real engineering, how quickly the community adapts them, and what share Ascend actually takes in 2027 training scenarios — questions that only time will answer, not a single announcement.