💬 NLP

D-cut: Adaptive Verification Depth Pruning for Batched Speculative Decoding

D-Cutは、ドラフトの信頼度と実行時コストモデルに基づいて、並行するリクエスト間で検証予算を動的に割り当てることで、高コンカレンシー下での推論加速を大幅に向上させつつ、拒絶されたトークンへの計算資源の浪費を防ぐ、バッチ化された投機的デコーディングのための適応型検証深度プルーニング手法である。

原著者： Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

公開日 2026-07-17

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたは、ある巨大で高速な図書館を運営していると想像してください。そこでは、一人の非常に賢い司書（AI）が、一度に数千人もの人々の質問に答えています。この司書は極めて優秀ですが、非常に特殊な働き方をします。彼らは一度に一つの単語しか書き込むことができません。複雑な質問に答えるためには、「考え、一つの単語を書き、また考え、次の単語を書き……」というプロセスを繰り返さなければなりません。この「一度に一つの単語」というルールこそが、図書館が渋滞する主な原因です。司書は、次の単語を取り出すために、ほとんどの時間を「待ち時間」として費やしてしまうのです。

この状況を改善するために、エンジニアたちは「投機的デコーディング（speculative decoding）」と呼ばれる巧妙なトリックを考案しました。司書が一つずつ単語を書く代わりに、少しだけ頭の回転が遅いアシスタント（ドラフター）を雇い、数単語をまとめて予測させるのです。司書はその予測を素早くチェックします。もし予測が正しければ、司書はそれらを一度に受け入れ、「考え、待つ、書く」というサイクルをスキップできます。これは、アシスタントが「次は『The』、『quick』、『brown』だと思います！」と叫び、司書が「その通りだ！」と言って次に進むようなものです。この方法は、図書館が空いている時には非常にうまく機能します。しかし、64人もの人々が同時に質問を投げかけているような、混雑した状況ではどうなるでしょうか？アシスタントは全員に対して長い予測リストを叫び続けますが、司書はそれらすべてをチェックしようとして、手一杯になってしまいます。もし予測が間違っていた場合、司書は捨てられるはずの単語をチェックするために貴重な時間を無駄にしてしまい、図書館全体の速度を低下させてしまいます。これが、この論文が取り組んでいるパズルです。つまり、群衆が巨大になったとき、どのようにしてスピードアップを維持するかという問題です。

問題点：多すぎる予測、足りない時間

Tencent Hunhengの研究者たちは、システムに不具合があることに気づきました。最近、新しいアシスタント（DFlashと呼ばれるものなど）は、例えば一度に15単語といった長い予測リストを叫ぶのが非常に得意になりました。図書館が空いているとき、これは超能力でした。司書はそのほとんどを受け入れ、図書館は質問を猛スピードで処理できました。

しかし、群衆が増えると（「バッチサイズ」や同時リクエスト数が増加すると）、システムはクラッシュし始めました。アシスタントは長いリストを叫び続けますが、手一杯になった司書はそれらをすべてチェックすることができなくなりました。さらに悪いことに、それらの長いリストの多くは間違いでした。司書は、結局拒否されることになるゴミのような単語をチェックすることに全エネルギーを使い果たしてしまいました。それはまるで、混雑したコンサートのセキュリティガードが、列に並ぶ15人のIDをチェックした挙動の末に、10人が偽物であることに気づき、本当のファンを入れるために使うべきだった時間を無駄にしてしまうようなものです。研究者たちは、混雑時にはこの「長い予測」方式が、実際には司書が一人で一つずつ単語を処理するよりも遅くなってしまうことを発見しました。

解決策：D-cut（スマートな用心棒）

この問題を解決するために、チームは「D-cut」と呼ばれる新しい戦略を提案しました。D-cutは、アシスタントと司書の間に立つ、非常に賢い用心棒だと考えてください。

アシスタントに全員分の長い予測リストを叫ばせ、司書にそれをすべてチェックさせるのではなく、D-cutは群衆と予測をリアルタイムで観察します。D-cutは次の2つのシンプルな質問を投げかけます。

