LLM推論における投機的デコーディング：スループット向上とトレードオフ
投機的デコーディングLLMサービングでは、ターゲットモデルに別のモデルになることを求めることなく、次のトークンを待つ時間を短縮できます。大規模なターゲットモデルがデコードステップごとに1トークンしか生成しないようにする代わりに、より低コストの提案モデルが短い続きをドラフトします。ターゲットモデルはその続きを並列に検証し、受け入れられたプレフィックスを確定して、最初に不一致が生じた箇所から処理を続行します。
これは万能の高速化策のように聞こえます。しかし、そうではありません。結果は、ドラフト品質、リクエストの構成、バッチ処理、サンプリング設定、GPUメモリの余裕、およびワークロードが本当にデコード律速かどうかに依存します。このガイドでは、内部で何が起きているのか、EAGLEとMedusaが設計をどのように変えるのか、そして投機的デコーディングをサービングスタックに組み込むべきかを判断する方法を解説します。
実践上のルール：投機的デコーディングは、論文上の高速化設定ではなく、計測に基づくサービング最適化として扱ってください。並行処理能力や信頼性を低下させることなく、実際のトラフィックで重要となるレイテンシまたは出力トークンのスループット目標を改善する場合にのみ、採用し続けてください。
投機的デコーディングLLM推論とは？
自己回帰生成は逐次的です。トークン t + 1 はそれ以前のトークンに依存します。そのため通常のデコーダーでは、生成するトークンごとに大規模なターゲットモデルの実行完了を待ちます。投機的デコーディングは、ターゲット分布ではなくスケジュールを変更します。より小規模または特化型のドラフト機構が複数の候補トークンを予測し、ターゲットモデルが候補位置をまとめてスコアリングまたは検証し、システムは一致した接頭辞を受理して、最初に棄却された位置でフォールバックします。
投機的デコーディングの原論文では、複数の候補位置を並列に評価しながらターゲットモデルから厳密なサンプルを得る方法として説明されています。同論文で報告された2～3倍の結果はT5セットアップにおけるベンチマーク結果であり、すべてのモデルやサービスでの効果を約束するものではありません。原論文を読む。
投機的デコーディングLLM推論の図
リクエスト + 現在のコンテキスト
|
v
ドラフト機構が提案: [A] [B] [C] [D]
|
v
ターゲットモデルが、提案されたすべての位置を1回のパスで検証
|
+-- [A] [B] [C] を受理 -> その接頭辞を確定（場合により追加のターゲットトークンを1つ確定）
|
+-- [C] で棄却 -> [A] [B] を確定し、[C] でサンプリング/修正してから繰り返す
削減される作業は、ドラフト計算そのものではありません。潜在的なメリットは、複数回の直列的なターゲットモデルのデコード反復を、1回のターゲットモデル検証パスに置き換えることから得られます。提案がしばしば誤っている場合、ターゲットは頻繁に復旧処理を行う必要があり、効果は小さくなります。
重要な指標：ターゲット検証1回あたりの受理トークン数
最も有用な健全性シグナルは、検証を通過した提案トークンの数です。チームではこれを受理率または受理長と呼ぶことがよくあります。両方を追跡してください。
| 指標 | わかること | 単独では誤解を招く理由 |
|---|---|---|
| 受理率 | 提案トークンのうちターゲットが受理する割合 | ドラフトコストやターゲット検証コストは含まれません。 |
| 平均受理長 | ラウンドごとに確定できるドラフトトークン数 | 平均値では、ロングテールのリクエストや異なるサンプリングモードが見えなくなる場合があります。 |
| トークン間レイテンシ（ITL） | ストリーミングされるトークン間の時間 | 通常、これはユーザーに見えるデコード指標です。 |
| 合計出力トークン/秒 | 同時リクエスト全体での有用なサービング容量 | 低QPSの対話ユーザーにはほとんどメリットがないまま改善する場合も、その逆の場合もあります。 |
| GPUメモリとアクティブリクエスト数 | 提案器がKVキャッシュや同時実行性を圧迫していないか | 単一リクエストが高速化しても、フリート全体ではより悪い構成となる場合があります。 |
公平なA/Bテストでは、モデルリビジョン、トークナイザー、量子化、最大出力長、プロンプト構成、サンプリングパラメータ、ハードウェア、同時実行ポリシーを固定してください。エンドツーエンドレイテンシ、最初のトークンまでの時間、p50/p95 ITL、出力トークン/秒、エラー率を比較します。負荷の形状を伴わない単一の「tokens/sec」値だけでは、構成を選択するには不十分です。
投機的デコーディングが有効な場面とそうでない場面
投機的デコーディングによるLLMサービングは、通常、デコードがメモリバウンドであり、各リクエストの生成長が十分に長く、繰り返される検証ラウンドが意味を持つ場合に最も魅力的です。現在のvLLMガイダンスでは、これを中～低QPSのメモリバウンドなワークロードにおけるトークン間レイテンシを削減する方法として位置付けており、実際の効果はモデルファミリー、トラフィック、ハードウェア、サンプリング設定に依存するとしています。vLLMの投機的デコーディングガイドを見る。
次のケースでは効果が限定的です。
- プリフィルがリクエストを支配している。 長いプロンプトと短い回答では、ほとんどの時間がコンテキストの取り込みに費やされます。ドラフティングが変更するのはデコード処理であり、すでにエンドツーエンドレイテンシを支配しているプロンプトのプリフィル処理ではありません。
- 受理率が低い。 クリエイティブなデコーディング、適合しないドラフトモデル、または弱い候補継続を生成する構成は、検証の失敗を繰り返す原因となる場合があります。
- サーバーがすでにバッチで飽和している。 高い同時実行性では、ターゲットGPUは通常のスケジューラーによって効率よく使用されている可能性があります。ドラフターを追加すると、本来ならより多くのリクエストの処理に使えるメモリや計算リソースを消費することがあります。
- KVキャッシュの余裕が少ない。 追加のドラフトモデルまたは提案器の状態により、退避やキューイングが始まる前に維持できるライブシーケンス数が減る場合があります。単一リクエストの高速化をフリート全体のメリットと解釈する前に、LLM GPUメモリ要件を確認してください。
- ターゲットモデルが選択した提案器と互換性がない。 モデルベースの手法には、互換性のあるアーティファクト、トークナイゼーション、サービングサポートが必要です。小規模モデルだからといって、安価であるという理由だけで有効なドラフトモデルだと決めつけてはいけません。
したがって問うべきことは、「投機的デコーディングでこのモデルを高速化できるか？」ではありません。「トラフィック分布の下で、どのサービスレベル制約を改善できるか？」です。
ドラフトモデル、EAGLE、Medusa：トークンを提案する3つの方法
独立したドラフトモデル
古典的な設計では、高速なドラフトモデルとより大規模なターゲットモデルを組み合わせます。ドラフトはk個のトークンを提案し、ターゲットがそれらを検証します。この仕組みは概念的にはシンプルですが、別のモデルアーティファクト、メモリフットプリント、互換性対応、そしてバージョン管理・監視すべき運用面が追加されます。
実証済みの互換性を持つ低レイテンシの提案器があり、ターゲットサービスの同時実行性を維持できる十分なGPU容量がある場合に使用してください。提案を深くすれば常に良いと仮定するのではなく、少数の投機的長から始めます。
EAGLE投機的デコーディングLLM
EAGLEは、従来の小規模トークンモデルのみの提案パスではなく、特徴量レベルでドラフトを行うモデルベースのアプローチです。論文では、特徴量レベルの不確実性に対処するため、1ステップ先行するトークンシーケンスで特徴量予測を条件付けると説明されています。論文でテストされた設定では、生成テキストの分布を維持しながらレイテンシとスループットが改善したと報告されています。これは手法の可能性を示す有用な証拠であり、別のモデルやGPUフリートに対する容量予測ではありません。EAGLE論文を読む。
運用者にとっての意味は明確です。ターゲットファミリー向けにサポートされるアーティファクトが利用可能な場合、EAGLEは魅力的な選択肢になり得ますが、すべてのチェックポイントで使える汎用的なスイッチではありません。本番へ昇格する前に、正確なターゲット/提案器の組み合わせとサービングエンジンのバージョンを検証してください。
Medusa投機的デコーディングLLM
Medusaはバックボーンモデルに複数のデコーディングヘッドを配置し、ツリーベースのアテンションを使用して複数の候補継続を生成・検証します。これにより、完全に独立した別のドラフトモデルを維持する必要はなくなりますが、ヘッドはバックボーン向けにトレーニングまたはファインチューニングする必要があります。Medusa論文では、バックボーンを凍結するパスと共同ファインチューニングを区別し、それらの実験セットアップにおけるベンチマーク高速化を報告しています。Medusa論文を読む。
運用上のトレードオフは、ドラフトモデルのペアとは異なります。独立したモデル管理を減らせる可能性がある一方で、モデル固有のアーティファクトとトレーニングまたは統合作業が必要です。実行時の小技ではなく、モデルサービングの選択肢として扱ってください。
GPU推論のための実践的な展開計画
1. 代表的なベースラインを確立する
少なくとも1つの本番環境に近いリクエストのスライスを取得します。プロンプト長の帯域、出力長の帯域、言語またはタスクタイプ、temperature/top-p設定、ストリーミング動作、同時実行レベルです。最初のトークンまでの時間とデコードについて、ベースラインを別々に記録してください。ワークロードがプロンプト中心である場合、出力トークンのベンチマークでプリフィルの問題が隠れないようにしてください。
2. 1つの提案器戦略と控えめな深さを選ぶ
ドラフトモデル、EAGLE、Medusa、または他のエンジンでサポートされる提案器といった、サポートされる手法を1つ選び、小さな候補長から開始します。たとえばvLLMでは、手法、提案器モデル、num_speculative_tokensなどの--speculative-config設定が文書化されています。設定を本番環境へコピーする前に、使用中のバージョンに対応するドキュメントを確認してください。より広範な運用セットアップについては、vLLMデプロイガイドを参照してください。最初の段階で、投機的な深さとバッチングを同時に調整してはいけません。
3. 単一のベンチマークではなく負荷マトリクスを実行する
同じトラフィックスライスを、低・中・ピーク相当の同時実行性でテストします。各ポイントについて、次を比較してください。
- ベースラインと投機的デコーディングのエンドツーエンドレイテンシ。
- ストリーミングリクエストにおけるp50およびp95トークン間レイテンシ。
- 合計出力トークン/秒と完了リクエスト/秒。
- 受理長、棄却頻度、提案器レイテンシ。
- GPUメモリ、KVキャッシュの圧力、キュー遅延、エラー/タイムアウト率。
可能であれば、プロンプト帯域と出力帯域ごとに結果を分割してください。長いコード補完には効果がある構成でも、短いチャット回答には効果がない場合があり、良好なオフライン結果でもキューイングを含めると劣化することがあります。
4. カナリア展開の前にガードレールを設定する
トラフィックに変更を公開する前にロールバックしきい値を定義します。たとえば、p95 ITLの悪化、ピーク負荷時の完了リクエスト/秒の低下、メモリ不足イベントの増加、または受理率の持続的な低下です。最初は適格なスライスのみにルーティングし、迅速に比較できるようベースラインパスを維持してください。
5. ローンチ後も測定を継続する
受理率は、モデル更新、プロンプト分布、ツール使用フォーマット、サンプリングのデフォルト値によって変動します。ターゲットモデル、トークナイザー、量子化、GPU、サービングエンジン、トラフィックプロファイルに重要な変更があった後は、比較を再実行してください。
最小限のvLLM開始例
対応するサービングエンジンでは、構成に提案器の手法を明示し、不透明なデフォルトに隠さないようにする必要があります。現在のvLLMドキュメントでは、独立したドラフトモデルに対して次のような構造が使用されています。
vllm serve <target-model> \
--speculative-config '{
"method": "draft_model",
"model": "<compatible-draft-model>",
"num_speculative_tokens": 5
}'
プレースホルダーは意図的なものです。互換モデル、投機的トークン数、並列処理設定、メモリ予算は、テスト済みのアーティファクトとエンジンバージョンに基づいて選択する必要があります。特定のターゲット/ドラフトの組み合わせがサポートされる証拠として、このスニペットをコピーしないでください。
スループット向上とトレードオフの一覧
| 判断 | 想定される利点 | 主なコストまたは障害モード | 最初に測定すべきもの |
|---|---|---|---|
| 独立したドラフトモデルを有効化する | 受理率が高い場合、直列的なターゲットデコードステップを削減 | 追加のモデルメモリ、互換性対応、ドラフトレイテンシ | 受理長、KVキャッシュの余裕、p95 ITL |
| 投機的長を増やす | 検証1回あたりの潜在的なトークン数が増加 | 後続トークンが棄却された場合にドラフト作業の無駄が増加 | 受理率だけでなく、正味ITLと合計出力TPS |
| EAGLEを使用する | アーティファクトがサポートされる場合の強力なモデルベース提案パス | モデルファミリーおよびエンジンの互換性要件 | ターゲット/提案器の互換性と負荷形状を反映したベンチマーク結果 |
| Medusaを使用する | 独立した完全なドラフトモデルなしでマルチヘッド提案を実現 | モデル固有のヘッドと統合/トレーニング作業 | 出力品質チェック、サービングサポート、ロールバックパス |
| ピークQPSで有効化する | 適切なエンジン/ワークロードではスループット向上の可能性 | スケジューラー、メモリ、計算リソースの競合により効果が失われる可能性 | 完了リクエスト/秒、キュー時間、エラー率 |
よくある質問
投機的デコーディングはターゲットモデルの回答を変えますか？
適切な投機的サンプリングでは、ターゲットモデルによる検証と修正を使用するため、サンプリングはターゲット分布を保持できます。この保証は、正しいアルゴリズムと互換性のある実装を使用することに依存します。サービングの変更は、レイテンシ、キューイング、エラーなどの運用上の挙動に影響を与える可能性があるため、速度だけでなく品質と信頼性も評価してください。
投機的デコーディングは最初のトークンまでの時間を改善しますか？
通常は、生成開始後のデコードフェーズを対象とします。リクエストでプロンプト処理が支配的な場合、最初のトークンまでの時間はほとんど変化しない可能性があります。プリフィルとデコードを分けて測定してください。
投機的トークンはいくつ使用すべきですか？
普遍的に最適な値はありません。モデル、提案器、サンプリング設定、GPUタイプ、同時実行性に対して、小さな範囲をテストしてください。より長い提案が有利になるのは、十分な数のトークンが受理され、追加作業によってサービス容量が低下しない場合に限られます。
EAGLEとMedusaのどちらを使用すべきですか？
ターゲットモデルとサービングエンジンが十分にサポートする手法を選び、その後ワークロード上でベンチマークしてください。EAGLEはサポートされる特徴量レベルのドラフティングアーティファクトに依存し、Medusaはバックボーンに関連付けられた複数のヘッドに依存します。どちらも汎用ドラフトモデルと自動的に交換可能ではありません。
判断を全体の文脈に置く
投機的デコーディングは、LLMサービング最適化の1つのレイヤーです。明確なモデルサービングの選択、現実的な容量制限、明示的な監視と併用した場合に最も効果を発揮します。より広範なサービングエンジンの比較については、vLLM vs SGLang：スループット、レイテンシ、モデルサポート、運用を参照してください。本番APIの容量面については、RPM vs TPM：LLMレート制限と429エラーの修正を参照してください。
GPU実験や新しい推論環境を計画している場合は、Flatkey Computeを確認し、ユーザーに見えるレイテンシとフリートレベルのスループットの両方を報告するベンチマーク計画から始めてください。最適な投機的デコーディングLLM構成とは、実際の負荷の下で制約対象の指標を改善し、ワークロードが変化したときに安全にロールバックできる構成です。この投機的デコーディングLLMガイドは、その測定規律の出発点であり、それに代わるものではありません。
