vLLMがエージェント向け推論基盤を最適化する方法

はじめに：推論サービスの前提が変わる

従来の推論サービスは、単発のリクエスト、一定範囲のコンテキスト、比較的長い生成を前提に最適化されることが多かった。エージェント型アプリケーションでは、モデルがツールを呼び出し、結果を読み取り、必要に応じてサブエージェントへ処理を分担しながら、同じセッションを何度も進める。各ターンでツール結果がコンテキストに追加されるため、入力は長くなり続ける一方、新しく生成される出力は短い。

この構造では、トークン生成を速くするだけでは不十分だ。すでに計算した長いプレフィックスを再利用し、そのKV状態をGPUや別のワーカー、ストレージ階層から効率よく取得しなければならない。vLLMはSemiAnalysisの公開ベンチマークAgentXを参考に、こうした負荷に対する全体的な最適化を説明している。

AgentXが示す負荷の特徴

• 長い多ターンセッション。 セッションのターン数は中央値43、入力は約142Kトークン、出力は444トークン。毎回コンテキスト全体を再送する一方、大部分は既計算の内容である。
• 高いプレフィックス再利用。 キャッシュヒット率は96％超に達する。再計算を減らせる反面、KVキャッシュを長く保持し、必要な計算場所へ移送する仕組みが重要になる。
• サブエージェントによる分岐。 セッションの44％に少なくとも一つのサブエージェントが含まれ、該当セッションではロールアウト数の中央値が4となる。親セッションからの分岐と結果の統合は、キャッシュ親和性とルーティングを難しくする。
• コストと応答性の両立。 コスト効率は固定されたハードウェアで動かせるエージェント数を左右し、遅延は次の推論やツール呼び出しまでの時間を左右する。総スループットだけでは、利用者が感じる待ち時間を捉えられない。

vLLMの三つの最適化層

データ層では、vLLMはPagedAttentionを基盤に、ハイブリッドKVキャッシュ管理を発展させている。現代のモデルは、フルアテンションに加えてスライディングウィンドウや線形アテンションを組み合わせることがあり、それぞれキャッシュの大きさや寿命が異なる。vLLMは統一されたページを割り当て単位とし、単一の共有ブロックプールを使うことで、静的な容量分割を避ける。並列度、コンテキスト長、再利用パターンに応じて容量を融通できる設計だ。

DeepSeek V4向けには、キャッシュを多数のテンソルやサイズ区分に分散させる方式から、ブロックごとの連続した領域へまとめるパック済みレイアウトも紹介されている。これによりパディング、ディスクリプタ、Prefill/Decode間の転送に伴う負荷を減らす。FP4インデクサーを有効にした場合、KVキャッシュのメモリ使用量を約10％削減できるという。

GPUだけでは容量が足りない場合、Mooncake Storeを分散共有KVキャッシュプールとして利用する。CPUメモリやディスクを含む階層構成に対応し、スタンドアロンストアモードでは外部クライアントがそれらの階層を管理する。Dynamoやllm-dなどのルーターとの統合により、リクエストが特定インスタンスに固定されなくてもキャッシュを利用しやすくする狙いがある。

実行層では、モデルに合わせた並列化、カーネル、非同期スケジューリング、投機的デコードを組み合わせる。ハイブリッドモデルではアテンション種別ごとの検索がCPU負荷を増やすため、データ構造の改善、非同期検索、スケジューラのクリティカルパス外への処理移動、送受信の並列化も行う。

制御層の焦点はPrefill/Decode分離だ。コンテキスト長、キャッシュヒット率、サブエージェントの挙動、同時実行数は変動するため、常に最適な固定比率は存在しない。ルーティングはキャッシュ局所性と負荷分散を両立させ、トラフィックに応じて比率を見直す必要がある。

影響と読み取り方

特定のAgentX構成で、vLLMはDeepSeek V4 ProにおいてGPU秒あたり最大13万の総トークン、MiniMax M3において毎秒最大376トークンのインタラクティビティを報告している。また、DeepSeek V4 Pro、MiniMax M3、Kimi K3では、Opus 5のAPI価格と比べて14.6倍から106倍のサービスコスト優位性を示した。これらは特定のモデル、ハードウェア、並列度、設定に基づくベンチマーク結果であり、すべての環境にそのまま適用できる保証ではない。

重要なのは、エージェント推論が単なるデコードエンジンではなく、コンテキストを扱う基盤になりつつある点だ。キャッシュの配置、ノード間転送、サブエージェント間の状態共有、Prefill/Decodeの配分は、カーネルの速度と同じようにセッション全体の時間とコストを左右する。運用側は今後、トークン毎秒だけでなく、長時間セッションの遅延、再利用率、転送コスト、同時実行時の挙動、総保有コストも評価する必要がある。

出典：vLLM Blog