
Spark3リーク:iFLYTEKの1.7Bおよび4B小規模モデルがvLLMに統合されつつある
- DeepSeekNEWDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.15 / $0.29 100万トークンあたり
- z-aiNEWZ.ai: GLM 5.32026-08-1860知能75コーディング
- obsidianNEWQwen3.8 27B2026-08-1552知能68コーディング
- qwenNEWQwen: Qwen3.8 27B (free)2026-08-13qwen/qwen3.8-27b-free
- deepseekNEWDeepSeek: DeepSeek V4 Pro 08132026-08-1253知能69コーディング
- grokNEWSpaceXAI: Grok 4.62026-08-1261知能77コーディング
- metaMeta: Muse Spark 1.22026-08-0557知能72コーディング
- qwenQwen: Qwen3.8 Max2026-08-0358知能72コーディング
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152知能69コーディング
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 100万トークンあたり
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463知能78コーディング
- googleGoogle: Gemini 3.6 Flash2026-07-2152知能69コーディング
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137知能49コーディング
- metaMeta: Muse Spark 1.12026-07-1653知能71コーディング
- kimiMoonshotAI: Kimi K32026-07-1560知能76コーディング
- openaiOpenAI: GPT-5.6 Luna2026-07-0952知能71コーディング
- openaiOpenAI: GPT-5.6 Terra2026-07-0957知能77コーディング
- openaiOpenAI: GPT-5.6 Sol2026-07-0961知能77コーディング
Spark3には公開されたウェイトもモデルカードもアナウンスもない——それにもかかわらず、今週、vLLM推論エンジンに、Spark3-1.7BとSpark3-4Bという2つのモデルを驚くほどの詳細さで記述したプルリクエストがマージされた。vLLMリポジトリのプルリクエスト#53373「[Model] Add Spark3 Model」は、Spark3アーキテクチャのネイティブサービングサポートを追加するものである。スライディングウィンドウアテンション、4段階の制御可能な思考予算、両サイズでのネイティブな100万トークンコンテキスト、そしてiFLYTEKを指すモデルIDが含まれている。そのどれもベンダーによって確認されておらず、何もリリースされていない。これは「現時点で判明していること」をまとめた記事である。プルリクエストは本物であり、モデルができるとされているすべてのことは、iFLYTEK——あるいはSpark3をリリースするであろう誰か——が実際にウェイトを公開するまでは未検証である。
リーク:仕様書のように読めるプルリクエスト
このシグナルは、合肥在住で中国科学技術大学に所属していると記載するGitHubコントリビューター、KnightYaoが提出したオープンなvLLM PRです。2026年8月23日時点ではまだマージされていません。vLLMのメンテナーは8月22日に「hold for discussions」という注記付きで変更を要求しました。このPRは初期段階であり、議論の対象となっていますが、これはこの種の統合では正常なことです。また、研究所の外では誰もダウンロードできないモデルに関するフレームワークのPRとしては、異例なほど詳細に書かれています。
この差分は8つのファイルに変更を加えます。vLLMのモデル実行器にSpark3ForCausalLMの実装、vLLMの設定レジストリとモデルレジストリに登録されるネイティブなSpark3Config、スライディングウィンドウアテンションとフルアテンションに加えてヘッド単位のアテンション出力ゲーティングのサポート、テンソル並列およびパイプライン並列の重み読み込み、そしてモデルのツール呼び出しを構造化された形でデコードできるようにするSpark3 XMLツールパーサーを追加します。また、vLLMのサポート対象モデルのドキュメントに、チェックポイントをXHToken/Spark3-1.7Bとして記載する行も追加されます。説明ではさらに、この統合はベンチマークが実施されたと主張しています。著者のテスト環境で、500の同時リクエスト、100%の成功率、毎秒約106リクエスト、毎秒13.5K出力トークンという結果です。これらの数値は、PRを書いた本人による自己申告であり、独立したベンチマークではありません。その点を正確に踏まえて読む必要があります。
iFLYTEKが明白な親会社である理由——ただし未確認
PRにはベンダーの名前は一切記載されていない。しかし、そこで登録されているチェックポイントID「XHToken/Spark3-1.7B」は、Hugging Face上のXHToken組織の配下にあり、その組織はiFLYTEKのものである。組織のページには企業として記載され、opensource.iflytek.comへのリンクがあり、現在公開モデルは0件、公開データセットも0件となっている。「XH」はiFLYTEKのモデルファミリーである星火 (Xinghuo, "Spark") の自然な略称だ。そこに投稿者の所在地である合肥(Hefei)—iFLYTEKは合肥に本社を置く—を加えれば、この推測はベンダーが確認する前に到達し得る最も強力な推測になる。
これはiFLYTEKの最近のパターンに当てはまる。同社が2026年2月にリリースしたSpark X2は、教育、医療、自動車、およびエージェントのユースケースを明確にターゲットにしており、オンデバイスモデルのSparkAuto-EMMシリーズは0.5Bから7Bまでの小型サイズで提供されている。このプレスリリースが表面化する2日前の8月21日、中間決算説明会でiFLYTEKは、完全に国産の計算基盤で構築された新しいフラッグシップ汎用モデルの登場を予告し、「8月末までに」段階的バージョンをリリース、10月の1024 Developer Dayで本格ローンチすると述べた。Spark3-1.7BとSpark3-4Bがその段階的リリースの一部なのか、それともエッジ特化の別トラックなのかは、プレスリリースが答えていない未解決の問いである。

