Speculative Decodingとは？出力精度を変えずにLLM推論を高速化する仕組み

Speculative Decoding（投機的デコーディング）は、LLMの出力分布を変えずに、生成を速くする推論手法です。

小さく速いモデルが先に複数のトークン候補を出し、本命の大きなモデルがそれをまとめて検証します。

「LLMの応答が遅い」「GPUを増やさずにレイテンシを下げたい」というときに、量子化やKVキャッシュと並んで候補に挙がる手法です。ただし、ドラフトモデルの選び方や候補数の設定を誤ると、かえって遅くなることもあります。

この記事では、次の内容を解説します。

• 通常の自己回帰生成や、量子化・KVキャッシュ・バッチ処理との違い

• ドラフト→一括検証→採択・棄却という仕組みと、出力精度が変わらない理由

• Draft-Target・MTP・EAGLE系・N-gramといった主な方式

• 速くなる条件と遅くなる条件

• vLLMでの導入手順と、検証に使うGPU環境の選び方

※設定例は、2026年11月時点のvLLM公式ドキュメント（開発版）を基にしています。設定キーや対応方式はバージョンで変わるため、利用中のバージョンのドキュメントもあわせて確認してください。

Speculative Decodingとは、1回のforward（順伝播計算）で複数トークンを確定させる推論高速化の手法です。

通常はターゲットモデル（本命の大きなモデル）が1トークンずつ生成しますが、これを「先読みした候補をまとめて検証する」処理に置き換えます。

なお、「出力精度を変えない」とは、ターゲットモデルの出力確率分布を保つという意味です。

temperature>0でサンプリングする場合、生成される文字列自体は毎回変わり得ます。一致するのは個々の文字列ではなく、文字列が引かれる確率分布です。

この手法は、2022～2023年にほぼ同時期に2つの論文で提案されました。

※数値はいずれも各論文の要旨より。どちらも、採択・棄却の規則を工夫することで、ターゲットモデル単体と同じ出力分布になることを数学的に示しています。

通常のLLMは、自己回帰（autoregressive）で文章を作ります。

1. 今までのトークン列を入力し、次の1トークンを決める

2. そのトークンを末尾に足す

3. 1～2を繰り返す

そのため、100トークン生成するにはターゲットモデルのforwardが100回必要です。

Speculative Decodingでも、トークンが1つずつ順番に決まる点は変わりません。違うのは、候補列が先に与えられている点です。

たとえば「東京 の 天気 は」の続きとして、候補「晴れ / です / 。」があるとします。ターゲットモデルは1回のforwardで、次の3つの分布をまとめて計算できます。

• 位置1：「東京 の 天気 は」の次に来るトークンの分布

• 位置2：「東京 の 天気 は 晴れ」の次に来るトークンの分布

• 位置3：「東京 の 天気 は 晴れ です」の次に来るトークンの分布

つまり、文章全体を一括で生成しているわけではありません。複数ステップ分の判定を1回のforwardにまとめているのがポイントです。

Speculative Decodingは、ほかの推論最適化と狙いが異なり、多くの場合は併用できます。

ターゲットを量子化した場合は、「精度が変わらない」の意味に注意が必要です。

• Speculative Decodingが保つのは、実際に動かしているターゲットモデルの分布

• FP8に量子化したモデルがターゲットなら、比較対象は元のFP16モデルではなく、量子化後のモデル単体

量子化による精度の変化と、Speculative Decodingによる高速化は、分けて評価しましょう。

KVキャッシュの仕組みは、こちらの記事を参考死してみてください。

Speculative Decodingは、次の3段階を1サイクルとして繰り返します。

1. ドラフトが候補を出す

2. ターゲットがまとめて検証する

3. 採択・棄却で確定する

確定したトークンを文脈に足し、次のサイクルの候補を作ります。1サイクルで確定するトークン数は、最小1、最大γ+1です。

この記事では、記号を次のように統一します。

最初に、ドラフトモデルが現在の文脈に続く候補をγ個生成します。

ドラフトモデルも一般的には自己回帰モデルなので、候補1→候補2→候補3…と順番に生成します。

x₁ ～ q(・| prefix)、x₂ ～ q(・| prefix, x₁)、…、xγ ～ q(・| prefix, x₁, …, xγ−1)

