Deepseekが85%高速化の裏側：大規模モデルがパラメータ競争を脱し、コスト戦へ

2026年6月27日、『DSpark：半自己回帰生成に基づく信頼度スケジューリング投機的デコード』と題する論文が業界の注目を集めた。この論文はDeepSeek創業者の梁文鋒氏が署名し、北京大学と共同で完成させたものだ。論文では、DSparkをDeepSeek-V4のオンラインサービスシステムに導入し実ユーザートラフィックを処理させた際、単一ユーザーの生成速度が60％〜85％（Flash版）および57％〜78％（Pro版）と大幅に向上したという注目すべきデータが明かされた。オフラインや高同時接続のシナリオでは、集約スループットが51％から400％も向上したという。

このデータは、単純なハードウェア追加による線形的な伸びではなく、推論アーキテクチャの根本的な質的変化を示している。この数字の持つ価値を理解するには、まず大規模モデルの推論プロセスに潜む計算力のブラックホールを見極めなければならない。

85％高速化の真相：「無効検証」に食われる計算力

現在主流の大規模モデルの多くは、自己回帰生成メカニズムを採用している。簡単に言えば、モデルがテキストを生成する際は、一文字ずつ順に吐き出していく。一文字生成するたびに、モデルはそれまでの全コンテキストを再処理し、次の文字の確率分布を計算する。この逐次的な生成方式のため、GPUの並列計算能力は大幅に遊休してしまう。より重要なのは、大規模モデルの推論が通常「メモリ律速」である点だ。

ハードウェアレベルでこのメモリ律速のボトルネックが最も顕著に現れるのが、KVキャッシュの読み書きである。過去のコンテキストを再計算しないようにするため、モデルは前ステップまでに生成された隠れ状態をKeyとValueの形式でビデオメモリに保存する。シーケンス長が伸びるにつれて、KVキャッシュのサイズは線形的に増大する。新しいトークンが一語生成されるたびに、GPUの演算ユニットは巨大なKVキャッシュがビデオメモリから演算コアへ運ばれるのを待たなければならない。すなわち、GPUは大半の時間を行列乗算ではなく、データ待ちに費やしていることになる。演算ユニットの空転と、ビデオメモリの反復的な読み書きによる帯域圧迫が、大規模モデル推論の最も底層にあるコストのブラックホールを形作っている。

この逐次的なボトルネックを打破するため、業界では投機的デコード技術が導入されている。基本的な考え方は、より小型で高速なドラフトモデルを導入し、次に生成されそうな数語をまず推測させ、その後、ターゲットとなる大規模モデルがそれらの草稿をバッチ検証する、というものだ。ドラフトの推測が正しければ、大規模モデルは一度に複数語を確定でき大幅に高速化する。外れていれば、大規模モデルはゼロからやり直す。

しかし従来の投機的デコードは、高速化と同時に新たな計算力の浪費を生み出していた。初期の並列ドラフト手法（Medusaなど）や自己回帰ドラフト手法（Eagle3など）は、往々にして闇雲に推測する戦略をとっていた。並列ドラフトを例にとると、ドラフトモデルが同一時点で次に来る可能性のある複数の語を並列に推測するが、語と語の間の前後依存関係が無視されていた。一方、自己回帰ドラフトは依存関係を考慮し、ドラフトモデル自身がまず長いシーケンスを生成するものの、シーケンスが長くなるにつれてドラフトモデルが外す確率は指数関数的に上昇する。

ターゲットの大規模モデルがこれらの長いドラフトを検証する際に、問題が露呈する。大規模モデルは、先頭の数語は合っているが、後続の大半が誤りであることを検出する。従来の検証メカニズムでは、大規模モデルはドラフトの全体に対して完全な順伝播計算を行わなければならない。この計算過程で、モデルは自身の膨大なパラメータ重みをロードするだけでなく、ドラフトによって生じた余分なKVキャッシュも処理しなければならない。これは、破棄されることが運命づけられた無駄な原稿を添削するために、大量のGPU演算力とビデオメモリ帯域を消費していることを意味する。この「無効検証」は、低同時接続時には目立たないかもしれないが、DeepSeek-V4の実トラフィックのような高負荷下では計算力の浪費が急激に拡大され、実際の応答速度を低下させるだけでなく、ただでさえ高い推論コストに拍車をかける。DSparkの登場は、この食われていた計算力を取り戻すためなのだ。