アシスタントの自信はどの程度か？ アシスタントが自信を持って叫んでいるなら、用心棒はその予測を通します。もしアシスタントが口ごもったり確信が持てなかったりする場合は、用心棒はリストを短く切り詰めます。
司書はどの程度疲れているか？ 用心棒は司書の現在のワークロードをチェックします。もし司書が多忙であれば（例えば、混雑したGPUチップ上であれば）、用心棒はより厳格になり、より多くの予測をカットします。もし司書が新鮮で強力であれば（例えば、別のより高速なチップ上であれば）、用心棒はより多くの予測を通します。

D-cutは単に一人のためにリストをカットするのではなく、リクエストの「バッチ全体」を見渡します。ある人にとってはアシスタントは天才だが、別の人にとってはアシスタントはデタラメに推測しているだけである、ということを理解します。そのため、D-cutは「検証予算（司書がチェックするために使える時間）」を、最も正解する可能性が高い人々に割り当てます。自信のない、長い予測の「裾野」を刈り取り（プルーニング）、司書のエネルギーを信頼度の高い部分に集中させるのです。

実戦での仕組み

研究者たちは、小さなモデルから巨大なモデルまで、さまざまなAIモデルや異なる種類のコンピュータチップを用いて、このアイデアをテストしました。その結果、D-cutは混雑時にゲームチェンジャーとなることがわかりました。

高負荷時の救世主： リクエスト数が多いとき（一度に64人がいるような場合）、従来の方法（DFlash）はしばしば、標準的な「一つずつ単語を処理する方法」よりも遅くなるほど速度が低下しました。D-cutはこの問題を解決しました。図書館が満員の状態でも、スピードアップを維持し続けました。
数値による実績： テストにおいて、D-cutは高負荷時における平均速度を、標準的な方法と比較して1.26倍から1.65倍へと向上させました。特定の非常に大規模なモデルでは、最大で3.0倍の速度に達しました。
ハードウェアへの適応： 最も素晴らしい機能の一つは、D-cutが群衆が到着する前に、司書がどれほど速いかを学習できることです。D-cutはコンピュータチップ（H20やH800 GPUなど）をプロファイリングし、一つの単語をチェックするコストがどれくらいかを調べます。チェックが「高価」であれば（遅いチップの場合）、D-cutはより積極的にカットします。チェックが「安価」であれば、カットを控えます。これにより、新しいコンピュータごとに人間がチューニングする必要はなく、自動的に最適化されます。

何を行わないのか（そして何を否定したのか）

D-cutが「何ではないか」を知っておくことも重要です。D-cutは、アシスタントをより賢くしたり、司書の考え方を変えたりしようとするものではありません。出力される回答自体は変わりません。司書がすべてをチェックした場合の結果と全く同じであり、ただその結果に到達する速度が大幅に向上するだけです。

この論文は、「長い方が常に良い」という考え方に明確に反対しています。彼らは、（DFlashのような）15単語のブロックを盲目的に生成することは、群衆が多い時には悪いアイデアであることを示しました。「全員に同じ数の予測をチェックする」という一律のアプローチは、全員が同じ量のチェックを必要としているわけではないため、失敗します。D-cutは、網羅的であることよりも、選択的であることが優れていることを証明しました。

結論

研究者たちは、単にこれが機能する可能性があると示唆しただけでなく、測定を行いました。彼らは、数千のリクエストが発生する実際のサーバー上でシミュレーションと実世界のテストを実施しました。その結果、低信頼度の予測をカットし、高信頼度の予測に集中させる、適応型のスマートな用心棒になることで、D-cutはAIライブラリが満員になっても高速に動作し続けることが証明されました。これは、本来ならら慢な速度に落ちるはずのシステムを、効率的な状態に保つことができます。時には、速く進むための最善の方法は、間違っているとわかっていることをチェックするのを止めることである、ということを証明したのです。

技術要約: D-cut: バッチ化された投機的デコーディングのための適応型検証深度プルーニング

1. 問題提起

