記事一覧へ戻る
推論・デプロイ

vLLM の DCP、長文脈推論における KV キャッシュの壁を崩す

読了目安 3 分

導入

長文脈推論は、もはやモデルのデモ機能ではなく、エージェント型 AI の実運用に近い課題になっている。コードリポジトリ、長い会話履歴、複数ターンのツール実行ログを扱うと、入力は 64K token を超え、場合によっては 1M token に近づく。vLLM のブログが焦点を当てるのは、この状況で decode 時の KV キャッシュが GPU メモリを占有し、並行処理数とスループットを制限するという問題だ。

主要ポイント

  • 従来の TP は KV キャッシュの分割に限界がある。 一般的な tensor parallelism は注意ヘッド単位で KV を分ける。しかし GQA では KV ヘッド数が少なく、並列度を上げると分割できず複製が発生する。MLA では Key/Value が共有された低ランク latent に圧縮されるため、ヘッド方向に切る余地はさらに小さい。
  • DCP はシーケンス方向に分割する。 Decode Context Parallelism は、同一リクエストの KV キャッシュをトークン位置の範囲ごとに GPU へ割り当てる。たとえば 200K token の文脈を複数区間に分ければ、各 GPU は全体の一部だけを保持すればよい。これにより 1 GPU あたりのキャッシュ使用量が下がり、より大きな batch と高い並行数を扱いやすくなる。
  • 通信パターンは decode に合わせて設計されている。 DCP では query を集約し、各 GPU がローカルの KV 断片に対して attention を計算し、最後に部分結果を統合する。decode では query が 1 token 分なので、この集約コストは比較的小さい。MLA 向けには query projection を複製して query all-gather を省くオプションも示されている。
  • 効果は長文脈・高並行で大きい。 ブログの実験では、単一の 8×B200 ノードで Kimi K2.6 を NVFP4 と vLLM で提供した。基準 TP は並行数 64 で KV 使用率が 100% に達し、約 1,863 tok/s/GPU 付近で頭打ちになった。一方 DCP は並行数 512 でも KV 使用率 82% にとどまり、6,091 tok/s/GPU を記録した。ブログはこの負荷で約 3 倍のスループット向上と説明している。

意味と影響

DCP の重要性は、単一の長文脈リクエストを劇的に速くすることだけではない。より本質的なのは、長い入力を持つ多数のエージェントセッションを同時に載せられるようにする点だ。GPU メモリを圧迫する KV キャッシュの複製を減らせれば、同じハードウェアでより多くのユーザーを処理でき、対話性とコストの両方に効いてくる。

また、GQA や MLA の普及により、ヘッド単位の分割だけに頼る設計は限界を迎えやすい。vLLM の DCP は、長文脈時代の推論サービングで、キャッシュ配置と GPU 間通信がモデル本体の最適化と同じくらい重要になっていることを示している。

出典:vLLM Blog

コメント

ログイン状態を確認中…

コメントを読み込み中…

関連記事

CCTest · Blog
SiliconBenchが示す、速度だけでは測れないローカルLLM推論
推論・デプロイ
cctest.ai
推論・デプロイ

SiliconBenchが示す、速度だけでは測れないローカルLLM推論

SiliconBenchは、Apple Silicon向けの9つのLLMサービングエンジンを速度、メモリ、出力忠実度の3軸で評価した。並列実行では、スループットだけでなくメモリ余裕、モデル対応範囲、通信方式が実用性を左右する。

続きを読む
CCTest · Blog
vLLMがQwen3.8-2.4TのPDサービングを最適化した方法
推論・デプロイ
cctest.ai
推論・デプロイ

vLLMがQwen3.8-2.4TのPDサービングを最適化した方法

vLLMは、GB300 NVL72上でQwen3.8-2.4TをPrefill-Decode分離方式で提供し、スループットから低遅延までの性能フロンティアを示しました。最終的な数値だけでなく、KVキャッシュと並列構成を調整する手順も説明しています。

続きを読む