インターンと指導教官：DSparkはいかにして投機的デコードを「闇雲」でなくすか

DSparkのコアとなる技術メカニズムは、半自己回帰生成と信頼度スケジューリング投機的デコードに要約できる。このふたつの難解な学術用語の本質は、ドラフトモデルとターゲットモデルの協調関係を再構築し、GPUのビデオメモリ読み書きと計算スケジューリングのロジックを根本から変えたことにある。

このプロセスは、身近なたとえで理解できる。ターゲットの大規模モデルを厳格な指導教官、ドラフトモデルを反応だけは速いインターンだとしよう。従来の投機的デコードでは、指導教官はインターンに、これから書くべき10の文を闇雲に推測させる。インターンは書くのは速いが、往々にして5文目あたりから脱線し始める。指導教官がそれを見ると、最初の4文は使えるが、後の6文は全て没だ。教官がこの没になった6文を添削するために費やした労力が、まさに浪費された計算力である。

DSparkの半自己回帰生成メカニズムは、インターンに前後の文脈を考慮できる補助的な頭脳を与えたようなものだ。インターンは推測する際、もはや文脈を完全に無視した闇雲な発散はせず、すでに生成された内容に基づいてある程度の自己修正を行える。技術的実装で言えば、ドラフトモデルが複数の候補語を生成する際、前のステップの隠れ状態を利用して次のステップの生成を誘導することを意味し、これにより長いドラフトの命中率を高め、末尾の内容が受け入れられなくなる減衰問題を緩和する。

より重要な革新は、信頼度スケジューリングだ。DSparkのフレームワークでは、インターンはドラフトを提出する際に、各部分に対し自身の推測の確度を示す信頼度スコアを付与する。指導教官は添削時に、このスコアに応じて動的にスケジューリングを行う。

具体的なアルゴリズムロジックでは、ドラフトモデルの出力層は、語彙上の確率分布に加えて、その予測語に対する信頼度を表す追加のスカラー値も出力する。DSparkは動的しきい値メカニズムを設定し、ドラフトシーケンスを分割する。あるドラフト区間の信頼度が連続してしきい値を上回っていれば、システムはそれが高い確率で正しいと判断し、高優先度に分類する。信頼度がしきい値を下回れば、システムはそれ以降のドラフトが誤っている可能性が極めて高いと見なす。

GPUの底層の計算ロジックにおいて、このスケジューリングは従来の「十把一絡げ」なバッチ検証モデルを変革する。インターンの高信頼度（おそらく正しい）部分に対して、教官は高優先度の計算ストリームに割り当て、集中的に迅速な添削を行う。低信頼度の部分に対しては、教官は直接破棄するか、あるいは低優先度の計算ストリームに入れて検証リソースの投入を減らす。これにより、ターゲットモデルが確実に誤る無駄な原稿で貴重なビデオメモリ帯域と計算サイクルを浪費する事態を回避する。

このメカニズムにより、DSparkは無効検証によって生じる計算力の浪費を効果的に削減する。智東西などのメディアによると、Qwen3シリーズモデルにおいて、DSparkの平均受理長は前世代Eagle3より26.7％〜30.9％、DFlashより16.3％〜18.4％向上したという。これは、同じ時間内にターゲット大規模モデルがより多くの正しいドラフトを採用でき、生成速度が自然に上昇したことを意味する。この最適化は、ハードウェアへの追加投資を一切行わず、純粋にスケジューリングアルゴリズムの改良によって計算力を引き出している。

計算力の帳簿：なぜ無駄を減らすことが単なるカード増設より重要なのか

エンジニアリングの観点から見れば、DSparkは見事なアルゴリズム最適化である。しかしビジネスの観点から見れば、これは大規模モデル企業が過酷なコスト競争の中で生き残るためのサバイバルガイドである。

