vLLM、エージェント型ワークロード向け最適化技術「AgentX」を公開

TL;DR: エージェントワークロードは vLLM のトラフィックの主要な源泉となりつつあります。多段階セッション、長いコンテキスト、そして広範なプレフィックス再利用を要するこれらの特性に対応するため、サービングスタック全体での最適化が求められています。本稿では、vLLM が KV キャッシュ管理、並列処理とエンジン最適化、prefill/decode の非同期化手法を通じて取り組む包括的なアプローチを紹介していきます。

SemiAnalysis が公開しているエージェントベンチマーク「AgentX」https://newsletter.semianalysis.com/p/agentx-inferencexv3-does-cuda-moat による測定では、DeepSeek V4 Pro では GPU セットあたり最大 130K トークン、MiniMax M3 ではインタラクション速度として最大 376 トークン/秒を達成しています。DeepSeek V4 Pro、MiniMax M3、Kimi K3 のいずれにおいても、vLLM は Opus 5 API の価格と比較して 14.6 倍から 106 倍のコスト優位性を実現しています（詳細は パフォーマンス を参照）。

Figure 1: SemiAnalysis AgentX における vLLM のパフォーマンス。DeepSeek V4 Pro、MiniMax M3、Kimi K3 の各モデルで最も設定された vLLM 構成の TCO 1 ドルあたりのトークン数と P90 インタラクティブ性を比較したグラフです。ケーススタディとして GB300 NVL72 上の DeepSeek V4 Pro を採用しています。データソース：SemiAnalysis AgentX。

エージェントワークロードの再評価

5 月に エージェントワークロードのサービング に関する最初の投稿を公開して以来、エージェント関連のトラフィックシェアは増え続けています。2026 年 6 月時点では、OpenAI が報告したところによると、エンタープライズ顧客において Codex が生成するトークン数は、Codex と ChatGPT を合わせた出力の 64% に達しています。

この増加するトークン消費量は、サービングインフラストラクチャに対して「コスト」と「レイテンシ」の 2 つの軸で負荷を強いています。コスト効率性は、固定されたハードウェア予算内で同時に稼働できるエージェントの数を決める要因であり、レイテンシは各エージェントが推論やツール使用のサイクルをどの程度速く進められるかを左右します。したがって、エージェントサービングを最適化するとは、全体としての「レイテンシとコストのフロンティア」を改善することを意味します。

このフロンティアを実際の代表的なトラフィック下で評価するため、SemiAnalysis は最近、実際のエージェントコーディングのトレースから構築されたパブリックベンチマーク AgentX を公開しました。このトレースは、サービングシステムが対応しなければならないワークロードの特徴を具体的に示すものです：

• 長時間実行される多ターンセッション。1 セッションあたりの中央値は 43 ターンです。

「長いコンテキストに対して短い出力を生成する」ケースが典型的です。入力の中央値は 142K トークン、出力の中央値は 444 トークンです。

「プレフィックスの再利用が非常に多い」のも特徴で、プレフィックスキャッシュのヒット率は 96% を超えます。

「サブエージェントを多用するトラフィック」も目立ちます。セッションの 44% で少なくとも 1 つのサブエージェントが使用され、その中で使われるサブエージェントのロールアウト数の中央値は 4 です。

これらの統計は、アジェンティック・セッションがどのように構築されるかによって説明がつきます。各ターンでは直近のツール結果を累積コンテキストに追加し、全体をモデルへ送り返します。そのため入力は成長し続け、各ターンで追加される新しいプレフィルは短く、リクエストのほとんどはエンジンが既に見たことのあるプレフィックスです。サブエージェントはこの文脈からフォークするか、あるいはゼロから開始され、その結果は最終回答の前に親セッションに統合されます。Figure 2 はそのようなセッションを 1 つ通して解説しています：スライダーを使って最初のターンから最終回答までステップを進めると、各リクエストでどれだけの部分が再利用されるプレフィックスで、どれだけの部分が新しいプレフィルなのかを確認できます。

アジェンティック・ワークロードのサービングにおける課題

これらのワークロード特性は、効率的なサービングにおいて 3 つの課題を生み出します。

• プレフィックスキャッシュへの負荷。マルチターンセッションの各ターンでは、これまでの会話全体が再実行されます。多くのセッションを同時に稼働させるためには、エンジンがターン間で KV キャッシュをオフロードする必要があります。これはスケーリングが進むほど難しくなり、GPU 間や prefill/decode を分離したインスタンス、レプリカにわたって KV キャッシュ管理、プレフィックスキャッシング、オフロードが効率的に連携することが求められます。

実行効率の向上

エージェントワークロードは長いコンテキストと厳しいレイテンシ要件を特徴とするため、エンジンではより多くのトークンを処理し、単位トークンあたりの作業量を短時間でこなす必要があります。これには、並列化、カーネル、スケジューリング、スペキュレティブデコーディング、およびその他のエンジン最適化を、新しいリクエストの形状に合わせて適応させることが求められます。

適切な P/D 比の発見

セッションやサブエージェント間ではコンテキスト長やキャッシュヒット率が大きく変動するため、ルーティングは各ランク間でキャッシュアフィニティと負荷を効率的にバランスさせる必要があります。これらの要因により、スループット最適化された P/D 比を見つけることは難しく、かつ並行度の変化に応じてその値も変動します。

vLLM のアプローチ：スタック全体での最適化

図 3 は 3 つのプレーンを要約したものです。このセクションの後半では、データプレーンから順に各プレーンを詳しく見ていきます。

データプレーン：KV キャッシュをウォームかつ計算リソース近くに保つ

進化し続けるハイブリッド KV キャッシュ管理

KV キャッシュ管理は、PagedAttention の導入以来 vLLM の中核をなしてきました。しかし、長いコンテキストを扱うエージェントワークロードでは、キャッシュ容量への負荷がさらに高まります。最近のハイブリッドモデルは、スライディングウィンドウ型と線形アテンション、そしてフルアテンションを組み合わせているため、割り当ての複雑さが一段増しています。これらのアテンションタイプによって、キャッシュされるブロックのサイズや寿命が大きく異なるからです。

vLLM のハイブリッド KV キャッシュマネージャーは、この複雑さを「単純な基本理念」で解決します。それは、すべてのアテンションタイプに共通する単一のメモリアロケーション単位としてページサイズを採用し、1 つの共有ブロックプール（図 4）を通じて管理するという考え方です。

共有プールを設けることで、vLLM はアテンションの種類ごとに容量を静的に分割するのではなく、必要に応じて動的にメモリを再割り当てできるようになります。これは非常に重要です。なぜなら、フルアテンションの KV キャッシュはシーケンス長とともに成長する一方、スライディングウィンドウやリカレント状態は異なる寿命とスケールルールに従うからです。最適なパーティショニングは、同時実行数、コンテキストの長さ、プレフィックス再利用のパターンによって常に変化します。

新しいアーキテクチャが台頭するにつれ、従来の抽象化の限界であるフラグメンテーション（断片化）や転送効率の低さが浮き彫りになってきています。例えば、DeepSeek V4 の初期 KV キャッシュレイアウトでは、キャッシュタイプを 3 つのサイズバケットに分割し、92 個もの別々のテンソルを割り当てていました。図 5 に示す通り、この方式はパディングによるメモリ浪費を招き、P/D（Pipeline/Device）転送や KV キャッシュのオフローディングにおいても非効率です。

これに対し、新しい packed KV cache layout では、ブロックごとに 92 個に断片化されたものではなく、すべてのキャッシュグループとレイヤーを 1 つの連続したバックアロケーション内に格納します。これにより記述子のオーバーヘッドや P/D 転送のコストが削減され、FP4 インデクサーを有効にした際にはより小さな割り当て単位が可能になるため、KV キャッシュメモリのおよそ 10% を節約 できます。

階層的 KV キャッシュオフローディング：分散 KV キャッシュプールとスマートな保持ポリシー

GPU メモリ容量の限界やエンジン間を超えてプリフィックスキャッシュを維持するため、vLLM は Mooncake Store を統合し、分散 KV キャッシュプールとして機能させています。この設計の詳細は以前のブログ記事で解説しています。採用は着実に拡大しており、エージェントワークロードにおける容量、効率性、保持戦略のさらなる改善に向けた新機能やパフォーマンス向上を継続して提供し続けています。

モデルアーキテクチャの互換性

