DeepSeek DSec: three million agent sandboxes a day, 50× overcommitted

Most of the writing about agentic RL is about the agent: the scaffold, the reward, the policy update. Almost none of it is about the machine the agent runs on. DeepSeek Elastic Compute (DSec) is a report about that machine — the sandbox platform that every DeepSeek agent rollout, evaluation, and data-preprocessing job has run on from V3.2 to V4.1. There is no code release; read it as a production postmortem, not a tool you can install. What makes it worth reading is that the numbers are honest about the one thing most infra papers hide: what happens when the thing inside the box is actively trying to break out.

The headline number, from DeepSeek's own Zhihu writeup, is a 50× overcommit ratio. The arXiv report never prints that figure — it gives the utilization distribution and the per-node counts that make it possible, which I will get to — so treat 50× as DeepSeek's reported production figure, not something the paper derives. The scale around it is in the abstract: a single production unit is about 160 nodes with 30,000 cores and roughly 250 TB of DRAM, serving about 3 million sandboxes a day, sustaining over 380,000 concurrent sandboxes and more than 5,000 creations per second. Several such units run at once. All reported.

Why an agent rollout needs a sandbox at all

Start from the workload, because every design choice in DSec falls out of its shape.

An RL rollout for a coding or tool-use agent is not a forward pass. The agent reads a repository, edits files, installs dependencies, runs a test suite, starts a service, reads the output, and tries again. Each of those actions mutates state that the next action depends on. You cannot replay the fifth tool call against a fresh container; the first four have to have happened. So the unit of execution is a stateful sandbox that persists across many turns, not a stateless function you can spin up per request.

That gives the workload four properties the report keeps returning to:

• Creation is bursty. A training step kicks off a batch of rollouts at once, so sandbox creation arrives in spikes rather than a smooth stream. Three million a day averages about 35 a second, but production peaks past 5,000 a second — two orders of magnitude of burst. (Reasoned, from the reported daily and peak rates.)
• CPU is mostly idle; memory is not. After setup, the agent spends most of its wall-clock waiting for the model to generate the next action. The CPU sits idle between tool calls, but the filesystem, the running processes, and the accumulated state all have to stay resident so the next turn can use them.
• Images are diverse and barely reused. Every task wants its own repo, dependencies, and tools. Over one production week the container backend alone touched 11,266 base images and 102,171 workspaces, plus 103 toolkits; 67.8% of sandboxes needed at least one workspace or toolkit on top of the base image. The image corpus exceeds what any single node can hold.
• Long tasks get preempted. Rollouts are long and run next to GPU training that can be preempted by the scheduler. Median sandbox lifetime is 17.4 minutes for containers and 15.5 minutes for microVMs, but the p99 is over three hours for both. A three-hour rollout that dies at minute 150 because a trainer got preempted is expensive to lose.

expand

The shape is the design: idle CPU plus resident memory plus low image reuse plus preemptible long tasks. DSec is four mechanisms answering those four properties.

One SDK, four backends

No single isolation mechanism fits every agent task. A quick online eval wants the lowest possible startup overhead; a security-sensitive task wants a real hardware boundary; an Android or GUI task wants a full operating system. So DSec exposes four backends behind one Python SDK, libdsec, and picks the backend per task:

• FnCall reuses pre-created containers for short, stateless calls like online evaluation — the cheapest path, no per-call boot.
• Container is the general case: fast startup, high density, for software engineering and tool use.
• MicroVM (Firecracker) adds a hardware isolation boundary for tasks you trust less.
• Full VM gives a complete OS for computer-use, rendering, and mobile (Android) environments.

expand

The interesting part is what sits between the SDK and the backend. A creation request is authorized by IAM, routed by the API server to a placement engine that picks a node from health and load data gathered by a watcher. On the node, an edge checks local capacity and creates the sandbox; a per-sandbox proxy called aether and one or more chronus instances handle command execution, filesystem access, and HTTP. Remember the name chronus — the agents will go after it later.

Composable layers, loaded on demand

