Speculative Decoding（スペキュラティブデコーディング）とは？読み方・LLM推論を2〜3倍高速化する仕組み・vLLM/EAGLE/Medusaの違いを完全解説

Speculative Decodingとは

Speculative Decoding（投機的デコーディング）とは、大規模言語モデル（LLM）の推論を高速化するための並列予測・並列検証技法である。通常、LLMは1トークンずつ順番に生成（自己回帰生成）するため、トークン1つ毎にGPUで重みのフルロードが発生して遅い。Speculative Decodingでは「軽量で高速なドラフトモデル」が複数トークンを先読みで予測し、本来のターゲットモデルがそれらを1回のフォワードパスで一括検証して、合致した分だけ採用する。出力品質を一切犠牲にせずに、推論速度を2〜3倍に高速化できる。

身近に例えるなら、Speculative Decodingは「秘書（ドラフトモデル）が下書きを書いて、上司（ターゲットモデル）が一気にチェックする」プロセスだ。下書きが正しければそのまま採用し、間違いがあればその箇所だけ書き直す。ChatGPTやClaudeなど主要なLLMサービスは内部でこの技術を活用しており、ユーザーが感じる「応答の速さ」を支える基盤技術になっています。Multi-Token PredictionやEAGLEなどのバリエーションも実用化が進んでいる重要な技法です。覚えておきましょう。

Speculative Decodingの読み方

Speculative Decodingの仕組み

Speculative Decodingは2022〜2023年にGoogle Research（およびDeepMind）から原型が発表され、その後のLLM推論最適化分野で爆発的に普及した技法である。中核アイデアは「LLM推論はメモリ帯域がボトルネックで、GPUの計算能力は余っている」という観察に基づいている。1トークン生成ごとに重みをVRAMからキャッシュにロードする時間が支配的なため、複数トークンを1回のパスで検証できれば、計算は増えても全体時間は短縮できる。

処理フロー

重要な性質として、Speculative Decodingは確率分布的に同一の出力を保証する。つまり「ドラフトモデルが当てた分だけ高速化する」という仕組みであって、品質劣化は一切起こらない。これは数学的に証明可能であり、Rejection Sampling（棄却サンプリング）のテクニックを応用した結果です。実務では「速度向上＝品質劣化のトレードオフ」がない、極めて稀な改善技法と覚えておきましょう。

主要なバリエーション

Speculative Decodingの使い方・実例

基本的な使い方（Quick Start）

# vLLMでSpeculative Decodingを有効化
from vllm import LLM, SamplingParams

# ターゲット: Llama 70B、ドラフト: Llama 7B
llm = LLM(
    model="meta-llama/Llama-3-70B-Instruct",
    speculative_model="meta-llama/Llama-3-7B-Instruct",
    num_speculative_tokens=5,  # 一度に予測するトークン数
)

prompt = "LLMの推論最適化技術について教えて"
out = llm.generate([prompt], SamplingParams(max_tokens=512))
print(out[0].outputs[0].text)

Hugging Face transformersで使う

from transformers import AutoModelForCausalLM, AutoTokenizer

target = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3-70B")
draft = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3-7B")
tok = AutoTokenizer.from_pretrained("meta-llama/Llama-3-70B")

inputs = tok("Hello", return_tensors="pt")
out = target.generate(
    **inputs,
    assistant_model=draft,  # ドラフトモデルを指定
    max_new_tokens=200
)

よくある実装パターン

パターンA: ペアモデル方式（Vanilla）

# ターゲットの1/10〜1/100程度のサイズのドラフトモデルを選ぶ
# 例: Llama 70B + Llama 7B
# ドラフトの構造とトークナイザがターゲットと同じであることが重要

向いているケース: 同じファミリーのモデルが揃っている場合（Llama、Qwen、Mistralなど）。実装が単純でトラブルが少ない。

避けるべきケース: ドラフトモデルとターゲットの語彙・トークナイザが違う場合。マッピングが複雑で実装エラーが起きやすい。

パターンB: Medusa/EAGLE方式

# ターゲットモデルに専用の予測ヘッドを追加
# 別モデルが不要なので運用が簡単
medusa_model = MedusaForCausalLM.from_pretrained("FasterDecoding/medusa-vicuna-7b-v1.3")

向いているケース: 別モデルを用意したくない、運用ノードを増やしたくない場合。事前学習済みのMedusa/EAGLEヘッドが配布されていれば即使える。

避けるべきケース: 自前ファインチューニング済みモデルにMedusaヘッドを追加する場合、追加学習が必要で手間がかかる。

アンチパターン: トークナイザが違うモデルでドラフトを組む

# ⛔ 絶対NG
target = "meta-llama/Llama-3-70B"     # Llama tokenizer
draft = "Qwen/Qwen2-0.5B"              # Qwen tokenizer (別物)
# トークン分割が一致せず、検証ステップで毎回拒否される

ドラフトモデルとターゲットモデルは必ず同じトークナイザでなければ動作しない。トークン化の結果が違えば、ドラフト予測したトークンをターゲットが受け取れず、毎回ゼロ受理（=単なる遅い推論）になる。実務では同じファミリー（Llama 3 70B + Llama 3 7Bなど）を使うのが鉄則です。