モデルがあると言われているもの
そのPRの主張は、すべて未検証:
• 2つのサイズ。 Spark3-1.7BとSpark3-4B。どちらも、密なフルアテンション構造ではなくスライディングウィンドウアテンションを使用した、効率性優先の設計として説明されています。
• 両方でネイティブな100万トークンのコンテキスト。 拡張モードの約束ではない。PRによると、そのコンテキストはアーキテクチャにネイティブであり、単一GPUで妥当なほど小さいモデルに100万トークンを載せることになる。
• 4段階の思考予算。推論は、なし・低・中・高に設定できる切替可能な思考設計であり、アプリケーションが推論の深さとレイテンシ、呼び出しごとのコストをトレードオフできるようにします。
• 200以上の言語と中国の試験での強み。このプレスリリースは、K-12とGaokaoの問題解答性能が高いと主張しており、同社の教育事業を考慮すれば、これはiFLYTEKの特徴である。また、200以上の言語にわたる多言語対応も謳っている。
• コーディングおよびエージェント指向。 サイズの割に強力なコード生成、ツール使用、マルチステップ実行、長文脈推論を謳っており、同じPRに含まれるXMLツールパーサーによって裏付けられている。
1.7Bモデルでネイティブな1Mコンテキストを実現しているのが注目すべき点です
コンテキスト長は、小規模モデルが苦戦してきた分野です。現在のオープンウェイトの状況では、1.7B~4Bモデルは通常、32K~256Kのネイティブウィンドウを備えています。Qwen3の小さなチェックポイントはネイティブ32Kで、RoPEスケーリングにより131Kに対応しています。そして、Qwen3.5が小さなバリアントでネイティブ256Kを改善したのも最近の一歩です。100万トークンのコンテキストはこれまで、大規模モデルの機能でした。GLMの1Mコンテキストチェックポイントは数千億パラメータを擁しています。もしSpark3が本当に4Bモデルでネイティブ1Mウィンドウを実現するなら、それは真に異例なスペックであり、スライディングウィンドウ・アテンションアーキテクチャこそ、メモリコストを抑えるためのまさにその方法です。ただし、注意点も隣合わせにあります。ネイティブ1Mという宣伝文句はPRに書きやすく、実際に役立つものにするのは難しいのです。長いコンテキストの品質(モデルが実際に70万トークン前の事実を見つけ出して使えるかどうか)は、ウィンドウにどれだけのトークンが入るかという問題とは別であり、独立した評価はまだ存在しません。
制御可能な思考予算が重要な理由も同じです。4つの推論レベル(なし/低/中/高)は、Qwen3のオン/オフ思考モードの精神を受け継いだ切替式思考設計ですが、より豊かです。二値的な選択ではなく、アプリケーションはリクエストごとにレベルを選べます——翻訳には思考なし、マルチステップのエージェントターンには高レベル——そして必要な推論にだけコストを支払います。エージェント型やバッチのワークロードにとって、これはまさに「高性能だが高コスト」な小規模モデルをコスト管理可能なものへと変えるための調整弁なのです。
ポストトレーニングのレシピは2026年のパターンに合致する。
PRによると、Spark3は「Scaled Reinforcement Learning and MOPD」を用いてポストトレーニングされたという。MOPD — Multi-Teacher On-Policy Distillation — は実在する現在の手法であり、arXiv論文(2606.30406)に記載されている。すなわち、並列にドメイン特化のRL教師を訓練し、その教師たちを生徒自身のロールアウト上で1つの生徒に蒸留し、プロンプトごとに適切な教師に対するトークン単位の逆KLを最小化する。これは2026年のレシピであり、単一のモデルが、RL実行同士が互いに干渉し合うことなく、数学・コーディング・エージェントスキルを継承できるようにするものである。また、MiMo Flash V2、DeepSeek V4、Nemotron 3 Ultraなどのモデルのポストトレーニングにおいて、公にその功績が認められている。Spark3が同じレシピを引用していることは、同モデルをその世代—小規模モデルにフロンティアのポストトレーニング技術を用いる世代—に位置づける。また、そのことは、「強力なコーディングとエージェント機能に関する主張」には、もっともらしいメカニズムが背後にあることも意味する。もっともらしいことは実証されたことと同じではない。ウェイトが公開され、独立した評価が実施されるまで、その主張はベンダー報告の域を出ない。
真に未知なるものとは何か
カレンダーが付いているものはほとんどすべて:
• リリース日。 Hugging Faceにはウェイトがなく、アナウンスもなく、タイムラインもありません。XHToken orgは今日は空です。
• ベンダー確認。iFLYTEKはSpark3について何も発表していない。XHToken orgのリンクは有力な証拠だが、公式な声明ではない。
• 段階的フラッグシップなのかどうか。 iFLYTEKの新フラッグシップの「8月末」段階版はこれかもしれない——あるいは無関係かもしれない。プレスリリースには日付が一切記載されていない。
• 価格とライセンス。 何も開示されていません。iFLYTEKのSparkファミリーは、歴史的に見て、オープンウェイトではなく、主にAPI経由で提供されてきました。そのため、Spark3-1.7BとSpark3-4Bがオープンチェックポイントなのか、それとも内部のサービングターゲットなのかは未解決の疑問です。
• あらゆるベンチマーク。 PR内のスループット数値は著者自身のサービングテストであり、独立した評価ではありません。また、モデルが公開されていないため、リーダーボードで評価されたモデルはありません。

