Kimi AIとkvcache-aiがAgentENVをオープンソース化：Kimi K3のエージェント強化学習（RL）トレーニングを支える分散システム

Moonshot AIのKimiチームとkvcache-aiは、エージェント環境を大規模に実行するための分散プラットフォームであるAgentENV（AENV）をオープンソース化しました。AgentENVは、Moonshotの2.8兆パラメータの混合専門家（MoE）モデルであるKimi K3のエージェント強化学習（RL）トレーニングを支えます。コードはMITライセンスの下で公開されています。

環境インフラがエージェントRLを妨げる理由

エージェントRLは単なるテキストサンプリングではありません。モデルが実際のコンピュータ環境内で動作する必要があります。各ロールアウトには、ファイルシステム、ネットワークスタック、ライブプロセスを備えた分離されたLinux環境が必要です。この要件は厳しいトレードオフを生みます。コンテナは起動が速いですがホストカーネルを共有するため、モデル生成コードに対する分離が弱くなります。完全な仮想マシンは適切に分離されますが、起動が遅く、アイドル時にメモリを保持します。AgentENVはまさにそのギャップをターゲットにしており、FirecrackerマイクロVMを使用して、アイドル、再起動、ブランチをトレーニングスケールで実行できるほど安価にします。

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

各サンドボックスは、独自のLinuxカーネル、ファイルシステム、ネットワーク名前空間を持つFirecrackerマイクロVMです。リクエストはAxum HTTP APIに到達し、サンドボックスのライフサイクルを管理するオーケストレーターに転送されます。ストレージの設計は興味深いものです。ルートファイルシステムは、overlaybdレイヤーイメージによってバックアップされたublkユーザースペースブロックデバイスを介して提供されます。読み取り専用のベースレイヤーはサンドボックス間で共有され、各サンドボックスは独自のアッパーレイヤーに書き込みます。各ゲスト内部では、envdと呼ばれるデーモンがコマンド実行、ファイル操作、ヘルスレポートをポート49983で処理します。リバースプロキシは、クライアントからのHTTPおよびWebSocketトラフィックをVM内で実行されているサービスにルーティングします。プロジェクトはまた、2つの密度メカニズムをリストしています。ホストページキャッシュはストレージとメモリスナップショットデータ間で共有されます。メモリバルーニングは、回収可能なゲストメモリをホストに返し、環境が時間とともに分散するにつれてオーバーコミットを維持します。

スナップショット、一時停止、再開、フォーク

これら4つの機能がプロジェクトの存在理由です。AgentENVはメモリとファイルシステムの変更をインクリメンタルにスナップショットし、毎回完全なイメージを書き込むことはありません。報告された数値は以下の通りです。スナップショットベースの環境は50ミリ秒未満で起動または再開し、100ミリ秒未満で一時停止します。高いディスク変更下でも、インクリメンタルスナップショットのキャプチャは100ミリ秒未満で完了します。フォークはRLに最も特化した機能です。実行中のサンドボックスは、同一ノード上で最大16個の独立した子サンドボックスにクローンできます。ソースはキャプチャ中に一時的に一時停止し、その後再開します。各子サンドボックスは、ソースのファイルシステム、メモリ、リソース設定を継承します。実際の効果は、高価なセットアップが一度だけ実行されることです。チームは依存関係をインストールし、リポジトリをクローンし、タスク状態に到達できます。その正確な状態が並行ロールアウトに分岐します。スナップショットはS3互換オブジェクトストレージまたは共有分散ファイルシステムに永続化されます。注目すべきデフォルト設定：各サンドボックスにはTTLがあり、期限切れは削除ではなく一時停止をトリガーします。削除には作成APIでautoPause: falseを渡す必要があります。

オンデマンドローディングとスナップショットリポジトリ

イメージはoverlaybdを介してオンデマンドでロードされます。ローカルディスクは境界のあるキャッシュとして機能し、ホットデータを保持しコールドデータを追い出します。これにより、クラスターレベルのストーリーが機能します。ノードはすべてのイメージを事前にウォームアップしたり、すべてのスナップショットの完全なコピーを保持する必要はありません。したがって、アドレス可能なイメージセットはローカルディスク容量を超えることができ、起動はクラスター全体で高速に保たれます。スナップショット状態は3つのレイヤーで編成されています。ビルダーステージングワークスペースはビルド中のアーティファクトを保持します。コミットされたスナップショットリポジトリは耐久性のある真実のソースです。ノードローカルランタイムキャッシュは起動時に派生した設定を保持します。2つのリポジトリバックエンドがサポートされています：posix_fs（デフォルト）とoss。ossパスは共有S3互換クライアントを介して実行されるため、明示的なリージョンが必要です。irohに基づくオプションのピアツーピアトランスポートは、コミットされたアーティファクトをピアノードにアドバタイズできます。デフォルトでは無効です。ドキュメントはP2Pがコミットされたスナップショットモデルを変更しないことを明示しています。共有ストレージの場合、ドキュメントは少なくとも1 Gbpsを要求し、10 Gbps以上を強く推奨しています。

E2B互換性が採用のレバー

AgentENVはE2B互換のHTTP APIを公開しています。E2B_API_URLをサーバーに向ければ、公式のE2B PythonまたはTypeScript SDKがコード変更なしで動作します。これは意図的な配布の選択です。すでにE2Bでエージェントを実行しているチームは、エージェントコードを書き直すことなくランタイムをセルフホストできます。ネイティブのaenv CLIも提供されており、ドキュメントはAgentENV固有のワークフローに推奨しています。

デプロイパス

前提条件はLinuxカーネル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スタック、ゲートウェイ、スケジューラー、ノードDaemonSetを含むKubernetesマニフェスト、Rustツールチェーンを使用したソースからのビルド。マルチノードデプロイは:8080にゲートウェイ、:9090にスケジューラーを追加します。

重要なポイント

デプロイはインストールスクリプト、Docker、Docker Compose、Kubernetesをカバーしており、マルチノードコントロールプレーンはプロトタイプとして文書化されています。AgentENVは各エージェント環境をコンテナではなくFirecrackerマイクロVMとして実行するため、分離はカーネルレベルです。プロジェクトはスナップショットからの起動または再開が50ミリ秒未満、一時停止が100ミリ秒未満と報告しています。実行中のサンドボックスは同一ノード上で最大16個の独立した子サンドボックスにフォークできます。HTTP APIはE2B互換であるため、既存のE2B PythonおよびTypeScript SDKコードは変更なしで動作します。

GitHubリポジトリとドキュメントを確認してください。この研究のすべての功績はこのプロジェクトの研究者に帰属します。

この記事はMarkTechPostに最初に掲載されました。