Code skills trained on all-domestic compute: iFlytek Spark X2.6 launches with 293B MoE and 1M context

On the afternoon of October 22, 2026, at the main forum of the 2026 Global 1024 Developer Festival in Hefei, iFlytek officially launched its edge-cloud integrated Spark X2.6. The most striking label of this launch was not the parameter count but the training base: according to iFlytek, this is the first large model to achieve breakthroughs in code and agent capabilities trained entirely on domestically produced compute. Against the backdrop of constrained N-card supply, that claim deserves a serious teardown.

Launch essentials: what X2.6 actually is

The core announcements compress into four points. First, the cloud flagship Spark X2.6, which according to iFlytek uses a 293B-A30B MoE architecture — 293 billion total parameters with 30 billion activated per inference — and a context window extended to 1 million tokens. Second, matching training and inference engineering: a self-developed dynamic parallel training technique for long-horizon tasks, plus adaptive storage-compute co-processing inference and the first four-tier KVCache technology built on all-domestic hardware. Third, the simultaneously open-sourced edge model Spark X2.6-4B, free for a limited time. Fourth, cloud inference pricing: 0.9 yuan per million input tokens (limited-time), 0.08 yuan on cache hits, and 3.6 yuan per million output tokens.

The X2.6 series is already available for trial on the iFlytek Spark official site. For developers, this is a launch you can actually get your hands on rather than a parameter slide deck — something not all that common among domestic model launches, and worth a nod.

The launch carried more than X2.6 itself. According to Zhidx.com （智东西）, iFlytek published a batch of benchmark results: on code, Spark X2.6 took first place on SWE Pro and SWE Multilingual, and second on SWE Verified behind DeepSeek-V4.1-Flash; on agents, it sits in the top tier for enterprise-ops agents and general tool-use on MCP-Atlas; on reasoning, it ties MiniMax M3 on AA-LCR v1.1. These are vendor-published scores — no independent third-party evaluations exist yet — but they at least give developers a coordinate system to check against. The event also saw the SparkAudio 1.0 speech foundation model, the SparkAuto Space 3.0 full-modal cockpit, the WinWork digital-employee platform for enterprises, and two X2.6-powered products: Spark Loomy for everyday office work and Spark AStudio for professional work like coding and research — the latter aimed squarely at developer scenarios.

Technical teardown: what 293B-A30B MoE means

The 293B-A30B naming follows industry convention: 293 billion total parameters, sparsely activated, with only 30 billion engaged per forward pass. The core value of the MoE (mixture-of-experts) architecture is trading near-30B-class inference cost for near-300B-class knowledge capacity. For code and agent tasks, that capacity matters enormously: code completion, cross-file reasoning, and long-horizon agent planning all depend on the model "remembering" vast numbers of patterns, API usages, and engineering conventions — and parameter scale directly caps that memory.

But the MoE ledger has two sides. Large total parameters mean heavy VRAM footprint and high communication overhead at deployment. The 30 billion activated parameters cost roughly what a 30B-class dense model costs at inference, yet KVCache and expert-weight loading demand far more memory bandwidth. That is precisely why iFlytek spent so much of the keynote on inference optimization — without engineering like the four-tier KVCache and storage-compute coordination, the bandwidth bottleneck would eat most of the MoE cost advantage.

The engineering meaning of 1M context

One million tokens of context, by rough Chinese-English mixed-text estimates, equals about 600,000 to 800,000 Chinese characters — enough to swallow the core files of a mid-sized code repository. For agent scenarios, the real value of long context is not "reading everything at once" but reducing information loss across multi-turn tasks: in long-horizon work, tool-call results, error messages, and intermediate decisions from early rounds fall out of the window, and the agent starts to "forget" and repeat mistakes. A million-token window pushes that boundary to an engineering-useful magnitude.

An honest patch is needed here, though: a model's effective context length and its nominal length are two different things. Multiple third-party evaluations across the industry show that many models' retrieval accuracy over the middle of the window degrades noticeably past a certain ratio (the familiar "needle in a haystack" decay). iFlytek has not published X2.6's needle-retrieval curve at the million-token length, so the practical usability of that long context will need third-party benchmarks or hands-on developer testing to verify — the headline number alone is not enough.

Dynamic parallel training and four-tier KVCache: what problems they solve

According to iFlytek, the self-developed dynamic parallel training technique for long-horizon tasks was built for a specific reality — domestic AI chips' relatively constrained VRAM and bandwidth — and delivers roughly a 4× improvement in ultra-long-context training efficiency. Translated into engineering language: domestic compute cards typically offer less per-card memory and weaker inter-card interconnect than flagship N-cards, so training on ultra-long sequences demands far more carefully tuned sharding strategies (combinations of data, tensor, sequence, and pipeline parallelism). Otherwise huge amounts of time burn in communication stalls. "Dynamic parallelism" addresses exactly that — letting the sharding strategy adapt in real time to task length and hardware topology.

