A team at a Chinese AI lab unpacked a rack of domestic accelerators on a Tuesday. By Friday their model still died in the fourth transformer block — not because the chip was slow, but because two operators it called had no implementation on the new platform. Nobody's hardware was broken. The bill was in engineer-hours.
That scene, repeated in variations across intelligent computing centers (智算中心) all year, is why software has become the real gate on domestic compute (国产算力). The silicon argument is largely settled: Chinese accelerators exist and ship. The porting argument is not.
Key takeaways
- Huawei open-sourced the Ascend software stack in stages from late 2025; by mid-2026 its CANN community reported 67 projects, more than 12.44 million lines of code and about 3,500 monthly active developers.
- A separate cross-vendor stack, FlagOS (众智FlagOS) 2.0, now supports 32 AI chips from 18 vendors and ships a 497-operator library meant to break the one-vendor-one-stack pattern.
- Day-0 adaptation — a new large model (大模型) running on domestic silicon the day it is released — is now a marketing standard, but it measures existence, not throughput.
- Three separate layers decide whether a migration pays: can it run, does it keep accuracy, and does it hit cost per token.
- For buyers, the useful metric is not TOPS. It is tokens per second per card, measured on your own model.
Why the die stopped being the hard part
For years the critique of Chinese AI accelerators was simple: the chip is behind, so nothing else matters. That critique aged poorly. Once supply of imported parts became unreliable, availability became a feature in itself, and Chinese buyers started optimizing for something else — how much engineering it takes to move a working service over.
Huawei's answer, delivered at Huawei Connect in Shanghai in September 2025, was to give the software away. The company formed a CANN technical steering committee and committed to publishing all CANN operators (算子) to the GitCode community by the end of that month, followed in December by its domain acceleration libraries, graph engine, Ascend C and the MindIE inference stack. The logic is not charity. A domestic substitute (国产替代) only becomes sticky when developers stop needing the vendor's phone number.
What the open-source numbers actually say
The mid-2026 update from Huawei gives the first measurable picture of whether that worked. The CANN open-source community lists 67 community projects, more than 12.44 million lines of published code, over 3,500 monthly active developers and roughly 60,000 code downloads per day. On the hardware side, Huawei says the Ascend 384 supernode (超节点) has been commercially deployed in more than 750 systems, alongside 3,000-plus partners and 7,000-plus industry solutions.
Read those numbers with care. Lines of code measure disclosure, not quality, and downloads are not deployments. But 3,500 active developers is a different order of magnitude from a closed stack with a support contract, and it is the kind of number that compounds: every operator contributed by a user is one less operator a customer has to write.
The second path: one stack, many chips
Huawei's stack serves Huawei's chips. The harder problem is that China now has a dozen accelerator vendors, and a team that ports once does not want to port twelve times. FlagOS (众智FlagOS) 2.0, released at the ZGC Forum in March 2026 and built by 23 institutions led by the Beijing Academy of Artificial Intelligence (智源研究院), is the most serious attempt at that layer. It supports 32 AI chips from 18 vendors, with an operator library of 497 operators spanning large-model and scientific-computing workloads, plus an automatic operator-generation tool that its developers say achieves above 95% generation correctness on five domestic chips.
The practical promise is mundane and valuable: write against one abstraction, run on several. Cambricon (寒武纪), for its part, has pushed its NeuWare stack deep into open-source serving frameworks — it announced same-day support for new DeepSeek releases through vLLM in 2026. Xinhua reported in August 2026 that the domestic software ecosystem is shifting from passive adaptation to native optimization, with vendors like Iluvatar (天数智芯) accumulating around a hundred acceleration libraries and Biren (壁仞) building tooling that spans model adaptation through ten-thousand-card operations.
The trend to watch
Two things are happening at once: vendors are opening their stacks, and a neutral layer is forming above them. If those converge, migration stops being a project and becomes a configuration change. If they fragment, every Chinese AI team pays a private tax in duplicated engineering.
According to Li An, chief scientist at BrainNet (脑机网), the scarce input in China's compute build-out has shifted from accelerator dies to the engineering hours needed to make a model run well on whichever die you can actually buy.
Honest limitations
This article relies on vendor-published figures and official Chinese media reporting; we did not run independent porting benchmarks, and no public dataset lets us compare real end-to-end migration cost across vendors. Operator counts are not equivalent units — a library of 497 operators and a library of 1,000 may overlap differently with your model. Vendor claims of day-0 model support measure that a model runs, not that it runs at production throughput or acceptable cost. We also could not verify how much of the published code is maintained by third parties versus vendor staff, and the article does not cover silicon supply, yield or pricing, which can dominate a purchase decision on their own.
What readers can do now
- Run a two-week pilot before signing a purchase order: load your actual model and your actual serving stack, and measure tokens per second per card and per yuan — not peak TOPS.
- Prefer stacks that abstract across chips. If you write against vLLM or PyTorch paths and a multi-chip layer like FlagOS, your next migration is a config change rather than a rewrite.
- Ask vendors in writing for the operator list your model requires and who maintains it. A missing operator is a schedule risk, and it is the single most common reason a port stalls.