DeepSeek details DSec: the sandbox infra that creates 3 million agent-training sandboxes a day

DeepSeek published a Zhihu post and an arXiv paper, “DeepSeek Elastic Compute (DSec)”, on September 30 (130+ authors including Liang Wenfeng, with Tsinghua), giving the first full account of the sandbox infrastructure behind all V4/V4.1-Agent training, evaluation and data preprocessing. It is the first first-hand look at what agent training actually costs to run.

Facts

• Role: one sandbox base serves all V4/V4.1-Agent training, evaluation and data preprocessing; since V4.1, the agent execution loop runs on compute outside the preemptible GPU pool.
• Execution backends: FnCall, Container, MicroVM and Full VM, all behind one Python SDK, libdsec.
• Images and scale: composable EROFS+OverlayFS images — 11,266 base images and 102,171 workspaces in one production week; on-demand loading touches only 4.2%–13.3% of image data, and spinning up 8,192 containers dropped from over 60 to 35 minutes.
• Resources: CPU oversubscription above 50x; one shard is roughly 160 servers, ~30k cores and 250 TB of RAM; about 3 million sandboxes created per day, 380k+ concurrent at peak.
• Security boundary: AppArmor plus eBPF; the authors state there is no general defense against kernel-level attacks.
• Sourcing note: the Zhihu article is from DeepSeek’s official account — treat the numbers as self-reported, cross-checkable against the paper.

Editorial take

Teams running agent RL can benchmark their own sandbox spend against this bill directly — on-demand image loading and CPU oversubscription are the two tricks worth stealing. Alibaba Cloud’s Agent Sandbox serves the same layer as a public product, so the two together bracket the design space; read it next to the Ascend components open-sourced the same day. The candid admission that kernel attacks have no general defense belongs in every security review.