DeepSeek has published a technical report on arXiv titled "DeepSeek Elastic Compute (DSec): Sandbox Infrastructure for Large-Scale Agent Training," submitted on September 19. The report covers the execution layer DeepSeek uses when training and evaluating agents — the environment where models write code, run commands, and operate a computer. The author list runs past a hundred names, with DeepSeek-AI as the lead organization; several PhD students from Tsinghua University contributed as interns.
DeepSeek has released plenty of model-training reports before. This is the first time it has written up, on its own, the "training ground" that sits behind its reinforcement learning work.
Four sandbox types, one interface
DSec exposes four backends through a single SDK, ordered from light to heavy by isolation strength and overhead:
- FnCall: stateless tasks, such as online judge (OJ) problems
- Containers: software engineering and tool-calling tasks
- Firecracker microVMs: security penetration tasks that need stronger isolation
- Full virtual machines (QEMU): Android development and graphics-intensive tasks
The workloads span repository-level coding tasks like SWE-bench, security exploitation, computer-use, and mobile development. The training framework only ever calls the same interface; the scheduling layer decides which sandbox backend a given task gets.
A few engineering numbers
Image loading gets the most space in the report. DSec stores images in EROFS format on DeepSeek's own 3FS distributed file system and reads them on demand. Compared with the conventional approach of pulling an entire Docker image locally first, the completion time for the same batch of tasks dropped from over 60 minutes to about 35 minutes — a 1.71x speedup by the report's own figure — while cumulative disk writes fell by 57%.
On memory, the report uses virtio-pmem paired with DAX so that multiple virtual machines on the same host share a single page cache instead of each keeping its own copy, cutting host peak memory by 40.2%. Adding DAMON-based and balloon-driver idle-page reclamation on top brought cumulative time-weighted memory usage down another 21.2%.
One more design choice ties directly into training: rollout execution has been moved onto DSec and split into two components, with the agent sandbox and the worker container jointly holding the complete rollout state. GPU training jobs are preemptible, and when a job is preempted, an in-progress multi-step interaction is not lost along with it.
Set against overseas peers
Agent sandboxes are already a business overseas, with a cluster of dedicated companies serving it. When OpenAI added sandboxing to its Agents SDK this past April, it plugged in third-party providers such as E2B, Modal, Daytona, and Cloudflare; Anthropic later shipped a self-hosted sandbox, and Cursor built an OS-level code sandbox. These products are aimed at developers running agents in production, and their focus is security boundaries and usage-based billing.
DSec starts from a different place. It serves DeepSeek's own reinforcement learning training, where the problem is spinning up and tearing down millions of environments a day without slowing down the GPUs. The concurrency and density figures in the report are rarely disclosed publicly by commercial sandbox products, so there's no clean apples-to-apples comparison to make.
Leading overseas labs likely run comparable systems internally, but they rarely turn the architecture and the numbers into a paper. By laying out the trade-offs among its four backends and its image- and memory-optimization techniques, DeepSeek has given teams in China working on agent training something concrete to compare against. The report does not say whether DSec's code will be open-sourced, nor whether it will be offered as a cloud service.
Sources: CocoLoop, the arXiv paper "DeepSeek Elastic Compute (DSec)", OpenAI Agents SDK documentation; concurrency, density, and image-loading speedup figures verified against the paper's main text.