⏱️ Reading time: 11 min
DeepSeek DSec sustains 380,000 active sandboxes at the same time within its agentic training infrastructure, and creates more than 5,000 new ones per second when training traffic spikes. That figure appears in a technical paper published on September 19, 2026 that describes DeepSeek DSec (DeepSeek Elastic Compute), the platform the company uses internally to train agents with reinforcement learning (RL) at scale.
📑 En este artículo
The document, 31 pages long and signed by more than 130 authors, explains how DeepSeek solves a problem that few companies face at this scale: creating, maintaining, and destroying millions of isolated environments per day without slowing down GPU training.
TL;DR
- DeepSeek published the DSec paper (arXiv:2609.22978) on September 19, 2026, with 31 pages and 13 figures.
- A single DSec production unit uses about 160 nodes and processes close to 3 million sandboxes per day.
- The system sustains more than 380,000 concurrent sandboxes and creates more than 5,000 per second in production.
- DSec unifies four isolation backends (FnCall, containers, microVM, and full VM) under a single SDK.
- Environment images are loaded on demand from 3FS, DeepSeek’s distributed file system.
- The design separates the stateful rollout from the training GPUs, which can be interrupted without losing context.
- DSec includes mechanisms against reward hacking, when an agent exploits the environment instead of solving the task.
- The work expanded from a two-page summary reviewed for ACM SIGOPS ATC 2026.
What happened
On September 19, 2026, a DeepSeek team led by Jialiang Huang and Wenfeng Liang uploaded to arXiv the paper “DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale.” The document describes a production system, not an academic prototype: DSec already runs in DeepSeek’s clusters and sustains the training of its models with agentic RL, the technique that teaches a model to use tools, run commands, and navigate code repositories instead of just predicting text.
According to the paper, the current version is a substantial expansion of a two-page summary that had passed the first review round of the operating systems track at ACM SIGOPS ATC 2026. DeepSeek decided to publish the full detail of its infrastructure instead of sticking with the short summary, something unusual for systems papers from major AI companies.
Context and history
Training with agentic RL changes the rules compared to classic supervised training. To teach a model to fix a bug in a repository, it needs a real environment: a file system, a terminal, an interpreter, and sometimes external services to interact with. Each training attempt, each rollout, needs its own isolated environment, because an agent running arbitrary commands can break another one’s state if they share the same space.
That’s where the scale problem shows up: training a large model involves millions of these rollouts per day, each with its own sandbox. Traditional sandboxing runtimes, designed to run a serverless function or a continuous integration container, weren’t built for massive creation bursts, for retaining state during long interactions, or for loading images from a catalog of tens of thousands of variants with little reuse between them. DeepSeek had already shown before how it tackles this kind of bottleneck: in 2025 it open sourced 3FS (Fire-Flyer File System), the distributed file system that now feeds data to DeepSeek DSec on demand.
Technical details of DeepSeek DSec and its performance
DSec exposes four distinct sandbox backends behind a single SDK: FnCall, containers, microVM, and full VM. The core idea is that not every task needs the same level of isolation, and forcing all of them through the heaviest path wastes compute that could go toward training.
| Backend | When to use it | Advantage | Limitation |
|---|---|---|---|
| FnCall | Short, stateless tasks, function-calling style | Near-instant startup, minimal overhead | Weaker isolation, not suited for long stateful processes |
| Container | Most agent tasks that run shell commands | Good density/isolation balance, reuses image layers | Shares kernel with the host |
| microVM | Tasks that need strong isolation against untrusted code | Hypervisor-level isolation, its own kernel | Slower startup and more memory per instance |
| Full VM | Environments that replicate a complete machine | Maximum isolation and compatibility | Most costly in density and provisioning time |
To decide which backend to use and where to run it, DSec coordinates the placement and lifecycle of sandboxes across the entire cluster, and composes each environment from independently versioned layers, something similar in spirit to how a container image is built from layers, but designed to reuse pieces across thousands of distinct task variants instead of downloading a full image for every sandbox.
The piece that makes this viable at this scale is 3FS: instead of packaging and distributing the full image of each environment, DeepSeek DSec loads the image data on demand directly from the distributed file system. That reduces how much needs to move over the network when a new sandbox is created, which is exactly the bottleneck when thousands need to be created per second.
flowchart TD
A["GPU RL Training"] --> B["DSec: placement and lifecycle"]
B --> C["FnCall"]
B --> D["Container"]
B --> E["MicroVM"]
B --> F["Full VM"]
C --> G[("3FS: on-demand layer loading")]
D --> G
E --> G
F --> G
B --> H["Idle memory reclamation"]The other axis of the design is density: DSec combines memory sharing, memory reclamation, and CPU scheduling so many sandboxes can coexist on the same node without degrading each other. There’s also a third axis, specific to RL: DSec is co-designed with the training framework to decouple rollout execution (which is stateful and can last minutes or hours) from GPU training (which is preemptible, meaning it can be interrupted and resumed). This lets DeepSeek reclaim idle GPUs for training without losing the state of rollouts still running in sandboxes.
The paper also mentions something rarely documented in public: mechanisms to mitigate reward hacking, the phenomenon where an RL agent finds a shortcut that maximizes reward without actually solving the task, for example deleting tests instead of fixing the code they fail on. That DSec includes safeguards at the infrastructure level, not just at the reward function level, suggests the problem is frequent enough to justify a defense at the sandboxing layer.
💭 Key point: the real bottleneck in agentic RL at this scale isn’t GPU compute: it’s how long it takes for a new environment to appear and how much memory it consumes while the agent uses it.
In production figures, a single DeepSeek DSec unit occupies about 160 nodes and processes close to 3 million sandboxes per day. At peak, the system sustains more than 380,000 concurrent sandboxes and creates more than 5,000 new ones per second. The paper doesn’t publish comparative benchmarks against other sandbox orchestrators; the numbers it does provide are these production-scale figures, verifiable by rereading the paper’s abstract.
How to get started
DSec itself isn’t a public product: the paper documents an internal DeepSeek system, and the unified FnCall, container, microVM, and full VM SDK hasn’t been released. What is open, and useful for understanding firsthand the piece that underpins DSec’s data layer, is 3FS, the distributed file system DeepSeek published as open source.
# Clone 3FS and prepare the build (Linux, requires cmake and a C++ compiler)
git clone https://github.com/deepseek-ai/3FS.git
cd 3FS
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)Building 3FS gives access to the same type of file system that, according to the paper, DeepSeek DSec uses to load sandbox images on demand instead of distributing the full package for every new environment.
To understand the design pattern the paper describes, a single SDK that abstracts several isolation backends, this conceptual outline illustrates the idea, though it isn’t DeepSeek’s actual code:
# Conceptual outline of the pattern described in the DSec paper
# (DeepSeek did not publish the actual SDK; this illustrates the idea)
from dataclasses import dataclass
@dataclass
class SandboxSpec:
backend: str # "fncall" | "container" | "microvm" | "fullvm"
image_layers: list # independently versioned layers
memory_mb: int
reclaimable: bool # whether the scheduler can reclaim idle memory
def request_sandbox(spec: SandboxSpec):
# placement is resolved across the cluster and layers
# are loaded on demand from a 3FS-like filesystem
...To verify that your 3FS build correctly brought up the mount point, the repository itself includes diagnostic tools in its documentation; the minimum reproducible check is confirming the mount responds before relying on it for any image loading.
💡 Tip: if you just want to read the design without compiling anything, the paper’s experimental HTML version on arXiv is lighter to navigate than the 31-page PDF.
Impact and analysis
The DeepSeek DSec paper confirms something the industry has been discussing since 2025: sandboxing infrastructure stopped being an implementation detail and became a research component in its own right. OpenAI, Anthropic, and Google have talked about their own code execution systems for agents, but rarely with the level of operational detail DeepSeek publishes here: nodes per unit, sandboxes per day, creations per second.
That transparency is also a competitive signal. DeepSeek has followed a strategy of opening up pieces of its stack, like 3FS, while keeping the trained model as its main product. Publishing DSec’s design without releasing the code follows that same pattern: it explains the how at the architectural level, without handing over the implementation that took more than 130 engineers to build.
For teams building their own agentic RL pipelines today, whether with open source tools or cloud providers, the paper works as a requirements list that no one had laid out this clearly before: task-configurable isolation, image layer reuse, explicit coordination between the sandbox scheduler and the GPU scheduler, and defenses against reward hacking at the infrastructure layer. That last point in particular rarely appears in RL framework papers, which focus on the reward function rather than the environment that runs it.
The most obvious limitation, and the paper itself doesn’t hide it, is that DSec is designed for DeepSeek’s own hardware and internal network. The figures of 160 nodes per unit and 5,000 creations per second don’t guarantee the same design scales equally well on a smaller cluster or a generic public cloud, where network latency to the distributed file system can be very different from that of an internal datacenter network.
What’s next
The paper was submitted for the first review round of the operating systems track at ACM SIGOPS ATC 2026, organized by USENIX, so it’s reasonable to expect a revised version or a presentation at that conference later in the year. DeepSeek hasn’t announced plans to release the DeepSeek DSec SDK the way it did with 3FS, but the pattern of publishing the paper first and later opening the reusable infrastructure piece has already repeated once.
For the rest of the industry, the paper leaves an open question: if training agents competitively requires sandboxing infrastructure at this scale, how many labs outside big tech have room to build something comparable, and how many will end up depending on a cloud provider packaging this layer as a service.
📖 Summary on Telegram: View summary
If you want to see in practice the open piece behind DeepSeek DSec, clone the 3FS repository and build it today with the commands above.
Frequently Asked Questions
What is DSec, in one sentence?
It’s DeepSeek’s internal platform that creates, coordinates, and destroys sandboxes to train agents with reinforcement learning at scale.
Is DSec open source?
No. The paper describes its design and architecture, but DeepSeek didn’t publish the SDK or backend code. 3FS, the distributed file system DSec depends on to load images, is open.
What sets DSec apart from running regular containers?
DSec doesn’t use a single isolation mechanism: it chooses between FnCall, container, microVM, or full VM depending on how trustworthy the task is, and coordinates that with thousands of simultaneous sandboxes and the training GPU scheduler, something a generic container runtime doesn’t solve on its own.
What is the reward hacking the paper mentions?
It’s when an agent trained with RL finds a way to maximize its reward without actually solving the task, for example manipulating the evaluation environment instead of completing the requested work.
What is 3FS and why does it appear in this paper?
It’s DeepSeek’s distributed file system, released as open source, which DSec uses to load each sandbox’s image data on demand instead of distributing the full image over the network.
Where can I read the full paper?
It’s published on arXiv, with free access to the PDF and the experimental HTML version, at arxiv.org/abs/2609.22978.
References
- arXiv:2609.22978: original paper “DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale.”
- github.com/deepseek-ai/3FS: open source repository for 3FS, the distributed file system that feeds DSec.
- usenix.org: official site of USENIX, the organization behind the ATC conference mentioned in the paper.
- Wikipedia: Reinforcement learning: context on the training technique that underpins DSec’s infrastructure.
📱 Enjoy this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de CDC en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments