Modal fait évoluer gVisor : isoler les tâches d'IA avec un démarrage de sandbox en 25 ms

Si votre agent IA sait exécuter du Python, installer des paquets et lancer des commandes, vous construisez déjà un service d'exécution de code tiers. Un conteneur ordinaire aide à séparer les environnements, mais laisse aux applications un noyau Linux commun. Une faille dans ce noyau peut transformer l'exécution ratée d'un script en problème pour toute la machine. Modal propose de se pencher sur gVisor : selon l'entreprise, la sandbox démarre en environ 25 ms pour un surcoût mémoire d'environ 12 Mo.

Le point de départ est un changement de gouvernance du projet. Selon la publication de Modal, Google transfère gVisor, avec son nom et ses marques, à la CNCF, tandis que la direction technique passe aux mainteneurs. Modal, Ant Group et Tines se sont engagés à rejoindre leurs rangs. Pour les développeurs d'infrastructure, l'essentiel est la poursuite du support des GPU, des échanges réseau et de la compatibilité avec les outils habituels.

Ce qui se passe entre le script et le serveur

Imaginez un service où l'agent télécharge le dépôt d'un utilisateur et lance les tests. On peut y trouver des dépendances inconnues, des scripts d'installation et des commandes arbitraires. Dans un conteneur ordinaire, leurs appels système sont traités par le noyau de l'hôte, celui-là même qu'utilisent les tâches voisines.

gVisor insère entre l'application et l'hôte son propre noyau logiciel, Sentry, écrit en Go. Il implémente lui-même l'interface des appels système Linux et ne s'adresse au vrai noyau que via un ensemble restreint d'opérations. Le programme dispose d'un environnement familier, mais son accès au serveur passe par un contrôle supplémentaire.

Sentry est lui aussi limité par les mécanismes de Linux : espaces de noms, limites de ressources et filtres seccomp. Ce sont plusieurs couches de protection, et non une promesse de sécurité absolue. La virtualisation matérielle n'est pas requise : l'approche convient aussi aux machines virtuelles cloud où la virtualisation imbriquée n'est pas disponible.

Modal affirme exécuter plus de 40 millions de conteneurs gVisor par jour. Parmi les charges : l'inférence, l'entraînement sur plusieurs machines et les sandboxes d'agents. C'est l'expérience d'un seul fournisseur, mais elle montre que la technologie est utilisée bien au-delà des bancs de démonstration.

GPU dans la sandbox : où apparaissent les difficultés

Isoler un script ne suffit pas : il a souvent besoin de CUDA, de plusieurs cartes graphiques et d'échanges de données rapides. Pour NVIDIA, gVisor dispose de nvproxy. Il analyse et vérifie les appels à l'interface du pilote tout en conservant l'exécution native des calculs et le travail avec la mémoire GPU.

Modal décrit les modifications soumises au projet principal pour les nouveaux pilotes, NVLink, CUDA MPS, les profileurs Nsight et la supervision. Le sens pratique est simple : déplacer une tâche dans la sandbox gêne moins le travail habituel de l'ingénieur. Il faut néanmoins vérifier dans son propre environnement la prise en charge d'un GPU, d'un pilote et d'un outil donnés.

Pour l'entraînement sur plusieurs serveurs, l'entreprise a ajouté rdmaproxy. Il vérifie les opérations de contrôle RDMA tout en laissant aux transferts de données un chemin direct via le matériel. Dans les tests NCCL all-reduce, Modal a obtenu environ 99 % du débit natif. C'est le résultat d'un benchmark précis : cela ne signifie pas que tout entraînement ne perd que 1 % de vitesse.

Un autre résultat éclairant concerne la transmission de paquets de données via la mémoire partagée : après modification de l'allocateur de mémoire, la vitesse d'un test est passée de 2,9 à 22 Go/s. Un tel gain montre à quel point la performance dépend de la nature de la charge et de l'implémentation de chaque opération.

Ce qu'il faut vérifier chez soi

Pour une équipe qui exécute le code d'utilisateurs ou d'agents, gVisor mérite un essai à part. Prenez une tâche réelle : installation de dépendances, parcours d'un gros dépôt, lancement de tests, lecture d'un jeu de données. Mesurez le temps de démarrage, la consommation mémoire, les opérations sur les fichiers et la compatibilité des bibliothèques nécessaires. Un démarrage rapide de la sandbox ne garantit pas à lui seul une réponse rapide du produit.

Pour l'inférence, les snapshots d'état sont intéressants : on peut sauvegarder un processus déjà préparé et le restaurer sur une autre machine. Modal indique environ 670 000 restaurations de conteneurs à partir de snapshots par jour. Mais les snapshots de programmes multi-GPU sont encore en développement ; GPUDirect Storage et le lancement de grands serveurs d'inférence en moins d'une minute sont eux aussi présentés comme des projets.

Le principal enseignement pour un fondateur ou un product manager : l'exécution de code généré exige une décision d'isolation distincte. Le passage de gVisor à la gouvernance par des mainteneurs élargit le cercle des entreprises responsables du projet. La décision d'adopter la technologie doit reposer sur vos propres tests de sécurité, de compatibilité et de coût d'exécution.