DeepSeek Moves Agent Training into the Sandbox

As of September 23, DeepSeek’s latest publicly available papers and technical materials have revealed an infrastructure system specifically designed for Agent training and evaluation: DeepSeek Elastic Compute, or DSec.

The system’s most notable metrics are as follows: it can generate more than 5,000 sandboxes per second, create approximately 3 million per day, and run up to 380,000 sandbox instances concurrently. Supporting this is a cluster comprising approximately 160 nodes, 30,000 CPU cores, and 250 TB of memory.

This is not another improvement to model architecture, nor is it a simple iteration on training techniques. What DSec actually addresses is how to provide Agents with a sufficient number of fast, mutually isolated execution environments when they need to write code, compile projects, launch browsers, install software, or even operate a complete operating system.

In other words, DeepSeek is moving Agent training from “having models answer questions” toward “having models act in a real world.”

In Agent Training, the Challenge Has Shifted from Models to Environments

In traditional language-model training, the data is usually a piece of text, a set of questions and answers, or a reasoning trajectory. After the model generates an answer, the system calculates the loss and then continues updating the parameters.

Agent training is completely different.

A coding Agent may first need to read a directory, modify code, run tests, inspect error messages, install dependencies, recompile, and finally submit a patch. A browser Agent, meanwhile, may need to open a webpage, click buttons, fill out forms, and determine its next action based on changes to the page.

Every tool call changes the state of the environment. Files may be overwritten, processes may crash, dependencies may conflict, and network requests may produce side effects. A failed Agent trajectory cannot simply be rolled back by removing a few pieces of text; the current environment must be discarded and a clean sandbox recreated.

As a result, the infrastructure for Agent training is more like a gigantic experimental facility: the model is the experimenter, the sandbox is the laboratory, and the training system must continuously launch new experiments, record every operation, reclaim failed environments, and feed the results back to the model.

If only a few dozen sandboxes can be launched per second, training will quickly encounter a bottleneck. The model may be ready, but there will not be enough laboratories.

The value of DSec lies in turning this laboratory into a production system capable of large-scale elastic expansion.

The First Challenge: Everything Can No Longer Be Packaged into a Single Image

Traditional Docker environments typically package the base system, code workspace, and tool dependencies into an image. This approach is simple and straightforward at a small scale, but in Agent training, the number of environment combinations can rapidly explode.

According to the paper, the DSec container backend uses a total of 11,266 base images and 102,171 workspaces. Among them, 67.8% of the sandboxes need to layer at least one additional workspace or tool package on top of the base image.

If composited images were still used, upgrading a single tool package could require rebuilding every image that references it. Assuming there are m tool packages and N image combinations, the maintenance cost would grow roughly with the number of combinations, approximately O(m·N).

DSec addresses this by decomposing the runtime environment into three independent, read-only image layers:

1. Base image: the operating system and runtime environment;
2. Workspace image: code, project files, and task data;
3. Tool-package image: compilers, Python packages, browsers, and other dependencies.

These three layers are versioned separately using the EROFS read-only file system and overlaid on demand through OverlayFS when a sandbox starts. When a tool package is updated, only the tool-package layer needs to be updated; all combination environments do not need to be rebuilt. The maintenance cost therefore decreases from O(m·N) to something closer to O(m) + O(k).

This may appear to be a file-system-level optimization, but it is critical for Agent training. Training environments are not composed of dozens of combinations, but tens or even hundreds of thousands. The more independent the image layers are, the higher the environment reuse rate, and the easier updates and rollbacks become.

The Second Challenge: Images Are Too Large, but Agents Do Not Use Most of Them

After the environment is split into layers, another problem remains: how should these images be delivered to the target nodes?

The most direct solution is to pull the complete images onto every machine in advance. However, statistics from DSec’s actual runtime data show that most image contents are never accessed in practice.

• Python container images average approximately 6.0 GB, of which Agents actually read about 6.0%;
• Java container images average approximately 12.1 GB, of which about 9.2% is actually read;
• C++ container images average approximately 4.9 GB, of which about 8.7% is actually read.

In other words, fully caching images in advance means moving more than 90% of potentially unused data onto the nodes before it is needed. As the cluster grows, the network, disks, and caches are all slowed down by this “unused content.”

DSec adopts a strategy closer to on-demand loading: when a sandbox starts, it first prepares the metadata and necessary files. Only when execution reaches a particular path or a particular file is read does the system retrieve the corresponding data from the distributed file system.

The logic is similar to streaming video: there is no need to download an entire movie in advance; instead, the next segment is loaded as playback reaches it. For Agents, many tasks touch only a small portion of the files in an environment, so this approach can significantly reduce startup latency and network traffic.

DSec runs on DeepSeek’s internally developed 3FS distributed file system. The file system is not merely a storage backend; it also directly participates in rapid sandbox creation, image distribution, and environment reuse.

Four Sandbox Foundations for Different Risk Levels

DSec does not force every task to use the same execution environment. Instead, it provides four types of backends:

• Function Call: for lightweight, stateless function calls, with the lowest resource overhead;
• Container: Docker-compatible and suitable for routine code execution and tool calls;
• MicroVM: based on Firecracker, providing stronger virtual-machine-level isolation;
• FullVM: based on QEMU, capable of running arbitrary guest operating systems and suitable for tasks requiring a complete operating system.

This design has strong practical significance. A task that only needs to execute a simple Python function has no need to launch a complete virtual machine. However, if an Agent needs to install kernel modules, run untrusted code, or simulate a real server environment, container isolation may be insufficient, requiring a MicroVM or even a FullVM.

For upper-layer training frameworks, the four backends are uniformly encapsulated in the same Python SDK. Operations such as creating a sandbox, executing commands, reading output, and destroying instances use a consistent invocation method, while the underlying isolation level is determined by task requirements and scheduling policies.

This abstraction allows the training system to make dynamic trade-offs between performance and security, rather than adopting the most expensive isolation solution for every task.

A Single Node Can Host Up to 3,200 Containers

When the number of sandboxes reaches hundreds of thousands, the launch mechanism is only the first step. The real challenge is scheduling.

DSec divides the entire pipeline into multiple components. After the training framework sends a creation request, the request first passes through IAM authentication and authorization before entering the API Server. The scheduling engine, Placement Engine, selects a target node based on CPU, memory, cache, and backend type. The Edge component on the node is responsible for actually launching the sandbox.

Network egress and package-management requests from the sandboxes are uniformly proxied by Aether. Commands executed by the Agent inside the sandbox, along with every line of output, are sent back to the training framework through the Chronus communication component. This allows the training system to continuously obtain complete Agent trajectories and determine the next feedback or reward.

In terms of resource utilization, DSec also uses resource overcommitment and high-density deployment: a single node can host up to approximately 3,200 containers or approximately 800 MicroVMs simultaneously.

This indicates that DeepSeek’s goal is not to give every Agent an exclusively allocated machine, but to compress as many short-lived, low-average-utilization sandboxes as possible onto the same pool of physical resources.

Of course, high-density deployment does not mean that resource requirements are low. A cluster with 30,000 CPU cores and 250 TB of memory already shows that the infrastructure costs of Agent training are rapidly approaching those of an independent cloud-computing platform.

The Key to DSec Is Not Speed, but Making Training Reproducible

When many people see “5,000 sandboxes per second,” their first reaction is to focus on throughput. For Agent training, however, throughput is only a surface-level metric. What truly matters is environment consistency and trajectory replayability.

If the dependency versions, network state, or tool-returned results differ between tasks, it becomes difficult to compare model performance. The training system also cannot determine whether a success resulted from the model’s capabilities or simply from the environment happening not to fail.

A sandbox platform must provide more than process isolation. It must also include:

• File-system isolation;
• Network egress control;
• CPU, memory, and disk quotas;
• Environment snapshots and restoration;
• Command-level logging;
• Task replay;
• Hierarchical permission management;
• Rapid reclamation of failed environments.

This is also why Agent security cannot rely solely on prompts or input filtering. A model with tool-calling capabilities is essentially an automated engineer with unstable permissions: it may delete files, modify configurations, access external networks, or even carry malicious instructions into subsequent tasks.

The purpose of a sandbox is not to make the model more intelligent, but to ensure that when the model makes a mistake, the error remains within a controllable scope.

Implications for the Industry: Agent Training Is Becoming “Systems Engineering”

The signal from DSec is clear: competition in Agent capabilities is no longer limited to model parameters, context length, and leaderboard scores.

In the future, whether an Agent can be deployed successfully will depend on at least four areas:

1. Model capabilities: whether it can understand tasks, plan steps, and invoke tools;
2. Environment coverage: whether it can provide browsers, code repositories, databases, terminals, and complete operating systems;
3. Execution efficiency: whether it can launch large numbers of independent environments with low latency;
4. Security and evaluation: whether it can record, replay, and isolate every action taken by an Agent.

The second through fourth areas were often treated as application-layer concerns in the past. They are now becoming core infrastructure for model companies.

This also explains why DeepSeek is investing substantial engineering resources in sandbox scheduling, image distribution, and file-system optimization. Without a high-throughput execution environment, reinforcement learning and online distillation would struggle to obtain enough realistic Agent trajectories.

One point should nevertheless be made clear: 5,000 sandboxes per second does not mean a 5,000-fold improvement in model capability. It means that the training system has achieved higher experimental throughput. The final results still depend on task design, reward functions, data quality, and the model itself.

For developers, what is more worth learning from DSec is its architectural approach rather than simply copying a particular number: environment layering, on-demand loading, multi-level isolation, unified abstraction, and replayable execution will gradually become standard components of Agent platforms.

At present, OpenAI Hub already supports unified access to major models including GPT, Claude, Gemini, and DeepSeek. For teams building Agent evaluation systems or automated workflows, model integration can initially be completed through interfaces compatible with the OpenAI format. However, once they move into large-scale training and high-risk execution, sandboxing, permissions, and trajectory systems will still need to be built separately.

What DeepSeek’s paper truly makes public is not merely a system capable of launching 5,000 environments per second, but a broader conclusion: the next competition in Agents will begin outside the model itself.