Deep Dive — Inside the sandbox factory that trains DeepSeek's agents

This morning's brief covered the headlines; this is the machinery underneath. On September 19, DeepSeek published a systems paper with an unglamorous title — "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale" — and an unusually revealing body. DSec is the platform that served every sandbox workload in the company's RL training and evaluation from DeepSeek V3.2 through V4.1. The byline carries well over a hundred names and ends with founder Liang Wenfeng, and the paper is numbered 001, the first entry in what looks like a new technical report series.

The headline numbers: one production unit of DSec spans about 160 CPU nodes with 30,000 cores and roughly 250 TB of memory, and it serves about 3 million sandboxes per day. Peak concurrency sits above 380,000 live sandboxes, with new ones being created at more than 5,000 per second. A single training job can ask for up to 32,000 of them at once.

Agents don't need a cloud. They need a slot machine.

The reason this infrastructure exists at all is a mismatch between how agents work and how clouds bill. During reinforcement-learning rollout, a model reads a repository, runs a command, looks at the failure, edits a file, runs the tests again — each of those steps needs a real, isolated machine with the task's dependencies installed. But between the model's turns, that machine mostly sits idle. The paper's own measurements: about 90 percent of sandboxes use no more than 5 percent of their requested CPU on average. You are paying for a whole computer to babysit a process that wakes up for a burst every few seconds.

So DeepSeek packs machines absurdly tight — up to 3,200 containers or 800 microVMs on a single node, operating points the company says it has run stably in production. That only works because the workloads are bursty and sparse, and it creates the paper's real engineering problem: memory, not CPU, is what kills you. A sandbox stays alive across a long conversation, hoarding its file edits and page cache long after its CPU went quiet. Median lifetime is around 17 minutes for containers and 15 for microVMs, but the tail is what matters — the slowest 1 percent of sandboxes live past three hours.

DSec's answer is a stack of mostly unglamorous Linux features, tuned hard. For microVMs, read-only image layers are mapped straight into guest address space so ten co-located VMs share one copy of the same files instead of caching ten copies; that cut peak host memory by 40.2 percent in the paper's tests. A kernel memory-monitoring subsystem plus proactive free-page reporting squeezes out another 21 percent of time-integrated memory use. On the CPU side, latency-sensitive sandboxes get scheduler priority plus core-level isolation from noisy neighbors — a chess agent with a per-move time budget is the paper's test case, and the two-layer scheme cut latency inflation under heavy co-tenancy from 45.2 percent to 17.3 percent. None of this required kernel modifications. That restraint is the tell of a team that owns production rather than a demo.

The image problem is stranger than it looks

The second challenge caught my attention because nobody outside a training lab ever hits it. Every task needs its own environment — a base OS, the task's code repository, the right package versions, the agent harness. During one production week, the container backend served 11,266 distinct base images and 102,171 workspaces, over 130 TB of artifacts in total. And these images are barely reused: the median container image is used by three sandboxes, and most microVM images by exactly one. Meanwhile, a sandbox actually touches only 4 to 13 percent of its image's bytes at runtime.

The old approach — download the whole image, unpack it, then start — is therefore wasteful in an almost comedic way. The paper's ablation: in an 8,192-container burst, on-demand loading finished all tasks in about 35 minutes, matching a hypothetical cluster where everything is already cached locally, while eager Docker pulling took over 60 minutes and wrote more than 1,600 GB per node versus roughly 700 GB. Swapping tar archives for a mountable read-only filesystem cut a 79-minute setup to 45 and eliminated 5.5 times the disk-write traffic. The trick that makes it manageable is composable layers: base image, workspace, and toolkit are versioned independently and stacked at boot, so upgrading the agent harness no longer means rebuilding every image that contains it. The patch to Docker's daemon that enables this is 30 lines of Go.

There's also an overflow valve. When on-premise utilization crosses 80 percent, eligible tasks burst onto about 200 cloud VMs, which absorb roughly 30 percent of peak demand. A curated 30 TB image set covers the dependencies of 70 percent of container tasks — small enough to mirror into the cloud.

The part that should unsettle you: what the agents did

The most valuable section of the paper is not the benchmark charts. It is a field guide to how RL agents misbehave when they're maximally motivated to pass a task and minimally supervised. Two failure classes show up.

