分散推論スタックllm-d、1.0を公開　Kubernetes上でAIエージェントの大量同時実行を運用する

llm-dはvLLMやSGLangといった推論エンジンを置き換えるものではなく、その上位に当たる運用層です。ルーティング、キャッシュ再利用、負荷分散、可用性管理を担い、既存のエンジンとモデル、クラスタを保ったまま必要な構成要素だけを導入できます。prefix-awareなルーティング、KVキャッシュのオフロード、prefillとdecodeの分離、広いexpert parallelismはこれまでにも提供されていました。1.0の新規性は、これらを本番運用の要件として統合した点にあります。

1.0の主な追加は4系統です。マルチテナントのQoS（品質保証）では、優先度と公平性を考慮したフロー制御で、遅延に敏感な対話リクエストとまとまった負荷が来るエージェント処理が同じクラスタを奪い合わないようにします。無停止運用では、ルーターのホットスタンバイ付き高可用性とローリングアップデートに加え、prefillとdecodeのレプリカ群を一つの論理ユニットとして扱うDisaggregatedSetを導入しました。基盤の安定化では、ルーター設定APIをv1に移行し、Responses APIがprevious_response_idを扱えます。エージェント対応では、セッションをキャッシュのあるレプリカに留めるセッション親和性と、ターン単位の優先制御を加えています。このほかGoogle Cloudは、強化学習の学習で遊んでいる時間に非同期推論を割り込ませるTPU・GPUの時間分割も紹介しました。

公表された数値は、いずれも特定の構成での測定値です。GoogleはIronwood TPU（TPU 7x）上のエージェント的コーディング評価で、prefix-awareルーティングとホストメモリ退避の組み合わせが、単純なKubernetes Service比で中央値TTFT（最初のトークンまでの時間）を85%超短縮し、総スループットを2.4倍にしたと発表しました。IBM ResearchがRed Hatの発表で紹介したデモは、約7,530億パラメータのオープンウェイトモデルGLM 5.2をNVIDIA GPUに展開したもので、最大3,000の並列コーディングエージェントを処理してピーク時毎分660万超の出力トークンを記録し、優先排除ゼロでした。この構成での1トークンあたり費用は、現在のクラウド賃料をもとにした試算で商用API価格の5分の1から10分の1になると説明されています。これは自己ホスト構成と商用API価格の比較であり、llm-dを導入すれば費用が下がるという一般的な保証ではありません。

Googleの実運用の例では、同社のGeminiプラットフォームがこの系統のスタックでprefixキャッシュのヒット率を35%から70%に上げ、コーディングエージェントのTTFTを35%超、バースト時のP95 TTFTを50%超減らしたと報じています。17,000ノード規模のマルチリージョン構成の公開ベンチマークでは、3クラスタでスループット2.9倍、成功率99.9%、ルーティングのオーバーヘッド1%未満とされています。

v1.0.0は「すべての機能が完成」を意味しません。リリースノートは、目標を追跡したIssue #2619の全項目を達成したわけではないと明記しています。独自ビルドの推論イメージは段階的に非推奨化され、AMD ROCm向けのllm-d-rocmイメージのビルドは廃止予定です。版の付け方も、このリリースを機に組織内のコンポーネントで揃えられました。

焦点は、第三者によるベンチマークの再現、非推奨イメージからの移行、v1.1以降の安定性です。エージェントの大量同時実行を自己ホストする企業にとって、キャッシュのヒット率や優先制御が推論費用とレイテンシに効く点は本番運用の論点になりますが、導入判断には自社のトラフィック構成での測定が要ります。