Beyond CUDA: Can DeepSeek and Huawei Build an Open AI Compute Stack?
DeepSeek and Huawei are trying to move AI-chip competition up the stack—from accelerator hardware to the programming tools, kernels and communications software that determine whether developers can use that hardware efficiently. The initiative is strategically important, but open code is only the first step toward a credible alternative ecosystem.
The software layer has become the strategic battleground
On September 30, DeepSeek said it had worked with Huawei to develop programming infrastructure optimized for Huawei Ascend processors. The announced package includes TileLang, compute kernels and communication libraries, as well as joint optimization of a 128-chip Ascend 950 “supernode” configuration. DeepSeek described the objective as a higher-level programming model that is easier to use while still exposing enough control to reach hardware performance. The announcement was reported by Reuters from DeepSeek’s official WeChat account [1].
The significance is larger than one collaboration. Modern AI accelerators compete as systems, not as isolated chips. A usable platform must connect model frameworks, kernel languages, compilers, runtime libraries, collective communication, debugging tools and cluster interconnects. NVIDIA’s CUDA documentation makes the same systems point from the incumbent side: the platform spans a programming model, language extensions, APIs, libraries and development tools rather than merely a device instruction set [2].
This systems view is consistent with MEMSWork’s earlier analyses of the memory bottleneck behind the AI boom and why advanced packaging may matter more than the next semiconductor node, where usable compute depends on the full platform rather than a single die.
That helps explain why nominally capable accelerators can struggle to win workloads. Porting a model is not the same as reproducing the mature kernel coverage, observability, failure handling and performance tuning that production users expect. DeepSeek and Huawei are addressing precisely that gap.
What is actually becoming open
The new stack has several distinct layers. TileLang is a Python-oriented domain-specific language for high-performance kernels. Its main project documents support work across several accelerator backends, while the Ascend-specific project compiles through two technical routes: Ascend C with Huawei’s PTO layer, and Ascend NPU IR [3][4]. The Ascend repository records a sequence of concrete 2026 additions, including DeepSeek V4 kernels on April 24, Flash Attention and Sparse Flash Attention material on March 28, a PTO code-generation target on January 23, and a PyTorch integration example on January 21 [4].
Huawei is opening adjacent layers as well. At HUAWEI CONNECT 2026, the company said the CANN platform had moved to sustained community-driven open-source development. It also described an upgraded Ascend C environment with combined SIMD and SIMT programming and a PTO virtual instruction set containing more than 120 instructions across eight categories [5]. These numbers are company-reported and should be treated as ecosystem indicators, not independent measures of developer satisfaction.
Figure 1. Open AI accelerator software stack. Original synthesis showing the interfaces from model frameworks to clustered accelerator hardware. Sources: TileLang, TileLang Ascend, Huawei CANN/PTO and SuperPoD materials [3]-[6].
The strongest evidence—and its limits
There is already evidence that the broader Ascend stack can run demanding language-model workloads. A 2025 paper on CloudMatrix384 describes a production-oriented system using 384 Ascend 910C NPUs and 192 Kunpeng CPUs connected by UnifiedBus. For DeepSeek-R1 inference, the authors report prefill throughput of 6,688 tokens per second per NPU and decode throughput of 1,943 tokens per second per NPU at less than 50 milliseconds time per output token [7].
These results matter because they combine compute, memory movement, expert parallelism, cache handling and serving software. They are also not a neutral head-to-head benchmark against the newest NVIDIA or AMD systems. Hardware generations, model settings, precision, batch size, latency target and software maturity can materially change comparisons. The paper therefore demonstrates feasibility and system integration—not universal performance leadership.
The same caution applies to openness. A repository can be public while important tuning knowledge, test infrastructure, binary components or deployment practices remain concentrated within the vendor and a small group of partners. TileLang’s own documentation warns that nightly builds may be less stable than official releases [3]. The relevant question is whether external developers can reproduce performance, diagnose failures and contribute without privileged access.
| Layer | Evidence now visible | Strategic value | Remaining proof |
|---|---|---|---|
| Kernel language | TileLang and Ascend-specific backends are public | Lower-level performance work becomes more accessible | Independent maintainers and stable releases |
| Compiler and ISA | Ascend C, PTO and two backend routes | Potential portability across Ascend generations | Reproducible optimization and debugging |
| Framework | PyTorch integration through torch_npu | Less application-level rewriting | Broad operator and version compatibility |
| Scale-out software | Compute and communication libraries plus SuperPoD APIs | Co-optimization of kernels and collectives | Fault recovery and utilization at production scale |
| System evidence | CloudMatrix384 results for DeepSeek-R1 | Shows integrated serving is feasible | Current independent comparisons and economics |
Why this is not yet a CUDA replacement
CUDA’s advantage is cumulative. It includes nearly two decades of developer learning, extensive libraries, profiler integration, cloud availability, third-party software support and a large base of optimized applications. A simpler kernel language can reduce one portion of the switching cost, but it cannot immediately replace the surrounding ecosystem.
The new stack must pass four practical tests. First, coverage: common and emerging model operators must work without bespoke rescue engineering. Second, portability: kernels should move across processor generations and, where intended, across vendors without hiding large performance losses. Third, operations: distributed jobs need reliable profiling, checkpointing, fault recovery and version management. Fourth, economics: users need evidence that engineering cost, availability and energy efficiency offset the cost of maintaining another platform.
Framework integration is improving. PyTorch has documented Ascend integration through an out-of-tree torch_npu plug-in, allowing PyTorch programs to target Ascend devices [8]. That lowers the application-level barrier, but high-performance kernels and communication behavior still remain hardware-specific. In other words, framework portability does not eliminate systems optimization.
Strategic implications for chipmakers and investors
For chipmakers, the lesson is direct: silicon without a credible programming path will be discounted. Compiler teams, kernel libraries and developer tooling are no longer support functions; they are part of the product moat. The DeepSeek–Huawei collaboration also shows why anchor model developers matter. Their workloads expose performance gaps earlier than generic benchmarks and can help prioritize the kernels that determine real deployment economics.
For cloud and enterprise buyers, a more open stack could improve negotiating leverage and reduce dependence on one accelerator family. However, diversification creates a new integration burden. Buyers may need to qualify kernels, numerical behavior, orchestration and reliability across several hardware-software combinations. The value of portability should therefore be measured in validated workloads and operator coverage, not in source-code availability alone.
For investors, repository activity is useful but insufficient. Stronger indicators include the number of externally maintained production kernels, time required to port a current model, performance retained after portability, third-party cloud availability, recurring paid workloads and evidence that users upgrade across hardware generations without major rewrites.
What to watch next
- Independent benchmarks of TileLang and CANN on current training and inference workloads, with complete configuration disclosure.
- Evidence that external teams—not only Huawei and DeepSeek engineers—can reproduce and maintain high-performance kernels.
- Broader PyTorch, vLLM and distributed-training compatibility with fewer model-specific patches.
- Production data on job completion, fault recovery, utilization and developer time, not only peak throughput.
- Commercial deployments of Ascend 950 systems and credible comparisons of total cost per trained or served token.
Takeaway
DeepSeek and Huawei are attacking the right constraint. Alternative AI hardware will not become strategically meaningful through transistor counts alone; it needs a software and systems layer that developers can trust. TileLang, CANN, PTO and SuperPoD co-design create a plausible path toward that goal. The decisive proof will be external adoption: repeatable performance, production reliability and a community that can innovate without depending on the original vendors for every difficult optimization.