DSparkを用いたvLLMの適応型検証

vLLMは、投機的デコーディング（speculative decoding）を最適化するために、DSparkの信頼度スケジュール検証（confidence-scheduled verification）を用いた適応型検証を実装しました。学習済みの信頼度ヘッドを使用してドラフト・トークンの生存確率をスコアリングすることで、vLLMはシステム負荷とトークンの信頼性に基づいてステップごとの検証トークン数を動的に決定できるようになり、num_speculative_tokensの手動チューニングが不要になりました。

高並列実行における投機的デコーディングの最適化

投機的デコーディングは、通常、計算リソースを増やす代わりにデコードステップ数を減らす手法です。これはGPUがメモリ帯域に制限される低バッチサイズでは効率的ですが、高並列（例：バッチサイズ256）では、ドラフト・トークンが実際のトークンと計算リソースを競合するため、問題となります。DeepSeek-V4-Pro-0813において、7トークンのブロック内の最後のトークンの生存率が10%未満になるような、採択率の低下が発生すると、拒否されたトークンは貴重な計算リソースを浪費し、全体ののスループットを低下させます。

適応型検証は、静的な投機長を動的な予算（budget）に置き換えることでこれを解決します。固定数のトークンを検証する代わりに、vLLMはバッチ全体の中で最も確率の高いドラフト・シーケンスに検証スロットを割り当て、計算が採択の可能性が高いトークンのみに費やされるようにします。

DSpark 信頼度スケジューリング・メカニズム

適応型検証は、DSparkの信頼度ヘッドを利用して、各ドラフト・トークンに生存確率を割り当てます。システムは、以下のロジックを使用して、ステップ時間あたりの期待トークン生成数を最大化することで、最適なドラフト予算（$B$）を決定します：

Global Top-B Selection: スケジューラは、すべてのリクエストにわたって最適な$B$個のドラフト・スロットを特定します。ドラフト内の位置が大きくなるにつれて生存確率が低下するため、システムは各リクエストのドラフトの連続した接頭辞（prefix）を単純に採用します。
Budget Calculation: 予算$B$は、期待されるボーナス・トークン（サンプリング・リクエスト1つにつきボーナス・トークン1つ＋ $B$個のベストスロットの生存）と、プロファイリングされたステップのコスト（非ドラフト・トークン$T$とドラフト・トークン$B$の合計）のバランスをとるコストモデルから導出されます。
Execution Pipeline: 予算のサイズ決定は、前のステップのダブルバッファ化された信頼度配列を使用してCPU上で行われます。リクエストへのスロットの実際の割り当ては、PyTorchとtorch.compile（Tritonに変換）を介してGPU上で実行され、ホスト・デバイス間の読み戻しを回避します。

技術的実装とCUDA Graphs

可変サイズの検証をサポートするために、vLLMはvarlen decode CUDA graphsを統合しました。この実装は以下のコンポーネントに依存しています：

Attention Kernel Support: システムは、可変長を処理するために、sparse MLAカーネルとDeepGEMMのvarlen indexerカーネルを使用します。
Graph Capture: デコード・グラフは、最大クエリ長 num_speculative_tokens + 1 でキャプチャされます。単一のグラフは、リクエストあたり1からnum_speculative_tokens + 1までの任意のトークン混合に対応できます。
Cost Modeling: 起動時に、エンジンはダミー・ステップをプロファイリングして、検証およびドラフト・コストのルックアップ・テーブルを作成します。プロファイリングのノイズやカーネルのタイルサイズの変動を処理するために、コスト曲線は単調増加になるよう強制されます。
CUDA Graph Padding: コストモデルは、CUDAグラフのパディングによる「階段状」効果を考慮しています（例：121トークンのバッチが128トークンのグラフのコストを発生させる可能性がある）。これにより、予算アルゴリズムが最大限の効率を得るためにCUDAグラフの領域内に留まるよう促されます。

パフォーマンス結果

DeepSeek-V4-Pro-0813 (TP=8 on 8×B300 SM100) でのテストでは、適応型検証が、並列度1から256までのスキャンにおいて、スループット対インタラクティブ性のパレートの境界（Pareto frontier）に一貫して留まっていることが示されました。

このシステムは、低並列時には長い固定ブロックを、高並列時には短い固定ブロックを効果的に模倣し、ワークロードの形状に関する事前知識を必要とせずに両方の利点を提供します。

現在の制限事項

適応型検証には現在、以下の制約があります：

ハードウェア/バックエンド要件: 完全な varlen decode グラフには AttentionCGSupport.ALWAYS が必要であり、現在は SM100 上の DSV4 sparse-MLA、sparse-SWA、および indexer バックエンドで報告されています。
サポートされていない機能: この機能は --enforce-eager モード、LoRA、またはパイプライン並列主義とは互換性がありません。
Logprobs: 検証プロセスがフォワード・パスの後にロジットを圧縮するため、出力の logprobs はサポートされていません。

設定と再現

適応型検証は、speculative-config JSON内の enable_adaptive_verification: true フラグによって有効になります。最適なパフォーマンスを得るには、検証バッチがキャプチャされたグラフ内に収まるように、max_cudagraph_capture_size を (num_speculative_tokens + 1) * max_num_seq に設定する必要があります。