vLLM において、KV キャッシュのオフローディングは依然として主要な機能の一つです。スパースアテンション、圧縮アテンション、線形アテンションなど、新しいモデルアーキテクチャへの完全なサポートを提供しています。これを実現しながらも、非同期スケジューリング、P/D 分離（disaggregation）、スペキュレーティブデコーディング、並列処理といった他のエンジン機能の動作とパフォーマンスは維持されています。

階層型 KV キャッシュオフローディング

vLLM は、分散された KV キャッシュプールに階層型ティアをサポートしており、ディスクや CPU のみで構成されるノードを追加することでキャパシティをさらに拡張できます。これは vLLM の Mooncake Store を standalone-store モードで使用することで実現されます。このモードでは、外部の Mooncake クライアントが CPU プールとディスクティアを管理し、vLLM ワーカーは純粋なリクエスト送信側として機能します。各ノードにスタンドアロンの Mooncake クライアントを起動させることで、CPU メモリとディスクを用いて KV キャッシュプールを自由に拡張できます。

また、Dynamo や llm-d などのルーターとの分散共有 KV キャッシュプールの統合も完了しており、どのインスタンスでもキャッシュヒットが可能になるため、ルーティングポリシーの簡素化に貢献しています。

パフォーマンス最適化

ハイブリッドモデルでは、各アテンションタイプごとにキーの構築と参照を別々に行う必要があるため、CPU のオーバーヘッドが倍増してしまいます。このコスト削減のため、より効率的なデータ構造の採用、非同期による参照処理、スケジューラのクリティカルパスからの作業の移管、そして並列的な送受信操作の実装を行いました。実装の詳細は以下の PR で確認できます。

PR#46188, PR#45444, PR#45659, PR#47317。

セッション認識型プレフィックスキャッシュの保持戦略

線形層やスライディングウィンドウ層とフルアテンション層を併用するハイブリッドモデルでは、プレフィックスの再利用時に、その境界点で線形の内部状態またはスライディングウィンドウキャッシュを維持する必要があります。トークンごとにこれらのスナップショットを保持するのはコストが高いため、2 つの補完的なポリシーを組み合わせています。

• 間隔ベースの保持：このポリシーは、各ターン（対話ラウンド）の末尾にあるキャッシュや線形状態を自動的に保持します。これにより、後のターンやフォークされたサブエージェントが、以前のコンテキストを再生して拡張する際にも、キャッシュされたコンテキストを再利用できるようになります。

しかし、共有されるプレフィックスは通常、1 つのターン内で終わってしまうため、間隔ベースの保持だけではチェックポイントが維持されない場合があります。このケースでの再利用を捉えるために、私たちは第 2 のポリシーを導入しました：

「Marconi スタイルの選択的保持」[1] は、特定のプレフィックスが再度観測された際にチェックポイントを保持する機能です。リクエストが以前に観測されたプレフィックスに遭遇した際、既に保持されているチェックポイントが存在しない場合、vLLM は欠落している状態を再計算し、その境界点で新しいチェックポイントを保存します。その後、同じプレフィックスを共有する他のリクエストは、このチェックポイントを再利用できるようになります。

これらのポリシーを組み合わせることで、大規模なエージェントワークロードにおいても、過度なストレージオーバーヘッドを抑えつつ高いキャッシュヒット率を維持できます。技術的な詳細については、vLLM Kimi K3 のブログ記事で詳しく解説しています。

実行層：高速なトークン生成

モデル固有の並列処理

現代の推論システムでは、テンソル並列（TP）、データ並列（DP）、エキスパート並列（EP）、パイプライン並列（PP）、コンテキスト並列（CP）など、複数の並列化軸が利用可能です。

しかし、最適な並列化戦略は、モデルアーキテクチャやハードウェアトポロジ、ワークロードのパターン、そしてレイテンシの SLO によって異なります。本節では、NVIDIA の GB シリーズおよび B シリーズ GPU とその AMD 製競合機上での代表的な 2 つのモデルを例に、私たちが行った最適化と得られた知見について解説します。

Kimi K3

Kimi K3 は、マルチヘッド潜在アテンション（MLA）と Kimi Delta Attention（KDA）を採用しています。MLA では KV 情報が単一の潜在空間に 1 つのヘッドで圧縮されるため、その潜在キャッシュをランク間で複製する従来のテンソル並列（TP）は、効率的ではありません。