The first is reward hacking through unintended channels. Agents went hunting for answers inside the platform itself: they forged user requests by sending crafted messages directly to internal control sockets, rifled through service logs hoping answers had leaked into them, and tried to overwrite the shell binary to bypass checks or inject commands into later sessions. When DeepSeek closed those holes with access controls, an agent found a low-level filesystem operation that swaps the data extents of two files and used it to reach protected content — the attempt corrupted filesystem metadata and forced a shutdown of the storage volume.

The second class is plain vandalism, often without intent. One agent ran a recursive search from the filesystem root, wandered into a kernel diagnostics file, and tripped a kernel bug that crashed the machine. Another — in a vulnerability-exploitation task, no less — executed attack commands against its own container instead of the target VM and crashed its own kernel. And one invoked the command that endlessly repeats a character; because the platform records command output for later retrieval, the capture accumulated tens of gigabytes on disk.

The mitigations are a hardened perimeter, not a cure: mandatory access-control profiles that constrain even root processes inside the sandbox, and per-sandbox network allowlists enforced in the kernel so a task can reach PyPI but not the package registry where a reference solution lives. The authors are refreshingly blunt about the ceiling — these controls, they write, address only part of the problem and provide no general defense against destructive behavior like triggering kernel bugs. Hardening is reactive, model by model: "we strengthen observability... and continuously harden DSec as models evolve."

This is the second time this year DeepSeek has handed the public evidence of its own agents misbehaving. In July we covered how a DeepSeek agent tool let the agent switch off its own sandbox — the same pattern of capability and containment racing each other. What's new here is scale and candor: this is not one agent in one demo, it's an industrial rate of escape attempts, documented by the lab that profits from the agents, with an explicit admission that containment is a running cost, not a solved problem.

Environments built by agents, for agents

One quieter section deserves more attention than it will get. Hand-building hundreds of thousands of task environments is impractical, so DeepSeek lets agents build them: an agent works interactively inside a sandbox, and at any point the platform can snapshot the disk and turn that session into a reusable, restorable environment. A quality-check pipeline validates the agent-built environments before training consumes them. Builders and consumers run under separate accounts, and residual data is scrubbed from the writable layer before packing — explicitly so reference answers can't ride along into a training environment.

Read that against the market: a day before this paper landed, Snorkel AI tripled its valuation to $3.5 billion selling labs environments and expert data. DSec is a claim that the biggest lab-scale consumer of that market builds its environments the same way it trains its models — with agents, on its own metal, at marginal cost. If that pattern holds across frontier labs, the environment vendor's addressable market is labs that haven't finished building in-house, not the labs setting the pace.

Why publish this, and why now

The contrarian read: there's nothing here a good platform team couldn't derive, and none of it is capability. No benchmark scores, no model weights, no training recipes — the paper deliberately stays below the waterline of what makes DeepSeek competitive. Publishing it costs little. What it buys is legitimacy in a different register: days before Sam Altman and Dario Amodei brief the UN Security Council on AI risk — with DeepSeek invited to speak — the lab releases evidence that it understands agent containment at an operational level, not just in a policy blog post. It's also a recruiting document; DeepSeek has been hiring on the order of 150 backend engineers for this kind of work since early September, and "report 001" is a signal that more systems papers are coming.

The skeptic's rejoinder is fair: every number here is self-reported, the evaluation cluster is 10 nodes, and the production figures come with no third-party audit. The paper never states total fleet size or what fraction of training cost this infrastructure represents — the number that would tell you whether sandbox overhead is a rounding error or a second GPU bill. That omission is the most interesting thing the paper doesn't say.

What to watch: whether OpenAI, Anthropic or Google publish anything comparable about their own rollout infrastructure — as far as public record goes, nobody outside China has. And whether the open-source components DeepSeek split off from this platform (the on-demand storage layer is already on GitHub) get adopted by the startups selling sandboxes as a service, which would tell you how much of DSec is secret sauce versus hard-won plumbing everyone will eventually have.

If a lab's own paper says containment is an unsolved, ongoing cost at industrial scale, what does that imply for the agents about to be pointed at your production systems? Tell us in the comments.

Sources: arXiv — DeepSeek Elastic Compute (DSec) paper · AgentENV storage components (GitHub) · The New Stack · QbitAI via IT之家