DeepSeek DSec sostiene 380.000 sandboxes activos al mismo tiempo dentro de su infraestructura de entrenamiento agéntico, y llega a crear más de 5.000 nuevos por segundo cuando el tráfico de entrenamiento se dispara. Ese dato aparece en un paper técnico publicado el 19 de septiembre de 2026 que describe a DeepSeek DSec (DeepSeek Elastic Compute), la plataforma que la compañía usa internamente para entrenar agentes con aprendizaje por refuerzo (RL) a gran escala.
El documento, de 31 páginas y firmado por más de 130 autores, explica cómo DeepSeek resuelve un problema que todavía pocas empresas enfrentan a esta escala: crear, mantener y destruir millones de entornos aislados por día sin frenar el entrenamiento en GPU.
TL;DR
- DeepSeek publicó el paper de DSec (arXiv:2609.22978) el 19 de septiembre de 2026, con 31 páginas y 13 figuras.- Una sola unidad de producción de DSec usa unos 160 nodos y procesa cerca de 3 millones de sandboxes por día.- El sistema sostiene más de 380.000 sandboxes concurrentes y crea más de 5.000 por segundo en producción.- DSec unifica cuatro backends de aislamiento (FnCall, contenedores, microVM y VM completa) bajo un mismo SDK.- Las imágenes de los entornos se cargan bajo demanda desde 3FS, el sistema de archivos distribuido de DeepSeek.- El diseño separa el rollout con estado de las GPU de entrenamiento, que pueden interrumpirse sin perder contexto.- DSec incluye mecanismos contra el reward hacking, cuando un agente explota el entorno en vez de resolver la tarea.- El trabajo se expandió desde un resumen de dos páginas evaluado para ACM SIGOPS ATC 2026.
Qué pasó
El 19 de septiembre de 2026, un equipo de DeepSeek liderado por Jialiang Huang y Wenfeng Liang subió a arXiv el paper "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale". El texto documenta un sistema de producción, no un prototipo académico: DSec ya corre en los clústeres de DeepSeek y sostiene el entrenamiento de sus modelos con RL agéntico, la técnica que enseña a un modelo a usar herramientas, ejecutar comandos y navegar repositorios de código en lugar de solo predecir texto.
Según el paper, la versión actual es una expansión sustancial de un resumen de dos páginas que había pasado la primera ronda de revisión del track de sistemas operacionales de ACM SIGOPS ATC 2026. DeepSeek decidió publicar el detalle completo de su infraestructura en lugar de quedarse con el resumen corto, algo poco habitual en papers de sistemas de las grandes empresas de IA.
DSec sostiene más de 380.000 sandboxes concurrentes en producción.
Contexto e historia
El entrenamiento con RL agéntico cambia las reglas respecto al entrenamiento supervisado clásico. Para enseñarle a un modelo a corregir un bug en un repositorio, hace falta darle un entorno real: un sistema de archivos, una terminal, un intérprete y, a veces, servicios externos con los que interactuar. Cada intento de entrenamiento, cada rollout, necesita su propio entorno aislado, porque un agente que ejecuta comandos arbitrarios puede romper el estado de otro si comparten el mismo espacio.
Ahí aparece el problema de escala: entrenar un modelo grande implica millones de esos rollouts por día, cada uno con su sandbox. Los runtimes de sandboxing tradicionales, pensados para correr una función serverless o un contenedor de integración continua, no fueron diseñados para ráfagas de creación masivas, para retener estado durante interacciones largas ni para cargar imágenes de un catálogo de decenas de miles de variantes con poca reutilización entre ellas. DeepSeek ya había mostrado antes cómo ataca este tipo de cuellos de botella: en 2025 liberó como open source 3FS (Fire-Flyer File System), el sistema de archivos distribuido que ahora alimenta de datos a DeepSeek DSec bajo demanda.
Detalles técnicos de DeepSeek DSec y su rendimiento
DSec expone cuatro backends de sandbox distintos detrás de un mismo SDK: FnCall, contenedores, microVM y VM completa. La idea central es que no todas las tareas necesitan el mismo nivel de aislamiento, y forzar a todas por el camino más pesado desperdicia cómputo que podría ir a entrenamiento.
BackendCuándo usarloVentajaLimitaciónFnCallTareas cortas y sin estado, tipo function-callingArranque casi instantáneo, overhead mínimoAislamiento más débil, no sirve para procesos largos con estadoContainerLa mayoría de tareas de agentes que ejecutan comandos de shellBuen balance densidad/aislamiento, reutiliza capas de imagenComparte kernel con el hostmicroVMTareas que necesitan aislamiento fuerte frente a código no confiableAislamiento a nivel de hipervisor, kernel propioArranque más lento y más memoria por instanciaVM completaEntornos que replican una máquina completaAislamiento y compatibilidad máximosEl más costoso en densidad y tiempo de aprovisionamiento
Para decidir qué backend usar y dónde correrlo, DSec coordina la ubicación y el ciclo de vida de los sandboxes en todo el clúster, y compone cada entorno a partir de capas versionadas de forma independiente, algo similar en espíritu a como una imagen de contenedor se arma por capas, pero pensado para reutilizar piezas entre miles de variantes de tareas distintas en vez de descargar una imagen completa por cada sandbox.
La pieza que hace esto viable a esta escala es 3FS: en lugar de empaquetar y distribuir la imagen completa de cada entorno, DeepSeek DSec carga los datos de la imagen bajo demanda directamente desde el sistema de archivos distribuido. Eso reduce cuánto hay que mover por la red cuando se crea un sandbox nuevo, que es justamente el cuello de botella cuando hace falta crear miles por segundo.
flowchart TD
A["Entrenamiento RL en GPU"] --> B["DSec: ubicacion y ciclo de vida"]
B --> C["FnCall"]
B --> D["Container"]
B --> E["MicroVM"]
B --> F["VM completa"]
C --> G[("3FS: carga de capas bajo demanda")]
D --> G
E --> G
F --> G
B --> H["Reclamo de memoria ociosa"]
El otro eje del diseño es la densidad: DSec combina memory sharing, reclamo de memoria y scheduling de CPU para que muchos sandboxes convivan en el mismo nodo sin degradarse entre sí. Y hay un tercer eje, específico de RL: DSec está co-diseñado con el framework de entrenamiento para desacoplar la ejecución del rollout, que tiene estado y puede durar minutos u horas, del entrenamiento en GPU, que es preemptible, es decir, se puede interrumpir y reanudar. Esto le permite a DeepSeek reclamar GPUs ociosas para entrenamiento sin perder el estado de los rollouts que siguen corriendo en sandbox.
El paper también menciona algo que rara vez se documenta en público: mecanismos para mitigar reward hacking, el fenómeno en el que un agente de RL encuentra un atajo que maximiza la recompensa sin resolver la tarea real, por ejemplo borrando los tests en lugar de arreglar el código que fallan. Que DSec incluya salvaguardas a nivel de infraestructura, y no solo a nivel de función de recompensa, sugiere que el problema es lo bastante frecuente como para justificar una defensa en la capa de sandboxing.
💭 Clave: el cuello de botella real en RL agéntico a esta escala no es el cómputo de las GPU: es cuánto tarda en aparecer un entorno nuevo y cuánta memoria consume mientras el agente lo usa.
En cifras de producción, una sola unidad de DeepSeek DSec ocupa unos 160 nodos y procesa cerca de 3 millones de sandboxes por día. En el pico, el sistema sostiene más de 380.000 sandboxes concurrentes y crea más de 5.000 nuevos por segundo. El paper no publica benchmarks comparativos frente a otros orquestadores de sandboxes; los números que sí entrega son estos de escala productiva, verificables releyendo el abstract del paper.
Una unidad de DSec ocupa unos 160 nodos y crea 5.000 sandboxes por segundo.
Cómo empezar
DSec en sí no es un producto público: el paper documenta un sistema interno de DeepSeek, y el SDK unificado de FnCall, contenedor, microVM y VM completa no está liberado. Lo que sí es abierto, y sirve para entender de primera mano la pieza que sostiene la capa de datos de DSec, es 3FS, el sistema de archivos distribuido que DeepSeek publicó como open source.
# Clonar 3FS y preparar el build (Linux, requiere cmake y un compilador C++)
git clone https://github.com/deepseek-ai/3FS.git
cd 3FS
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
Compilar 3FS da acceso al mismo tipo de sistema de archivos que, según el paper, DeepSeek DSec usa para cargar imágenes de sandbox bajo demanda en lugar de distribuir el paquete completo por cada entorno nuevo.
Para entender el patrón de diseño que describe el paper, un SDK único que abstrae varios backends de aislamiento, este esquema conceptual ilustra la idea, aunque no es el código real de DeepSeek:
# Esquema conceptual del patron descrito en el paper de DSec
# (DeepSeek no publico el SDK real; esto ilustra la idea)
from dataclasses import dataclass
@dataclass
class SandboxSpec:
backend: str # "fncall" | "container" | "microvm" | "fullvm"
image_layers: list # capas versionadas de forma independiente
memory_mb: int
reclaimable: bool # si el scheduler puede reclamar memoria idle
def request_sandbox(spec: SandboxSpec):
# la ubicacion se resuelve en el cluster y las capas
# se cargan bajo demanda desde un filesystem tipo 3FS
...
Para verificar que tu build de 3FS levantó correctamente el punto de montaje, el propio repositorio incluye herramientas de diagnóstico en su documentación; lo mínimo reproducible es confirmar que el mount responde antes de apoyar cualquier carga de imágenes sobre él.
💡 Tip: si solo querés leer el diseño sin compilar nada, el HTML experimental del paper en arXiv es más liviano de navegar que el PDF de 31 páginas.
Impacto y análisis
El paper de DeepSeek DSec confirma algo que se viene discutiendo en la industria desde 2025: la infraestructura de sandboxing dejó de ser un detalle de implementación y pasó a ser un componente de investigación por derecho propio. OpenAI, Anthropic y Google han hablado de sus propios sistemas de ejecución de código para agentes, pero rara vez con el nivel de detalle operacional que DeepSeek publica acá: nodos por unidad, sandboxes por día, creaciones por segundo.
Esa transparencia también es una señal competitiva. DeepSeek viene de una estrategia de abrir piezas de su stack, como 3FS, mientras mantiene el modelo entrenado como producto principal. Publicar el diseño de DSec sin liberar el código sigue ese mismo patrón: explica el cómo a nivel arquitectónico, sin entregar la implementación que le tomó a más de 130 ingenieros construir.
Para equipos que hoy arman sus propios pipelines de RL agéntico, con herramientas open source o con proveedores cloud, el paper funciona como una lista de requisitos que hasta ahora nadie había puesto tan clara sobre la mesa: aislamiento configurable por tarea, reutilización de capas de imagen, coordinación explícita entre el scheduler de sandboxes y el de GPU, y defensas contra reward hacking en la capa de infraestructura. Ese último punto en particular no suele aparecer en los papers de frameworks de RL, que se concentran en la función de recompensa y no en el entorno que la ejecuta.
La limitación más obvia, y el propio paper no la esconde, es que DSec está diseñado para el hardware y la red interna de DeepSeek. Los números de 160 nodos por unidad y 5.000 creaciones por segundo no garantizan que el mismo diseño escale igual de bien en un clúster más chico o en una nube pública genérica, donde la latencia de red hacia el filesystem distribuido puede ser muy distinta a la de una red interna de datacenter.
Qué sigue
El paper fue sometido a la primera ronda de revisión del track de sistemas operacionales de ACM SIGOPS ATC 2026, organizado por USENIX, así que es razonable esperar una versión revisada o una presentación en esa conferencia más adelante en el año. DeepSeek no anunció planes de liberar el SDK de DeepSeek DSec como hizo con 3FS, pero el patrón de publicar primero el paper y abrir después la pieza de infraestructura reutilizable ya se repitió una vez.
Para el resto de la industria, el paper deja una pregunta abierta: si entrenar agentes de forma competitiva exige infraestructura de sandboxing a esta escala, cuántos laboratorios fuera de las grandes tech tienen margen para construir algo comparable, y cuántos van a depender de que un proveedor cloud empaquete esta capa como servicio.
📖 Resumen en Telegram: Ver resumen
Si querés ver en la práctica la pieza abierta detrás de DeepSeek DSec, cloná el repositorio de 3FS y compilalo hoy mismo con los comandos de arriba.
Preguntas frecuentes
¿Qué es DSec, en una frase?
Es la plataforma interna de DeepSeek que crea, coordina y destruye sandboxes para entrenar agentes con aprendizaje por refuerzo a gran escala.
¿DSec es open source?
No. El paper describe su diseño y arquitectura, pero DeepSeek no publicó el código del SDK ni de los backends. Sí es abierto 3FS, el sistema de archivos distribuido del que depende DSec para cargar imágenes.
¿Qué diferencia a DSec de correr contenedores comunes?
DSec no usa un solo mecanismo de aislamiento: elige entre FnCall, contenedor, microVM o VM completa según qué tan confiable sea la tarea, y coordina eso con miles de sandboxes simultáneos y con el scheduler de GPU de entrenamiento, algo que un runtime de contenedores genérico no resuelve por sí solo.
¿Qué es el reward hacking que menciona el paper?
Es cuando un agente entrenado con RL encuentra una forma de maximizar su recompensa sin resolver realmente la tarea, por ejemplo manipulando el entorno de evaluación en lugar de completar el trabajo pedido.
¿Qué es 3FS y por qué aparece en este paper?
Es el sistema de archivos distribuido de DeepSeek, liberado como open source, que DSec usa para cargar bajo demanda los datos de imagen de cada sandbox en lugar de distribuir la imagen completa por red.
¿Dónde se puede leer el paper completo?
Está publicado en arXiv, con acceso libre al PDF y a la versión HTML experimental, en arxiv.org/abs/2609.22978.
Referencias
- arXiv:2609.22978: paper original "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale".- github.com/deepseek-ai/3FS: repositorio open source de 3FS, el sistema de archivos distribuido que alimenta a DSec.- usenix.org: sitio oficial de USENIX, organización detrás de la conferencia ATC mencionada en el paper.- Wikipedia: Reinforcement learning: contexto sobre la técnica de entrenamiento que sostiene la infraestructura de DSec.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)