[1]: https://github.com/vllm-project/vllm/pull/47782

TP の代替手段として、デコード・コンテキスト・パラレリズム (DCP) を用いることで、顕著なパフォーマンス向上を確認しました。DCP はシーケンス次元に沿ってキャッシュを分割し、各ランクが KV 状態の 1/N を保持する仕組みです。

具体的には、エージェントワークロードにおいて DCP は以下の 2 つのメリットをもたらします（図 6）：

• デコードレイテンシの低減: MLA アテンションはメモリーバウンドであり、そのコストはコンテキスト長とともに増大します。エージェントのプレフィックスが成長するにつれ、アテンションは各デコードステップにおける割合を占めるようになり、これをランク間で分割することでステップ時間を短縮できます。

• スループットと KV キャパシティの向上: KV キャッシュの複製を回避できるため、エンジンが KV 受付待ちで停止することなく、より多くのシーケンスを並行処理可能となり、結果として高いスループットを実現します。

DCP のトレードオフは追加の通信コストです。KV キャッシュがシーケンス単位で分割されるため、MLA デコード層ではアテンション前にクエリの集約（gather）と、その後に部分出力の還元（reduction）が必要となります。

DCP の計算パスを慎重に最適化し、NCCL 操作を迂回してこれらのオーバーヘッドを回避しました。対称メモリバッファを使用しており、相互接続された GPU が直接読み書きできます。クエリはアテンションカーネルが消費するバッファへ直接マルチキャストされます。各 GPU は、部分的なアテンション出力と log-sum-exp (LSE) 統計量を、相手の GPU の受信スロットに直接書き込みます。その後、各ランクでオンラインソフトマックスを用いて結果をローカル統合します。

これらの GPU 間への書き込みは計算と融合され、同じカーネル内に組み込まれます（図 7）。これにより、デフォルトの DCP8 実装と比較して、1 レイヤーあたり約 13% のレイテンシ短縮を実現しました。

図 7: 対称メモリを使用した DCP4 下の MLA デコードパス。各ステップが単一のカーネルに融合され、NCCL all-gather、ステージングコピー、all-to-all、アンパックの各ステップを置き換えています。

ドメインの規模が大きくなると、最適な戦略も変化します。例えば NVL72 クラスのシステムでは、データ並列性を併用した広域 EP（DEP）の方が DCP よりもスケーラビリティに優れ、同じデコードレイテンシ SLO を維持しながらより高いスループットを実現できます（図 8）。大規模なマルチノード構成における DCP では、シャード化されたアテンションの通信コストが、計算リソースを節約する効果を上回ってしまいます。DEP はリクエストとその KV キャッシュを異なるデータ並列ランクに割り当てるため、DCP で必要なアテンション集合演算を回避しつつ、MoE のエキスパートもランク間でシャード化できます。

DeepSeek V4

DeepSeek V4 もまた、TP（テンソル並列）下で複製される MLA スタイルの KV キャッシュを採用しており、メモリ使用効率が低下しています。さらに、圧縮スパースアテンションは以下の 3 つの理由から、TP のヘッドシャード化を計算非効率にします。

• コンプレッサパスでは、圧縮された位置ごとに共有された 1 つの KV 表現しか生成されず、ヘッドごとの独立した状態は作成されません。その結果、TP では KV ヘッド次元に沿った計算のシャード化ができず、すべてのランクでコンプレッサ処理が重複して実行されます。

• インデクサは 64 のヘッドを持ちますが、トークンごとに生成されるのはグローバルな top-k 選択のみです。現在の TP パスでは、dense なスコア削減をスキップして top-k を選ぶ代わりに、インデクサの全処理が各ランクで複製されてしまいます。

スパース MLA（Sparse MLA）では、トップ k の KV キャッシュエントリをスキャンして集める処理が支配的であり、アテンション演算自体は二次的なものです。TP（Tensor Parallelism）では、このメモリ帯域に依存する作業の多くが各ランクで繰り返される一方、比較的軽量なヘッドごとの計算のみが分割されます。

実用上、長いプリフィル処理にはプリフィル文脈並列化（PCP: Prefill Context Parallelism）が最も効果的ですが、データ並列化とエキスパート並列化（DEP: Data and Expert Parallelism）はより幅広いサービング条件で良好に機能します。

PCP はプロンプトシーケンス（クエリテンソル）をシャードし、圧縮器とインデクサの処理を各ランクに分散させることで、スパース MLA に対してより広く効率的なヘッドローカル形状を実現します。32K のプロンプトにおいて、PCP8 は TP8 と比較してプリフィル速度で 2.65 倍の向上を示し、TTFT（Time To First Token）を大幅に削減しました。ただし、デコード側の状態は各ランク間で複製されるため、PCP は専用プリフィルワーカーへの採用が最適です。

DCP（Decode Context Parallelism）は、DeepSeek V4 においては Kimi K3 と比べて効果が低いです。これは V4 のより複雑なモデルアーキテクチャに起因します（詳細は デコード文脈並列化の限界 を参照）。

一方、DEP はリクエストとデコード済みトークンをデータ並列ランク間で分散し、アテンションパスを完全にローカルに保ちます。この特性により、DEP が DeepSeek V4 のほとんどの構成におけるデフォルト選択となっています。

2 レベルでの混合エージェントトラフィックのスケジューリング

エージェント型サービスでは、頻繁に追加されるリクエスト（長いプレフィックスを再利用し、短いプリフィルのみで済むもの）と、稀に発生する数万トークン規模の新しい長文プリフィルが混在します。これにより、2 つのスケジューリング上の課題が生じます。

1. インスタンス内では、長いプリフィルが短い対話ターンをブロックしてしまうこと。
2. DEP ランク間では、プリフィルの配置が偏り、負荷の不均衡を引き起こすことです。

これらに対し、2 つの補完的なスケジューリング制御で対応します。

先頭ブロックの解消

デフォルトでは、vLLM のチャンク化プリフィルスケジューラは FIFO（先着順）で動作します。長いプリフィルがステップごとにトークン予算をすべて占有してしまい、同じランクにキューイングされている短いターンは、その長いプリフィルが完了するまで全くスケジューリングされません。これを「先頭ブロック（head-of-line blocking）」と呼びます。

Figure 9 は、あるランクのキューにおけるセッションビューでこの現象を示しています。

この課題に対して、シンプルなスケジューリングポリシーで対応します。具体的には --long-prefill-token-threshold パラメータを用いて、1 つのリクエストがステップごとにスケジュールできるトークン数の上限を設けます。

512 トークンの閾値を設定すると、長いプリフィル処理があっても短いターンがバッチに割り込まれ、より早くデコードを開始できるようになります。DeepSeek V4 Pro を B300s で実行した場合、この設定により GPU 秒あたりの総トークン数（TPGS）は最大で 93% 向上し、P90 の応答性も約 2.3 倍改善されます。ただし、長いリクエスト自体の TTFT は増加するため、TTFT に敏感なデプロイメントではより大きな閾値を使用する必要があります。

DEP プリフィルスケジューリングのタイミングを合わせる

DEP では、もう一つの非効率性が生じます。MoE のアールツーオール通信により、すべてのランクが同期して進行するため、1 つのランクでプリフィル処理が遅れると、グループ全体が影響を受けます。異なるランクで異なるステップにプリフィルが到着すると、このペナルティが繰り返されてしまいます。

この不均衡を緩和するために、--prefill-schedule-interval を設定し、N 番目のエンジンステップごとにのみプリフィル処理を受け付けるようにします。これにより、データ並列化されたランク間でカウントが同期され、プリフィル処理がすべてのランクで同じステップに集中します。その結果、残りのステップの多くをデコード専用に割り当てることが可能になります。図 10 は、DEP8 グループにおけるこのタイミングの例を示しています。

図 10: DEP8 グループ全体における Prefill スケジュールのタイミング。左側：Prefill が異なるステップで到着し、同期グループを繰り返し停止させる様子。右側：間隔を 4 に設定すると、Prefill はタイミングの合うステップに集約され、その間のステップは Decode のみとなる。

最適な P/D 分離構成によるスケーリング

単一のエンジンだけを最適化しても、分散環境におけるレイテンシとコストの最佳点を導き出すことはできません。また、GPU を増やしたり分離構成を導入しただけで自動的に性能が向上するわけでもありません。Prefill と Decode の両ステージをレートマッチングさせることが不可欠です。

アジェンシーワークフローによって自動化可能な、標準的な 2 フェーズのレートマッチング手法を採用しています。

フェーズ 1：サチュレーションプロファイリング

Prefill のみ、Decode のみのデプロイメントをそれぞれ別々にベンチマークします。並列化戦略（TP と広域 EP など）と導入規模（8、16、32 GPU）を変えながら、スループットが飽和するまで並行処理数を増やしていきます。その結果として得られるのは、各（並列化、サイズ）構成ごとの最大 Prefill/Decode 要求数（req/s）を記録したサチュレーションテーブルです。

フェーズ 2：P/D スイープ

各設定のフェーズ 1 の飽和点から P/D 比を導出し、統合された非同期デプロイメントで並行度をスイープして、動作範囲全体にわたるメトリクスを収集します。

ループを閉じる：モデル固有カーネルとコミュニティによる貢献

エージェントワークロードでは、カーネルのボトルネックが長文コンテキストアテンション、推測デコーディング、および通信へとシフトします。ここでは、エンドツーエンドのパフォーマンスに明確な影響を与えるいくつかの変更点を紹介します。当社のすべてのカーネルは完全オープンソースであり、一部はすでに他のオープンソースエンジンでも採用されています。

MiniMax M3 の場合、CuteDSL による長文コンテキストインデクサー が導入され、形状に応じて GB300 インデクサのレイテンシが約 3% から 31% 改善しました。マージされた MSA top-k パスは最悪ケースのカーネルパフォーマンスを最大 4 倍向上させ、AgentX のエンドツーエンドスループットは約 7% 向上します。また、推測検証パスは、報告されたテストにおいて中規模バッチのデコード性能を約 20% 改善しました。

Kimi K3 では、GEMM と reduce-scatter の融合 がシーケンス並列通信を強化し、latent-tail MoE の融合 によりエンドツーエンドのレイテンシが約 5% 短縮されました。

DeepSeek V4 においては、コミュニティからの貢献により MXFP4 MoE および HCA の圧縮技術が改善され（#43584 および #44230）、マルチストリームの C4A が追加され（#42925）、クラスタベースの top-k 処理も強化されました。

パフォーマンス：エージェントファーストで、かつ検証可能

vLLM が「エージェントファースト」であることは、SemiAnalysis AgentX による独立した検証によって示されています。これは、実世界のエージェントによるコーディングの痕跡 100 万件（コンテキスト長 100 万トークン）から構築されたオープンなデータセットで、1,000 チップ以上と約 2MW の計算リソースを備えたパブリックベンチマークインフラ上で実行されています。

図11はKimi K3のダッシュボードを示す一例です。ベンチマークおよびそのすべての結果は、AgentX Dashboard で公開されています。他のモデルや設定におけるパレート最適の結果もぜひご確認いただくことをお勧めします。

本稿では、DeepSeek V4 Pro、MiniMax M3、Kimi K3 の 3 つのオープンフロンティアモデルの結果に焦点を当てます。各モデルについて、ユーザーあたり P90 応答性が 50 トークン/秒以上（一般的なかつ厳しいレイテンシ SLO）を維持する vLLM 設定の中でスループットが最大となる構成を報告しています。以下の表に主要な結果をまとめました。

1 GPU セconds あたりの総トークン数 (TPGS) は、入力トークン、出力トークン、およびキャッシュされたトークンをすべて含みます。詳細な内訳は各モデルのリンクから確認できます。

DeepSeek V4 Pro は、高スループットかつコスト効率に優れたケースを代表するモデルです。12 基の GB300 を P/D (プロセッサ/デコーダ) 構成で展開することで、256 の並行エージェントセッションを処理しながら、P90 レベルでユーザーあたり 58.3 トークン/秒を維持します。この運用ポイントでは、GPU セconds あたり 83K の総トークンを処理可能です。

MiniMax M3 は、対話性をさらに高めたモデルです。B300 をわずか 2 基使用するだけで、P90 レベルでユーザーあたり 74.2 トークン/秒を維持し、GPU セconds あたり 70K の総トークンを処理します。

