DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale
Abstract
DeepSeek Elastic Compute is a production sandbox platform that unifies multiple isolation backends, coordinates distributed lifecycle management, and integrates with reinforcement learning training to support large-scale agentic LLM workloads.
Large-scale agentic training and evaluation with large language models (LLMs) rely on isolated, stateful execution environments in which models inspect repositories, invoke tools, execute commands, and interact with task-specific services. These workloads create sandboxes in large bursts, span heterogeneous functionality and isolation requirements, retain state across long interactions, and draw from large image corpora with limited reuse. Supporting them therefore requires an elastic execution platform rather than a single sandbox runtime. This report presents DeepSeek Elastic Compute (DSec), a production sandbox platform that exposes FnCall, container, microVM, and full-VM sandbox backends through a unified SDK. DSec coordinates placement and lifecycle management across the cluster, composes environments from independently versioned layers, combines memory sharing, reclamation, and CPU scheduling for high-density execution, and loads image data on demand from Fire-Flyer File System (3FS), a cluster-wide distributed filesystem. DSec is co-designed with the reinforcement learning (RL) framework, decouples stateful rollout execution from preemptible GPU training, coordinates sandbox lifecycle with training to preserve rollout state while reclaiming idle resources, and mitigates agent misbehavior such as reward hacking. A single production-scale unit of DSec spans around 160 nodes, serving about 3 million sandboxes per day; in production, it supports over 380,000 concurrent sandboxes and sustains over 5,000 sandbox creations per second. Our evaluation and deployment experience show that these mechanisms reduce environment setup and image-distribution overhead, improve memory efficiency, and preserve latency-sensitive performance under high-density overcommit.
Community
We built an independent, open-source implementation of the architecture described in this paper: OpenDsec — https://github.com/Kernflux/opendsec
To be explicit up front: this is not DeepSeek code, it is not an official release, and it is not affiliated with or endorsed by the authors. The architecture and most design decisions come from the report; where the paper leaves something open or we chose differently, docs/SPEC.md marks each point as either taken from the paper (with the section) or our own decision.
What we implemented:
- Control plane: a stateless apiserver handling auth, quota and placement; a Raft-replicated IAM holding identities, projects and quotas; a watcher aggregating per-node health; and an edge daemon per compute node that makes the final admission decision. Components talk over gRPC with mTLS, and the sandbox id encodes its edge, so the apiserver keeps no per-sandbox routing state.
- Backends: Firecracker microVM, container, and full QEMU VM.
- In-sandbox: Aether for the runtime channel, Chronus for persistent shell sessions; exec, files, HTTP, processes and PTY share one runtime API.
- Lifecycle: pause to a memory snapshot, restore, and
forka running microVM with memory preserved. Same-node forks share pages; cross-node forks pull the snapshot from the source node. - Images: import from any OCI registry, compose layers without copying data, and pack a sandbox diff back into a new image.
- Network: default-deny with per-sandbox domain/CIDR/port rules, enforced with nftables and a DNS proxy rather than eBPF.
- Compatibility: an E2B-compatible gateway, so existing E2B SDK clients can point at a self-hosted deployment.
Two deviations worth naming: we use a generic shared filesystem (NFS/CephFS/JuiceFS) instead of 3FS, and Firecracker is our primary backend rather than one option among several.
All numbers we quote are our own measurements on our hardware, not figures from the paper — for example ~0.1 s microVM cold start, ~55 ms snapshot restore, a 5,120-microVM burst on one 384-thread node, and 8,192 containers across two nodes. Measurement conditions are in the repo, and docs/SPEC.md states them alongside the design.
Happy to answer questions about any part of the implementation, especially where we had to make a call the paper did not settle.
Get this paper in your agent:
hf papers read 2609.22978 Don't have the latest CLI?
curl -LsSf https://hf.co/cli/install.sh | bash Models citing this paper 0
No model linking this paper
Datasets citing this paper 0
No dataset linking this paper