今回の論文
今回取り上げるのは、Yaniv Leviathan、Matan Kalman、Yossi Matias による 2023 年の論文「Fast Inference from Transformers via Speculative Decoding」です。公開元は ICML 2023 の Proceedings of Machine Learning Research で、研究分野は LLM 推論最適化、デコード高速化です。URL は https://proceedings.mlr.press/v202/leviathan23a.html です。
この論文を選んだ理由は、いまの LLM プロダクトで非常に重要な「品質は落としたくないが、応答は速くしたい」という要求に対して、かなり筋の良い原理を示した元論文だからです。後続の Medusa や各種 speculative decoding 系実装の土台でもあり、推論基盤を考えるうえで一度は押さえておきたい技術です。
どんな技術か
Speculative Decoding は、軽いドラフトモデルが数トークン先まで下書きを作り、その下書きを重い本命モデルがまとめて検証することで、自己回帰生成の逐次性を少し崩して高速化する技術です。
通常の LLM 生成では、1 トークン出すたびに大きなモデルを 1 回呼び出します。これが遅さの本質です。Speculative Decoding では、まず小さいモデルが「この先はたぶんこう続く」と複数トークンを提案し、その候補列に対して大きいモデルを並列に当てます。もし候補が十分もっともらしければ、1 回の本命モデル呼び出しで複数トークンを一気に確定できます。
重要なのは、単なる近似高速化ではなく、受理と棄却のルールを工夫することで、本命モデル単体で生成したときと同じ分布を保てる点です。つまり「多少ズレてもよいから速くする」ではなく、「出力品質と確率分布は維持しながら、無駄な逐次ステップを減らす」という立場の手法です。
課題
この技術が解決しようとしている課題は、大規模 Transformer の推論が本質的に逐次処理で、1 トークンずつしか前に進めないことです。モデルが大きくなるほど 1 ステップのコストは上がり、長文生成や対話では待ち時間が積み上がります。
何が難しいのかというと、次のトークンが確定しないと、その次のトークン分布も正しく計算できないことです。学習時は並列化できても、生成時は自己回帰の依存関係が残るため、巨大な GPU や TPU を使っていても逐次の壁が残ります。
既存の高速化には、量子化、蒸留、アーキテクチャ変更、早期終了のような方法がありますが、どれも一長一短です。モデル自体を作り替えたり再学習したりする方法は、研究としては強力でも、既存の本番モデルへ後付けしにくいことがあります。また、近似が強いと出力品質や分布が変わりやすく、評価や運用上のコストが増えます。
なぜこの課題を解く必要があるかというと、チャット、RAG、コード生成、エージェント、翻訳、要約のどれでも、レイテンシと GPU コストがそのまま UX と粗利に響くからです。特に、1 ユーザー向けの低バッチ推論や、長い回答を返す業務支援ツールでは、デコードの逐次性がかなり目立ちます。
実際の AI システムでは、モデルの重み読み出しやメモリ帯域がボトルネックになることも多く、計算器が遊んでいるのに 1 トークンずつしか進めない場面があります。Speculative Decoding は、この「計算資源はあるのに逐次生成が詰まる」問題に対して、並列検証で切り込む技術です。
用語解説
- 自己回帰デコード
- 過去に生成したトークン列を条件にして、次の1トークンを順番に生成していく方式です。LLM推論の標準形ですが、1ステップずつしか進めないため、Speculative Decoding が崩したいボトルネックそのものです。
- ドラフトモデル
- 本命モデルよりかなり小さく速い近似モデルです。この論文では Mq として表され、先読み候補を作る役割を持ちます。どれだけ本命モデルに近い予測を出せるかが受理率を左右します。
- 受理率
- ドラフトモデルが提案したトークンが、本命モデルの基準でもそのまま採用できる割合です。論文ではこの値が高いほど、1回の検証で複数トークンを前に進めやすくなり、速度改善が出やすいと整理されています。
- Rejection Sampling
- 候補をそのまま受け入れるか、確率に基づいて棄却するかを決めるサンプリング法です。この論文では単なるフィルタではなく、分布を厳密に保つための中心的な仕組みとして使われています。
- 出力分布の一致
- Speculative Decoding を使っても、本命モデル単独で通常デコードしたときと同じ確率分布からサンプルされることを指します。実務では品質比較や安全性評価をやり直さずに済みやすいので、かなり重要な性質です。
技術の仕組み
この論文の核は、「小さいモデルで下書きして、大きいモデルでまとめて答え合わせする」だけではありません。答え合わせのしかたを工夫して、棄却が起きても最終分布が崩れないように設計しているところが本質です。
基本アイデア
本命モデルを Mp、ドラフトモデルを Mq とします。まず Mq が現在の prefix から γ 個のトークンを自己回帰で先読みします。次に Mp が、その prefix と途中までの候補列に対する分布を並列に計算します。
これにより、通常なら 1 トークンにつき 1 回必要だった本命モデルの評価を、1 回で複数位置ぶんまとめて行えます。候補がすべて妥当なら、1 回の検証で最大 γ + 1 トークン進みます。少なくとも 1 トークンは必ず進むので、通常デコードより悪化しにくい構造です。
受理と棄却のルール
各候補トークンは、ドラフトモデルの確率 q と本命モデルの確率 p を比較して受理されます。直感的には、ドラフトが本命より強気に出しすぎていない候補は受け入れやすく、ズレが大きい候補は棄却されやすくなります。
論文では、候補トークン x を q(x) からサンプルしたあと、q(x) <= p(x) ならそのまま保持し、q(x) > p(x) のときは確率 1 - p(x) / q(x) で棄却します。ここが rejection sampling の部分です。
ポイントは、棄却したら単純に本命モデルの分布へ戻るのではなく、max(0, p - q) を正規化した補正分布から再サンプルすることです。これにより、ドラフト側で先に使ってしまった確率質量をきちんと差し引けます。結果として、最終的なサンプルは本命モデル Mp から直接引いた場合と同じ分布になります。
なぜ速くなるのか
通常の自己回帰生成では、本命モデルのシリアル呼び出し回数は生成トークン数と同じです。Speculative Decoding では、受理されたぶんだけこの回数を減らせます。
論文では、受理率を高く保てるなら、1 回の本命モデル呼び出しで平均して複数トークンを生成できます。ドラフトモデルの実行コスト c が小さく、受理率 α がそれを上回れば、全体の wall time 改善が見込めると理論化しています。実験では、ドラフトモデルが本命モデルより 2 桁程度小さい場合、c は 0.05 未満になることが多いと報告されています。
モデル選びの勘所
ドラフトモデルは小さければよいわけではありません。小さすぎると外れが増えて受理率が落ち、せっかく先読みしても棄却が増えます。逆に大きすぎると、本命モデルとの差が縮んでもドラフト自体が重くなり、速度改善が薄れます。
論文では、本命モデルより数桁小さい近似モデルがバランスを取りやすいとしています。たとえば T5-XXL 11B に対して T5-small 77M をドラフトにすると、翻訳と要約の両方で最も良い speedup が出ました。単に「より賢いドラフトほどよい」ではなく、受理率とコストの積で考えるべきだとわかります。
雑な近似でも意外と効く
この論文の面白い点は、unigram や bigram のような単純な近似でも、受理率がゼロにはならないと示したことです。英独翻訳では、bigram モデルでも受理率がおよそ 0.2 あり、γ = 3 で 1.25 倍程度の改善が見込めると報告されています。
これは実務上かなり示唆的です。つまり、必ずしも追加学習済みの高品質ドラフトがなくても、タスクに応じて軽い近似器を置く価値があるかもしれません。たとえば定型応答、構造化出力、繰り返しが多い UI では、簡易的なドラフトでも効く可能性があります。
実験と結果
論文の実験は、単なる理論速度ではなく、実際の wall time がどれだけ改善するかを見ています。特に T5-XXL の実装で、本当に 2 倍から 3 倍クラスの改善が出るかを確かめているのが重要です。
何を検証したのか
主な検証は 2 つです。1 つ目は、Speculative Decoding を実装したとき、本命モデルの通常デコードに対してどのくらい速くなるかです。2 つ目は、どの程度の受理率が実際に得られるかを、モデル規模やタスクごとに測ることです。
使ったデータセットや評価設定
wall time の評価では、T5 version 1.1 の encoder-decoder 構成を使い、英独翻訳は WMT EnDe、要約は CNN/DailyMail で fine-tune された T5-XXL 11B を本命モデルにしています。ドラフトモデルには T5-small 77M、T5-base 250M、T5-large 800M を使い、batch size 1、単一 TPU-v4 で argmax と通常サンプリングの両方を測っています。
受理率の観測では、ほかに 97M の GPT-like モデルによる言語生成と、137B の LaMDA による対話タスクも使われています。論文は 1 つのモデルに閉じず、decoder-only と encoder-decoder の両方で考え方が通ることを確認しています。
どのような結果が出たのか
T5-XXL の翻訳タスクでは、T5-small をドラフトにすると、argmax で 3.4 倍、通常サンプリングで 2.6 倍の speedup が出ました。要約タスクでも、argmax で 3.1 倍、通常サンプリングで 2.3 倍の改善が出ています。
一方で、ドラフトを T5-large に大きくすると受理率は上がっても速度は落ちました。たとえば翻訳の argmax では、T5-large の受理率は 0.82 と高いのに、speedup は 1.7 倍に留まっています。これは、ドラフトが賢くなってもコストが重すぎると得しないことをよく示しています。
受理率そのものを見ると、T5 系ではおおむね 0.5 から 0.8 台、GPT-like 97M に対する 6M ドラフトでは 0.88 から 0.89、LaMDA 137B に対する 2B や 8B のドラフトでも 0.71 から 0.75 程度が出ています。つまり、十分に小さいがタスクに合ったドラフトを用意できれば、かなり高い確率で候補を前倒し受理できます。
結果から何が言えるのか
この結果から言えるのは、Speculative Decoding は「たまたま一部のモデルだけで効く小技」ではなく、かなり一般的な推論高速化の原理だということです。特に batch size 1 に近い条件でも 2 倍から 3 倍の改善が出ているので、チャットや業務支援のようなリアルタイム用途と相性がよいです。
また、速度改善は単純にドラフトの精度だけで決まるわけではありません。受理率 α とドラフトコスト c のバランスが重要で、ここを外すと「賢いけれど重いドラフト」を使って逆に得を減らしてしまいます。これは実装時の重要な設計指針です。
何に使える？
Speculative Decoding は、既存の LLM の品質をできるだけ保ったまま応答を速くしたい場面で広く使えます。特に、モデルの入れ替えや再学習より、推論レイヤーの工夫で改善したいケースに向いています。
チャットや社内アシスタント
ユーザーが 1 人ずつ問い合わせるチャットや社内アシスタントでは、batch size が小さく、1 回ごとの待ち時間がそのまま体感速度になります。Speculative Decoding はこの条件で効きやすく、回答品質の大きな再評価なしにレイテンシを下げられる可能性があります。
コード生成や構造化出力
コード補完、SQL 生成、JSON 生成のように、出力の局所パターンが比較的読みやすいタスクでは、ドラフトモデルの予測が当たりやすい可能性があります。複数トークンをまとめて前進しやすいので、IDE 補完や開発支援ツールの応答改善に向いています。
エージェントの中間ステップ
エージェントは長文回答だけでなく、ツール選択、観測要約、次アクション決定など、短い生成を何度も行います。この反復が多いワークフローでは、1 ステップあたりのデコードコスト削減が累積で効いてきます。最終回答より内部推論のほうが回数が多い設計では特に有効です。
既存サービスの推論基盤改善
すでに十分な精度のモデルがあり、モデル刷新よりも GPU 単価や応答待ちを改善したい SaaS でも使えます。特に speculative decoding 対応の推論エンジンを採用すれば、モデル本体を変えずに改善余地を取りにいけます。
開発や事業へのヒント
この論文から得られる大きなヒントは、LLM プロダクトの差はモデル精度だけでなく、推論の進め方でも作れるということです。実務では「どのモデルを使うか」と同じくらい、「そのモデルをどう速く回すか」が重要です。
ドラフトモデルは独立したプロダクト設計対象になる
Speculative Decoding では、ドラフトモデルは単なる補助ではなく、速度改善の中核です。自社プロダクトに多い問い合わせパターンや出力形式がわかっているなら、その分布に合わせた小型ドラフトを作る価値があります。これは本命モデルの再学習より軽く、かなり現実的な差別化ポイントになりえます。
小規模プロダクトでも応用しやすい
この手法は巨大研究所だけのものではありません。小規模チームでも、既存の小型モデルやタスク専用ルールベース近似をドラフトとして置けるなら、限定的な形で試せます。たとえば JSON テンプレート補完や定型メール下書きでは、軽い先読み器でも十分機能するかもしれません。ここは推測を含みますが、論文の bigram の結果を見る限り、雑な近似でもゼロでは終わらないという発想は持ってよさそうです。
モデル変更の前に推論経路を見直す
応答が遅いとすぐに軽量モデルへ切り替えたくなりますが、品質低下が痛い場面では、まず speculative decoding のような推論最適化を検討するほうが筋が良いことがあります。品質評価や業務導入のし直しを避けつつ、原価と UX の両方を改善できる可能性があるからです。
今後注目すべき方向性
この論文以降、self-speculative decoding、dynamic speculation lookahead、Medusa のような派生手法が増えています。共通する方向性は、「どこまで先読みするか」「ドラフトを別モデルにするか、同一モデル内部に持つか」「受理率をどう上げるか」です。今後も推論最適化ではかなり重要な系譜として追う価値があります。
限界
まず、Speculative Decoding は追加の並列計算資源があることを前提に効く技術です。論文でも、メモリ帯域が律速で計算資源に余裕がある環境では有効だが、追加計算資源がない構成では助けになりにくいと明示しています。
また、ドラフトモデルの選定がかなり重要です。小さすぎると受理率が落ち、大きすぎるとドラフトの計算コストが増えて、速度改善が薄れます。つまり「とりあえず何か小さいモデルを置けば速くなる」わけではありません。
実装も単純ではありません。本命モデルとドラフトモデルのトークナイザ、サンプリング処理、KV キャッシュ、並列実行をきちんと整合させる必要があります。現在は各推論エンジンがかなり吸収してくれますが、自前でやると難易度はそれなりに高いです。
さらに、論文の主な wall time 評価は batch size 1 の設定です。高バッチ時や実運用の複雑なスケジューリングでは、効果の出方が変わる可能性があります。実際の導入では、自社のトラフィック分布、出力長、ハードウェア構成で再評価したほうがよいです。
よくある質問
Q. Speculative Decoding は出力品質を落とす高速化ですか？
A. 論文の方式では、正しく受理と棄却を行えば、本命モデル単独で通常デコードした場合と同じ分布を保てます。そのため、理論上は品質を落とす近似ではなく、計算の進め方を変える高速化です。
Q. なぜ小さいドラフトモデルを挟むだけで速くなるのですか？
A. 小さいモデルが先に複数トークンを提案し、それを大きいモデルがまとめて検証できるからです。候補がよく当たると、本命モデルの逐次呼び出し回数が減り、結果として wall time が短くなります。
Q. ドラフトモデルは大きいほど有利ですか？
A. そうとは限りません。大きいほど受理率は上がりやすいですが、ドラフト自体が重くなります。論文でも T5-large より T5-small のほうが speedup が高く、受理率とコストのバランスが重要だと示されています。
Q. どんなプロダクトで導入価値が高いですか？
A. 低バッチのチャット、コード生成、エージェント内部処理、構造化出力 API などです。共通点は、1 回ごとの体感レイテンシが重要で、モデル品質は維持したいことです。
Q. Medusa や self-speculative decoding との関係は何ですか？
A. Speculative Decoding はこの系統の基本形です。Medusa は別ドラフトモデルの代わりに追加ヘッドで候補を作る方式で、self-speculative decoding は同一モデルの一部を軽いドラフトとして使う方向です。どれも「本命モデルの呼び出し回数を減らす」という発想を共有しています。
今日の学び
この論文は、LLM 推論が遅い根本原因として、自己回帰デコードの逐次性を扱いました。これに対して、小型ドラフトモデルで候補を先読みし、本命モデルでまとめて検証する Speculative Decoding を提案し、しかも受理と棄却の設計によって出力分布を保てることを示しました。
ここから得られるヒントは、推論最適化はモデル性能と別の独立した競争力だということです。自社アプリの問い合わせ分布や出力形式に合うドラフトを設計できれば、モデルを替えずに UX と原価を同時に改善できる余地があります。