Speculative Decoding が「常時オン」になった 2026 年
- 年までの speculative decoding は「一部のワークロードで効く実験機能」という扱いだったが、2026 年現在、vLLM、SGLang、TensorRT-LLM のいずれもデフォルトで spec decoding を推奨し、本番 serving スタックで外す理由がほぼなくなった。背景にあるのは三点の成熟である。第一に、EAGLE-3 を筆頭とする draft アーキテクチャが accept rate 80% 超を一般的なチャット／コード生成ワークロードで安定して出せるようになったこと。第二に、continuous batching との統合が洗練され、低 QPS でも高 QPS でも壊れにくくなったこと。第三に、draft model の配布と fine-tuning パイプラインが Hugging Face Hub や各ベンダの専用ハブ経由で標準化され、target model を差し替えるたびに draft を一から作る必要がなくなったことだ。
KGA では 2026 年 Q1 に 40 を超える顧客インフラで spec decoding の本番導入を支援しており、本稿ではそこで集めた実測値と設計知見をまとめる。
EAGLE-3、Medusa-2、Lookahead の違い
EAGLE-3 EAGLE シリーズは「target モデルの hidden state を入力とする autoregressive draft head」を訓練する方式で、EAGLE-3 では training target が next-token だけでなく「複数トークン先の hidden state との整合」にも拡張された。これにより draft tree の深さを 6～8 まで伸ばしてもドリフトが少なく、Llama-3-70B や Qwen3-72B で accept length 3.8～4.5 を安定して出す。必要な追加パラメータは target の約 0.5～1% で、メモリ圧は軽い。
Medusa-2 Medusa 系は「target の final hidden から複数の独立した classification head を生やし、並列に k トークン先を予測する」非自己回帰型。Medusa-2 では tree attention と typical acceptance が組み込まれ、draft 生成コストがほぼゼロに近い点が最大の利点。一方で head 同士の依存をモデル化しない構造上、accept length は EAGLE-3 に比べて短く、典型的に 2.2～2.8 程度。実装が単純で、target 側を finetune せず後付けしやすいのが採用理由になる。
Lookahead decoding Lookahead は draft model を使わず、target 自身の n-gram 履歴で future token を仮置きし、検証ステップで一致を取る方式。訓練コストゼロ、任意モデルに即適用できるのが魅力だが、accept rate は入力のパターン性に強く依存する。コード補完や構造化出力（JSON、XML、SQL）では accept length 3.0 前後まで伸びるが、自由な会話では 1.5 を切ることも多い。
実務では「EAGLE-3 を第一候補、target finetune が難しい運用上の制約があれば Medusa-2、コード専用や構造化生成サービスでは Lookahead」という使い分けが落とし所になっている。
Accept rate / accept length のチューニング
Spec decoding の指標で最も誤解されるのが accept rate と accept length である。accept rate は「draft が提案したトークンのうち何 % が検証で通ったか」、accept length は「1 回の target forward で前進したトークン数の期待値」。スループットに直結するのは後者で、draft tree のトポロジーと typical acceptance の閾値で大きく動く。
EAGLE-3 の場合、tree width と depth はワークロードで分ける。単ターン短応答（10～30 トークン出力）が主体なら width=6、depth=4 程度で十分。長応答（数百～数千トークン）では width=8、depth=6 に広げると accept length が 0.5～1.0 伸びる。ただし tree を広げると検証時の target forward における KV 追加が増えるため、高 QPS 帯ではバッチが詰まって逆効果になる閾値がある。この境界は実測で決めるしかない。
typical acceptance の閾値 τ は、通常 0.09～0.15 のレンジで設定し、hallucination 寄りの出力を避けたいワークロードでは下げ、throughput を最大化したい汎用チャットでは上げるのが経験則だ。τ を 0 に近づけると「確率分布が同じでなくても top-k に入っていれば受理」する挙動になり、accept length は伸びるが出力品質が若干 drift する。品質評価を A/B で回し、MT-Bench や社内評価で劣化が出ない閾値を探す。
Throughput 改善の実測データ
KGA 検証ラボと顧客環境での実測値（H200 SXM 8 枚、vLLM 0.7.x 系、FP8 KV、Llama-3.3-70B-Instruct、シーケンス長 2048 入力／512 出力、batch size 可変）。
- baseline（spec なし）: 単発 QPS で 42 tok/s、QPS=8 で aggregate 320 tok/s、TTFT 中央値 180ms、ITL 中央値 24ms。
- EAGLE-3（width=6, depth=4, τ=0.12）: 単発 QPS で 98 tok/s（+133%）、QPS=8 で aggregate 512 tok/s（+60%）、TTFT 182ms（ほぼ不変）、ITL 中央値 10ms。accept length 4.1。
- Medusa-2（5 heads, tree 候補 64）: 単発 QPS で 76 tok/s（+81%）、QPS=8 aggregate 451 tok/s（+41%）、accept length 2.6。実装の軽さが高 QPS で効き、メモリ余裕がある場合に好ましい。
- Lookahead（ngram size 4, window 7）: 単発 QPS で 58 tok/s（+38%）、コード生成系ワークロードのみで aggregate +48%。汎用チャットでは +10% 前後にとどまる。
MoE モデル（Mixtral-8x22B 相当）では話が変わる。target 側 forward が expert 選択で既にスパースのため、draft が与える「1 forward あたりのトークン数増」の効果が dense より大きくなる。EAGLE-3 を MoE 用に再訓練した派生では accept length 4.8 を叩き出し、throughput 改善 70% 超の報告も複数ある。
vLLM での設定例
vLLM 0.7 系列では speculative config が engine 引数で統一され、以下のように指定する。
```python from vllm import LLM, SamplingParams from vllm.config import SpeculativeConfig
llm = LLM( model="meta-llama/Llama-3.3-70B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8", gpu_memory_utilization=0.92, speculative_config=SpeculativeConfig( method="eagle3", model="kga-labs/eagle3-llama3.3-70b", num_speculative_tokens=5, draft_tensor_parallel_size=1, posterior_threshold=0.12, posterior_alpha=0.3, ), enable_chunked_prefill=True, max_num_batched_tokens=8192, ) ```
本番では `draft_tensor_parallel_size` を 1 に固定して draft を小さく保ち、target TP=8 の空きストリームで draft を走らせる設計が効く。draft を分散させると通信オーバーヘッドが accept の利得を食う。
SGLang での設定例
SGLang は RadixAttention と spec decoding の統合に強みがあり、prefix 共有が多いマルチテナント環境で特に刺さる。
```bash python -m sglang.launch_server \ --model-path Qwen/Qwen3-72B-Instruct \ --tp 8 --kv-cache-dtype fp8_e5m2 \ --speculative-algorithm EAGLE3 \ --speculative-draft-model kga-labs/eagle3-qwen3-72b \ --speculative-num-steps 5 \ --speculative-eagle-topk 8 \ --speculative-num-draft-tokens 64 \ --enable-torch-compile \ --chunked-prefill-size 8192 ```
SGLang 特有の `speculative-eagle-topk` と `speculative-num-draft-tokens` の組み合わせが tree 形状を直接制御する。KGA の検証では topk=8、draft tokens=64 が多くのチャットワークロードで sweet spot だった。
導入時の落とし穴
実装ミスで頻出する三点を挙げておく。第一に、draft model と target model の tokenizer が完全一致していないケース。EAGLE-3 の draft は target から派生して訓練されているので通常は問題ないが、target を post-training で差し替えた際に draft を更新し忘れると accept rate が劇的に落ちる。第二に、FP8 KV と spec の相互作用。target が FP8 KV を使い draft が FP16 KV の場合、KV 共有ができず draft 側に別途 KV ページを持つ必要があり、メモリ圧が想定より増える。第三に、低 QPS で spec が効き高 QPS で効かない挙動は正常であり、ルーティング層で負荷に応じて spec ON/OFF を切り替える「adaptive spec」を kubernetes の HPA と組み合わせるのが定番化している。
まとめ
EAGLE-3 を第一候補にし、accept length を 4.0 前後、aggregate throughput 改善 40～60% を目標ラインとして設計する。MoE では 70% 超も現実的になる。vLLM か SGLang いずれでも導入コストは一週間以内に収まる。2026 年の LLM serving で spec decoding を入れないのは、明確な理由がない限り機会損失である。