Moonshot AI と kvcache-ai、分散システム「AgentENV」をオープンソース化
Moonshot AI と kvcache-ai は、Kimi K3 の強化学習訓練を支える分散型プラットフォーム「AgentENV」を MIT ライセンスで公開した。
AI深層分析を開く2026年7月28日 09:06
AI深層分析
キーポイント
環境インフラの課題解決
コンテナと完全仮想マシンのトレードオフを解消し、Firecracker マイクロVM を活用して隔離性と起動速度を両立する。
革新的なストレージ設計
ublk ユーザー空間ブロックデバイスとオーバーレイイメージを採用し、読み取りベース層の共有と書き込み層の分離を実現している。
高速なスナップショット機能
メモリとファイルシステムの変更を逐次記録することで、環境の起動・再開が 50ms 未満、一時停止が 100ms 未満で完了する。
RL に特化したフォーク機能
実行中のサンドボックスから最大 16 の独立した子環境を生成でき、リソース設定と状態を正確に継承して並列ロールアウトを可能にする。
スナップショットとストレージの仕組み
スナップショットは S3 互換ストレージや共有分散ファイルシステムに永続化され、ローカルディスクはホットデータを保持するバウンドキャッシュとして機能する。
重要な引用
AgentENV targets exactly that gap. It runs Firecracker microVMs, then makes idle, restart, and branching cheap enough to run at training scale.
Snapshot-backed environments boot or resume in under 50 ms and pause in under 100 ms.
A running sandbox can clone into up to 16 independent child sandboxes on the same node.
Every sandbox carries a TTL, and expiry triggers a pause, not a delete.
編集コメントを表示
編集コメント
強化学習における環境管理の難しさを解決する実用的なアーキテクチャが公開された。特にスナップショットとフォーク機能の数値は、大規模訓練の実現性を示す重要な指標となる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Moonshot AI の Kimi チームと kvcache-ai は、大規模なエージェント環境を実行するための分散プラットフォーム「AgentENV(AENV)」をオープンソース化しました。このシステムは、Moonshot が開発した 2.8 兆パラメータの Mixture-of-Experts モデル「Kimi K3」における、エージェント型強化学習(RL)のトレーニングを支えています。コードは MIT ライセンスの下で公開されています。
なぜ環境インフラがエージェント型 RL のボトルネックになるのか
エージェント型 RL は単にテキストをサンプリングするだけではありません。モデルが実際のコンピュータ上で行動を起こす必要があります。ロールアウトごとに、ファイルシステムやネットワークスタック、実行中のプロセスを含む、完全に隔離された Linux 環境が必要になります。
この要件は、決定的なトレードオフを生み出します。コンテナは起動が速いものの、ホストカーネルを共有するため、モデル生成コードの安全性(アイソレーション)が弱まります。一方、フル仮想マシンは適切に分離できますが、起動に時間がかかり、アイドル状態でもメモリを消費し続けます。
AgentENV はまさにこの隙間を埋めるために設計されました。Firecracker ミクロVM を実行し、アイドル時のコストや再起動、分岐処理を劇的に削減することで、トレーニング規模での運用を可能にしています。
AgentENV の Firecrcker アーキテクチャの中身
各サンドボックスは、独自の Linux カーネル、ファイルシステム、ネットワーク名前空間を持つ Firecracker ミクロVM です。リクエストは Axum 製の HTTP API を経由し、サンドボックスのライフサイクルを管理するオーケストレーターへ転送されます。
特に興味深いのはストレージ設計です。ルートファイルシステム(rootfs)は、オーバーレイ BD レイヤーイメージでバックされた ublk ユーザー空間ブロックデバイスを通じて提供されます。読み取り専用のベース層はサンドボックス間で共有され、各サンドボックスは独自の上書き層にのみデータを書き込みます。
各ゲスト環境内には、ポート 49983 でコマンド実行、ファイル操作、ヘルスレポートを担う「envd」というデーモンが動作しています。リバースプロキシがクライアントからの 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 以上の高速接続を強く推奨しています。
AgentENV は E2B との互換性を重視した設計となっています。E2B_API_URL を自社のサーバーに設定すれば、公式の E2B Python または TypeScript SDK をそのまま利用でき、コードの変更は一切不要です。
これは意図的なアーキテクチャ上の選択です。すでに E2B でエージェントを運用しているチームでも、エージェント側のコードを書き換えることなく、ランタイムを自前でホストできます。また、AgentENV 固有のワークフローにはネイティブな CLI ツール「aenv」も用意されており、ドキュメントではこちらの利用が推奨されています。
導入にあたっては、Linux カーネル 6.8 以上と/dev/kvm へのアクセス権限が必要です。インストールスクリプトを実行する環境としては Ubuntu 24.04 が必須となります。CLI ツールの「aenv」は x86_64 および arm64 対応の Linux と macOS で動作しますが、サーバー側は KVM を必要とするため Linux のみで動作します。
ドキュメントでは以下の 5 つの導入パスが紹介されています。
- systemd サービスとしてサーバーを起動するインストールスクリプト
- ghcr.io/kvcache-ai/aenv-server に公開された Docker イメージ
- マルチノードクラスタをシミュレートするための Docker Compose スack
- ゲートウェイ、スケジューラ、およびノードの DaemonSet を含む Kubernetes マニフェスト
- Rust ツールチェーンを使用したソースコードからのビルド
マルチノード環境では、ゲートウェイがポート 8080、スケジューラがポート 9090 で動作します。
キミAIとkvcache-aiが「AgentENV」をオープンソース化。キミK3の自律型強化学習(RL)トレーニングを支える分散システム
デプロイメントには、インストールスクリプト、Docker、Docker Compose、そしてKubernetesが含まれています。マルチノードのコントロールプレーンについては、プロトタイプとして文書化されています。
AgentENVは、各エージェント環境をコンテナではなくFirecrackerマイクロVMで実行します。これにより、分離レベルがカーネルレベルに達しています。
プロジェクトによると、スナップショットからの起動または再開は50ミリ秒以内、一時停止は100ミリ秒以内で完了します。
稼働中のサンドボックスでは、同じノード上で最大16の独立した子プロセスをフォークできます。
HTTP APIはE2Bと互換性があるため、既存のE2B用PythonおよびTypeScript SDKコードを変更せずにそのまま使用可能です。
GitHubリポジトリとドキュメントをチェックしてみましょう。本件の研究に対するすべてのクレジットは、このプロジェクトの研究チームにあります。
キミAIとkvcache-aiが「AgentENV」をオープンソース化。キミK3の自律型強化学習(RL)トレーニングを支える分散システムという記事は、MarkTechPostで最初にお伝えしました。
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み