SPEED-Benchの紹介: 推測的デコードのための統一的かつ多様なベンチマーク

Talor Abramovich

talor-abr

&フォロー

nvidia

Maor Ashkenazi

maorashnvidia

&フォロー

nvidia

Izzy Putterman

IzzyPutterman

&フォロー

nvidia

Benjamin Chislett

benchislett

&フォロー

nvidia

Tiyasa Mitra

TM-nvda

&フォロー

nvidia

Bita Rouhani

Bitadr

&フォロー

nvidia

Ran Zilberstein

RanZilberstein-Nvidia

フォロー

nvidia

Yonatan Geifman

ygeifman

フォロー

nvidia

Despite rapid progress in SD algorithms, their evaluation remains fragmented and often unrepresentative of real-world data and serving conditions.
In practice, SD speculation quality and inference speedups are inherently data-dependent, serving-regime–dependent, and system-dependent.
Yet most existing benchmarks rely on small prompt sets, limited semantic diversity, short input sequence lengths, batch size one, or high-level inference stacks that do not reflect production environments.

To address these gaps, we introduce SPEED-Bench: a unified benchmark designed to evaluate SD across diverse semantic domains and realistic serving regimes, using production-grade inference engines.

What is SPEED-Bench?

SD must be evaluated from two perspectives.

On one hand, draft quality depends on the semantic domain and entropy of the input text.
On the other hand, real-world speedups depend on batch size, input sequence length (ISL), and system constraints, which determine whether inference is memory-bound or compute-bound.

SPEED-Bench therefore introduces a benchmarking ecosystem for SD.
It combines two purpose-built dataset splits and a unified measurement framework, each designed to capture a different aspect of SD behavior:

1. A \"Qualitative\" data split, optimized for semantic diversity and designed to measure speculation quality (drafter accuracy) across domains.
2. A \"Throughput\" data split, constructed to evaluate system-level speedups across various input sequence lengths and high concurrency.
3. A unified measurement framework, integrated with production inference engines, that standardizes evaluation across systems.

Together, these components enable practitioners and researchers to analyze SD behavior that is often masked by existing benchmarks.

Figure 1 provides a high-level overview of the SPEED-Bench ecosystem.

定性的分割: セマンティックカバレッジとドラフトの正確性

定性的分割の目的は、推測的デコーディングの品質を測定することです。具体的には条件付き受諾率（ARs）と受諾長さ（ALs）を、幅広いセマンティックドメインにわたって評価します。

SpecBench は、多様なアプリケーションシナリオ、例えばマルチターン対話、翻訳、数学的推論などにまたがる最初の統一SDベンチマークを、広く使用されているデータセットのインスタンスを統合して統一されたテスト環境を作ることによって導入しました。しかし、標準化された評価へ向けた重要な一歩であるにもかかわらず、スケールと多様性に関して重大な制限があります。ほとんどのカテゴリは、平均入力長が< 100 トークン未満のサンプルがわずか10件程度しかなく、現代のドラフト作成者を圧力をかけるには不十分である可能性があります。さらに、いくつかのカテゴリは構造的多様性に欠けることが多く、多言語カテゴリのように、ドイツ語から英語への翻訳プロンプトのみで構成されていることがあります。

理論上は多数のデータセットに跨る広範な評価が可能ですが、手間がかかり、迅速な実験には実用的でなく、SDアルゴリズムとモデルを公開する異なる研究グループ間の直接比較を妨げます。代わりに、網羅的な評価に頼る代わりに、セマンティック多様性を最大化するよう設計された、コンパクトでありながら高度に代表的なサブセットを厳選します。
18の公開ソースからデータを集約し、Coding、Math、Humanities、STEM、Writing、Summarization、Roleplay、RAG、Multilingual、Reasoning、QAを含む11のカテゴリに整理します。

各カテゴリには80サンプルが含まれており、合計880プロンプトとなります。
従来のベンチマークはカテゴリ内の多様性が低いことが多いのに対し、SPEED-Bench 定性的分割は明示的にセマンティック多様性を優先します。

これを達成するために、各候補プロンプトは事前学習済みのテキストエンベダー(openai/text-embedding-3-small)を用いて密なベクトル空間に埋め込まれます。
次に、各カテゴリ内で平均的な対ペアのコサイン類似度を最小化する選択アルゴリズムを適用します。
これにより、選択されたサンプルが意味空間をできるだけ広くカバーするようになり、冗長性を減らし評価の忠実度を高めます。

このアプローチの有効性は図2に示されており、SPEED-BenchとSpecBenchでの平均セマンティック類似性を比較します。