The inference side is a different combination: adaptive storage-compute coordination inference plus the first four-tier KVCache technology built on all-domestic hardware. KVCache is the VRAM hog of the decoding stage; the tiered-KVCache idea places caches of different "hotness" on different storage tiers (HBM, DRAM, even slower media) and uses scheduling algorithms to hide access latency. "Four tiers" means finer-grained staging. According to Zhidx.com, with this architecture, inference efficiency on domestic Feixing-2 chips reached 4.5× the pre-optimization level, and KV Cache hit rate rose from 63% to 95.7% — the hit-rate figure is more concrete than "4.5×" because it directly determines decoding latency for long-context agent tasks. The same caveat applies: test methodology (batch size, sequence length, baseline) was not fully disclosed, so treat it as a vendor-reported upper bound for now.

The X2.6-4B edge model: where iFlytek's open-source base comes from

To weigh X2.6-4B properly, look at its predecessor first. According to Zhidx.com, X2.5-4B has reached 2.56 million downloads since its open-sourcing on September 1, ranking among the global top four edge models. 2.56 million is a hard number: it means iFlytek has built a genuine developer base on the edge rather than storytelling from zero — the edge-model demand wave (local knowledge-base Q&A, offline coding assistants, lightweight agents for privacy-sensitive scenarios) is real, and iFlytek rode it.

iFlytek's edge-model pedigree differs from pure cloud-model vendors. Its speech technology — voice typing in input methods, meeting transcription, real-time translation — has run on phones and IoT devices for years, giving it over a decade of accumulated engineering in "small model + weak compute + low latency." The claim that its self-developed inference framework beats Ollama on efficiency (again vendor-reported, awaiting hands-on verification) would, if true, make X2.6-4B notably more usable than same-class open models on consumer GPUs or even CPUs. That is a concrete win for vibe developers: running a 4B model locally on a laptop that can handle a simple agent loop means debugging prompts and toolchains without burning cloud API money every round — an order-of-magnitude faster iteration.

A bucket of cold water is still warranted: the agent-capability ceiling of a 4B-class model is objective. No amount of fine-tuning or framework optimization will let a 4B model reliably complete deeply-planned multi-step tasks. The sane expectation is to treat it as a "local development sandbox": get the agent's tool definitions, prompt templates, and error-handling flows right locally and verify the logic; then switch to cloud X2.6 or another large model for production runs. iFlytek's "edge-cloud integration" narrative is essentially pushing this workflow — the edge model is the hook, the cloud API is what gets sold. Seeing through that layer means neither fantasizing about the 4B model's agent skills nor missing its real value.

Edge-cloud integration and the 96.1%: what the number actually means

First, a correction on an easy misreading: according to Zhidx.com, 96.1% is the edge-cloud routing accuracy — how accurately the on-device model decides whether a task should be handled on-device only, cloud only, or by edge-cloud collaboration. iFlytek lifted it from 81.2% to 96.1% through a comment-model-based edge-cloud routing co-training mechanism. It is a concrete classification-accuracy metric, not a fuzzy "coordination efficiency" notion. Accurate routing is what makes edge-cloud integration meaningful: one wrong route either crushes quality by pinning a heavy task on-device or burns money by sending a light task to the cloud.

The accompanying task-allocation design: 60% of AI application tasks complete on the local device with raw data never uploaded; 30% are handled by edge-cloud collaboration; the remaining 10% of hard tasks call the cloud model. This "6-3-1" structure tries to answer three questions at once: data security (local closed loop), compute cost (light tasks stay off the cloud), and task quality (hard tasks have cloud backup). Liu Qingfeng framed the edge-cloud integrated solution on stage as reconciling the tension between large-model security and inference cost — an accurate positioning.

The practical implication for developers is workflow design. If over 60% of your app's requests are intent classification, simple Q&A, or formatting — light tasks the on-device 4B model can fully cover — and only a small share of heavy reasoning goes to the cloud, total cost and latency both drop significantly, and the on-device portion naturally satisfies privacy compliance. This "tiered routing" idea is being explored in the Claude and GPT ecosystems too, but iFlytek ships it as an officially supported closed loop: open-sourced edge model, unified coordination framework, flagship cloud API — more turnkey out of the box.

"All-domestic compute": substance and controversy

