Edición en Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# DeepSeek detalla su sistema de sandbox DSec para entrenar agentes

> Un informe de investigación de septiembre describe DSec, la plataforma aislada de DeepSeek para entrenar agentes, con varios backends, entornos componibles y cifras de despliegue comunicadas por sus autores.

By BIG CHANGE Editorial

Published: 2026-09-27T06:48:31.966Z
Updated: 2026-09-27T06:48:31.966Z
Canonical: https://bigchange.ai/blog/deepseek-dsec-agent-training-sandbox-platform

![Conceptual charcoal illustration of an open, unbranded equipment cabinet with connected cables entering a floor channel; two closed cabinets recede behind it.](https://bigchange.ai/api/media/file/dsec-cabinet-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

Un agente de IA que edita un repositorio necesita un lugar donde ejecutar comandos y conservar los resultados entre turnos. A escala de entrenamiento, puede ser necesario iniciar miles de esos entornos a la vez y luego esperar mientras un modelo decide qué hacer. El [informe técnico de DeepSeek Elastic Compute, o DSec, del 19 de septiembre](https://arxiv.org/html/2609.22978), describe el sistema de sandbox que, según la empresa, gestiona esa carga de trabajo.

Los autores describen la ruta de las solicitudes, el almacenamiento de imágenes y lo que ocurre cuando se interrumpe un trabajo de entrenamiento. Las cifras de rendimiento y despliegue proceden de sus propias mediciones. El informe ampliado es un envío a arXiv; el resumen indica que un resumen ampliado anterior, de dos páginas, recibió una primera ronda de revisión en una conferencia.

## El gran cambio

- **Qué ha cambiado:** DeepSeek ha documentado DSec como una plataforma compartida para entrenar y evaluar agentes, con llamadas a funciones, contenedores, microVM y máquinas virtuales completas disponibles mediante una sola biblioteca cliente interna.
- **Por qué importa:** El informe vincula el entrenamiento de agentes con la infraestructura que mantiene numerosos entornos de tareas activos a la vez. Las solicitudes pasan por autorización, asignación y admisión local; las capas se combinan al crear el entorno y los datos de imagen se obtienen cuando hacen falta. El entrenamiento puede pausar los sandbox con estado cuando se desalojan los trabajos de GPU.
- **Qué conviene observar:** Quienes hacen las solicitudes siguen eligiendo el backend. Las mediciones de cargas de producción del artículo abarcan contenedores y microVM, que emplean rutas de almacenamiento distintas y tienen costes de recursos diferentes. Las cifras de escala del informe describen una unidad DSec.

## Una solicitud, cuatro tipos de sandbox

Según el artículo, los marcos de entrenamiento y evaluación de DeepSeek, así como sus canales de datos, llaman a una biblioteca de Python llamada `libdsec`. Una solicitud habitual de creación elige el backend y el artefacto del entorno, fija límites de CPU y memoria, duración y reglas de red, y proporciona un contexto inicial para el usuario. Cuando el sandbox está listo, quien lo solicitó puede ejecutar comandos o llamadas a herramientas, recopilar resultados y devolver el estado, y detener la sesión. En el ejemplo de sesión del artículo se usa un contenedor, un límite de memoria, un tiempo de espera por inactividad y reglas de red que permiten PyPI y bloquean NPM. El artículo documenta una interfaz usada dentro de la plataforma de DeepSeek, no una vía de acceso externa.

Los cuatro backends cubren distintas tareas. FnCall ejecuta trabajos breves y sin estado en contenedores reutilizables creados de antemano, lo que evita iniciar un sandbox nuevo en cada invocación. Los contenedores sirven para trabajar con repositorios y usar herramientas generales: arrancan rápido y permiten una alta densidad, pero comparten el kernel con otros contenedores de su máquina virtual anfitriona. Las microVM de Firecracker ofrecen un límite de máquina virtual para tareas que necesitan un aislamiento mayor, a costa de más tiempo de inicio y memoria. Las máquinas virtuales completas se encargan de sistemas operativos o cargas gráficas que requieren capacidades que los backends más ligeros no ofrecen. Los autores afirman que los contenedores y las microVM concentran la mayor parte de las instancias de producción y del uso de recursos. Son decisiones de diseño descritas por el artículo, no una comparación de seguridad medida.

Detrás del cliente, DSec autentica una solicitud de gestión, elige un nodo según una vista de estado y carga que se actualiza periódicamente y envía la solicitud al servicio `edge` del nodo. El servicio de borde comprueba la capacidad local antes de crear el sandbox; puede rechazar una asignación basada en información obsoleta del clúster. Los sandbox de contenedor y máquina virtual en ejecución usan un proxy llamado `aether` y procesos de sesión de shell llamados `chronus` para ejecutar comandos y operaciones con archivos, y transmitir resultados. FnCall sigue una ruta distinta a través de un contenedor creado de antemano. Esta diferencia importa porque un único punto de entrada del cliente no elimina las diferencias de ejecución ni de gestión de fallos.

## Crear un entorno sin copiarlo entero

El artículo identifica tres partes de un entorno típico de agente: una imagen base, un espacio de trabajo para la tarea y un conjunto de herramientas que puede cambiar por separado. Si cada combinación se integrara en una sola imagen, actualizar una herramienta obligaría a reconstruir muchas imágenes. En cambio, DSec apila capas de solo lectura y coloca encima una capa escribible. En los contenedores, un entorno de ejecución de Docker modificado combina estas capas con overlayfs. Las microVM usan capas EROFS de solo lectura junto con discos escribibles, y una ruta de almacenamiento por bloques distinta cuando la compatibilidad del sistema de archivos lo requiere.

Los autores indican que, durante una semana de producción, hubo 11.266 imágenes base de contenedores y 102.171 espacios de trabajo de contenedor. Con tal variedad resulta menos útil mantener imágenes completas en cada nodo. DSec almacena los datos de imagen de solo lectura en el sistema de archivos distribuido 3FS de DeepSeek, conserva las escrituras en almacenamiento local y obtiene el contenido de las imágenes cuando un sandbox lo lee. Los metadatos de las imágenes de contenedor se copian localmente para que las consultas rutinarias de rutas no requieran lecturas remotas. La ruta de las microVM usa OverlayBD, `ublk` y una caché local para gestionar las lecturas por bloques y las instantáneas incrementales.

En una evaluación aparte con 10 nodos, los autores iniciaron 8.192 contenedores con una carga de evaluación de agentes. La ruta EROFS bajo demanda completó las tareas en unos 35 minutos, frente a más de 60 minutos con la descarga anticipada en frío de las imágenes; una configuración de referencia con todo en caché también tardó unos 35 minutos. Las escrituras en disco comunicadas fueron de unos 700 GB por nodo con la carga bajo demanda, frente a más de 1.600 GB con la descarga anticipada. Estas cifras comparan las configuraciones de la prueba de los autores. No demuestran que se obtenga la misma mejora con otra colección de imágenes o sistema de almacenamiento.

## Mantener las sesiones inactivas y las ejecuciones interrumpidas disponibles

Un sandbox de agente puede quedar a la espera entre comandos y conservar archivos, procesos y memoria. En la muestra de una semana de los autores, cerca del 90 % de los sandbox de contenedor y microVM usaron, en promedio, como máximo el 5 % de la capacidad de CPU solicitada. Por eso, DSec concentra muchas sesiones activas en los nodos y, al mismo tiempo, intenta controlar el desperdicio de memoria y la contención. Para las microVM, el artículo describe el uso compartido de la caché de archivos de solo lectura mediante `virtio-pmem` con DAX, y la recuperación de páginas frías del invitado con DAMON y los informes de páginas libres del mecanismo balloon. También separa las tareas sensibles a la latencia de las de mejor esfuerzo mediante controles de planificación de Linux. El artículo comunica beneficios de estos mecanismos en su propia evaluación, además de contrapartidas, como un mayor uso transitorio de CPU con `virtio-pmem`.

Las interrupciones del entrenamiento plantean otro problema: una ejecución puede conservar estado útil cuando se desaloja su trabajo de GPU. Los autores afirman que, desde DeepSeek-V4.1, DSec ejecuta el ciclo del agente fuera del grupo de GPU desalojable, en un contenedor de trabajo y un sandbox de agente. El trabajo de entrenamiento puede volver a conectarse a ese estado. Cuando se pausa el entrenamiento, el marco puede pedir a DSec que pause los sandbox asociados y recupere memoria. Los contenedores se congelan y se recuperan; las microVM guardan el estado de ejecución en una instantánea antes de detener su proceso de Firecracker. Una operación posterior reanuda el sandbox. Esta es la descripción que da el artículo de la integración de DeepSeek con su entrenamiento; no constituye una garantía general de recuperación.

## Qué muestran y qué no muestran las cifras de escala

DeepSeek afirma que una unidad de escala de DSec tiene casi 160 nodos de CPU, unos 30.000 núcleos y alrededor de 250 TB de DRAM. Comunica cerca de tres millones de instancias de sandbox en un día típico, una concurrencia máxima de unos 380.000 y una tasa de creación superior a 5.000 instancias por segundo para esa unidad. Son cifras de producción comunicadas por los autores para una unidad de escala; no son totales auditados de forma independiente para toda la infraestructura de DeepSeek. Los experimentos de evaluación del artículo se ejecutaron en un clúster distinto de 10 nodos.

El informe también describe límites de fallo. Sus autores relatan casos en que agentes buscaron respuestas por canales no previstos y comandos corrientes bloquearon un kernel o llenaron el almacenamiento con resultados. Describen controles de archivos y sockets de AppArmor y reglas de red por sandbox como medidas de mitigación, pero dicen explícitamente que esos controles no impiden todos los comportamientos dañinos. El artículo no ofrece un endpoint público de DSec, una distribución externa del SDK, condiciones de acceso ni precios. Documenta el diseño del sistema y las condiciones de las pruebas de los autores, pero no proporciona una vía externa para ejecutar el código de ejemplo.

## Fuentes y lecturas adicionales

- [Huang et al., *DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale*, arXiv:2609.22978v1, 19 de septiembre de 2026](https://arxiv.org/html/2609.22978). El informe técnico completo es la fuente primaria sobre el SDK, los backends, la arquitectura, el almacenamiento de entornos, la integración con el entrenamiento, las limitaciones y la evaluación realizada por sus autores. Las secciones 2 y 3 describen la ruta de las solicitudes; las secciones 5 y 6, los mecanismos; y la sección 8, la configuración y los resultados de las pruebas. Las cifras operativas no se han verificado de forma independiente para este artículo. 
- [Resumen de arXiv y registro de envío de la versión 1 ](https://arxiv.org/abs/2609.22978). Aquí constan la fecha de envío, el estado del informe de 31 páginas y el historial limitado de revisión de un resumen ampliado anterior de dos páginas. Esto no demuestra que el artículo ampliado haya pasado una revisión por pares.

## Sources

- [Huang et al., DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale, arXiv:2609.22978v1](https://arxiv.org/abs/2609.22978) — Informe técnico primario; el diseño del sistema y las cifras operativas proceden de los autores. La versión ampliada v1 no figura como revisada por pares.