# Accelerating Large-Scale Reasoning Model Inference with Sparse Self-Speculative Decoding > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 4 (May 21 / Thu)、Grand Ballroom 2、09:30 - 09:45 PDT > - **セッション名:** Research Track Oral -- LLM Serving 5（Moderator: Xiang Song） > - **登壇者:** Yilong Zhao (UC Berkeley) ※発表者は筆頭著者から推定 > - **URL:** https://mlsys.org/virtual/2026/oral/3733 > - **OpenReview:** https://openreview.net/forum?id=yeqrwcWjPu > - **共著者:** Yilong Zhao$^{1*}$, Jiaming Tang$^{2*}$, Kan Zhu$^{3}$, Zihao Ye$^{4}$, Chi-Chih Chang$^{5}$, Chaofan Lin$^{6}$, Jongseok Park$^{1}$, Guangxuan Xiao$^{2}$, Mohamed S. Abdelfattah$^{5}$, Mingyu Gao$^{6}$, Baris Kasikci$^{3}$, Song Han$^{2,4}$, Ion Stoica$^{1}$（$*$ 等貢献。$^{1}$UC Berkeley, $^{2}$MIT, $^{3}$University of Washington, $^{4}$NVIDIA, $^{5}$Cornell University, $^{6}$Tsinghua University） > - **コード:** https://github.com/sspec-project/SparseSpec（オープンソース） > [!abstract] 概要（論文アブストラクトの忠実な日本語訳） > 推論言語モデル（RLM）は、精緻な chain-of-thought 解を生成することで困難なタスクにおいて卓越した能力を示してきた。しかし、この長大な生成は推論のボトルネックを計算律速からメモリ律速へ移行させる。各トークンを生成するにあたりモデルは過去の全トークンにフルアテンションを適用するため、増大し続ける KV-Cache へのメモリアクセスが必要となる。生成が長くなるほどステップごとのメモリアクセス要求が増大し、メモリ帯域への負荷が甚大となる。この課題に対し、我々はドラフトモデルとターゲットモデルに**同一のモデル**を再利用する投機的復号フレームワーク SparseSpec（自己投機）を提案する。SparseSpec は新規のスパースアテンション機構 PillarAttn を特徴とし、検証フェーズの情報を巧みに再利用することで重要トークンを正確に選択する。さらに SparseSpec は自己投機と 3 つのシステム最適化を協調設計する: (1) 並列性を最大化するためにドラフトフェーズと検証フェーズを単一バッチにまとめる**統合スケジューラ**、(2) CPU/GPU のオーバーラップを実現する**遅延検証**、(3) GPU メモリ利用を最大化するためにホストメモリへのオフロードを可能にする**動的 KV-Cache 管理**。各種モデルとデータセットにおいて SparseSpec は最先端手法を上回り、最大 2.13 倍のスループット向上を達成する。コードは github.com/sspec-project/SparseSpec で公開されている。 ## 問題設定: RLM 推論はメモリ律速である - OpenAI o1 や DeepSeek-R1 に代表される推論言語モデル（RLM）は、chain-of-thought（CoT）により数百トークンの問題記述から**数万トークン**の解答を生成する。Qwen3-14B は AIME データセットで平均 13,542 トークンを出力し、非推論型の Qwen-2.5-32B-Instruct（平均 2,593 トークン）の約 7 倍である（論文 Table 1）。 - この長大な出力はバッチ推論時に深刻なメモリボトルネックを引き起こす。各リクエストが完了まで巨大な KV-Cache を保持し続けるため、同時処理可能なリクエスト数（バッチサイズ）が厳しく制約される。例えば Llama-3-8B を H100 でサービングする場合、8K 生成長では 64 リクエストしか同時処理できない（論文 3.1 節）。 - H100 上の Qwen3-8B（AIME、平均出力 12K）のプロファイリングでは、アテンションがエンドツーエンド実行時間の 77% 以上を占め、メモリ帯域利用率は全時間にわたり高い一方、計算利用率は 50% 未満にとどまる（論文 Figure 2）。**計算資源に余剰があるにもかかわらずメモリ帯域が飽和している**状態である。 ## 既存手法の課題 - **投機的復号（speculative decoding）** はメモリ帯域ボトルネックを緩和する無損失な高速化手法である。軽量なドラフトモデルが候補トークン列を逐次生成し、ターゲットモデルが並列に検証することで、KV-Cache の読み込みを 1 回に抑える（論文 2.3 節）。 - しかし既存手法には以下の問題がある: - **訓練ベース手法**（EAGLE シリーズ、Hydra、Multi-Token Prediction 等）: ターゲットモデルごとに別個のドラフトモデルの訓練が必要で、デプロイメントの複雑さが増す（論文 1 節）。 - **訓練不要手法**（N-gram、MagicDec、TriForce 等）: RLM のコンテキストダイナミクスへの適応力が不足し、**受理率が oracle Top-K アテンションに遠く及ばない**。MagicDec はスライディングウィンドウアテンションを用いるが、RLM の動的なスパーシティパターンに追従できない（論文 Figure 3）。 - **自己投機手法**（LayerSkip、Self-SD、SkipDecode）: レイヤスキップに基づくためファインチューニングが必要、またはバッチサービングに対応できない（論文 8 節）。 - さらに、受理率が同等であっても**システムレベルの課題**により理論的高速化を達成できない。具体的には (1) ドラフト/検証フェーズ間のワークロード変動、(2) CPU-GPU 間の明示的同期、(3) KV-Cache の非効率な利用（論文 3.3 節）。 ## SparseSpec: アルゴリズムとシステムの協調設計 SparseSpec は**スパースアテンションによる自己投機的復号**を実現するフレームワークである。同一モデルの重みを共有し、ドラフトフェーズではスパースアテンション、検証フェーズではフルアテンションを用いる。アルゴリズム（PillarAttn）と 3 つのシステム最適化（統合バッチスケジューラ、遅延検証、動的 KV-Cache 管理）を協調設計する（論文 Figure 6）。 ### PillarAttn: 動的スパースアテンション（論文 4.1 節） - PillarAttn は自己投機的復号に特化した動的スパースアテンション機構である。KV-Cache のうちアテンションスコアが最も高い**重要トークン（critical tokens）** のみを選択的にロードし計算する。 - **動的スパーシティパターン:** RLM では意味的コンテキストが生成中に大きく変化するため、スパーシティパターンは固定でなく周期的に更新する必要がある。PillarAttn はコンテキストの意味が空間的局所性を持つという仮定に基づき、投機ステップ $k$ と同じストライドで更新する（論文 Figure 7）。 - **オーバーヘッドフリーな識別:** 検証フェーズではフルアテンションが計算されるため、その正確なアテンションスコアをそのまま再利用して次のドラフトステップ用のスパーシティパターンを決定する。カスタムアテンションカーネルによりオンザフライでアテンションスコアを logit と log-sum-exp の形式でダンプする。これらを復元して Top-K を適用し、$k$ 個のドラフトトークンと全クエリヘッド（同一 GQA グループ内は平均化）にわたり重要トークンを特定する（論文 4.1 節）。 - Quest（Tang et al., 2024）のようなクエリ依存スパースアテンション手法と比較して、PillarAttn は検証フェーズの正確なアテンションスコアを使うため、**追加のメモリや計算オーバーヘッドなしに**より高い受理率を達成する。AIME 上の Qwen3-1.7B で受理率 74.20%（Quest は 57.80%）、スループット 4,239 tok/s（Quest は 3,780 tok/s）（論文 Table 5）。 ### 統合バッチスケジューラ（論文 4.2 節） - ドラフトフェーズと検証フェーズは GEMM のリソース使用量が異質である。ナイーブにすべてのリクエストが同一フェーズを同時実行すると、検証フェーズで GEMM バッチサイズが $(k+1)B$ に膨張して飽和点を超え、ドラフトフェーズでは $B$ のみで過少利用となる（論文 Figure 14 左）。 - **統合バッチング:** リクエストを $k+1$ 個のバケットに分散し、各イテレーションで $k$ 個のドラフトバケットと 1 個の検証バケットを同時実行する。新規リクエストは最も負荷の低いバケットに割り当てるグリーディなビンパッキング戦略を採用（論文 Figure 8）。これにより GEMM バッチサイズが $\frac{2k+1}{k+1}B$ 前後で安定し、ワークロード変動が解消される。 - **融合アテンションカーネル:** スパースアテンションとフルアテンションは算術強度が異なるため最適なカーネル構成（タイルサイズ、MMA 命令等）が異なる。SparseSpec は persistent-kernel スタイルの**融合カーネル**を導入し、単一カーネル起動内でドラフト用スパースアテンションと検証用フルアテンションをそれぞれの最適テンプレートにディスパッチする。逐次起動比 1.3 倍、ナイーブバッチ比 1.8 倍の高速化を達成（論文 5.6 節、Figure 15）。 ### 遅延検証（論文 4.3 節） - 投機的復号では検証フェーズの結果（受理/棄却の判定とスパーシティパターンの更新）に CPU 処理が必要であり、次の GPU イテレーションとの間に明示的な同期が生じる。これはエンドツーエンドレイテンシの 20% 以上を占めうる（Srivatsa et al., 2024）。 - SparseSpec は**検証を 1 サイクル遅延**させることでこの同期を排除する。統合バッチングにより検証リクエストはバッチの $\frac{1}{k+1}$ に過ぎないため、非検証リクエストの CPU メタデータ準備は GPU 結果を待たずに進行でき、検証リクエストのみ 1 イテレーション待機する。$k=8$ の場合、追加オーバーヘッドは $\frac{1}{k+1} \approx 11\%$ だが、CPU 操作をクリティカルパスから除去する効果がこれを上回る（論文 Figure 9、5.6 節）。 - Qwen3-14B を $4\times$H100 で実行した場合、GPU 実行 18.37 ms/step に対し CPU 処理 8.55 ms（約 46.5%）が節約でき、遅延検証オーバーヘッド 11% を差し引いても純 1.12 倍のスループット向上（論文 6 節）。 ### 動的 KV-Cache 管理（論文 4.4 節） - RLM の出力長の分散が極めて大きい（AIME で Qwen3-14B の標準偏差 7,626 トークン; 論文 Table 1）ため、出力長予測に基づく KV-Cache 管理は過少利用か再計算のいずれかに陥る（論文 Figure 5）。 - SparseSpec は出力長予測を行わず、**積極的にリクエスト並行度を引き上げて GPU メモリを KV-Cache で飽和させ**、容量不足に近づいたリクエストの KV-Cache をホスト（CPU）メモリへ非同期・チャンク単位でオフロードする。FIFO 順序でオフロード/ロードを行い公平性を保証する。 - Qwen3-8B（バッチサイズ 128）の場合、各デコードステップで生成される新規トークンは 128 個で KV-Cache 増分はわずか 18 MB。GPU レイテンシ約 10 ms に対しオフロードに必要な帯域は約 18 GB/s で、PCIe 帯域の上限を十分下回る（論文 4.4 節脚注）。オフロードによるサイクルタイム延長は平均 0.5% と事実上無視できる（論文 5.6 節）。 - Oracle（出力長既知）に迫る GPU メモリ利用率をゼロ再計算で達成する（論文 Figure 5）。 ## 評価 ### 実験設定 - **モデル:** Qwen3-1.7B（TP1）、Qwen3-8B（TP2）、Qwen3-14B（TP4）。汎用性検証として DeepSeek-R1-Distill-Llama3-8B（TP1）、QwQ-32B（TP4）も評価（論文 Table 2）。 - **ハードウェア:** NVIDIA DGX-H100-SXM5 サーバ。 - **データセット:** AIME（数学）、OlympiadBench（STEM）、LiveCodeBench（プログラミング）。各 2,048 リクエストをサンプリング、温度 0.65。最大バッチサイズ 256。 - **ベースライン:** vLLM（v0.11.0）、vLLM-NGram、MagicDec、TriForce、vLLM-EAGLE3。 - **SparseSpec のハイパーパラメータ:** スパーシティ比 $s=0.05$、投機ステップ $k=8$（論文 5.4 節）。 ### エンドツーエンドスループット（論文 Figure 10、5.2 節） SparseSpec は全構成で vLLM を一貫して上回る: | モデル (TP) | データセット | vLLM (tok/s) | SparseSpec (tok/s) | 高速化 | |---|---|---|---|---| | Qwen3-1.7B (TP1) | AIME | 1,986 | 4,239 | **2.13x** | | Qwen3-1.7B (TP1) | LiveCodeBench | 2,358 | 4,495 | **1.91x** | | Qwen3-1.7B (TP1) | OlympiadBench | 2,534 | 5,163 | **2.04x** | | Qwen3-8B (TP2) | AIME | 2,619 | 4,685 | **1.79x** | | Qwen3-8B (TP2) | LiveCodeBench | 3,094 | 4,897 | **1.58x** | | Qwen3-8B (TP2) | OlympiadBench | 2,753 | 4,937 | **1.62x** (*) | | Qwen3-14B (TP4) | AIME | 4,497 | 6,802 | **1.51x** | | Qwen3-14B (TP4) | LiveCodeBench | 5,300 | 6,968 | **1.31x** | | Qwen3-14B (TP4) | OlympiadBench | 5,166 | 6,906 | **1.34x** | (*) OlympiadBench の Qwen3-8B 高速化は論文 Figure 10 の数値から算出。 - 訓練不要手法との比較: vLLM-NGram に対し最大 1.56 倍、MagicDec に対し最大 1.36 倍、TriForce に対し最大 1.76 倍のスループット向上（論文 5.2 節）。 - 大型モデル・高 TP 度では高速化率がやや低下する。Qwen3-8B と 14B はヘッド次元と KV ヘッド数が同一のため、14B の方がリクエスト収容数が増え飽和点に近づくことが要因（論文 5.2 節）。 ### ドラフトモデルベース手法との比較（論文 Figure 12、Table 2） - EAGLE3（訓練ベース、ドラフトトークン $k=3$）と比較して、SparseSpec は追加訓練なしで**全設定で同等以上のスループット**を達成: - Qwen3-1.7B: 4,632 vs 4,043 (SparseSpec 優位) - Qwen3-8B: 4,840 vs 4,639 (SparseSpec 優位) - Qwen3-14B: 6,892 vs 6,469 (SparseSpec 優位) - DeepSeek-R1-Distill-Llama3-8B（TP1）で 2.43 倍、QwQ-32B（TP4）で 2.38 倍の vLLM 比高速化を達成し、Qwen3 以外のモデルファミリでも有効性を確認（論文 Table 2）。 ### 受理率（論文 Figure 11、5.3 節） - PillarAttn は $k=8$ トークンのドラフトで平均 **6.1 トークンが受理**される（全モデル・全データセット平均）。EAGLE3 は 1.1 トークン、N-gram は 1.6 トークン、Streaming（固定 sink + 最近トークン）は 4.8 トークンにとどまる（論文 Figure 11 左）。 - スパーシティ比 $s=0.05$ で受理率は飽和傾向を示し、ストライドを大きくすると受理率は低下するが $s=0.05, k=8$ が良好なバランスを提供する（論文 Figure 11 右）。 ### レイテンシ分析（論文 Table 3, Table 4） - Qwen3-8B の実行時間内訳（AIME）: SparseSpec はアテンション実行時間を vLLM 比 **3.29 倍削減**（17.1 ms → 5.2 ms、70% 減）、GEMM はわずかに増加（7.2 ms → 8.9 ms、24% 増）、CPU オーバーヘッドは 1 ms 未満を維持。全体で **44% のレイテンシ削減**（28.7 ms → 16 ms; 論文 Table 3）。 - 固定バッチサイズでの TPOT（Time Per Output Token）: Qwen3-1.7B で 1.97 倍、Qwen3-8B で 1.72 倍の改善（論文 Table 4）。 ### アブレーション（論文 Figure 13、5.6 節） Qwen3-1.7B / AIME での段階的アブレーション: | 構成 | スループット (tok/s) | 累積高速化 | |---|---|---| | ナイーブ投機 | 2,135 | 1.23x | | + 統合バッチスケジューラ | 2,624 | 1.61x | | + 動的 KV-Cache オフロード | 4,224 | 1.12x (追加) | | + 遅延検証（SparseSpec 完全版） | 4,722 | **2.22x** (累積) | 3 つのシステム最適化がそれぞれ 1.23 倍、1.61 倍、1.12 倍と有意に寄与する。 ## 議論と制約 - **MoE モデルへの適用:** SparseSpec はアテンションモジュールのみに関与するため、MoE モデルにも修正なく適用可能。MoE ではエキスパートの部分活性化によりエキスパートあたりの入力トークン数が減少し GEMM の飽和点が上がるため、自己投機の恩恵がさらに大きくなる可能性がある（論文 6 節）。 - **Multi-Token Prediction (MTP) との組み合わせ:** EAGLE3 や MTP と階層的に組み合わせ可能。MTP が $k_1$ トークンをドラフトし、PillarAttn で検証後に受理トークンを蓄積、$k_2$ トークン蓄積後にフルアテンションで検証する構成が考えられる（論文 6 節）。 - **制約:** 長生成ワークロードのメモリ効率改善に焦点を当てているため、出力長が短くバッチサイズを大きく取れるタスクでは、ワークロードが計算律速に移行し恩恵が減少する。GPQA-Diamond（平均出力約 8,000 トークン）では Qwen3-1.7B で 1.66 倍、Qwen3-8B で 1.44 倍にとどまる（論文 6 節 Limitation）。 ## 所感・位置づけ - RLM 推論の長大出力がメモリ帯域律速を引き起こすという問題を、自己投機にスパースアテンション（PillarAttn）を組み合わせるアルゴリズム設計と、統合バッチング・遅延検証・KV-Cache オフロードの 3 つのシステム最適化で包括的に解決するフレームワークである。 - 無損失・訓練不要・プラグアンドプレイという 3 条件を同時に満たす点が実用上の強みであり、vLLM への統合可能性が高い。 - スパーシティ比 5% で KV-Cache アクセスの 95% を削減しつつ受理率 76.5% を維持するという結果は、RLM のアテンションパターンが高度にスパースであるという先行研究の知見と整合する。