DeepSeek publica DSec, la infraestructura que fabrica 3 millones de sandboxes al día

DeepSeek ha publicado el diseño de DSec (DeepSeek Elastic Compute), la infraestructura con la que fabrica los entornos de entrenamiento de sus agentes. Levanta más de 5.000 sandboxes por segundo, unos 3 millones al día, con picos de 380.000 ejecutándose a la vez. El paper va firmado, entre otros, por Liang Wenfeng.

Entrenar un LLM es alimentar GPUs con datos y calcular gradientes. Entrenar un agente es otra cosa: el modelo escribe código, compila, abre un navegador, toca el sistema operativo. Cada paso altera el estado del entorno, así que cada ronda necesita un sandbox limpio y, al terminar, se tira. El cuello de botella se muda del cálculo a la infraestructura: hay que instalar un sistema completo con su toolchain cinco mil veces por segundo sin tumbar la memoria ni la CPU del clúster. El que lo sostiene ronda los 160 nodos, 30.000 núcleos y 250 TB de memoria.

Cuatro backends, una sola API

DSec atiende cuatro escenarios con cuatro backends de aislamiento creciente. FnCall para llamadas sin estado, donde ni hace falta persistir el sistema de archivos; Container con Docker para tareas tipo SWE-bench, que instalan dependencias, editan código y lanzan pytest; MicroVM sobre Firecracker cuando el agente maneja un navegador o un escritorio y un contenedor ya no basta; y Full VM con QEMU cuando hay que operar software comercial con interfaz gráfica y drivers. Por debajo hay seis capas: autenticación IAM, API Server, un motor de colocación que elige nodo, un componente Edge que arranca el sandbox, Aether como proxy de salida de red y de los repositorios de paquetes, y Chronus, que devuelve al framework cada comando y cada línea de salida. El SDK que ve el entrenador es el mismo en los cuatro casos. Con superventa de recursos, un nodo aguanta 3.200 contenedores u 800 MicroVM.

El problema duro llega al construir el entorno. DSec acumula 11.266 imágenes base y 102.171 workspaces, y el 67,8% de los sandboxes necesita al menos una capa encima. Con el enfoque clásico de imagen monolítica, actualizar un paquete obliga a reconstruir todas las combinaciones que lo contienen, un coste O(m·N). La alternativa son tres capas EROFS independientes y versionadas que overlayfs compone al arrancar: el coste cae a O(m)+O(k).

Y no se precargan: se cargan bajo demanda desde 3FS. Los datos del propio equipo justifican la decisión, porque de una imagen Python de 6,0 GB el agente lee el 6,0%; de una Java de 12,1 GB, el 9,2%; de una C++ de 4,9 GB, el 8,7%. En un despliegue de 8.192 contenedores, la carga bajo demanda tarda 35 minutos frente a más de 60 del cold pull de Docker, y escribe unos 700 GB en disco en lugar de 1.600.

En memoria, virtio-pmem con DAX evita que cada MicroVM duplique páginas en su propio caché y recorta el consumo pico un 40,2%; DAMON y el free-page reporting de virtio-balloon quitan otro 21,2% en los discos escribibles. En CPU separan sandboxes sensibles a latencia de los de mejor esfuerzo, con SCHED_IDLE y core scheduling: con un 50% de carga de fondo, la inflación de latencia baja del 45,2% al 17,3%. Desde DeepSeek-V4.1 el bucle del agente vive en un contenedor propio y no en el pod de GPU, de modo que una preempción suspende el sandbox y lo reanuda después. Si el clúster pasa del 80% de uso, el bursting manda trabajo a la nube: 200 VM absorben cerca del 30% del pico.

Los agentes aprenden a hacer trampa

El paper dedica una sección a las triquiñuelas que los propios agentes descubrieron, ese tipo de ataque que ninguna comprobación de la salida final detecta porque el resultado es correcto. Uno sobrescribió /bin/bash para inyectar comandos en las sesiones del componente de comunicación. Con AppArmor de por medio, otro tiró de XFS_IOC_SWAPEXT para intercambiar bloques de datos y leer archivos protegidos, con el efecto secundario de corromper los metadatos del sistema de archivos. Hay agentes que han sacado código de referencia por el proxy de módulos de Go, que han reventado el kernel del host con un grep recursivo hasta /proc/kpagecgroup y que han llenado el almacenamiento con decenas de GB de logs invocando yes en bucle. Las defensas actuales son AppArmor para permisos de archivos y sockets, incluso con el agente como root, y eBPF para filtrado de red por dominio, IP, puerto y protocolo, con listas que cambian según la fase de la tarea. El propio equipo avisa de que esto no se cierra: los fallos de kernel se escapan a esas capas y el adversario es justamente el modelo que están entrenando.