投機的デコーディングベンチマークとは？（トウキテキデコーディングベンチマーク）意味・特徴をわかりやすく解説

Q: 投機的デコーディングベンチマークとは？

投機的デコーディングベンチマーク（Speculative Decoding Benchmark）は、投機的デコーディング手法の性能を定量的に評価・比較するための指標体系と測定手法である。採択率（Acceptance Rate）、トークン/秒（Tokens/s）、レイテンシ、メモリ使用量、スピードアップ倍率を主要指標とし、ハードウェア（A100/H100/RTX 4090）、モデルサイズ、タスク種別ごとの多次元評価が求められる。vLLM・TensorRT-LLM・SGLangなど主要推論フレームワークの実デプロイ環境での比較が実務上重要である。

投機的デコーディングの評価指標体系

投機的デコーディング手法を正確に評価するためには、単一の指標ではなく複数の指標を組み合わせた多次元的な評価が不可欠である。以下に主要な評価指標を体系化する。

指標	定義	単位	測定方法
採択率（α）	検証で採択されたドラフトトークンの割合	%	accepted_tokens / total_draft_tokens
期待採択長	1回の検証ステップで採択されるトークン数の期待値	tokens/step	経験的平均 or (1-α^(γ+1))/(1-α)
出力スループット	単位時間あたりの生成トークン数	tokens/s	total_output_tokens / wall_time
TTFT（Time to First Token）	最初のトークンが出力されるまでの時間	ms	入力送信〜最初の出力の経過時間
TPOT（Time Per Output Token）	1出力トークンあたりの平均時間	ms	(total_time - TTFT) / (output_tokens - 1)
E2Eレイテンシ	リクエスト全体の応答時間	ms	入力送信〜出力完了の経過時間
メモリオーバーヘッド	投機的デコーディングによる追加GPU メモリ使用量	GB	peak_memory_speculative - peak_memory_baseline
スピードアップ倍率	ベースライン（通常の自己回帰生成）に対する高速化率	×	baseline_latency / speculative_latency
品質差異	ターゲットモデル単体との出力品質の差	perplexity差	同一プロンプトでの出力比較

ハードウェア別ベンチマーク結果

投機的デコーディングの効果はハードウェアに強く依存する。メモリ帯域幅対演算能力の比率（Arithmetic Intensity）が低いほど、通常の自己回帰生成が帯域律速になりやすく、投機的デコーディングの恩恵が大きい。

NVIDIA A100 (80GB SXM)

手法	ターゲット	ドラフト	採択率	tokens/s	スピードアップ
Baseline（AR）	Llama-2-70B	—	—	18.5	1.0×
Speculative Sampling	Llama-2-70B	Llama-2-7B	0.75	42.3	2.3×
SpecInfer（4 SSMs）	Llama-2-70B	Llama-2-7B ×4	0.78	55.1	3.0×
Medusa-2	Llama-2-70B	Head ×5	0.68	40.8	2.2×
EAGLE-2	Llama-2-70B	Feature AR	0.82	58.7	3.2×
Sequoia	Llama-2-70B	Llama-2-7B	0.80	65.2	3.5×

NVIDIA H100 (80GB SXM)

手法	ターゲット	ドラフト	採択率	tokens/s	スピードアップ
Baseline（AR）	Llama-2-70B	—	—	32.1	1.0×
Speculative Sampling	Llama-2-70B	Llama-2-7B	0.75	68.5	2.1×
SpecInfer（4 SSMs）	Llama-2-70B	Llama-2-7B ×4	0.78	89.3	2.8×
Medusa-2	Llama-2-70B	Head ×5	0.68	64.2	2.0×
EAGLE-2	Llama-2-70B	Feature AR	0.82	96.8	3.0×
Sequoia	Llama-2-70B	Llama-2-7B	0.80	112.4	3.5×

NVIDIA RTX 4090 (24GB)

手法	ターゲット	ドラフト	採択率	tokens/s	スピードアップ
Baseline（AR）	Llama-2-13B	—	—	35.2	1.0×
Speculative Sampling	Llama-2-13B	TinyLlama-1.1B	0.62	62.8	1.8×
Medusa-2	Llama-2-13B	Head ×4	0.60	59.4	1.7×
EAGLE-2	Llama-2-13B	Feature AR	0.72	74.5	2.1×

H100のようにメモリ帯域幅が広いGPUでは、ベースラインの自己回帰生成自体が高速であるため、スピードアップの絶対倍率はA100より小さくなる傾向がある。ただし、tokens/sの絶対値はH100の方が大きい。

タスク別の採択率分析

投機的デコーディングの効果はタスクの特性（出力のエントロピー、反復パターンの有無）に強く依存する。

タスク	典型的エントロピー	採択率範囲	最適投機長	備考
コード生成	低	0.80〜0.92	6〜8	構文パターンの予測が容易
翻訳	低〜中	0.75〜0.85	5〜7	ソース言語による制約で予測しやすい
要約	中	0.65〜0.80	4〜6	入力テキストからの制約あり
一般QA	中	0.60〜0.78	4〜5	事実ベースの回答は比較的予測可能
創造的ライティング	高	0.45〜0.65	3〜4	自由度が高く予測が困難
数学推論	変動大	0.50〜0.80	3〜6	推論ステップは予測可能、数値は困難
対話・チャット	中〜高	0.55〜0.75	3〜5	ペルソナ・トピック依存