ここで押さえたいのは、先読み自体の計算は無料ではない点です。ドラフトのforwardはγ回発生し、各位置の分布q(x)も後の判定用に保持します。

候補数γを増やしたときの影響は、次のとおりです。

• 1サイクルで確定できるトークン数の上限は増える

• ドラフトの計算時間は、γに比例して増える

• 後ろの候補ほど採択されにくい（それより前の候補がすべて採択されていることが前提のため）

各位置の条件付き採択率が一定でも、先頭からk個が連続で採択される確率はそれらの積になり、後ろの位置ほど小さくなります。γは大きいほど速い、というものではありません。

次に、ターゲットモデルが「確定済みの文脈＋γ個の候補」を入力し、1回のforwardでγ+1個の位置の分布を計算します。

p(・| prefix)、p(・| prefix, x₁)、…、p(・| prefix, x₁, …, xγ)

• Transformerのcausal attentionはそのまま保たれる

• 位置kの分布は「k番目までの候補」だけを見て計算され、1トークンずつ生成した場合と同じ値になる

• 処理の形は、プロンプトを読み込むprefillとよく似ている

注意したいのは、forwardは1回でも、処理するトークンはγ+1個分なので計算量は増えるという点です。

それでも速くなるのは、LLMのデコードが多くの場合、計算量ではなくメモリ帯域に律速されているからです。

• デコードでは、1ステップごとにモデル重み（数GB～数百GB）の多くをGPUメモリから演算器へ読み出す

• バッチが小さいと演算器は読み出し待ちが長く、計算能力に余裕がある

• 複数トークンを1回のforwardで処理すれば、重みの読み出しコストを複数トークンで分け合える

※実際の転送量は、実装やキャッシュの効き方によって変わります。

ただし、次のような場合は検証時間が目に見えて伸びることが確認できます。

• γが大きい

• 文脈が長く、attentionの計算が重い

• バッチが大きく、計算律速に近い

最後に、ドラフトの候補を先頭から1つずつ判定し、出力を確定させます。判定方法はデコード方式によって異なります。

• greedy（temperature=0）の場合

各位置で、ターゲットが最も確率が高いと判断したトークン（argmax p）とドラフトの候補を比べます。

• 先頭から一致している候補は、すべて採択

• 最初に不一致となった位置では、ターゲットのargmaxのトークンを代わりに採用

結果は、ターゲット単体でgreedy生成した場合と同じトークン列になります。

• sampling（temperature>0）の場合

候補xᵢは、次の確率で採択します（本記事では「採択確率」と呼びます。受理確率、acceptance probabilityとも呼ばれます）。

αᵢ ＝ min(1, p(xᵢ) / q(xᵢ))

• ターゲットの方が確率を高く見積もっているトークン（p(x)≧q(x)）は、必ず採択

• ドラフトが過大に見積もったトークンは、その比率に応じて棄却

棄却した場合は、次の分布からトークンを1つ引き直します。

p′(x) ＝ max(0, p(x) − q(x)) ／ Σx′ max(0, p(x′) − q(x′))

この分布は、「ドラフトは出しにくいが、ターゲットは出したい」トークンの分だけを補うものです。採択分と引き直し分を合わせると、ちょうどターゲットの分布pに一致します。

これが「出力精度を変えずに速くなる」根拠です。

• 最初に棄却が起きた位置より後ろの候補は、すべて破棄する（正しくない文脈を前提に作られているため）

• γ個すべてが採択された場合は、②で計算済みの分布からもう1トークン引けるため、γ+1トークンが確定する

• 途中でEOSなどの終了トークンが出たり、最大長に達したりした場合は、そこで終了する

一連の流れを擬似コードにすると、次のとおりです。

※この擬似コードは、仕組みを示すための簡略版です。

• max(p[i] - q[i], 0)は、語彙全体の確率ベクトルに対する要素ごとの演算

• normalize、sample、forward_all_positionsは概念上の関数

• EOSや最大長などの終了条件は簡略化し、greedy時の判定やバッチ処理は省略

こちらの記事からは、PyTorchの基本を学ぶことができます。

方式は、「候補を誰がどう作るか」で分かれます。

検証と採択・棄却の考え方は共通です。違うのは、ドラフトの作り方と、追加で必要になるモデルやメモリです。

