Lotook
speculative decodingは、出力品質を変えずにトークン生成を高速化するLLMの推論技術です。小さく高速なドラフトモデルが複数の候補トークンを先に提案し、より大きなターゲットモデルがそれらを一度の並列処理ですべて検証します。有効な予測を採用し、最初に不一致が起きた位置から再サンプリングすることで、ターゲットモデルの正確な出力分布を保ちます。
大規模言語モデルは通常、トークンを一つずつ生成して回答を作ります。出力の各ステップではモデルの重みをメモリから読み出す必要があり、メモリ帯域を待つ間、アクセラレータの演算能力を十分に活用できません。speculative decodingは、逐次的な確認を並列検証に変えることで、一ステップにつき一トークンというボトルネックを解消します。
標準的な自己回帰デコーディングはなぜ遅いのか？
標準的な自己回帰デコーディングが遅いのは、各トークンの生成にモデル全体の独立した順伝播が必要だからです。そのため、処理は演算能力ではなくメモリ帯域によって制限されます。
言語モデルが回答を書く際、各トークンはそれ以前のすべてのトークンに依存します。標準的なデコーディングでは、70 billion（七百億）のパラメータを持つモデルは、最初のトークンを生成するために高帯域メモリから重みを読み込み、次のトークンを生成するために同じ重みを再び読み込み、このサイクルを何百回も繰り返す必要があります。
しかし、回答中の多くのトークンは簡単に予測できます。機能語、コードの閉じ括弧、よくある言い回しや定型的な構文を正確に推測するために、巨大モデルの推論能力をすべて使う必要はありません。ただし、回答全体に対する最終判断は大きなモデルに任せたいものです。GPUやTPUは、短いトークン列を単一トークンの処理とほぼ同じ実時間で並列処理できるため、単一トークンのデコーディング中には余分な演算能力が遊んでいます。speculative decodingはこの余剰の並列演算能力を活用します。
speculative decodingはどのような手順で動くのか？
speculative decodingは、候補トークンの作成、ターゲットモデルによる並列検証、一致したトークンの採用、最初の棄却位置での再サンプリングという四段階のループを、回答が完成するまで繰り返します。
推論エンジンは、大きなターゲットモデルにすべてのトークンを順番に生成させる代わりに、はるかに小さく高速な近似モデル（一般にドラフトモデルと呼ばれます）を組み合わせます。各サイクルは次の四つの段階からなります。
- 候補トークンの作成： 現在の系列から、小さなドラフトモデルが$K$個の候補トークンを一つずつ素早く生成して短い先読み窓を作り、各位置の確率分布を記録します。
- 並列検証： 大きなターゲットモデルは元の系列とドラフトされた$K$個すべてのトークンを受け取り、一度の順伝播を行います。Transformerアーキテクチャは、プロンプト処理時と同様に既知のトークン系列を並列に評価できるため、ターゲットモデルは各ドラフト位置に対する自身の確率分布を同時に計算します。
- ドラフトトークンの採用または棄却： エンジンは$K$個のドラフトトークンを左から右に見て、正式な棄却サンプリングの規則（しばしばspeculative samplingと呼ばれます）を使い、各ステップでドラフトモデルとターゲットモデルの確率を比較します。貪欲デコーディング（温度ゼロ）では、ドラフトトークンがターゲットモデルの第一候補と一致すれば採用されます。サンプリングモードでは、ターゲットモデルがドラフトモデル以上の確率を割り当てたトークンは常に採用され、確率がそれより低いトークンはターゲットとドラフトの確率の比率に応じて採用されます。
- 再サンプリングとボーナストークンの生成： 最初の不一致が位置$m$で起きた場合、そのトークンと後続のすべてのドラフトトークンを破棄し、両モデルの確率を考慮して調整された残差分布から位置$m$の代替トークンを直接サンプリングします。$K$個のドラフトトークンがすべて採用された場合、ターゲットモデルは同じ並列処理ですでに位置$K + 1$の確率分布を得ているため、追加コストなしでボーナストークンをもう一つサンプリングできます。
棄却と再サンプリングの規則がドラフトモデルの誤りを数学的に相殺するため、speculative decodingは損失がありません。複数トークンを処理する各ステップで得られるサンプルは、ターゲットモデルだけを実行した場合とまったく同じ確率分布に従います。つまり、ベンチマーク精度、推論能力、文体は劣化しません。
speculative decodingは実際にどれくらい速いのか？
基礎研究では、適切に組み合わせたドラフトモデルと十分な並列演算能力があれば、speculative decodingによって大規模言語モデルの実時間が約2Xから3X高速化することが示されています。
この技術を2022年末から2023年初めに紹介した基礎論文では、モデルの重みや出力分布を変えることなく、エンコーダ・デコーダ型とデコーダのみの両方のTransformerで大幅なレイテンシ改善が示されました。
| 研究 | ターゲットモデル | ドラフトの構成 | 報告された実時間の高速化 | 条件とタスク |
|---|---|---|---|---|
| Leviathan et al. (2023) | T5-XXL（11Bパラメータ） | T5-small（77Mパラメータ） | 2X–3X（T5-smallの構成表では最大2.6X–3.4X） | そのまま利用できるT5Xの実装で、翻訳（EN-DE）と要約（CNN/DM）をargmax（temp 0）および標準サンプリング（temp 1）で実施。 |
| Chen et al. (2023) | Chinchilla（70Bパラメータ） | speculative sampling用に訓練された4Bパラメータのドラフトモデル | 2X–2.5X | TPU v4上の分散構成で要約（XSum）とコード生成（HumanEval）を実施。 |
両研究におけるターゲットモデルとドラフトモデルのサイズ差に注目してください。T5-smallはT5-XXLより約二桁小さく、4Bのドラフトモデルは70BのChinchillaモデルのごく一部の大きさです。ドラフトモデルは、その上で$K$回の逐次ステップを実行しても、ターゲットモデルの一ステップに比べて追加負荷がごく小さくなる程度に小さい必要があります。
採用率は何で決まり、なぜ高速化は保証されないのか？
speculative decodingの高速化は、ドラフトモデルとターゲットモデルの予測がどの程度一致するか（採用率）と、ハードウェアにどの程度の余剰の並列演算能力があるかという二つの主な要因に依存します。そのため、正味の高速化は決して保証されません。
ドラフトモデルが常に予測を外す場合、システムはドラフトモデルで$K$回の逐次ステップを実行するレイテンシを負担したうえで、最初のトークンをターゲットモデルに棄却されます。この最悪のケースでは、投機的な一サイクルで得られるのは再サンプリングされた一トークンだけで、通常のターゲットモデルの一ステップよりも時間がかかります。
speculative decodingが推論を高速化するか低速化するかは、いくつかの実用上の変数によって決まります。
- ドラフトモデルとターゲットモデルの整合性： ドラフトモデルはターゲットモデルとまったく同じトークナイザーと語彙を共有し、訓練分布もよく一致している必要があります。コード補完、構造化されたJSON出力、予測しやすい表現の翻訳では、多様なトークンが同じくらいあり得る高温度の創作よりも、一般に採用率が高くなります。
- ドラフトモデルによる追加レイテンシ： ドラフトモデル自体が大きすぎて遅い場合、採用率が高くても生成は高速化しません。Leviathan et al.は、より小さいT5-smallのドラフトモデルが、より大きいT5-baseやT5-largeの候補よりも実時間全体の高速化で優れたことを示しました。これは、各ステップでのドラフト作成の追加負荷がはるかに小さかったためです。
- 先読み窓の長さ（$K$）： 先読みが短すぎると、一度に検証できるトークン数が制限されます。長すぎると、前のトークンが棄却されたときに破棄される後続トークンのドラフト作成に時間を浪費します。
- 利用可能な並列演算能力（バッチサイズによる飽和）： speculative decodingは、未使用の演算能力を使ってレイテンシを下げます。バッチが小さくレイテンシが重要なサービスでは、アクセラレータに十分な余剰能力があり、ほぼ追加時間なしに$K$個のトークンを並列検証できます。同時処理のバッチが非常に大きくGPUの演算ユニットがすでに完全に飽和している場合、リクエストごとに$K$個の検証位置を追加すると処理時間が増え、高速化の効果が消えることがあります。
speculative decodingとKV cache、プロンプトキャッシュの関係は？
speculative decodingが高速化するのは出力生成のデコード段階だけです。一方、KV cacheの利用はトークン間のアテンションの再計算を避け、プロンプトキャッシュは繰り返される入力のプリフィルを高速化し、料金を割り引きます。
これら三つの最適化はいずれもTransformerの推論レイテンシに関わるため、開発者はリクエストのライフサイクルにおけるそれぞれの位置を混同しがちです。
- プリフィルとデコード： LLMへの各リクエストは二段階に分かれます。プリフィルでは入力プロンプトの全トークンを並列に処理して初期状態を構築します。この段階はすでに演算能力に制約され、トークン当たりの処理が高速です。デコードでは出力トークンを順に生成し、メモリ帯域に制約されます。speculative decodingが役立つのはデコード段階だけで、長い入力プロンプトの読み込みは高速化しません。
- KV cacheの役割： speculative decodingでは、ターゲットモデルとドラフトモデルの両方がそれぞれのKV cacheを使用します。候補トークンの作成と検証に伴い、それらのKeyとValueの状態がキャッシュに追加されます。ターゲットモデルが位置$m$より後のドラフトトークンを棄却すると、推論エンジンは両モデルのKV cacheを単に巻き戻して切り詰め、棄却されたエントリを除去してから次のサイクルを始めます。
- プロンプトキャッシュとの違い： プロンプトキャッシュは、別々のAPI呼び出しで同じプロンプトの先頭部分に対する計算済みKV cacheブロックを再利用し、最初のトークンまでの時間（TTFT）を短縮し、多くの場合は入力トークンの料金も下げます。speculative decodingは、回答をストリーミング出力する間のトークン間レイテンシ（ITL）を短縮します。
API開発者やセルフホスティング利用者にとってspeculative decodingは何を意味するか？
API開発者にとって、speculative decodingは独立した請求項目ではなく、ストリーミング全体のレイテンシ低下として現れます。一方、セルフホスティング利用者は、リクエストごとの応答性を改善するために推論エンジン内で直接設定します。
speculative decodingとの関わり方は、ホストされたモデルのエンドポイントを呼び出すか、独自のGPU群を管理するかによって異なります。
- ホスト型APIのトークン当たりの課金はほとんど変わらない： ホスト型AIプロバイダーは通常、ユーザーから見た処理済みの入力・出力トークンを百万トークン単位で課金します。プロバイダーが内部でspeculative decodingを使っていても、棄却されたドラフトトークンは配信エンジン内部のものであり、請求されるのは最終的に生成された出力トークンに対するモデルの標準料金です。待ち時間だけでなくAPIの直接費用を下げるには、プロンプトエンジニアリング、バッチAPI、AI APIのコストを削減する実践的な方法を検討するか、AIモデルの選び方を考える際に料金を比較してください。
- リアルタイムのユーザー体験への利点： アプリケーション開発者にとってspeculative decodingが特に役立つのはユーザー体験です。音声エージェント、IDEのコードアシスタント、ライブコーディングの支援ツールからAI Studio Videoのようなクリエイティブツールと組み合わせたスクリプトのパイプラインまで、インタラクティブな制作ワークフローは、性能の低いモデルに切り替えずに出力トークンが二倍の速さで届くと、体感的にかなり軽快になります。
- セルフホスティングでの設定： 重みが公開されたモデルを自社のインフラで動かす場合、配信スタックでspeculative decodingを直接設定します。ターゲットモデルとドラフトモデルの両方をGPUメモリに読み込み（またはドラフト不要の方式を使い）、両者がまったく同じトークナイザーを共有することを確認し、通常の同時実行数に合わせて先読みの長さを調整する必要があります。
別のドラフトモデルは常に必要なのか？
後に登場したspeculative decodingの派生手法では、同じドラフトと検証の原則を維持しながら、別の小さなドラフトモデルを訓練・デプロイする必要をなくしています。
二つの別々のモデルをメモリで管理し、ターゲットモデルとまったく同じトークナイザーを持ち、動作も一致する小さなモデルを見つけることは、運用上面倒な場合があります。この問題を解決するため、推論研究者や配信フレームワークは、ドラフトモデル不要の手法をいくつか導入しています。
- N-gramとプロンプト検索によるドラフト作成： トークンのドラフトにニューラルネットワークを使う代わりに、エンジンは入力プロンプトと最近生成された出力から一致するテキスト部分を探し、その後に続くトークンを候補としてコピーします。文書の要約、コードの編集、コンテキストウィンドウ内にすでに存在する引用の抽出で特に効果的です。
- 複数トークン予測ヘッドと補助層： 独立したモデル全体を維持する代わりに、少数の軽量な予測ヘッドやドラフト層をターゲットモデルの隠れ状態に直接接続し、次の数個のトークンを一度に提案できます。
- Self-speculative decoding： 構成によっては、ターゲットモデル自身の層の一部を使い、ドラフト時には中間層を飛ばして候補トークンを生成し、その後すべての層を実行して検証します。
候補トークンの提案方法にかかわらず、中心となる保証は同じです。完全なターゲットモデルが候補を並列検証し、採用された各トークンに対して自身の正確な確率分布を適用します。
よくある質問
speculative decodingはモデルの精度や出力品質を変えるのか？
いいえ。標準的なspeculative decoding（speculative sampling）は数学的に損失がありません。貪欲デコーディングでは、ターゲットモデルの最上位の予測と正確に一致するトークンのみを採用します。温度を用いたサンプリングでは、棄却と残差分布からの再サンプリングの規則により、生成系列はターゲットモデルでの標準的な自己回帰デコーディングとまったく同じ確率分布に従います。
speculative decodingは最初のトークンまでの時間（TTFT）を短縮するのか？
いいえ。最初のトークンまでの時間は、モデルがプリフィル段階で入力プロンプトを読み込み、最初の出力トークンを出すまでにかかる時間です。プリフィルではすでにプロンプトのトークンを並列処理しているため、speculative decodingが高速化するのはその後のデコードステップだけです。これにより、残りの回答のトークン間レイテンシと完了までの総時間が短縮されます。
バッチサイズが大きいとspeculative decodingが遅くなることがあるのはなぜか？
speculative decodingは、GPUまたはTPUの余剰の並列演算能力を利用し、複数のドラフトトークンを一トークンの検証とほぼ同じ時間で確認します。サーバーが非常に大きなバッチで同時リクエストを処理する場合、アクセラレータの演算能力はすでに完全に使われています。そのため、リクエストごとに追加のドラフトトークンを検証すると実際の実行時間が増え、メモリ読み出しの削減分を上回ることがあります。
どんな小さなモデルでも、どんな大きなモデルのドラフトモデルとして使えるのか？
標準的なトークン単位のspeculative decodingでは、そのまま使うことはできません。候補トークンのIDとその確率分布を両モデル間で正しく対応付けるため、ドラフトモデルとターゲットモデルは互換性のある語彙とトークナイザーを共有する必要があります。そのため、T5-XXLのドラフトにT5-smallを使うように、通常は同じモデルファミリーから組み合わせます。
出典
- Yaniv Leviathan, Matan Kalman, and Yossi Matias — Fast Inference from Transformers via Speculative Decoding (arXiv:2211.17192, ICML 2023)
- Charlie Chen, Sebastian Borgeaud, Geoffrey Irving, Jean-Baptiste Lespiau, Laurent Sifre, and John Jumper — Accelerating Large Language Model Decoding with Speculative Sampling (arXiv:2302.01318, 2023)