大規模モデル業界の財務モデルは、推論コストに極めて敏感だ。OmniToolsが以前に行ったOpenAIのリーク帳簿分析では、衝撃的なコスト構造が明らかになった：年収130億ドルながら、運営損失は209億ドルに達する。このキャッシュを燃やして規模を追う手法の背景には、高額な訓練コストだけでなく、さらに継続的に出血を強いられる推論計算力の消費がある。大規模モデルの訓練コストは莫大だが、通常は一時的または段階的な設備投資である。一方、推論コストは運営コストであり、ユーザーがAPIを呼び出すたび、モデルが回答を生成するたびに、GPUの計算力、電力、減価償却費として実質的なコストが消費されているのである。

一度の典型的なAPI呼び出しにおけるコスト構造を具体的に試算してみよう。ユーザーが1000語のプロンプトを入力し、モデルに1000語の回答を生成させるケースを想定する。従来の自己回帰モデルでは、Prefill段階で1000の入力語を処理し、その後Decode段階で1000回の逐次生成を行う。毎回の生成で、膨大なモデル重みをロードし、増え続けるKVキャッシュを読み書きする必要がある。典型的な数千億パラメータモデルでは、Decodeの1ステップの計算は数ミリ秒で済むかもしれないが、データの転送には数十ミリ秒かかる可能性がある。

従来の闇雲な投機的デコードを採用した場合、ドラフトモデルが200語を素早く生成しても、ターゲットモデルが検証してみると先頭の50語のみが正しく、後ろの150語は全て誤っていることが判明する。すると、後ろの150語を処理するために、ターゲットモデルが動かしたGPU演算ユニット、占有したビデオメモリ帯域、消費した電力は、すべてサンクコストと化す。日に数千万回のAPI呼び出しがあると、この無効検証が積み重ねる計算力の浪費は、企業の四半期財務諸表に直接反映され、利益を食い潰す底なし沼となるのに十分だ。

ユーザー数が急増したとき、推論効率が低ければ、企業に残された道はふたつしかない。ユーザーのアクセスを制限するか、クレジットカードを切りまくってGPUを買い増すかだ。前者は市場シェアを失い、後者はキャッシュフローを圧迫する。資本が次第に理性的になりつつある現在、無限の資金調達で計算力の穴を埋めるモデルは、もはや維持が難しい。さらに致命的なことに、モデルのパラメータ規模が増大しコンテキスト長が拡張されるにつれ、一回の推論で消費される計算力は指数関数的に上昇する。無効検証などの計算力浪費を放置すれば、大規模モデル企業の赤字幅はユーザー規模の拡大に伴い際限なく拡大してしまうだろう。

DSparkが代表する推論最適化のアプローチは、第三の解法を示している。無効検証の計算力浪費を減らすことで、DeepSeek-V4はハードウェアクラスタを追加することなく、高同時接続シナリオでの集約スループットを最大400％向上させた。これは、同じサーバー群で、従来の何倍ものユーザーリクエストをさばけることを意味する。

大規模モデル企業にとって、この種のエンジニアリング最適化の価値は、単に計算力を積み上げるよりもはるかに大きい。GPUの増設は、コストの線形的な増加と生産能力の線形的な増加をもたらすもので、カードを1枚追加するごとに、調達コスト、運用コスト、エネルギー消費圧力が1枚分加算される。一方、アルゴリズムレベルでの効率向上は、固定費のまま生産能力を指数関数的に引き上げる飛躍を意味する。業界が価格競争の段階に入ったとき、1回のAPI呼び出しにおける計算コストを抑えられる者が、粗利率を確保しつつ、より強力な価格を打ち出せる。DSparkはモデルを高速化しただけでなく、大規模モデルの商業的クローズドループをより健全なものにし、薄利時代を生き抜く企業に自信を与えているのだ。

オープンソースDeepSpec：中小チームに武器を届ける

DSparkの論文を公開すると同時に、DeepSeekはDeepSpecフレームワークもオープンソース化しました。公式GitHubによると、DeepSpecはMITライセンスでオープンソース化されており、DSpark、DFlash、Eagle3などの投機的デコードアルゴリズムモジュールを含み、Qwen3やGemmaなどの主要なオープンソースモデルと互換性があります。

これは業界が高い関心を払うべき動きである。現在のAIエコシステムにおいて、OpenAIやAnthropicといったクローズドソースの巨人たちも、その基盤部分では投機的デコーディングや類似の推論高速化アーキテクチャを採用しているが、こうしたフルスタックの推論最適化ツールチェーンをオープンソース化することはほとんどない。中小のAIスタートアップチームが、自社のファインチューニングモデル用に効率的な下書きモデル（ドラフトモデル）を訓練しようとすると、多くの場合、車輪をゼロから再発明しなければならない。