This was the most headline-grabbing part of the launch. iFlytek chairman Liu Qingfeng said on stage: "Spark is the only one trained on all-domestic compute; everyone else trains on N-cards" — with other vendors "at most migrating to domestic compute arrays afterwards." (Liu Qingfeng's on-stage remark, as reported in launch coverage.)

The substance first. If true, it means iFlytek has walked a complete engineering chain of "domestic chips training domestic large models": adapting the training framework to domestic cards, operator optimization, parallel strategies for ultra-long context, and storage-compute coordination on the inference side. The value of that chain is not any single trick but pushing domestic compute from "can run demos" to "can train flagship models." In the current supply environment, that is a genuine positive signal for the domestic compute ecosystem — at minimum, proof that the path of "training competitive models without N-cards" is engineering-feasible.

Now the controversy and the reasons for calm. First, "everyone else trains on N-cards" is far too absolute: multiple domestic vendors are exploring domestic-compute training to varying degrees, and asserting "only Spark" lacks a verifiable denominator — training-compute composition is a trade secret no outsider can independently audit for any vendor. Second, iFlytek did publish a batch of benchmark rankings this time (first on SWE Pro and SWE Multilingual; second on SWE Verified; top tier on MCP-Atlas) — a genuine transparency improvement — but these remain vendor-selected eval sets with vendor-reported scores, and no independent third-party evaluations exist yet, so the launch's "first" and "only" language should be read with a marketing discount and the real test awaits community reproduction. Third, even if the training stage is all-domestic, the launch said nothing about domestic content in EDA tooling or parts of the IP stack — a blank left unfilled. Fourth, the absolute training-efficiency numbers deserve a close look: according to Zhidx.com, training 2000B tokens at 256K length on the ten-thousand-card domestic Feixing-2 platform dropped from 4.5 months to 1.2 months; Liu Qingfeng said X2.6 itself was trained over the past 2–3 months — that timeline is itself the strongest footnote for "domestic compute can train large models."

My read: treating "all-domestic-compute training" as an engineering milestone is fair — it proves feasibility. Treating it as "domestic compute has fully caught up" is a stretch. The real tests are prosaic: X2.6's API stability, inference latency, actual performance on code tasks, and whether developers will pay for it. A launch keynote cannot supply those numbers; the market will.

Pricing in context: what 0.9 / 0.08 / 3.6 yuan means

X2.6's inference pricing is public: 0.9 yuan per million input tokens (limited-time), 0.08 yuan on cache hits, 3.6 yuan per million output tokens. Laid out plainly:

Billing item	Price (yuan / M tokens)	Notes
Input	0.9	Limited-time price; regular price not announced
Cache hit	0.08	For cached input portions — under a tenth of the input price
Output	3.6	4× the input price, a standard industry ratio

In context, this pricing sits in the lower-middle band of China's API market: the 0.9-yuan input is clearly a volume-driving trial price, while the 0.08-yuan cache-hit price is the genuinely sharp design. Agent tasks are multi-turn, long-context, and repeatedly re-read the same code or documents — scenarios where prompt caching hits constantly. At 0.08 yuan, a 10-round agent task may cost a fraction of full billing. The pricing structure is unmistakably aimed at agent developers: pull agent workflows over with low prices first, keep them with the ecosystem. Output at 3.6 yuan keeps the industry-standard 1:4 input-output ratio with no extra markup — the subsidy sits on the "get you started" input side, not recouped on output.

Note the word "limited-time": 0.9 yuan is a promotional input price, and the regular price is undisclosed. Budget long-term costs assuming it may rise after the promotion; in the short term, it is cheap enough to run serious evaluations on. Lei Technology's cross-market read: this pricing sits in the low band of China's model API market — cheaper than Zhipu and Doubao, slightly pricier than Xiaomi MiMo and DeepSeek's Flash models — "very cost-effective." That third-party view matches our own: X2.6's pricing strategy is "low prices for ecosystem," betting that agent workflows, once migrated, won't easily move away.

A judgment for vibe developers: are domestic models ready for code/agent work

Translating the launch into developer language, my verdict comes in three layers:

• Worth trying now: Chinese-language code completion, comment generation, unit-test writing, simple cross-file refactoring; local agent prototypes on the open-sourced X2.6-4B — the edge 4B plus a self-developed inference framework (claimed to beat Ollama) is a handy fit for getting an agent loop running on a laptop before deciding whether to go cloud. The cache-hit pricing also makes multi-round agent experiments affordable.
• Worth verifying before relying on: long-repo Q&A over the million-token context, complex multi-step agent planning. Nominal length is not effective length — run your own "needle in a haystack" test on your own repository: bury key facts in 500K tokens of context, see whether the model retrieves them reliably, then decide on production readiness.
• Watch and wait: the vendor-reported 4× training efficiency, 4.5× inference efficiency, and 96.1% edge-cloud routing accuracy — none of these numbers' test methodologies are public. Treat them as "directionally correct" signals, not selection criteria, until independently reproduced. And the "all-domestic compute" narrative has no direct bearing on selection — developers care about latency, quality, and price; which country made the chips changes nothing about the API's behavior.

One blunt closing note: over the past two years, domestic models' coding ability has bounced between "almost usable" and "actually usable." Tying "all-domestic compute + code/agent breakthrough" together in this launch carries more marketing weight than technical weight — but marketing aside, a domestic 293B-MoE model with 1M context, 0.9-yuan input and 0.08-yuan cache hits sitting in front of you makes the cost of running your own evaluation essentially negligible. For vibe developers, the best verdict is always the same: throw your real tasks at it, run 20 cases — worth more than 20 launch write-ups.

The X2.6 series is already available for trial on the iFlytek Spark official site, and the X2.6-4B open-source model is free for a limited time — the wool's expiry date is your evaluation window.