TL;DR
Evolving Infraは、エージェントの多様で変動する負荷に合わせ、P/D（prefill/decode）の計算割当とKVキャッシュ管理を分離して実行時に適応するLLM配信フレームワークです。ノードを再起動せずP/Dを切り替え、共有ホストメモリKVプールとアクティブ分岐を考慮した退避・転送でKV再利用を保ちます。論文ではDynamo比で平均E2Eレイテンシ最大4.1倍低減、P95 TTFT最大14倍低減などを報告しています。評価は特定のエージェント作業・モデル・GPU環境に限られます。
既存手法との違い
比較対象はDynamo（NVIDIAの本番フレームワーク）、Arrow（コード非公開のため著者らが再実装）、SGLang Model Gatewayのcache-aware/sticky、Dynamo KV router、メモリプール追加版、最良の静的P/D分割です。条件はClaude Code traces（90同時エージェント、1時間）、コード・数学・コンピュータ操作、GLM-5.2/Kimi K2.6、GB300 GPUです。既存手法はP/D切替に再起動やKV損失、粗い信号による需要推定、LRU中心のKV退避といった制約があります。Evolving Infraは計算割当とKV管理を分離し、オンラインプランナとエージェント対応KVマネージャで適応する点が異なります。論文報告ではDynamo比で平均E2Eレイテンシ最大4.1倍低減、P95 TTFT最大14倍低減、定常負荷で最大2.7倍スループット、最良静的比最大38%増、変動構成でDynamo比2.1倍・最良静的比28%増です。
使える条件
対象は、エージェントがステップ実行し、連続リクエストが長いプレフィックスを共有するLLM推論です。ハーネスによるfork、sub-agent、compactionで文脈が変わる状況を想定します。実装前提として、各ノードがprefill/decode両方を実行でき、共有ホストメモリKVプールとクラスタ横断KVディレクトリを用意できることが必要です。評価はGLM-5.2/Kimi K2.6、GB300 GPU（Abstractは最大256台、評価節は36台と記載）、Claude Code/Putnam/OSWorld系の作業です。RAGや非エージェントの一般ワークロードへの適用可否は提示本文からは確認できません。
限界と未検証の範囲
評価は論文内の特定エージェント作業・モデル・GPU構成に限定され、汎用のRAGやチャット配信での効果は未検証です。Arrow比較は再実装です。オンライン学習の誤推定時の挙動、KVディレクトリの障害・整合性、マルチテナント分離、セキュリティ、運用コストは提示本文から確認できません。Abstractの最大256 GPUと評価節の36 GPUの記載差があり、スケールに関する一般化には注意が必要です。長期的な本番運用や他ハーネスへの一般化も未検証です。
解説
ねえ智也くん、エージェント向けのLLM配信を速くする論文を見つけたんだけど、P/D割当とKV管理を分離するってどういうこと？
まず前提。エージェントは何ステップもLLMを呼ぶ。連続するリクエストは長いプレフィックスを共有するから、KVキャッシュを再利用できる。でも既存のPD分離は計算割当とKV管理が結びついてて、負荷が変わっても柔軟に動かせない。
P/Dはprefillとdecodeだよね。ノードの役割を変えるのが重いって話？
そう。論文は、Dynamoは切替でワーカーを再起動するから平均681秒かかると報告してる。Arrowは再起動なしでもKVを活かせず、34回の切替で使えるKV再利用の55.5%を失う、とも書いてある。
それはもったいない。Evolving Infraはどう変えたの？
各ノードをprefillにもdecodeにも使えるようにして、フェーズとKV置き場を切り離す。KVは全ノードのホストメモリで共有プールを作って、クラスタ全体のディレクトリでどのコピーを何個のアクティブな分岐が参照してるか数える。切替してもKVは読める。
アクティブな分岐って、forkとかsub-agentで増えるやつ？
そう。ハーネスがfork、sub-agent、compactionをすると、どのKVがまだ使われるか変わる。だからLRUだけじゃなくて、アクティブな分岐が参照してない履歴や終わったsub-agent、転送で残った重複コピーを先に捨てる。ルータはリモートKVを待ち行列中に非同期で取って、TTFTが短いノードへ回す。
計算側は？
オンラインでprefillとdecodeのiteration-timeモデルを学ぶ。prefillモデルはKV再利用も入れる。平均作業量で各計画窓を見て、切替のスループット利得が窓全体で続く時だけ切り替える。短いバーストで頻繁に切り替えないため。
評価は何と比べてるの？
Dynamo、Arrowの再実装、SGLang Model Gatewayのcache-aware/sticky、Dynamo KV router、あとメモリプール追加版、最良の静的P/D分割。Claude Code tracesで90同時エージェント、コード・数学・コンピュータ操作、GLM-5.2とKimi K2.6、GB300 GPUって条件。
数字は？
論文報告ではDynamo比で平均E2Eレイテンシ最大4.1倍低減、P95 TTFT最大14倍低減。定常負荷でDynamoの最大2.7倍スループット、最良静的より最大38%増。変動する構成でDynamoの2.1倍、最良静的より28%増。
すごい。でも万能ではないよね？
評価は特定のエージェント作業、モデル、GPU構成に限られる。一般のRAGやチャット配信は未検証。Arrow比較は再実装。KVディレクトリの障害や整合性、マルチテナント分離、運用コストは本文から確認できない。あとAbstractは最大256 GB300、評価節は36 GB300と書いてあって、スケールの一般化は注意。
なるほど。じゃあ私の部屋の散らかったKVキャッシュもアクティブな分岐だけ残して整理したいな。
君の場合は全部アクティブな分岐だから。まず参照カウントじゃなくて片付けろ。