このセマンティック多様性は、SD におけるドメイン依存の挙動を露呈させる上で重要です。たとえば、低エントロピー領域（例: Coding、Math）と高エントロピー領域（例: Roleplay、Writing）の間の強い対比などです。

The Throughput split: realistic serving workloads

定性的分割はドラフトの正確性を捉えますが、システムレベルの高速化を評価するには不十分です。

システムレベルの高速化を評価するため、2つの指標を用います。Throughput (Output TPS) はすべての同時リクエストに対して1秒あたり生成される総トークン数、User TPS はリクエストあたりのトークン生成レートです。User TPS はエンドユーザーの待機時間の代理として機能します。

実運用環境では、モデルは高い同時実行性とさまざまな入力シーケンス長の範囲の下で提供されるため、多くのSDベンチマークで使われる短いISLサンプルよりも長いことがよくあります。
バッチサイズが大きくなると、推論はしばしば計算ボトルネックの領域からメモリ束縛の領域へ移行し、推測デコーディングのコストと利益のトレードオフを根本的に変えます。

Throughput split はこの挙動を捉えるために特別に設計されています。

長い文脈アプリケーションとしてのCODINGアシスタントや retrieval-augmented generation の重要性が高まることを反映して、1k から 32k トークンの固定ISLバケットを構築します。
各ISLバケットについて、プロンプトは低エントロピー、混合エントロピー、および高エントロピードメインに対応する3つの大まかな難易度カテゴリに集約されます。

各ISLバケットには1,536件のプロンプト（難易度カテゴリごとに512件）、さまざまなバッチサイズにわたって安定したThroughput Pareto曲線を構築するのに十分な量を提供します（図3）。

決定論的なプレフィルコストを保証するため、プロンプトはセマンティック内容を保持しつつ、制御された方法で切り捨てられるか、パディングされます。

重要なのは、SPEED-Bench はスループットのベンチマークにランダムトークン入力を使用しないことです。
後ほど示すように、ランダムトークンは受諾挙動、MoEモデルのエキスパートルーティング、スループットの測定を著しく歪め、過度に楽観的な結論を招く可能性があります。

統一測定フレームワーク

SDを推論エンジン全体でベンチマークすることは、微妙だが重要な課題です。

異なるエンジンは、異なるチャットテンプレートを適用したり、BOSトークンの取り扱いを異なる場合があり、入力を一貫してトークン化しないことがあります。
これらの差は、ドラフトされたシーケンスを黙って変える可能性があり、エンジン間の比較を信頼できないものにします。

SPEED-Bench は、トークン化とプロンプト整形を外部で処理する軽量な測定フレームワークを導入します。
推論エンジンは事前トークン化されたシーケンスを受け取り、すべてのシステムが同一の入力を処理することを保証します。

このフレームワークは、本番グレードのエンジンと統合します: TensorRT-LLM、vLLM、および SGLang。
ストリーミング応答からの細粒度のタイミング情報を取得して、受理挙動、ステップ遅延、ユーザー単位のトークン毎秒、そして全体のスループットを計算します。

以下は、Llama 3.3 70B Instruct をターゲットモデルとして、ドラフトモデルに EAGLE3 を用い、SPEED-Bench の Qualitative 分割において、TensorRT-LLM をバッチサイズ 32（8×H100 GPU）で実行した測定フレームワークの実行例です:

bash-5.2$ 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
...
[TensorRT-LLM] TensorRT LLM version: 1.2.0rc1
...
Running requests (concurrency=32): 100%|██████████| 880/880 [02:58<00:00,  4.93it/s]
...
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
E2E Request Time {'min': '0.1031', 'max': '51.3442', 'mean': '4.7313', 'std': '4.8872', 'quantiles': {'0.25': '1.6972', '0.5': '3.5459', '0.75': '6.1715'}}
TTFT Time {'min': '0.0528', 'max': '0.8010', 'mean': '0.1217', 'std': '0.1133', 'quantiles': {'0.25': '0.0841', '0.5': '0.0982', '0.75': '0.1139'}}
Request Generation Step Time {'min': '0.0000', 'max': '0.8010', 'mean': '0.0299', 'std': '0.0173', 'quantiles': {'0.25': '0.0259', '0.5': '0.0267', '0.75': '0.0280'}}
Request Generation Tokens Per Second {'min': '35.1116', 'max': '142.9547', 'mean': '85.3162', 'std': '17.4823', 'quantiles': {'0.25': '75.0608', '0.5': '84.9756', '0.75': '97.0815'}}
Number of Output Tokens {'min': '3.0000', 'max': '4096.0000', 'mean': '394.8787', 'std': '452.7451', 'quantiles': {'0.25': '123.0000', '0.5': '281.0000', '0.75': '518.2500'}}

