iFlytek Spark-X2.6 Launches on Xingchen MaaS Platform, with Real-World Tests of Device-Cloud Collaboration and the 4B On-Device Model

I took a walk around iFlytek's annual Global 1024 Developer Festival, and I came away with just one impression:

Lively. Really lively.

One look at the photos and you know how hard it was to move two steps forward in that crowd—

Among them, the Spark-X2.5 series open-source models released this September have surpassed 2.56 million cumulative downloads across all channels (entering the global top four for on-device model downloads), and the 4B version even hit No. 1 on the Hugging Face 7-day Trending list.

"2.56 million downloads, No. 1 on the list"—those results are indeed impressive, but what I really had my eye on this time was something else:

iFlytek is still taking a path that's a bit different from most players.

Full-stack self-reliance and controllability.

From model training to inference, and then to on-device deployment, iFlytek has been using domestic compute to support its entire large-model system.

How hard this path is, well, anyone who knows knows...

So the question is:

Without relying on Nvidia GPUs, how far has this fully domestic system actually taken Chinese models?

Although everyone talks about "domestic large models," the domestic compute routes within that are actually not quite the same.

From model training, reinforcement learning, and continuous iteration to inference deployment, the entire chain runs on domestic compute platforms.

The Nvidia content in the core chain is zero. How should I put it? It does sound satisfying.

But once you really dig in, you realize how hard this is.

Over the past few years, when the industry discussed fully domestic large models, the first question usually asked was:

Can domestic chips actually train a model at all?

That is indeed the most intuitive hurdle, but the real difficulties only start to emerge once you reach large-scale training.

Nvidia's advantage lies not only in GPUs but also in the software ecosystem it has built around CUDA over many years. After switching to domestic chips, everything from operators and frameworks to multi-card communication has to be re-adapted.

Once the scale reaches thousands or tens of thousands of cards, training efficiency and cluster stability become new tests.

A lot of the work is hidden behind the model. Ordinary users don't see it, yet it consumes the most time and R&D resources.

I then went back through iFlytek's timeline over the past few years and found that its understanding of "fully domestic" has indeed gone several steps beyond "training a model on domestic cards."

This may be related to iFlytek's long-term deep roots in industry scenarios.

Once models enter the various hardware devices in hospitals, schools, and enterprise systems, compute supply, data security, and deployment costs become unavoidable issues, and that has pushed it onto the full-chain localization route earlier.

In 2023, iFlytek teamed up with Huawei to launch "Feixing-1," first building a large-scale domestic compute foundation.

Later came the hundred-billion-parameter model Spark-V3.5 and the deep reasoning model Spark-X1 on domestic compute.

By this year, Spark-X2.5 open-sourced the 4B and 1.7B on-device models, starting to work their way into more terminal devices.

All the way through to Spark-X2.6, the question has already moved from training to deployment:

Where exactly should the model run?

I recently happened to read Every's article "How Codex Happened" and found that OpenAI also paid tuition on this question.

OpenAI initially put all of Codex in the cloud, but ran into trouble because environment configuration was cumbersome and tasks were hard to intervene in at any time. Only later did it turn to local, and gradually connect the two sides.

Why did it end up needing both sides? One look at this table makes it clear:

The cloud wins on capability, while the device side wins on offline response, cost, and privacy. In real business, it's hard to bet on just one side.

The more practical approach is to give the choice to enterprises:

Which tasks stay local, which tasks go to the cloud, which data can be uploaded, and how many tokens they're willing to spend on a single call.

What Spark-X2.6 does is precisely to let the device side and the cloud divide the work on demand:

The task is first judged by the on-device model, which then chooses the appropriate execution path, forming three collaboration modes.

Simple tasks are completed directly locally—this is "pure on-device execution."

For tasks that need cloud capabilities, the data is first desensitized on the device side and then handed to the cloud for processing—this is "pure cloud-side execution."

For tasks that require both sides to work together, the data is desensitized on the device side and then enters "cloud + device execution"—either the cloud provides guidance while the device side completes the operation, or the device side and the cloud divide the work and collaborate to complete the task together.

The idea sounds smooth enough, but can it really save tokens and protect privacy?

Well then, let's test it.

Spark-X2.6 is now available on the iFlytek Spark MaaS platform. It uses a MoE architecture, with 293B total parameters, about 30B activated per inference, and supports a 1M context.

The current API price is 40% off: 0.9 yuan per million input tokens and 3.6 yuan per million output tokens (about 10% cheaper than the big fat fish valley price).

Compared with X2.5 released in September, this generation mainly pushes forward in three steps:

Stronger at getting work done: X2.6's coding and agent capabilities each improved by about 8 points overall, placing the model's overall strength in the industry's first tier;

Smoother on domestic compute: through training and inference architecture optimization, the model's efficiency on domestic training platforms increased 4x, and the four-layer KV Cache hit rate reached 95%;

