はじめに：なぜ投機的デコーディングの評価が重要なのか
LLMサービングのコストとレイテンシを劇的に削減できる 投機的デコーディング(Speculative Decoding, SD) 技術が注目を集めています。SDは軽量なドラフトモデル(draft model)が複数の将来トークンを先読みし、ターゲットモデル(target model)がそれを並列検証する方式です。理論上は出力分布を維持しながらスループットを大幅に向上できます。
しかし問題は 評価方法 にあります。既存のベンチマークはデータの多様性が不足し、入力シーケンス長が短く、バッチサイズ1に固定されているケースがほとんどでした。実際の運用環境とはかけ離れた条件で測定された性能は、現場では全く異なる結果を示します。
このギャップを解消するためにNVIDIA研究チームが公開した SPEED-Bench は、SDアルゴリズムを 多様な意味ドメイン(semantic domain) と 現実的なサービング環境(serving regime) で評価できる統合ベンチマークです。本記事ではSPEED-Benchの設計思想と実際の使い方を解説し、実務適用時の注意点も整理します。
SPEED-Benchの二つの核となるデータセット
SPEED-BenchはSDの二つの側面をそれぞれ評価するために Qualitative split と Throughput split で構成されています。
Qualitative split：意味的多様性とドラフト精度
この分割は 意味的多様性(semantic diversity) を最大化し、ドラフトモデルの精度を測定します。18の公開データソースから収集したデータを11カテゴリ(コーディング、数学、人文科学、STEM、文章作成、要約、ロールプレイ、RAG、多言語、推論、QA)に構成し、各カテゴリ80サンプル(合計880プロンプト)を含みます。
鍵となるのは 意味的重複を最小化 する選択アルゴリズムです。各候補プロンプトを openai/text-embedding-3-small で埋め込み、カテゴリ内の平均コサイン類似度(pairwise cosine similarity)が最小になるようにサンプルを選定します。これにより低エントロピー領域(コーディング、数学)と高エントロピー領域(ロールプレイ、文章作成)のSD性能差を明確に捉えられます。
Throughput split：現実的なサービングワークロード
システムレベルの高速化(speedup)を評価するために設計された分割です。入力シーケンス長(ISL) を1k〜32kトークンまで固定バケットに分割し、各バケットに低/中/高エントロピー領域から512個ずつ(合計1,536個)のプロンプトを提供します。
本番環境では高い同時実行性(concurrency)と長いコンテキストが一般的です。バッチサイズが大きくなるほど推論は メモリバウンド(memory-bound) から コンピュートバウンド(compute-bound) へ移行し、SDのコスト対効果のバランスが完全に変わります。Throughput splitはこの現実を正確に反映しています。
注意点： SPEED-Benchはランダムトークン入力を使用しません。ランダムトークンはアクセプタンス長(acceptance length)を歪め、MoEモデルのエキスパートルーティング(expert routing)を非現実的にし、測定値を約23%過大評価することが示されています。
統合測定フレームワーク：エンジン間の公平な比較
SDベンチマークのもう一つの落とし穴は 推論エンジン間の差異 です。各エンジンはチャットテンプレート、BOSトークン処理、トークナイザ方式が異なり、同じ入力でも異なるシーケンスを生成する可能性があります。
SPEED-Benchは 事前トークン化されたシーケンス(pre-tokenized sequences) を全エンジンに渡すことでこの問題を解決します。現在TensorRT-LLM、vLLM、SGLangを正式サポートし、ストリーミング応答から詳細なタイミング情報を抽出してアクセプタンス動作、ステップレイテンシ、ユーザー別TPS、全体スループットを計算します。
以下はTensorRT-LLMでLlama 3.3 70B Instruct(ターゲット)+EAGLE3(ドラフト)の組み合わせでQualitative splitを実行する例です：
mpirun -n 1 --oversubscribe python3 run.py \
--model_dir meta-llama/Llama-3.3-70B-Instruct \
--tokenizer meta-llama/Llama-3.3-70B-Instruct \
--draft_model_dir yuhuili/EAGLE3-LLaMA3.3-Instruct-70B \
--dataset speed --dataset_path data/speed/qualitative \
--tp_size 8 --ep_size 1 --draft_length 3 \
--output_length 4096 --engine TRTLLM --concurrency 32 \
--show_progress
実行結果は以下の主要指標を提供します：
Acceptance Length Histogram
{1: 57385, 2: 36968, 3: 24441, 4: 61182}
Conditional acceptance rate
1 1.0
2 0.681151931368627
3 0.6984444208791836
4 0.7145509968116043
Acceptance Rate Results
┏━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃ Category ┃ Average AR ┃
┡━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│ coding │ 3.0001 │
│ humanities │ 2.3699 │
│ math │ 2.4710 │
│ multilingual │ 1.7277 │
│ qa │ 2.3184 │
│ rag │ 2.7502 │
│ reasoning │ 2.6142 │
│ roleplay │ 2.0407 │
│ stem │ 2.4306 │
│ summarization │ 2.6026 │
│ writing │ 2.6364 │
├─────────────────┼────────────┤
│ Overall Average │ 2.4511 │
└─────────────────┴────────────┘
Output TPS 2518.1464055829188
Output TPS/gpu 314.76830069786485
SPEED-Benchが明らかにした三つの洞察
1. ドメインに依存する精度と高速化の差異
SDのアクセプタンス長(acceptance length)はドメインに大きく依存します。低エントロピー領域(コーディング、数学)は一貫して高いアクセプタンス長を示す一方、高エントロピー領域(ロールプレイ、文章作成)は推測が困難です。またドラフト手法間でも差が顕著です：
| ドメイン | Llama 3.3 70B + N-Gram | GPT OSS 120B + EAGLE3 | Qwen3-Next + MTP |
|---|---|---|---|
| Coding | 1.54 | 2.46 | 3.34 |
| Math | 1.43 | 2.46 | 3.13 |
| Roleplay | 1.15 | 1.87 | 2.09 |
| Writing | 1.33 | 1.98 | 2.46 |
| Mean AL | 1.41 | 2.25 | 2.81 |
| Mean Speedup | 0.88x | 1.34x | 1.20x |
注目すべきは N-Gram 方式が逆に速度低下(net slowdown)を引き起こす可能性がある点です。またMTP(Multi-Token Prediction)ヘッドをベースモデルと共に最初から共同学習(co-training)した場合、EAGLE3のような事後学習(post-trained)方式よりもはるかに高いアクセプタンス長を示します。
2. 語彙刈り込み(Vocabulary Pruning)のトレードオフ
EAGLE3で使用される語彙刈り込みは最終射影層の計算コストを削減しますが、ロングテール(long-tail)入力ではアクセプタンス長を著しく低下させます。特に多言語、RAG、要約カテゴリでその影響が顕著です。この効果は多様性の低い既存ベンチマークでは完全に隠れてしまいます。
3. ランダムトークンは絶対に使うな
多くの研究でランダムトークンでプロンプト負荷をシミュレーションしていますが、これはSD評価に致命的です。モデルがノイズを検知して 予測可能な応答(trivial response) を生成したり、特定キーワードに固執する トピックラッチング(topic latching) 現象が発生し、アクセプタンス長が歪みます。SPEED-Benchの実験では、ランダムトークンを使用するとSDスループットが実際より約23%過大評価されました。
日本開発コミュニティでの適用コンテキスト
日本国内でもLLMサービング最適化への関心が高まっています。特にNECのcotomi、NTTのtsuzumi、そして様々なスタートアップの自社モデルが実際のサービスにデプロイされるにつれ、推論コスト削減 が核心課題となっています。
SPEED-Benchはこうした状況で以下の実務的価値を提供します：
- 日本語特化ドメイン評価： 現在Qualitative splitに多言語カテゴリは含まれていますが、日本語に特化したデータセットは不十分です。今後、日本語コーディングアシスタント、日本語RAG、日本語要約などのドメインを追加すれば、より現実的なベンチマークになります。
- 国内クラウド環境に合わせたチューニング： 日本ではNVIDIA A100、H100 GPUを使用するケースが多いですが、バッチサイズやISL分布はサービスごとに大きく異なります。SPEED-BenchのThroughput splitを活用し、自社サービスの実際のワークロードに最適なSDアルゴリズムを選択できます。
- オープンソースエンジンの活用： vLLMとSGLangはオープンソースで活発に開発されており、日本のスタートアップでも容易に導入できます。SPEED-Benchの統合測定フレームワークを使用すれば、エンジン間の公平な比較が可能です。
まとめ：SPEED-Benchでより現実的なSD評価を始めよう
SPEED-Benchは投機的デコーディング評価の標準を一段階引き上げました。既存ベンチマークが見落としていた 意味的多様性、現実的なサービングワークロード、エンジン間の公平性 を全て解決した点が最大の強みです。
ただし、SPEED-Benchにも限界があります：
- ドラフトモデルのサイズとアーキテクチャ による影響はまだ十分に分析されていません。
- マルチターン対話(multi-turn conversation) シナリオはまだ含まれていません。
- コスト(cost) 面の評価(例：FLOPs対スループット)は提供されていません。
次のステップとしての学習方向
- 実際に実行してみる： SPEED-Benchの測定フレームワークをクローンし、自社モデルに適用してみてください。(根拠資料)
- 多様なSDアルゴリズムの比較： EAGLE3以外にもMedusa、Lookahead Decoding、Self-Speculative Decodingなどを同一条件で比較すると興味深い洞察が得られます。
- 日本語データセットの拡張： 独自の日本語SD評価データセットを構築し、SPEED-BenchのQualitative splitに追加する方法を検討してみてください。
合わせて読みたい記事：