投機的デコード（Speculative Decoding）とは 2026年版：ドラフトモデルで tok/sec を1.5〜3倍にする仕組みと、効くケース・効かないケース

結論：投機的デコード（speculative decoding）は、小さなドラフトモデルに数トークン先読みさせ、大モデルがそれを一括検証することで tok/sec を1.5〜3倍に引き上げる高速化です。最大の利点は「出力が大モデル単体とまったく同じ」というロスレス性。品質を一切落とさず速くなります。ただし速度は『ドラフトの予測がどれだけ当たるか（受理率）』次第で、コード生成・JSON・定型出力では大きく効き、雑談・創作では効きにくい。VRAMにドラフト分の余裕があり、構造化された出力を多く回す人ほど恩恵が大きい技術です。

ローカルLLMの最大の不満は「生成が遅い」こと。tok/sec（1秒あたり生成トークン数）を上げる方法というと、まず思いつくのは「帯域の高いGPUを買う」「量子化でモデルを小さくする」の2つでしょう。どちらもハードやモデルそのものに手を入れる話です。

これに対して投機的デコードは、ハードもモデルも変えずにソフトウェア側だけで速くする第3の道です。しかも出力は変わりません。2026年には llama.cpp・LM Studio・vLLM すべてで標準的に使えるようになり、「追加ハードなし・微調整なし・品質劣化ゼロで効く、ローカルLLM最良の最適化」とまで言われるようになりました。この記事では、なぜそんな都合のいいことが成立するのかを仕組みから説明し、効くケースと効かないケースの判断軸を渡します。

まず仕組み：1人で書くより、下書き役と添削役で分業する

通常のLLMの生成（decode）は、1トークンずつ順番に作ります。「次の単語」を1個出すために大モデルを丸ごと1回走らせ、それをひたすら繰り返す。トークン生成のたびにモデルの全重みをメモリから読み出すので、ここが遅さの正体です（この仕組みは「メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み」で詳説しています）。

投機的デコードは、この処理を**「下書き役」と「添削役」の分業**に置き換えます。

1. ドラフトモデル（下書き役）：小さく高速なモデルが、次の数トークン（例：4〜8個）を一気に予測して提案する
2. ターゲットモデル（添削役）：本来使いたい大モデルが、その提案を1回の処理でまとめて検証する。先頭から照合して、自分が出すはずだった答えと一致する分まではそのまま採用、最初に食い違ったところで自分の正解に差し替える

ポイントは添削の部分です。大モデルは「4トークンを1個ずつ4回」ではなく「4トークンまとめて1回」で検証できます。検証は前から順に照合するだけなので、ドラフトの提案がよく当たれば、大モデルを1回走らせるだけで複数トークンを確定できる。これが速くなる理由です。

なぜ品質が落ちないのか：当たれば採用、外れれば差し替え

「小さいモデルに下書きさせたら精度が落ちるのでは？」。ここが最大の誤解ポイントなので、先に潰します。

落ちません。投機的デコードはロスレスで、出力は大モデル単体で生成した場合と完全に一致します。

理由は検証の仕組みにあります。ドラフトの提案は「採用候補」にすぎず、最終的に何を出すかを決めるのは必ず大モデル（ターゲット）です。

• ドラフトの提案が大モデルの答えと一致したトークン → そのまま採用（=大モデルが自分で出した結果と同じ）
• ドラフトの提案が大モデルの答えと食い違った最初のトークン → 大モデルの正解に差し替え、そこから先のドラフト提案は破棄

つまりドラフトは「速く確定させるための先回り」であって、品質の判断には一切関与しません。当たればショートカット、外れても大モデルが正す。だから速くなるか・据え置きになるかの違いはあっても、品質が下がることはない。ここが量子化（速くする代わりに精度がわずかに劣化する）との決定的な違いです。

速度を決めるのは「受理率」の一点

ロスレスなら常に使えばいいかというと、そうではありません。速度がどれだけ伸びるかは、**ドラフトの提案がどれだけ採用されたか＝受理率（acceptance rate）**でほぼ決まります。

• 受理率が高い（提案がよく当たる）→ 大モデル1回で何トークンも確定 → 大幅高速化
• 受理率が低い（提案がよく外れる）→ 差し替えが多発し、ドラフトを走らせた手間が無駄に → ほぼ効かない、むしろ遅くなることも

受理率0.6〜0.8（提案の6〜8割が当たる）あたりが一般的なクエリの目安で、このとき1.5〜3倍の速度が出ます。ドラフト長（一度に先読みするトークン数 K）は4〜8が標準的なバランスです。

外れたときに「ドラフトを走らせた計算が丸損になる」点が重要です。受理率が低い処理では、この空振りのオーバーヘッドが利得を食いつぶし、素のデコードより遅くなることすらあります。だから「使えば常に速い」ではなく「当たる処理でだけ速い」のが投機的デコードの本質です。

効くケース・効かないケース（早見表）

受理率は「次のトークンがどれだけ予測しやすいか」で決まります。文章が定型的・反復的なほどドラフトが当たり、自由度が高いほど外れる。用途別に整理します。

用途	受理率の傾向	速度の伸び	理由
コード生成	高い	大（最大3倍前後）	構文・予約語・定型パターンが多く次トークンが読みやすい
JSON / 構造化出力	非常に高い	大	キー名・括弧・区切りなど形式が決まっている
要約・翻訳・書き換え	中〜高	中	入力に沿うため分岐が比較的少ない
技術文書・定型ビジネス文	中	中	言い回しがパターン化しやすい
雑談・対話	中〜低	小	話題の分岐が多く先読みが外れやすい
創作・ブレスト	低い	小〜ほぼゼロ	多様性が高く次トークンが予測しにくい