Speculative Decodingのメリット・デメリット

メリット

• 2〜3倍の高速化が無料：典型的なワークロードで2〜3倍、場合によっては5倍以上の推論速度向上が得られる。
• 品質劣化ゼロ：数学的に同じ出力分布が保証される（Rejection Samplingの結果）。
• 主要推論サーバが標準対応：vLLM、TGI、TensorRT-LLM、SGLangなどが組み込みで対応している。
• 長文出力ほど効果が大きい：トークン数が多い生成タスクほど絶対的な時間短縮が大きい。
• 追加GPUが少なくて済む：ドラフトモデルは小さいため、ターゲットと同じGPUに同居できることが多い。

デメリット

• ドラフトモデル選定が難しい：受理率が低いと逆に遅くなることもある。チューニングが必要。
• 追加メモリ消費：ドラフトモデル分のVRAMが必要。70B+7Bなら約14GB追加。
• バッチサイズが大きいと効果減：高負荷時は計算ボトルネックになり、メモリ帯域制約が緩むため速度向上幅が縮小する。
• 非トランスフォーマー型モデルには適用しにくい：Mambaなどの状態空間モデルでは別の最適化が必要。

Speculative DecodingとContinuous Batchingの違い

Speculative DecodingとContinuous Batchingはどちらも「LLM推論を速くする技術」だが、最適化する次元が異なる。下記の比較表で違いを整理する。

重要なのは、両者は補完関係にあり同時利用できる点です。実務ではvLLMやTGIが両技術を組み合わせて、低レイテンシかつ高スループットを実現しています。

Speculative Decodingに関するよくある誤解

誤解1: 「Speculative Decodingは品質を犠牲にして速度を稼ぐ近似手法」

なぜそう誤解されるのか：「投機的（speculative）」という単語が「賭け」「予測」「不確実性」を連想させ、品質と速度のトレードオフがある近似アルゴリズムだという背景知識が混同を招く。量子化（Quantization）など他の高速化技術が品質劣化を伴うことから、すべての高速化技術が同じだと推測される理由でもある。

正しい理解：Speculative Decodingは数学的に「ターゲットモデル単独と同一の出力分布」を保証する技術です。Rejection Samplingの理論を応用しており、品質劣化は一切起きません。劣化するのは「ドラフトの予測が外れた時の速度向上幅」であって、出力品質そのものではありません。

誤解2: 「ドラフトモデルが大きいほど速い」

なぜそう誤解されるのか：「予測が当たる確率＝モデルの賢さ」という単純な背景理解から、大きなドラフトを使えば速くなると推測される。「大は小を兼ねる」という直感が混同の理由です。

正しい理解：ドラフトが大きすぎるとドラフト自体の推論コストが増え、トータルでは遅くなる。一般にターゲットの1/10〜1/100程度のサイズがスイートスポットで、Llama 70B + Llama 7Bや Qwen 72B + Qwen 0.5B などが推奨されます。

誤解3: 「すべてのワークロードで2〜3倍速くなる」

なぜそう誤解されるのか：論文や紹介記事で「2〜3倍高速化」という数字が独り歩きする背景がある。代表的なベンチマークの結果が、すべてのワークロードに当てはまると混同される理由です。

正しい理解：効果はワークロードに依存し、バッチサイズが大きい場合（メモリ帯域がボトルネックでなくなる）や、ドラフトの受理率が低いタスク（コーディング、数値計算）では速度向上が縮小します。実測してから採用判断することが重要です。

Speculative Decodingの実務での活用シーン

① 対話型チャットUIのレイテンシ削減

ユーザーが応答を待っているチャットUIでは、Time-To-First-Tokenよりも全体の生成時間が体感品質に直結する。Speculative Decodingで2〜3倍速くなれば、応答完了までの時間が半減し、UXが大きく改善する。

② 長文生成タスク

記事生成、コード生成、要約など出力トークン数が多いタスクほど効果が大きい。生成時間が10秒→3秒になるだけで、ユーザー体験は劇的に変わる。

③ 自社推論基盤のコスト削減

同じGPU資源で2〜3倍のリクエストをさばけるため、サーバー台数を半分以下にできる。クラウドGPUコストが月数万ドル規模なら、Speculative Decoding導入で数千ドル単位のコスト削減になります。

④ オンデバイスLLM推論

iPhone/Macなどのデバイス上で動くLLM（Apple Intelligence等）でも、メモリ帯域がボトルネックになるため効果が大きい。実務では小型モデルとセットでメモリ使用量を抑える設計と相性が良い。

Speculative Decodingに関するよくある質問（FAQ）

まとめ

• Speculative DecodingはLLM推論を2〜3倍高速化する技術。
• ドラフトモデルが先読みし、ターゲットモデルが一括検証する仕組み。
• Rejection Samplingにより出力品質は数学的に保証。
• vLLM、TGI、TensorRT-LLM、SGLangなど主要推論サーバが標準対応。
• 派生形にMedusa、EAGLE、Multi-Token Prediction、Lookahead Decodingなど。
• Continuous Batchingと併用可能で、両技術はLLMサービング基盤の標準装備となっている。

参考文献・出典