Signed by Liang Wenfeng, DeepSeek has released a new paper again.
DeepSeek has released a new research paper.
This time, it focuses on a field rarely noticed by the public yet increasingly restricting the scaling of Agent training: sandbox infrastructure.
Paper title: DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale
Paper link: https://arxiv.org/pdf/2609.22978v1
This is a 31-page full-length system paper, with more than 100 authors including Liang Wenfeng. The paper introduces DSec (DeepSeek Elastic Compute), the production-grade sandbox platform inside DeepSeek for large-scale Agent training and evaluation.
First look at its scale. One DSec production unit consists of approximately 160 CPU nodes, 30,000 CPU cores and about 250 TB DRAM, managing PB-level images and environment layers. On a typical day, it serves around 3 million sandbox instances; at peak time, more than 380,000 sandboxes are online concurrently, with a creation speed exceeding 5,000 instances per second.
More notably, the paper explicitly states: From DeepSeek V3.2 to V4.1, all sandbox workloads for DeepSeek's RL training and evaluation run on DSec.
In other words, what this paper demonstrates is essentially the "training ground" DeepSeek built for its models in the Agentic RL era.
When the training scale reaches hundreds of thousands of concurrent Agents, a seemingly simple problem quickly becomes tricky: Where on earth can so many Agents run?
Agents are getting more capable of handling tasks,
but the training system can no longer keep up first
For traditional large models, the core work of one inference is to generate Tokens. For Agents, the model starts to actually "take actions": open code repositories, search files, call tools, run commands, modify code, execute tests, and one round of task may last for tens of minutes or even several hours.
In the reinforcement learning training phase, these operations need to be executed in a real environment. Each Agent requires an independent sandbox equipped with code, dependencies, testing tools and running services; the files modified and processes started by the Agent also need to be continuously retained across multiple rounds of interactions.
As the scale expands, pressure is quickly transmitted from the model side to the infrastructure side.
DeepSeek observes that one training task may instantly apply for 32,000 sandboxes. These environments also present a very special resource usage pattern: long lifecycle, but idle for most of the time.
Statistics from the paper show that about 90% of Containers and microVMs have an average CPU usage of less than 5% of the allocated resources. Meanwhile, the median lifecycle of Containers reaches 17.4 minutes, and that of microVMs is 15.5 minutes; at p99, both will last for more than three hours.
The reason is not hard to understand. Agents often stay in the loop of "model thinking — executing a few commands — waiting for model output again". As a result, hundreds of thousands of execution environments may hang in the cluster at the same time, occupying memory and state quietly for most of the time, and suddenly start running tasks together at a certain moment.
This type of workload raises a new challenge for traditional computing platforms: How to keep hundreds of thousands of stateful execution environments online for a long time, while supporting instantaneous burst requirements for instance creation and computing?
DSec is exactly the infrastructure DeepSeek built to solve this problem.
Four types of Sandboxes to accommodate increasingly diverse Agent tasks
Agents are capable of handling more and more types of work, so it is impossible to use a single solution to cover all execution environments. Therefore, DSec provides four types of execution backends: FnCall, Container, MicroVM and FullVM.
The lightest FnCall is suitable for short tasks such as Online Judge, code compilation, and GPU Kernel execution; software engineering and general tool calls mainly run in Containers, which feature fast startup and high deployment density; tasks requiring stronger isolation are assigned to Firecracker-based microVMs; scenarios relying on a full operating system such as Android, GUI and graphics rendering use FullVM instead.
The four types of environments are uniformly connected to the same set of SDK and lifecycle management system. For upper-layer Agents, they still face a unified set of interfaces; the bottom layer can select the appropriate operating environment according to the characteristics of the task.
Unifying interfaces is relatively easy to achieve. The real tricky part is how to create, run and save the state of hundreds of thousands of such environments at the same time.
Hundreds of thousands of Sandboxes,
how does DeepSeek make them run properly?
Thousands of Sandboxes flood in per second, the scheduling system first faces the peak load
The scheduling link of DSec is not complicated.
After the user submits a request, the system first completes identity and permission checks, then the Placement Engine finds appropriate nodes according to the cluster load. After the task falls to the machine, the local component continues to check the capacity, and then creates a Container, microVM or other execution environment. During operation, another set of components is responsible for maintaining the Session, handling command execution, file access, HTTP requests and streaming I/O.
The difficulty lies in the scale. At the peak of DeepSeek's production cluster, more than 5,000 Sandboxes need to be created every second. The number of concurrent online instances of a single Production Unit exceeds 380,000. At this speed, how to distribute environment images quickly becomes a bottleneck.
According to the statistics of the paper, the total amount of active environment Artifacts within one week exceeds 130 TB. Moreover, these images are highly scattered: the median number of nodes using one Container Image is only 3; the number is even lower for microVM Image, with a median of only 1. This means that many environments may only be used once or twice after being downloaded to the machine.
If every time a Sandbox is started, several GB or even more than ten GB of images are fully pulled, the network, disk and startup time overhead will increase rapidly.
Therefore, DSec stores images on 3FS, DeepSeek's self-developed distributed file system, and reads data on demand when actually running.
Behind this choice, there is another very critical data.
For an image of several GB, the Agent may only access hundreds of MB of it
DeepSeek analyzed the actual accessed data volume of different programming environments. The results show that after an Agent completes the entire task, it often only touches a small part of the image: about 8.7% for C++ environment, 13.3% for Go, 9.2% for Java, 6.0% for Python, and even only 4.2% for JavaScript. It is obviously wasteful to download the entire image completely.
Therefore, DSec adopts On-demand Loading: Containers use EROFS, microVMs use EROFS with OverlayBD, and only fetch the required data block from 3FS when it is needed.
This is similar to watching online videos. In the past, you had to download the whole movie before playing it; now you only read the part you need at the moment. The files that the Agent never accesses will not generate corresponding network and disk overhead.
This design brings quite obvious benefits in subsequent experiments.
With too many environments, DeepSeek splits them into "building blocks"
A large number of images bring another trouble: the combination of environments is becoming more and more diverse.
In one Agent task, the basic operating system, code repository, testing tools and various dependencies usually exist at the same time. When you switch to another task, the Workspace changes; when you upgrade the toolchain, the Toolkit also changes. If each combination is saved as a complete image, the update cost will expand rapidly.
DSec splits one environment into multiple layers: Base Image, Workspace, Toolkit, and the top writable layer.
Base Image provides the basic system, Workspace stores code and task data, Toolkit saves the toolchain. Modifications generated during the running of the Agent are written into its own Writable Layer. Different layers can be updated independently, and then combined into a complete file system through OverlayFS.
The paper gives a very intuitive change in complexity: assuming there are N environments, if you update m Base Images, the reconstruction cost can be reduced from O(m・N) to O(m); if you update k Toolkits, the cost also drops from O(k・N) to O(k).
When the number of training environments reaches tens of thousands or even hundreds of thousands, this difference will directly affect the construction time, storage and distribution cost.
One machine hosts 3200 Containers, the problem becomes "how to avoid running out of memory"
As mentioned earlier, Agent Sandbox has a very special feature: huge quantity, while CPU is often idle. This leaves room for DSec — oversubscription deployment.
DeepSeek has achieved stable operation in the production environment: at least 3200 Containers or 800 microVMs on a single node. The paper emphasizes that this is only a practically verified running point, and the system upper limit has not been touched yet.
CPU is relatively easy to handle, but memory is more troublesome, especially for microVMs. The same file may be cached once on the host machine, and then cached separately inside each virtual machine. When hundreds of VMs are running, the same data is very likely to be occupied repeatedly.
DSec uses two sets of mechanisms:
The first set is virtio-pmem + DAX. Multiple microVMs can share the same Page Cache on the host, reducing duplicate file pages.
The second set is DAMON + virtio-balloon Free Page Reporting. The system continuously monitors which memory pages have not been accessed for a long time, and gradually reclaims cold data; the idle memory in the Guest will also be returned to the Host.
The goal is very clear: more Sandboxes can be hosted, and idle memory should be reclaimed as much as possible.
CPU is idle, but the Agent cannot be stuck when it starts to run
High-density deployment brings another problem: hundreds of thousands of Sandboxes are usually quiet, but once they start executing, CPU competition will suddenly become intense. Some Agents are very sensitive to response time, such as chess game tasks, where each step has a strict time budget.
Therefore, DSec divides workloads into two categories: Latency-Sensitive (LS) and Best-Effort (BE).
Background BE tasks use Linux's SCHED_IDLE to yield more CPU resources; for latency-sensitive LS workloads, Core Scheduling is used to reduce resource interference on the same physical core.
This set of mechanisms ultimately solves a very practical balance: host as many Sandboxes as possible on the same machine, while avoiding obvious slowdown of Agents that are actually running tasks.