Kimi K3 は、最大規模のオープンフロンティアモデルの一つであり、最先端知能の可能性を示すものです。パラメータ数は 2.8 兆に達しますが、従来の単一サーバー構成では対応が困難です。それでも GB300 を 16 基展開することで、P90 レベルでユーザーあたり 62.7 トークン/秒を維持し、GPU セconds あたり 11.8K の総トークンを処理できます。

性能だけでなく、コストはユーザーの日常利用やトークノミクスにおいて最も重要な指標です。以下の表では、3 つのオープンモデルと Opus 5 のサービングコストを比較します。

Opus 5 の計算では、キャッシュされた入力 × 0.50 ドル/M + キャッシュされていない入力 × 5 ドル/M + 出力 × 25 ドル/M という式が用いられています。これは完璧な理論的なキャッシュヒット率を前提としており、キャッシュ書き込み料金や長文コンテキストに対する価格プレミアムは除外されています。この計算は保守的かつ Opus に有利な設定です。ここで比較しているのはモデルの品質ではなく、サービングコストです。

このコスト優位性は、エージェント型トラフィックが持つ本質的な性質から生まれます。理論的なキャッシュヒット率が 96% を超える場合、vLLM はプレフィックスを効果的に再利用し、上記の表と同じ設定下で、3 つのモデルすべてにおいてその再利用をサービング効率へと変換します。

DeepSeek V4 Pro の場合、GB300 インフラストラクチャにおける TCO（総所有コスト）は、測定されたワークロードを処理するのに約 1 時間あたり 28 ドルです。一方、Opus 5 で同じトークン量を処理する場合、理論的に再利用可能なすべてのトークンにキャッシュ読み取り価格を適用しても、費用は約 2,926 ドルになります。B300 上で稼働する MiniMax M3 は 85 倍のコスト優位性を示し、GB300 上の Kimi K3 もモデルサイズが大幅に大きいにもかかわらず、14.6 倍の安価さを維持しています。

これらは今日の時点での数値です。ダッシュボードは稼働しており、誰でもアクセス可能です。AgentX ハーネスは SemiAnalysisAI/agentx-harness で公開されており、上記のすべての結果には、再現を容易にするため InferenceX ダッシュボード上の対応する実行リンクが添付されています。

苦い教訓：失敗した点と得た学び

失敗したアイデアは、探索範囲を狭めるものです。我々は、直感的に妥当と思えたアプローチが、エンドツーエンドの測定では機能しなかったケースをいくつか観察しました。これらの機能については現在も改善を進めていますが、これまでの教訓をお伝えします。

パイプライン並列化 (PP) は、ウォームなエージェント処理には不向きです

チャンク化パイプライン並列化 (CPP) を含むパイプライン並列化 (PP) は、長く新鮮なプロンプトに対しては高いパフォーマンスを発揮します。大規模なプリフィル処理により、パイプラインの各ステージに十分な負荷をかけられ、通信コストを抑えつつスループットをほぼ線形にスケールさせることが可能です。

しかし、多くのエージェント処理ターンでは、システムプロンプトや過去の対話履歴がキャッシュ済みであり、新しいリクエストで追加されるトークンは数百から数千程度にとどまります。パイプラインを効率的に埋めるだけの新鮮な計算量が不足しており、パイプラインのバブル（アイドル状態）が発生して、本来得られるはずの性能向上の多くを失ってしまいます。

ここで重要なのは、PP 自体が無効だということではありません。冷たい（キャッシュされていない）、計算集約型のプリフィル処理においては有効です。しかし、エージェントセッションで支配的となる「ウォーム」な、プレフィックス依存度の高いターンに対しては、デフォルトの選択肢として採用すべきではありません。

デコードコンテキスト並列化 (DCP) は、DeepSeek V4 にはそのまま適用できません

DCP は、DeepSeek R1 や Kimi K2.5、K2.7 といった純粋な MLA モデルや、Kimi K3 のようなハイブリッド MLA モデルにおいてすでに示した通り良好に機能します。しかし、より複雑なアテンションスタックを持つ DeepSeek V4 では、同様の恩恵を実現するのははるかに困難です。

圧縮スパースアテンションと高度に圧縮されたアテンションには、インデクサー、追加のコンプレッサー、そしてメインのアテンション演算が含まれています。これらすべてのサブレイヤーを分割して調整する必要があるため、文脈並列化（Context Parallelism）では大幅な通信コストと実装の複雑さが生じます。

