ステータス：ドラフト（2026-10-27）、n-gram実測、EAGLE・MTP・suffix未実測。 8GBクラスのノートPC用GPU（Ada世代）1枚、vLLM 0.31.0、Qwen3-Reranker-0.6Bで2026-10-27に測定しました。モデルベースの手法（EAGLE、MTP、ドラフトモデル）はドラフトの重みを、suffix方式は追加パッケージを新しくダウンロードする必要があるため、今回は測定していません。 2026-10-27追加。 会話用のQwen3-0.6BとvLLM 0.32.0で再測定した結果を3-1節に追加しました。0.31.0およびリランクモデルの数値はそのまま残しています。 作成規則：実測データを基本とし、測定できなかったものは「未実測」、確認できなかったものは「未確認」と表示します。
目次
- 1. 原理：予測し、一度に確認する
- 2. vLLMのドラフト手法
- 3. 実際に測定してみる
- 3-1. 2026-10-27再測定：会話モデルと0.32.0
- 4. いつ有効にするか
- 5. 確認できなかったこと
- 参考
1. 原理：予測し、一度に確認する
デコードの1ステップは、重みをメモリから1回読み込むことに大部分の時間を費やします（第2回）。しかし、1ステップでトークンを1つ検査しようと5つ検査しようと、重みの読み込み量は同じです。それならば、次の数トークンを安価に 予測しておき、大きなモデルにそのドラフト全体を 一度に検証させればよいのです。
초안(싼 방법): " keeps a queue of" ← 4토큰 제안
검증(큰 모델 한 걸음): " keeps" ✓ " a" ✓ " queue" ✓ " of" ✓ + 다음 토큰 하나
→ 한 걸음에 5토큰 확정
最初の間違ったトークンで停止し、その場所は大きなモデルが選んだトークンに置き換えます。そのため、1ステップにつき少なくとも1トークンは必ず増加します。サンプリング（温度 > 0）では拒否サンプリング（rejection sampling）により大きなモデル単体で作った場合と同じ分布を維持し、貪欲デコーディングでは出力が一致する必要があります。Leviathanら（ICML 2023）はT5-XXLで出力を変えずに2〜3倍、Chenら（DeepMind, 2023）はChinchilla 70Bで分散環境において2倍から2.5倍高速化したと報告しています（抄録基準）。
メリットは2つの数値によって決まります。
- 受容長：1ステップあたり平均して何トークンを確定するか。ドラフトがよく当たるほど長くなります。
- 検証ステップのコスト：k個のドラフトをまとめて検査するステップが、通常のステップに比べてどれくらい高コストか。GPUに計算の余力がある場合（バッチが小さい場合）はほぼ同じですが、バッチが大きくてGPUがすでに高負荷な場合は、k個多く検査する分だけステップが長くなります。
そのため公式ドキュメントでも、推論デコーディングを「中程度以下のリクエスト率、メモリにボトルネックがある負荷においてトークン間隔を短縮する機能」と紹介しています。
2. vLLMのドラフト手法
| 方法 | ドラフトの生成方法 | 準備物 | ドキュメントの評価（定性） | 論文が報告している数値（抄録基準） |
|---|---|---|---|---|
n-gram（ngram, ngram_gpu) |
プロンプトとこれまでの出力から同じトークン列を見つけてその続きをコピー | なし | 低いリクエスト率で低〜中 | プロンプト照会デコーディング：A100 1枚、Mistral-7B、要約・文脈QAで平均2.4倍 |
suffix（suffix) |
プロンプトと過去のリクエストの出力からサフィックスツリーを作成し、頻度に応じて長さを変えながら提案 | arctic-inference パッケージ |
低〜中、反復が多い作業に強い | SuffixDecoding：エージェント作業（SWE-Bench、Text-to-SQL）で最大5.3倍 |
EAGLE・EAGLE-3（eagle, eagle3) |
大きなモデルの隠れ状態を受け取って次のトークンを出力する小さなヘッド | 学習済みドラフトヘッド | 高 | EAGLE：LLaMA2-Chat 70Bで2.7〜3.5倍。EAGLE-3：最大6.5倍 |
MTP（mtp など） |
モデルが本来持っているマルチトークン予測ヘッド | MTPを持つモデル（DeepSeek-V3、Qwen3.5など） | 高 | |
ドラフトモデル（draft_model) |
同じ語彙を持つ小さなモデル | 小さなモデル | 高 |
設定は1つのJSONで指定します。
vllm serve <모델> --speculative-config '{"method":"ngram","num_speculative_tokens":4,"prompt_lookup_min":2,"prompt_lookup_max":5}'
n-gramの prompt_lookup_max·min は検索するトークン列の長さの範囲であり、両方省略した場合は5です。0.32.0ではModel Runner V2に長さが動的に変わるGPU n-gram提案機が追加されました。0.31.0には ngram_gpu がすでに選択肢にありましたが、実測ではどちらの方法も「Model Runner V2がまだこの方法をサポートしていないためV1ランナーを使用する」という警告が出力されました。CPU版 ngram は「非同期スケジュールの無効化」という警告も出力しました。
一緒に使用できない機能もあります。0.32.0のドキュメントの互換性表によると、推論デコーディングはLoRA、プーリングモデル、プロンプト埋め込み入力と同時に使用できず、 min_p と logit_bias は無視されるという警告がログに記録されました。
3. 実際に測定してみる
方法
- 環境：8GBクラスのノートPC用GPU（Ada世代）1枚、vLLM 0.31.0、Qwen3-Reranker-0.6B（bf16）。
- ワークロード。すべて出力256トークン、
ignore_eos.- コピー：自作の英語段落とPython関数1つ（約300トークン）を与えて「そのまま2回コピーせよ」とする。貪欲デコーディング。出力が入力とほぼ同じであり、n-gramが最も機能するケースです。
- ワードチェイン：30個の単語をランダムに繋げた200単語を与えて続きを書かせる。貪欲デコーディング。このモデルは同じ言葉を繰り返す傾向が強く、出力が入力の単語を再利用することが多くなります。
- ランダム出力：語彙全体からランダムに抽出した200トークンを与えて温度1.0で生成。重複が最も少ないと予想されるケースです。同じシードを使用することで、サーバーが異なっていても同じプロンプトを受け取ります。
- サーバー：デフォルト（推論なし）、n-gram提案2・4・8個、GPU n-gram提案4個。ルックアップ長2〜5。
- 繰り返し：条件ごとに4バッチ（最初のバッチはウォームアップ）、高並行性は3バッチ。受容率はバッチの前後における
vllm:spec_decode_num_accepted_tokens_totalと..._draft_tokens_totalの差から算出しました。
結果1. 単体で使用する場合：コピーすれば4倍から6倍
| 作業（同時1） | デフォルト | n-gram k=2 | n-gram k=4 | n-gram k=8 | GPU n-gram k=4 |
|---|---|---|---|---|---|
| コピー、tok/s | 176.4 | 427.5（2.4倍） | 704.1（4.0倍） | 1,117.0（6.3倍） | 669.5（3.8倍） |
| コピー、受容率 | 97.7% | 99.0% | 95.8% | 95.3% | |
| ワードチェイン、tok/s | 175.6 | 524.7（3.0倍） | 515.8（2.9倍） | ||
| ワードチェイン、受容率 | 90.8% | 67.9% |
k=4はサーバーを個別に2回起動して測定し（692.6、704.1 tok/s）、ほぼ同じ値になりました。コピーにおいて提案数を8個に増やすと、8個のドラフトのうち平均7.7個が当たり、大きなモデルが追加する1トークンを含めて1ステップあたり約8.7トークンが確定しました。しかしスループットは8.7倍ではなく6.3倍でした。9トークンを一度に検証するステップが、通常のステップ（5.7ms）よりも約1.4倍（7.8ms）長かったことを意味します。重みの読み込みが1回であっても、検証するトークンが増えると計算とアテンションが増加します。
「ワードチェイン」も3倍高速化したのは、このモデルが同じ単語を繰り返すためです（例： signal river meadow signal river meadow …）。通常の会話モデルではこのように一致しないでしょう。
結果2. ランダム出力：プロンプトによって異なる
温度1.0のランダム出力はプロンプトごとに結果が大きく異なるため、バッチごとに記載します（同時1、tok/s）。
| プロンプト | デフォルト | k=2 | k=4（受容） | k=8 |
|---|---|---|---|---|
| 1 | 171.4 | 242.4 | 237.6(113/430) | 397.6 |
| 2 | 171.3 | 384.0 | 596.5(202/208) | 914.2 |
| 3 | 171.4 | 149.2 | 153.6(22/175) | 139.9 |
- プロンプト2はランダムなプロンプトであったにもかかわらず、モデルがすぐに同じ言葉を繰り返したため受容率は97%でした。
- プロンプト3はすべてのkにおいてデフォルトより遅くなりました（-13%、-10%、-18%）。 k=4において175個の提案中22個しか当たりませんでした。当たらないドラフトも検証ステップを重くし、n-gramの検索にも時間がかかります。提案を増やすほど（k=8）、ペナルティが大きくなりました。
結果3. 同時実行数を上げるとメリットが減り、ランダム出力は損になる
| 作業 | 同時実行数 | デフォルト tok/s | n-gram k=4 tok/s | 比率 | 受容率 |
|---|---|---|---|---|---|
| コピー | 8 | 1,124.6 | 2,860.6 | 2.54 | 97.1% |
| コピー | 32 | 2,868.7 | 4,042.9 | 1.41 | 83.4% |
| ワードチェイン | 8 | 1,089.7 | 2,478.3 | 2.27 | 92.1% |
| ランダム単語入力、負荷テスト（第2回と同じ条件） | 16 | 1,683.1 | 2,436.5 | 1.45 | |
| ランダム単語入力、負荷テスト | 64 | 2,899.3 | 3,267.8 | 1.13 | |
| ランダム出力 | 8 | 1,072.0 | 950.4 | 0.89 | 58.2% |
| ランダム出力 | 32 | 2,590.8 | 2,239.8 | 0.86 | 51.4% |
バッチが大きくなるとGPUがすでに高負荷になり、検証するトークンが増える分だけステップが長くなります。受容率が高いコピーでも、同時実行数32ではメリットが1.41倍に減減少、受容率が半分程度のランダム出力は同時実行数8と32で11〜14%のマイナスとなりました。ドキュメントの「高リクエスト率ではメリットが減少する」という説明が数値として表れています。
結果4. 出力とコスト
- 貪欲出力の一致：固定プロンプト12個（コピー6、ワードチェイン6）を貪欲デコーディングで128トークンずつ生成したところ、n-gram k=4サーバーの出力はデフォルトサーバーと10個が文字まで完全に一致し、ワードチェインの2個が異なっていました。ドキュメントには、推論デコーディングはアルゴリズム上の損失はないものの、検証ステップが複数のトークンを一度に計算する際に生じる浮動小数点数の違いにより出力が変化する場合があると記載されています。実測結果はその警告と一致していました。
- KVキャッシュ容量：推論デコーディングサーバーでは、KVキャッシュ容量が40,208トークンから30,832トークンへと23%減少しました。同じ警告（V1ランナーへのフォールバック）に伴ってメモリの測定値が変化したものとみられ、原因は未確認です。KVキャッシュがカツカツのサーバーであれば、有効にする前にこの行を確認する必要があります。
- 起動時間：推論デコーディングサーバーは準備に78秒と96秒がかかり、コンパイルキャッシュがヒットしたデフォルトサーバー（約32秒）よりも時間がかかりました。
- 位置ごとの受容:
vllm:spec_decode_num_accepted_tokens_per_pos_totalは、ドラフトの何番目のトークンが当たったかを個別にカウントします。k=4サーバーの全履歴において、1番目から4番目までそれぞれ84.2%、79.4%、77.0%、74.7%であり、1ステップあたり平均4.15トークンを確定しました。後方に向かって低下するこの曲線が、kを選択する根拠となります。
3-1. 2026-10-27再測定：会話モデルと0.32.0
先ほどの測定は、同じ言葉を繰り返すリランクモデルであったためn-gramに有利でした。会話用のQwen3-0.6B（bf16）とvLLM 0.32.0で再測定しました。ワークロードは4つです。
- コピー：上記と同様（生プロンプト、貪欲、256トークン固定）。
- コードを返す: チャット形式で「このPython関数の変数 budget を token_budget に置き換え、関数全体をコードブロックのみで返すこと」。貪欲、自然終了。
- 説明: 「1つの長いプロンプトが、共有言語モデルサーバーの他のユーザーを遅くする理由を3つの短い段落で」。貪欲、自然終了。入力を繰り返すことがほとんどないタスクです。
- ランダム出力: 上記と同じ（ランダムトークン200個、temperature 1.0）。
| タスク | 同時実行 | 基本 tok/s | n-gram k=4 tok/s | 比率 | 受容率 |
|---|---|---|---|---|---|
| コピー | 1 | 176.3 | 656.0 | 3.72 | 87.3% |
| コードの返却 | 1 | 177.7 | 544.2 | 3.06 | 69.7% |
| コードの返却 | 8 | 1,288.6 | 3,252.8 | 2.52 | 69.7% |
| 説明 | 1 | 178.6 | 173.9 | 0.97 | 3.0% |
| 説明 | 8 | 1,163.5 | 1,141.5 | 0.98 | 3.6% |
| ランダム出力 | 1 | 171.9 | 197.3 | 1.15 | 13.0% |
| ランダム出力 | 8 | 1,074.7 | 961.9 | 0.90 | 18.0% |
- 自作の応答では、n-gramがほとんど一致しませんでした。 説明の説明における受容率は3%であり、スループットは3%低下しました。損失が小さいのは、一致するn-gramが見つからない場合に下書きを出力しないステップが多いためです（提案1,188件、再ランキングモデルのランダム出力よりもはるかに少ない）。
- コードの返却は3倍高速化しました。 ただし、この0.6Bモデルは名前を変更するという指示に従わず、関数をそのまま返しました。そのため、この値は「ほぼそのままコピーされた出力」の場合のものです。実際に数行を修正した出力であれば、修正箇所ごとに下書きが外れるため、メリットはこれよりも小さくなるはずです（未計測）。
- 貪欲出力は12件すべてがベースサーバーと文字単位で一致していました。 0.31.0の再ランキングモデルでは12件中10件でした。
- 0.32.0では、KVキャッシュの容量がほとんど減りませんでした。 0.31.0では、推論デコーディングサーバーのKVが23%減少し、「V1ランナーに戻ります」という警告が出ました。0.32.0のログには「Using V2 Model Runner」が出力され、KVは38,224トークンから37,456トークンへ、わずか2%の減少にとどまりました。先ほど未確認とした23%の減少は、V1ランナーへのフォールバックに関連していると推測されます。「非同期スケジューリングをオフにする」という警告は0.32.0でもそのまま残っていました。
4. いつ有効にするか
- 出力が入力を繰り返すタスク（コード修正、文書校正、要約からの文の引用、エージェントの反復呼び出し）では、n-gramだけでも大きなメリットがあります。準備物が不要なため、すぐに有効化できます。
- 通常の会話で応答速度を短縮したい場合 は、EAGLEやMTPのようなモデルベースの手法が適しています。そのモデル用にトレーニングされた下書きヘッドが必要です（未計測）。
- スループットが目的の高同時実行サーバーではメリットが減少し、受容率が低い場合は損失になります。有効化前後のスループットを実際の負荷で測定する必要があります。0.32.0の動的推論デコーディングのように、負荷に応じて提案長を変更する機能はこの問題に対処するためのものです（未計測）。
- 有効にした場合は、
vllm:spec_decode_num_accepted_tokens_total ÷ vllm:spec_decode_num_draft_tokens_totalをダッシュボードに配置し、位置ごとの受容に基づいて k を調整します。
5. 確認できなかったこと
- EAGLE、EAGLE-3、MTP、下書きモデル、suffixは、下書きの重みや
arctic-inferenceパッケージを新しく取得する必要があるため、未計測です。 - 一般的な対話モデルにおけるn-gramの受容率は、3-1節の0.6B単体でしか測定していません。実際に数行を修正するコード編集の出力は未計測です。
- 0.31.0で推論デコーディングサーバーのKV領域が23%減少した原因は、V1ランナーに戻ったことに関連していると推測されるだけで、確認はできていません（0.32.0では2%減少）。
参考
- vLLMドキュメント、Speculative Decoding、N-Gram、Suffix Decoding、EAGLE（0.31.0および0.32.0共通）: https://docs.vllm.ai/en/latest/features/speculative_decoding/
- Leviathan他、「Fast Inference from Transformers via Speculative Decoding」、ICML 2023. https://arxiv.org/abs/2211.17192
- Chen他、「Accelerating Large Language Model Decoding with Speculative Sampling」、2023. https://arxiv.org/abs/2302.01318
- Li他、「EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty」、ICML 2024. https://arxiv.org/abs/2401.15077
- Li他、「EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test」、2025. https://arxiv.org/abs/2503.01840
- Oliaro他、「SuffixDecoding: Extreme Speculative Decoding for Emerging AI Applications」、2024. https://arxiv.org/abs/2411.04975
- Saxena、「Prompt Lookup Decoding」、2023. https://github.com/apoorvumang/prompt-lookup-decoding