speculative decodingとは？LLM推論を速める仕組みと導入方法

アプリ開発者が知りたいのは、自分のワークロードで回答のストリーミングが速くなるかどうかです。推論サーバーの運用担当者にとっては、同時リクエストやメモリ逼迫があっても、その効果が続くかが問題になります。ホステッドAPIを利用するチームなら、そもそもプロバイダーがこの最適化を提供し、仕様を公開しているかを確認する必要があります。

ドキュメント確認日：2026年10月30日。 対象はvLLM、SGLang、NVIDIA TensorRT-LLMです。以下のコマンドは公開中のドキュメントに沿った設定例であり、本記事で測定したベンチマーク結果ではありません。

speculative decodingはどのように動くのか

低コストの候補生成器が次のトークンを予測し、回答に採用できるかをターゲットモデルが判断します。 トークンはモデルが扱うテキストの単位で、単語の一部に相当することもよくあります。ターゲットとは、元の振る舞いを維持したいモデルのことです。

細部に厳しい編集者のために、アシスタントが文章を下書きする場面を考えるとわかりやすいでしょう。アシスタントは先回りして書けますが、編集者の確認が済むまで読者には届きません。この手法の要点は、新しいトークンごとに生成ステップを待つのではなく、提案された続きをターゲットがまとめて評価できることです。NVIDIAも、候補を生成する仕組みと、その後にターゲットが行う検証処理として説明しています。TensorRT-LLMのドキュメント

この図の文字はトークンIDを表しています。ドラフトモデルはA B Cを提案します。次のトークンとして確率が最も高いものを選ぶ貪欲法で、ターゲットはA Bには同意するものの、その次にはXを選ぶとします。確定する回答はA B Xです。棄却されたCの後に用意されていた続きも、誤った先頭部分に基づいているため破棄されます。

サンプリングによる出力では、両モデルが同じ単語を選んだかどうかを比べるだけでは採否を決められません。標準的な投機的サンプリングでは、ターゲットと候補生成側の確率を使い、候補を棄却した場合は補正分布を用います。この補正によって、ターゲットの確率分布を維持します。また、元のアルゴリズムでは、候補列がすべて採用されたときに、ターゲットが追加のトークンを出力することもできます。Leviathan、Kalman、Matiasによる原論文

つまり、小さいモデルの役割は候補の提案であり、回答を代行することではありません。厳密な検証を使うなら、出来の悪いドラフトモデルは速度を落とす要因にはなっても、知らないうちに回答を引き継ぐことはないはずです。

「性能の低いモデルに任せない」とはどういう意味か

確認すべき保証は、ターゲットの分布が維持されることです。 毎回同じランダムな応答が得られることも、ターゲットの誤りがなくなることも、推論能力が向上することも保証しません。vLLMは、アルゴリズムがロスレスでも、数値計算やバッチ処理の影響によって差が生じうると説明しています。vLLMのロスレス性に関する保証

投機的デコーディングを評価するときは、ターゲットの重み、量子化、サンプリング設定を固定してください。複数の条件を同時に変えると、品質の差がどの変更によって生じたのか判断できなくなります。

主な方式と各エンジンの設定ドキュメント

使うターゲットモデルと推論エンジンのリリースが対応している候補生成方式を選びます。 候補を生成して検証する基本の仕組みは共通で、候補の作り方が異なります。

独立したドラフトモデルを使う方式

小さい言語モデルが、自身の重みを使って候補トークンを生成します。最も直感的な構成ですが、別のモデルをロードして運用する必要があります。互換性とターゲットとの一致度が重要であり、小さいだけで役に立つとは限りません。vLLMは通常、語彙の共有を前提としていますが、制約付きで異なる語彙に対応する選択肢も公開しています。vLLMのドラフトモデル

すでにメモリ上限に近いサービスでは、モデルを追加することが最初の一手として適切とは限りません。一方、レイテンシが重要で、容量に余裕があり、相性のよいドラフトモデルがあるサービスなら、条件をそろえて試す価値があります。

EAGLEによる投機的デコーディング

