Speculative Decoding（投機的デコーディング）とは？仕組みと速くなる条件、LM Studio・llama.cpp・vLLMでの設定

Speculative Decoding（投機的デコーディング）は、小さなドラフトモデルが数トークン先まで下書きし、本命のターゲットモデルがその下書きを1回の推論でまとめて検証する高速化手法です。受理と棄却の規則が確率的に設計されているため、出力の分布はターゲットモデル単体で生成した場合と一致します。品質を落とさずに速くなる、というのはこの規則の帰結です。

ただし、受理率とドラフトの軽さの条件を外すと単体より遅くなります。本記事では、品質が保たれる理由、倍率の見積もり式、日本語での実測値、LM Studio・llama.cpp・vLLM・Transformersでの設定、使わないほうがよい場面を、原論文と公式ドキュメントに沿って整理します（2026年9月28日時点）。

まとめ：Speculative Decodingの要点

• ドラフトモデルがγ個のトークンを提案し、ターゲットモデルが1回の順伝播で全位置を検証します。各トークンは確率 min(1, p(x)/q(x)) で受理され、最初に棄却された位置では残差分布から1トークンを引き直します。
• この規則により出力分布はターゲットモデルと一致します。原論文はT5-XXLで2〜3倍、DeepMindはChinchilla 70Bで2〜2.5倍の高速化を報告しています。
• 速さを決めるのは受理率αとコスト比c（ドラフト1トークンの時間÷ターゲット1トークンの時間）です。日本語要約の実測では、ドラフト47Mで2.02倍、247Mで0.90倍と、大きすぎるドラフトは逆効果でした。
• LM Studioは0.3.10（2025年2月18日）で対応し、現行の安定版は0.4.25です。0.4.19以降の既定（Engine Protocol有効）では、モデルのLoad Parameters > Advanced > Speculative Decodingでドラフトを指定します。
• llama.cppは --spec-draft-model（-md）、vLLMは --speculative-config、Transformersは assistant_model で有効化します。llama.cppの旧オプション --draft-max は削除済みです。
• 同時リクエストの多い高スループット運用、受理率の低い創作系タスク、VRAMに余裕のない環境では、導入前に実測で効果を確かめてください。

Speculative Decodingの仕組み：ドラフトの下書きとターゲットの一括検証

1トークンずつの生成が遅い理由

GPU上の密なモデルを小さなバッチで動かす場合、デコードの各ステップでは大部分の重みの読み出しが必要になり、メモリ帯域が速度を制限しやすくなります。この段階（デコード）は計算量に比べてメモリ転送が重く、GPUの演算器は待ち時間の多い状態です。そのため、1トークン分の順伝播と、数トークン分を並べた順伝播の所要時間はあまり変わりません。

Speculative Decodingはこの余った計算能力を使います。安いドラフトモデルに先読みさせ、高価なターゲットモデルは「数トークンをまとめて採点する」ためだけに呼び出す構成です。vLLMの公式ドキュメントも、対象を「QPSが中〜低程度でメモリ律速のワークロード」のトークン間レイテンシ短縮と位置づけています。LLM推論のPrefillとDecodeの違いや、KVキャッシュ・連続バッチングを含む高速化の全体像はLLM推論の仕組みと高速化手法の解説にまとめています。

受理・棄却の規則と出力分布が変わらない理由

1回の反復は次の順に進みます。記号は、ターゲットモデルの確率分布をp、ドラフトモデルの確率分布をqとします。

1. ドラフトモデルが自己回帰でγ個のトークンを提案する（qからサンプリング）。
2. ターゲットモデルが、γ個の提案を並べた入力に1回だけ順伝播し、γ+1位置ぶんのpを得る。
3. 先頭から順に、提案トークンxを確率 min(1, p(x)/q(x)) で受理する。
4. 棄却が起きた位置では、残差分布 norm(max(0, p(x)−q(x))) から1トークンを引き直し、以降の提案は捨てる。
5. γ個すべてが受理されたら、γ+1位置目のpからもう1トークンを追加する。

