Back to feed
News Story
AI前线
1 sources

DeepSeek Unveils DSec Sandbox Infrastructure for V4.1 Agent Training, Liang Wenfeng Listed as Author

DeepSeek, together with Tsinghua University, released a technical report publicly detailing DSec, the industrial-grade sandbox platform that supports agent training from V3.2 to V4.1. The platform can serve about 3 million sandboxes per day, handle peak concurrency of over 380,000, create more than 5,000 sandboxes per second, and launch up to 32,000 sandboxes for a single training task. The report has over 130 authors with Liang Wenfeng listed last, underscoring that agent training infrastructure has become a core engineering priority for DeepSeek.

SynthePulse Insight · AI deep readingMembers

DeepSeek Opens Up Agent Training Substrate DSec: When Reinforcement Learning Starts 'Operating a Computer,' Why Cloud-Native Architecture Fails

Version 1 · 1 source

DeepSeek, together with Tsinghua University, has released a technical report that for the first time discloses DSec, the sandbox infrastructure supporting its training from V3.2 to V4.1. What is truly worth reading in this report is not another set of performance numbers, but a structural contradiction it reveals: agentic reinforcement learning requires execution environments that are stateful, long-lived, and burst-concurrent, while the underlying assumptions of traditional cloud-native architecture are exactly the opposite.

  • DeepSeek, together with Tsinghua University, released a technical report that for the first time discloses DSec, the sandbox infrastructure supporting its training from V3.2 to V4.1; the author team exceeds 130 people, with Liang Wenfeng listed last.
  • One production unit of DSec consists of roughly 160 CPU nodes, 30,000 CPU cores, and 250TB of memory, hosting PB-scale images; it can serve about 3 million sandboxes per day, with peak concurrency exceeding 380,000, a creation speed exceeding 5,000 per second, and a single training task able to spin up as many as 32,000 sandboxes at once.
  • The report states that agentic reinforcement learning and traditional large-model training diverge fundamentally: the latter is closer to 'answering questions,' while the former requires actually operating a computer, and the environment must be stateful and highly coherent.
Open section navigationA Structural Contradiction Exposed by One Report: Agent Training Is Not 'Answering Questions'

A Structural Contradiction Exposed by One Report: Agent Training Is Not 'Answering Questions'

DeepSeek, together with Tsinghua University, released a technical report titled 'DeepSeek Elastic Compute (DSec): Efficient Sandbox Infrastructure for Large-Scale Agent Training,' for the first time publicly disclosing the industrial substrate DSec that supports its training from V3.2 to V4.1. The report's author team exceeds 130 people, with Liang Wenfeng listed last. DSec is DeepSeek's self-developed production-grade elastic compute sandbox platform, an internal dedicated infrastructure that was previously introduced in the DeepSeek-V4 report, whose responsibility is to provide a safe and stable sandbox runtime environment for large-scale training and evaluation of large-model agents.

The report distinguishes the underlying logic of agentic reinforcement learning from that of traditional large-model training: the latter is closer to 'answering questions'—the model is given a prompt or math problem, generates a derivation or answer, and the system computes a reward based on rules and backpropagates; whereas agents oriented toward real software engineering or system operations need to actually operate a computer, retrieving code repositories, configuring dependencies, modifying code, executing tests in a terminal, and continuing to debug based on error messages. This distinction is the starting point for understanding all of DSec's design trade-offs.

The direct constraint this brings is: if, in a single exploration of reinforcement learning, thousands upon thousands of agents are exploring simultaneously, the system must instantly deliver tens of thousands of mutually isolated execution environments that must be stateful and highly coherent. The command an agent executes at step ten must be strictly built upon the files modified, binaries compiled, and processes started in the first nine steps. This is not a problem that can be bypassed with a stateless microservices mindset.

The Triple Mismatch of Traditional Cloud Architecture: Why Kubernetes Doesn't Fit

The report states that traditional container orchestration represented by Kubernetes and stateless Serverless have their underlying assumptions built on smooth scaling and stateless microservices; when facing the high-frequency burst, long-lived, and extremely heterogeneous compute workloads of agentic reinforcement learning, they directly encounter a triple structural mismatch.

The first is transient burst concurrency: a single task can request tens of thousands of sandboxes within seconds (peaking at 32,000), and a full pull-and-decompress will instantly trigger severe write I/O congestion, greatly lengthening startup latency and forcing GPU clusters to sit idle. The second is massive heterogeneity and extremely low reuse: facing over 130TB of environment data, the median image reuse fan-out is only 1 to 3, and conventional local caching mechanisms fail completely. The third is long-lived residency and compute tides: sandboxes live for tens of minutes or even hours, but for 90% of the time CPU utilization is below 5%, making exclusive resource occupancy extremely wasteful, while crude oversubscription easily triggers memory overflow and hyperthread contention.

These three mismatches point to the same conclusion: traditional cloud computing solutions cannot simultaneously achieve high concurrency, strong statefulness, and low cost. DSec's positioning is precisely as dedicated infrastructure built to resolve these contradictions, rather than an optimization of general-purpose cloud solutions.

Free for now

Read the full analysis

4 more sections of analysis, plus the full takeaway

Loading

Credibility boundary

The core facts on which this article is based come from the technical report released by DeepSeek together with Tsinghua University, as relayed by AI Frontline reporting. The existence of the report, the scale of the author team, DSec's platform positioning, the four backend type divisions, the production unit specifications, and the capacity numbers are confirmable factual statements; whereas all performance improvement magnitudes (memory plunging 40.2%, disk writes reduced 57%, task duration shortened by over 40%, long-tail latency suppressed from 45.2% to 17.3%, etc.) as well as judgments such as '90% of sandbox CPUs utilize less than 5%' are all self-reported by the reporting party, lacking independent third-party verification. The capacity data (3 million daily sandboxes, 380,000 peak concurrency) come from a single-source report, with no cross-verification seen. The report does not state whether DSec has already been used for formal V4.1 training, nor does it disclose cost, energy consumption, backend resource proportions, or fault records. Readers should treat the design logic in this article as the reporting party's engineering claims, and treat the performance numbers as self-reported metrics awaiting verification.

Sources for this version

  1. DeepSeek首次公开V4.1 Agent训练"大本营"，梁文锋署名AI前线

Primary report

AI前线

Primary source