Spark3 Leak: iFLYTEK's 1.7B and 4B Small Models Are Being Wired Into vLLM

Spark3 has no public weights, no model card, no announcement — and yet a pull request landed this week in the vLLM inference engine describing two models, Spark3-1.7B and Spark3-4B, in remarkable detail. Pull request #53373 in the vLLM repository, "[Model] Add Spark3 Model," adds native serving support for the Spark3 architecture: sliding-window attention, a controllable thinking budget with four levels, native million-token context on both sizes, and a model ID that points at iFLYTEK. None of that is confirmed by the vendor, and nothing has shipped. This is a what-we-know-so-far piece: the pull request is real, and everything the models are said to do is unverified until iFLYTEK — or whoever ships Spark3 — actually publishes weights.

The leak: a pull request that reads like a spec sheet

The signal is an open vLLM PR, submitted by a GitHub user called KnightYao (a contributor based in Hefei who lists the University of Science and Technology of China), and as of August 23, 2026 it has not been merged. A vLLM maintainer requested changes on August 22 with the note "hold for discussions." The PR is early and contested, which is normal for this kind of integration — and it is also unusually detailed for a framework PR about a model nobody outside the lab can download.

The diff touches eight files. It adds a Spark3ForCausalLM implementation in vLLM's model executor, a native Spark3Config registered in vLLM's config and model registries, support for sliding-window attention and full attention plus head-wise attention-output gating, tensor- and pipeline-parallel weight loading, and a Spark3 XML tool parser so the model's tool calls can be decoded in a structured way. It also adds a row to vLLM's supported-models documentation listing the checkpoint as XHToken/Spark3-1.7B. The description even claims the integration was benchmarked: 500 concurrent requests, 100% success, roughly 106 requests per second and 13.5K output tokens per second on the author's test setup. Those numbers are self-reported by the person who wrote the PR, not an independent benchmark, and they should be read exactly that way.

Why iFLYTEK is the obvious — but unconfirmed — parent

Nothing in the PR names the vendor. But the checkpoint ID it registers, XHToken/Spark3-1.7B, sits under the XHToken organization on Hugging Face, and that organization is iFLYTEK's: the org's page lists it as a company, links to opensource.iflytek.com, and currently shows zero public models and zero public datasets. "XH" is the natural shorthand for 星火 (Xinghuo, "Spark"), iFLYTEK's model family. Add the author's Hefei location — iFLYTEK is headquartered in Hefei — and the inference is about as strong as an inference gets before the vendor confirms it.

It fits iFLYTEK's recent pattern. The company's Spark X2, released in February 2026, was explicitly aimed at education, medical, automotive, and agent use cases, and its SparkAuto-EMM line of on-device models ships in small sizes from 0.5B up to 7B. Two days before this PR surfaced, at its interim results conference on August 21, iFLYTEK said a new flagship general-purpose model built entirely on domestic compute was coming, with a phased version due "by the end of August" and a full launch at its 1024 Developer Day in October. Whether Spark3-1.7B and Spark3-4B are part of that phased release, or a separate edge-focused track, is an open question the PR does not answer.

What the models are said to be

The PR's claims, all unverified:

• Two sizes. Spark3-1.7B and Spark3-4B. Both are described as efficiency-first designs using sliding-window attention rather than a dense full-attention layout.

• Native 1M-token context on both. Not an extended-mode promise — the PR says the context is native to the architecture, which would put a million tokens on a model small enough to be plausible on a single GPU.

• A four-level thinking budget. Reasoning can be set to none, low, medium, or high, a switchable-thinking design that lets an application trade reasoning depth against latency and cost per call.

• 200+ languages and Chinese-exam strength. The PR claims strong K-12 and Gaokao question-answering performance — an iFLYTEK signature, given the company's education business — and multilingual coverage across 200+ languages.

• Coding and agent orientation. Claims of strong code generation, tool use, multi-step execution, and long-context reasoning for its size, backed by the XML tool parser included in the same PR.

Native 1M context on a 1.7B is the part worth noticing

Context length is where small models have been stuck. In the current open-weight landscape, a 1.7B–4B model typically ships with a 32K–256K native window: Qwe​n3's small checkpoints are 32K native with 131K via rope scaling, and even Qwen3.5's improved native 256K on small variants is a recent step. Million-token context has so far been a big-model feature — G​LM's 1M-context checkpoints are hundreds of billions of parameters. If Spark3 really does deliver a native 1M window on a 4B model, it would be a genuinely unusual spec, and the sliding-window attention architecture is precisely how you make that cheap on memory. The caveat that has to sit next to it: a native 1M headline number is easy to write in a PR and hard to make useful in practice. Long-context quality — can the model actually find and use a fact 700K tokens back — is a separate question from how many tokens fit in the window, and no independent evaluation exists yet.

