2026-08-12·無料·論文·11分で読めます

投機的デコーディングを1から解説 — 小さな下書きモデルで、出力を一切変えずにLLMを速くする

小型モデルに数トークン先まで下書きさせ、大型モデルが一括検証する「投機的デコーディング」。出力分布を数学的に変えないまま2〜3倍速くなる仕組みを、採択率αの直感とともに原論文から解説する。

#inference #speculative-decoding #llm #efficiency #sampling

Fast Inference from Transformers via Speculative Decoding

一次資料 — この記事の根拠

論文の発表 2022-11-30→この解説の公開 2026-08-123年8か月後

Fast Inference from Transformers via Speculative DecodingYaniv Leviathan, Matan Kalman, Yossi Matias · 2022-11-30 · v2arXiv:2211.17192論文ページ·PDF

原文の要旨（Abstract）を読む

Inference from large autoregressive models like Transformers is slow - decoding K tokens takes K serial runs of the model. In this work we introduce speculative decoding - an algorithm to sample from autoregressive models faster without any changes to the outputs, by computing several tokens in parallel. At the heart of our approach lie the observations that (1) hard language-modeling tasks often include easier subtasks that can be approximated well by more efficient models, and (2) using speculative execution and a novel sampling method, we can make exact decoding from the large models faster, by running them in parallel on the outputs of the approximation models, potentially generating several tokens concurrently, and without changing the distribution. Our method can accelerate existing off-the-shelf models without retraining or architecture changes. We demonstrate it on T5-XXL and show a 2X-3X acceleration compared to the standard T5X implementation, with identical outputs.

なぜ、賢いAIほど返事が遅いのか

ChatGPTのようなモデルの文章は、1トークン（単語の断片）ずつ順番に生成されます。次のトークンを決めるには直前までの全文が必要なので、K個のトークンを出すにはモデルをK回、直列に動かすしかありません。論文はこの逐次性こそが遅さの根本原因だと指摘します（Abstract）。

もうひとつ、見逃されがちな観察があります。論文によれば、大規模モデルの推論のボトルネックは足し算掛け算の量ではなく、メモリ帯域と通信であることが多い（§1）。巨大な重みをメモリから読み出す時間が支配的で、せっかくの演算器は待ちぼうけしているのです。この「余っている計算力」を並列性で活用しよう、というのが本論文の出発点です。メモリ律速の背景はメモリの壁の記事で詳しく扱っています。

比喩: 若手の下書きと、編集長の赤入れ

編集長（大型モデル）が一語ずつ執筆するのは遅い。そこで若手ライター（小型モデル）に数語先まで下書きさせ、編集長は下書きをまとめて読んで「ここまでは私が書くのと同じ。ここから違う」と赤を入れる。編集長の仕事1回で複数語が一気に確定します。

元ネタはCPUの投機的実行（分岐予測など）です。「必要かどうか確認する前に、たぶん必要になる仕事を先にやってしまう」技法で、論文はこれを「仕事が確率的にしか決まらない」言語生成の世界へ一般化しました（§1）。

全体像: 下書き → 一括検証 → 修正（§2.1）

速くしたい本命をターゲットモデル $M_p$ 、下書き係を近似モデル（draft model） $M_q$ と呼びます。1回の反復はこう動きます。

$M_q$ が $\gamma$ 個のトークンを普通に（自己回帰で）下書きする
$M_p$ を「元の文」「元の文+下書き1個」…「元の文+下書き $\gamma$ 個」の $\gamma+1$ 通りに対して並列に1回走らせ、各位置の確率分布をまとめて得る
下書きを前から順に採択ルール（次節）で判定する。最初に棄却された位置は修正した分布から引き直し、全部通ったらおまけをもう1個サンプルする

この設計の利点は、 $M_p$ の1回の実行で最低1トークン、最大 $\gamma+1$ トークンが必ず確定すること。つまり最悪ケースでも $M_p$ の直列実行回数は普通の生成を上回りません（§2.1）。論文の図1では、97Mパラメータのターゲットが6Mの下書きモデルの助けを借り、38トークンの文をわずか9回の直列実行で生成しています。

下書きがどれだけ「当たる」かは、確率分布の形にも左右されます。論文の実験では、温度を下げて分布が尖っているほど採択率が高くなりました（§4.2）。分布の尖り方は次の図で体感できます。

FIG 1温度スライダーで次トークンの確率分布が尖ったり平らになったりする。論文の観測では、尖った（温度が低い）分布ほど下書きの採択率αが高かった（§4.2）