• Draft-Target方式

既存の小型モデルをそのままドラフトに使う、最も基本的な方式です。組み合わせの例は次のとおりです。

ドラフトは、パラメータ数の小ささだけでなく、次の点も確認して選びます。

• 語彙・トークナイザーの互換性：同じトークンIDが同じ文字列を表す必要がある。同じ系列でも、世代が違うと語彙が拡張されていることがある

• ドラフトの速さ：十分に速くないと、先読みの時間が節約分を食いつぶす

• 採択長：1サイクルで平均何トークン採択されるか。同系列で学習データの傾向が近いほど長くなりやすい

• 追加VRAM：ドラフトの重みとKVキャッシュの分が余分に必要

ローカル環境でよく使われるLM Studioも、この方式に対応しています。チャット画面のサイドバーでドラフトモデルを選ぶだけで有効になります。

LM Studioのドキュメントでは、ドラフトはメインモデルと同じ語彙が必要とされています。高速化を期待できるドラフトの最大サイズの目安は次のとおりです。

※3Bのメインモデルについては、目安が示されていません。

なお、語彙が異なるモデル同士を組み合わせる拡張もあります。vLLMではuse_heterogeneous_vocabを有効にすると、両者の語彙の共通部分だけで候補を作るToken-Level Intersectionが使えます。

ただし、2026年10月時点では次の制約があります。

• 基本方式とは前提が異なる拡張である

• draft_model方式でのみ利用できる

• 確率的なドラフトサンプリングには未対応

まずは同じ語彙のモデルを組み合わせましょう。そのうえで、推論エンジンとそのバージョンが対応しているかを公式ドキュメントで確認してから試すのが確実です。

• MTP方式

MTPは、1つの位置から次の複数トークンをまとめて予測するようにモデルを学習させる考え方です。もともとは学習・モデル設計の手法です。

MetaのGloeckleらの研究では、4トークン先まで予測するように学習したモデルが、自身の追加ヘッドを使った自己投機的デコーディングで最大3倍速くなりました。大きなバッチサイズでも効果があったと報告されています。

大規模モデルでの実用例がDeepSeek-V3です。テクニカルレポートの5.4.3節では、MTPモジュールを投機的デコーディングと組み合わせた結果が次のように報告されています。

• 2トークン目の採択率：生成トピックを問わず85～90%

• 生成速度：1.8倍

推論時の動きは、通常のSpeculative Decodingと同じです。MTPモジュールが候補を出し、本体が検証して確定させます。

• 利点：別のドラフトモデルを用意しなくてよい

• 制約：MTPモジュール付きで公開されたモデル系列に限られている

• vLLMでの指定："method": "mtp"。候補数は1から始めることが推奨されている

• EAGLE系

EAGLEは、ターゲットモデルの内部の特徴量を使う専用の軽量ドラフトで候補を作る方式です。

最終層付近の隠れ状態を入力にするため、ターゲットが「何を言おうとしているか」を直接使えます。トークン列だけを見る小型モデルより、採択長を伸ばしやすいのが特徴です。

後継のEAGLE-3では、主に次の点が改められました。

• 特徴量ではなく、トークンを直接予測する

• 最終層だけでなく、複数の層の特徴を組み合わせる

• training-time testと呼ばれる学習方法を採用する

論文では、最大6.5倍の高速化（EAGLE-2比で約1.4倍）が報告されています。

利用者として押さえておきたいのは、方式の細部よりも次の2点です。

• EAGLEのドラフト重みは特定のターゲットモデル向けに学習されたもので、ほかのモデルには流用できない

• 推論エンジンが、そのEAGLEのバージョン（eagle／eagle3）とターゲットの組み合わせに対応している必要がある

Hugging Faceには、RedHatAIなどが公開しているEAGLE-3の重みがあります。まずは、使いたいターゲットに対応する重みがあるか確認しましょう。

• N-gram

N-gram方式は、ニューラルネットのドラフトを使わず、すでに出てきたトークン列から候補を作る方式です。Prompt Lookup Decodingとも呼ばれます。

プロンプトや生成済みのテキストから、直近の数トークンと一致する箇所を探し、その続きを候補にします。