投機的デコーディング（Speculative Decoding）は、ドラフト生成と検証を分離することで、大規模言語モデル（LLM）の推論を加速させる主要なロスレス手法として台頭しています。近年の進展（DFlashなどのブロック並列ドラフターなど）は、単一のフォワードパスでドラフト・トークン全体のブロックを生成し、ドラフト長とドラフト・レイテンシを切り離すことで、低コンカレンシー設定において高い平均受理トークン数（MAT）を実現しています。

しかし、本論文は高コンカレンシーなバッチ・サービングにおける決定的なボトルネックを特定しています。

検証コストの爆発: バッチサイズ（ $B$ ）が増加するにつれ、ターゲットモデルはステップごとに $B \times (D+1)$ 個のトークンを検証しなければなりません（ここで $D$ はドラフト長）。これにより、検証プロセスはメモリ帯域制限から計算量制限へとシフトします。
非効率なリソース配分: 高コンカレンシーのシナリオでは、長く固定された深度のドラフトは高い拒絶率を招きます。例えば、ドラフト長が15の場合、平均受理長は約6トークンに過ぎず、検証されるトークンの約60%が拒絶されていることを意味します。
スループットの低下: 拒絶されたトークンの検証にかかる計算コストがステップ時間を膨張させ、高バッチサイズ（例：$bs=64$）において、投機的デコーディングのスループットが飽和、あるいは標準的な自己回帰（AR）デコーディングを下回る原因となります。
静的 vs 動的ニーズ: 既存の手法は通常、バッチ内の全リクエストに対して一律の検証深度を適用します。これは、同時実行されるリクエスト間での受理長の大きな分散や、異なるハードウェア環境（例：計算資源が制約されたH20 vs 計算資源が豊富なH800 GPU）における検証の計算コストの違いを考慮できていません。

2. 手法: D-cut

著者らは、検証予算をバッチ全体の共有リソースとして扱い、受理される可能性が最も高いトークンに動的に割り当てる適応型プルーニング戦略であるD-cutを提案します。この手法は、ターゲットモデルの変更や追加の学習を必要としません。

コアメカニズム

リクエスト横断型プルーニング（信頼度ガイド）:
- すべてのリクエストに対して固定の深度を検証するのではなく、D-cutはドラフターの予測信頼度を用いて、バッチ内のすべての候補トークン位置をスコアリングします。
- 各位置に対して「接頭辞積（prefix-product）」スコア（ $s_{i,k}$ ）を計算します。これは、ブロックが深さ $k$ まで生存する確率を表します。
- バッチ内のすべての候補位置をこれらのスコアによってグローバルにランク付けします。信頼度の低い接尾辞はプルーニングされ、信頼度の高い接頭辞は保持されます。これにより、検証予算が低収益のリクエストから高収益のリクエストへとシフトされます。
実行時適応型深度選択:
- 追加のトークンを検証するコストは、実行時の環境（GPUタイプ、モデルアーキテクチャ、並列化戦略、およびバッチサイズ）に大きく依存することを認識し、D-cutはプロファイリングされたコストモデルを組み込んでいます。
- プロファイリング: サーバー起動時に、D-cutは様々な離散的な検証予算比率（ $\rho \in \{0.25, 0.50, 0.75, 1.00\}$ ）およびバッチサイズに対して、エンドツーエンドの投機ステップのレイテンシをプロファイリングします。
- 最適化: サービング中、D-cutは期待されるスピードアップを最大化する最適なグローバル予算比率（ $\rho^*$ ）を動的に選択します。スピードアップは、期待される利益（信頼度スコアに基づく推定MAT）とハードウェア・プロファイリングされた実行コストの比として定式化されます。
- これにより、D-cutは計算資源が制約されたハードウェア（例：H20）やドラフト品質が低い場合には積極的にプルーニングを行い、一方で、検証コストが低い計算資源が豊富なハードウェア（例：H800）では、より多くのトークンを保持するように適応できます。

パイプラインの概要

ドラフティング: ドラフターが信頼度スコアを伴うトークンブロックを生成します。
スコアリングとランキング: セレクターはすべての位置をフラット化し、接頭辞積スコアを計算して、グローバルにランク付けします。
予算選択: セレクターは、ユーティリティ対コストの比を最大化する最適な予算比率 $\rho^*$ を選択するために、事前プロファイリングされたコストテーブルを参照します。
パッキング: スコアの高い上位 $K$ 個の位置が、高密度な検証バッチにパックされます。重要な点として、保持される位置はスコアが接頭辞積であるため、各リクエストに対して連続した接頭辞を形成し、既存の推論エンジンやCUDAグラフとの互換性を確保します。
検証: ターゲットモデルがパックされたバッチを検証します。

3. 主な貢献

ボトルネックの特定: 本論文は、高コンカレンシーなバッチ・サービングにおいて、長い固定深度のドラフト（DFlashなど）が、拒絶されたトークンの高い検証コストにより、スループットをARデコーディング以下に低下させることを実証的に示しています。
D-cut アルゴリズム: ドラフトの信頼度に基づいたクロスリクエスト検証深度プルーニングングと、実行時適応型深度選択を行う、学習不要のロスレスなプルーニング戦略です。
実行時コストモデリング: 静的なヒューリスティックに頼るのではなく、特定のデプロイ環境（ハードウェア、バッチサイズ、モデルアーキテクチャ）に適応できる、プロファイリングされたコストモデルの導入。
システム統合: D-cutは、検証予算を離散的な比率に制限することで、既存の推論エンジン（vLLMなど）と動作するように設計されており、区分的なCUDAグラフのキャプチャへの適合性と形状爆発の回避を実現しています。

4. 実験結果

著者らは、NVIDIA H20およびH800 GPUを用い、6つのターゲットモデル（密なアーキテクチャおよびMoEアーキテクチャを網羅）と5つのベンチマーク（math, code, chat）でD-cutを評価しました。

スループットの向上: 高コンカレンシー（バッチサイズ32）において、D-cutはDFlashベースラインと比較して、オートレグレッシブ・デコーディングに対する平均スピードアップを 1.26倍から1.65倍 に向上させました。
加速の回復: 長いドラフトを持つDFlashが、高コンカレンシー時にARデコーディングを下回る密なモデルにおいて、D-cutは正の加速を回復させます。
MoEの性能: Mixture-of-Experts (MoE) モデルにおいて、D-cutはオートレグレッシブ・デコーディングに対して最大 3.0倍のスピードアップ を達成しました。
ハードウェア適応性:
- 計算資源が制約されたH20では、D-cutは積極的にプルーニングを行い（多くの場合25%の予算を選択）、固定比率のベースラインを大幅に上回ります。
- 計算資源が豊富なH800では、D-cutはより多くのトークンを保持するように適応し（多くの場合50%以上）、不要なプルーニングを行うことなくスループットを最大化します。
堅牢性: D-cutは、標準的な長いドラフト手法が完全に失敗する確率的なターゲットサンプリング（温度1）の下でも、その優位性を維持します。

5. 意義と主張

本論文は、D-cutが現在の投機的デコーディング・システムにおける根本的なミスマッチ、「長いドラフトは常に優れている」という仮定に対処していると主張しています。著者らは、バッチ・サービングにおいては、検証の計算量こそが希少なリソースであると述べています。

パラダイムの転換: 本研究は、焦点を「単一リクエストの受理長を最大化すること」から、「バッチ化された検証の効率を管理すること」へとシフトさせています。
実用的な影響: D-cutは、強力なブロック並列ドラフターを、それ自体では有害となる可能性のある高コンカレンシーなプロダクション環境で使用可能にします。
限界: 著者らは、検証バッチの形状の変化が、現在の推論エンジン（Spec-V2や区分的なCUDAグラフなど）の静的な形状の仮定に適合させるための注意深い取り扱いを必要とするという、システム統合上の課題を認めています。彼らは、動的な検証の全潜在能力を実現するには、サービング・フレームワークとのより緊密な協調設計が必要であると述べています。

要約すると、D-cutは、より多くのトークンを受理することによるアルゴリズム上の利益と、それらを検証するためのハードウェアコストとのトレードオフを動的にバランスさせるメカニズムを提供し、高負荷下でも投機的デコーディングが実行可能な加速技術であり続けることを保証します。