心臓部: 出力分布を変えない採択ルール（§2.3）

「小さいモデルの下書きを使ったら、出力の質が落ちるのでは？」——ここが本論文の最大の貢献で、投機的サンプリングという採択ルールにより、出力の確率分布はターゲット単独の場合と数学的に同一であることが保証されます（§2.3, §A.1）。近似が良ければ速く、悪くても遅くなるだけで、出力は一切変わらない。この虫のいい話を成立させるルールは、たった3行で書けます。ここからは、その中身と「なぜ分布が保たれるのか」の証明、そして速さを支配する採択率 $\alpha$ の正体まで一気に見ていきます。

下書きトークン $x$ について、ターゲットの確率を $p(x)$ 、下書きモデルの確率を $q(x)$ とすると、

$q(x) \leq p(x)$ なら無条件で採択
$q(x) > p(x)$ なら確率 $1-\frac{p(x)}{q(x)}$ で棄却
棄却したら、次の修正分布から引き直す

$p'(x) = \mathrm{norm}\big(\max(0,\; p(x) - q(x))\big)$

$p'(x)$ は「ターゲットが下書きモデルより多めに確率を割いている場所」だけを残し、合計が1になるよう正規化（norm）した分布です。下書き係が過小評価していたトークンほど、引き直しで選ばれやすくなります。つまり $p(x)$ は「編集長がその語をどれだけ書きたかったか」、 $q(x)$ は「若手がどれだけ書きたかったか」で、若手が盛りすぎた分を消し、編集長の言い分が残った所から引き直す、ということです。

これで本当に分布が保たれる証明は、論文§A.1でわずか数行です。あるトークン $x$ が最終的に選ばれる確率は「採択経由」と「棄却→引き直し経由」の和で、

採択経由: $q(x)\cdot\min(1, \frac{p(x)}{q(x)}) = \min(p(x), q(x))$
引き直し経由: $p(x) - \min(p(x), q(x))$

足すとちょうど $p(x)$ 。しかもこの証明は $q$ に何の条件も課していないので、下書きモデルは何を使ってもよい（§3.6）。numpyで書くとこれだけです。

def speculative_sample(p, q, x):        # x は M_q が引いた下書きトークン
    if np.random.rand() < min(1.0, p[x] / q[x]):
        return x                        # 採択
    resid = np.maximum(0.0, p - q)      # ターゲットが多めに賭けている所だけ残す
    return sample(resid / resid.sum())  # 修正分布から引き直し

採択率αがすべてを決める（§3.1–3.2）

下書きが通る確率を採択率 $\beta$ 、その期待値を $\alpha$ と呼びます。論文はきれいな定理を示しています: $\alpha$ は2つの分布の重なりの面積そのものです（Theorem 3.5, Corollary 3.6）。

$\alpha = \sum_x \min(p(x),\, q(x))$

つまり、下書きモデルとターゲットが「同じトークンに同じくらいの確率を割いている」ほど、下書きは通りやすい。 $\alpha$ はモデルとタスクの性質で決まる量で、これを測ればハードウェアに触れず高速化の見込みが立ちます。

そして、 $\beta$ が毎回独立同分布という単純化を置くと、 $M_p$ 1回あたりに確定するトークン数の期待値は次式になります（§3.1）。

