8月15日、llm-d.aiが「Pull, Don't Recompute: Peer-to-Peer KV Cache Sharing in llm-d」と題した記事を公開した。この記事では、LLM推論クラスタにおいてKVキャッシュを再計算せずピア間で転送することで、スループットとTTFTを改善するP2Pキャッシュ共有の仕組みと実測結果について詳しく紹介されている。

問題の本質：ルーティングだけでは局所性を保てない

LLM推論でKVキャッシュの再利用が重要なのは周知の事実だ。プレフィックスが長いほど再計算のコストは大きく、48Kトークンのプレフィックスを再計算すれば2秒近くかかる。

llm-dはKubernetes上でLLM推論を分散実行するためのオープンソースフレームワークで、vLLM（高スループットなLLM推論エンジン）を内部で活用している。llm-dはすでに「プレフィックス対応ルーティング」によってキャッシュ済みエンドポイントへリクエストを誘導し、「KVオフローディング」でCPUメモリ層に保持する仕組みを持っている。しかしこれだけでは解決しない局面がある。

• キャッシュを持つエンドポイントが輻輳していてキューが詰まっている
• ロードバランシングが別のエンドポイントを選んだ
• Prefill/Decode分離（P/D disaggregation）でデコーダが生成したKV履歴をプレフィラーが必要とする

この場合、選択肢は「キャッシュ所有者のキューで待つ」か「別エンドポイントで再計算する」の二択になる。P2Pキャッシュ共有はここに第三の選択肢を追加する。最適なエンドポイントにルーティングしつつ、不足しているKVブロックをピア間で転送するというものだ。

アーキテクチャ：GPUを使わないCPU-to-CPU転送

P2Pでは各vLLMインスタンスが2つのロールを担う。

• Consumer：ローカルで計算する代わりに、ピアからKVブロックを取得する
• Producer：別ピアからリクエストされたとき、自分のCPUオフロード層からブロックを提供する

転送にはNVIDIAのNIXL（NVIDIA Inference Xfer Library）を使用する。ConsumerがProducerに必要なブロックのハッシュを送り、Producerが一致するブロックをCPUメモリ越しに書き込む。GPUはこのコピーに関与しない。ProducerはGPUコンピュートではなくCPUメモリ帯域とネットワーク帯域を消費するだけで、自分のコピーも維持したまま転送できる。

EPPが転送先と転送元を決定し、サイドカーがエンジンに伝達、NIXLがCPU間でブロックを移動する

ルーターのEPP（Endpoint Picker）がプレフィックスインデックスを参照し、最もキャッシュ済みトークンを多く持つピアとリクエストの実行先を比較する。転送コストの閾値（minCachedTokenDelta）を上回る差があれば、そのピアをKV転送元として指定する。同程度の候補が複数ある場合は待機キューの深さに反比例した重みで確率的にサンプリングし、転送が1つのProducerに集中しないよう分散させる。

転送 vs 再計算：どこが損益分岐点か

P2Pが有効なのはあくまで「転送コスト < 再計算コスト」の場合だ。この閾値はモデル、KV表現、ハードウェア、ネットワーク構成によって変わるため、実測が必要だと記事は強調している。

openai/gpt-oss-120b（OpenAIが公開した約120Bパラメータのオープンウェイトモデル、H200 GPU使用）では、最小計測値の2Kトークン時点ですでに転送が勝っていた。プレフィックスが長くなるほど差は拡大する。転送コストはプレフィックス長に線形だが、再計算はアテンションの二乗項が効いてくるためだ。

再計算はプレフィックス長に対して急激に増加するが、P2P転送は緩やかな線形増加にとどまる

一方、753BのGLMモデル（KVフットプリント約93KB/トークン）では様相が異なる。8Kトークン付近では転送と再計算がほぼ拮抗し、損益分岐点は約8,700トークンだった。24Kトークンでは転送が61%速く、24KプレフィックスのKVサイズは約2.1GiBに達する。損益分岐点はモデルサイズではなく、プレフィックスコストとKV転送コストの比率で決まるという点が重要だ。

このため、P2Pはデフォルト無効になっており、デプロイごとに閾値を設定するオプトイン方式を採用している。

実測：飽和状態のGLMクラスタで何が起きたか

753BのGLM-5.2-FP8を使った同時実行数64の負荷試験（300秒固定ウィンドウ内に完了したリクエスト数で評価）での比較が最も興味深い。

3回の繰り返し計測の平均では、成功スループット**+9.6%、入力トークンスループット+11.8%だった。また、精密ルーティング+P2Pではプレフィルキューのp90が12.8〜13.7リクエストから8.0〜9.0リクエストに削減**されており、キューの詰まりが解消されていることが確認できる。

P/D分離との組み合わせ

Prefill/Decode分離（P/D disaggregation）とは、プレフィル処理（入力トークンのKV計算）とデコード処理（トークン逐次生成）を別々のノードやGPUで担当させるアーキテクチャだ。この構成でも、P2Pキャッシュ共有は効果を発揮する。デコーダが生成した最新のKV履歴を、次のターンを担当するプレフィラーがP2P転送で取得することで、再計算なしにセッション履歴を引き継げる。アプリケーション側の変更は不要だ。

Llama-3.1-8Bを使ったクリーンなA/B比較では、8 req/sで中央値レイテンシが43%削減、飽和付近ではフリートの上限スループットが22%向上、ピークトークンスループットが32%向上した。

P2Pを使わない方が良いケース

記事は「万能の高速化ではない」と明示している。ルーティングがすでにローカルヒットを達成している場合、P2Pは正しく何もしない。基本原則は「ローカルヒット優先、局所性が崩れたときだけピア転送」だ。

短いプレフィックスでは転送コストが再計算を上回ることがあり、ファブリックの混雑やProducer側の負荷も考慮が必要だ。本番環境での閾値は測定された損益分岐点に十分なマージンを加えて設定することが推奨されている。

詳細はPull, Don't Recompute: Peer-to-Peer KV Cache Sharing in llm-dを参照していただきたい。