L’équipe Kimi de Moonshot AI et kvcache-ai ont ouvert le code d’AgentENV (AENV), une plateforme distribuée conçue pour exécuter des environnements d’agents à grande échelle. AgentENV est utilisé pour l’entraînement par apprentissage par renforcement (RL) agentique de Kimi K3, le modèle Mixture-of-Experts de Moonshot doté de 2,8 billions de paramètres. Le projet est publié sous licence MIT.

Pourquoi l’infrastructure d’environnement constitue un goulot d’étranglement pour le RL agentique

Le RL agentique ne se limite pas à échantillonner du texte à partir d’un modèle. Il exige que le modèle agisse dans un véritable environnement informatique. Chaque rollout nécessite un environnement Linux isolé avec un système de fichiers, une pile réseau et des processus actifs. Dans ce type de boucle d’entraînement, l’environnement fait partie du chemin de génération des données ; la vitesse de réinitialisation, l’isolation et la capacité à reproduire ou à faire diverger des états de tâche influencent donc directement le nombre de rollouts utiles pouvant être collectés.

Cette exigence crée un arbitrage d’infrastructure difficile. Les conteneurs peuvent démarrer rapidement, mais ils partagent le noyau de l’hôte, ce qui affaiblit l’isolation lorsque du code généré par le modèle est exécuté. Les machines virtuelles complètes offrent une isolation plus forte, mais elles démarrent plus lentement et continuent d’occuper de la mémoire lorsqu’elles sont inactives.

AgentENV est conçu pour combler cet écart. Il exécute des microVM Firecracker et vise à rendre les états inactifs, les redémarrages et les branchements suffisamment peu coûteux pour prendre en charge des charges de travail à l’échelle de l’entraînement.

À l’intérieur de l’architecture AgentENV fondée sur Firecracker

Chaque sandbox AgentENV s’exécute comme une microVM Firecracker avec son propre noyau Linux, son système de fichiers et son espace de noms réseau. Les requêtes sont reçues via une API HTTP Axum, qui les transmet à un orchestrateur chargé de gérer le cycle de vie de la sandbox.

Le stockage est un élément central de la conception. Le système de fichiers racine est servi via un périphérique bloc en espace utilisateur ublk, adossé à des images en couches overlaybd. Les couches de base en lecture seule sont partagées entre les sandboxes, tandis que chaque sandbox écrit dans sa propre couche supérieure.

Dans chaque environnement invité, un démon appelé envd gère l’exécution des commandes, les opérations sur les fichiers et les rapports de santé sur le port 49983. Un proxy inverse achemine le trafic HTTP et WebSocket des clients vers les services exécutés à l’intérieur de la machine virtuelle.

Le projet décrit également deux mécanismes destinés à améliorer la densité. Le cache de pages de l’hôte est partagé entre le stockage et les données de snapshots mémoire. Le memory ballooning restitue à l’hôte la mémoire invitée récupérable, ce qui aide à maintenir le surengagement à mesure que les environnements divergent au fil du temps.

Snapshot, pause, reprise et fork

La prise de snapshots, la mise en pause, la reprise et le fork sont les fonctionnalités centrales d’AgentENV. Le système capture les changements de mémoire et de système de fichiers de manière incrémentale au lieu d’écrire une image complète à chaque fois.

Les chiffres de performance communiqués indiquent que les environnements adossés à des snapshots démarrent ou reprennent en moins de 50 ms et se mettent en pause en moins de 100 ms. La capture incrémentale de snapshot serait réalisée en moins de 100 ms, même en cas de modifications importantes du disque.

Le fork est la fonctionnalité la plus spécifique aux charges de travail RL. Une sandbox en cours d’exécution peut se cloner en jusqu’à 16 sandboxes enfants indépendantes sur le même nœud. L’environnement source se met brièvement en pause pendant la capture, puis reprend. Chaque enfant hérite du système de fichiers, de la mémoire et de la configuration des ressources de la source.

