Sandboxes AgentENV¶
Le chiffre qui résume cette section : 51 219 741 sandboxes créées au cours de l'entraînement et de l'évaluation de Kimi K3, à partir de 1 505 678 images distinctes.
Les trois runtimes¶
Kimi K3 emploie plusieurs runtimes de sandbox pour couvrir les besoins variés du post-entraînement et de l'évaluation :
| Runtime | Usage |
|---|---|
| Conteneurs traditionnels | Cas simples |
| Sandbox GPU | Tâches de noyaux, entraînement en sandbox |
| AgentENV (microVM) | Le plus notable — conçu spécifiquement pour les charges agentiques |
AgentENV est développé en collaboration avec des partenaires et ouvert : github.com/kvcache-ai/AgentENV.
Objectif 1 : isolation et fidélité¶
Le problème réel, tel que rencontré¶
Ce que le rapport documente
À mesure que les agents deviennent capables et les tâches difficiles, ils explorent plus agressivement et peuvent même tenter du reward hacking.
Dans nos premières expériences avec des runtimes de sandbox à base de conteneurs traditionnels, nous avons observé plusieurs paniques noyau et interblocages causés par des opérations non intentionnelles des agents.
Ce n'est pas une inquiétude théorique : les agents ont réellement fait tomber les machines.
La tension à résoudre¶
Deux exigences contradictoires :
- Sécurité : un agent hors de contrôle ne doit pas compromettre l'hôte ;
- Capacité : il faut permettre autant d'exploration que possible, pour ne pas brider les capacités de l'agent. Le rapport est explicite : les tâches complexes exigent un environnement proche du réel — les agents doivent pouvoir monter des disques, exécuter des conteneurs, voire lancer des machines virtuelles à volonté.
La solution : les microVM¶
Firecracker
En exécutant des microVM isolées avec Firecracker, AgentENV fournit un niveau d'isolation et de fidélité que les runtimes à base de conteneurs ne peuvent pas égaler.
| Conteneur | microVM Firecracker | |
|---|---|---|
| Noyau | Partagé avec l'hôte | Séparé |
| Une panique noyau affecte | L'hôte | La seule VM |
| L'agent peut lancer des conteneurs | Difficilement | Oui |
| L'agent peut lancer des VM | Non | Oui |
| Latence de démarrage | ~100 ms | ~125 ms |
Le compromis usuel « isolation contre légèreté » est ici résolu par une technologie — Firecracker, conçue par AWS pour Lambda — qui offre presque les deux.
Objectif 2 : cycles de vie flexibles pour le RL agentique¶
La brique de base : le checkpointing incrémental¶
AgentENV supporte le checkpointing et la reprise incrémentaux de l'état de sandbox : seules les pages mémoire salies depuis le dernier checkpoint sont sauvegardées.
Les latences annoncées
| Opération | Latence |
|---|---|
| Checkpoint | 133 ms |
| Reprise | 49 ms |
Ces chiffres sont ce qui rend le partial rollout praticable : mettre en pause des milliers de trajectoires entre itérations coûte quelques secondes au total, pas des heures.
Les trois opérations de haut niveau¶
(a) Pause et reprise
Une sandbox en pause ne consomme ni mémoire ni CPU. On peut donc la mettre en pause pendant que l'agent attend le résultat d'inférence du modèle.
Le chiffre décisif
Cette attente peut représenter jusqu'à 98 % de la durée de vie de la sandbox.
Autrement dit : sans pause, 98 % des ressources de sandbox seraient gaspillées à attendre. C'est probablement le levier d'efficacité le plus important de tout le système RL.
(b) Fork
Crée une nouvelle sandbox à partir de l'état exact de l'originale, tout en gardant l'originale en fonctionnement.
Usage : le jugement de récompense sans effet de bord. On forke, on laisse le juge inspecter et manipuler la copie, et l'original poursuit intact.
(c) Snapshot
Des instantanés sont sauvegardés à intervalles réguliers, pour la récupération d'erreur. Une trajectoire de plusieurs heures ne doit pas être perdue à cause d'une défaillance à la 900ᵉ étape.
Objectif 3 : efficacité et densité¶
Le problème d'échelle¶
Dans nos charges, des dizaines de milliers de sandboxes, chacune avec un ensemble unique d'images, peuvent devoir être créées en quelques secondes.
C'est un problème de distribution d'images d'une sévérité inhabituelle : ce n'est pas la même image répliquée, mais des images différentes.
Les solutions¶
| Technique | Rôle |
|---|---|
| OverlayBD comme format d'image | Format en couches, montable à la demande |
| Implémentation ublk personnalisée | Pilote de bloc en espace utilisateur, taillé sur mesure |
| Partage au niveau du stockage | Les couches communes ne sont stockées qu'une fois |
| Transport P2P | Les nœuds se servent mutuellement les couches, au lieu de saturer un registre central |
Résultat : latence de lancement sub-seconde à grande échelle.
La densité mémoire¶
Deux techniques supplémentaires :
- mémoire en copie sur écriture (copy-on-write) ;
- optimisations du cache de pages.
Le résultat
Un taux de surengagement mémoire allant jusqu'à 6,5× dans les charges réelles.
Autrement dit : on peut faire tourner l'équivalent de 6,5 fois plus de sandboxes que la mémoire physique ne le permettrait naïvement, parce que la plupart partagent l'essentiel de leurs pages.
Ce que 51 millions de sandboxes signifient¶
Une mise en perspective
51 219 741 sandboxes sur, disons, six mois d'entraînement, cela représente environ 3 300 créations de sandbox par minute, en continu.
Et 1 505 678 images distinctes indique que chaque tâche, ou presque, a son propre environnement — ce ne sont pas quelques modèles réutilisés, mais un parc massivement hétérogène.
Ce chiffre est probablement le meilleur indicateur unique de ce qu'est devenu l'entraînement d'un modèle agentique de frontière : moins un calcul qu'une exploitation industrielle d'environnements simulés.
Vérification de compréhension¶
Pourquoi le fork est-il indispensable pour le jugement de récompense ?
Parce qu'un juge qui inspecte un environnement le modifie : il lance des commandes, lit des fichiers, change des horodatages, consomme de la mémoire. Si l'agent devait continuer dans cet environnement, il verrait un état pollué. Le fork garantit que le jugement est sans effet de bord sur la trajectoire.
Quel est le lien entre AgentENV et le partial rollout ?
Direct et essentiel. Le partial rollout met en pause des trajectoires inachevées pour les reprendre à l'itération suivante. Mais une trajectoire n'est pas seulement du texte : c'est aussi l'état complet d'un environnement — fichiers créés, processus en cours, base de données modifiée. Sans checkpointing/reprise de sandbox, on ne pourrait pas reprendre une trajectoire là où elle s'est arrêtée.
Pourquoi le transport P2P plutôt qu'un registre d'images central ?
Parce que créer des dizaines de milliers de sandboxes en quelques secondes depuis un registre central saturerait instantanément sa bande passante. En P2P, chaque nœud qui a déjà téléchargé une couche peut la servir aux autres : la capacité de distribution croît avec le nombre de consommateurs, au lieu de diminuer.
Chapitre précédent : Infra RL 1 M · Chapitre suivant : Cache de préfixe hybride