ドラフトが確率を過大評価したトークン（q>p）は割り引いて受理し、過小評価したトークン（p>q）は棄却時の引き直しで補う、という対称な設計です。結果として、各位置のトークンはpからサンプリングした場合と同じ分布に従います。Leviathanらの論文とChenらの論文はいずれもこの一致を証明しています。

数式を追わなくても、シミュレーションで確かめられます。語彙5トークンの玩具分布で20万回サンプリングしたPythonコードと、その実行結果です（Python 3.9.6・NumPy 2.0.2で実行）。

import numpy as np

rng = np.random.default_rng(0)
V = 5                                         # 語彙5トークンの玩具モデル
p = np.array([0.40, 0.25, 0.15, 0.12, 0.08])  # ターゲット（大）の分布
q = np.array([0.20, 0.40, 0.20, 0.10, 0.10])  # ドラフト（小）の分布

def speculative_step():
    x = rng.choice(V, p=q)                    # ドラフトが1トークン提案
    if rng.random() < min(1.0, p[x] / q[x]):  # 受理確率 min(1, p/q)
        return x, True
    resid = np.maximum(p - q, 0.0)            # 棄却時は残差分布から引き直す
    return rng.choice(V, p=resid / resid.sum()), False

N = 200_000
out = np.empty(N, dtype=int)
acc = 0
for i in range(N):
    out[i], a = speculative_step()
    acc += a

print("target p      :", p)
print("observed freq :", np.round(np.bincount(out, minlength=V) / N, 3))
print("accept rate   :", round(acc / N, 3))
print("1 - TVD(p,q)  :", round(1 - 0.5 * np.abs(p - q).sum(), 3))

target p      : [0.4  0.25 0.15 0.12 0.08]
observed freq : [0.402 0.25  0.149 0.12  0.079]
accept rate   : 0.78
1 - TVD(p,q)  : 0.78

ドラフトの分布qはターゲットと大きく違うのに、出力の頻度はpと小数第2位まで一致しました。受理率0.78は、2つの分布の全変動距離（TVD）から計算した 1−TVD(p,q) と同じ値です。つまり受理率は「ドラフトの分布がターゲットにどれだけ似ているか」で決まり、品質には影響しません。分布の似ていないドラフトを選んでも出力は壊れず、遅くなるだけです。

実装上の注意として、vLLMのドキュメントは「理論上はロスレスだが、ハードウェアの浮動小数点精度やバッチサイズの違いにより出力がわずかに変わりうる」と明記しています。温度0の生成を有効化前後でビット単位まで一致させる用途では、この点を前提に検証してください。

「投機的」とデコーディングの意味

speculativeは「投機的な・見込みでの」という意味で、原論文（Leviathanら）は着想元としてCPUの投機的実行（speculative execution）を挙げています。分岐の結果が出る前に先の命令を実行しておき、外れたら捨てる。ドラフトの下書きを先に進めて、棄却された分を捨てる動きがこれに対応します。デコーディングは、モデルが出力する確率分布から実際のトークン列を選び出す処理を指し、貪欲法（greedy）・サンプリング・ビームサーチがその方式です。Speculative Decodingはこれらを置き換えるものではなく、既存のサンプリングと同じ分布を速く得るための実行方式です。

高速化倍率を左右する受理率α・ドラフト長γ・コスト比c

高速化倍率を見積もる式と早見表

各位置の受理率を独立同分布と近似し、その平均をα、1回の提案数をγとすると、ターゲットモデル1回の検証で確定する期待トークン数は (1−α^(γ+1))/(1−α) です（Leviathanらの式）。さらに、並列検証にかかる時間をターゲットの通常の1トークン生成と同じと近似し、ドラフトの重さを加えます。ドラフト1トークンの時間をターゲット1トークンの時間で割った値をコスト比cとすると、1反復の時間はターゲット単体の (γc+1) 倍になるため、期待される高速化倍率は (1−α^(γ+1))/((1−α)(γc+1)) で近似できます。この分数形はα≠1の場合に使い、α=1の場合の期待トークン数はγ+1、高速化倍率は (γ+1)/(γc+1) です。この式で計算した値が次の表です。