A100 GPUを数枚しか持たないスタートアップチームのリアルな状況を想像してみよう。彼らは垂直領域に特化したモデルをファインチューニングしたかもしれないが、いざデプロイしてみると生成速度が極めて遅く、ユーザー体験は非常に劣悪だった。仮に投機的デコーディングを自力で導入しようとすれば、CUDAオペレーターの開発、KVキャッシュのメモリ管理の理解、さらには下書きモデルの訓練プロセスそのものの設計まで必要となる。これは高い人件費を意味するだけでなく、長い試行錯誤の期間も覚悟しなければならない。多くの中小チームはまさにこの段階で資金が尽きてしまう。

DeepSpecのオープンソース化は、最先端の推論最適化という武器を業界全体に直接手渡すものだ。具体的なフレームワーク設計において、DeepSpecは高度にモジュール化されたインターフェースを提供している。開発者は推論エンジンを低レベルから書き直す必要はなく、設定ファイルでメインモデルのパスと下書きモデルのパスを指定するだけで、下書き生成、信頼度算出、ターゲットモデル検証という一連のプロセスをフレームワークが自動的に引き継いでくれる。

独自の下書きモデルを訓練したいチーム向けに、DeepSpecは標準化されたデータ蒸留モジュールを提供している。これにより、ターゲットとなる大規模モデルの隠れ状態を蒸留し、下書きモデルに学習させることが可能になり、データ準備のハードルを大幅に下げられる。開発者は、半自己回帰型の下書きモデルをどう構築するか自ら模索する必要もなく、信頼度スケジューリングのパラメータを何度も調整する必要もない。DeepSpecが提供する標準化されたツールチェーンを通じて、中小チームはドキュメントに従ってパラメータを設定するだけで、自社モデルに投機的デコーディング機能を接続し、生成速度が大幅に向上する恩恵を享受できるようになる。

このオープンソース戦略は、業界全体の技術の反復を加速させるだけでなく、クローズドソースの巨人たちが持つ推論効率における「堀」をある程度埋めることにもつながる。最先端のエンジニアリング最適化能力が業界の公共インフラとなった場合、大規模モデル競争の焦点は、より上位のアプリケーションイノベーションと、より下層のデータ品質へと必然的に移行せざるを得なくなる。

主戦場の移行：モデルの外はすべてHarness（ハーネス）

DSparkの公開とDeepSeek-V4への実装成功は、不可逆的な業界トレンドを裏付けている。すなわち、大規模モデル競争の主戦場はすでに移行したのである。

OmniToolsが『モデルの外はすべてHarness：DeepSeek参戦、中国AI競争の主戦場はなぜ変わったのか？』で指摘したように、各社の基盤モデルのパラメータ規模が数千億レベルに達し、各種ベンチマークテストでの性能が均質化する傾向にある現在、単にパラメータを競うだけでは差別化できなくなっている。AI製品の成否とコストを決めるのは、モデルの外側にあるツールチェーン、推論スケジューリングアーキテクチャ、APIルーティングといったシステムレベルのエンジニアリング能力、いわゆる「Harness（ハーネス）」なのである。

低レイヤーのエンジニアリングに詳しくない人にとって、「Harness」という言葉はやや抽象的に感じられるかもしれない。ソフトウェアエンジニアリングにおいて、Harnessは通常「テストハーネス」や「フレームワーク」を指すが、大規模モデルの文脈では、基盤モデルの周囲を取り巻くシステムエンジニアリングインフラの一式全体を指す。これには、ユーザーリクエストを管理するAPIルーティング分配システム、生成を高速化する推論スケジューリングアーキテクチャ（投機的デコーディングやKVキャッシュ管理など）、モデルが外部ツールやインターネット検索を呼び出すためのツールチェーン、高可用性を保証する災害復旧・監視システムなどが含まれるが、これらに限定されない。基盤モデルはエンジンに例えられるならば、Harnessはシャーシ、トランスミッション、ドライブシャフトだ。エンジンがどれほど強力でも、Harnessが貧弱であれば、その動力は車輪に伝わらない。

