Nous avons fait le pari très tôt de donner aux LLM la capacité d'exécuter du code arbitraire. Cet article explique pourquoi nous avons fait ce choix et ce qu'il faut pour gérer des milliers de ces environnements isolés (sandboxes) simultanément, en les créant et en les supprimant aussi rapidement que les utilisateurs démarrent et terminent leurs conversations avec l'agent.
Chaque conversation qu'un utilisateur a avec l'agent Adapt est prise en charge par son propre ordinateur. Il ne s'agit pas simplement d'un conteneur restreint sur un serveur partagé, mais d'une machine virtuelle (VM) isolée avec laquelle le modèle peut faire ce qu'il veut : installer des logiciels, écrire et exécuter des programmes, naviguer sur le Web, interagir avec des API. Nous appelons ces environnements des « sandboxes », et ils constituent l'une des primitives fondamentales sur lesquelles Adapt est construit.
Contrôle total
Les LLM sont des génies du code, et mon travail a principalement consisté à construire l'environnement de développement idéal pour qu'ils puissent travailler.
La manière habituelle de connecter une IA au monde extérieur consiste à créer manuellement des intégrations : un connecteur sur mesure pour GitHub, un autre pour HubSpot, un autre pour Stripe, ou à attendre que chaque service propose un serveur MCP. Cela n'est tout simplement pas évolutif, et je ne suis pas vraiment fan de l'idée d'écrire du code d'intégration jour après jour.
Alors, au lieu de faire ce travail nous-mêmes, nous laissons le modèle s'en charger. Tout service exposant une API peut être accédé depuis Adapt, car nous donnons au LLM tout ce dont il a besoin pour écrire le script ou le programme qui communique avec cette API. C'est une grande partie de ce que nous voulons dire lorsque nous qualifions Adapt d'« intelligence horizontale » : il n'est pas limité à une liste fixe d'outils, il peut construire l'outil dont il a besoin sur le moment.
La base de tout cela est de donner au LLM un accès complet à la sandbox. Au lieu de fournir au modèle un ensemble statique de langages et d'outils CLI avec un accès limité au système de fichiers, nous lui donnons un accès complet à tout. Il s'exécute en tant que root. Et bien que nos sandboxes soient livrées avec des environnements d'exécution courants comme Node et Python, que faire si le meilleur SDK pour l'API d'un service est écrit en Go ? Le modèle peut simplement l'installer et l'exécuter.
Le LLM a-t-il besoin d'écrire un programme en Go ? Il n'a qu'à installer Go et l'exécuter.
Alors, si nous permettons au modèle d'installer ce qu'il veut et d'exécuter du code qu'aucun humain n'a vérifié, comment le sécuriser ? Heureusement, nous ne sommes pas les premiers à avoir eu besoin d'exécuter du code non fiable. Il existe deux environnements d'exécution sécurisés très populaires pour cela : gVisor et Firecracker. Notre parcours nous a permis de bien connaître les deux.
De gVisor à Firecracker
Notre première incursion dans les sandboxes sécurisées pour LLM a été l'approche « facile » : exécuter chaque sandbox avec gVisor au-dessus de GKE (Google Kubernetes Engine), en utilisant GKE Sandbox. Nous exécutions déjà tous nos autres services sur GKE, c'était donc l'étape naturelle pour nous.
gVisor se place entre un conteneur et le noyau hôte. Au lieu de laisser un programme effectuer des appels système directement vers le noyau Linux réel — ce que vous ne voulez vraiment pas que du code non fiable manipule — gVisor intercepte ces appels dans son propre noyau en espace utilisateur et les traite lui-même. Vous bénéficiez de la plupart des avantages d'un conteneur classique avec une surface d'attaque beaucoup plus réduite. Et GKE Sandbox regroupe tout cela. Vous déployez des Pods (conteneurs) et ils s'exécutent de manière transparente sous gVisor, sans que nous ayons à effectuer beaucoup de configuration d'infrastructure.
Et cela a très bien fonctionné au début. Nous avons défini la sandbox « de base » comme une image Docker et avons laissé GKE la mettre à l'échelle en fonction du nombre de sandboxes dont nous avions besoin à un moment donné. Les mises à jour des logiciels inclus dans les sandboxes se résumaient à de simples mises à jour du Dockerfile et à une incrémentation de version dans un manifeste.
Des centaines de Pods sandbox s'exécutant sous GKE Sandbox.
Mais l'abstraction même qui rendait gVisor facile est celle contre laquelle nous avons continué à lutter. Comme gVisor réimplémente la surface des appels système Linux en espace utilisateur, tout ne se comporte pas exactement comme sur un noyau réel, et les charges de travail que notre modèle imagine sont aussi imprévisibles que possible. L'interception qui vous apporte la sécurité vous coûte également cher sur les tâches intensives en appels système et en E/S. Et dépendre de GKE pour l'ensemble du cycle de vie signifiait que les éléments que nous voulions le plus contrôler — temps de démarrage, densité de regroupement, mise en réseau et agressivité du recyclage des machines — étaient ceux sur lesquels nous avions le moins de contrôle. Le Pod « OutOfcpu » errant ci-dessus est le genre de chose que vous commencez à voir lorsque vous poussez l'ordonnanceur de quelqu'un d'autre plus fort qu'il ne le souhaite.
C'est ce qui nous a poussés vers Firecracker.
Les microVM Firecracker sont de véritables machines virtuelles, chacune avec son propre noyau invité, fonctionnant avec la virtualisation matérielle, mais dépouillées pour démarrer en une fraction de seconde avec seulement quelques mégaoctets de surcharge. C'est la même technologie qu'AWS a construite pour regrouper un nombre énorme de charges de travail Lambda et Fargate sur du matériel partagé. Cela nous donne une frontière d'isolation plus forte qu'un noyau partagé, démarre assez rapidement pour sembler instantané et est assez petit pour en regrouper beaucoup sur un seul hôte.
Le compromis est que Firecracker vous donne une VM et pas grand-chose d'autre. Il n'y a pas de couche de style GKE pour gérer l'ordonnancement, la mise en réseau et l'orchestration du cycle de vie. Nous en avons donc construit une, et nous l'appelons orc.
Le rootfs n'est qu'une image
Une chose à laquelle nous ne voulions pas renoncer en abandonnant les conteneurs était de définir une sandbox comme un simple Dockerfile. Les conteneurs rendent cela trivial ; les VM ne le font traditionnellement pas, car une microVM démarre un système de fichiers racine, pas une image OCI.
Donc, orc fait le pont entre les deux. Lorsqu'il est invité à créer une VM, il prend une image Docker/OCI ordinaire et génère le système de fichiers racine de la VM à la volée, en mettant le résultat en cache pour que les démarrages ultérieurs de la même image soient rapides. Notre sandbox de base est toujours un simple Dockerfile, et orc le transforme en un rootfs amorçable au moment de la demande.
Cela maintient notre flux de travail identique à l'époque de GKE : modifier un Dockerfile, déployer une nouvelle sandbox, tout en s'exécutant sur de vraies VM en dessous. Et cela ouvre une porte que nous commençons à peine à franchir. Comme n'importe quelle image OCI peut devenir une microVM, nous pouvons démarrer des sandboxes à partir d'images autres que celle par défaut. Vous voulez une VM qui a déjà Postgres et pgvector intégrés ? Indiquez cette image à orc et vous l'obtenez en tant que machine isolée. La sandbox cesse d'être un environnement fixe unique pour devenir « n'importe quelle image dont le travail a besoin, démarrée comme sa propre VM ».
Exécuter à grande échelle
Et voici ce qui rend ce problème réellement difficile : chaque conversation obtient sa propre sandbox. Une machine par conversation. À tout moment, nous en avons des milliers d'actives, et ce nombre ne reste jamais immobile. Chaque fois que quelqu'un ouvre une discussion, une sandbox doit apparaître ; chaque fois qu'une discussion devient silencieuse, l'une d'elles doit disparaître pour que nous ne payions pas pour elle. Nous créons et supprimons constamment des sandboxes.
Deux chiffres dominent tout : la vitesse à laquelle nous pouvons préparer une sandbox et le nombre que nous pouvons faire tenir sur un hôte.
Latence de démarrage. Une microVM Firecracker démarre en quelques centaines de millisecondes. C'est assez rapide pour que nous n'ayons pas besoin de conserver un pool « chaud », ce qui est l'une des victoires les plus discrètes de ce changement. Sous GKE, nous aurions dû conserver une capacité excédentaire pour masquer le temps de démarrage. Avec orc, une nouvelle sandbox est prête avant que vous ne vous en rendiez compte, nous en créons donc une à la demande lorsqu'une discussion commence et nous la supprimons lorsqu'elle est terminée. Plus besoin de surveiller ou de payer pour un pool inactif.
Densité. Comme chaque microVM est minuscule, nous pouvons en regrouper beaucoup sur un seul hôte physique. Nous dimensionnons le CPU et la mémoire de chaque sandbox en fonction de ce dont elle a réellement besoin plutôt que de sur-provisionner, ce qui nous permet d'en exécuter des milliers de manière économique.
orc lui-même est délibérément petit. C'est un plan de contrôle qui utilise une API simple : créer une VM avec N vCPU et M mégaoctets de mémoire à partir d'une image donnée, diffuser des commandes à l'intérieur, lire et écrire des fichiers, l'étiqueter pour pouvoir la retrouver plus tard, et la supprimer une fois le travail terminé. Chaque invité exécute un minuscule processus init en tant que PID 1 et obtient son propre réseau isolé. C'est l'essentiel. La magie ne réside pas dans une astuce ingénieuse, mais dans le fait que ces primitives sont simples et assez rapides pour gérer une flotte entière.
La récompense pour toute cette plomberie est ce avec quoi nous avons commencé : un modèle capable d'installer n'importe quoi, d'écrire un programme, d'interroger une API et de vous renvoyer une réponse, le tout sur un véritable ordinateur.