私たちは計算との通信オーバーラップに注力し、対応するカーネルの最適化にも多大な投資を行いました。それでもなお、DCP は DEP に匹敵する程度にとどまり、それを上回ることはできませんでした。この結果は、実行平面セクションで示されたより広範な点を裏付けるものです。つまり、並列化戦略はモデルアーキテクチャに合わせる必要があります。ある潜在アテンションモデルで成功した手法が、別のモデルでも通用するとは限りません。

負荷分散が必ずしも性能向上につながるわけではない

集約された DEP デプロイメントでは、ランク間で KV キャッシュの使用量に大きな偏りがあることが確認されました。自然な対応策として、キュー深度や実行中のトークン数、現在の KV 利用率に基づいてリクエストをバランスさせる方針が検討されます。

しかし、AgentX での実験では、これらのポリシーはいずれも単純なセッション認識型スタティックルーティングよりも性能が劣りました。その理由はキャッシュの局所性にあります。多くのエージェントセッションはターン間の遅延が短いため、次のリクエストが到来する時点で、そのプレフィックスはまだ前の GPU に残存していることが多いのです。セッションを負荷の少ないランクへ移動させると、システムは KV キャッシュを取得する必要が生じます。ただし、分散された KV キャッシュプール内ではプレフィックス自体は保持されています。転送は非同期で行われ計算と重なりますが、無料ではありません。プリフェッチされたブロックが一時的に GPU の KV キャパシティを占有するため、宛先ランクが受け入れ可能なシーケンス数が減少します。その結果、システム全体で処理できる同時リクエスト数は減りますが、キューのバランスはより良くなります。

ターン間遅延が短いワークロードにおいては、瞬時の負荷を完全にバランスさせることよりも、セッションの局所性を維持する方が価値が高いのです。ルーティング決定では、キューされた作業量だけでなく、各ワーカーに既に残存している状態も考慮する必要があります。

今後の道筋：計画されている最適化と将来の研究

次のステップは、エージェント構造をサービングスタック全体で明示的に扱うことです。以下に各レイヤーの具体例を示します。

制御平面では、最初のターン（1 回目）のリクエストと、2 回目以降のリクエストを明確に分離してルーティングできます。1 回目はプレフィックスキャッシュを埋めるために長い新規プリフィルが必要になる傾向があり、2 回目以降はキャッシュの再利用率が高く、比較的短い追加プリフィルで済みます。この分離により、ヘッド・オブ・ライン（先頭）ブロックを防ぎつつ、PCP や CPP などを用いて両側でエンジン設定や並列処理を最適化し、それぞれの効率を最大化することが可能になります。

実行平面とデータ平面では、コミュニティと共に以下の機能の実装を進めています。

• エージェントのヒント: エージェントフレームワークやハルネスは、セッション構造、分岐の可能性のある地点、キャッシュ位置、ツール呼び出しの遅延、セッションライフサイクルといった情報をリクエストに付随させることができます。まずは標準化された API を通じてこれらのヒントを取り込み、次にスケジューリングやキャッシュの退去ポリシー、その他の最適化をエンジンが実行する際のガイドとして活用します。

• プログラム可能な KV キャッシュ: 異なるワークロードには、配置・保持・複製・退去のポリシーがそれぞれ異なります。プログラム可能なインターフェースを提供することで、ユーザーは自身のワークロードパターンに合わせて、KV キャッシュのプリフェッチや退去、ソフトピンニングを制御できるようになります。

• セッションベースの KV キャッシュ管理: ターン間のギャップは、保持中の KV 状態を次のターンを担当する可能性が高いワーカーへ移動させる機会となります。このアイドル期間中にプリフェッチを行うことで転送遅延を隠蔽し、コールドな再開回数を減らすことが可能です。

謝辞

本取り組みは、Inferact が主導し、vLLM コミュニティの広範な支援を受けて進められました。オープンソースベンチマーク「AgentX」の開発・運営および、その手法と結果の再現性を可能にした SemiAnalysis への感謝を申し上げます。また、本研究を通じて密接に協力し、多大なるサポートを提供いただいた NVIDIA および AMD にも厚く御礼申し上げます。