読み取れることは2つです。ドラフトが軽い（c=0.05）場合でも、γを増やせば常に倍率が伸びるわけではなく、α=0.6ではγ=5の1.91倍からγ=8の1.77倍へ下がります。ドラフトが重い（c=0.3）と、γを増やすほど下書きの時間がかさみ、α=0.6ではγ=5で1倍を割ります。「受理率が低めでドラフトが重い」組み合わせでは、提案数を1〜3に抑えるのが基本です。llama.cppの既定値がγ=3、Ollamaの別体ドラフトの既定値が4と控えめなのも、この性質に沿った設定と読めます。

論文と実装が報告する高速化倍率

論文の倍率は、それぞれ異なる機器・タスク・実装で測った値です。例えばLeviathanらのT5実験はGPUではなく単一のTPU v4、バッチサイズ1で行われています。ローカルPCで数十億パラメータのモデルを動かす場合は、LM Studioが告知で挙げた1.5〜3倍の幅を目安にし、自分のプロンプトで測るのが確実です。

日本語要約の実測：ドラフトの大型化による速度低下

日本語でSpeculative Decodingを検証した研究として、東北大学の林崎・能勢・伊藤による「日本語投機的デコーディングの検討」（言語処理学会 第30回年次大会、2024年3月、P7-19）があります。OpenCALMと同じトークナイザでサイズ違いの日本語モデルを学習し、409Mのターゲットに6M〜247Mのドラフトを組み合わせて、日本語ニュース要約（XLSum）のテストデータ889件をRTX 3090 1枚で生成しています。

ドラフトを大きくすると受理率は0.405から0.677まで上がりますが、コスト比cも0.026から0.745まで膨らみ、247Mではターゲット単体より遅くなりました。最も速かったのは受理率が中程度の47Mです。温度を1.0に上げると受理率が下がり、同じ47Mでも2.02倍から1.55倍に落ちています。この実験では47Mが最も速く、247Mは受理率の高さを計算コストが打ち消しました。ドラフトは受理率と計算時間を併せて選び、温度変更の影響もモデルとタスクごとに測ってください。

ドラフトの作り方の種類：別モデル・n-gram・Medusa・EAGLE・MTP

下書きを誰が作るかで方式が分かれます。下書きをターゲットで検証する考え方は共通ですが、受理規則と出力分布の保証は方式によって異なります。Medusaのtypical acceptanceや、本体も追加学習するMedusa-2を、元のターゲット分布を厳密に保つ方式と同一視することはできません。

n-gramは、要約・コード修正・RAGの回答のように入力の文字列が出力にそのまま現れるタスクで効きます。ドラフトモデルを用意できないときに最初に試す選択肢です。MTP（Multi-Token Prediction）はDeepSeek-V3などが学習時に組み込んだ複数トークン予測の層をドラフトとして流用するもので、学習手法としてのMTPとの関係はMTPが複数トークンを同時に予測する仕組みの解説で扱っています。Gemma 4のMTPはモデル本体とは別配布のドラフターで、vLLMのドキュメントも汎用のドラフトモデルではなく "method": "mtp" で指定するよう注記しています。

LM StudioでのSpeculative Decodingの設定手順

Draft Modelの指定場所：Engine Protocolの有無による違い

LM Studioは0.3.10（2025年2月18日）で、llama.cppエンジンとMLXエンジンの両方でSpeculative Decodingに対応しました。その後、設定の置き場所が変わっています。公式の変更履歴によると、LM Studio Engine Protocolを有効にするとSpeculative Decodingの設定は予測パラメータ側から Load Parameters > Advanced > Speculative Decoding へ移り、Engine Protocolは0.4.19で既定オンになりました。2026年9月28日時点の公式ダウンロードページの版は0.4.25なので、現行版では次の手順が基本です。

