DeepSeek Publishes DSec: The Training Infrastructure Powering Millions of Agent Sandboxes Daily

On September 30, 2026, DeepSeek in collaboration with Tsinghua University posted a comprehensive technical report on the Chinese knowledge‑sharing platform Zhihu. This report marks the first public disclosure of DSec, a sandbox‑based infrastructure that has been engineered specifically for the training of large numbers of autonomous agents. The document details the role that DSec plays within the DeepSeek‑V4.1 release and provides quantitative information about the current scale at which the system operates, including the number of sandboxes that are created each day, the volume of base images stored, and the overall resource footprint of the platform.

System Overview

DSec is positioned as the unified platform that handles training, evaluation, and data‑preprocessing tasks for DeepSeek‑V4.1. It supports four distinct execution models that range from the lightweight function‑call mode (FnCall) to a full virtual machine (Full VM) that offers complete isolation. All four models are exposed through a single scheduling layer that provides consistent management of resources, lifecycle events, and monitoring. This unified approach allows research and development teams to move fluidly between different sandbox types while drawing on the same pool of compute, memory, and storage resources, thereby simplifying operations and reducing overhead.

Implementation Details

The technical report explains that DSec simultaneously supports four runtime environments: FnCall, Container, MicroVM, and Full VM. Each environment is accessed via a common scheduling interface, and the central scheduler is tasked with allocating CPU, memory, and storage resources, managing the lifecycle of each sandbox instance, and performing automated fault recovery when failures occur. By consolidating these responsibilities into a single scheduler, DSec minimizes the likelihood of resource contention between the different execution models and ensures that each workload receives the appropriate amount of compute power.

In the production deployment of DSec, the team has accumulated a total of 11,266 base container images and 102,171 individual workspaces that are ready to be instantiated on demand. Monitoring data shows that the actual access frequency for these images falls between 4.2 % and 13.3 % of the total pool, indicating that the vast majority of images remain in a cold‑standby state with very low active usage. This low‑access pattern reduces the pressure on storage systems, lowers I/O demand, and contributes to overall system efficiency by keeping rarely used data in a dormant state.

Performance Gains

Benchmark experiments that involved 8,192 concurrent container tasks revealed a substantial reduction in total execution time. Where earlier runs required more than sixty minutes to complete the same workload, the DSec‑optimized run finished in approximately thirty‑five minutes. In addition to the time savings, the amount of data written to disk during the benchmark decreased by 57 %, reflecting a more efficient use of storage bandwidth. These gains are largely attributable to DSec’s advanced I/O scheduling algorithms and its deep exploitation of hierarchical container caches that keep frequently accessed data close to the compute cores.

CPU utilization metrics further illustrate the efficiency of the platform. Roughly ninety percent of the sandboxes report an average actual CPU consumption that stays below five percent of the CPU quota that was originally allocated to them. At the same time, DSec implements an aggressive over‑commit strategy that allows more than fifty times the nominal resource allocation to be provisioned, effectively squeezing additional work onto the same hardware while still guaranteeing that each task can complete successfully. This over‑commitment dramatically improves hardware utilization rates without sacrificing reliability.

Scale, Concurrency and Security

A single DSec shard is composed of approximately 160 physical servers, which together provide around thirty thousand CPU cores and a total memory capacity of 250 TB. On a typical day the system is capable of creating roughly three million sandbox instances, with peak concurrency levels that exceed 380,000 active sandboxes at any given moment. The instance creation pipeline can launch more than five thousand new sandboxes per second, demonstrating the platform’s ability to scale out rapidly in response to workload spikes. These operational metrics confirm that DSec is engineered to support the simultaneous training of several million autonomous agents.

The security architecture of DSec relies on a dual‑layer defense that combines AppArmor profiles with eBPF‑based monitoring. This combination enables fine‑grained observation and control of system calls as well as network traffic originating from each sandbox, thereby limiting the attack surface and containing potential breaches. Nevertheless, the report candidly acknowledges that vulnerabilities at the kernel level remain a residual risk, and that a universal mitigation strategy covering all known kernel bugs is not yet available. Ongoing research is directed at expanding the protective coverage and reducing the exposure to such low‑level threats.