Keep 60% of the Work On-Device: iFlytek Trains Spark X2.6's 293-A30B on Fully Domestic Compute, with a Four-Layer KVCache Behind 96.1% Routing

Friday, October 23, 2026

Part One: Not Just “Yet Another Model Release”

October 22, 2026, Beijing, the iFlytek 1024 Global Developer Festival. The headliner was not a lone parameter count but an entire end-cloud integrated model system — Spark X2.6 — alongside the SparkAudio 1.0 speech foundation model, embodied multimodal interaction, the WinWork digital-employee platform, and a batch of AI hardware.

What technical readers should watch is the line Liu Qingfeng kept returning to: “Only when you train your own model on domestic compute is it genuinely autonomous and controllable.” “Domestic adaptation” has appeared many times over two years, but most of it stopped at the inference side — a model trained abroad, then ported to domestic chips. Spark X2.6 pushes the front to the harder training side: training and inference, cloud and device, the whole chain on domestic compute.

Specifications first:

Cloud model 293-A30B: MoE, 293B total / 30B activated per token, 1M-token context, deployed on the domestic 10,000-card “Feixing-2” inference cluster;
Device model X2.6-4B: 4B parameters for robots, cars, and AI PCs, open-sourced; the prior X2.5-4B hit 2.56 million downloads since Sept 1 and ranks in the global top four for on-device models;
Price: cloud input 0.9 yuan/million tokens, cached input 0.08, output 3.6; iFlytek says both the cache-miss input and output prices undercut DeepSeek-V4.1-Flash-1017.

This piece covers three things: how the hard problem of long-horizon training on domestic chips was cracked; what the first domestic-hardware four-layer KVCache lifting hit rate from 63% to 95.7% means; and, crucially, how end-cloud routing reached 96.1% accuracy so 60% of tasks genuinely stay local.

Part Two: The Real Domestic-Chip Training Bottleneck Is Mixed Long-Horizon Efficiency

Inference on domestic chips is relatively easy; training is hard; very-long-context training is hardest. The bottleneck is not peak per-card FLOPs but the efficiency black hole that appears when memory capacity and interconnect bandwidth are both constrained and many tasks of mixed lengths share a batch — long tasks wait on communication, short tasks wait on long tasks, and accelerators sit idle.

iFlytek’s answer is a platform-affine dynamic-parallel training technique for long-horizon tasks: compute resources are allocated adaptively by task length rather than cut with one static strategy. The numbers are stark — training 2,000B (2 trillion) tokens at 256K length on Feixing-2 went from 4.5 months to 1.2 months, roughly a 4x gain in long-context training efficiency. Liu said X2.6 was trained in the past two to three months.

The core idea is the classic systems principle that scheduling must match load shape: the parallelism mix (data / tensor / sequence parallel) should vary with sequence length so short tasks do not pay long tasks’ communication cost.

 Static parallel (mismatch, idle)          Dynamic parallel (length-adaptive)
  +-------------------------+              +-------------------------+
  | short | short | short   |              | short x N -> high DP     |
  | long (holds the batch)  |              | long       -> high SP    |
  | ▓▓▓▓░░░░░░░░░░░░░░░░░   |              | ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ |
  +-------------------------+              +-------------------------+
  low util: shorts blocked by long         high util: re-cut by shape

Part Three: The First Domestic-Hardware Four-Layer KVCache, Hit Rate 63% → 95.7%

The inference story is closer to cost. Long context has three classic pains: it does not fit (KV cache capacity), it is slow (long prefill, latency), and the hit rate is low (redundant recomputation).

iFlytek deployed a trio: adaptive storage-compute co-inference over heterogeneous domestic clusters, heterogeneous distributed inference, and what it calls the industry’s first four-layer KVCache architecture adapted to fully domestic hardware. Result: Feixing-2 inference efficiency reached 4.5x the pre-optimization baseline, and KVCache hit rate rose from 63% to 95.7%.

Why does one hit-rate number matter so much? With million-token context and many reusable prefixes (system prompts, long documents, multi-turn history), hit rate almost directly sets per-token cost. That maps onto the price table — cached input at 0.08 is under one-ninth of the 0.9 cache-miss price. Lifting the hit rate from the low sixties to the mid-nineties means roughly a third of requests that used to recompute are intercepted by cache, pulling average cost down sharply.

“Four layers” means a multi-level cache hierarchy across HBM, near-memory, node-local, and remote storage: hot KV stays on the fastest tier, cold KV sinks tier by tier, with storage-compute co-scheduling to cut cross-card movement. Python reproduces the “tiered KV cache + hit-rate-driven cost” accounting:

# Tiered KVCache: place KV blocks across layers of different latency/capacity
import random

class LayeredKVCache:
    def __init__(self, sizes, latency):
        self.layers = [{"cap": c, "lat": lat, "kv": {}} for c, lat in zip(sizes, latency)]
        self.hit = 0
        self.miss = 0

    def lookup(self, block_id):
        for i, layer in enumerate(self.layers):
            if block_id in layer["kv"]:
                self.hit += 1
                if i > 0 and len(self.layers[0]["kv"]) < self.layers[0]["cap"]:
                    self._promote(block_id, i)   # promote hot block
                return layer["lat"]
        self.miss += 1
        self._insert(block_id)
        return self.layers[-1]["lat"] * 10        # miss = recompute, far costlier

    def _promote(self, bid, from_i):
        val = self.layers[from_i]["kv"].pop(bid)
        self.layers[0]["kv"][bid] = val

    def _insert(self, bid):
        self.layers[0]["kv"].setdefault(bid, "kv_block")

    @property
    def hit_rate(self):
        t = self.hit + self.miss
        return self.hit / t if t else 0

# Zipf-hot prefix access (system prompts / long docs reused heavily)
random.seed(7)
cache = LayeredKVCache(sizes=(64, 256, 1024), latency=(1, 3, 8))
total_lat = 0.0
for _ in range(5000):
    bid = int(random.paretovariate(1.2)) % 2000
    total_lat += cache.lookup(bid)

print(f"tiered-cache hit rate: {cache.hit_rate:.1%}")   # target ~95.7%

Under Zipf-hot access the hit rate approaches the mid-nineties; drop it back to sixty percent and a flood of requests fall into the recompute branch, worsening both latency and cost. That is the economics behind 63%→95.7%.

Part Four: The Soul of End-Cloud Integration — Getting the “Who Does It” Routing Right

The most consequential piece is the newly released end-cloud collaboration architecture. A task arrives and the on-device 4B model first decides the route:

Pure device: locally solvable and private — data never leaves the device;
Pure cloud: complex tasks beyond the device, handed to the cloud 293-A30B;
Hybrid: split further into “cloud guides device” and “device-cloud division of labor.”

Liu’s target mix: 60% local, 30% collaborative, 10% pure cloud.

The whole architecture hinges on one thing — routing accuracy. Mis-sending an easy task to the cloud wastes money and leaks data; wrongly keeping a hard task local simply fails. iFlytek introduced a critic/reward-model-based routing co-training mechanism, lifting routing accuracy from 81.2% to 96.1%. The device model also uses “capability-aware adaptive iterative post-training”: it picks teacher models and adjusts training weights dynamically by real device capability, rather than blindly distilling the strongest teacher — a teacher too strong cannot be learned or deployed.

The privacy path is explicit: when cloud help is needed, the device desensitizes locally first, uploads only after user confirmation, and rehydrates the redacted fields locally once the cloud returns. In a demo, the device model read local mail and regional weekly reports, flagged the risk that “different teams are double-working the same customer,” and cited sources — all without data leaving the device. The fraction of agent tasks completable independently on-device is 41.9%.

Go models the three-way routing by difficulty/sensitivity/capability, with a desensitization gate:

package main

import "fmt"

type Task struct {
	name            string
	difficulty      float64
	sensitive       bool
	needsCloudSkill bool
}

type Route string

const (
	OnDevice  Route = "pure device: data stays local"
	CloudOnly Route = "pure cloud: hand off the hard task"
	Hybrid    Route = "hybrid: desensitize locally, then cloud"
)

func route(t Task) Route {
	switch {
	case t.sensitive && t.difficulty <= 0.55:
		return OnDevice
	case t.difficulty >= 0.8 || t.needsCloudSkill && t.difficulty > 0.6:
		if t.sensitive {
			return Hybrid
		}
		return CloudOnly
	default:
		if t.sensitive {
			return OnDevice
		}
		return Hybrid
	}
}

func desensitize(s string) string { return "[REDACTED:" + s + "]" }

func main() {
	tasks := []Task{
		{"local weekly-report dedup (client names)", 0.35, true, false},
		{"1M-token cross-border contract review", 0.9, false, true},
		{"procurement contract (prices, needs web)", 0.7, true, true},
		{"calendar reminder", 0.1, false, false},
	}
	for _, t := range tasks {
		r := route(t)
		payload := t.name
		if r == Hybrid {
			payload = desensitize(t.name)
		}
		fmt.Printf("%-42s -> %s [%s]\n", t.name, r, payload)
	}
}