More economical to use: in high-frequency application scenarios, about 60% of tasks saw a reduction in token consumption.

To sum up, these upgrades still point to that familiar theme:

Getting work done.

Since what's being tested is the ability to get work done, asking a few questions in a chat box is obviously not enough.

So this time, I hooked Spark-X2.6's API into the DeepSeek Harness, letting it directly read and write files, run code, and troubleshoot errors based on the execution results.

Before anything else, let's see how big the gap still is between it and the current top-tier models.

Recently, when top Silicon Valley models are released, visual coding has become almost a fixed segment—the pelican riding a bicycle and 3D interactive scenes get trotted out again and again.

Although this kind of task can't replace a benchmark, its advantage is that the results are intuitive enough, so for the first round I also gave Spark-X2.6 the "top-tier same-style" treatment.

"Top-tier same-style": testing just how strong the model itself is

First, a pelican riding a bicycle.

The prompt uses the minimalist style common in Silicon Valley tests, specifying no art style, composition, or implementation method—just one sentence to the model:

Create an SVG of a pelican riding a bicycle. Save it as pelican.svg in the current directory and preview the result. Do not use external image assets.

The fewer the requirements, the harder it is for the model to hide its own coding fundamentals and taste.

The image below is the result of the model's one-shot output, and at first glance the level of completion is indeed not low:

The bicycle structure is complete, and both the foreground and background have been filled in.

While I was at it, I added another task: a 3×3 Rubik's Cube simulator.

This time it wasn't just about drawing the cube in pure CSS 3D—all six faces had to actually turn, with scramble and reset also included.

The final version was also quite hassle-free: no dependencies to install, one file opens and runs, dragging the mouse changes the viewing angle, and you can twist it however you like.

If it can twist a Rubik's Cube, then surely it's time for a final boss-level ultimate test:

Build a freely explorable 3D Forbidden City with code.

I threw it an AI-generated prompt, and then, while Spark-X2.6 was running in the background, went off to eat.

Unexpectedly, when I came back, it had delivered a complete web page consisting of index.html, style.css, and main.js.

Opening the local service, red walls and golden tiles spread out along the central axis, and the mouse could freely rotate, zoom, and move the viewpoint.

Honestly, it was quite a bit more complete than I expected.

From this small trial, although Spark-X2.6 can't guess every detail right in one go, it responds quickly to feedback.

This point is actually quite important for a coding agent.

Anyone who has tried Vibe Coding should know the feeling: even with the flagship models from the "OA" duo, having a single generation fully meet expectations is not very realistic.

So for me, what really affects the experience is whether the model can understand plain human language and revise quickly and accurately.

Of course, drawing images and building web pages are just warm-ups; next it needs to be given some real work to do.

Putting a 4B model on a computer and letting it work independently

This time the protagonist switches to the just-open-sourced Spark-X2.6-4B.

Despite having only 4B parameters, it supports up to 1M context and more than 200 languages, and is also adapted to local runtime tools such as Ollama and LM Studio, as well as mainstream inference frameworks such as llama.cpp and vLLM.

To squeeze as much capability as possible out of the 4B model, iFlytek added a capability-awareness mechanism during post-training, letting the model judge its own weak spots and then learn in a targeted way from different teacher models.

According to iFlytek's internal evaluation, the proportion of agent tasks that same-size on-device models can complete independently is about 12.8%, while Spark-X2.6-4B raised this number to 41.9%.

Never mind—whether it's a mule or a horse, it has to be taken out for a run.

Since my computer only has an AMD integrated GPU and no discrete graphics card, the model relied on CPU inference the whole time, so I deployed the Q4 quantized version of Spark-X2.6-4B through Ollama and called the local API from the terminal.

After the model ran successfully, I disconnected the network directly to ensure that material reading, analysis, and result output all stayed on this computer.

I assigned it the task of completing a weekly business review for a fictional robotics company.

Sales weekly reports, customer emails, production schedules, and supply chain records were scattered across different files, and some information even contradicted each other. It needed to cross-check data across files, identify revenue changes, customer conflicts, and delivery risks, and finally list the matters awaiting management's decision.

In the end, the model took 6.8 minutes and delivered a complete business review report.

It distinguished the 25.5 million yuan sales-basis revenue from the 23.7 million yuan financially confirmed revenue, and also identified two key business opportunities and three types of supply chain gaps, with sources noted for the main conclusions.

Across the five dimensions of numerical accuracy, cross-file association, risk identification, source tracking, and report completeness, this round of task completion was about 90%.

To nitpick, it classified one order in hand as a potential business opportunity, so the categorization isn't rigorous enough; however, the relevant facts and amounts are all correct, and after a simple manual review, it can already serve as reference material for management discussion.

For a 4B model that is fully offline and runs entirely on CPU, this is a solid performance.

For complex tasks involving sensitive information, let the cloud take over

