Kimi et kvcache-ai open-sourcent AgentENV — une plateforme distribuée pour l'entraînement RL d'agents à l'échelle Kimi K3

L'équipe de Moonshot AI (créatrice du modèle Kimi K3), en collaboration avec kvcache-ai, a open-sourcé (licence MIT) la plateforme AgentENV — un système distribué pour l'exécution à grande échelle d'environnements d'agents, utilisé pour l'entraînement par renforcement (RL) de leur modèle MoE (Mixture of Experts) de 2,8 billions de paramètres, Kimi K3. Chaque sandbox est une micro-VM Firecracker avec son propre noyau Linux, système de fichiers et espace de noms réseau, offrant une isolation au niveau du noyau. La gestion du cycle de vie des sandbox est assurée via une API HTTP Axum qui achemine les requêtes vers un orchestrateur. Le système de fichiers racine (rootfs) passe par ublk dans l'espace utilisateur, utilisant overlaybd pour des images en couches : les couches de base sont en lecture seule et partagées entre les sandbox, tandis que chaque sandbox a sa propre couche supérieure inscriptible. Dans la VM invitée, le daemon envd (port 49983) gère les commandes, les opérations de fichiers et les rapports d'état ; un proxy inverse route le trafic HTTP et WebSocket des clients vers les services de la VM. Une attention particulière est portée à la réduction de la surcharge : le cache de pages de l'hôte est partagé entre les données de stockage et les snapshots mémoire, et un mécanisme de ballonnement mémoire (ballooning) permet de récupérer l'excès de mémoire de l'invité vers l'hôte, prenant en charge le surengagement (overcommit) à mesure que les environnements divergent. Les fonctionnalités clés incluent la capture instantanée (snapshotting), la mise en pause, la reprise et le fork. Les snapshots sont incrémentiels, pas complets. Selon les données rapportées, le chargement ou la reprise à partir d'un snapshot prend moins de 50 ms, la mise en pause moins de 100 ms, et les snapshots incrémentiels, même sous forte charge d'écriture, s'achèvent en moins de 100 ms. La fonctionnalité de fork, spécifique au RL, permet de cloner un sandbox en cours d'exécution en jusqu'à 16 sandbox enfants indépendants sur le même nœud. Le sandbox parent est brièvement mis en pause pendant la capture, puis repris. Tous les enfants héritent du système de fichiers, de la mémoire et de la configuration des ressources du parent. Cela permet d'effectuer des configurations coûteuses (installation de dépendances, clonage de dépôts) une fois, puis de forker l'état en exécutions parallèles. Les snapshots sont sauvegardés vers un stockage d'objets compatible S3 ou un système de fichiers distribué. Par défaut, chaque sandbox a une TTL (Time To Live) ; à son expiration, il n'est pas supprimé mais mis en pause ; pour le supprimer, il faut passer autoPause: false à la création. Les images sont chargées à la demande via overlaybd avec un cache disque local qui stocke les données chaudes et évince les données froides. Cela évite de préchauffer chaque image sur tous les nœuds et peut dépasser la capacité du disque local. L'état est organisé en trois couches : un espace de travail (collector workspace) pour les artefacts, un dépôt de snapshots (stockage persistant) et un cache d'exécution local pour les configurations dérivées. Deux backends de dépôt sont supportés : posix_fs (par défaut) et oss (via un client compatible S3, la région doit être explicitement spécifiée). Un transport P2P optionnel basé sur iroh peut annoncer les artefacts aux nœuds voisins mais est désactivé par défaut. Pour le stockage partagé, une bande passante minimale de 1 Gbit/s est recommandée, et 10 Gbit/s ou plus est fortement recommandé. Pour une transition facile, AgentENV fournit une API HTTP compatible E2B : il suffit de définir l'URL de l'API E2B (E2B_API_URL) vers votre propre serveur, et les SDK officiels E2B Python/TypeScript fonctionneront sans modification de code des agents. Une interface en ligne de commande native, aenv, est également disponible. Le déploiement nécessite Linux 6.8+ et /dev/kvm ; le script d'installation cible Ubuntu 24.04. L'interface CLI supporte Linux et macOS sur x86_64 et arm64, tandis que le serveur nécessite Linux (KVM). Cinq méthodes de déploiement sont documentées : un script d'installation avec systemd, une image Docker, Docker Compose pour la simulation de cluster, des manifestes Kubernetes avec gateway, scheduler et DaemonSet, et la compilation à partir des sources Rust. Dans les déploiements multi-nœuds, une gateway sur le port 8080 et un scheduler sur le port 9090 sont ajoutés.