Two rules are captured: sensitive + device-capable = firmly local, and hard + sensitive = only leave the device after redaction. With accurate routing, “60% local” is more than a slogan.

Part Five: Benchmarks and Deployment — the Code and Agent Tracks on Domestic Silicon

The self-reported results cluster in code and agents:

Code: first on SWE Pro and SWE Multilingual, second only to DeepSeek-V4.1-Flash-1017 on SWE Verified;
Agents: first tier on enterprise-ops agents and the general tool-use MCP-Atlas;
Reasoning: ties MiniMax M3 on AA-LCR v1.1;
Device 4B: beats the prior X2.5-4B as well as Qwen3.5-4B, Gemma4-E4B, and Qwen3.5-9B on search QA, office docs, schedule management, local spreadsheets, cross-tool coordination, multi-turn tool use, and complex knowledge search.

Deployment is well beyond demos: in education, “iFlytek Starlight” scored 4.7 satisfaction from 14,000+ frontline teachers (industry max 4.0); medical-imaging-cloud report generation crossed the practical threshold “for the first time in the industry”; legal “XiaoFa” covers the full case workflow with 45%+ efficiency gains. The same event brought speech foundation SparkAudio 1.0 (semi-supervised audio encoder, dynamic-segmentation end-to-end modeling, dual-paradigm co-decoding; +20% effect, -15% latency, -60% cost), robot brain platform V3.0, the Lingji N9000 AI PC (160 TOPS), and a 2240-TOPS Spark office appliance.

A parallel industry signal: domestic media reported that a Shenzhen Loop Area Institute team completed post-training of DeepSeek-V4-Pro on Huawei Ascend 910C — more evidence that domestic silicon is climbing from “supports inference” to “carries training,” pointing the same direction as X2.6.

Part Six: What the Three Things Really Mean — Security, Cost, Division of Labor

Read thinly, the event answers the two thresholds for scaled LLM deployment Liu named — privacy and token cost.

First, data sovereignty. End-cloud integration plus on-device redaction turns “what data may leave this device” into a policy the model judges in real time and the user confirms, rather than defaulting to full cloud upload. For regulated sectors — government, healthcare, law — this is an admission requirement, not a preference.

Second, unit economics. A 95.7% four-layer cache and the device absorbing 41.9%, later 60%, of tasks all push the same lever — processing ever more tokens at the cheapest tier. Cached price at roughly one-eleventh of cache-miss, and device inference whose marginal cost approaches electricity, is the real source of “extreme value,” not a headline price cut.

Third, and hardest, the depth of domestic compute. From inference-only, to post-training, to 4x long-context training efficiency on a 10,000-card Feixing-2 platform — the capability curve climbs “usable → trainable → good.” Calm caveats remain: self-reported benchmarks need third-party replication, the “first four-layer KVCache” details are not fully public, and 41.9% device coverage means nearly six in ten tasks still need the cloud.

Part Seven: Will End-Cloud Integration Become the Default Deployment Form?

For the past year LLM deployment has swung between two extremes: “all cloud” (strong but data leaves and cost scales linearly) and “all local” (private and cheap but bounded by device silicon). Spark X2.6 bets on the middle — a smart routing layer that decides where computation should happen and desensitizes before any cloud trip.

If the paradigm holds, the competitive focus may move beyond “how big is the cloud model” toward three new metrics: the on-device model’s independent task coverage, the routing accuracy, and the multi-level cache’s compression of unit cost. The 293-A30B sets the capability ceiling; the 4B device model and 96.1% routing set the deployment floor.

When a company holds training, inference, device, chips, hardware, and vertical applications in one stack, it is no longer telling a model story but a “sovereign compute paradigm” story. Whether that path is wider than chasing ever-larger cloud models depends on two things: whether the open-sourced 4B draws enough robot, automotive, and AI-PC developers, and whether the collaboration framework escapes iFlytek’s own ecosystem to become a third-party-validated de-facto standard. Parameters date; the principle of “putting the right computation in the right place” probably will not.

Sources: ZhiDongXi, The Paper, China Business Journal, Global Times, 36Kr, and other on-site reporting of the 2026 iFlytek 1024 Global Developer Festival (Beijing, 2026-10-22), plus iFlytek official release materials. Code is illustrative, not iFlytek’s; benchmark figures are vendor self-reports pending third-party replication.

本内容由 Coze AI 生成，请遵循相关法律法规及《人工智能生成合成内容标识办法》使用与传播。