EAGLEはExtrapolation Algorithm for Greater Language-model Efficiencyの略で、ターゲットに対応する学習済みの補助ドラフトモデルを使います。このモデルは、ターゲットの内部表現を利用して続きを提案します。ヘッドと呼ばれることも多い、こうした学習済みコンポーネントには、互換性のあるチェックポイントが必要です。vLLMはeagleとeagle3の設定を区別しています。vLLMのEAGLEドキュメント

ターゲットとEAGLEチェックポイントは、互換性のある組み合わせとして扱ってください。名前に同じモデルファミリーが含まれているという理由だけで選んではいけません。正しいモデルファミリー、モデルのリビジョン、推論エンジンの実装を、すべてデプロイの記録に残します。

MTPによる投機的デコーディング

Multi-token prediction（MTP）は、モデルに組み込まれた、先のトークンを提案する能力を使います。vLLMは対応モデルファミリー向けの選択肢として紹介し、別のドラフトモデルIDを必要としない起動例を掲載しています。その能力がないモデルでmethodをmtpにしても、MTPが使えるようにはなりません。vLLMのMTPドキュメント

対応するMTPチェックポイントをすでに運用しているなら、別系統の独立したドラフトモデルを加える前に、公式の設定手順を試してください。互換性について判断する項目を減らせます。ただし、性能の測定は引き続き必要です。

以下の表から、各エンジンの公式ドキュメントを参照できます。設定を調べ始めるための案内であり、すべてのモデルが表のすべての組み合わせで動くという意味ではありません。

アルゴリズムの名称と、実行時の構成は別の話です。TensorRT-LLMの現行リリースノートでは、独立したドラフトエンジンによる実行方式が削除され、モデル内のサブモジュールとしてドラフトモデルを配置する実装が残されています。これは、ドラフト／ターゲット方式そのものがなくなったという意味ではありません。 古いデプロイ手順には、インストール済みのリリースでは使えない実行方式が載っている可能性がある、ということです。TensorRT-LLMのリリースノート

速くなる条件と、効果が出ない条件

追加の処理をすべて含めても、有効な出力が早く得られる場合にだけ効果があります。 採用率は重要ですが、それだけで判断はできません。

採用トークンの効果が候補生成コストを上回ること

採用率は、採用された候補トークン数を、提案された候補トークン数で割った値です。それ自体は、候補を作るためにどれだけのコストがかかったかを示しません。遅いドラフトモデルは、ターゲットとの一致率が高くても、サービス全体を遅くすることがあります。

判断には、次の式が役立ちます。

（候補生成時間 + 検証時間 + 連携処理時間）÷ 確定した出力トークン数 < ベースラインのトークンあたりデコード時間

これは処理コストを比較するための式であり、ベンチマーク結果を予測するものではありません。自分のハードウェアで、処理の一巡にかかる時間を測ってください。「確定した出力トークン」には、採用された候補だけでなく、ターゲットが補正やボーナスとして出力したトークンも含みます。

コード編集アシスタントでは、周辺に繰り返し現れる構造が候補生成に役立つかもしれません。一方、サポート用アシスタントでは、丁寧なつなぎ表現は一致しても、製品固有の回答では一致しにくい可能性があります。平均採用率を導入判断に使う前に、両方のワークロードを別々に測定してください。

候補列を長くすると、破棄される処理も増えます。候補生成の深さを増やすのは、確定出力の増加が、候補生成・検証・メモリの追加コストを補える間に限ります。Fireworksのチューニングガイドも、採用率だけでは高速化を示せないと、運用上の判断を区別しています。Fireworksのベンチマークガイド

バッチサイズで高速化の余地が変わる

まずデコードが律速する対話型ワークロードで試し、その後にピーク時の同時実行数で検証します。 vLLMは特に、リクエストレートが中〜低程度のメモリ律速ワークロードを対象に挙げています。メモリ律速のステップでは、使える演算能力よりも、モデルデータの転送が処理の進行を制限します。vLLMのワークロードガイド

検証を並列化すると、それまで余っていた演算能力を活用できます。ただし、負荷の高いサーバーでは、その能力がすでに別のリクエストに使われているかもしれません。そのため、単独のチャットでレイテンシが下がっても、高負荷のエンドポイントで総スループットが向上するとは限りません。