この設計は、SD アルゴリズムとシステム最適化の影響を、前処理アーティファクトから分離します。

SPEED-Bench からの洞察

Domain-dependent accuracy and speedups

下の表は、現実的なバッチサイズ（32）とドラフト長さ3において、ドメインとモデルを横断した平均受容長と高速化を報告します。

結果は、SD 受容長が高度にドメイン依存であることを確認しています。
コーディングや数学のような低エントロピーなドメインは一貫してより高い受容長をもたらしますが、ロールプレイや執筆のような高エントロピーなタスクは推測が難しいです。

表は、推測手法間の差異も強調しています。
N-gram 推測のような軽量な手法は、中程度のバッチサイズで純粋な遅延の増加を招くことがあります。さらに、ネイティブ MTP ヘッドは、EAGLE3 のような事後学習済み代替よりもはるかに大きい AL を達成することがわかり、基盤モデルとドラフターをゼロから共訓練する利点を際立たせています。

すべてのカテゴリと異なるモデルの Qualitative 分割に関する完全な結果は、私たちの論文に掲載されています。

語彙の剪定は長尾の失敗を露呈させる

SPEED-Bench can also assist with exposing side effects of aggressive system optimizations.

語彙の剪定は、最終射影層の計算コストを削減するために EAGLE3 で使用されます。
狭い領域で効果的ですが、この最適化はユーザー入力の“長尾”の受容長を低下させる可能性があります。

図 4 は、EAGLE3 を用いた GPT-OSS 120B で、完全な語彙と剪定語彙を使用した場合のドメイン横断の受容長を示します。
コーディングと数学では影響は最小ですが、多言語、RAG、要約カテゴリでは大幅です。

これらの効果は低多様性ベンチマークではほとんど見えず、評価データにおける広範な意味カバレッジの重要性を強調します。

ランダムなトークンはスループットを過大評価する

推論ベンチマークで一般的な手法は、プロンプト負荷を模擬するためにランダムなトークンを使用することです。
自動回帰デコードには十分かもしれませんが、このアプローチは SD アルゴリズム、さらには推測なしの MoE（Mixture of Experts）モデルには本質的に欠陥があり、以下に示します。

ランダムなトークンは、測定値を歪める2つの不具合を引き起こします：

• 些細な応答: モデルはノイズを識別して予測可能な応答にデフォルトし、AL を人工的に過大評価します。

例の出力（ベース: GPT-OSS 120b、ドラフター: EAGLE3、ドラフト長:3、平均 AL: 3.44）:

混在言語の非常に長いブロックを貼り付けたようで、明確な質問や依頼を形成していません。お手伝いできて嬉しいですが、もう少しガイダンスが必要です。
このテキストで何をしたいのか教えてください。例えば: ...

• 話題固定: モデルはノイズ内の特定のキーワードにアンカーし、幻視的な一貫した応答を生み出すことが多く、結果として低い AL をもたらします。

例の出力（ベース: GPT-OSS 120b、ドラフター: EAGLE3、ドラフト長:3、平均 AL: 1.877）:

以下は、拡張され、実運用向けのロードマップ で、最初の Unity のインストールから、完全で磨き上げられた 2-D プラットフォーマー（プレーヤー、カメラ、敵、コレクション、UI、オーディオ、レベル読み込み、そして最終ビルド）へと導くものです。
すべてのタスクは一口サイズに分解され、実行する正確なアクションとその場でコピー可能な C# 断片が用意されています。
...

図 5 は、ランダムトークンと SPEED-Bench ワークロードで測定したスループットを比較します。
SD が有効な場合、ランダムトークンはスループットを約23%過大評価します。

ランダム入力は MoE モデルで現実的なエキスパートルーティングを引き起こすことができず、スペキュレティがない設定でもスループット測定を不正確にします。これは 図 6 に示されています。

SPEED-Bench の利用を開始

SPEED-Bench is released to establish a unified standard for evaluating SD in both research and production settings.

It enables practitioners to analyze draft accuracy across diverse domains, measure throughput under realistic serving regimes, and compare inference engines using identical workloads.

The dataset and measurement framework are openly available and designed to integrate directly with existing SD implementations.

Resources

• 論文
• データセット
• ⚙️ 測定フレームワーク

SPEED-Bench が、推測的デコードのより厳密で現実的、デプロイメントを意識した評価を促進することを願っています！