1. メインモデルのロード設定を開き、Load Parameters > Advanced > Speculative Decoding でドラフトモデルを指定する。
2. その設定でメインモデルをロードし、チャットを始める。
3. 0.3.10で追加された受理トークンの色分け表示をオンにすると、緑が多いほど下書きが効いていると判断できる。

Engine Protocolをオフにしている環境（Settings > Developer で切り替え）では、公式ドキュメントにある旧来の手順になります。UIのモードを Power User 以上にしてメインモデルをロードし、チャットのサイドバーの Speculative Decoding セクションで Draft Model を選びます。

LM Studioはメインモデルとドラフトモデルの組み合わせの互換性を自動で判定し、互換のあるものだけを候補に出します。Python SDK（lmstudio 1.2.0以降）からは、draftModel を渡すだけで使えます。ドラフトモデルを別途ロードする必要はありません。

import lmstudio as lms

model = lms.llm("qwen2.5-7b-instruct")
result = model.respond(
    "What are the prime numbers between 0 and 100?",
    config={"draftModel": "qwen2.5-0.5b-instruct"},
)
stats = result.stats
print(f"Accepted {stats.accepted_draft_tokens_count}/{stats.predicted_tokens_count} tokens")

最後の行が出す「受理されたドラフトトークン数/生成トークン数」は、出力中のドラフト由来トークンの割合であり、早見表の受理率αとは異なります。この比率は下書きが使われた程度を示しますが、高速化の判定には、同じプロンプト・生成条件でドラフト有効時と無効時の生成速度や所要時間を比較する必要があります。Gemma 4のMTPドラフターをLM Studioで使う手順と既知の不具合はLM StudioのMCP設定とGemma 4の動かし方で解説しています。

ドラフトモデルの選び方とサイズの目安

ドラフトモデルはメインモデルと同じ語彙（vocabulary）を持つ必要があります。同じモデルファミリーの小型版は候補になりますが、語彙・トークナイザや実行エンジンの条件を必ず満たすとは限りません。LM Studioの互換性判定で確認してください。LM Studioの公式ドキュメントが示す組み合わせ例と、高速化が見込めるドラフトの上限サイズは次のとおりです。

小さいパラメータ版が存在しないファミリーでは、互換性のある大小モデルを用意できる別のファミリーへ、メインモデルとドラフトモデルの組み合わせごと切り替えます。ドキュメントは、ドラフトが遅すぎるか提案の質が低い場合は速くならず、むしろ遅くなりうるとも明記しています。

llama.cpp・vLLM・Transformersで有効にする方法

llama-serverのドラフトモデル・方式・提案数の設定

現行のllama-serverは、ドラフトモデルを --spec-draft-model（別名 -md・--model-draft）で指定します。1回の最大提案数は --spec-draft-n-max（既定3）、最小は --spec-draft-n-min（既定0）です。以前の --draft-max・--draft-min は削除済みで、READMEには置き換え先の案内だけが残っています。もう1点、現行版は --spec-type の既定値が none です。EAGLE-3やMTPの一部はGGUFのメタデータから方式が推定されますが、通常の小型モデルをドラフトに使うときは --spec-type draft-simple を明示してください。古い解説記事のコマンドをそのまま使うと、ドラフトが働かないまま動くことになります。

llama-server \
  -m models/Qwen3-14B-Q4_K_M.gguf \
  --spec-draft-model models/Qwen3-0.6B-Q8_0.gguf \
  --spec-type draft-simple \
  --spec-draft-n-max 3 \
  --spec-draft-ngl all

--spec-type には draft-eagle3・draft-mtp・ngram-simple などもあり、カンマ区切りで複数を併用できます（2026年9月時点のmasterのllama.cppのSpeculative Decodingドキュメントに基づく）。

vLLMのspeculative-configによる方式と提案数の設定

vLLMはJSONオブジェクトで方式と提案数を渡します。method には draft_model・ngram・suffix・mtp・eagle3 などを指定し、num_speculative_tokens で1ステップあたりの提案数を決めます。2026年9月28日時点のPyPI最新版は0.30.0（9月22日公開）です。