Continuous batchingでは、各生成ステップを共有するリクエストの組み合わせが変わります。実際のリクエスト到着パターンも含め、そのスケジューラーの下で投機的デコーディングを評価してください。空いている開発用エンドポイントと、キューがある本番エンドポイントでは、実験の条件が異なります。

どの環境にも通用するバッチサイズの上限を設けるべきではありません。有効な境界は、モデル、ハードウェア、候補生成方式、スケジューラーによって変わります。応答がどの速さで流れてくるかというレイテンシの視点と、目標レイテンシを守りながらどれだけのトラフィックを処理できるかという容量の視点を、両方持って評価します。

メモリ不足で効果が消えることもある

ドラフトモデルも、限られたGPUメモリを使います。 追加の重み、候補生成の状態、検証用の作業領域は、本来ならリクエスト処理に使える容量を消費します。既存トークンのアテンションの状態を保存するKVキャッシュも、同じメモリ予算に含まれます。

短いプロンプトでは速くても、長い文書では容量上限に近づく文書アシスタントを考えてみてください。短いプロンプトで試してうまくいっても、本番のキャッシュとドラフトモデルが同時に収まるかはわかりません。サポートする予定の最長コンテキストを使い、実際に近い同時実行数でテストしてください。

SGLangのメモリ不足対策には、メモリ予約量、グラフキャプチャのサイズ、候補ツリーのサイズ、同時リクエスト数を減らすことが明記されています。投機的デコーディングをメモリに収めるために同時実行数を下げるなら、それは測定すべきトレードオフであり、無償で得られる最適化ではありません。SGLangのメモリ問題への対処

ユーザーの待ち時間を生んでいる部分を速くする

「回答が遅い」といっても、出力開始までの待ち時間が長い場合、出力開始後のストリーミングが遅い場合、モデルの外で遅延している場合があります。投機的デコーディングが対象とするのは生成処理です。アプリが文書検索やツール呼び出し待ちに大半の時間を使っているなら、デコードループを速くしても体感はほとんど変わらないかもしれません。

測定では、キュー待ち、プリフィル、デコードを分けてください。プリフィルはプロンプトを処理し、デコードはその続きを生成します。LLM推論ガイドではこれらの段階を説明し、トークン毎秒のガイドでは出力速度とリクエスト全体のスループットを区別しています。

投機的デコーディングを有効にするには

推論サーバーのプロセスで有効化し、同じターゲットで無効にした場合と比較します。 以下の例は、エンジンがインストール済みで、選んだモデルがハードウェアに収まり、その重みにアクセスできることを前提としています。デプロイするリリースに合うドキュメントを参照してください。公開中のlatestページは、古いコンテナとの互換性を保証するものではありません。

vLLMで投機的デコーディングを設定する

vLLMでは、--speculative-configにJSONオブジェクトを渡します。独立したドラフトモデルを使う次の例は、オンラインサービングのドキュメントにあるターゲット、ドラフトモデル、候補列の長さをそのまま使っています。

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

5はこの例で提案するトークン数であり、最適値として推奨されているわけではありません。以前使われていた個別のフラグ--speculative-modelと--num-speculative-tokensは、ドキュメントで非推奨とされています。vLLMの起動例

モデル内蔵のMTPを使う例として、ドキュメントにはXiaomi MiMoのベースチェックポイントを使う次の設定があります。

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

これは別のモデルを使った例であり、先ほどのQwenターゲットにそのまま組み合わせるドラフトモデルではありません。制約になるのはチェックポイントの対応状況です。モデル自体にMTPが備わり、エンジンも対応している必要があります。vLLMのMTP起動例

SGLangで投機的デコーディングを設定する

SGLangの現行オーバーラップスケジューラーの例では、独立したQwenのターゲットとドラフトモデルを次のように組み合わせています。

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

現行のオーバーラップ実行方式では、--speculative-eagle-topk 1が必須です。別の例から幅の広いツリー設定を持ち込んでも、この方式では使えません。ドキュメントにあるスケジューラー設定と候補生成設定を、組み合わせたまま使ってください。SGLangのオーバーラップスケジューラー設定例

ワークロードが変動する場合に向けて、SGLangは、対応するEAGLE構成で使える適応型の投機的デコーディングも別途説明しています。候補生成の深さが自動調整されることを期待する前に、この機能の要件を確認してください。SGLangの適応型投機的デコーディング