The controllable thinking budget matters for the same reason. Four reasoning levels (none / low / medium / high) are a switchable-thinking design in the spirit of Qwe​n3's on/off thinking mode, but richer: instead of a binary choice, an application can pick a level per request — no thinking for a translation, high for a multi-step agent turn — and pay only for the reasoning it needs. For an agentic or batch workload that is exactly the knob that turns a "capable but expensive" small model into a cost-managed one.

The post-training recipe fits a 2026 pattern

The PR says Spark3 was post-trained with "Scaled Reinforcement Learning and MOPD." MOPD — Multi-Teacher On-Policy Distillation — is a real and current technique, described in an arXiv paper (2606.30406): train parallel domain-specialist RL teachers, then distill them back into one student on the student's own rollouts, minimizing per-token reverse KL against the right teacher per prompt. It is the 2026 recipe that lets a single model inherit math, coding, and agent skills without one RL run fighting another, and it has been publicly credited in the post-training of models like MiMo Flash V2, DeepSeek V4, and Nemotron 3 Ultra. Spark3 citing the same recipe places it in that generation — small models, frontier post-training techniques. It also means the "strong coding and agent claims" have a plausible mechanism behind them. Plausible is not the same as shown: the claims remain vendor-reported until weights appear and independent evals run.

What is genuinely unknown

Almost everything with a calendar on it:

• Release date. No weights on Hugging Face, no announcement, no timeline. The XHToken org is empty today.

• Vendor confirmation. iFLYTEK has said nothing about Spark3. The XHToken org link is strong evidence, not an official statement.

• Whether it is the phased flagship. iFLYTEK's "end of August" phased version of its new flagship could be this — or unrelated. The PR gives no dates at all.

• Pricing and license. Nothing is disclosed. iFLYTEK's Spark family has historically been mostly API-served rather than open-weights, so whether Spark3-1.7B and Spark3-4B are open checkpoints or an internal serving target is an open question.

• Every benchmark. The throughput figures in the PR are the author's own serving test, not an independent evaluation, and no leaderboard has scored the model because no model exists publicly.

What to watch

The XHToken Hugging Face organization is the release channel to watch. If the model is real, its weights — or at least a model card — should appear there, and the org going from zero to one public repo is the signal that matters most. A few things to check the moment it does:

• The context number. Is 1M native, or rope-extended with a quality trade-off? The PR says native; model cards are where that gets settled.

• The thinking-budget API. How the four reasoning levels are exposed — as a sampling parameter, a chat-template field, or a separate model variant — determines how easy it is to actually use.

• The license. Open weights would make Spark3 the first sub-5B model with native 1M context available to self-host; an API-only launch would make it a different kind of product.

• iFLYTEK's announcement calendar. The phased flagship is promised by end of August and the full launch at the October 1024 Developer Day. If Spark3 is part of either, the official description will say what the PR leaves open.

• Whether the PR merges. vLLM support matters as a quality signal and as infrastructure: the first runtime with native Spark3 support makes the model runnable in production the day weights land.

What a developer should do right now

Nothing. There is no model to call, no weights to download, no API key to provision — any tool that claims to serve Spark3 today is serving something else. What you can do is decide how you will evaluate it the day it appears, because this is a model with a very checkable promise: a 1.7B or 4B that reads a million tokens and reasons at four depths is either a genuinely new small-model category or a spec-sheet story, and the difference is measurable in an afternoon on your own workload.

That is also where a routing layer earns its keep. On OrcaRouter, a model is not a contract you commit to; it is an entry in a catalog you call through one API, and provider list prices are passed through at zero markup — so when a new model appears in a provider catalog, its real price is live on our side the same day, and trying it costs no second integration and no renegotiation. For a model as unproven as Spark3, the sane pattern is the same one you would use for any promising leak: put it behind automatic failover in the routing DSL, let a share of traffic hit it, and keep a proven model on the other side of the rule so a bad eval, a license surprise, or a disappointing long-context result is a routing change rather than an incident. One key, one endpoint, 200+ models — and when Spark3-1.7B or Spark3-4B is actually runnable, the pass-through and the failover apply to it like any other model.

The honest summary is a sentence, not a verdict: a framework PR written this week claims iFLYTEK has two small models with native million-token context and a four-level thinking budget, and no weight of evidence has been published to back any of it. Watch the XHToken org, watch iFLYTEK's end-of-August promise, and when the weights are real, put them through a routing rule with a failover before you bet a production path on them. That is the whole playbook for a leak — believe the infrastructure, verify the model, and keep the exit cheap.