speculative decoding / EAGLE / DFlash

なぜ「一語ずつ」は遅いのか

第15章で見たように、1トークンずつ書くdecodeの段階では、GPUは計算よりも「重みをメモリから読み出すこと」に時間を使っています。1トークン分の計算でも、5トークン分の計算でも、読み出す重みの量はほとんど同じです。

つまり、もし「次の5トークンはたぶんこれ」という候補が手元にあれば、大きなモデルは1回の計算で5個まとめて「合っているか」を確かめられます。かかる時間は1トークンを書くのとあまり変わりません。これが投機的デコーディングの出発点です。

投機的デコーディングの基本

sequenceDiagram
  participant D as 下書きモデル
  participant T as 本命モデル
  D->>T: 候補「今日は 晴れ で 暑い」
  T->>T: 4語を1回でまとめて検証
  T-->>D: 「今日は 晴れ」まで採用
  T-->>D: 3語目は「の」に差し替え
  D->>T: 「の」の続きを再び下書き

この方法は2022〜2023年に、Google の Leviathan らと DeepMind の Chen らがほぼ同時に発表しました。肝心なのは、受理・却下の判定に特別な確率的手続き（修正版の棄却サンプリング）を使うことで、本命モデルが単独で生成した場合と同じ確率分布から出力が得られる点です。品質を犠牲にする近似ではなく、「同じ答えを速く出す」技術です。

Leviathan らは T5-XXL で2〜3倍、Chen らは70Bの Chinchilla で2〜2.5倍の高速化を報告しています。どちらもモデルの再学習や構造の変更は不要でした。

当たり率で速さが決まる：シミュレーターで確かめる

速さを左右するのは、下書きのトークンが採用される確率、受理率 α です。各トークンが独立に確率 α で当たると仮定すると、1回の検証で確定するトークン数の期待値は (1 − α^(k+1)) / (1 − α) になります（kは下書きの長さ）。

初期状態（α = 0.7、k = 4）では「検証1回あたり約2.77トークン」と表示されます。普通の生成なら1回で1トークンなので、検証の回数は約3分の1で済む計算です。「検証を10回シミュレート」を押すと、✓（採用）が続いたあと ✗（却下）で止まり、+1（本命が足す1トークン）が付く様子を見られます。全部当たった場合も、本命がおまけの1トークンを足せます。

α を0.9に上げると約4.10トークン、0.5に下げると約1.94トークンになります。k を伸ばすと伸びしろは増えますが、α が低いと後ろのほうはほぼ外れるので効果が頭打ちになります。しかも実際には下書きを書く時間もかかるので、表示はあくまで理想値です。「よく当たる下書きを、いかに安く作るか」——以下の方式は、すべてこの問いへの答えです。

下書きの作り方いろいろ

プロンプトルックアップ（prompt lookup decoding）は、下書きモデルの代わりに「直前の数語と同じ並びが入力文のどこかにないか」を探し、その続きを候補にするだけの方法です。要約・文書QA・コード編集のように入力の一部をそのまま書き写す場面では、作者のリポジトリで2〜4倍の高速化が報告されています。vLLMでは ngram、Hugging Face Transformers では prompt_lookup_num_tokens で使えます。

Medusa（2024年）は、本命モデルの最終層の上に「2つ先」「3つ先」……を予測するヘッドを追加し、それぞれの上位候補を組み合わせた木を木構造の注意（tree attention）で一度に検証します。本命を凍結してヘッドだけを学習する Medusa-1 で、品質を落とさず2.2倍以上の高速化と報告されています。

EAGLE：本命の「頭の中」を読む下書き係

EAGLE は Li らによる方式で、名前は Extrapolation Algorithm for Greater Language-model Efficiency の略です。本命モデルの「頭の中」にあたる内部特徴（最終層の一つ手前の特徴ベクトル）を、小さな1層のネットワークで先読みするのが核心です。

• EAGLE（2024年1月）: トークンではなく特徴の並びを先読みする方が簡単、という観察から出発。特徴だけだと「どの語が選ばれたか」が曖昧になるので、1ステップ先のトークン列も入力に加えて解決しました。LLaMA2-Chat 70B で2.7〜3.5倍の高速化。
• EAGLE-2（2024年6月）: 下書きの「木」の形を固定せず、文脈に応じて動的に変える。下書き係の自信度が実際の受理率とよく一致することを利用し、当たりそうな枝を伸ばします。3.05〜4.26倍、EAGLE-1より20〜40%高速。
• EAGLE-3（2025年3月）: 特徴を予測する制約をやめてトークンを直接予測し、本命の低・中・高の複数の層の特徴を混ぜて使う。学習時に推論と同じ状況を再現する「training-time test」で、学習データを増やすほど伸びるようにしました。最大6.5倍、EAGLE-2の約1.4倍。NeurIPS 2025 採択。