TensorRT-LLMの設定方法

TensorRT-LLMでは、YAML設定ファイルで投機的デコーディングを設定できます。次の内容をspeculative.yamlとして保存します。

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

候補列の長さとチェックポイントは、NVIDIAの投機的デコーディング設定例に基づいています。公式のサービングCLIを使い、対応するターゲットを起動します。

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

設定名だけでなく、チェックポイントの世代も確認してください。NVIDIAはEagleをEagle3の互換用エイリアスとしていますが、古い世代のEAGLEチェックポイントは、この実行方式では引き続き使えません。TensorRT-LLMのチェックポイント制約

投機的デコーディングの方式と併せて推論エンジンも選ぶなら、より広い観点からまとめたvLLMとSGLangの比較を参照してください。優れたドラフトモデルでも、アプリに必要な別の機能がエンジンに欠けていれば補えません。

ホステッドAPIでも効果は得られるのか

プロバイダーが仕様を公開し、有効にしている場合は効果を得られます。操作できる範囲はサービスによって異なります。 プロバイダー側の推論最適化の恩恵を受けるために、自分でGPUを所有する必要はありません。

ホステッド推論プロバイダーのFireworks AIは、専用デプロイメントの対応モデルの多くに、デフォルトのドラフトモデルを用意していると説明しています。デフォルトのドラフトモデルがないモデルは、別途設定しない限り、モデルベースの投機的デコーディングを使わずに動作します。サーバーレス環境の推論設定はFireworksが管理するため、専用デプロイメントに設定フラグがあることだけでは、すべてのサーバーレスエンドポイントで使われているとは判断できません。Fireworksのデプロイメントドキュメント

ファイルに小さな修正を加えて再生成する用途には、FireworksはPredicted Outputsも公開しています。リクエストのpredictionフィールドに、予想されるテキストを渡す機能です。既知のテキストが別の候補生成源となり、モデルベースの投機的デコーディングと併用できます。自由回答の質問を投げる場合よりも、回答の大部分がすでにわかっている場合に役立ちます。FireworksのPredicted Outputs

別のホステッドエンドポイントについて効果をうたったり設定を追加したりする前に、そのサービス自身のドキュメントを確認してください。APIの互換性だけでは、背後でドラフトモデルが動いているか、動いているならどのモデルかはわかりません。

過大評価しやすい点

投機的デコーディングは、条件が合うときに推論サーバーを改善する手法であり、どこでも同じ倍率で速くなるものではありません。 ここでは高速化の倍率を示していません。ターゲット、ドラフトモデル、GPU、トラフィックの構成が異なる環境の結果を、そのまま自分のサービスに当てはめることはできないためです。

「採用トークンが増えればアプリは速くなる」という見方には、候補生成コスト、キュー待ち、生成の前後にアプリが行う処理が抜けています。「候補列は長いほどよい」という考えは、棄却後に無駄になる処理を見落としています。「ロスレスなら同じ文字列になる」という理解は、サンプリングの分布と、ある回に得られたランダムな結果を混同しています。

最も高くつくのは、低負荷のエンドポイントで得られた結果を、本番での処理容量の根拠にしてしまうことです。開発者自身にはコード支援アシスタントが速く感じられても、共有エンドポイントが同時に扱えるセッション数は減っているかもしれません。改善したいのは応答レイテンシか、持続的なスループットか、その両方かを決め、導入判定の基準に明記してください。

来週から何を進めるべきか

開発者は、デコードがボトルネックなら互換性のある候補生成方式を試しましょう。運用担当者は、本番負荷で効果が出ることを条件にします。ホステッドAPIを使うチームは、プロバイダーが実際に公開している設定から始めてください。

待ち時間の大部分が生成前に発生しているなら、まずそちらのボトルネックを解消してください。ドラフトモデルがメモリに収まらない場合や、互換性のあるチェックポイントがない場合は、ターゲットを通常どおり動かします。機能が利用可能であることは、自分の環境に必要であることの根拠にはなりません。

開発者がよく疑問に思うこと

AIシステムの構築と運用に役立つ実践ガイドを、ニュースレターで受け取れます。