数百のAIエージェントを数台のサーバーでコスト増なく走らせる方法

通常、Kubernetesでの作業は予測可能です：1つのサービス — 1つのPod（あるいはReplicaSet）。しかし、AIエージェントの世界に入ると、このおなじみのパターンは崩れます。数多くのエージェントがそれぞれメモリ内にダイアログコンテキスト、環境変数、ファイルシステム状態を保持している状況を想像してみてください。大多数のエージェントは何もしません — ユーザーコマンドやイベントを待っているだけです。各エージェントにK8sで完全なPodを割り当てるのはコストがかかります：コントロールプレーンはオブジェクトの数で処理が詰まり、クラスタリソースが浪費されてしまいます。

Googleのチーム（ただしプロジェクトは非公式とされています）がAgent Substrateを導入しました。これは、数多くのアクティブなエージェントセッションをほんの数個の物理Podで「ジャグリング」できるシステムです。

標準アプローチの問題点

Kubernetesでは、Podの作成はインスタントではありません。etcdでの状態更新、スケジューラの待機、イメージのプル、コンテナの起動が必要です。インタラクティブなエージェントにとって、数秒の遅延はすでに長すぎます。さらに、エージェントが「スリープ」状態のとき、そのリソースを解放したいですが、起きた時にはファイルとメモリ内のすべての変数を即座にリストアする必要があります。

Agent Substrateは、アクターとワーカーの概念でこの問題を解決します。アクターはあなたのアプリケーション（エージェント）であり、ワーカーは長命のPodシェルです。システムは、多数のアクターを少数のワーカープールにマッピングします。

プロジェクトの主な機能

インスタントセッションテレポーテーション

魔法のように聞こえますが、実際にはgVisorに基づいて動作しています。エージェントが非アクティブなとき、Substrateはその状態（メモリを含む）のスナップショットを取得して保存します。リクエストが来るとすぐに、システムは空いているワーカーを探し、スナップショットをそこで「展開」します。アクティブ化は1秒未満で完了します。

ハックなしの状態で維持

エージェントの各動作のために外部データベースを苦労して設定したり、遅いネットワークドライブをマウントしたりする必要はありません。RAMの内容やローカルファイルを含む状態全体が完璧に維持されます。エージェントがターミナルでコードを書いていたり、メモリ内にデータ配列を保持していた場合、ハイバネーション後も正確に中断したところから続きます。

驚異的な多重化

デモビデオでは、作者たちが250個のステートフルアクターがたった8個のPodに収まる様子を示しています。これによりリソース節約が数十倍になります。AIエージェンシーや開発サービス（Claude Codeなど）のプラットフォームを構築している人にとって、クラウド請求書を削減する直接的な道筋です。

内部的动作

このプロジェクトはGoで書かれており、Kubernetesエコシステムと緊密に統合されていますが、アクター管理をK8sコントロールプレーンのクリティカルパスから切り離しています。

主なコンポーネントは次のとおりです：

• ateapi：システムの中核で、アクターのライフサイクルを管理します。
• atelet：ノード上のデーモンで、スナップショットと状態転送をオーケストレーションします。
• atenet：トラフィックルーティングを処理し、 нужныйワーカー（必要なアクターが現在「起きている」場所）にリクエストを届けます。
• gVisor (runsc)：分離を提供し、プロセスのチェックポイントを実現します。

ちなみに、このプロジェクトは完全にフレームワークに依存しません。LangChain、Claude Code、カスタムのPythonスクリプトのどれを使用しても問題ありません — OCIコンテナとしてパッケージ化されていれば、Substrateはそれを実行します。

クイックスタート

Go、Docker、kubectlがインストールされていれば、kindを通じてローカルでシステムを試すことができます。開発者は、数分でクラスタとデモ環境を立ち上げるスクリプトを用意しています。

# Создаем локальный кластер
hack/create-kind-cluster.sh

# Ставим систему и демо-приложение
hack/install-ate-kind.sh --deploy-ate-system
hack/install-ate-kind.sh --deploy-demo-counter

# Устанавливаем плагин для kubectl
go install ./cmd/kubectl-ate

# Создаем пространство и первого актора
kubectl ate create atespace demo
kubectl ate create actor my-counter-1 -a demo --template ate-demo-counter/counter

その後、標準的なcurlでアクターを呼び出すことができます。システムは、起床させる必要があるかどうか、そしてリクエストをどこへルーティングするかを自動的に判断します。

今試す価値はあるか

このプロジェクトは「非常に初期の開発」段階にあります。これはAPIが必ず変更され、後方互換性が保証されていないことを意味します。本番環境にはまだ早すぎますが、R&D部門やLLMサービスのインフラを設計している人にとって、研究必須のプロジェクトです。

コード実行用の数千の分離されたサンドボックスや、コンテキストを記憶する必要があるAIアシスタントの群れを実行する必要がある場合、Agent SubstrateはネイティブKubernetesを無限にスケールしようとするよりもはるかにエレガントな道を提供します。

ビデオでは、システムがリアルタイムでアクターをジャグリングしている様子が示されています。

プロジェクトチームはCNCF Slack（チャンネル#substrate-usersと#substrate-dev）で積極的にコミュニケーションを取っており、週次ミーティングを行っています。このプロジェクトの裏には、仮想化とコンテナ化に関する真剣な専門知識があることが明らかです。少なくとも、K8sの能力を特定のワークロード向けに拡張する方法の素晴らしい例です。