EAGLE-3 は SGLang・vLLM・llama.cpp などの主要エンジンが対応しており、2026年10月時点で「学習済みの下書き係」を使う方式の代表格です。なお2026年10月20日には、Eagle 社（GitHubの eagle-hq）が「EAGLE-4」と名づけたリポジトリを公開しました。EAGLE-3 型の下書き係に、GPUで実測したコストからバッチの大きさに応じて下書きの量を決めるランタイム eagle-harness を組み合わせたものとされています。ただし、EAGLE-1〜3 を発表した研究チームのリポジトリ（SafeAILab/EAGLE）では EAGLE-4 は「予定」のままで、両者の関係は2026年10月時点で確認できていません。性能の独立した検証もまだありません。

MTP：最初から「先読み」を学んだモデル

MTP（Multi-Token Prediction、複数トークン予測）は、学習の段階から「次の1語」だけでなく「その先の数語」も予測させる方法です。Meta の Gloeckle らは2024年の論文で、学習の効率が上がるうえに、4トークン予測で学習したモデルは推論が最大3倍速くなると報告しました。

実用で有名なのが DeepSeek-V3 です。本体の横に「次の次」のトークンを予測するMTPモジュールを1つ持ち、学習の補助目標として使います。推論時はこれをそのまま下書き係として投機的デコーディングに使えます。技術報告によると2番目のトークンの受理率は話題を問わず85〜90%で、生成速度（トークン毎秒）は1.8倍になりました。下書き係を別に学習しなくてよいのがMTPの強みで、vLLM や llama.cpp も対応しています。

DFlash：拡散モデルで「一気に」下書きする

ここまでの下書き係（下書きモデル、EAGLE）は、どれも自分自身も1トークンずつ順番に書いています。k個書くにはk回の計算が必要で、下書きを長くするほど時間がかかります。DFlash はここを変えました。

DFlash は Chen・Liang・Liu（Z Lab）による2026年2月の論文「DFlash: Block Diffusion for Flash Speculative Decoding」で提案され、ICML 2026 に採択されました。名前のDの由来は論文に明記されていませんが、題名の「Block Diffusion」から来ていると見られます。下書き係に軽量なブロック拡散モデルを使い、ブロック内のトークンを1回の計算で並列にまとめて下書きします。

flowchart TD
  A["本命モデル"] --> B["複数の層の
内部特徴"]
  B --> C["DFlash 下書き係
ブロック拡散"]
  C --> D["16トークン分を
1回で下書き"]
  D --> E["本命が1回で検証"]
  E --> F["採用分を確定"]
  F --> A

拡散型のLLMは単独では自己回帰型ほど賢くありません。DFlash はその弱点を、本命モデルの複数の層から取り出した内部特徴を下書き係の全層のKとVに注入することで補います。埋め込み層と出力層は本命のものを共有し、学習するのは間の数層だけです。プロジェクトページによれば、評価はブロック長16・ノイズ除去1ステップで行われています。

論文では、さまざまなモデルとタスクで6倍を超える高速化（出力は変わらない）、EAGLE-3と比べて最大2.5倍の高速化を報告しています。論文の表（NVIDIA H200、Qwen3-8B、温度0）では、MATH-500 で DFlash が6.08倍（1回の検証で平均約7.9トークン採用）、EAGLE-3 は設定により1.81〜2.05倍でした。一方、雑談系の MT-Bench では DFlash 2.75倍・EAGLE-3 1.63〜1.90倍と、どの方式でも伸びは小さくなります。いずれも開発チーム自身の測定です。

2026年8月には後継の DFlash 2 が公開されました。DFlash ではブロック内の各位置が独立に候補を選ぶため、隣どうしの語がかみ合わないことがありました。DFlash 2 は隣接する候補の組み合わせを評価する仕組みなどを加え、1回の検証で採用されるトークン数を16〜25%増やしたと発表しています（開発元のブログによる）。

実際に使うときのポイント

2026年10月時点の主要エンジンでは、設定ひとつで投機的デコーディングを有効にできます。

• vLLM: --speculative-config の method に draft_model、ngram、suffix、mtp、eagle3、dflash などを指定。
• llama.cpp: --spec-type に draft-simple、draft-eagle3、draft-mtp、draft-dflash、ngram-simple などを指定。下書きモデルは -md で渡します。

注意したいのは、効果が大きいのは同時リクエストが少なく、GPUが暇をしているときだという点です。vLLM のドキュメントも、中〜低負荷でメモリ律速の状況でトークン間の遅延を減らす技術だと説明しています。大勢を同時に捌いてGPUの計算がすでに埋まっていると、外れた下書きの検証が純粋な無駄になり、効果が薄れたり逆効果になったりします。最近の方式が「負荷に応じて下書きの量を変える」方向に進んでいるのはこのためです。

また、受理率はタスクで大きく変わります。コードや数学、入力の書き写しが多い作業では当たりやすく、自由な雑談や創作では外れやすい。自分の用途で実測するのがいちばんです。