推論デコーディング：LLMの推論処理を20-50%高速化

70Bパラメータのモデルは1回のフォワードパスで1つのトークンを生成し、各パスではVRAMから重みを読み込み、コンテキスト全体でアテンションを計算し、メモリを同期します。トークンの間では、逐次依存関係が解決されるのを待つ間、GPUはアイドル状態になります。

H100では、70Bモデルは30〜50msごとに1つのトークンを生成します。GPUには複数のトークンを並列に処理する十分な計算能力がありますが、逐次依存関係のためにそれが阻止されます。各トークンは直前のトークンに依存しており、パイプラインが停止します。

投機的デコーディング（Speculative Decoding）は、出力分布を変更することなく、通常1つのトークンを生成するのと同じ時間で複数のトークンを生成することを可能にすることで、このボトルネックを打破します。得られるトークンは、標準的な自己回帰デコーディングから得られるものと統計的に同一です。違いは、それらが得られる速さだけです。

このガイドでは、メカニズム、2026年に利用可能なバリエーション、受容率（acceptance rate）のトレードオフ、およびllama.cpp、vLLM、SGLang、TensorRT-LLMにおける実践的なセットアップについて解説します。

自己回帰デコーディングの仕組み（およびなぜ遅いのか）

投機的デコーディングを理解するには、それが回避する自己回帰制約を理解する必要があります。標準的な自己回帰生成はトークンを逐次処理します：

1. 現在のコンテキストでモデルを通じてフォワードパスを実行します。
2. 出力分布から次のトークンをサンプリングします。
3. トークンをコンテキストに追加します。
4. 繰り返します。

各ステップでは完全なフォワードパスが必要です。VRAMから重みを読み込み、コンテキスト全体でアテンションを計算し、単一のトークンを生成します。70Bパラメータのモデルの場合、H100ではトークンあたり約30〜50msかかります。GPUには余分な計算能力がありますが、逐次依存関係のためにそれが阻止されます。

計算とVRAMのギャップ

現代のGPUは、単一トークン生成に必要なFLOPSよりも多くのFLOPSを持っていますが、真のボトルネックはメモリ帯域幅です。フォワードパスごとに重みをVRAMから計算ユニットにストリーミングする必要があります。1つずつトークンを生成する場合、GPUは有用な計算を行うよりも、メモリ転送を待つのに多くの時間を費やします。

投機的デコーディングは、メモリ転送ごとにGPUにより多くの作業を与えることでこれを解決します。1つのフォワードパスで1つのトークンの代わりに、複数の出力にわたってメモリコストを分散させることで、1つのフォワードパスでK個のトークンを生成します。

ドラフト-検証メカニズム

投機的デコーディングは、反復されるドラフト-検証サイクルによって機能します。高速なドラフトメカニズムはK個の候補トークンを提案します（小さなドラフトモデル、n-gramルックアップ、またはターゲットモデルに接続された予測ヘッドから）。ターゲットモデルは1つのフォワードパスですべてのK個を検証します。ドラフトフェーズは安価で、通常はターゲットモデルのフォワードパス時間の5-20%ですが、検証は各ドラフトされたトークンをターゲットが生成するものと比較し、最も長い一致するプレフィックスを受け入れ、最初の拒絶から再サンプリングします。

K個のトークンを検証するコストは、自己回帰的に1つのトークンを生成するコストとほぼ同じなので、ドラフトが正しい場合、1つの検証ステップのコストでK個のトークンを得ることができます。

具体的な例

ドラフトモデルが5つのトークンを提案したとします：["I", " like", " cooking", " and", " traveling"]。ターゲットモデルは1つのフォワードパスでそれらを検証します：

ターゲットはトークン1と2を受け入れ、次にトークン3として" playing"を生成し、3つの別々のフォワードパスの代わりに1つのサイクルで3つのトークンを生成します。ドラフトがトークン5まで正しかった場合、1つの検証のコストで5つのトークンを得ることになり、そのサイクルだけで5倍の高速化となります。

検証のボトルネック

実際には、検証が実行時間を支配します。方法とモデルサイズに依存して、サイクルの42-95%を占めます。ターゲットモデルのフォワードパスがボトルネックであり、拒絶されたトークンは無駄な計算を表します。

これが受容率がそれほど重要である理由です。最初の後の各拒絶されたトークンは、無駄な検証作業です。最高の投機的デコーディング方法は、単なる生受容率ではなく、サイクルあたりの期待される受容トークン数を最大化します。

数学的な保証

投機的デコーディングの最も重要な特性の一つは、ターゲットモデルからの標準的な自己回帰サンプリングと同じ正確な分布からトークンを生成することです。検証ステップは拒絶サンプリングを使用します。ドラフトがトークンxを提案するとき、ターゲットモデルは自身の確率p(x)を計算し、ドラフトはp_draft(x)を計算します。受容確率は：

min(1, p(x) / p_draft(x))

ターゲットが同意する場合（p(x) ≥ p_draft(x)）、トークンは常に受け入れられます。ターゲットが不同意する場合、トークンは比率に比例した確率で受け入れられ、拒絶されたトークンは残差分布から再サンプリングされます：

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

この手続きは、出力シーケンスがターゲットモデルの分布を正確に従うことを保証するため、投機的デコーディングはロスレスです。ドラフトモデルは速度に影響しますが、品質には影響しません。得られるトークンは、同じパープレキシティと分布を持つ標準的なデコーディングから得られるものと統計的に区別できません。違いはレイテンシだけです。

ドラフトモデル戦略

ドラフトメカニズムは、最も重要な変数です。異なるアプローチは、セットアップの複雑さ、受容率、高速化の間で異なるトレードオフを持っています。

スタンドアロンドラフトモデル

最も単純なアプローチは、ターゲットと一緒に小さなモデルを読み込みます。通常、7B-70Bのターゲットに対してドラフトを行う1B-3Bモデルです。

利点:

• 概念的にシンプル
• 任意のターゲットモデルで動作
• ドラフトモデルはターゲットの分布に一致するように調整可能

欠点:

• VRAMに2番目のモデルを読み込む必要がある（サイズに応じて1-4 GB）
• ドラフトモデルの品質が受容率を直接決定する
• 家族間ドラフト（例：QwenがLlamaのためにドラフト）は通常、パフォーマンスが低い

経験則： 同じファミリーのモデルを使用します。Gemma 2 2BはGemma 2 27Bのためにうまくドラフトします。Llama 3.2 1BはLlama 3.1 70Bのためにうまくドラフトします。家族間ドラフトは、トークン分布が分歧するため、受容率が低くなる傾向があります。

互換性のあるドラフトモデルの発見

すべての小さなモデルが、与えられたターゲットのドラフトモデルとして動作するわけではありません。重要な要因は分布の整合性です。ドラフトモデルの出力確率がターゲットの出力確率にどれだけ近いかです。

黄金のルール：ドラフトモデルの受容率が50%以下に落ちると、投機的デコーディングは実際に速度を低下させる可能性があります。ドラフトモデルの実行と検証のオーバーヘッドは、ほとんどの提案が拒絶される場合、利点を上回ります。

EAGLEとEAGLE-3：予測ヘッド

EAGLE（Efficient Architecture Guided Language Model Estimation）は、別々のドラフトモデルの必要性を排除します。代わりに、ターゲットモデルの内部レイヤーに軽量な自己回帰予測ヘッドを接続します。

EAGLEの仕組み

EAGLEは、ターゲットモデルの中間レイヤーからの隠れ状態を取得し、将来のトークンを予測する予測ヘッドを訓練します。推論中に：

1. ターゲットモデルはレイヤーを通じてフォワードパスを実行します。
2. 各レイヤーで、EAGLEヘッドは隠れ状態を読み取り、将来の位置のトークンを提案します。
3. 複数のヘッドが並列に動作し、それぞれ異なる未来タイムステップを予測します。
4. ターゲットモデルは1つのパスですべての提案を検証します。

利点：EAGLEヘッドは、ターゲットモデルの分布に一致するように特別に訓練されています。ターゲットの内部表現を直接見るため、スタンドアロンドラフトモデルよりもはるかに良い整合性を持ちます。

EAGLE-3の改善

EAGLE-3（2025年）は、3つの主要な変更でアプローチを洗練化了：

1. レイヤー選択： すべてのレイヤーにヘッドを接続する代わりに、EAGLE-3はベイズ最適化を使用して最適な終了レイヤーを選択し、オーバーヘッドを削減します。
2. マルチトークン予測： 各ヘッドは同時に複数のトークンを予測し、計算コストを比例させずにドラフト深度を増やします。
3. 訓練効率： EAGLE-3はターゲットモデル自身の生成データで訓練され、分布内ワークロードでの受容率を向上させます。

受容率： EAGLE-3は、分布内ワークロードで通常60-80%の受容率を達成し、スタンドアロンドラフトモデルの40-60%と比較されます。高い反復を持つコード生成ワークロードでは、受容率は85%を超える可能性があります。

セットアップ： EAGLE-3は、ターゲットモデル用の事前訓練されたヘッドを必要とします。NVIDIAは、TensorRT-LLMとHuggingFaceのSpeculative Decoding Modulesコレクションを通じて、いくつかの人気モデル用のEAGLE-3ヘッドを提供しています。vLLMとSGLang用のサードパーティ実装も存在します。

P-EAGLE：並列ドラフト（2026年3月）

EAGLE-3の主な制限は自己回帰ドラフトです。各ドラフトトークンは直前のトークンに依存するため、K個のドラフトトークンを生成するには、ドラフトヘッドを通じてK個の逐次フォワードパスが必要で、ドラフトオーバーヘッドはKに比例して線形に増加します。P-EAGLEは、10個までのトークンを並列に予測するように訓練された軽量な4層ドラフターを通じて、すべてのK個のドラフトトークンを1つのフォワードパスで生成することで、この天井を排除します。

結果： P-EAGLEは、NVIDIA B200上の実際のワークロードで、バニラEAGLE-3に対して最大1.69倍の高速化を提供します。利点はK値が高いほど広がり、EAGLE-3の逐次ドラフトがボトルネックになる場所で、P-EAGLEの並列ドラフトは追加のコストを発生させません。

vLLMでのセットアップ： HuggingFaceから事前訓練されたP-EAGLEヘッドをダウンロードし、vLLM設定で"parallel_drafting": trueを設定し、同じ--speculative-modelフラグを使用します。vLLMは残りを処理します。P-EAGLEはEAGLEベースの投機的デコーディングの現在の最先端であり、2026年にEAGLEをデプロイする場合、P-EAGLEが使用するべきバリエーションです。

n-gram投機的デコーディング

n-gram投機的デコーディングは、ニューラルドラフトをプロンプト履歴に対するパターンマッチングに置き換えます。アルゴリズムはコンテキストで繰り返されるn-gramシーケンスを探し、現在のトークンシーケンスが以前に見られたパターンに一致する場合、そのパターンに続いてきたトークンを提案します。例えば、モデルがすでにdef calculate_total(items):を生成し、def calculate_total(を再び遭遇する場合、以前の出現に基づいて、次のトークンはおそらくitems):であると知ります。

n-gram mapバリエーション（ngram-map-k, ngram-map-k4v）は、線形スキャンの代わりにハッシュテーブルを使用して高速なルックアップを行い、ハッシュキーは現在のサイズNのn-gram、値はそれに続いてきたトークンシーケンスです。

利点:

• VRAMオーバーヘッドゼロ — 追加のモデルを読み込む必要がない（ハッシュテーブル用約16 MB）
• 反復的なワークロード（コード編集、リファクタリング、テンプレート生成）に極めて高速
• 高い自己類似性を持つワークロードで受容率は90%+に達する可能性

欠点:

• 新規な生成には無意味 — パターンが以前に出現していない場合、n-gramは何も提案できない
• 創造的または多様なワークロードで受容率はほぼゼロに低下
• ドラフト深度が限られている（通常、一致ごとに2-4トークン）

最適な用途： コードリファクタリング、テンプレートの埋め込み、反復的なドキュメント、およびモデルが類似したパターンを再訪する任意のワークロード。最悪の用途：創造的な執筆、オープンエンドなチャット、および推論タスク。

パラメータ調整

n-gramパラメータは、予想よりも重要です。デフォルトはコードに適していますが、テキストワークロードは調整が必要です：

テキストワークロードの場合、size-nを8-10に減らし、min-hitsを2に増やします。これは、一致頻度をトレードオフして、一致あたりの受容率を高くします。

自己投機的デコーディング

自己投機的デコーディング（LayerSkipまたは自己投機とも呼ばれる）は、モデル自身の部分的計算をドラフトとして使用するため、別々のモデルは必要ありません。

仕組み

各トークンに対して完全なモデルを実行する代わりに、自己投機的デコーディングは、いくつかのトランスフォーマーレイヤーをスキップして、部分的なバージョンを実行し、安価にドラフトトークンを生成し、完全なモデルがその後、提案を検証します。

例えば、32層のモデルは、ドラフトのために16層だけで実行し、その後32層すべてで検証するかもしれません。切り捨てられたフォワードパスは、より少ないレイヤーを処理するため高速であり、ドラフトトークンはターゲットと同じ初期レイヤーを見る利点があります。

利点:

• 読み込む追加のモデル重みがない
• ターゲット分布と自然に整合（同じアーキテクチャ、部分的レイヤー）
• 深いレイヤーに大きな冗長性を持つモデルでうまく動作

欠点:

• 部分的フォワードパスをサポートするために推論エンジンを修正する必要がある
• KVキャッシュの複雑さ — ドラフトは、完全なモデルのキャッシュと調整される必要がある部分的KVキャッシュを使用
• 受容率は通常、EAGLEまたは適切に調整されたドラフトモデルよりも低い

llama.cpp実装： PR #18471は、コンテキスト履歴をドラフトとして使用する自己投機的デコーディングを導入しました。モデルは、同じコンテキストウィンドウ内でパターンが繰り返されるコーディングワークロードで特に効果的に、自身の生成履歴からトークンを再利用して継続を提案します。

MTP（マルチトークン予測）

MTPは、特定のモデルチェックポイントに直接組み込まれた投機的デコーディングの特殊な形態です。Qwen 3.6は、標準とMTP対応のGGUFバリエーションの両方を提供します。

違い： MTPヘッドは、訓練中にモデルアーキテクチャに焼き込まれます。モデルは、1つのフォワードパスで複数の未来トークンを提案する追加の予測ヘッドを持ちます。別々のドラフトモデルはありません — MTPヘッドはターゲットモデル自体の一部です。

トレードオフ:

• 管理するドラフトモデルがない — --spec-type draft-mtp --spec-draft-n-max NでMTPがアクティブ化される
• MTPヘッドは約1-2 GBのVRAMオーバーヘッドを追加
• MTPヘッドが安価に保たれるMoEアーキテクチャ（Qwen 3.6 35B-A3B）で最もよく動作

Qwen 3.6 27Bおよび35BでのMTPと標準デコーディングの詳細なベンチマークについては、Qwen 3.6 MTP vs Standard on 16GB GPUをご覧ください。

受容率：実践的な意味

受容率（α）は、投機的デコーディングパフォーマンスにとって最も重要なメトリクスです。それは、高速化を得ているのか、オーバーヘッドを支払っているのかを決定します。

高速化の公式

検証パスあたりの期待される受容トークン数：

E[accepted] = α × K

ここでKは、サイクルごとに提案されるドラフトトークンの数です。α = 0.7かつK = 5の場合、パスあたり3.5トークンを受け入れます。これは、パスあたり1トークンを生成する標準デコーディングに対して3.5倍の高速化です。

方法別の受容率

受容率が低下するとき

受容率は、生成全体で一定ではありません。以下によって変動します：

• トークン位置： 初期トークンは通常、より高い受容率を持ちます（より多くのコンテキスト、不確実性が少ない）。後期のトークンは、モデルがより多様な継続を探求するため、低下します。
• ワークロードタイプ： 繰り返されるパターンを持つコード編集はα > 80%を見ます。オープンエンドな創造的な執筆はα < 40%を見ます。
• 温度： 高い温度はドラフトとターゲット間の分歧を増加させ、受容率を低下させます。投機的デコーディングは低温度（0.0-0.7）で最もよく動作します。

重要な閾値： 有効な受容率（α × K）が1.0以下に低下する場合、投機的デコーディングは標準デコーディングよりも遅くなります。ドラフトオーバーヘッドと検証時間の合計が、単一の自己回帰ステップのコストを超えます。

本番環境での投機的デコーディング：実際に何が起こるか

研究論文は2-4倍の高速化を報告していますが、本番環境のベンチマークはより微妙な物語を語ります — 高速化はバッチサイズとともに縮小し、検証がサイクル時間を支配し、単一の方法がすべてのワークロードで勝つわけではありません。

SpecDecode-Benchの発見（2026年）

vLLM上の5つのSDバリエーション（n-gram、EAGLE、EAGLE-3、Draft-Model、MTP）の4つのモデルと6つのワークロードに対する体系的な評価は、以下を明らかにしました：

1. SDは動作しますが、高速化はバッチサイズとともに縮小します。 バッチサイズ1で、EAGLEはLlama-3-70Bで最大1.96倍を達成します。バッチサイズ128では、これは1.21倍に低下します。システムは高い並行性で計算制約になり、GPUは投機のために余分なアイドル容量が少なくなります。

2. 検証が実行時間を支配します（42-95%）。 ターゲットモデルのフォワードパスがボトルネックです。拒絶されたトークンでの無駄な検証を削減することが、改善のための最も有望な道筋です。

3. どこでも勝つ単一の方法はありません。 EAGLE-3は最も優れたオールアラウンドな選択肢です。ドラフトモデル方法は、ターゲットモデルが大きい（70B+）場合に優れています。n-gramはコード編集と高いオーバーラップタスクに最適です。

4. オラクル分析はギャップを明らかにします。 n-gramとEAGLEを組み合わせた戦略の理論的な上限は、コード編集ワークロードで約4.9倍に達しますが、現在の実装は2-3倍を達成します。最適化の余地があります。

実践的な高速化の期待

バッチサイズ効果は重要です。小規模なバッチでは、GPUは投機のために余分な計算能力を持っています。大規模なバッチでは、システムはすでに飽和しており、投機的デコーディングは比例した利点なしにオーバーヘッドを追加します。

本番環境でのモニタリング

本番環境で受容率を追跡する必要があります。低下する受容率は、ドラフトモデルがターゲットから分歧していることを示します。ワークロードが変更されたためか、ドラフトモデルが再訓練を必要としているためか。

監視すべき主要メトリクス:

• リクエストあたりの受容率（ベースライン周辺で安定しているべき）
• 投機的デコーディングありなしのトークン/秒（実際の高速化）
• サイクル時間の割合としての検証時間（42-95%であるべき）
• ドラフトモデルのフォワードパス時間（ターゲットモデル時間の< 20%であるべき）

受容率が40%以下に低下する場合、そのリクエストに対して投機的デコーディングを無効にします。オーバーヘッドは価値がありません。

実践的なセットアップ

エンジンの選択はドラフト戦略と同様に重要です。Ollama vs vLLM vs LM Studio and other local runtimesをご覧ください。これは、各ランタイムがバッチング、API互換性、スループットをどのように処理するかを示し、投機的デコーディングパスを選ぶ前に参照してください。

llama.cpp

一般的なサーバーセットアップとGGUF読み込みについては、llama.cppクイックスタートから始めてください。以下のフラグは、その上に投機的デコーディングを追加します。

llama.cppは、--spec-typeフラグを通じて複数の投機的デコーディング方法をサポートしています：

# ドラフトモデル（スタンドアロン）
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # 必須: 投機的デコーディングには --parallel 1

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (テキストワークロード調整)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# 自己投機的 (コーディングワークロード)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

重要なフラグ:

• --parallel 1 — llama.cppでの投機的デコーディングは、単一バッチモードを必要とします。これは現在の制限です。
• --spec-draft-n-max — サイクルあたりのドラフトトークン数。3-5から始めます。高い値はVRAM圧力が増加します。
• --spec-ngram-simple-size-n — ルックアップn-gram長。デフォルト12はコードに良く動作します。テキストの場合は8に減らします。

一般的な落とし穴:

• --parallel 1を忘れる — サーバーは投機的デコーディングをサイレントに無視します。
• 交差ファミリーのドラフトモデルを使用する — 受容率は崩壊し、高速化を相殺します。
• --spec-draft-n-maxを高く設定しすぎる — 各追加のドラフトトークンは、ドラフトバッファのためのVRAMを消費します。5-8で収穫逓減が始まります。

vLLM

vLLMクイックスタートは基本デプロイメントをカバーしています。以下のフラグは、既存のvLLMサーバーで投機的デコーディングを有効にします。

vLLMは、--speculative-modelおよび--speculative-num-stepsフラグを通じて投機的デコーディングをサポートしています：

# ドラフトモデル
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (並列ドラフト)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

vLLMの投機的デコーディングは、継続的バッチングと統合されているため、並列ワークロードで動作します。スケジューラは1つのフォワードパス内の複数のトークンスロットを処理し、メモリマネージャーはドラフトおよびターゲットモデルの両方のKVキャッシュを処理します。

SGLang

SGLangは、--speculative-algorithmフラグを通じて投機的デコーディングをサポートしています：

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

SGLangのRadixAttentionアーキテクチャは、プレフィックスキャッシングが検証コストを削減するため、投機的デコーディングとよく連携します。ターゲットモデルは共有プレフィックスのキャッシュされたアテンションを再利用し、各検証パスを冷たいフォワードパスよりも安価にします。

TensorRT-LLM

TensorRT-LLMは、Triton Inference Serverと組み合わせて、本番環境グレードの投機的デコーディングを提供します。セットアップは複雑ですが、NVIDIAハードウェアで最良のパフォーマンスを提供します：

1. ターゲットおよびドラフトモデルの両方用のTensorRTエンジンをビルドします。
2. 投機的デコーディング構成を指定するmodel.yamlでモデルリポジトリを構成します。
3. LLM API / PyTorchバックエンドでTritonを起動します。

TensorRT-LLMは、ドラフトモデルおよびEAGLE-3バリエーションの両方をサポートしています。コード生成ワークロードでは、TensorRT-LLMとn-gram投機的デコーディングは、本番環境デプロイメントで2-3倍のレイテンシ削減を達成しました。

投機的デコーディングを使用する時期

使用する時期

• 大きなターゲットモデル（7B+）： ドラフトメカニズムのオーバーヘッドは、ターゲットの計算にわたって分散されます。投機的デコーディングは、ターゲットモデルが遅い場合に輝きます。ターゲットが大きいほど、高速化は価値があります。
• 低温度ワークロード： 投機的デコーディングは、ターゲットモデルの分布が集中し、ドラフトが一致する可能性が高い温度0.0-0.7で最もよく動作します。
• インタラクティブアプリケーション： レイテンシセンシティブなワークロード（チャット、コード補完、エージェントツールコール）が最も恩恵を受けます。GPUをすでに飽和させているバッチ処理は、より少ない恩恵を受けます。
• コード生成と編集： コードパターンでの高い反復は、n-gramおよび自己投機的デコーディングを特に効果的にします。

スキップする時期

• 小さなターゲットモデル（< 3B）： ドラフトモデルのオーバーヘッドは、ターゲットのフォワードパス時間に近づきます。高速化は微小または負です。
• 高温度サンプリング： 温度 > 0.7では、ターゲットモデルの分布はドラフトが信頼できに一致するには広すぎます。
• 創造的な執筆とオープンエンドな生成： 新規コンテンツでの低い受容率は、オーバーヘッドを価値のないものにします。
• 大規模バッチ（> 32）： システムは計算制約になり、投機的デコーディングは比例した利点なしにオーバーヘッドを追加します。SpecDecode-Benchは、バッチサイズが1から128に増加するにつれて、高速化が1.96倍から1.21倍に低下することを示しています。

方法の組み合わせ

高度なセットアップは、複数の投機的デコーディング戦略を組み合わせます。SpecDecode-Benchオラクル分析は、n-gramとEAGLEを適応的に組み合わせることで、コード編集ワークロードで高速化を4.9倍に押し上げることができることを示しました。

アイデアは、受容が高くオーバーヘッドがほぼゼロの以前に出現したパターンにn-gramを使用し、新規トークンにEAGLEにフォールバックすることです。実際には、これはマルチメソッド投機のためのエンジンサポートを必要とします — vLLMとTensorRT-LLMは実験的なサポートを持っていますが、本番環境グレードの実装はまだ成熟しています。

現在、最も実用的な組み合わせは、llama.cppでのMTP + n-gramです。MTPはニューラル投機を処理し、n-gramはMTPが逃す反復パターンを捕捉します。Qwen 3 27Bでは、この組み合わせは標準の67トークン/秒に対して120トークン/秒を達成し、1.8倍の高速化となります。

コスト考慮事項

投機的デコーディングは、レイテンシのために計算をトレードします。トークンあたりの総計算はほぼ同じです — 逐次的ではなく、並列により多くの作業を行っています。

GPUコストへの影響:

• 単一リクエストのレイテンシは20-50%改善され、インタラクティブアプリケーションで重要です。
• スループット（多くのリクエストにわたるトークン/秒）はあまり改善されません — GPUはすでに大規模バッチで飽和しています。
• VRAM使用量は、ドラフトモデルのフットプリント（スタンドアロンドラフトで1-4 GB、n-gram/EAGLEでは最小）が増加します。

クラウド推論： H100あたりの$2-4/時間で、投機的デコーディングは、トークンあたりのコストを増加させずにリクエストあたりのレイテンシを削減します。GPUをすでに飽和させているバッチ処理では、コスト利益は最小です — どちらにせよ、同じGPU時間のために支払っています。

投機的デコーディングがお金を節約するとき： リクエストごとに課金し、最初のトークンまでの時間を削減したいインタラクティブアプリケーション。2倍の高速化は、ユーザーが半分待つことを意味し、同じハードウェアでより多くのリクエストを処理できます。

そうではないとき： GPU利用最大化をすでにしているバッチ処理。投機的デコーディングからの追加計算はスループットを増加しません — それは単にレイテンシプロファイルを変更します。

次は何か

投機的デコーディングは、研究の新規性から本番環境標準に成熟しています。フロンティアは、現在の制限を超えて押し進めています：

• 投機的投機的デコーディング（SSD）： ドラフトと検証ステージを別々のハードウェアで並列化します。ドラフトモデルは非同期的に実行され、複数の可能性のある検証結果を事前投機します。初期結果は、最適化された投機的デコーディングに対して最大2倍、自己回帰デコーディングに対して5倍の高速化を示しています。まだ本番環境準備はできていませんが、方向性は明確です。

• SpecSA（スパース投機的検証）： 投機的デコーディングと動的スパースアテンションを組み合わせます。スパースアテンションを検証指向のワークロードに変え、自己回帰スパースデコーディングに対して最大3.49倍のエンドツーエンドスループットを達成します。スパースアテンションがすでに使用されている長コンテキストモデルに関連します。

• 適応投機： ワークロード特性に基づいて、n-gram、EAGLE、およびドラフトモデル方法間で自動的に切り替えます。オラクル分析は、未開拓の大きな可能性を示しています — 現在の実装は2-3倍を達成しますが、理論的な上限は4.9倍です。

• マルチモーダル投機的デコーディング： ドラフト-検証をビジョン言語モデルと動画生成に拡張します。初期調査は、同じ原則が適用されることを示していますが、検証戦略は非テキストモーダルに適応する必要があります。

決定フレームワーク