# Speculative Decoding - Performance or Illusion? > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 4 (May 21 / Thu)、Grand Ballroom 2、09:00 - 09:15 PDT > - **セッション名:** Research Track Oral — LLM Serving 5（Moderator: Xiang Song） > - **登壇者:** Xiaoxuan Liu (UC Berkeley) ※筆頭著者から推定。Xiaoxuan Liu と Jiaxiang Yu が Equal contribution > - **URL:** https://mlsys.org/virtual/2026/oral/3782 > - **共著者:** Xiaoxuan Liu\*^1, Jiaxiang Yu\*^1, Jongseok Park^1, Ion Stoica^1, Alvin Cheung^1（^1 UC Berkeley, Sky Computing Lab） > - **OpenReview:** https://openreview.net/forum?id=fzkqtezFEi > - **関連リソース:** https://github.com/orgs/SpecDecode-Bench/repositories（プロファイリングツールおよびシミュレータ） > [!abstract] 概要（論文 Abstract の忠実日本語訳） > 投機的復号（SD）は大規模言語モデル（LLM）の推論を高速化する一般的な手法として広まったが、先行評価が研究プロトタイプや非現実的に小さいバッチサイズに依拠しているため、実世界での有効性は依然として不明瞭である。本論文は、プロダクショングレードで広く展開されている推論エンジン vLLM 上で SD を体系的に研究した初の成果を、著者らの知る限り提示する。n-gram、EAGLE/EAGLE-3、ドラフトモデル、Multi-Token Prediction（MTP）という複数の SD 変種を、多様なワークロード・モデルスケール・バッチサイズにわたって評価した。SD の性能を支配する重要因子を分析し、SD 高速化の理論的上界を定量化する。結果として、ターゲットモデルによる検証が実行時間を支配し、受理長はトークン出力位置・リクエスト・データセットによって著しく変動することが示された。測定性能と理論上界の比較は、観測値と理論上界の間に大きな乖離を明らかにし、この知見を活用して SD 改善のための新たな研究機会を強調する。 ## 問題設定と動機 - 投機的復号（SD）はメモリアクセスの償却によりレイテンシを削減する手法であり、Gemma 4、Qwen3、DeepSeek V3、GLM-4.5 などのモデル、vLLM・SGLang・Fireworks AI・TensorRT-LLM などのフレームワーク、Cursor・ChatGPT などのアプリケーションに広く導入されている - しかし先行研究の評価には以下の問題がある: - プロトタイプ実装での評価が多く、本番レベルの最適化（CUDA グラフ等）を欠く - バッチサイズ 1 での評価が大半で、実運用の大バッチ環境を反映しない - SD 変種間の横断的比較がほとんどない - 高速化が現れる/消える理由の分析が限定的 - 本論文の目的: プロダクション環境に近い条件での体系的ベンチマークの実施 ## 実験設定 - **推論エンジン・ハードウェア:** vLLM v0.10.1 / v0.11.1、NVIDIA H100（80 GB）。8B モデルは GPU 1 枚、70B/106B モデルは GPU 4 枚（テンソル並列 4） - **最適化:** KV キャッシュ管理、継続バッチング、チャンクドプリフィル、CUDA グラフをすべて有効化 - **SD 手法:** n-gram、EAGLE、EAGLE-3、ドラフトモデル、MTP の 5 種 - **モデル:** Llama3.1-8B、Llama3-70B、Qwen3-8B、GLM-4.5-Air-106B - **ワークロード（6 種）:** - コード編集: InstructCoder - オンラインチャット: ShareGPT - 要約: CNN/DailyMail - 数学: GSM8K - 長鎖推論: AIME22-24、GPQA-Main - **評価指標:** トークン生成スループット（tokens/sec）。高速化率（Speedup）= SD 有りスループット / SD 無しスループット - **復号設定:** 温度 0（greedy）、top_p=1、top_k=-1。最大生成長は通常 8192 トークン、推論ワークロードでは 32,768 トークン ## エンドツーエンド性能 ### バッチサイズの影響 - **バッチサイズの増大はスループットの絶対値を向上させるが、SD の相対的高速化率を系統的に低下させる。この効果は大規模モデルほど顕著である** - Llama3.1-8B / GSM8K での EAGLE の高速化率: バッチ 1 で 1.73 倍 → バッチ 128 で 1.21 倍 - Llama3-70B では低下がさらに大きい: バッチ 1→32 で高速化率が 14.0% 低下（EAGLE / ShareGPT、1.96 倍→1.72 倍） - 原理: 小バッチではシステムがメモリバウンドであり空き計算資源で投機・検証を行えるが、大バッチではコンピュートバウンドとなり、拒否されたトークンの検証オーバーヘッドが相対的に高コストとなる ### SD 変種とデータセットの違い - **n-gram は大半のワークロードで他手法に劣るが、コード編集タスク（InstructCoder）では例外的に最良の性能を達成する** - Qwen3-8B / InstructCoder でバッチ 1 のとき n-gram-fixed-5 が約 2.5 倍の高速化 - コード編集ではプロンプトと出力の重複が高く、n-gram の検索がうまく機能する - **ドラフトモデル手法は 70B ターゲットモデルで最良の性能を達成するが、小規模モデル（8B）では効果が減衰する** - 70B での高い受理率に加え、ドラフトとターゲットの実行時間比（c）が 70B で約 12.5% と小さいのに対し、8B では約 37.5% と大きくなるため - GSM8K・CNN/DailyMail・ShareGPT では EAGLE-3 またはドラフトモデルが全バッチサイズで最高の高速化率 ### ツリー型検証 vs. チェーン型検証 - ツリー型手法（EAGLE Tree k=6, k=21 等）はバッチサイズ 1 でチェーン型よりやや高い高速化率を達成する - 例: Qwen3-8B / GSM8K でチェーン 1.65 倍 → Tree k=6 で 1.68 倍、Tree k=21 で 1.85 倍 - **しかしバッチサイズの増加に伴いツリー型の優位は急速に消失し、バッチ 64 で k=21 ツリーは全ワークロードで 1 倍未満（減速）に陥る** - チェーン型検証のほうがバッチサイズ全体にわたりロバストな選択肢である ### 推論ワークロードと MTP - Qwen3-8B-Thinking では EAGLE-3 が全データセットで一貫してリードし、GPQA-Main および AIME22-24 で 1.64 倍〜1.80 倍の高速化 - n-gram も推論タスクで 1.50 倍〜1.58 倍を達成。長いコンテキストが反復パターンを増やし n-gram に有利に働く - **MTP は n-gram を上回るが理論上界を下回る（GLM-4.5-Air で 1.3 倍〜1.8 倍）。単一の MTP ヘッドをドラフトトークン全体で再利用する制約があり、位置ごとの受理率が急落する（GPQA-Main で 0.91→0.67→0.38）** ## 実行時間とメモリの分解 ### 実行時間の内訳 - SD の実行時間は 4 フェーズに分解される: ドラフティング、検証、棄却サンプリング、その他のオーバーヘッド - **検証時間が全 SD 変種で実行時間の最大部分を占め、総時間の 42%〜95% を占める**。モデルサイズとバッチサイズの増大に伴い上昇 - ドラフティング時間の比率は手法により大きく異なる: - n-gram: 全実行で 2% 未満（ほぼ無視可能） - EAGLE/EAGLE-3: 最大 20% - ドラフトモデル: 最大 47%（Qwen3-8B、バッチ 1） - サンプリング時間は全実行で 1.7% 未満と微小 - vLLM のシステムオーバーヘッドは 3〜12% ### メモリオーバーヘッド - **SD のメモリオーバーヘッドは総じて小さい** - 静的メモリ（モデル重み）: - n-gram: 追加メモリゼロ（CPU 常駐のヒストリから検索） - EAGLE/EAGLE-3: ターゲットモデルの 3.1%〜5.3%（Llama3.1-8B）、1.4%〜4.9%（他モデル） - ドラフトモデル: ドラフトモデルサイズに依存（Llama3-70B + Llama3.2-1B で 1.8% 増、Qwen3-8B + Qwen3-0.6B で 7.3% 増） - トークン当たり KV キャッシュ: - n-gram: 追加なし - EAGLE: 3.1%（Llama3.1-8B）、1.3%（Llama3-70B） - ドラフトモデル: 1.77 倍増（Qwen3-8B + Qwen3-0.6B、144 KiB→256 KiB） ## 受理挙動の分析 - 受理パターンは**3 つの次元で変動する: リクエスト内（トークン位置）、リクエスト間、データセット間** ### リクエスト内の変動 - 長い生成を伴うワークロードほど位置ごとの受理トークン数が増加する傾向がある - n-gram は推論タスクの反復パターン（変数名・数式・定型句の繰り返し）から恩恵を受けるが、**生成の終盤（結論の記述段階）で受理率が低下する** - GPQA-Main / Qwen3-8B-Thinking で n-gram の平均生成長は出力 <4K トークンで 1.6〜3.7 → 出力 >13K トークンで 2.7〜5.0 に成長するが、末尾のトークン区間では低下 - EAGLE-3 はより漸進的に成長し（短出力 2.1〜2.5 → 長出力 2.5〜5.7）、安定したパターンを示す ### リクエスト間の変動 - **ドラフトモデル手法がリクエスト当たり平均生成長の中央値で最長を達成するが、分散も大きい（5th-95th パーセンタイルの幅が広い）** - EAGLE/EAGLE-3 はコンパクトで対称的な分布（中央値付近に集中、典型的に 2〜4 トークン）を示し、安定性が高い - n-gram は裾の重い分布を示し、標準偏差が EAGLE 系の 2〜5 倍。大半のリクエストで短い受理だが、局所的繰り返しが見つかると 15 トークン超のバースト的長受理が発生する ### データセット間の変動 - データセットレベルの統計（Table 4）: - InstructCoder / n-gram: 平均 7.27、中央値 6.57、標準偏差 4.19 - InstructCoder / EAGLE: 平均 4.24、中央値 4.21、標準偏差 1.07 - InstructCoder / EAGLE-3: 平均 4.18、中央値 4.06、標準偏差 0.99 - GSM8K / n-gram: 平均 1.41、中央値 1.28、標準偏差 0.47 - ShareGPT / EAGLE-3: 平均 3.06、中央値 2.92、標準偏差 0.80 - GPQA-Main / n-gram: 平均 4.20、中央値 3.73、標準偏差 2.24 - GPQA-Main / EAGLE-3: 平均 2.78、中央値 2.49、標準偏差 0.87 ## ケーススタディ: InstructCoder における n-gram の性能 - n-gram がコード編集で特に強い理由の仮説: **プロンプトと出力の間の局所的繰り返し（local repetition）** - BLEU-4 スコアでプロンプト−出力間の重複度を定量化し、n-gram と EAGLE/EAGLE-3 の相対的高速化率と相関を分析 - **BLEU-4 スコアが一定閾値（例: Llama3.1-8B で 0.6）を超えると、n-gram が全バッチサイズで EAGLE/EAGLE-3 を一貫して上回る** - 提案長 3 で最大 53% の相対高速化、提案長 5 にすると最大 100% の相対高速化を達成 - コード編集の構造上の特徴: 出力はプロンプトの大部分をそのまま保持し、局所的な編集のみを適用する（Figure 15 の例: クラス定義の文字列型を enum 型に置換するタスクで、大部分のコードは変更なし） ## 理論的高速化上界 ### エンドツーエンド高速化の定式化 - SD の高速化は式 $E(\text{speedup}) = \frac{1 - \alpha^{k+1}}{(1-\alpha)(kc+1)}$ で表される - $k$: 提案長、$c$: ドラフトとターゲットの 1 回フォワードパスの実行時間比、$\alpha$: トークン受理率 - 高速化はこの 3 因子のバランスで決まり、ドラフト手法の絶対実行時間ではなくターゲットモデルとの比率のみが影響する ### オラクル vs. 固定長・適応的ポリシー - 3 つの提案長ポリシーを比較: - **固定長**（k=1, 3, 5） - **適応的ヒューリスティック**（初期 k=5、全受理で +2、拒否で -1、最小 1） - **オラクル**（各ステップで実際の受理数を提案長として使用 = 拒否トークンの検証を完全に排除する理想設定） - **現行手法とオラクルの間に大きな乖離がある:** - n-gram / InstructCoder / バッチ 1: オラクル約 2.75 倍 vs. 固定 k=5 約 2.1 倍 vs. 適応的約 2.3 倍（差 +0.45 倍〜+0.65 倍） - EAGLE-3 / InstructCoder / バッチ 1: オラクル約 2.8 倍 vs. 固定 k=3 約 2.4 倍（差 +0.42 倍） - **バッチサイズの増加に伴い乖離は拡大する**: 固定 k と適応的ポリシーはオラクルよりも急速に劣化する ### 相補的 SD 手法の組合せ - n-gram と EAGLE-3 は位置ごとに異なる受理パターンを示し、相補的な強みを持つ（Figure 9: 赤=EAGLE-3 が優位、青=n-gram が優位の領域が交互に出現） - **Oracle_Combined**（各位置で n-gram と EAGLE-3 のうちより長い受理を選択する理想的な組合せ）を定義: - InstructCoder / バッチ 1: Oracle_Combined は Oracle_EAGLE3 に対し**最大 +1.60 倍**の追加高速化（約 4.9 倍の端対端高速化） - GSM8K / バッチ 1: +0.24 倍の追加高速化 - **組合せの利得はワークロードに強く依存する**: InstructCoder のように n-gram と EAGLE-3 が交互に優位する場面が多いワークロードで最大。GSM8K のように n-gram の受理が全般に低いワークロードでは Oracle_Combined が Oracle_EAGLE に近づく ## 主要な知見と今後の方向性（スライド Takeaways） 1. **投機的復号は実際に高速化をもたらす** — 全構成で SD なしのベースラインを上回る 2. **検証がランタイムのボトルネックである** — 拒否されたトークンの検証に費やされる計算が最大の無駄であり、検証コスト削減が最も効果的な最適化方向 3. **受理挙動はトークン位置・リクエスト・データセットにわたって変動する** — 単一の固定 k ポリシーでは対応しきれない 4. **適応的な提案長と提案手法の選択が有望な将来方向である** — 軽量な予測器でワークロード・位置・リクエストに応じて最適な手法と提案長を動的に選択する仕組みの開発 ## 関連情報 - 論文の ACM Artifacts Available および Artifacts Evaluated – Functional バッジを取得 - コードとシミュレータ: https://github.com/orgs/SpecDecode-Bench/repositories