何を見るべきか
XHToken Hugging Face organizationは、注目すべきリリースチャネルです。もしそのモデルが本物なら、その重み(または少なくともモデルカード)がそこに現れるはずです。そして、そのorgが公開リポジトリをゼロから一つに増やすことが、最も重要なシグナルです。それが起こった瞬間に確認すべきいくつかの点:
• コンテキスト番号。1Mはネイティブなのか、それとも品質と引き換えにRoPE拡張されたものなのか?PRはネイティブと言っているが、決着がつくのはモデルカードだ。
• 思考予算API。4つの推論レベルがどのように公開されるか——サンプリングパラメータ、チャットテンプレートフィールド、または別のモデルバリアントとして——によって、実際の使いやすさが決まります。
• ライセンス。オープンウェイトであれば、Spark3はセルフホスト可能なネイティブ1Mコンテキストを備えた初の5B未満モデルになるでしょう。一方、API限定のローンチであれば、それは別の種類の製品になるでしょう。
• iFLYTEKの発表カレンダー。段階的なフラッグシップは8月末までに約束されており、正式ローンチは10月の1024 Developer Dayに行われる。Spark3がどちらかに含まれる場合、公式の説明はプレスリリースが未確定のままにしている点を明言するだろう。
• PRがマージされるかどうか。vLLMサポートは、品質シグナルとしてもインフラとしても重要です。ネイティブSpark3サポートを備えた最初のランタイムにより、重みが公開されたその日にモデルを本番環境で実行可能になります。
今、開発者がすべきこと
何もない。呼び出すモデルも、ダウンロードする重みも、プロビジョニングするAPIキーも存在しない。今日Spark3を提供すると主張するツールは、何か別のものを提供しているにすぎない。あなたにできるのは、それが登場した日にどのように評価するかを決めておくことだ。なぜなら、これは非常に検証可能な約束を持つモデルだからだ。100万トークンを読み、4つの深さで推論する1.7Bまたは4Bのモデルは、真に新しい小型モデルのカテゴリか、スペックシート上の物語かのどちらかであり、その違いは自分のワークロードを使えば午後ひとつで測定できる。
そこがまさに、ルーティング層が存在価値を発揮する場面です。OrcaRouterでは、モデルはコミットすべき契約ではなく、単一のAPIを通じて呼び出すカタログの1エントリにすぎません。プロバイダーの定価はゼロマークアップでそのまま透過されるため、新しいモデルがプロバイダーのカタログに登場したその日に、実際の価格が当社側でも反映されます。試すのに追加の統合も再交渉も不要です。Spark3のように実績のないモデルに対して賢明なパターンは、有望なリークに対して使うのと同じものです。ルーティングDSL内で自動フェイルオーバーの背後に置き、トラフィックの一部にそれを当て、ルールの反対側には実証済みのモデルを残します。そうすれば、悪い評価やライセンスの想定外、期待外れのロングコンテキスト結果も、インシデントではなくルーティング変更で対応できます。ワンキー、ワンエンドポイント、200+モデル。そしてSpark3-1.7BやSpark3-4Bが実際に実行可能になったとき、パススルーとフェイルオーバーは他のどのモデルと同様にそれにも適用されます。
![A screenshot of vLLM pull request 53373 titled '[Model] Add Spark3 Model' on GitHub (captured August 23, 2026) showing the open PR status, the author KnightYao, the 'new-model' label, the reviewers including youkaichao, and the description 'This PR adds native support for the Spark 3 model architecture'.](https://cms.orcarouter.ai/api/media/file/4-438.png)
正直な要約は、判決ではなく一文だ。今週書かれたフレームワークPRは、iFLYTEKがネイティブの百万トークンコンテキストと4段階の思考予算を持つ2つの小規模モデルを備えていると主張しているが、それを裏付ける証拠の重みは一切公開されていない。XHToken組織に注目し、iFLYTEKの8月末の約束にも注目せよ。そして、重みが本物になったなら、本番パスをそれらに賭ける前に、フェイルオーバー付きのルーティングルールに通せ。それがリークに対するすべてのプレイブックだ——インフラを信じ、モデルを検証し、出口は安く保て。