フィジカルAIに関してはこちらの記事が人気です。

速くなるかどうかは、主に次の3つで決まります。

• ドラフトの速さと採択長のバランス

• GPUの負荷の高さ

• メモリの余裕

このほか、文脈長（attentionの計算量）や、テンソル並列時のGPU間通信も速度に影響します。どれかが崩れると、出力は同じまま速度だけが落ちることもあります。

高速化の度合いは、「1サイクルで平均何トークン確定するか」と「1サイクルにかかる時間」の比で決まります。

Leviathanらの論文に沿って、各候補の条件付き採択率を一定のαとすると、1サイクルで確定するトークン数の期待値は次のとおりです。

E[確定トークン数] ＝ (1 − α^(γ+1)) ／ (1 − α)

さらに次の2つを仮定すると、通常生成に対する速度向上率はおおよそ次の式で見積もれます。

• ドラフト1回のforwardにかかる時間は、ターゲット1回のc倍

• 検証のforwardは、通常の1ステップと同じ時間

速度向上率 ≈ (1 − α^(γ+1)) ／ {(1 − α)(γc + 1)}

この式に数字を入れると、傾向がつかめます。

表から読み取れるポイントは、次の3つです。

• 採択率が高ければ、γを4から8に倍増しても伸びはほぼ頭打ち

• 採択率が0.5まで下がると、同じγでも効果は大きく縮む

• 採択率が低いうえにドラフトが重い（cが大きい）と、通常生成より遅くなる

実際には、検証のforwardもγに応じて重くなり、採択率も位置やプロンプトで変わるため、この式は目安です。

それでも、「小さく速いドラフト」と「ターゲットとよく一致するドラフト」の両立が必要だという構造はよく分かります。

LM Studioのドキュメントでも、タスクによって採択されやすさが変わると説明されています。

• 採択されやすい：定番の公式を答える質問や計算問題など、続きの候補が限られるタスク

• 棄却が増える：物語の創作など、続きが無数にあるタスク

• 低～中負荷と高負荷ではボトルネックが変わる

効果は、同時に処理しているリクエスト数（負荷）で大きく変わります。

vLLMのドキュメントでも、主な対象は「中～低QPSで、メモリ律速のワークロード」におけるトークン間レイテンシの短縮とされています。

vLLMのドキュメントでは、方式ごとの効果が次のように整理されています。

• EAGLE・MTP：低負荷時は「効果大」、高負荷時は「中～大」

• Draft-Target方式：高負荷時は「中」

• N-gram・Suffix Decoding：ピーク時にも負荷を増やしにくい選択肢

負荷が時間帯で大きく変わるサービスでは、負荷に応じて投機の深さを調整するDynamic Speculative Decodingのような仕組みも検討対象になります。

• 追加VRAMとKVキャッシュの容量を見積もる

Draft-Target方式やEAGLE系では、ターゲット本体に加えて次のメモリが必要です。

• ドラフトモデル（またはEAGLEヘッド）の重み

• ドラフト側のKVキャッシュ

• 検証中の候補γ個分の、ターゲット側の一時的なKVキャッシュ

KVキャッシュの1トークンあたりのサイズは、次の式で計算できます。

KV（バイト/トークン）＝ 2 × 層数 × KVヘッド数 × ヘッド次元 × 1要素のバイト数

FP16（2バイト）で計算すると、次のようになります。

このほか、ドラフトの重みもFP16で約2.5GB増えます。

vLLMは、確保したGPUメモリからモデル重みを除いた残りをKVキャッシュに割り当てます。そのため、ドラフトを追加すると保持できるシーケンス数や文脈長が減り、同時接続数の上限が下がることがあります。

導入前に、次の合計がGPUメモリに収まるかを見積もっておきましょう。

• ターゲット＋ドラフトの重み

• 想定する同時接続数×文脈長分のKVキャッシュ

GPUSOROBANでLlamaを使う方法は、こちら記事を参考にしてみてください。

vLLMでは、speculative_config（CLIでは--speculative-config）を1つ追加するだけでSpeculative Decodingを有効にできます。

ただし、設定しただけで速くなるとは限りません。次の順に進めるのが確実です。

1. 対応方式・モデル・実行環境を確認する

2. Speculative Decodingなしのベースラインを測る

