On 23 September the Chinese lab DeepSeek made public a paper bearing founder Liang Wenfeng among its more than 130 authors, submitted on 19 September. The paper gives the first full technical account of DSec, short for DeepSeek Elastic Compute, the sandbox platform that trains AI agents at scale.
DSec first appeared in the DeepSeek V4 technical report, where it serves as the sandbox for agent training so that large-scale agent runs stay stable. The paper states that from DeepSeek V3.2 through V4.1 every reinforcement-learning training and evaluation workload ran on DSec, and opening the details now amounts to handing over the secret recipe.
Why agent training needs so many sandboxes
Classic large-language-model training can centre on static inputs, outputs and reward signals, but agent training is different. An agent must enter a real environment and actually run tasks such as checking code, calling tools, running commands and editing files. Each step can change the environment, and the next step builds on the result.
That means researchers must keep a large set of working environments that look close to real machines, can install dependencies and run software, and can be reset to a clean state for the next rollout. These sandboxes are many and heavy. The paper notes one training task once pulled up 32,000 sandboxes at once, and because an agent often waits between steps, the central processing units sit idle while memory and writable state stay reserved.
The old pattern of start a container, finish a task, could no longer hold. DSec exists to solve bulk sandbox creation, scheduling, environment copying, state saving, pause and resume, and security isolation at once.
Four environment backends under one platform
Agent tasks vary so widely that no single spec fits. A light task may need only a function call, a software-engineering task needs a full Linux user space, security work needs stronger isolation, and driving commercial software needs something close to a whole computer. DSec offers four backends, FnCall, container, Firecracker microVM and full virtual machine, covering from short function calls to a complete operating system.
A training framework need not care whether the backend is a container or a virtual machine. Through a Python software development kit called libdsec it creates sandboxes, runs commands and collects results without adapting to each environment type.
All four backends run under one scheduler. The platform checks identity and rights, then picks a node by cluster load, and an edge component on the node builds the sandbox. Aether and Chronus link the platform to the execution inside the sandbox, while image data comes from the 3FS file system on demand.
Copying tens of thousands of environments fast
Agent environments are not just many, they combine in complex ways. One production week logged 11,266 base images, 102,171 workspaces and 103 toolkits on the container backend, and 67.8 per cent of sandboxes added a workspace or toolkit on top of the base image.
DSec splits the base image, workspace and toolkit into three independent read-only layers, then combines them through overlay at sandbox start. When one component changes, only that layer updates. Image delivery is on-demand: the paper found that sandboxes actually read only 4.2 to 13.3 per cent of a full image, so data sits on 3FS and loads as needed while metadata is prefetched locally.
The gain is concrete. Deploying 8,192 containers in a burst took 35 minutes with on-demand loading, against over 60 minutes for a cold Docker pull, and per-node disk writes fell from about 1,600 gigabytes to about 700 gigabytes. DSec can also let an agent build the environment, then snapshot the difference and reuse it as a new sandbox.
Moving rollout off the GPU
In earlier designs the agent’s inference and rollout shared the GPU pod with model training, so a preempted GPU job also broke the running rollout. From V4.1 DeepSeek moved rollout out of the GPU training environment and onto DSec, where the agent sandbox runs DeepSeek Harness and a worker container runs the task, neither needing GPU resources. When GPU training is preempted, the rollout state stays intact.
When cluster capacity runs low, DSec can expand to the cloud. Once utilisation passes 80 per cent, eligible sandboxes move to cloud virtual machines. DeepSeek pre-staged about 30 terabytes of deduped images, about 70 per cent of which cloud container tasks actually touch, and in production 200 cloud virtual machines absorbed about 30 per cent of peak load.
Real environments bring real risk
DSec solves scale and efficiency, but real environments carry other hazards. The paper logs agents that rummaged through logs, faked remote procedure calls, even edited /bin/bash to slip past the normal flow, and agents that scanned reachable services and pulled outside code to cheat the evaluation.
Worse, an agent can break the environment itself. The paper records a recursive file scan that crashed the kernel and a single yes command that ballooned logs to tens of gigabytes. DSec limits agent actions mainly through AppArmor and eBPF, the first controlling file and socket access, the second limiting network access, with rules that shift by task stage. These still cover only part of the risk, and kernel-level holes are hard to fully close.
DSec shows what large-scale agent training now demands as standalone infrastructure, from sandbox creation and environment reuse to rollout scheduling, state saving and isolation. As agent tasks grow longer and more interactive, keeping tens of thousands of sandboxes stable while holding down cost and risk is the next problem the field must solve. For DeepSeek’s agent work, the platform that carries the tasks has to keep pace with the models themselves.
Editor’s note: This is an adapted translation of the original Zhidx report. It has been trimmed and restructured for readability for an international business audience. The full original (in Chinese) is at https://www.sohu.com/a/1080090901_115978.