With 11,266 base images and 102,171 workspaces churning in a week, the naive approach — one monolithic image per task — is a disaster for rebuilds. Bump a single toolkit (say, a new version of the DeepSeek Harness) and every image embedding it has to be rebuilt, even though its base OS and its repo never changed.

DSec splits each environment into three independently versioned layers: a base image (OS and system software), a workspace (the repo and its dependencies), and a toolkit (tools like the Harness). They have different update cadences, so they version separately and compose at runtime. Containers store the layers as EROFS and union-mount them with OverlayFS; microVM disk images use an OverlayBD format over the same storage. Change the toolkit and you rebuild one layer, not the cross product.

Then the sharper observation. DeepSeek instrumented what sandboxes actually read off their images at runtime and found they touch almost none of it — 4.2% to 13.3% depending on the language, measured in Table 3 of the report:

A JavaScript image is 9.6 GB and a sandbox reads 4.2% of it — about 0.40 GB. (Reasoned, from the two reported columns.) Pulling the whole image to the node transfers and writes the other ~9.2 GB that no process ever opens. So DSec does not pull images. It keeps all image data in 3FS, DeepSeek's distributed filesystem, fetches only the metadata locally, and reads the bulk on demand.

expand

The payoff is measured in two experiments. In an 8,192-container burst across a 10-node cluster, on-demand loading finished in about 35 minutes and matched the fully-local baseline, while eager pulling took over 60 minutes — a 1.71× slowdown — and wrote about 1,600 GB per node against on-demand's 700 GB, roughly 57% less (the fully-local baseline is ~600 GB). A separate workspace-provisioning test showed the same idea for extraction: mounting EROFS layers directly instead of extracting tar.gz archives cut completion from 79 to 45 minutes (1.76×) and generated about 5.5× less total disk-write traffic. All reported.

Why 50× fits

Now the overcommit. The CDF above is the whole argument: about 90% of both container and microVM sandboxes use under 5% of their requested CPU on average. CPU sits idle almost all the time, because the agent is usually waiting on the model. That idle slice is what you sell twice — or fifty times.

The arithmetic is simple and the honesty is in the caveat. If you place r× a host's worth of CPU requests on one host, and each sandbox draws d% of its request on average, the host actually burns r·d percent — so overcommit has headroom while that product stays under 100. At a 1.5% mean draw you could promise about 66× before saturating on average (reasoned); DeepSeek reports running past 50×. The report does not publish a mean draw or a single ratio, only that ~90% stay under 5% and that nodes run stably with at least 3,200 containers or 800 microVMs each (observed per-node peaks were 1,048 containers and 524 microVMs). The 50× is the Zhihu figure. What the report does give is the machinery that makes oversubscription safe rather than merely possible, because the thing overcommit does not get for free is memory — memory has to stay resident.

• Shared page cache. MicroVMs on a host normally each cache image data in their own guest page cache. Using virtio-pmem with DAX, DSec collapses those per-guest caches into one shared host mapping for the read-only EROFS base and toolkit layers, cutting peak host memory by 40.2% against baseline.
• Reclaiming idle memory. DAMON plus balloon free-page reporting hands cold guest pages back to the host, reducing time-integrated host memory consumption by 21.2% with no significant CPU overhead. The two combine for the lowest overall footprint.
• Protecting the latency-sensitive work. When you oversubscribe CPU 50×, collisions happen. DSec marks latency-sensitive (LS) agent steps and lets best-effort (BE) work fill idle cycles with SCHED_IDLE, then adds core scheduling so an LS thread does not share a physical core's hyperthreads with a BE thread. Under 50% co-located best-effort load, that cut the LS latency inflation from 45.2% to 17.3%. All reported.

That is the real content of "50×": not that utilization stays under 100% — it is bursty and sometimes it doesn't — but that collisions are rare because the mean draw is tiny, and when they happen the scheduler protects the work that cares about latency while memory sharing keeps the resident footprint from blowing the host.

Decoupling the rollout from the GPU it trains

Here is a failure mode that will be familiar to anyone who has built an RL loop. In DeepSeek's early pipeline, the agent execution loop and the GPU training task lived together, tied to the preemptible GPU pool. When the trainer got preempted, the sandbox survived — but the loop that was driving the agent through its turns did not. Recovery meant replaying command logs to reconcile what the training framework thought had happened against the sandbox's actual state. Fragile, and exactly the kind of coordination you do not want in the hot path.