3. speculative_configを設定して生成する

4. 候補数と同時接続数を変えて最適値を探す

以下では、ターゲットにLlama 3.1 8B Instruct、ドラフトに同じ語彙を持つLlama 3.2 1B Instructを使う例で説明します。

Speculative Decodingを試すGPUは、次の2点を軸に選びます。

• ターゲット＋ドラフト＋KVキャッシュが余裕をもって載るVRAM

• デコード速度を左右するメモリ帯域

演算性能（FLOPS）よりも、この2点が効果を左右しやすいのがこの手法の特徴です。

FP16／BF16の重みは、おおよそ「パラメータ数×2バイト」です。

• 8Bモデル：約16GB

• 70Bモデル：約140GB

ここに、ドラフトの重み、両モデルのKVキャッシュ、vLLMの作業領域が加わります。

ターゲット単体でVRAMがぎりぎりだと、ドラフトを追加した途端に同時接続数や文脈長を削ることになり、比較の条件がそろいません。

低負荷時のデコードはメモリ帯域に律速されるため、帯域が広いGPUほど、通常生成そのものは速くなる傾向があります。

ただし、Speculative Decodingによる相対的な高速化率は、帯域だけでは決まりません。採択率、ドラフトの速さ、演算性能とのバランス、バッチサイズなどで変わります。

70BクラスのモデルをFP16/BF16で扱う場合、重みだけで約140GBになります。H200でも1枚ではドラフトやKVキャッシュを置く余裕がほとんどないため、次のどちらかが必要です。

• テンソル並列で複数GPUに分割する

• FP8などに量子化する

1枚に載らないモデルは、テンソル並列で複数GPUに分割します。

• 検証のforwardのたびにGPU間通信が発生するため、NVLinkなど高速な接続を持つ構成が有利

• ドラフトは小さいので、draft_tensor_parallel_sizeで別の並列数を指定でき

Speculative Decodingの対応方式は、vLLMのバージョンで大きく変わります。新しいvLLMを使うには、対応したPyTorch・CUDA・ドライバが必要です。

手元のマシンでドライバを更新できない場合や、OSごと環境を作り直したい場合は、クラウドの方が試しやすいことがあります。

モデル規模ごとのGPU構成の目安は、次のとおりです。

GPU環境を比べるときは、1時間あたりのGPU単価だけで判断しないことも大切です。同じモデル・設定でも、GPUの種類や枚数で出力スループットは変わります。

測定したスループットから、次のような処理量あたりの費用に換算して比べると、費用対効果を判断しやすくなります。

• 100万トークン生成あたりの費用

• 想定するリクエスト量を処理するための費用

Speculative Decodingの検証は、何度も起動し直して測る作業です。そのため、必要なときに必要な時間だけ使えるGPUクラウドと相性が良いといえます。

たとえば国内のGPUクラウドサービスGPUSOROBANでは、NVIDIA H200やB200を搭載した環境が提供されています。B200のクラスター環境は、GPU1枚・1分単位の課金で利用できます。

まず小さな構成で効果を確かめ、本番に必要なGPU枚数を見極めてから拡張する、という進め方も取りやすくなります。

Speculative Decodingに相性が良い高性能GPU・B200については、こちらの記事を参考にしてみてください。

Speculative Decodingは、ドラフトが先読みした候補をターゲットモデルがまとめて検証し、ターゲットの出力分布を保ったまま生成を速くする手法です。

• 目的：ターゲットの逐次ステップ数を減らす。量子化やKVキャッシュとは目的が異なり、多くの場合は併用できる

• 精度が変わらない根拠：採択確率min(1, p(x)/q(x))と、棄却時にmax(p−q, 0)を正規化した分布から引き直す規則

• 主な方式：Draft-Target・MTP・EAGLE系・N-gramなど。使えるモデルや追加メモリが異なる

• 速くなる条件：採択率とドラフトの軽さのバランス、負荷の高さ、VRAMの余裕で決まる。低～中負荷で効果が出やすい

• 導入：vLLMではspeculative_configで有効化。ベースラインを測り、候補数と同時接続数を変えて最適値を探す

効果は環境とワークロードによって大きく変わります。まずは自社のプロンプトに近いデータで、ベースラインとの比較から始めてみてください。