vllm serve Qwen/Qwen3-14B \
  --speculative-config '{
    "method": "draft_model",
    "model": "Qwen/Qwen3-0.6B",
    "num_speculative_tokens": 5
  }'

vLLMの draft_model は、ターゲットとドラフトの語彙サイズ（config.jsonの vocab_size）が一致しないと起動時にValueErrorで止まります。Qwen3-14BとQwen3-0.6Bはどちらも151,936で一致しますが、LM Studioの組み合わせ例にあるQwen2.5 14B（152,064）と0.5B（151,936）は一致しません。llama.cppは語彙数の差が128以内なら中身を照合して受け入れるため、LM Studioで動く組み合わせがvLLMでは通らないことがあります。語彙の異なる組み合わせには use_heterogeneous_vocab がありますが、現状は貪欲法のドラフトサンプリングに限られます。方式ごとの設定キーはvLLMのSpeculative Decodingドキュメントにまとまっています。vLLMの構成全体やOllamaとの使い分けはvLLMの仕組みと使い方の解説を参照してください。

Transformersのassisted generation設定と出力比較

Transformersでは、generate() に assistant_model を渡すと別モデルのドラフトが、prompt_lookup_num_tokens を渡すとn-gram方式が有効になります。トークナイザの異なる組み合わせは、tokenizer と assistant_tokenizer の両方を渡すUniversal Assisted Decodingで扱えます。

import statistics, time, torch
from transformers import AutoModelForCausalLM, AutoTokenizer

torch.set_num_threads(8)
torch.manual_seed(0)
tok = AutoTokenizer.from_pretrained("gpt2-medium")
target = AutoModelForCausalLM.from_pretrained("gpt2-medium")   # 355M
draft = AutoModelForCausalLM.from_pretrained("distilgpt2")     # 82M・同じGPT-2語彙
inputs = tok("The quadratic formula is", return_tensors="pt")

def run(**kw):
    run_once(**kw)                            # 方式ごとにウォームアップ
    times = []
    for _ in range(3):
        out, t = run_once(**kw)
        times.append(t)
    return out, statistics.median(times)      # 3回の中央値

def run_once(**kw):
    t = time.perf_counter()
    out = target.generate(**inputs, max_new_tokens=64, do_sample=False,
                          pad_token_id=tok.eos_token_id, **kw)
    return out, time.perf_counter() - t

base, t_base = run()
spec, t_spec = run(assistant_model=draft)
look, t_look = run(prompt_lookup_num_tokens=5)
print("same as baseline:", torch.equal(base, spec), torch.equal(base, look))
print(f"baseline {t_base:.2f}s / assisted {t_spec:.2f}s / prompt lookup {t_look:.2f}s")

same as baseline: True True
baseline 10.57s / assisted 7.46s / prompt lookup 7.21s

Intel Core i9-9880H（CPUのみ・8スレッド）・Python 3.11.15・PyTorch 2.2.2・Transformers 4.48.3で、方式ごとにウォームアップしてから3回測った中央値です。貪欲法では、どちらの方式も出力のトークン列が通常の生成と完全に一致しました。所要時間は通常の10.57秒に対し、別モデルのドラフトで7.46秒（約1.42倍）、n-gram方式で7.21秒（約1.47倍）です。ドラフトモデルなしのn-gram方式が並んだのは、GPT-2の貪欲生成が同じ2文を繰り返し、既出の文字列から下書きが当たり続けたためです。どちらが速いかはモデルと出力の性質で入れ替わるので、候補を並べて測るのが近道です。

Speculative Decodingを使わないほうがよい場面

次の条件に当てはまるなら、導入を急ぐ必要はありません。先に量子化やバッチングの変更余地を確認し、レイテンシ・スループット・品質への影響を比較してください。