However, the capabilities of on-device models ultimately have limits, and when faced with more complex tasks, the cloud still has to step in.

So which tasks stay local, and which tasks are worth sending to the cloud?

To this end, iFlytek introduced a collaborative training mechanism for device-cloud routing based on a critic model.

Simply put, the same task is run several times on the device side and in the cloud, and then the critic model compares the results and gives feedback, and through alternating training it continuously optimizes the routing decision, so the system becomes clearer about whether a task should be handed to the device side, the cloud, or both working together.

According to iFlytek's internal evaluation, this mechanism raised the accuracy of device-cloud task routing from 81.2% to 96.1%.

Since it's already 96.1%, for this round of hands-on testing I decided to give it a more sensitive set of materials with more complex relationships:

Review a procurement contract for industrial vision inspection equipment.

The contract is still fictional, but it includes company names, contacts, phone numbers, bank accounts, and contract amounts, and there are also multiple interrelated risks hidden among payment, acceptance, data upload, intellectual property, and liability for breach.

I first had the local 4B model handle de-identification.

It took 4.3 minutes, and all 26 sensitive items in the contract were replaced with placeholders; the check results showed no residual original information.

Only after confirming it was clean did I reconnect to the internet and hand the de-identified contract to the cloud X2.6.

After 70.8 seconds and 7,368 tokens consumed, it delivered a complete review report, identifying 18 risks and 8 groups of clause conflicts.

Issues hidden across different clauses, such as acceptance standards contradicting each other and data being allowed to be uploaded directly to the cloud while the supplier is required to bear unlimited liability, were also traced and uncovered by it.

Afterward, I disconnected from the network again, restored the contract information locally, and generated a Word file with item-by-item revision suggestions.

To avoid grading its own work, I also threw the entire set of materials to Codex for a second review.

The results showed that the contract received by the cloud contained no original sensitive information, and after local restoration no placeholders remained; the contract body and tables were also fully preserved.

Only at this point was the entire process truly working end to end:

Sensitive information stays local, complex analysis goes to the cloud, and after processing it returns locally for restoration.

It should be noted that this time I only did a minimal feasibility verification.

To see the data flow at each step clearly, I kept the manual allocation step; the complete solution supports automatic routing.

Once it truly enters an enterprise environment, the system can automatically allocate device and cloud tasks according to task difficulty and security requirements, turning this technical solution into a business process that can run continuously.

After going through this round of testing, what impressed me most about Spark-X2.6 was that it leaves enterprises room to choose.

When large models first became popular, enterprises using AI basically just connected to a cloud API—simple and direct.

Contracts and customer materials are not convenient to upload, high-frequency calls will continuously generate token costs, and if everything is placed on the device side, capability on complex tasks may not keep up.

The value of device-cloud collaboration lies in letting enterprises freely adjust their deployment approach according to their own business.

Stanford's 2026 AI Index shows that 88% of surveyed enterprises worldwide already use AI, but the scaled deployment rate of Agents in almost all business functions is still only in the single digits.

This shows that AI has entered enterprises, but core business has not yet truly been handed over to Agents.

If Agents are to continue moving into core business, then in addition to model capabilities, deployment methods must also change with the scenario.

Hospitals, schools, and offices face different constraints, so how to divide work between device and cloud naturally will not have only one answer.

iFlytek's interesting point is that it has been thinking about this problem for several years.

From the beginning, iFlytek spent a great deal of time grinding away at a domestic computing power foundation.

You have to know that just getting models to "run" on domestic computing power and solving a series of inference adaptation problems is already enough to wear you down.

But what is even more impressive is that iFlytek not only got it running, but also completed the full training process for large models on this foundation, directly training large models whose strength benchmarks against top international models.

From "running" to "training out," it sounds like only a few words of difference, but the engineering difficulty behind it is on a completely different order of magnitude.

Looking around, there really are very few companies willing to keep filling in the pits for this full chain over the long term.

And the pits iFlytek has stepped into and the experience it has accumulated over the years have now all become its strongest cards for building on-device models and device-cloud collaboration.

Of course, starting early is only the beginning; what really determines how far this route can go still depends on performance in scaled deployment.

Similar long-term tests are not uncommon in China's technology industry.

Beidou was approved in 1994 and completed global networking in 2020, taking 26 years.

The C919 was approved in 2007 and made its first commercial flight in 2023, also taking 16 years.

From technological breakthrough to actual use, there is still a long road ahead.

The path of domesticization for Chinese models cannot avoid this hurdle either.

New models and leaderboard results are easier to see, while matters such as system adaptation, project delivery, and long-term operation rarely enter discussion.

Model capabilities can be caught up through iteration after iteration, but this kind of less conspicuous accumulation is hard to make up overnight.

The advantage iFlytek has gained by starting a few years earlier has already begun to show.

P.S. You can now go to the Xingchen MaaS platform to claim a free 1 billion token quota for Spark-X2.6~

Portal: