メインコンテンツへスキップ

問題点:自己回帰型デコーディングは処理が遅い

LLMは 1 個のトークンずつテキストを生成します。各トークンを生成するためには、モデル内のすべての重みやレイヤーを通る完全な順伝播処理が必要となり、次のトークン生成が始まる前にこれが完了しなければなりません。推論の仕組みで説明されている通り、このデコード段階は メモリ帯域幅に依存 しています。つまりGPUは単一のトークンを生成するためにメモリから何ギガバイトもの重みデータを読み出し、次のトークン生成時にも同様の処理を繰り返すのです。 演算ユニットはほとんどの時間、データ到着を待つだけで何もしていません。GPUは実質的に無駄な時間を過ごしており、メモリからのデータ転送を待っているだけなのです。 スペキュレーティブデコーディングはこの余剰な処理能力を活用する仕組みです。各フォワードパスごとに 1個のトークンを生成する代わりに、複数のトークンを先読みして一括で検証するのです。

基本的な考え方

スペキュレーティブデコーディングでは 2 個のモデルが連携して動作します:
  1. ドラフトモデル — 小規模かつ高速なモデルで、先に N 個のトークン(通常は 4 個から 8 個)を予測します。
  2. ターゲットモデル — 実際に使用したい大規模モデルが、提案された全てのトークンを一回のフォワードパスで検証するのです。
If the target model agrees with K of the proposed tokens, you get K+1 tokens for the cost of 1 forward pass of the large model (plus 1 cheap forward pass of the small model). Wrong guesses are discarded and generation continues from the last accepted token. 計算は簡単です。75%という受け入れ率と5個のドラフトトークンを用いれば、大規模モデルでのフォワードパスごとに平均で2から3個のトークンが生成され、これは1個よりも少ない数値です。この結果、生成速度が2倍から3x倍ほど向上します。
スペキュレーティブデコーディングは出力品質に影響しません。ターゲットモデルが依然としてすべての受け入れ判断を行うため、出力分布は通常の自己回帰デコーディングと数学的には同一です。

N-gramスペキュレーティブデコーディング

別個のドラフトモデルを使う代わりに、N-gramスペキュレーティブデコーディングでは現在のシーケンス内の最後のN個のトークンを参照し、文脈内で同じパターンが過去に現れたかを検索して、そのパターンに続くトークンを提案します。これは既存テキスト内での純粋なパターンマッチングに過ぎません。例えば、最後の4個のトークンがdef calculate_total(であり、文脈内にdef calculate_total(items): return sum(というパターンが存在する場合、エンジンは次にitems、:、return、sumという4個のトークンを提案します。その後ターゲットモデルがこれらを検証します。
最適な用途: コード生成、構造化された出力、反復的なテキスト、テンプレート、ログ解析。不向きな用途: 創作活動、多様な自由形式の応答、反復パターンが存在しない短い文脈。N-gramスペキュレーションは、関数シグネチャやJSONスキーマ、定型コードなど、繰り返し構造が含まれる出力に非常に有効です。一方でパターンマッチングが困難な多様なテキストの場合は受け入れ率が低下し、通常のデコーディングに切り替わる形で静かに機能しなくなります。
追加のモデルダウンロードやVRAMの増設は不要です。唯一のコストは文脈内でマッチングを探すためのCPU時間ですが、GPUでのフォワードパスに比べればごくわずかな負荷にすぎません。

モデルによるスペキュレーティブデコーディングの実装案

同じモデルファミリーに属する小規模なモデルが候補となるトークンを生成します。例えば、Llama-3.1-8BがLlama-3.1-70B用のドラフトモデルとなります。小規模モデルが独自に自己回帰生成を行い 4から8個のトークンを提案すると、大規模モデルがそれらを一括して 1回のフォワードパスで検証します。受け入れ率、つまりターゲットモデルがドラフトモデルからのトークンを承認する割合は、相性の良いモデルペアでは通常 70%から85%の範囲に収まります。受け入れ率が高いほど処理速度の向上幅も大きくなります。
最適な用途: 小規模モデル用のVRAM余裕がある場合の汎用的な生成処理です。メモリ消費量: 両モデルを同時にロードする必要があります。8Bサイズのドラフトモデルを追加すると、ターゲットモデルに加えておよそ 4から5ギガバイト分(Q4量子化時)のメモリが必要になります。事前に モデルの適合性 を確認しておきましょう。Speedup: 1.5-2.5x depending on acceptance rate and draft token count. Diminishing returns past 6-8 draft tokens because acceptance drops for later tokens in the sequence.
ドラフトモデルとターゲットモデルは同じファミリーのものを使用する必要があります。異なるファミリー間の組み合わせ(例:MistralをLlama用のドラフトモデルとして利用)では、トークンの分布が異なるため受け入れ率が著しく低下します。

DFlash:モデルに同梱されるドラフト機能

従来のドラフトモデルの利用では互換性のある小規模モデルを自ら探し、最適な組み合わせを調整する必要がありました。Metaが開発した Muse Glimmer 30B 用ドラフト機能であるDFlashはその手間を省いてくれます。この機能はターゲットモデルと同時に提供され、16個のトークンブロックを提案します。Muse Glimmerはそれらを 1回のフォワードパスで検証する仕組みです。 Meta reports 3.1x on an RTX 5090, 1.8x on an Apple M5 Max, and 1.5x on an Apple M4 Max. These are vendor-reported numbers with no independent reproduction yet, so benchmark your own hardware before you count on them.

モデルネイティブなスペキュレーティブヘッド:MTPおよびDSpark

一部のモデルアーキテクチャでは、一回のフォワードパスだけで複数の将来のトークンを同時に予測するように訓練されています。モデル自体が複数の候補トークンを一度に生成するのです。別途ドラフトモデルを用意したり、パターンマッチングを行ったりする必要はありません。モデル内部の表現からスペキュレーティブトークンが生み出されるのです。これは外部スペキュレーションとは根本的に異なります。複数トークン用ヘッドはベースモデルと共に訓練されるため、文脈に対する理解も共通しているのです。
最適な用途: これをネイティブにサポートするモデルです。設定の選択肢は存在しません。モデルがMTPヘッドを用いて訓練されていれば有効化でき、そうでなければ追加することは不可能です。現在のDeepSeekにおける例: DeepSeek-V4-Flash-0731では公式チェックポイント内にDSparkモジュールが同梱されています。一方Qwenモデル群ではMTPヘッドが採用されています。利点: 別途ドラフトモデル用のチェックポイントやモデルペアのチューニングが不要です。欠点: 特定のモデル訓練が必須となります。任意のチェックポイントにMTPを適用することはできません。
公式の 0731 サンプルでは、同じチェックポイント内に格納されているDSparkヘッドが利用されています。このモデルに対しては --speculative-draft-model-path を追加しないでください。
公式の0731モデルカードには、vLLMおよびSGLang向けのDSparkに関する説明が記載されている。ただしハードウェア対応状況はまだ一定ではないため、該当するランタイム設定を使用し、ご自身のチェックポイントでベンチマークを行ってほしい。詳細は DeepSeek V4 Flash 0731 ローカルハードウェア を参照されたい。

EAGLE(より効率的な言語モデル運用のための外挿アルゴリズム)

EAGLEでは、対象モデルの隠れ状態の上に小さな「ヘッド」ネットワークを学習させる。完全なドラフトモデルを読み込む代わりに、軽量なニューラルネットワークを対象モデルの中間表現に付加し、それを用いて次に来るトークンを予測するのだ。このヘッドネットワークは対象モデル自身の内部状態を参照するため、単純なドラフトモデルよりも高い受け入れ率(80~90%)を実現できる。またヘッドネットワークの規模は完全なモデルに比べて極めて小さく、通常は対象モデルのサイズの5~10%程度に過ぎない。
最適な用途: 利用可能な環境であれば、EAGLEはあらゆる手法の中で最も速度向上とメモリ消費のバランスに優れる。現状: 現在は研究段階であり、ランタイム対応も限定的だ。vLLMおよびSGLangでは実験的なEAGLE統合機能が用意されているが、多くのモデルファミリー向けにはまだ広く公開されていない事前学習済みのEAGLEヘッドチェックポイントが必要となる。When EAGLE support matures, expect: 2-3x speedup with only 5-10% memory overhead — significantly better than full draft models.
EAGLEヘッドチェックポイントはモデルごとかつアーキテクチャごとに異なる。この手法を利用する前に、ご使用の対象モデル向けに公開されているEAGLEチェックポイントが存在するかどうかを必ず確認してほしい。

比較情報

N-gram方式

追加メモリ: なし 速度向上率: 1.2から1.5x 学習の必要性: なし 実行時対応: vLLM、llama.cpp 最適な用途: 繰り返し出現する内容、コード、構造化された出力

ドラフトモデル

追加メモリ: 20から30%分の余分なメモリが必要 速度向上率: 1.5から2.5x 学習の必要性: なし(同じモデルファミリー内のより小さいモデルを利用可) 実行時対応: vLLM、llama.cpp 最適な用途: VRAMに余裕がある環境での汎用的な生成処理

マルチトークン予測方式

追加メモリ: なし 速度向上率: 1.5から2x 学習の必要性: はい(モデルごとに必要) 実行時対応: vLLM(特定のモデルのみ) 最適な用途: DeepSeek V4 Flash 0731 DSparkや対応するQwen MTPバリアントなどの専用モデル向け

EAGLE方式

追加メモリ: 5~10% 速度向上率: 2~3x トレーニングが必要: はい(ヘッドネットワーク) ランタイムでの利用: 実験的段階 最適な用途: 利用可能な場合、速度向上率とメモリ消費量のバランスが最も良い

スペキュレーティブデコードを使うべき場面

以下の場合に利用してください:
  • ワークロードがデコード主体である場合 — プロンプト処理よりもトークン生成に時間がかかる長い生成処理
  • ドラフトモデル用にVRAMの余裕がある場合(ターゲットモデル以外に少なくとも5から10ギガバイトの空き容量が必要)
  • コードやテンプレート、JSON、ログといった構造化された出力や繰り返し的な出力を生成できる
  • You serve a single user or low-concurrency workload
以下の場合は使用しないでください:
  • ワークロードがプリフィル主体である場合 — 入力が長く出力が短い処理(要約や分類など)。スペキュレーティブデコードはデコード段階のみ高速化する仕組みです
  • 既に VRAMの上限に達しています。ドラフトモデルや余分なKVキャッシュエントリが原因でメモリ不足に陥る可能性があります。容量計画については DGX Sparkのメモリチューニング をご参照ください。
  • 高い同時接続数で継続的バッチ処理を行っている場合。スペキュレーティブデコードは多くのランタイムにおける効率的なバッチスケジューリングと競合します。検証処理では各リクエストのドラフト長さが固定であると仮定されるため、バッチ構成が複雑化するからです

実践的なセットアップガイド

vLLMにおけるN-gram推測機能

最も簡単な開始方法です。追加のダウンロードやメモリの確保は一切不要です:
The --ngram-prompt-lookup-max flag sets the window size for pattern matching. Larger values find more matches in long contexts but slow the draft step slightly. Start with 5 and increase if acceptance is low.

vLLMにおけるドラフトモデル

VRAMに余裕がある場合にはさらに高速化が可能です:
メモリ不足に陥った場合は --max-model-lenの値を小さくしてください。両モデルは同じVRAMプールを共有しており、ドラフトモデルのKVキャッシュ分も合算されます。
このようにドラフトモデルを調達・調整するのが一般的な手順です。ただしMeta社の Muse Glimmer 30B ではその手順が不要です。末尾が -dflashとなるOllamaタグ(例えば muse-glimmer:30b-q4_K_M-dflashなど)を取得すれば、特に --speculative-modelフラグを設定せずともDFlashドラフターが即座に利用可能となります。

llama.cppにおけるN-gram推測機能

The --lookup-cache-static flag caches n-gram lookups across tokens, improving draft speed for repetitive patterns.

高速化効果の測定方法

同じプロンプトを二回実行してみましょう。一回はスペキュレーティブデコーディングを有効にし、もう一回は無効にします。そして毎秒生成されるトークン数を比較してください:
ベースラインサーバーを停止し、スペキュレーティブサーバーを起動した上で同一のリクエストを送信して比較します。x-tokens-per-secondヘッダーの値を確認するか、usage.completion_tokensを経過時間で割って算出してください。 体系的なベンチマークを行う際は、vLLMに備わっているベンチマークツールを利用しましょう。
適切にチューニングされたスペキュレーティブ設定では、出力品質や生成トークン数に変化はなく、平均デコード遅延が1.5から2.5x程度改善されます。

さらに詳しく

デコードおよびプリフィル処理の性能

ご使用のハードウェアで最大スループットを得られるよう、プリフィルおよびデコード処理の各段階を調整しましょう。

推論処理の仕組み

プリフィル処理やデコード処理の内容、およびメモリ帯域幅がボトルネックとなる理由を理解しましょう。

DGX Spark上でのvLLM利用

スペキュレーティブデコード機能も含め、最適な設定でvLLMを構成しましょう。

モデルの搭載可否

ご使用のターゲットモデルとドラフトモデルを合わせた際にVRAMに収まるかどうかを算出しましょう。

ご自身のデプロイ状況をベンチマークする

ローカル環境におけるLLMデプロイ向けの体系的なベンチマーク手法について説明する