Le résultat pratique est qu’une configuration coûteuse peut être effectuée une seule fois. Une équipe peut installer des dépendances, cloner un dépôt et atteindre un état de tâche donné, puis dériver cet état exact en rollouts parallèles. C’est important pour les tâches agentiques où des essais répétés doivent démarrer depuis le même état préparé tout en explorant différentes trajectoires d’action. Les snapshots peuvent persister dans un stockage objet compatible S3 ou dans un système de fichiers distribué partagé.

Un comportement par défaut mérite d’être noté : chaque sandbox possède un TTL, et son expiration déclenche une pause plutôt qu’une suppression. La suppression nécessite de transmettre autoPause: false à l’API de création.

Chargement à la demande et dépôt de snapshots

Les images sont chargées à la demande via overlaybd. Le disque local agit comme un cache borné, conservant les données chaudes et évincant les données froides.

Cette conception prend en charge un fonctionnement à l’échelle d’un parc, car les nœuds n’ont pas besoin de préchauffer chaque image ni de stocker une copie complète de chaque snapshot. L’ensemble d’images adressable peut dépasser la capacité du disque local tout en conservant un démarrage rapide dans l’ensemble du cluster.

L’état des snapshots est organisé en trois couches. Un espace de staging du builder conserve les artefacts pendant une build. Un dépôt de snapshots validés sert de source de vérité durable. Un cache d’exécution local au nœud stocke les configurations dérivées au moment du lancement.

Deux backends de dépôt sont pris en charge : posix_fs, qui est l’option par défaut, et oss. Le chemin oss utilise un client partagé compatible S3 ; une région explicite est donc requise.

AgentENV inclut également un transport pair-à-pair optionnel fondé sur iroh, capable d’annoncer les artefacts validés aux nœuds pairs. Il est désactivé par défaut. La documentation précise explicitement que le P2P ne modifie pas le modèle de snapshots validés. Pour le stockage partagé, la documentation demande au moins 1 Gbps et recommande fortement 10 Gbps ou plus.

La compatibilité E2B comme voie d’adoption

AgentENV expose une API HTTP compatible E2B. En pointant E2B_API_URL vers un serveur AgentENV, les utilisateurs peuvent exécuter les SDK officiels E2B Python ou TypeScript sans modification du code.

Cette compatibilité relève d’un choix de distribution délibéré. Les équipes qui exécutent déjà des agents sur E2B peuvent auto-héberger le runtime sans réécrire leur code d’agent. AgentENV fournit également une CLI native aenv, que la documentation recommande pour les workflows propres à AgentENV.

Options de déploiement

AgentENV nécessite le noyau Linux 6.8+ et l’accès à /dev/kvm ; le script d’installation exige en outre Ubuntu 24.04. La CLI aenv prend en charge Linux et macOS sur x86_64 et arm64. Le serveur est uniquement compatible Linux, car il nécessite KVM.

La documentation décrit cinq voies de déploiement :

• Un script d’installation qui exécute le serveur comme service systemd
• Une image Docker publiée à l’adresse ghcr.io/kvcache-ai/aenv-server
• Une stack Docker Compose qui simule un cluster multinœud
• Des manifests Kubernetes avec une passerelle, un ordonnanceur et un DaemonSet de nœuds
• Une voie de compilation depuis les sources à l’aide de la chaîne d’outils Rust

Les déploiements multinœuds ajoutent une passerelle sur :8080 et un ordonnanceur sur :9090. Le plan de contrôle multinœud est documenté comme un prototype, ce qui fait de la maturité de l’ordonnancement en cluster et des exigences opérationnelles liées au stockage partagé des éléments importants pour les équipes évaluant des déploiements plus vastes.

AgentENV exécute chaque environnement d’agent sous forme de microVM Firecracker plutôt que de conteneur, ce qui fournit une isolation au niveau du noyau. Le projet fait état de temps de démarrage ou de reprise fondés sur les snapshots inférieurs à 50 ms et de temps de pause inférieurs à 100 ms. Une sandbox en cours d’exécution peut se dupliquer en jusqu’à 16 enfants indépendants sur le même nœud, et l’API HTTP compatible E2B permet au code existant des SDK E2B Python et TypeScript de fonctionner sans modification.