11月10日、Google Cloudが「The open AI-native stack on Kubernetes: From open models to distributed inference and agents」と題した記事を公開した。この記事では、Kubernetes上でオープンモデルのRL後学習・分散推論・AIエージェント実行を統合する、オープンソースのAIネイティブスタックの全体像について詳しく紹介されている。
「KV Cache命中率を35%→70%に倍増」が示す分散推論の本質
AIワークロードを本番環境へ移行する際、エンジニアが最初に直面するのがKV Cache（Key-Valueキャッシュ）の消滅問題だ。標準的なKubernetesのラウンドロビン・ロードバランシングは、マルチターンのエージェントリクエストを異なるPodに分散させてしまうため、前ターンで構築したKV Cacheが毎回破棄される。これはLLMのマルチターン推論において、コンテキストの再計算コストが累積し、レイテンシが跳ね上がる直接的な原因になる。
この問題に正面から取り組んだのが**llm-d 1.0（CNCF Sandbox）だ。Google Cloud、Red Hat、IBM Research、CoreWeave、NVIDIAが共同で立ち上げ、25以上の組織から500名超のエンジニア**が貢献するプロジェクトで、vLLMやSGLangなどの推論エンジンをクラスター全体の統合サービング基盤へと変える分散推論コントロールプレーンである。
中核機能はプレフィックスキャッシュ認識ルーティングだ。Endpoint Pickerと呼ばれるコンポーネントがKubernetes Gateway API Inference Extensionに統合され、各WorkerのリアルタイムKV Cache残存状況を評価してリクエストを最適なPodへ誘導する。本番環境での実績として、KV Cache命中率を35%から70%へ倍増、マルチターンエージェントワークロードにおけるTTFT（Time to First Token：最初のトークンが返るまでの時間）の中央値を70〜85%削減という数字が報告されている。これらはレイテンシの改善指標であり、元記事においてコスト半減を直接示す数字としては言及されていない点に留意されたい。
また、長文コンテキスト処理時のHBM（高帯域幅メモリ）逼迫に対しては、3段階KV Cacheオフロードで対処する。HBM → ホストCPU RAM → ローカルNVMe SSD / Google Cloud Managed Lustre / Cloud Storageという階層でキャッシュブロックを退避させ、高コストなコンテキスト再計算を回避する。
さらに、Prefill（プロンプトの事前処理）とDecode（トークン生成）を異なるハードウェアプールへ分離するEPD分離（Disaggregated Prefill/Decode）も実装されており、LeaderWorkerSet（LWS）上に構築されたDisaggregatedSetにより、ゼロダウンタイムのローリングアップグレードも可能だ。llm-dの分散推論アーキテクチャを起点に、次節以降では後学習・エージェント実行という残る二つの柱を見ていく。
RL後学習をKubernetesに統合する「OpenRL」
ドメイン特化モデルの性能を引き上げる手段として、SFT（教師あり微調整）だけでなくRL（強化学習）後学習が注目されている。しかし、RL後学習をKubernetes上で動かすには独特の難しさがある。GPUやTPUが学習フェーズとロールアウト生成フェーズの切り替え時に遊休状態になる問題だ。
これを解決するのが**OpenRL（CNCF Sandbox）**だ。研究者はforward_backward・optim_step・sample・save_stateという4つのPythonプリミティブで学習コードを記述するだけでよく、Kubernetesの内部実装を意識する必要がない。
特徴的なのは協調型アクセラレータタイムスライシングで、同一の物理アクセラレータ上で学習ステップとロールアウト推論を交互に実行する。これにより、学習専用・ロールアウト専用の独立クラスターを用意する必要がなくなる。また、最適化ステップごとに数GBのモデル重みをネットワーク転送するのではなく、差分重み（デルタウェイト）のみをロールアウトWorkerへ送信することでネットワーク帯域の飽和を防ぐ。
実際の評価として、Gemma 4を法律分野ベンチマークLegal Agent Benchmark（LAB）（M&Aデューデリジェンスから契約紛争分析まで24の法律実務領域をカバー）で検証した結果、SFTが多段階推論で約50%の精度で頭打ちになった一方、OpenRLを用いたRL後学習では精度を70%まで引き上げた。なお、元記事においてLABの開発主体や詳細な出典は明示されていないため、ベンチマーク内容については元記事の記述をそのまま参照されたい。OpenRLによって後学習基盤が整ったうえで、次に問題となるのが生成されたエージェントコードの安全な実行環境だ。
エージェント実行の安全分離：Agent SubstrateとgVisor
コードを生成してシェルコマンドを実行するような自律型AIエージェントを、マルチテナントのKubernetesクラスター上で動かすことはセキュリティリスクを伴う。サンドボックスエスケープや権限昇格が現実的な脅威となる。
Google Cloudが貢献する**gVisor（CNCF Sandbox）**はユーザースペースカーネルとしてシステムコールをインターセプト・仮想化し、信頼されていないエージェントコードがホストカーネルや隣接テナントに影響を与えないよう隔離する。サンドボックスはエージェントの各ターンごとにミリ秒単位で起動し、OpenRLのロールアウト生成と本番エージェントワークロードの両方に対応する。
Agent Substrate（CNCF Sandbox）はgVisorと組み合わせて使用されるオーケストレーションランタイムで、マルチターンのAIエージェントワークフローにおける実行ターゲットの提供を担う。元記事ではその詳細な内部アーキテクチャまでは踏み込んでいないが、gVisorによるサンドボックス隔離と組み合わせることで、エージェントの安全な実行環境を構成する位置づけとして紹介されている。
スタック全体像
記事では、組織の役割ごとの活用パターンも整理されている：
| 組織タイプ | 主課題 | スタックの使い方 |
|---|---|---|
| エンタープライズ プラットフォームチーム | 複数MLチームへの分断なき提供 | DRA・KueueでRLaaS（Reinforcement Learning-as-a-Service）を既存GKEクラスター上に構築 |
| 規制業種（金融・医療・法律） | IPや法規制によりデータを外部APIへ送れない | Gemma 1B〜30BモデルをプライベートVPC内で後学習・サービング |
| エージェント開発者 | 長文マルチターンのコスト・レイテンシ問題 | llm-dプレフィックスキャッシュルーティング＋gVisor隔離環境 |
| MaaSベンダー（複数テナントにGPU/TPUクラスターを提供するクラウド事業者） | 多様なハードウェアへのマルチテナント提供 | OpenRL・llm-dの混合GPU/TPUクラスター対応 |
分散Pythonと機械学習のオーケストレーションには、RayCluster・RayJob・RayServiceなどのカスタムリソースでRayクラスターを管理する**KubeRay（CNCF Sandbox）**が組み合わさる。Kueueとの統合によりマルチテナントでの公平なリソース共有が実現する。
詳細はThe open AI-native stack on Kubernetes: From open models to distributed inference and agentsを参照していただきたい。