• 同時リクエストの多い高スループット運用：大きなバッチではGPUの演算資源の余裕が減り、投機的デコーディングの追加計算によって効果が小さくなることがあります。vLLMの方式比較表でも、別モデルのドラフトは低QPSで効果大・高QPSで効果中と区分されています。
• 受理率の低いタスク：物語の生成のように次の語の候補が無数にある出力は、ドラフトの提案が棄却されやすくなります。LM Studioのドキュメントは、二次方程式の解の公式を答えるプロンプトと、物語の書き出しを続けるプロンプトを対比して説明しています。温度変更の影響は、同じモデルとプロンプトで比較してください。
• VRAMに余裕がない環境：ドラフトモデルの重みとKVキャッシュが追加で載ります。メインモデルの量子化を一段下げてまでドラフトを載せるのは本末転倒です。
• メインモデルに対して十分に軽いドラフトを用意できない場合：LM Studioの目安表には3B向けの推奨サイズがありませんが、3B以下で高速化できないという意味ではありません。採否はメインモデルの絶対サイズではなく、実測したコスト比cと受理率で判断します。

判断に迷ったら、ログで受理数・棄却数・棄却後に無視された提案数を区別し、受理数÷（受理数＋棄却数）から平均受理率αを推定し、ドラフト単体とメイン単体の生成速度からコスト比cを取り、先の式に入れてください。本記事では、見積もりが1.2倍未満なら導入を保留し、実測と運用負担を確認することを提案します。この値は論文由来の採用基準ではありません。NVIDIA GPUで本番運用する場合の選択肢はTensorRT-LLMの仕組みと採用判断でも比較しています。

よくある質問

Speculative Decodingとは何ですか？

小さなドラフトモデルが数トークン先まで下書きし、大きなターゲットモデルが1回の推論でまとめて検証して確定する、LLMの推論高速化手法です。日本語では投機的デコーディング、投機的デコードとも呼ばれます。本記事で扱う、ターゲットの出力分布を保つサンプリング方式は、2022年のLeviathanら（Google）と2023年のChenら（DeepMind）の論文で示されています。

投機的デコーディングで出力の品質は落ちませんか？

理論上は落ちません。受理確率 min(1, p/q) と棄却時の引き直しにより、出力分布はターゲットモデル単体と一致します。受理率が低いと遅くなるだけです。ただしvLLMは、浮動小数点精度やバッチサイズの違いで出力がわずかに変わりうると注記しています。

LM Studioでドラフトモデルが選択肢に出ないのはなぜですか？

主な原因は、メインモデルと語彙や実行エンジンの互換条件を満たす小型モデルが手元にないことです。LM Studioは互換性を自動判定し、互換のある組み合わせだけを候補に出します。同じファミリーの小さいパラメータ版（例：Qwen 2.5 14Bに対してQwen 2.5 0.5B）を試してください。設定場所は、Engine Protocol有効時（0.4.19以降の既定）が Load Parameters > Advanced > Speculative Decoding、無効時がPower User以上のモードで表示されるチャットのサイドバーです。

Speculative Speculative Decodingとは何ですか？

Tanishq Kumar、Tri Dao、Avner Mayによる論文（arXiv:2603.03251）が提案した手法（SSD）です。ターゲットモデルが検証している間に、ドラフト側が検証結果を予測して次の候補を先回りで用意します。要旨は、最適化済みのSpeculative Decoding比で最大2倍、通常の自己回帰デコード比で最大5倍の高速化を報告しています。

ClaudeやGeminiでもSpeculative Decodingは使われていますか？

Googleは公式ブログ「Looking back at speculative decoding」で、Google検索のAI Overviewsで応答品質を保ったまま生成を速めるために使っていると明記しています。ClaudeやGeminiアプリがどの方式をどう組み合わせているかは各社の推論基盤の内部構成にあたるため、採用の有無を判断材料にするなら各社の公式発表を確認してください。

関連記事

• LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】
• MTPが複数トークンを同時に予測する基本構造と仕組みの全体像
• LM StudioのMCP設定とGemma 4の動かし方｜OAuth・MTP高速化・Web検索
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説
• TensorRT-LLMとは？NVIDIA GPUでのLLM推論高速化の仕組みと採用判断を解説【2026年版】