Kubernetes 上で KV キャッシュ対応ルーティングと P/D 非同期化

K8s で実現する AI エージェントの高速化：KV キャッシュ最適化と P/D 非同期化の実践

従来の LLM 推論ベンチマークが示す「安定した状態」の数字には、AI エージェント特有の複雑な対話パターンは映し出されません。Red Hat の技術者が明らかにしたのは、多段対話や文脈の激しい変動に対応する新しいインフラアーキテクチャです。

本記事では、エージェントワークロードにおける KV キャッシュ管理の課題と、それを解決するための「KV キャッシュ対応ルーティング」および「プリフィル/デコード（P/D）非同期化」という 2 つの核心技術について解説します。これらを組み合わせることで、実環境において TTFD（初回トークンまでの時間）を 4 倍に短縮し、処理可能リクエスト数を 60% 増加させることに成功した事例を紹介します。

エージェントワークロードが壊す「従来の推論モデル」の前提

AI エージェントの普及は、推論インフラの設計思想そのものを転換させました。これまでの LLM 運用は、一定の負荷がかかる「定常状態（steady state）」を想定したバッチ処理が主流でした。しかし、実際のエージェントワークロードは全く異なります。

「エージェントは多段対話を行い、文脈が劇的に変動します。従来の平均値ベースの容量計画では対応できません。」

Red Hat の Yuchen 氏は、SweetBench や Cloud Code セッションなどの実データから、以下のような特徴を指摘しています。

• 多段対話の増加: 数ターンから 3,000 ターンを超える長い会話が行われることが一般的です。
• 文脈の激しい変動: ユーザーやクライアントが定義するプロンプト構造が多様で、入力と出力の比率が 100 倍以上になるケースさえあります。
• サブセッションの存在: 複雑なスケジューリングを必要とするパターンが見られます。

この「カオスな現実」に対応するには、単なるスループットの追求ではなく、「インタラクティブレイテンシ」と「キャッシュ効率」への最適化が不可欠です。特に重要なのが KV キャッシュ（Key-Value Cache）の管理です。

KV キャッシュ対応ルーティング：システムプロンプトを最大化する

エージェントワークロードでは、ユーザーはシステムプロンプトやタスク定義を頻繁に再利用します。これにより、キャッシュヒット率が 90% を超えることが珍しくありません。しかし、文脈がクライアント依存であるため、KV キャッシュの管理は極めて不安定になり、頻繁な書き換えや削除（eviction）が発生します。

これを解決するのが、LLMD（LLM Dispatcher）に実装された「エンドポイントピッカープラグイン」です。

このコンポーネントは、各ポッドの状態をリアルタイムでプローブし、以下の基準に基づいてリクエストを最適なポッドへルーティングします。

1. KV キャッシュの局所性: 同じシステムプロンプトを持つキャッシュが既に存在するポッドを選定。
2. 負荷状況: 実行中および待機中のリクエスト数、プリフィックスキャッシュの利用可能度。
3. スケーラビリティ: 最も負荷が低く、キャッシュヒットの可能性が高いノードへ優先的に割り当て。

「エンドポイントピッカーは、システムプロンプトの再利用性を最大化し、最適なポッドへリクエストを誘導します。」

実証デモの結果：

このルーティング戦略により、パフォーマンスに劇的な変化が生まれます。最初のリクエストでは KV キャッシュが構築されるため 3 秒かかりますが、2 番目のリクエストで同じシステムプロンプトを使用すれば、キャッシュが再利用され処理時間は約 1 秒に短縮されます。逆に、システムプロンプトが変われば新しいポッドへルーティングされ、再び 3 秒かかるものの、ユーザー側のプロンプトだけを変えてシステムプロンプトを維持すれば、またもや 1 秒で応答可能です。

この仕組みにより、TTFD（Time to First Token）の改善だけでなく、スループット全体が向上します。経済的な観点からも、キャッシュトークンと非キャッシュトークンのコスト差は最大 10 倍に達するため、キャッシュ活用はビジネスの成否を分けます。

P/D 非同期化：物理的に分離して相互干渉を防ぐ

KV キャッシュの最適化に加え、推論エンジンのアーキテクチャ自体を見直す必要があります。それが「プリフィル/デコード（P/D）非同期化」です。

従来の集約型（aggregated）サーバーでは、1 つのポッドが「初期プロンプト処理（プリフィル）」と「トークン生成（デコード）」の両方を受け持ちます。しかし、これら 2 つのフェーズには物理的な特性の違いがあり、同じ GPU で実行すると相互干渉を引き起こします。

• プリフィル: 計算集約型。高い FLOPS を必要とし、バッチ処理で大量の KV キャッシュを構築する。突発的な負荷に弱い。
• デコード: メモリ帯域集約型。1 トークンずつ生成するため、レイテンシが敏感でキャッシュの定着性が求められる。

「プリフィルとデコードを同じ GPU で実行すると、長時間のプロンプト処理が突如として発生した際、進行中のトークン生成を完全に停止させます。」

LLMD はこの問題を解決するために、2 つのフェーズを物理的に分離し、独立してスケーリングするアーキテクチャを採用しています。

1. プリフィル専用ポッド: 計算リソースを最大化し、高速に KV キャッシュを構築します。
2. デコード専用ポッド: メモリ帯域とキャッシュの定着性を最適化し、安定したトークン生成を行います。
3. ネットワーク転送: プリフィルで生成された KV キャッシュは、メタデータと共に高速なネットワークファブリックを経由してデコードポッドへ転送されます。

これにより、プリフィルのバースト負荷がデコードのレイテンシに影響を与える「フェーズ干渉」を排除できます。Red Hat の内部テストでは、P/D 非同期化を採用した環境での P99 インタートークンレイテンシ（ITL）は、従来の集約型に比べて約 9 倍改善し、900 ミリ秒から 100 ミリ秒へ短縮されました。

H200 クラスターで実証：TTFD 4 倍、リクエスト数 60% 増

これらの技術を統合した実証実験が、H200 クラスター上で GLM-5.2 モデルを用いて行われました。P/D 非同期化と並列戦略を組み合わせることで、以下のような成果が得られています。

• TTFD の向上: 4 倍の短縮を実現し、ユーザー体験を劇的に改善。
• 処理可能リクエスト数の増加: 60% の増強が可能に。

これは、Kubernetes 上で分散推論を柔軟に制御する標準的なパターンとして確立されつつあることを示しています。Red Hat は、LLMD を中心としたこのアーキテクチャにより、エージェントワークロードの複雑な対話パターンやコスト効率への要求に応える、現実的な解決策を提供しています。

まとめ

AI エージェント時代における推論インフラは、単なる「高速化」から「文脈変動への適応」と「キャッシュ活用の最適化」へとその役割を変えています。KV キャッシュ対応ルーティングと P/D 非同期化という 2 つの柱を K8s で実現することで、安定性とコスト効率を両立する大規模エージェント運用が可能になります。

「エージェントワークロードへの適応は、もはやオプションではありません。インフラ設計の根幹を変えるべき課題です。」

ベンチマークの数値に惑わされず、実環境の複雑さを理解した上でアーキテクチャを見直すことが、次世代 AI サービス成功の鍵となるでしょう。