コード生成タスクで採択率が特に高い理由は、プログラミング言語の構文的制約（括弧の対応、インデント、キーワード列）が次トークンの予測を容易にするためである。一方、創造的ライティングでは次トークンの選択肢が広いため、ドラフトモデルの推測が外れやすい。

推論フレームワーク別の実装比較

主要な推論フレームワークにおける投機的デコーディングの実装状況と特徴を比較する。

フレームワーク	サポート手法	ツリー投機	バッチ対応	量子化統合	特徴的な最適化
vLLM	Speculative, Medusa, EAGLE, Draft-Target	○	○	AWQ, GPTQ, FP8	PagedAttention統合、Continuous Batching
TensorRT-LLM	Speculative, Medusa, EAGLE, Draft-Target	○	○	FP8, INT8, INT4	カーネルフュージョン、TensorRTグラフ最適化
SGLang	Speculative, EAGLE	○	○	FP8, AWQ	RadixAttention、プレフィックスキャッシュ
HF Transformers	Assisted Generation	×	△	BitsAndBytes	動的投機長調整
llama.cpp	Speculative	×	×	GGUF (Q4/Q5/Q8)	CPU/Metal/CUDA マルチバックエンド
MLC-LLM	Speculative, Medusa	○	△	INT4	モバイルデバイス向け最適化

vLLMでのベンチマーク実行例

vLLMでの投機的デコーディングベンチマークは以下の手順で実行できる。

--speculative-model にドラフトモデルを指定してサーバーを起動する
--num-speculative-tokens で投機長γを設定する
ベンチマークスクリプト（benchmark_serving.py）でリクエストを送信し、tokens/sとレイテンシを測定する
--enforce-eager フラグでCUDAグラフを無効化して純粋な計算コストを測定する（プロファイリング用）

TensorRT-LLMでの最適化ポイント

TensorRT-LLMはNVIDIA GPU向けに高度に最適化されており、投機的デコーディングのカーネルフュージョンが特に効果的である。ドラフト生成と検証のパイプライン処理、KVキャッシュのページ管理、アテンションカーネルの統合により、フレームワークオーバーヘッドを最小化する。

ベンチマーク設計の注意点

投機的デコーディングのベンチマークを正確に行うためには、以下の注意点を押さえる必要がある。

注意点	説明	推奨対策
ウォームアップ	初回推論はJITコンパイル等で遅延する	10〜100リクエストのウォームアップ後に測定
入力長の統制	入力プロンプト長がプリフィル時間に影響する	固定長プロンプトまたは長さ分布を明記
出力長の統制	出力長がデコーディング時間の大半を占める	max_tokens を統一、または分布を明記
バッチサイズ	バッチサイズが大きいと効果が減衰する	バッチサイズ1, 4, 8, 16, 32 で測定
サンプリング設定	temperature, top_p が採択率に影響する	同一サンプリングパラメータで比較
KVキャッシュ	プレフィックスキャッシュのヒット率が影響する	キャッシュなし/ありの両方で測定
GPU温度	長時間ベンチマークでサーマルスロットリングが発生する	GPU温度監視、ファン速度固定

研究方向	潜在的インパクト	成熟度
EAGLE後継	採択率+10%、スピードアップ+30%	活発に研究中
Speculative RAG	RAGレイテンシ50%削減	初期研究段階
マルチモーダル投機	VLM推論2〜3倍高速化	提案段階
分散推論統合	大規模デプロイの効率化	一部実用化
専用ハードウェア	10倍以上の効率化（長期）	探索段階

よくある質問（FAQ）

Q1: 投機的デコーディングのベンチマークで最も重要な指標は何ですか？

実務的には出力スループット（tokens/s）とE2Eレイテンシ（ms）が最も重要である。採択率は内部指標として有用だが、最終的なユーザー体験に直結するのはスループットとレイテンシである。特にリアルタイムチャットアプリケーションではTPOT（Time Per Output Token）が50ms以下であることが快適な体験の目安とされる。

Q2: バッチ推論環境でのベンチマークはどうすべきですか？

バッチ推論では、リクエストレート（requests/s）を段階的に変化させながらスループットとレイテンシの関係をプロットするのが標準的である。投機的デコーディングは低バッチサイズで最大の効果を発揮するため、バッチサイズ1〜4での測定が特に重要である。高負荷時（バッチサイズ16以上）では効果が減衰するため、Continuous Batching環境での平均的なバッチサイズを把握した上で評価する必要がある。

Q3: 異なるフレームワーク間の公平な比較はどう行うべきですか？

同一ハードウェア、同一モデル（同一チェックポイント）、同一入出力データ、同一サンプリングパラメータで比較することが前提である。さらに、各フレームワークの最適設定（CUDAグラフ有効化、FlashAttentionバージョン、量子化方式）を適用した上での比較が公平である。ベンチマークスクリプトとしては、vLLMの benchmark_serving.py やSGLangの bench_serving.py が広く利用されている。

Q4: 投機的デコーディングの効果が出にくいケースはありますか？

以下のケースで効果が限定的または逆効果になりうる。(1) バッチサイズが大きく既に計算律速の場合。(2) ドラフトモデルの品質が低く採択率が0.4以下の場合。(3) 出力が非常に短い（10トークン以下）場合。(4) GPUメモリが不足しドラフトモデルのロードでターゲットモデルの量子化精度を下げる必要がある場合。これらのケースでは、Medusa/EAGLEのようなヘッド追加型の方がメモリ効率的に有利である。

投機的デコーディングベンチマーク（トウキテキデコーディングベンチマーク）