Moonshot AIのKimiチームとkvcache-aiは、エージェント環境を大規模に実行するために設計された分散プラットフォームAgentENV（AENV）をオープンソース化した。AgentENVは、Moonshotの2.8兆パラメータのMixture-of-ExpertsモデルであるKimi K3のエージェント型強化学習（RL）トレーニングに使用されている。このプロジェクトはMITライセンスで公開されている。

エージェント型RLにおいて環境インフラがボトルネックになる理由

エージェント型RLでは、モデルからテキストをサンプリングするだけでは不十分だ。モデルが実際のコンピュータ環境内で行動する必要がある。各ロールアウトには、ファイルシステム、ネットワークスタック、実行中のプロセスを備えた分離済みLinux環境が必要になる。この種のトレーニングループでは、環境そのものがデータ生成経路の一部となるため、リセット速度、分離性、タスク状態を再現または分岐できる能力が、収集可能な有用なロールアウト数に直接影響する。

この要件は、インフラ面で難しいトレードオフを生む。コンテナは高速に起動できるが、ホストカーネルを共有するため、モデルが生成したコードを実行する際の分離性が弱くなる。完全な仮想マシンはより強い分離性を提供する一方、起動が遅く、アイドル時にもメモリを保持し続ける。

AgentENVは、このギャップに対応するよう設計されている。Firecracker microVMを実行し、アイドル状態、再起動、分岐を、トレーニング規模のワークロードを支えられるほど低コストにすることを目指している。

AgentENVのFirecrackerベースのアーキテクチャ内部

各AgentENVサンドボックスは、独自のLinuxカーネル、ファイルシステム、ネットワーク名前空間を持つFirecracker microVMとして実行される。リクエストはAxum HTTP APIを通じて受け付けられ、サンドボックスのライフサイクル管理を担うオーケストレーターへ転送される。

ストレージは設計の中核を成す。ルートファイルシステムは、overlaybdのレイヤードイメージをバックエンドとするublkユーザー空間ブロックデバイスを通じて提供される。読み取り専用のベースレイヤーはサンドボックス間で共有され、各サンドボックスはそれぞれ独自の上位レイヤーに書き込む。

各ゲスト環境内では、envdと呼ばれるデーモンがポート49983でコマンド実行、ファイル操作、ヘルスレポートを管理する。リバースプロキシは、クライアントから仮想マシン内で実行されるサービスへのHTTPおよびWebSocketトラフィックをルーティングする。

このプロジェクトは、密度を高めるための2つの仕組みも説明している。ホストのページキャッシュは、ストレージデータとメモリスナップショットデータの間で共有される。メモリバルーニングは、再利用可能なゲストメモリをホストに返却し、環境が時間とともに分岐していく中でもオーバーコミットの維持を支援する。

スナップショット、pause、resume、fork

スナップショット、pause、resume、forkは、AgentENVを支える中核機能だ。このシステムは毎回完全なイメージを書き出すのではなく、メモリとファイルシステムの変更をインクリメンタルにスナップショット化する。

報告されている性能指標によると、スナップショットを利用する環境は50 ms未満で起動またはresumeし、100 ms未満でpauseする。インクリメンタルなスナップショット取得は、ディスク変更が多い状況でも100 ms未満で完了するとされている。

forkは、RLワークロードに特に固有の機能だ。実行中のサンドボックスは、同一ノード上で最大16個の独立した子サンドボックスへ自身を複製できる。ソース環境は取得中に短時間pauseし、その後resumeする。各子環境は、ソースのファイルシステム、メモリ、リソース構成を継承する。

実務上の効果として、コストの高いセットアップを一度だけ実行できる。チームは依存関係をインストールし、リポジトリをクローンし、特定のタスク状態に到達したうえで、その正確な状態を並列ロールアウトへ分岐できる。これは、繰り返しの試行を同じ準備済み状態から開始しつつ、異なる行動軌跡を探索する必要があるエージェントタスクにとって重要だ。スナップショットは、S3互換オブジェクトストレージまたは共有分散ファイルシステムに永続化できる。

注目すべきデフォルト動作がある。すべてのサンドボックスにはTTLがあり、期限切れになると削除ではなくpauseが実行される。削除するには、create APIでautoPause: falseを渡す必要がある。

オンデマンド読み込みとスナップショットリポジトリ

イメージはoverlaybdを通じてオンデマンドで読み込まれる。ローカルディスクは容量制限付きキャッシュとして機能し、ホットデータを保持し、コールドデータを退避する。

この設計により、フリート規模での運用が可能になる。各ノードはすべてのイメージを事前ウォームアップしたり、すべてのスナップショットの完全なコピーを保存したりする必要がない。したがって、アドレス可能なイメージセットはローカルディスク容量を超えることができ、同時にクラスタ全体で高速な起動を維持できる。

スナップショット状態は3つのレイヤーに整理される。builder staging workspaceはビルド中の成果物を保持する。committed snapshot repositoryは永続的な信頼できる情報源として機能する。node-local runtime cacheは、起動時に導出される構成を保存する。

サポートされるリポジトリバックエンドは2つある。デフォルトのposix_fsとossだ。ossパスは共有のS3互換クライアントを使用するため、明示的なリージョン指定が必要になる。

AgentENVには、irohをベースとした任意のピアツーピア転送機能も含まれており、コミット済み成果物をピアノードに通知できる。これはデフォルトでは無効になっている。ドキュメントは、P2Pがコミット済みスナップショットモデルを変更しないことを明示している。共有ストレージについて、ドキュメントは少なくとも1 Gbpsを求め、10 Gbps以上を強く推奨している。

採用経路としてのE2B互換性

AgentENVはE2B互換のHTTP APIを公開している。E2B_API_URLをAgentENVサーバーに向けることで、ユーザーは公式のE2B PythonまたはTypeScript SDKをコード変更なしで実行できる。

この互換性は、意図的な配布上の選択だ。すでにE2B上でエージェントを実行しているチームは、エージェントコードを書き換えることなくランタイムをセルフホストできる。AgentENVはネイティブのaenv CLIも提供しており、ドキュメントではAgentENV固有のワークフローにこれを推奨している。

デプロイの選択肢

AgentENVにはLinux kernel 6.8+と/dev/kvmへのアクセスが必要で、インストールスクリプトにはさらにUbuntu 24.04が必要となる。aenv CLIはx86_64およびarm64上のLinuxとmacOSをサポートする。サーバーはKVMを必要とするため、Linux専用だ。

ドキュメントでは5つのデプロイ経路が説明されている。

• サーバーをsystemdサービスとして実行するインストールスクリプト
• ghcr.io/kvcache-ai/aenv-serverで公開されているDockerイメージ
• マルチノードクラスタをシミュレートするDocker Composeスタック
• gateway、scheduler、node DaemonSetを含むKubernetesマニフェスト
• Rustツールチェーンを使用してソースからビルドする経路

マルチノードデプロイでは、:8080上のgatewayと:9090上のschedulerが追加される。マルチノード制御プレーンはプロトタイプとして文書化されており、クラスタ化されたスケジューリングの成熟度と共有ストレージに関する運用要件は、大規模デプロイを評価するチームにとって重要な詳細となる。

AgentENVは各エージェント環境をコンテナではなくFirecracker microVMとして実行し、カーネルレベルの分離を提供する。このプロジェクトは、スナップショットベースの起動またはresumeが50 ms未満、pauseが100 ms未満であると報告している。実行中のサンドボックスは同一ノード上で最大16個の独立した子環境へforkでき、E2B互換HTTP APIにより既存のE2B PythonおよびTypeScript SDKコードを変更なしで実行できる。