メインコンテンツにスキップ

Agent Substrateとは？待機時間の長いAIエージェントを少数のPodで大規模に動かすKubernetesの新しい仕組み

AIインフラ
Agent Substrateは、待機中のAIエージェントの状態（メモリとファイル）をスナップショットとして退避して実行環境を解放し、呼び出されたら空いている実行環境に復元することで、少数のPodで多数のエージェントを動かす仕組み…
作者

obelos

公開

2026年11月12日

更新日

2026年11月12日

結論：Agent Substrateは、待機中のAIエージェントの状態（メモリとファイル）をスナップショットとして退避して実行環境を解放し、呼び出されたら空いている実行環境に復元することで、少数のPodで多数のエージェントを動かす仕組みです。

ポイントは次の3つです。

  1. 問題：エージェントは大半の時間を待機に使うのに、従来は1エージェントに1つのPodを割り当て、計算資源を確保したままにしていた
  2. 解決：待機中のエージェントをメモリとファイルシステムごと退避してワーカーを解放し、再び呼ばれたら空いているワーカーに復元する
  3. 効果：NVIDIAは、標準的なコンテナと比べて10倍の密度で実行できるとしている

Googleが始めたオープンソースで、CNCF Sandboxに採択されています。NVIDIAは2026年11月10日、自社の推論基盤との連携を発表しました。

前提1：AIエージェントは大半の時間を待機に使う

AIエージェントの処理を時間軸で見ると、実際に計算している時間はわずかです。

  • 人の入力を待つ
  • LLMの応答を待つ
  • ツールの実行結果を待つ

コーディング支援のエージェントであれば、「LLMで考える→リポジトリを編集する→テストを実行する→再びLLMで考える」を繰り返し、そのたびに待機が発生します。

前提2：Podの起動とコールドスタート

KubernetesでPodを1つ起動するには、次の処理を順に通ります。

  1. APIサーバーがリクエストを受け付ける
  2. アドミッション（受付時の検証）を行う
  3. etcdに記録する
  4. スケジューラが配置先のノードを決める
  5. ノード上のkubeletがコンテナを起動する
  6. コンテナイメージを取得する
  7. ネットワークを設定する

この処理に数秒かかります。これを コールドスタート と呼びます。NVIDIAによれば、エージェントのサンドボックスには、10ミリ秒のコマンドを毎秒数百回実行する使い方があり、そのたびに数秒のコールドスタートを挟むことはできません。

従来の2つの方式とその問題

方式 問題
1エージェントに1つのPodを常駐させる 待機中もメモリを確保したままになる
使わないときはPodを削除する 再開のたびに数秒のコールドスタートが発生し、エージェントの状態も失われる

強化学習の事後学習（RL post-training）でも同じ問題があります。学習用の環境の準備が遅いと、学習を行うGPUが待機状態になります。

Agent Substrateの仕組み

Agent Substrateは、多数のエージェントのセッションを、少数の起動済みワーカーPodに多重化して実行する、サンドボックス型の実行環境です。セキュリティを強化したゼロトラストの設計になっています。

構成要素

構成要素 役割
アクター エージェントとその実行環境をまとめた単位
ワーカーPod アクターを実行する通常のKubernetesのPod
サンドボックス アクター同士を隔離する。gVisorまたはmicroVMを使う
制御プレーン 多数のアクターを少数のワーカーに割り当てる
ルーター すべてのワーカーが使用中のとき、リクエストを待機させる

処理の流れ

  1. アクターは、ワーカー上のサンドボックスで実行される
  2. アクターが待機状態になると、メモリとファイルシステムの状態をスナップショットとして退避し、ワーカーを解放する
  3. アクターが再び呼び出されると、その時点で空いているワーカーに状態を復元する
  4. 復元は、APIサーバー、スケジューラ、kubeletを経由せず、起動済みのワーカーに状態を戻すだけで行う
  5. すべてのワーカーが使用中の場合、ルーターがリクエストを待機させる。待機時間とキューの長さには上限がある

重要なのは4です。アクターの再開時に、前述の数秒かかるPodの起動処理を通らないため、高速に再開できます。

一方で、ワーカーPod自体は通常のPodなので、Kubernetesのスケジューリング、リソースクォータ、配置ポリシーはそのまま適用されます。Kubernetesの外に独自の仕組みを作るのではなく、Kubernetesの上に層を追加する設計です。

NVIDIA Dynamoとの連携

NVIDIAの推論基盤 Dynamo は、次のような推論の状況をAgent Substrateに通知します。

  • 最初のトークンが返るまでの予測時間
  • GPUプールの使用率

Agent Substrateはこの情報を使い、アクターの扱いを次のように決めます。

推論の状況 アクターの扱い
応答がすぐ返る見込み ワーカー上に残しておく
応答まで時間がかかる見込み 退避してワーカーを解放する
応答が返る直前 応答の完了前に復元しておく

GPUを含む計算資源の割り当ては、NVIDIAのスケジューラ KAI Scheduler が担当し、ワーカーPodを学習サーバーや推論サーバーと並べて配置します。

想定される用途

NVIDIAは次の3つを挙げています。

  1. コーディング支援エージェント：LLMの呼び出しとリポジトリの操作を交互に行い、ターンをまたいで環境を保持する必要がある
  2. 強化学習の事後学習：CPU負荷の高い環境を一度に大量に動かす。1回の学習で、数百のサンドボックスから数十万規模まで増えることがある
  3. 研究用のGPUサンドボックス：CUDAのコンパイルやカーネルの性能測定など、短時間で隔離されたGPU環境が必要な作業

NVIDIAによる貢献

NVIDIAは、Agent Substrateのリポジトリに次のような貢献をしています。

  • ルーターでのリクエスト待機の実装と、動作中のアクター宛てのリクエストがキューで滞留しないための改善
  • microVMサンドボックスでの、コンテナごとのCPU・メモリ上限の設定
  • KubernetesのDRA（Dynamic Resource Allocation）によるデバイスの差し替え対応。最初の対象はNVIDIA GPUで、作業中
  • GPUの状態を保存・復元するための、ベンダーに依存しない設計の提案。保存時のデバイスの特性を記録し、一致するデバイスに復元するか、一致しなければ通常の起動に切り替える

制約と注意点

  • APIはまだ変更される可能性があり、GPU対応はDRAを基盤に作り直している最中です
  • Dynamoとのエージェント連携の一部は実験的な機能です
  • 「10倍の密度」はNVIDIAの説明であり、実際の負荷で同じ結果になるかは検証が必要です

まとめ

  • AIエージェントは大半の時間を待機に使うため、1エージェントに1つのPodを常駐させると資源の無駄が大きい
  • Agent Substrateは、待機中のアクターを状態ごと退避し、呼び出されたら空いているワーカーに復元することで、少数のPodで多数のエージェントを実行する
  • 再開時にPodの起動処理を通らないため高速で、ワーカーは通常のPodなので既存の運用ルールも適用される
  • NVIDIAはDynamoやKAI Schedulerと連携させ、推論の待ち時間に応じて退避するかどうかを決める方向で開発を進めている

あわせて読みたい

参考

次に読む