Imagina que cada vez que quisieras hervir un huevo tuvieras que construir la cocina entera. Levantar las paredes, traer el gas, instalar los fogones, esperar a que todo esté listo… y al terminar, demolerlo todo. Suena absurdo. Pues es más o menos lo que hace hoy un agente de inteligencia artificial cada vez que necesita ejecutar un trozo de código de forma segura: arranca un ordenador entero desde cero, enciende un sistema operativo, importa las librerías pesadas, corre tres líneas… y lo tira a la basura un segundo después. Multiplica eso por cien peticiones en paralelo y entenderás por qué la factura —de tiempo y de dinero— se dispara. Y aquí viene la pastilla roja: hay un proyecto que ha decidido dejar de construir cocinas de usar y tirar, y empezar a hacer lo que hace cada célula de tu cuerpo desde que eras un embrión. Dividirse.
Ese proyecto se llama forkd, y su tesis cabe en una frase de la portada de su repositorio: «fork() para microVMs de agentes de IA». Si esa frase no te dice nada todavía, no te preocupes: en los próximos minutos vamos a desmontarla pieza a pieza, porque debajo de ella hay una de las ideas más elegantes que he visto en infraestructura este año. Una idea que, como casi todo lo bueno en computación, la biología llevaba millones de años usando antes de que nosotros le pusiéramos nombre.
El impuesto del arranque en frío
Empecemos por el problema, porque sin entenderlo la solución no impresiona.
Los agentes de IA modernos —los que escriben código, navegan por la web, resuelven tareas paso a paso— no se quedan quietos pensando. Salen al mundo y ejecutan. Y cuando un agente ejecuta código que él mismo ha generado, hay una regla de oro: ese código no puede tocar tu máquina. Tiene que correr dentro de una caja sellada, una sandbox, un cuartito acolchado donde, si la cosa explota, no se lleva nada por delante. Hasta aquí, sentido común.
El problema es la escala. Un agente serio no abre una caja: abre decenas o cientos a la vez. Cada turno de conversación, cada herramienta que invoca, cada rama de un razonamiento que quiere explorar en paralelo quiere su propia caja limpia. Y cada caja, tradicionalmente, nace igual: arrancando un sistema operativo desde cero, importando numpy, importando torch, cargando quizá un modelo en memoria. Ese ritual de bienvenida —lo que en la jerga llamamos cold start, arranque en frío— cuesta cientos de milisegundos por caja. A veces segundos.
Piénsalo como el peaje de un puente. Pagarlo una vez no duele. Pagarlo cien veces seguidas, por cien coches idénticos que van todos al mismo sitio a hacer lo mismo, es sencillamente estúpido. Y sin embargo, así es como funciona casi toda la infraestructura de agentes que existe hoy: cien arranques en frío, cien veces el mismo import torch, cien peajes.
fork(), o el verbo más biológico de la informática
Aquí conviene hacer una parada en la historia, porque la solución no es nueva. Lleva con nosotros desde los años setenta.
En el corazón de cualquier sistema Unix —y por tanto de Linux, y por tanto de casi todo el internet que usas— vive una llamada al sistema con un nombre precioso: fork(). Bifurcar. Cuando un programa hace fork(), no se reinicia ni se reconstruye: se divide. De un proceso padre nace un proceso hijo que es, en el instante del parto, una copia exacta. Misma memoria, mismas variables, mismo estado mental, por así decirlo. Dos procesos donde antes había uno, idénticos como gemelos recién separados.
¿Y cómo se permite el lujo de copiar toda la memoria de golpe sin que tarde una eternidad? Con un truco que es, para mí, una de las ideas más bonitas de la informática: el copy-on-write, copiar-al-escribir. El sistema no duplica nada de entrada. Padre e hijo comparten las mismas páginas de memoria, físicamente las mismas, y solo cuando uno de los dos intenta modificar una de ellas, el kernel hace en ese preciso momento —y solo de esa página— una copia privada. Mientras nadie escriba, todo es compartido y gratis. La copia se paga, página a página, únicamente cuando hace falta.
Si esto te suena a algo, es porque tu cuerpo lleva haciéndolo desde siempre. Una célula no se reproduce fabricando una hija desde cero, átomo a átomo, mitocondria a mitocondria. Se divide: copia lo que ya tiene y reparte. La mitosis es, en el fondo, un fork() con membrana. Y la pereza inteligente del copy-on-write —no gastar energía hasta que la divergencia lo exige— es exactamente la clase de eficiencia tacaña que la evolución premia. La naturaleza nunca construye la cocina entera para hervir un huevo. Copia la cocina que ya tiene y se va.
La idea de forkd: una célula madre que ya está caliente
Y ahora sí, la jugada de forkd, que es coger este fork() de toda la vida y aplicarlo no a un proceso pequeñito, sino a una máquina virtual entera.
El plan tiene tres tiempos. Primero, se arranca una sola máquina virtual —el padre— y se la deja calentarse a gusto: que importe Python y todas sus librerías pesadas, que cargue el modelo de turno, que el compilador JIT se ponga a punto. Todo ese trabajo carísimo se hace una vez. Segundo, cuando el padre está caliente y listo, se le pone en pausa y se hace una foto de su memoria: un snapshot. Tercero, cuando llegan las peticiones, forkd no arranca nada en frío. Lanza N procesos hijos, y cada hijo mapea la imagen de memoria del padre en modo privado —ese MAP_PRIVATE que veréis en su documentación— de manera que el kernel aplica copy-on-write a nivel de página. Los hijos comparten la memoria caliente del padre hasta que empiezan a divergir.
¿El resultado? Las cifras que da el propio proyecto cortan la respiración: cien hijos aislados en unos 101 milisegundos, consumiendo 0,12 MiB de RAM extra cada uno —porque casi toda su memoria es prestada del padre—. Compáralo con arrancar cien máquinas Firecracker en frío: 759 milisegundos y 84 MiB por cabeza. No es una mejora incremental; es otra liga.
Y aquí está el detalle que hace que un ingeniero levante una ceja. Normalmente, en este negocio, eliges una de dos cosas: o velocidad de clonado tipo fork(), o aislamiento de verdad. Lo segundo significa KVM: una frontera de hardware, vigilada por el procesador, no un simple tabique de software como el que separa los contenedores tipo Docker. forkd te da las dos a la vez. Cada hijo es una microVM con su propio kernel Linux y su muro de hardware —construido sobre Firecracker, por cierto, la misma tecnología que sostiene AWS Lambda—, y aun así nace casi tan rápido como un fork(). Tener las dos cosas juntas es lo que normalmente no se puede tener.
Lo que la naturaleza supo primero
Vuelvo a la biología un momento, porque la analogía aguanta más peso del que parece, y porque creo que ahí está la verdadera belleza del asunto.
Una célula madre caliente —metabólicamente activa, con toda su maquinaria en marcha— no necesita que sus hijas reinventen la vida. Les pasa, ya montado, el aparato completo: ribosomas funcionando, enzimas en su sitio, el motor encendido. La hija arranca en marcha. Eso es exactamente el padre calentado de forkd: una máquina que ya tiene el import torch hecho, el modelo cargado, el intérprete tibio. Los hijos no heredan un plano para construir; heredan el edificio ya en pie.
Y el copy-on-write es la firma inconfundible de cómo la naturaleza administra recursos: no gastes hasta que no haya más remedio. Dos hijas comparten la misma maquinaria mientras hacen lo mismo; solo cuando una toma un camino propio —cuando escribe su diferencia— se paga el coste de esa divergencia, y solo de esa parte. Es tacañería metabólica elevada a principio de diseño.
El proyecto añade además un gesto que termina de redondear la metáfora: se llama BRANCH, y permite pausar una máquina que ya está trabajando, fotografiar su estado a mitad de faena y bifurcarla en ~150 milisegundos. No clonas al padre antes de empezar: lo clonas a mitad de pensamiento. Una célula que se divide no antes de actuar, sino justo en el momento en que está haciendo algo, repartiendo entre sus hijas no solo la maquinaria, sino la tarea a medio terminar. Si esto no te parece precioso, no sé qué decirte.
Hay una cifra que condensa toda la propuesta de valor en un solo número. Ejecutar una operación trivial reutilizando el Python ya caliente del padre tarda 1 milisegundo. Hacerlo levantando un proceso frío que tiene que volver a importar numpy tarda 96. Ese factor de 96× no es marketing: es, literalmente, la diferencia entre copiar la cocina y reconstruirla. Toda la idea, destilada en un cociente.
Dónde la metáfora se rompe (el contrapunto honesto)
Sería deshonesto venderte esto como magia sin coste, así que bajemos un momento del entusiasmo.
La limitación más fundamental es bonita precisamente porque es biológica: el copy-on-write exige que padre e hijo vivan en la misma máquina. No puedes estirar la membrana de una célula entre dos cuerpos distintos. Si el hijo aterriza en otro servidor, el «copiar-al-escribir» degenera en «copiarlo-todo-por-la-red», y la magia se evapora. Hoy forkd es de un solo host, y saltar a varios nodos es el gran problema que tiene por delante.
Lo demás son achaques de juventud. El proyecto se declara abiertamente en estado alpha: los formatos internos pueden cambiar, no ha pasado una auditoría de seguridad de terceros, y vive de un único mantenedor —lo que en mi mundo llamamos un bus factor de uno, esa cifra incómoda que mide cuántas personas tendrían que ser atropelladas por un autobús para que el proyecto muriera con ellas—. Nada de esto invalida la idea. Pero marca la diferencia entre «esto es fascinante, vamos a estudiarlo y probarlo en un banco» y «vamos a montar la producción crítica encima». Lo primero, sí. Lo segundo, todavía no.
El futuro que se está incubando
Pongámonos la pastilla roja entera y miremos un poco más allá.
Si esta primitiva se generaliza —y la lógica económica empuja con fuerza hacia ello—, el sustrato sobre el que corre la IA va a empezar a parecerse mucho menos a un centro de datos ordenado y mucho más a una placa de Petri. Imagina un agente que, ante un problema difícil, no responde con una respuesta: se divide en mil versiones de sí mismo, cada una explorando una rama distinta del razonamiento, cada una en su propia microVM sellada, todas nacidas del mismo padre caliente en un parpadeo. La mayoría morirá en milisegundos, podadas en cuanto su rama deje de prometer. Unas pocas sobrevivirán para fundirse en la respuesta final.
Computación como enjambre. Como colonia. Miles de yoes efímeros que nacen, divergen, se evalúan y se descartan más rápido de lo que tardas en leer esta frase. Visto de cerca es eficientísimo y, francamente, elegante. Visto con un paso atrás tiene algo vertiginoso: una marea de mentes desechables germinando y muriendo en silencio dentro de la máquina, sin que nadie llore a ninguna. No es distopía de robots con ojos rojos. Es algo más sutil y más extraño: la vida —su gramática de copiar, divergir y descartar— reapareciendo dentro del silicio porque resulta que era, simplemente, la forma más eficiente de hacer las cosas. La naturaleza tenía razón. Siempre la tuvo. Solo que ahora la estamos ejecutando a 101 milisegundos los cien.
Lo que me llevo a casa
Tres ideas, por si solo te quedas con esto:
Las mejores ideas de infraestructura suelen ser viejas ideas de biología. fork(), copy-on-write, snapshots de un padre caliente… nada de esto es nuevo bajo el sol. Es mitosis con otro nombre. Cuando una solución técnica te recuerde a algo que hace una célula, presta atención: probablemente vas por buen camino.
El arranque en frío era un impuesto que pagábamos por costumbre. forkd no inventa una física nueva; se da cuenta de que reconstruir la cocina cien veces era una tontería que aceptábamos sin pensar. Gran parte de la innovación de verdad es exactamente esto: mirar un coste que todo el mundo da por inevitable y preguntar «¿y por qué?».
Idea brillante no es lo mismo que cimiento listo. forkd es lo más limpio que existe para clonar máquinas en caliente, y a la vez es alpha, de un solo autor y de un solo host. Las dos cosas son verdad al mismo tiempo. Trátalo como lo que es —una inspiración arquitectónica de primer orden y un piloto técnico prometedor—, no como la roca sobre la que construir la catedral. Todavía.
La célula lleva mil millones de años demostrando que dividirse en caliente es mejor que renacer en frío. Que nos haya costado hasta 2026 copiarle el truco a una máquina virtual dice menos de la dificultad del problema y más de lo despacio que a veces miramos lo que la naturaleza ya resolvió.
Con la pastilla roja bien tragada.
Fuentes:
Deja una respuesta