Desde el principio, apostamos por darle al LLM la capacidad de ejecutar código arbitrario. Este artículo trata sobre por qué tomamos esa decisión y lo que implica ejecutar miles de estos entornos aislados (sandboxes) simultáneamente, activándolos y desactivándolos tan rápido como los usuarios inician y terminan sus chats con el agente.
Cada conversación que un usuario mantiene con el agente Adapt está respaldada por su propia computadora. No solo un contenedor restringido en un servidor compartido, sino una máquina virtual (VM) aislada con la que el modelo puede hacer lo que quiera: instalar software, escribir y ejecutar programas, navegar por la web, comunicarse con APIs. A esto lo llamamos sandboxes, y son uno de los elementos fundamentales sobre los que se construye Adapt.
Control total
Los LLM son genios de la programación, y mi trabajo se ha centrado principalmente en construir el entorno de desarrollo perfecto para que puedan trabajar.
La forma habitual de conectar una IA con el mundo exterior es crear integraciones manualmente: un conector a medida para GitHub, otro para HubSpot, otro para Stripe, o esperar a que cada servicio lance un servidor MCP. Esto simplemente no escala, y no me entusiasma la idea de escribir código de integración día tras día.
Así que, en lugar de hacer ese trabajo nosotros mismos, dejamos que el modelo lo haga. Cualquier servicio que exponga una API puede ser accedido desde Adapt, porque le damos al LLM todo lo que necesita para escribir el script o programa que interactúa con esa API. Esa es una gran parte de lo que queremos decir cuando llamamos a Adapt una "inteligencia horizontal": no está conectada a una lista fija de herramientas, puede construir la herramienta que necesita sobre la marcha.
Fundamental para esto es darle al LLM acceso total al sandbox. En lugar de entregarle al modelo un conjunto estático de lenguajes y herramientas de línea de comandos (CLI) con acceso limitado al sistema de archivos, le damos acceso completo a todo. Se ejecuta como root. Y aunque nuestros sandboxes vienen con entornos de ejecución comunes como Node y Python, ¿qué pasa si el mejor SDK para la API de algún servicio está escrito en Go? El modelo simplemente puede instalarlo y ejecutarlo.
¿El LLM necesita escribir un programa en Go? Adelante, instala Go y ejecútalo.
Entonces, si permitimos que el modelo instale lo que quiera y ejecute código que ningún humano ha verificado, ¿cómo lo aseguramos? Afortunadamente, no somos los primeros en necesitar ejecutar código no confiable. Existen dos entornos de ejecución seguros muy populares para esto: gVisor y Firecracker. Nuestra trayectoria hasta ahora nos ha hecho conocer muy bien ambos.
De gVisor a Firecracker
Nuestra primera incursión en sandboxes seguros para LLMs fue el enfoque "fácil": ejecutar cada sandbox con gVisor sobre GKE (Google Kubernetes Engine), utilizando GKE Sandbox. Ya estábamos ejecutando todos nuestros otros servicios en GKE, así que este fue el paso natural para nosotros.
gVisor se sitúa entre un contenedor y el kernel del host. En lugar de permitir que un programa realice llamadas al sistema directamente al kernel real de Linux —algo que realmente no quieres que un código no confiable manipule—, gVisor intercepta esas llamadas en su propio kernel de espacio de usuario y las gestiona él mismo. Obtienes la mayor parte de la comodidad de un contenedor normal con una superficie de ataque mucho menor. Y GKE Sandbox empaqueta todo esto. Despliegas Pods (contenedores) y se ejecutan de forma transparente bajo gVisor, sin que tengamos que hacer mucha configuración de infraestructura.
Y esto funcionó muy bien al principio. Definimos el sandbox "base" como una imagen de Docker y dejamos que GKE lo escalara al número de sandboxes que necesitábamos en cualquier momento. Las actualizaciones del software que incluían los sandboxes eran simples actualizaciones de Dockerfile y un cambio de versión en un manifiesto.
Cientos de Pods de sandbox ejecutándose bajo GKE Sandbox.
Pero la misma abstracción que hizo que gVisor fuera fácil es la que nos mantuvo luchando. Debido a que gVisor reimplementa la superficie de llamadas al sistema de Linux en el espacio de usuario, no todo se comporta exactamente como lo haría en un kernel real, y las cargas de trabajo que nuestro modelo imagina son tan impredecibles como pueden serlo. La interceptación que te brinda seguridad también te cuesta en trabajos con uso intensivo de llamadas al sistema y de E/S. Y depender de GKE para todo el ciclo de vida significaba que las partes que más queríamos controlar —tiempo de arranque, densidad de empaquetado, redes y qué tan agresivamente reciclamos las máquinas— eran las partes sobre las que teníamos menos control. El Pod "OutOfcpu" perdido que se ve arriba es el tipo de cosas que empiezas a notar cuando estás presionando al programador de alguien más más fuerte de lo que quiere ir.
Eso es lo que nos llevó a Firecracker.
Las microVM de Firecracker son máquinas virtuales reales, cada una con su propio kernel invitado, ejecutándose con virtualización de hardware, pero simplificadas para arrancar en una fracción de segundo con solo unos pocos megabytes de sobrecarga. Es la misma tecnología que AWS construyó para empaquetar un número enorme de cargas de trabajo de Lambda y Fargate en hardware compartido. Nos brinda un límite de aislamiento más fuerte que un kernel compartido, arranca lo suficientemente rápido como para sentirse instantáneo y es lo suficientemente pequeño como para empaquetar muchas de ellas en un solo host.
La contrapartida es que Firecracker te entrega una VM y poco más. No hay una capa al estilo GKE que haga la programación, las redes y la orquestación del ciclo de vida. Así que construimos una, y la llamamos orc.
El rootfs es solo una imagen
Una cosa a la que no queríamos renunciar al dejar los contenedores era definir un sandbox como un Dockerfile simple. Los contenedores hacen que eso sea trivial; las VMs tradicionalmente no, ya que una microVM arranca un sistema de archivos raíz, no una imagen OCI.
Así que orc une ambos mundos. Cuando se le pide crear una VM, toma una imagen de Docker/OCI común y genera el sistema de archivos raíz de la VM sobre la marcha, almacenando el resultado en caché para que los arranques posteriores de la misma imagen sean rápidos. Nuestro sandbox base sigue siendo solo un Dockerfile, y orc lo convierte en un rootfs arrancable en el momento de la solicitud.
Eso mantiene nuestro flujo de trabajo idéntico al de los días de GKE: editar un Dockerfile, enviar un nuevo sandbox, mientras se ejecuta en VMs reales por debajo. Y abre una puerta por la que apenas estamos empezando a caminar. Debido a que cualquier imagen OCI puede convertirse en una microVM, podemos arrancar sandboxes desde imágenes distintas a la predeterminada. ¿Quieres una VM que ya tenga Postgres y pgvector integrados? Apunta orc a esa imagen y la obtendrás como su propia máquina aislada. El sandbox deja de ser un entorno único y fijo para convertirse en "cualquier imagen que el trabajo necesite, arrancada como su propia VM".
Ejecución a escala
Y aquí está lo que hace que este sea un problema genuinamente difícil: cada chat obtiene su propio sandbox. Una máquina por conversación. En cualquier momento dado tenemos miles de ellos activos, y ese número nunca está quieto. Cada vez que alguien abre un chat, debe aparecer un sandbox; cada vez que un chat se queda en silencio, uno debe desaparecer para que no estemos pagando por él. Estamos constantemente activando y desactivando sandboxes.
Dos números dominan todo: qué tan rápido podemos tener listo un sandbox y cuántos podemos meter en un host.
Latencia de inicio. Una microVM de Firecracker arranca en unos pocos cientos de milisegundos. Eso es lo suficientemente rápido como para no mantener un grupo de reserva (warm pool) en absoluto, lo cual es una de las victorias más silenciosas del cambio. Bajo GKE, habríamos tenido que mantener capacidad extra para ocultar el tiempo de inicio. Con orc, un sandbox nuevo está listo antes de que te des cuenta, así que simplemente creamos uno bajo demanda cuando comienza un chat y lo eliminamos cuando termina. Ya no hay un grupo inactivo que cuidar o por el que pagar.
Densidad. Debido a que cada microVM es diminuta, podemos empaquetar muchas de ellas en un host físico. Ajustamos la CPU y la memoria de cada sandbox a lo que realmente necesita en lugar de sobreaprovisionar, que es lo que nos permite ejecutar miles de ellos de forma económica.
orc en sí es deliberadamente pequeño. Es un plano de control que habla una API simple: crear una VM con N vCPUs y M megabytes de memoria a partir de una imagen dada, transmitir comandos hacia ella, leer y escribir archivos en su interior, etiquetarla para que podamos encontrarla más tarde y eliminarla cuando hayamos terminado. Cada invitado ejecuta un pequeño proceso init como PID 1 y obtiene su propia red aislada. Eso es casi todo. La magia no es ningún truco inteligente, es que estos elementos básicos son aburridos y lo suficientemente rápidos como para ejecutar una flota con ellos.
La recompensa por toda esta infraestructura es lo que teníamos al principio: un modelo que puede instalar cualquier cosa, escribir un programa, acceder a una API y devolverte una respuesta, todo en una computadora real.
