Unikraft y el problema de escala de la infraestructura de IA: cómo meter un millón de sandboxes en un único servidor
Resumen ejecutivo
En una charla reciente en Londres, Felipe Huici, CEO y cofundador de Unikraft, lanzó una pregunta directa a su audiencia: ¿cuántas máquinas virtuales caben en un servidor de 48 núcleos? Las opciones que él mismo ofreció eran irónicas: una Ubuntu completa, decenas, cientos si el operador se siente aventurero, o, si consigues escalarlas a cero cuando no se usan, una densidad aún mayor. La charla llevaba por título "Fixing the AI Infra Scale Problem by Stuffing 1M Sandboxes in a Single Server" y su tesis central es que el cuello de botella de la nueva generación de infraestructura para IA no es computación sino densidad de aislamiento. Los sandboxes que la IA agentiva necesita ejecutar ya no caben en el modelo de contenedor, ni siquiera en el de microVM clásico. Lo que hace falta es replantear el primitive de aislamiento desde cero, y Unikraft ha construido su plataforma entera alrededor de esa idea. Este artículo explica qué es Unikraft, por qué el aislamiento importa más que nunca para workloads de IA, qué relación tiene con Firecracker y con los unikernels, y qué decisiones de arquitectura puedes tomar tú mañana si estás construyendo plataformas de ejecución de código agentivo.
El cambio de significado de la palabra "sandbox"
Durante casi una década, sandbox fue sinónimo de contenedor. Docker popularizó el término en 2013 y, desde entonces, la mayoría de desarrolladores asocia sandbox con imagen de contenedor, runtime de contenedor y orchestration con Kubernetes. Felipe Huici abre su charla admitiendo que el término ha sido reciclado: hoy, cuando la gente habla de sandboxes en el contexto de IA, casi nunca se refiere a contenedores. Se refiere a entornos aislados donde un agente de IA — ya sea un LLM con capacidad de ejecutar código, un sistema multi-agente que orquesta herramientas, o un pipeline que evalúa código generado — puede correr instrucciones de forma segura, sin afectar al resto del sistema.
Este cambio semántico no es cosmético. Es estructural. Un contenedor de Docker comparte el kernel del host. Un agente de IA ejecutando código arbitrario en un contenedor está, técnicamente, ejecutando ese código con acceso al kernel del host. Las mitigaciones estándar — seccomp, AppArmor, namespaces — reducen la superficie de ataque, pero no la eliminan. Un escape de contenedor significa comprometer el host. Y un agente de IA es, por definición, una pieza de software que ejecuta código que no fue auditado por un humano antes de correrlo. Si tu agente ejecuta un millar de instrucciones por minuto, la probabilidad acumulada de que una de ellas sea maliciosa o simplemente defectuosa hasta el punto de permitir un escape es distinta de cero.
Por eso el primitive de aislamiento importa. Un microVM basado en Firecracker ya no comparte kernel con el host: cada VM tiene su propio kernel, su propio sistema de archivos raíz y su propio set de dispositivos virtualizados. Un escape de la VM todavía tiene que atravesar el hypervisor antes de tocar el host, y el hypervisor es una base de código mucho más pequeña que un kernel Linux completo. Esa es la diferencia operativa entre "confío en que mis sandboxes no serán escapados" y "mi arquitectura está diseñada asumiendo que habrá intentos de escape".
Qué es Unikraft y qué aporta al debate
Unikraft no es un hypervisor nuevo. Es una plataforma para construir plataformas cloud. La compañía comercializa la idea de que cualquier cloud platform — desde una edge function runtime hasta un servicio de ejecución agentiva — debería construirse sobre una base que ofrezca densidad de aislamiento nativa, sin sacrificar velocidad de cold boot. La pieza que Unikraft aporta al ecosistema es un framework para componer unikernels y microVMs optimizados para workloads específicos, junto con herramientas para desplegarlos en producción.
La charla de Huici hace un recorrido por los primitives de aislamiento disponibles: máquinas virtuales estándar, microVMs, unikernels, contenedores y aislamiento a nivel de runtime de lenguaje. El punto al que llega es que cada uno tiene su lugar, pero que los contenedores por sí solos no son suficientes para workloads donde el código ejecutado es generado por un modelo de IA. Los microVMs son un paso adelante, pero un microVM clásico todavía carga un kernel Linux completo y un userland reducido. Un unikernel va más allá: en lugar de ejecutar una distribución Linux mínima dentro de la VM, el unikernel compila la aplicación junto con un kernel mínimo que solo contiene los drivers y subsistemas que esa aplicación necesita. El resultado es una imagen mucho más pequeña, con un TCB medido en cientos de miles de líneas de código en lugar de decenas de millones.
El cold boot es donde el primitive brilla. Huici cita mediciones donde los microVMs optimizados con Unikraft arrancan en pocos milisegundos. Para workloads agentivos, donde cada llamada a herramienta puede requerir un sandbox fresco, milisegundos frente a segundos marca la diferencia entre una experiencia de usuario fluida y un sistema que se siente lento. Para plataformas que ejecutan millones de sandboxes por hora, milisegundos frente a segundos marca la diferencia entre un coste de infraestructura viable y uno que rompe el modelo de negocio.
El argumento del TCB
El trusted computing base, o TCB, es el conjunto de software que debe ser correcto para que el sistema funcione de forma segura. Si tu TCB es pequeño, tienes menos código que auditar, menos superficie de ataque y menos probabilidad de que una vulnerabilidad pase desapercibida. Si tu TCB es grande, ocurre lo contrario.
Para una VM estándar, el TCB incluye el hypervisor, el VMM y, dentro de la VM, el kernel Linux completo. El kernel Linux, en sus versiones modernas, ronda los 30 millones de líneas de código. Cada release incluye miles de parches; cada subsistema — red, almacenamiento, scheduler, drivers — es un vector potencial. Si confías en que tu kernel está libre de vulnerabilidades, estás confiando en que 30 millones de líneas no contienen errores explotables. Es una apuesta que la historia demuestra perdedora.
Para un contenedor, el TCB es peor: incluye el kernel completo del host, más el container runtime, más los namespaces y cgroups del kernel. El contenedor no aísla del kernel; comparte el kernel. Esto significa que una vulnerabilidad en cualquier subsistema del kernel es una vulnerabilidad en todos los contenedores que corren sobre ese host. Seccomp y AppArmor reducen el riesgo limitando las syscalls disponibles, pero no eliminan el kernel del TCB.
Para un unikernel, el TCB es drásticamente menor: el kernel mínimo compilado junto con la aplicación, más el hypervisor. Si el hypervisor es KVM o Firecracker, hablamos de un TCB total de cientos de miles de líneas de código, posiblemente menos si se compilan solo los drivers necesarios. Esto no garantiza seguridad absoluta, pero cambia radicalmente el modelo de auditoría: en lugar de auditar 30 millones de líneas, auditas unas pocas decenas de miles, y tu superficie de ataque cabe en una hoja de cálculo.
Lo que el aislamiento importa para IA agentiva
La IA agentiva es el caso de uso que ha puesto el sandboxing de vuelta en el centro del debate de infraestructura. Un agente es, en esencia, un LLM que decide qué herramientas llamar, ejecuta esas herramientas, observa los resultados e itera. Las herramientas típicas incluyen ejecución de código Python, llamadas HTTP a APIs externas, lectura y escritura de archivos, y shells. Cada una de estas herramientas es, desde la perspectiva de seguridad, un vector de ataque potencial.
Tres riesgos concretos hacen que el aislamiento importe más que nunca:
El primero es el riesgo de prompt injection. Un agente que resume una página web está exponiendo el contexto del LLM al contenido de esa página. Un atacante que coloque instrucciones maliciosas en una página web puede manipular al agente. Sin aislamiento robusto entre el agente y el sistema, esas instrucciones pueden terminar ejecutándose en el host con privilegios indebidos.
El segundo es el riesgo de código no auditado. Un agente que genera código Python y lo ejecuta está ejecutando código que ningún humano revisó. La tasa de errores en código generado por LLMs sigue siendo lo bastante alta como para que un porcentaje no trivial de ejecuciones fallen, y un porcentaje menor pero no despreciable produzca efectos laterales no deseados: borrar archivos fuera del directorio esperado, abrir sockets a destinos arbitrarios, consumir memoria hasta afectar al host.
El tercero es el riesgo de coste. Un agente en bucle, iterando sin progreso, puede consumir recursos del host hasta degradar el servicio. Sin aislamiento, este consumo puede afectar a otros tenants. Con aislamiento por VM, el peor caso es que esa VM concreta quede inservible; el resto del sistema sigue funcionando.
Para plataformas que ejecutan agentes a escala, la combinación de estos tres riesgos hace que el aislamiento por contenedor sea insuficiente. Las plataformas líderes del espacio — Anthropic con su entorno de ejecución, OpenAI con su runtime de herramientas,基础设施建设 de varios startups — están migrando hacia arquitecturas basadas en microVMs o unikernels precisamente porque el modelo de contenedor, aunque útil en muchos contextos, no da las garantías que la IA agentiva demanda.
La densidad como problema de negocio
El número que Huici pone sobre la mesa — un millón de sandboxes en un servidor — no es un benchmark vanidoso. Es una cota que define qué modelos de negocio son viables. Si tu plataforma ejecuta un sandbox por cada llamada de herramienta de un agente, y un agente activo genera decenas de llamadas por minuto, y tienes millones de agentes activos, entonces el coste unitario por sandbox determina tu margen. Si tu sandbox consume 512 MB de RAM, un servidor con 512 GB de RAM ejecuta mil sandboxes. Si tu sandbox consume 50 MB de RAM, el mismo servidor ejecuta diez mil. Si tu sandbox consume 5 MB, cien mil. Y si tu sandbox consume 0.5 MB, un millón.
El coste de memoria no es el único factor. También importa el coste de cold boot: si cada sandbox tarda 5 segundos en arrancar, tu plataforma solo puede crear 12 sandboxes por segundo por nodo, y necesitas cientos de nodos para sostener un tráfico de miles de sandboxes por segundo. Si el cold boot baja a 50 milisegundos, un solo nodo puede crear 20 sandboxes por segundo, y la economía cambia radicalmente.
El tercer factor es el coste operativo. Mantener un unikernel o un microVM optimizado requiere expertise que mantener un contenedor Docker no requiere. Unikraft, precisamente, ofrece esa expertise como producto: en lugar de que cada equipo de plataforma tenga que aprender a compilar unikernels, puede usar el framework de Unikraft para construir imágenes optimizadas para sus workloads específicos.
Cuándo unikernel, cuándo microVM, cuándo contenedor
No todos los workloads necesitan unikernels. La decisión correcta depende de tres ejes: requisitos de aislamiento, requisitos de densidad y requisitos de portabilidad.
Si tu workload es un servicio web stateless tradicional que recibe tráfico HTTP, procesa y responde, un contenedor es probablemente suficiente. El aislamiento del kernel es aceptable porque el código es auditado, el tráfico es predecible y la superficie de ataque es limitada. Los beneficios de unikernel — menor TCB, menor memoria — no compensan la pérdida de familiaridad y tooling.
Si tu workload ejecuta código generado por IA o código de terceros no auditado, sube a microVM. Firecracker es la opción más popular; las VMs arrancan en cientos de milisegundos, el TCB es razonable, y la compatibilidad con Linux es alta. El coste de memoria es más alto que unikernel, pero el modelo operativo es familiar.
Si tu workload es un agente de IA de alta frecuencia que necesita escalar a millones de sandboxes concurrentes, unikernel empieza a tener sentido. El menor TCB reduce el riesgo de seguridad, la menor huella de memoria aumenta la densidad, y el cold boot más rápido mejora la latencia. El precio es la pérdida de portabilidad: un unikernel compilado para KVM no corre fuera de KVM sin recompilación.
Si tu workload ejecuta código que necesita acceso a drivers específicos, hardware especializado o extensiones del kernel, unikernel puede ser difícil. Algunos drivers no están disponibles en formato compatible con unikernels. En estos casos, microVM con kernel Linux estándar puede ser la mejor elección.
El coste de no elegir bien
El error más caro que puede cometer un equipo de plataforma hoy es subestimar el cambio de requisitos que la IA agentiva impone. Construir una plataforma basada en contenedores para ejecutar agentes de IA, descubrir que el aislamiento es insuficiente, migrar a microVMs, descubrir que la densidad no escala, migrar a unikernels, y entonces darse cuenta de que el camino más corto habría sido unikernels desde el principio — este ciclo cuesta meses de trabajo de ingeniería y cientos de miles de dólares en infraestructura desperdiciada.
El error opuesto también es común: invertir en unikernels para workloads que no lo necesitan, pagar el coste de complejidad y de tooling, y descubrir que los beneficios no se materializan porque el workload era demasiado simple. En este caso, el coste es menos dramático pero sigue siendo real: tiempo de ingeniería dedicado a una optimización innecesaria.
La decisión correcta depende de hacer las preguntas correctas al principio: ¿qué tipo de código ejecutará el sandbox? ¿Quién lo escribió? ¿Qué pasa si el sandbox es comprometido? ¿Cuántos sandboxes necesito ejecutar concurrentemente? ¿Cuál es la latencia aceptable para crear un sandbox fresco? Si las respuestas a estas preguntas incluyen "código generado por IA", "muchos" y "baja latencia", unikernels o microVMs son probablemente la respuesta correcta.
El futuro del espacio
El espacio de sandboxing para IA está evolucionando rápidamente. Varios startups están construyendo plataformas optimizadas para workloads agentivos. Los proveedores de cloud hyperscale están lanzando servicios de ejecución segura basados en microVMs. La comunidad open source está produciendo herramientas para compilar unikernels sin necesidad de expertise profundo.
La pregunta no es si el sandboxing basado en VM取代 a los contenedores para IA, sino cuándo y para qué workloads. La coexistencia es probable: contenedores para servicios tradicionales, microVMs para workloads agentivos generales, unikernels para workloads agentivos de alta densidad o alta sensibilidad de seguridad. La elección correcta depende del contexto.
Lo que sí está claro es que el primitive de aislamiento es una decisión de arquitectura que debe tomarse al principio del diseño de una plataforma de IA, no al final. Cambiar el primitive después de que el sistema está en producción es costoso y arriesgado. Los equipos que están construyendo plataformas para IA agentiva deberían tomarse el tiempo de evaluar unikernels y microVMs como parte de su diseño inicial, no como una optimización tardía.
Conclusión
Unikraft y el primitive de aislamiento basado en VMs hiperdensas no es una moda pasajera. Es la respuesta correcta a un problema real: la IA agentiva ejecuta código que no fue auditado por humanos, a escalas que el modelo de contenedor no soporta, con requisitos de seguridad que el shared kernel no puede garantizar. Para los equipos que están construyendo plataformas de ejecución agentiva hoy, unikernels y microVMs optimizados representan la frontera del estado del arte.
Si estás diseñando una plataforma de IA y todavía no has evaluado seriamente unikernels o microVMs optimizados, este es el momento. La charla de Felipe Huici es un excelente punto de partida; el framework de Unikraft y otros proyectos similares te dan las herramientas para empezar. La densidad, el cold boot y el TCB no son optimizaciones tardías: son requisitos de arquitectura desde el día uno.
El coste de hacerlo bien desde el principio es una fracción del coste de migrar después. Y la migración, en este espacio, no es opcional: cuando tus workloads agentivos crezcan hasta el punto de necesitar sandboxes hiperdensos, los contenedores te quedarán cortos. Mejor descubrirlo ahora que en producción.