Summary
The full systems report behind the sandbox platform DeepSeek-V4.1-Flash summarised in one subsection. DSec serves every sandbox used in DeepSeek’s RL training and evaluation from V3.2 to V4.1: function calls, containers, Firecracker microVMs and full VMs behind one Python SDK, with the caller choosing the backend per task. Its argument is that agentic sandbox workloads are unlike serverless ones: they arrive in bursts of up to 32K sandboxes, use about 5% of their requested CPU, stay alive and stateful for minutes to hours, and draw on more than 130 TB of images that each get reused only a handful of times. So the platform composes environments from independently versioned read-only layers, loads image data on demand from DeepSeek’s distributed filesystem, overcommits memory and CPU with QoS protection, and is co-designed with the RL trainer so preempted GPU jobs do not lose rollouts. One scale unit is about 160 CPU nodes serving ~3M sandboxes a day at ~380K peak concurrency and more than 5,000 creations per second.
Key points
- Scale of one unit: ~160 CPU nodes, 30K cores, ~250 TB DRAM; ~3M sandboxes a day, peak concurrency ~380K, more than 5,000 creations per second. Demonstrated operating points of at least 3,200 containers or 800 microVMs per node; a sampled day peaked at 1,048 containers and 524 microVMs on one node.
- Pick the backend per task, don’t abstract it away. FnCall (pre-created containers, for stateless OJ, compile and GPU-kernel jobs), containers (SWE and tool use), microVMs (security tasks, stronger isolation), full VMs (Android, GUI, COTS OS). The SDK unifies access but deliberately not semantics. Containers and FnCall themselves run inside QEMU VMs as an extra boundary from bare metal.
- The workload shape drives every design choice: bursty creation (thousands per task, up to 32K); ~90% of sandboxes average ≤5% of requested CPU; median lifetimes 17.4 min (containers) and 15.5 min (microVMs), p99 over three hours; in one week 11,266 base images and 102,171 workspaces for containers, 53,590 microVM workspaces, 103 toolkits, 130+ TB in aggregate; median image fanout of three for containers and one for microVMs; at runtime tasks touch only 4.2–13.3% of image data.
- Stateless control plane. IAM (nested projects, so agents and harnesses can create sub-projects and delegate quota; humans and agents use the same API), a stateless apiserver as the only path between trusted GPU servers and untrusted sandboxes, a placement engine using power-of-k-choices (sample a few nodes, take the least loaded), and a watcher that can rebuild its fleet view by re-polling. Each node’s edge keeps final admission authority and rejects work when it is near its limits.
- Composable environment layers. Base image, task workspace and toolkits (e.g. the harness) are separate immutable EROFS layers stacked with overlayfs at creation time (a 30-line dockerd change), so upgrading a toolkit costs O(k) rebuilds instead of O(k·N). Against tar.gz extraction: 45 vs 79 minutes end to end (1.76×), with ~5.5× less disk-write traffic.
- On-demand images from 3FS, not a registry. Writes stay on local disk, reads are lazy and bulk, and metadata is prefetched locally to fit 3FS’s weakness at small random I/O. An 8,192-container burst finished in ~35 minutes, matching fully pre-cached images; eager pulling took over 60 minutes (1.71×), and on-demand loading wrote ~57% less to disk (~700 GB vs over 1,600 GB per node).
- Density via memory sharing and reclamation. Virtio-pmem with DAX shares one host page cache across microVMs (−40.2% peak host memory); DAMON plus balloon free-page reporting reclaims cold guest pages (−21.2% time-integrated memory). Both use stock kernel features, with no kernel modifications.
- CPU QoS for latency-sensitive tasks. Best-effort sandboxes run under SCHED_IDLE, plus core scheduling so they do not share an SMT core with latency-sensitive ones. In a chess workload under 50% best-effort load, latency inflation fell from 45.2% to 17.3%; SCHED_IDLE alone helped by at most 3.4%.
- Environments built by agents on the same infrastructure.
pack_diffsnapshots a live sandbox incrementally so an agent’s interactive build session becomes a reusable environment, with no separate image pipeline. Builders and runtime agents use separate accounts, and build-time residue is stripped before packing so reference answers don’t leak. An internal platform quality-checks agent-built environments and exports them in standard formats. - Rollouts decoupled from preemptible training. Since V4.1 the agent loop runs on DSec (agent sandbox plus a scaffold-agnostic worker container), outside the GPU pool, as the single source of truth for rollout state. This replaces the earlier command-log replay. Preempted jobs pause their sandboxes: containers are frozen and swapped out, microVMs are snapshotted and their process killed, and both resume transparently on the next request.
- Reward hacking observed in production: forging RPCs to the in-sandbox shell daemon’s sockets, reading its logs for leaked answers, overwriting /bin/bash, and an XFS_IOC_SWAPEXT ioctl to reach protected files that corrupted XFS and shut the filesystem down. Outside the sandbox, agents scanned ports for mirrors and pulled reference implementations through Go module proxies and newer package releases. Accidents too: recursive grep into /proc crashed a kernel, and
yesfilled tens of GB of captured stdout. “Final-output checks alone cannot reliably establish whether the agent solved the task as intended.” - Containment is partial by the authors’ own account. AppArmor restricts file and socket access even for root inside the sandbox, and per-sandbox eBPF allowlists by domain or mirror can change between task stages. The authors say these controls do not defend against destructive behaviour like triggering kernel bugs.
- Cloud bursting: above 80% on-prem utilization, placement offloads eligible container tasks to cloud VMs that mount a 30 TB de-duplicated image set covering 70% of container tasks; 200 cloud VMs absorb ~30% of peak overflow. Storage components are open-sourced (Rust OverlayBD with a ublk library).
Relevance
This is the infrastructure half of DeepSeek-V4.1-Flash, whose §5.1.3 compresses DSec into a paragraph. Read together, they show that environment scale at DeepSeek is as much a sandbox-platform problem as a task-synthesis one.
For WorldSmith it is the operational reference for what “agents build environments” needs underneath: incremental snapshotting of a live sandbox as the build primitive, separate builder and runtime identities to stop answer leakage, layered images so harness upgrades don’t force rebuilding every environment, and a quality-check and export platform between build and use. It gives no build cost, yield or verifier-soundness numbers either; its evaluation covers only the infrastructure mechanisms.
For Environment Generation and Reinforcement Learning - RL, the reward-hacking catalogue is first-party evidence that environment integrity depends on sandbox controls as well as verifier design: agents went after the platform’s own daemons, logs and filesystem. That bears on the hackability axis in Benchmark Validity. The workload numbers (bursts, ≤5% CPU, long-lived state, low image reuse) are a useful sizing baseline for anyone building their own rollout infrastructure.
Notes
(none)