ざっくり言えば、「答えがある程度決まっている生成」ほど効き、「何が来てもおかしくない生成」ほど効かない。コーディング支援や定型レポート自動生成を主目的にローカルLLMを回す人には刺さり、創作チャット中心の人には響きにくい、という相性があります。

4つの方式：ドラフトモデル / Medusa / EAGLE・EAGLE-3 / n-gram

「ドラフト役」をどう用意するかで方式が分かれます。2026年に実用される主要な4つを押さえておきます。

• 別ドラフトモデル方式：本命と同系列の小型モデルをドラフトに使う最も基本的な方式（例：Llama 3.2 1B をドラフト、Llama 3.3 70B をターゲット）。ドラフトとターゲットはトークナイザーを共有している必要があるため、原則同じモデルファミリーで揃えます
• Medusa：ターゲットモデルに複数の予測ヘッドを足し、別モデルを用意せず自分で複数トークンを先読みする方式
• EAGLE / EAGLE-3：ターゲットの内部特徴を使って学習した専用ドラフトヘッドを載せる方式。受理率が高く、EAGLE-3は70Bクラスで4〜6倍の高速化報告もある（バッチ1・単一ユーザー時）。2026年時点で最も速い部類
• n-gram / prompt-lookup：モデルを一切使わず、入力文や既出のトークン列から「次に来そうな並び」を引き写す方式。RAGや長文要約のように入力の語句がそのまま出力に再登場しやすい処理で効く。追加VRAM不要なのが利点

「とりあえず試す」なら別ドラフトモデル方式かツール標準のEAGLE系、「入力をなぞる処理が多い」ならn-gram、というのが入り口の目安です。

必要VRAMの考え方：ドラフト分が上乗せされる

投機的デコードはターゲットとドラフトの両方を同時にVRAMへ常駐させます。したがって、ドラフトモデルのサイズ分だけメモリが上乗せされます。

• 0.5BクラスのドラフトをQ4量子化で使う場合：目安0.5GB前後の上乗せ
• 1〜3Bクラスを使う場合：1〜2GB程度の上乗せ

上乗せ自体は小さいのですが、問題はVRAMがギリギリの構成です。ターゲットモデルだけでVRAMを使い切っている状態でドラフトを足すと、メモリ不足でターゲットの一部がVRAMからあふれ、かえって遅くなる。投機的デコードは「容量に余裕がある環境」向けの高速化だと理解してください。VRAMがカツカツなら、まずは量子化でターゲット自体を軽くするのが先決です（→「ローカルLLMの量子化フォーマットとは」）。

なお、ドラフトは小さいほど速く回りますが、小さすぎると受理率が落ちます。逆に大きいとドラフト自体が重くなる。ターゲットの1/10〜1/30程度のサイズが、速度と受理率のバランスとして無難なレンジです。

使えるツール（2026年）：llama.cpp / LM Studio / vLLM / Ollama

最後に実装側。2026年には主要ツールで標準的に使えます。

ツール	対応状況	使い方の要点
llama.cpp	対応	llama-cli / llama-server の --model-draft（-md）でドラフトGGUFを指定。ターゲットと同じトークナイザーが必須
LM Studio	0.3.10〜 GUI対応	サイドバーに「Speculative Decoding」欄が追加。メインモデルをロードすると互換ドラフトが選べる。設定のみで利用可
vLLM	対応	ドラフトモデル方式に加え EAGLE / EAGLE-3 / Medusa をサポート。サーバー用途向け
Ollama	限定的	対応するモデルタグが必要。すべてのモデルにドラフトが組まれているわけではない

GUIで最も手軽に試せるのはLM Studio 0.3.10、CLIで細かく詰めるなら llama.cpp の --model-draft、サーバーで本格運用なら vLLM のEAGLE系、という住み分けです。

ひとつ注意点を添えておくと、コンシューマーGPUやMoEモデルでは効果がまちまちで、構成によってはオーバーヘッドのほうが勝って体感が変わらない・わずかに遅くなる例も報告されています。投機的デコードは「設定したら必ず速くなる魔法」ではなく、自分の用途（受理率が高い処理か）と環境（VRAMに余裕があるか）が噛み合ったときに効く最適化です。まずは普段使う典型的なプロンプトで、オンとオフの tok/sec を実測して判断するのが確実です。

まとめ：品質を落とさず速くする、唯一の手軽な選択肢

投機的デコードのポイントを最後に1行で。

ドラフトが先読み、大モデルが一括検証。出力は変えずに、当たる処理でだけ1.5〜3倍速くする。

帯域の高いGPUを買うのもモデルを小さく量子化するのもコスト（お金か品質）を伴いますが、投機的デコードは追加ハードなし・品質劣化ゼロで効く点が他の高速化と一線を画します。コード生成・構造化出力を多く回し、VRAMに少し余裕がある人なら、設定するだけで体感が変わる可能性が高い。まずは手持ちの環境でオン・オフを実測して、自分の用途で受理率が出るかを確かめてみてください。

設定値そのもの（n-gpu-layers・KVキャッシュ量子化・flash attention など）でのチューニングは「ローカルLLM 推論を速くする llama.cpp / Ollama チューニング設定ガイド」、tok/sec が何で決まるかの大本は「メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み」で扱っています。あわせて読むと、ローカルLLM高速化の全体像がつながります。

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版
• ローカルLLM 推論を速くする llama.cpp / Ollama チューニング設定ガイド 2026年版
• ローカルLLMの量子化フォーマットとは 2026年版：GGUF / GPTQ / AWQ / EXL2 の仕組みと選び方