7月25日、vettedconsumer.comが「Speculative Decoding, Explained: The Free Speed Toggle Your Local LLM Is Probably Not Using」と題した記事を公開した。LM StudioやLlama.cppには、モデルの出力を一切変えずに生成速度を1.5〜2.5倍に引き上げられる設定が存在する——それが「Speculative Decoding（投機的デコーディング）」だ。ほとんどのユーザーはオフのまま使っており、オンにしてもペアリングを間違えて逆に遅くなるケースも多い。
「設定一つで速くなる」のに、なぜ誰も使っていないのか
LM StudioやLlama.cppには、モデルの出力を一切変えずに生成速度を1.5〜2.5倍に引き上げられる設定が存在する。量子化を下げるわけでも、小さいモデルに乗り換えるわけでもない。同じモデルが、数学的に同一の回答を、より速く返す。
それがSpeculative Decodingだ。ほとんどのユーザーはオフのまま使っている。オンにしても、ペアリングを間違えて逆に遅くなるケースも多い。
なぜ効くのか：GPUの「待ち時間」を埋める発想
トークン生成がなぜ遅いかを理解すると、この手法の本質が見えてくる。
LLMの生成速度はGPUの演算性能（TFLOPS）ではなく、メモリ帯域幅によって制約される。新しいトークンを1つ生成するたびに、GPUはモデルの重みをVRAMから読み出す必要があり、演算ユニットはその間ほぼ待機している。プロンプト処理（Prefill）が数百トークン/秒で動くのに、生成（Decode）が20トークン/秒程度に落ちるのはこのためだ。
Speculative Decodingはこの「待ち時間」を利用する。仕組みはシンプルだ：
- ドラフトモデル（小さくて速いモデル）が次のトークンを数個まとめて予測する
- メインモデルがその予測をまとめて1回のパス（並列処理）で検証する
- 合っていた予測はそのまま採用。最初に外れた箇所からはメインモデルの出力に切り替える
ここで重要なのが「ロスレス（lossless）」という性質だ。これは近似ではない。検証ステップにはリジェクションサンプリングが使われており、メインモデル単体で生成した場合と確率分布が数学的に同一になることが証明されている。Googleの原論文（Leviathan et al., 2022）も「出力分布を変えることなくスピードアップを実現する」と明記している。
2026年の転換点：ドラフトモデルが「同梱」される時代へ
従来のSpeculative Decodingには「互換性のあるドラフトモデルを自分で探す」という手間があった。これを解消したのがMulti-Token Prediction（MTP）だ。モデル開発者がドラフトヘッドをモデル本体に組み込んで配布するため、ユーザーは何も考えずに投機的デコーディングを使える。
2024年末にDeepSeek-V3の技術レポートがMTPの活用を示して以降、2026年には主要モデルが相次いで対応した：
- Qwen 3.6：MTPレイヤー搭載。llama.cppが今春
--spec-type mtpフラグでサポート。M2 Max 96GBで27Bモデルを動かしたユーザーがr/LocalLLaMAに報告している：
「結果は驚異的。2.5倍の速度向上で28 tok/sに到達した」
- Gemma 4：2026年5月にGoogle自身が公式MTPドラフターチェックポイントを全サイズ向けにリリース。Ollama・vLLM・SGLang・MLXで対応済み。Googleは「標準生成と完全に同一の品質を保ちつつ最大3倍」と主張している。
r/LocalLLaMAのあるユーザーはMTPとクラシックなSpeculative Decodingの違いをこう整理している：
「MTPはSpeculative Decodingの一種。従来のspec decが独立したドラフターを使うのに対し、MTPではメインモデル自体が追加の出力ヘッドを持ち、メインモデルの状態を活用してドラフトする。数学は同じ、ドラフターの精度が上がり、セットアップがゼロになる」
実際にオンにする方法
| ランタイム | 方法 |
|---|---|
| LM Studio | Speculative Decodingパネルで同一ファミリーのドラフトモデルを選択（例：Qwen 2.5 14B + Qwen 2.5 0.5B）。採用トークン数をリアルタイム表示 |
| llama.cpp（クラシック） | llama-server -m big.gguf --model-draft small.gguf --spec-draft-n-max 3（同一トークナイザーが必須） |
| llama.cpp（MTPモデル） | --spec-type mtp --spec-draft-n-max 3（Qwen 3.6・Gemma 4対応GGUFに対して） |
| llama.cpp（ドラフト不要） | --spec-type ngram-mod：直近のトークンのパターンマッチングでドラフト。追加VRAMゼロ |
| Ollama | Gemma 4 MTPはModelfileのDRAFTコマンドで対応 |
n-gramバリアントはVRAMが逼迫している環境で特に有効だ。追加モデル不要でコストゼロ。コード編集・RAG・要約のように「入力テキストを大量に引き写す」タスクでは実測での速度向上が得られる。
ドラフトモデルを使う場合のペアリングルールは2点：①ドラフトとメインモデルは同一ファミリー（Qwen→Qwen、Llama→Llama）、②ドラフトはメインモデルの1/10程度のサイズが目安。LM Studioの推奨は「8Bモデルに1Bドラフト、32Bモデルに1.5Bドラフト」だ。
逆効果になる3つのケース
1. 高速なMoEモデル
2026年において最も重要な落とし穴がこれだ。RTX 3090上でQwen3.6-35B-A3Bを対象に19種類の投機的デコーディング設定を検証した独立ベンチマークでは、ベースライン135.7 tok/sに対して最良の投機的設定でも131.1 tok/s（3%遅い）、最悪のケースでは15%遅くなった。採用率がほぼ100%でも、だ。
原因はMoE（Mixture-of-Experts）のルーティングにある。ドラフトトークンを検証する際、それぞれ異なるエキスパートのウェイトをロードする必要があり、並列検証の恩恵が消える。すでに速いモデルほど、投機的デコーディングで得られるものは少ない。
2. 高温度でのクリエイティブ生成
次のトークンが高度に不確定な状況では、ドラフトの採用率が低下し損益分岐点を下回る。コード生成・構造化出力・低temperatureのタスクが最も恩恵を受けやすく、自由なプロズは最も効果が出にくい。
3. VRAMの逼迫
1Bドラフトモデルの追加でメインモデルの量子化を下げる必要が生じるなら、得られる速度向上以上のものを失う可能性がある。
判断の基準は「採用率」
LM StudioもLlama.cppも採用率（acceptance rate）をリアルタイムで表示する。この数字だけ見ていれば判断は単純だ：
- 70%以上→利益が出ている（元記事記載の閾値）
- 60%未満→ドラフトを変えるか、オフにする（同）
ベンチマーク数値はあくまで参考で、自分のワークロードで実測することが唯一の正解だ。MoEの3090結果が示すように、他人の環境での数字は当てにならない。
詳細はSpeculative Decoding, Explained: The Free Speed Toggle Your Local LLM Is Probably Not Usingを参照していただきたい。
