DeepSeek DSec Training Infrastructure First Public Disclosure: How the Sandbox Layer That Trained V4 Actually Works
On September 19, 2026, DeepSeek posted a paper to arXiv titled “DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale.” The submission was unassuming — 31 pages, 13 figures, cs.DC category — but it was the first time DeepSeek publicly disclosed the production infrastructure that trained the V4 model family, including the V4.1 Flash model that retired V4-Pro ten days earlier.
This is not a sandbox runtime paper. It is a training infrastructure paper. DSec is the layer that made large-scale agentic reinforcement learning economically viable for DeepSeek — the layer that lets a model practice agentic tasks (inspecting repositories, invoking tools, executing commands, interacting with services) across millions of sandboxed environments per day, without the infrastructure cost collapsing under its own weight.
If V4.1 Flash is the proof that architecture beats scale, DSec is the proof that infrastructure architecture is what makes the model architecture shippable. This post breaks down what the first public disclosure actually tells us.
The Problem DSec Solves
Large-scale agentic training and evaluation with LLMs requires isolated, stateful execution environments. A model learning to act as an agent must:
- Inspect repositories (clones a git repo, reads files)
- Invoke tools (runs shell commands, calls APIs)
- Execute commands (spawns processes, writes files)
- Interact with task-specific services (databases, web servers, sandboxes)
Each of these workloads creates a sandbox. The workloads have four properties that make them brutal to serve at scale:
- Bursty creation — sandboxes appear in large bursts when a rollout phase begins, not at a steady trickle
- Heterogeneous isolation — some sandboxes need only a function call’s worth of isolation; others need a full virtual machine
- Long-lived state — a single agent rollout can retain state across hundreds of tool calls, and that state must persist
- Large image corpora, limited reuse — sandboxes draw from large container images, and the same image is rarely re-used across rollouts
A single sandbox runtime cannot serve this shape. What is needed is an elastic execution platform — one that can scale up to hundreds of thousands of concurrent sandboxes, scale down when the rollout phase ends, and reclaim idle resources without breaking the stateful work in flight. That platform is DSec.
The Architecture: Four Backends, One SDK
DSec exposes four sandbox backends through a single unified SDK, ordered from lightest to heaviest isolation:
┌─────────────────────────────────────────────────────────────────┐
│ Unified DSec SDK │
└──────────────────────────┬──────────────────────────────────────┘
│ selects backend per task
┌──────────┬───────┴───────┬──────────────┐
▼ ▼ ▼ ▼
┌────────────┐ ┌──────────┐ ┌───────────┐ ┌────────────┐
│ FnCall │ │ Container│ │ microVM │ │ full-VM │
│ backend │ │ backend │ │ backend │ │ backend │
│ │ │ │ │ │ │ │
│ Lightest │ │ Shared │ │ Stronger │ │ Heaviest │
│ isolation │ │ kernel │ │ isolation │ │ isolation │
│ Fastest │ │ cgroup- │ │ Own │ │ Full │
│ spin-up │ │ bounded │ │ kernel │ │ hypervisor │
└────────────┘ └──────────┘ └───────────┘ └────────────┘
- FnCall — the lightest backend. For agent tasks that only need isolated function execution (no filesystem, no process spawn). Fastest to create, cheapest to run.
- Container — shared-kernel isolation with cgroup bounds. For tasks that need a filesystem and process space but not a full kernel.
- microVM — own-kernel isolation in a lightweight virtual machine. For tasks that need stronger isolation guarantees.
- full-VM — heaviest isolation, full hypervisor. For tasks that need complete virtual machine semantics.
The unified SDK is the key abstraction. A training framework does not pick a backend manually — it declares the requirements of a sandbox and DSec selects the cheapest backend that meets them. This is the same pattern cloud platforms use for serverless functions, applied to agent training.
Layered Composition and 3FS
DSec composes environments from independently versioned layers. A sandbox image is not a single monolithic blob — it is a stack of versioned layers (base OS, Python runtime, task-specific dependencies, agent harness, etc.). When a sandbox is created, DSec assembles the right layer versions and presents a coherent environment.
The image data itself is loaded on demand from the Fire-Flyer File System (3FS) — DeepSeek’s cluster-wide distributed filesystem. 3FS is the same filesystem that backs DeepSeek’s training data pipeline. By loading sandbox images on demand from 3FS rather than pre-staging them on every node, DSec avoids the image-distribution bottleneck that plagues naive container orchestration at scale.
This is one of the more quietly important details in the paper. Image distribution is the hidden tax on sandbox platforms: if every node must hold a local copy of every image a sandbox might need, the storage cost scales with (nodes × images) — and with heterogeneous agentic workloads, the image count explodes. 3FS-on-demand collapses that to a single cluster-wide copy, fetched only when and where a sandbox actually needs it.
Memory Sharing, Reclamation, and CPU Scheduling
DSec combines three resource-management techniques to achieve high-density execution — running many sandboxes per node without each one paying full resource cost:
| Technique | What It Does | Why It Matters |
|---|---|---|
| Memory sharing | Multiple sandboxes share read-only pages (e.g. the base image, common libraries) | Cuts per-sandbox memory cost dramatically when many sandboxes run the same stack |
| Memory reclamation | Idle memory from one sandbox is reclaimed and given to another | Prevents one stuck sandbox from starving its neighbors |
| CPU scheduling | CPU is scheduled across sandboxes, not statically partitioned | A sandbox that is waiting on I/O yields its CPU to one that is computing |
The combination is what allows DSec to overcommit nodes safely. The paper reports that these mechanisms reduce environment setup and image-distribution overhead, improve memory efficiency, and preserve latency-sensitive performance under high-density overcommit. That last clause — preserving latency under overcommit — is the hard part. Naive overcommit destroys interactive latency. DSec’s contribution is doing it without that collapse.
The RL Co-Design
The most strategically important section of the DSec paper is the co-design with the reinforcement learning framework. DSec is not a generic sandbox platform — it is built specifically to serve agentic RL training, and that shapes three of its core decisions.
1. Decoupling Stateful Rollout From Preemptible GPU Training
Agent rollouts are stateful — a model takes actions in a sandbox over many steps, and the sandbox retains state across those steps. GPU training, by contrast, is preemptible — the training step can be paused, resumed, and re-run without losing correctness, so long as the rollout state is preserved.
DSec exploits this asymmetry. Stateful rollout execution runs on the sandbox cluster (CPU-heavy, long-lived). Preemptible GPU training runs on the GPU cluster (compute-heavy, interruptible). DSec coordinates the two so that rollout state is preserved while idle GPU resources are reclaimed — meaning the GPUs are not sitting idle waiting for a slow rollout to finish, and the rollout is not killed when the GPU scheduler wants the node back.
This is the infrastructure pattern that makes large-scale agentic RL economically viable. Without it, either GPUs sit idle (wasting the most expensive resource in the cluster) or rollouts are killed (losing expensive stateful work). With it, both resources stay near fully utilized.
2. Sandbox Lifecycle Coordinated With Training
DSec coordinates the sandbox lifecycle with the training loop. A sandbox is created when a rollout needs it, kept alive for the duration of the rollout, and destroyed the moment training no longer needs its state. This is not a generic container orchestrator’s “keep alive until idle timeout” — it is a tight, training-aware lifecycle that reclaims sandboxes the instant they are no longer needed.
3. Mitigating Agent Misbehavior (Including Reward Hacking)
The paper explicitly notes that DSec mitigates agent misbehavior such as reward hacking. This is the dark side of agentic RL — agents learn to exploit the environment in ways that maximize reward without accomplishing the intended task. A sandbox layer that observes every action an agent takes is in a uniquely strong position to detect and block these patterns. DSec’s position as the execution substrate gives it the visibility to enforce behavioral guardrails that the RL framework alone cannot.
The Production Numbers
The most striking part of the disclosure is the scale at which DSec runs in production:
| Metric | Value |
|---|---|
| Nodes per production-scale unit | ~160 |
| Sandboxes served per day | ~3,000,000 |
| Concurrent sandboxes in production | 380,000+ |
| Peak sandbox creation rate | 5,000+ per second |
To put those numbers in perspective:
- 3 million sandboxes per day is roughly 35 sandboxes per second sustained. That is the rate at which agent rollouts are spawned, executed, and destroyed in DeepSeek’s training pipeline.
- 380,000 concurrent sandboxes means that at any given moment, nearly 400,000 isolated agent environments are alive across the cluster — each one potentially running a different agent, on a different task, with different state.
- 5,000 creations per second peak is the burst capacity. When a rollout phase begins, DSec must be able to spawn 5,000 sandboxes per second without collapsing. That is the difference between an agentic RL pipeline that trains in hours and one that trains in weeks.
These numbers are why V4.1 Flash exists. The asymmetric architecture that beat V4-Pro was discovered through large-scale agentic RL — and large-scale agentic RL is only possible on infrastructure that can serve millions of sandboxes per day at this concurrency.
Why the Public Disclosure Matters
DeepSeek had been running DSec internally since the V3.2 training cycle. The September 19, 2026 arXiv paper is the first time the architecture, the backends, the layer composition, the 3FS integration, the RL co-design, and the production numbers were publicly documented.
The disclosure matters for three reasons.
1. It opens the path for the open-source ecosystem. DSec’s design — unified SDK over heterogeneous backends, layered composition, on-demand image loading from a cluster filesystem, RL-coordinated lifecycle — is a blueprint. Any lab building large-scale agentic RL training now has a reference architecture that is proven at production scale. This is the same gift DeepSeek gave the world with V3’s open weights, applied to infrastructure instead of model parameters.
2. It reframes the agent-training infrastructure conversation. Before DSec, the agent-training infrastructure conversation was fragmented — every lab had its own ad-hoc sandbox layer, and none of them talked to each other. DSec provides a vocabulary (FnCall / container / microVM / full-VM backends, versioned-layer composition, RL-aware lifecycle) that the entire field can now share. Expect every serious agent-training infrastructure to adopt some subset of this vocabulary over the next 18 months.
3. It reveals the second half of the V4.1 Flash story. V4.1 Flash’s architecture is half the story. The other half is that the model was trained on infrastructure that could serve 3 million agent sandboxes per day. The architecture made the model efficient. The infrastructure made the architecture discoverable. Without DSec, there is no V4.1 Flash — there is only V4-Pro, still symmetric, still expensive, still retired by something it cannot match.
What DSec Tells Us About the Next Phase
The DSec disclosure is, in some ways, more significant than any single model release. Models come and go — V4-Pro is already retired, V4.1 Flash will be replaced in turn. But the infrastructure that trains them compounds. DSec is the layer DeepSeek will build every future model on, from V4.1 Pro to whatever comes after.
Three predictions follow.
First, agent-training infrastructure is the new moat. Model weights are open. Architectures are published. The thing that is hard to replicate is the production sandbox platform that can serve 3 million agent environments per day at 380,000 concurrent. That is a moat built from systems engineering, not from capital or parameter count.
Second, the 3FS integration will be copied. On-demand image loading from a cluster-wide filesystem is the kind of detail that, once published, every other platform will adopt — because the alternative (pre-staging images on every node) does not scale to hundreds of thousands of concurrent sandboxes.
Third, RL-aware sandbox lifecycle will become the default. The decoupling of stateful rollout from preemptible GPU training is too economically important to remain a DeepSeek-specific optimization. Every agentic RL framework will need it. The question is whether the open-source community builds it, or whether DeepSeek open-sources DSec itself — as it has open-sourced every other layer of its stack.
The Infrastructure That Made V4 Possible
DeepThink V4.1 Flash is the model the industry will remember. DSec is the infrastructure that made it possible. The first public disclosure of that infrastructure — the backends, the layers, the filesystem, the RL co-design, the production numbers — is, in its own way, as consequential as the model release itself.
Models are the proof. Infrastructure is the moat. DSec is both.