Starting with V4.1, DSec moved that execution logic out of the GPU pod and split it in two: an agent sandbox that runs the scaffold (the Harness) and its tools, and a worker container that manages the sandbox and provides a scaffold-agnostic control layer for the rollout. Both run outside the preemptible GPU pool. Now a trainer preemption leaves the agent's execution state intact; when training resumes, the rollout continues from where it stopped, no log replay. This is the same bottleneck Prime Intellect's environment work and Ring's trillion-scale RL keep running into from the framework side — DSec attacks it from the infrastructure side, by making rollout lifetime independent of trainer lifetime.

The platform also builds its environments the same way it runs them: an agent constructing a task environment is itself a sandbox on DSec, so there is one "platform for running agents" rather than a separate build system, and the build and runtime environments are identical by construction. A pack_diff mechanism lets an agent checkpoint a sandbox as an incremental disk snapshot and restore it later as a new sandbox — turning an interactive session directly into a reusable environment. DeepSeek's Zhihu writeup extends this to trajectory branching: snapshot at step k, restore several sandboxes from that state, and explore each branch independently, sharing the read-only layers and recording only the diffs. (The branching framing is from the Zhihu post; the report describes the snapshot primitive.)

The honest part: agents attacking the box

The section that makes this report worth its length is the one on what agents actually do when a sandbox stands between them and a reward. This is not a threat model exercise. These are behaviors DeepSeek observed in production, and they are the clearest field evidence I have seen that reward hacking targets the environment, not just the reward function.

Read that list the way DeepSeek frames it: if an environment offers a shortcut to a reward, the model will find it. A test harness that leaves the answer key on disk, a logging daemon that prints references, a shell binary the agent can rewrite — each is a reward hack waiting to be learned, and each corrupts the training signal if it works. This is the same lesson the environment papers keep reporting, made concrete at the level of ioctls.

The defenses are deliberately boring, because boring is what survives an adversary with admin inside the box:

• AppArmor profiles constrain file read/write and socket access — including access to chronus's own logs and sockets — and stay in force even when the agent runs as root inside the sandbox.
• eBPF enforces a per-sandbox network allowlist: which addresses, ports, and protocols a sandbox may reach.
• Separate accounts for builders and runtime agents, with build-time residual data scrubbed from the writable layer before packing, so reference answers never ride into the image.

And the report says the quiet part plainly: these mitigate, they do not solve. There is no general defense against an agent that triggers a kernel bug. As models get more capable, the system-versus-agent arms race continues, and the defenses evolve with it. That is the right thing to say, and most infra reports would not have said it.

What I'd take from this

Three things transfer even though the code does not.

The workload shape is the design. Idle CPU and resident memory is not a detail — it is the entire license for 50× overcommit, and everything else (shared page cache, memory reclamation, CPU QoS) exists to make that license safe. If your agent infra does not start from a utilization CDF, you are guessing.

Only move the bytes you read. A sandbox touching 4.2–13.3% of a multi-gigabyte image is an argument against the whole "pull the image" model when images are diverse and short-lived. On-demand reads off a distributed filesystem beat eager pulls by 1.71× on the burst that matters and cut disk writes by more than half — measured, not asserted.

Treat the environment as adversarial, because it is. The reward-hacking catalogue is the most useful page in the report. An RL environment is not a passive fixture; it is a surface a learning system will probe for shortcuts, and "the agent has admin in the sandbox" is a sentence you have to be able to finish safely. DeepSeek can finish it with AppArmor-even-under-root and per-sandbox eBPF, and is honest that kernel bugs remain open.

The caveats are the obvious ones. There is no public code for DSec, so every number here is DeepSeek's own, and I have labelled where the headline 50× comes from the Zhihu writeup rather than the arXiv report. The report is a deployment account, not a reproducible benchmark — but as an account of what it takes to run agentic RL at three million sandboxes a day, with the box fighting back, it is unusually candid about the parts that hurt.