DSparkはまさに、このHarnessレベルでの典型的な競争の一手である。DeepSeek-V4の基盤パラメータを変更せず、モデルの知能を向上させるわけではないが、究極のエンジニアリング最適化によって、実際のトラフィック下における計算リソースの浪費問題を解決し、ユーザー体験（応答速度）と企業の財務モデル（推論コスト）を直接的に改善する。今後の大規模モデル競争は、このような目に見えないシステムレベルのエンジニアリング競争として顕在化する割合がますます増えるだろう。よりスマートな推論スケジューリング、より効率的なKVキャッシュ管理、より高い投機的デコーディングの命中率を実現した者が、同じ計算リソースの備蓄でより多くのアウトプットを叩き出せる。この「パラメータ競争の消耗戦」から「エンジニアリング実装競争」への転換は、企業に対し、アルゴリズムだけでなく、システム、ハードウェア、リアルなトラフィック特性を深く理解することを要求している。

限界と境界：DSparkは万能薬ではない

DSparkは長文テキスト生成や高並行処理のシナリオにおいて驚くべき最適化効果を示しているが、大規模モデル推論の問題を解決する万能薬ではない。あらゆる技術ソリューションには適用可能な境界があり、DSparkも例外ではない。

第一に、極めて高いストレージのハードルがある。DSparkの論文で開示されたデータによると、中規模モデル（Qwen3-4Bなど）に適応する下書きモデルを訓練するために必要なターゲットキャッシュの容量は38TBにも達する。この数字は、巨大な計算クラスタを持つ大手企業にとっては通常の構成に過ぎないかもしれないが、リソースの限られた中小チームにとって、38TBの高速ストレージアクセスは、それ自体が乗り越えがたいハードルである。これは、DeepSpecがコードをオープンソース化したとはいえ、中小チームがDSparkレベルの最適化を完全に再現しデプロイするには、依然としてハードウェアリソースという現実的な障壁を克服しなければならないことを意味する。ストレージコストとI/Oのボトルネックは、この技術の全面的な普及を阻む現実的なギャップとなる可能性がある。

第二に、最適化対象となる段階の限界である。大規模モデルの推論は通常、プリフィル（事前入力）とデコード（復号）の二段階に分けられる。プリフィル段階は、モデルがユーザー入力のプロンプトを読み取り、最初の単語を生成するプロセスであり、この段階は計算集約型で、GPUの計算能力が十分に活用される。一方、デコード段階は、その後に続く逐次的な単語生成プロセスであり、メモリアクセス集約型で、投機的デコーディングが主に効果を発揮する段階でもある。DSparkは主にこのデコードプロセスを対象としている。ユーザーにとって極めて重要なファーストトークン遅延（すなわちプリフィル段階）に対しては、DSparkの最適化効果は相対的に限定的である。短いテキストのインタラクションシナリオ（単純な質疑応答や命令実行など）では、生成されるコンテンツ自体が少ないため、投機的デコーディングが発揮できる加速余地は圧縮され、DSparkの速度優位性は顕著に現れない可能性がある。

最後に、異種計算リソースへの適応問題がある。現在、DSparkのオンライン検証は主にDeepSeek-V4の特定のサービスアーキテクチャに基づいており、Nvidia以外のハードウェア（各種国産計算チップなど）における適応状況や実際の加速比については、公開されたテストデータが不足している。異なるハードウェアアーキテクチャでは、メモリ帯域幅や計算ユニットのスケジューリングロジックが異なり、信頼度スケジューリング戦略を再調整する必要があるかどうかも、依然として解決すべきエンジニアリング上の課題である。

技術最適化に銀の弾丸は存在しない。DSparkは、アルゴリズムスケジューリングによって計算リソースの浪費を排除するという大きな可能性を証明し、大規模モデル業界がコスト競争に打ち勝つための鋭い武器を提供した。しかし実際の実装において、開発者は依然として、自身のビジネスシナリオ、ハードウェアの備蓄、遅延への感度に応じて、このソリューションのROI（投資対効果）を理性的に評価する必要がある。大規模モデルのエンジニアリングへの道のりは、まさに深水区に入ったばかりである。