E(\#\text{tokens}) = \frac{1-\alpha^{\gamma+1}}{1-\alpha}

(1)

読み方: ターゲット1回の実行で、平均何トークン進むか。言い換えると $\gamma$ は「若手が一度に下書きする語数」、 $\alpha$ は「その1語が通る確率」で、この分数は「編集長の赤入れ1回で何語ぶん進んだか」を表しています。全部通れば1回で $\gamma+1$ 語が片づく、ということです。 $\alpha$ が1に近い（下書きがよく当たる）ほど、また下書き長 $\gamma$ が大きいほど増えます。論文Table 1の例では、 $\alpha=0.8$ 、 $\gamma=5$ でコストを無視できる場合に3.69倍のスピードになります。

実測: 何も変えずに2〜3倍（§3.3, §4.1）

実時間の改善には、下書き自体のコストも入れる必要があります。下書きモデル1回とターゲット1回の時間比をコスト係数 $c$ とすると（論文の実験では下書きが2桁小さく、常に $c<0.05$ 。§3.3）、実時間の改善率は

$\frac{1-\alpha^{\gamma+1}}{(1-\alpha)(\gamma c+1)}$

分子は上の「1回で進むトークン数」、分母の $\gamma c+1$ は「下書き $\gamma$ 回+ターゲット1回」の時間です。つまり全体は「1往復で稼いだ語数 ÷ その1往復にかかった時間」。若手に長く下書きさせるほど分子は伸びますが、分母の $\gamma c$ も一緒に伸びる、というつり合いの式です。 $\alpha > c$ でありさえすれば必ず得になる $\gamma$ が存在し（Corollary 3.9）、最適な $\gamma$ は $\alpha$ と $c$ から数値的に求まります（§3.5）。

実験では、T5-XXL（11B）に既製のT5-small（77M）を下書き係として組み合わせ、再学習もアーキテクチャ変更も一切なしで、英独翻訳で3.4倍（argmax時）/2.6倍（温度1）、要約で3.1倍/2.3倍を実測しています（§4.1, Table 2）。LaMDA 137Bなど他モデルでも、2桁小さい下書きモデルで $\alpha$ は0.5〜0.9に収まりました（§4.2）。極端な例では、ただの2-gram表を下書き係にしても $\alpha\approx0.2$ が取れ、1.25倍の高速化になります（§3.6）。

タダ飯ではない: 演算量は増える（§3.4）

注意点をひとつ。 $M_p$ を $\gamma+1$ 通り並列に走らせるので、総演算量はむしろ増えます（Theorem 3.11）。下書きが棄却されればその分の計算は捨てられる。一方で、重みとKVキャッシュをメモリから読む回数は「1回で進むトークン数」分の1に減ります。だからこの手法は「演算器が余っていてメモリ帯域が詰まっている」典型的なLLM推論でこそ効く、と論文は位置づけています（§1, §6）。

論文の限界・まだ検証されていないこと

追加の計算資源がない構成では役に立たない。論文自身が§6で明言しています。演算がすでに飽和した環境では逆効果になりえます。
理論式は $\beta$ の独立同分布という近似の上に立っており、理論値と実測にはずれがあります（§A.3）。
実時間での検証はT5-XXLのみで、batch size 1・TPU-v4という条件です（§4.1）。LaMDA等は $\alpha$ の計測にとどまります。
ビームサーチとの両立は性能ペナルティ付きの素描のみで、分析は今後の課題です（§A.4）。
検証はテキスト生成のみで、画像などの他分野は未検証です（§6）。
付録では分布の同一性を緩めて（lenience）さらに速くする案も示されますが、サンプルの多様性を損なう可能性が指摘されています（§A.5）。本編の結果はすべて厳密版です。

現場ではこう使う

この技術を触るのは、主にLLMサービングを担当する推論基盤エンジニアです。チャットやコード補完のようにレイテンシが問われるAPIで、GPUを増やさずに応答を縮めたいときの定番手になっています。

実務上は、llama.cpp の --model-draft、vLLM の speculative decoding 設定（num_speculative_tokens が本論文の $\gamma$ に相当）など、主要サービング基盤に既に組み込まれています。チューニングの勘所は論文の理論がそのまま使えます: 触るのは実質 $\gamma$ だけで、上げすぎると棄却時の無駄計算が膨らむ（Table 1のトレードオフ）。 $\alpha$ はタスクと温度に依存するので、自分のトラフィックで実測してから決めるのが筋です。

事故になる落とし穴は3つ。第一に、大バッチで演算が既に飽和しているサーバでは効かないどころか悪化しうる（論文§6の限界そのもの）。効くのは低バッチ・レイテンシ重視の場面です。第二に、実務ではdraftとtargetのトークナイザ（語彙）が一致していないと下書きの突き合わせができません。論文の実験もすべて同一トークナイザで揃えています（§4.2）。第三に、温度が高いワークロードでは $\alpha$ が下がり効果が薄れます（Table 2で温度0と1の差を確認できます）。

面接で「なぜ出力を変えずに速くなるのか」と問われたら、§A.1の2行——採択経由の $\min(p,q)$ と引き直し経由の $p-\min(p,q)$ を足すと $p$ に戻る——で答えられれば十分です。

まとめ

投機的デコーディングは「小さいモデルに下書きさせ、大きいモデルが一括検証する」だけのシンプルな仕組みで、採択ルールの数学が出力分布の完全な同一性を保証します。速さの源泉は採択率 $\alpha$ ＝2つの分布の重なりで、既製モデルの組み合わせだけで2〜3倍の実測改善が出ました。推論高速化の他のアプローチは量子化の記事、前提となるメモリ律速の話はメモリの壁とKVキャッシュをどうぞ。

🎬 この内容の解説動画（Manim・字幕つき）