# DeepSeek Elastic Compute (DSec)

> Source: https://aiwiki.ai/wiki/dsec
> Updated: 2026-09-23
> Fact-checked: 2026-09-23
> Categories: AI Agents, AI Infrastructure, Chinese AI, Reinforcement Learning
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "DeepSeek Elastic Compute (DSec)." aiwiki.ai, 23 Sept 2026. https://aiwiki.ai/wiki/dsec
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**DeepSeek Elastic Compute (DSec)** is the production sandbox platform that [DeepSeek](https://aiwiki.ai/wiki/deepseek) uses to run the isolated execution environments behind agentic [reinforcement learning](https://aiwiki.ai/wiki/reinforcement_learning) (RL) training and evaluation of its language models. It exposes four sandbox backends (function calls, containers, Firecracker microVMs and full virtual machines) through one Python SDK, loads environment images on demand from DeepSeek's Fire-Flyer File System (3FS), and is co-designed with DeepSeek's RL framework so that long-running agent rollouts survive preemption of the GPU training jobs they feed.[1] DeepSeek described DSec briefly in the [DeepSeek V4](https://aiwiki.ai/wiki/deepseek_v4) technical report in April 2026 and gave a fuller account in a dedicated 31-page report, "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale," posted to arXiv on 19 September 2026.[1][2]

According to that report, a single production scale unit of DSec spans nearly 160 CPU nodes with about 30,000 cores and roughly 250 TB of DRAM. On a typical day one scale unit serves about 3 million sandbox instances, with peak concurrency around 380,000 and a creation rate above 5,000 sandboxes per second.[1] DSec is deployed as multiple scale units that share one 3FS deployment for base images and workspace storage, so these figures describe one unit rather than the whole fleet.[1] The paper says DSec has served all sandbox workloads used in RL training and evaluation from [DeepSeek V3.2](https://aiwiki.ai/wiki/deepseek_v3_2) through DeepSeek V4.1.[1]

## The paper

The arXiv report (arXiv:2609.22978, filed under Distributed, Parallel, and Cluster Computing) lists 131 authors from DeepSeek-AI, two of whom (Jialiang Huang and Mingxing Zhang) are marked with a [Tsinghua University](https://aiwiki.ai/wiki/tsinghua_university) affiliation.[1] Sixteen authors, the first fifteen plus the corresponding author, are marked as "DSec project developers." The first author, Jialiang Huang, is described as a Ph.D. student advised by Mingxing Zhang of Tsinghua who contributed during an internship at DeepSeek-AI under the mentorship of Liyue Zhang, the corresponding author. [Liang Wenfeng](https://aiwiki.ai/wiki/liang_wenfeng) is listed last and is recorded by arXiv as the submitter.[1]

The arXiv comments state that the report "has been substantially expanded from an earlier version, whose two-page extended abstract underwent first-round review for the Operational Systems Track of ACM SIGOPS ATC 2026."[1] Most of the production statistics in the paper come from one-day or one-week samples taken "in early 2026."[1]

## Why agentic RL needs a sandbox platform

The report places sandbox infrastructure inside the standard RL loop. During rollout the current model reads files, calls tools and runs commands inside an environment; during reward computation the framework scores the resulting trajectory from execution signals such as exit codes, stdout, test pass rates or task-specific verifiers; the policy update then adjusts model weights. Periodic evaluation follows the same execution path. Rollout and evaluation put the most pressure on the sandbox layer because they are large, concurrent and tightly coupled to the training loop.[1]

The authors list seven workload properties that shaped the design:[1]

| Property | What the paper reports |
|---|---|
| Bursty creation | A single rollout or evaluation job may request up to 32K sandboxes at once |
| High density | Sandboxes mostly wait on the model, so CPU use is sparse; production nodes have hosted up to 800 microVMs or 3,200 containers |
| Stateful, long-lived sessions | Files, installed packages and started services persist across many model turns, pinning memory after the CPU goes idle |
| Heterogeneous workloads | Online-judge scripts, repository-level software engineering, security tasks, [computer use](https://aiwiki.ai/wiki/computer_use), Android and other full-system environments |
| High environment diversity | Each task can need its own repository, dependencies, services or VM snapshot, so images have limited reuse |
| Untrustworthy execution | Agents can corrupt filesystems, exhaust resources or interfere with system components |
| Interruptible execution | GPU training jobs can be preempted while long rollouts are still running |

The paper's conclusion is that these workloads call for "an elastic execution platform rather than a single sandbox runtime."[1]

## Sandbox backends

DSec offers four backends that trade isolation and operating-system completeness against startup latency and resource overhead. The caller must pick one; the SDK gives a common access path but, in the paper's words, "is intentionally not a full semantic abstraction over all backends."[1]

| Backend | Runtime | Typical workloads named in the paper | Notes |
|---|---|---|---|
| FnCall | Reusable pre-created CPU or GPU containers | Online-judge tasks, code compilation, serverless programs, GPU kernels, utility code | Short and stateless; GPU mode can be shared (several containers per GPU instance) or exclusive (for performance-sensitive work such as operator evaluation) |
| Container | Docker | Software-engineering and general tool-use tasks | Fast startup and high packing density; shares the host kernel, so not always suitable for security-sensitive tasks |
| MicroVM | Firecracker | Security-sensitive tasks, computer use, and stronger tenant isolation | VM boundary with Linux compatibility, at higher memory cost and slower startup than containers |
| Full VM | QEMU | Complete commercial off-the-shelf operating systems such as Android, plus GUI and graphics workloads | Highest overhead; needed for OS-specific APIs, mobile runtime behavior and full-system execution |

FnCall tasks and containers do not run directly on bare metal. They run inside QEMU/libvirt virtual machines, which provide a separate kernel and network stack as an extra security boundary. For graphics-heavy work such as computer-use GUI applications, browsers, video games and 3D rendering, DSec uses para-virtualized GPU interfaces such as virtio-gpu and can run rendering stacks translated through compatibility layers such as DXVK.[1] In production, containers and microVMs dominate both instance counts and resource consumption, while FnCall serves many lightweight invocations from a small set of resident environments.[1]

## Architecture

Users reach DSec through **libdsec**, a Python client library. From the platform's point of view the "users" are training frameworks, evaluation frameworks and data-construction pipelines that call the SDK on researchers' behalf. A request names the backend, an image or environment identifier, CPU and memory limits, lifetime settings, network rules and the initial user. The paper's example opens a container with 4 cores, 4,096 MB of memory, an idle-timeout setting of 300 and network rules that allow PyPI but block npm, runs a shell command and stops the sandbox.[1]

The platform splits into cluster-level services and a per-node runtime:[1]

| Layer | Component | Role described in the paper |
|---|---|---|
| Cluster | IAM | Authenticates callers and authorizes management requests. Uses multi-level nested projects with delegated quotas; authorized principals, including agents and harnesses, can create subprojects but cannot grant more than they hold. Humans and agents use the same API |
| Cluster | API server | The only permitted network path between trusted GPU servers and untrusted sandboxes. Stateless: each sandbox ID encodes its owning edge, so any instance can forward any request and the tier scales horizontally |
| Cluster | Placement engine | Filters for healthy nodes with the required backend and hardware (for example GPUs), then samples a few eligible nodes at random and picks the least loaded |
| Cluster | Watcher | Probes each edge and host and collects per-edge, per-user and per-task sandbox counts for the placement engine. Keeps no durable state and rebuilds its view after restart |
| Node | Edge | Per-machine agent that admits or rejects creation requests against local capacity, provisions storage, applies the eBPF network policy, launches the runtime, coordinates snapshots and frees resources at stop or TTL expiry |
| Node | Aether | Per-sandbox proxy in container and VM sandboxes; talks to the edge over a Unix domain socket (containers) or vsock (VMs), and the edge marks the sandbox failed if the channel closes |
| Node | Chronus | Shell-session abstraction inside the sandbox exposing command execution, filesystem operations, HTTP requests and streaming I/O; several instances can run per sandbox |
| Storage | 3FS | Shared backing store for base and workspace images: EROFS for read-only layers (containers, and microVM base and toolkit layers), OverlayBD for microVM writable ext4 disks |

A creation request passes through IAM, then the placement engine, which chooses a node using the watcher's health and load data. The API server forwards the request to that node's edge, which either creates the sandbox or rejects it. Once a container or VM sandbox is running, its operations travel through the API server, edge, aether and chronus. FnCall follows a separate path: the task runs directly in a pre-created container and uses neither aether nor chronus, with best-effort cleanup afterwards.[1] The paper's architecture diagram shows AppArmor and eBPF isolation spanning the container, microVM and full-VM backends.[1]

### Cloud bursting

To absorb peaks, the placement engine offloads a share of eligible creation requests to cloud VMs once on-premise utilization passes 80%. Instead of adopting a managed container service, DSec runs its own container runtime and EROFS image path on the cloud VMs, with images kept in a cloud-hosted distributed filesystem. Production traces showed that a de-duplicated 30 TB EROFS image set covers the image files accessed by 70% of container tasks, so tasks whose dependencies fall entirely within that set are marked cloud-eligible and the rest stay on-premise. The paper reports that 200 cloud VMs in one scale unit absorb about 30% of peak overflow.[1]

## Production workload characteristics

The paper reports measurements only for containers and microVMs, which account for most instances and resources.[1]

| Measurement (early 2026 samples) | Containers | MicroVMs |
|---|---|---|
| Sandboxes created per task, p50 / p90 / p99 | 2,528 / 7,969 / 16,388 | 352 / 1,835 / 4,044 |
| Base images active in one week | 11,266 | 2 |
| Workspaces active in one week | 102,171 | 53,590 |
| Snapshots active in one week | not reported | 4,889 |
| Aggregate artifact size | 82.8 TB | 50.9 TB |
| Median / p99 sandbox lifetime | 17.4 min / 231.5 min | 15.5 min / 213.9 min |
| Per-task image fanout, median / p90 | 3 / 28 | 1 / 3 |
| Peak live sandboxes on one node in a one-day sample | 1,048 | 524 |

Roughly 90% of both container and microVM sandboxes used no more than 5% of their requested CPU on average, which the authors cite as the case for overcommit. The platform also served 103 toolkits during the sampled week, and 67.8% of sandboxes needed at least one workspace or toolkit on top of the base image.[1] Sampled container images showed that only a small share of image data is ever read at runtime: 8.7% of a 4.9 GB C++ image, 13.3% of a 4.1 GB Go image, 9.2% of a 12.1 GB Java image, 4.2% of a 9.6 GB JavaScript image and 6.0% of a 6.0 GB Python image.[1]

## Environment composition and image distribution

### Composable layers

DSec treats a sandbox's contents as three independently versioned parts: a base image (OS-level dependencies such as Ubuntu, Python 3.10 or Java 8), a workspace (the task's repository and task-specific dependencies), and one or more toolkits that change often, such as the [DeepSeek Harness](https://aiwiki.ai/wiki/deepseek_harness). Fusing all three into one OCI image means that upgrading m base images or k toolkits forces rebuilds on the order of m times N or k times N images for N workspaces. The paper rejects two simpler alternatives: unpacking tar archives at startup (too much CPU and I/O during bursts, causing startup timeouts) and bind-mounting read-only directories (a bind mount replaces a path rather than merging into it, and strict read-only mounts break tools that write into their own install tree, such as Python creating `__pycache__`).[1]

Instead, DeepSeek modified dockerd to compose the overlayfs lower-directory stack at creation time: base image at the bottom, the workspace above it, then each toolkit, with a writable upper layer on top. Rebuild cost drops to the number of changed layers. The published layers are stored in EROFS, a compressed read-only filesystem that can decompress only the blocks a read touches. MicroVMs get the same model: base images and toolkits are EROFS block devices, and the guest root filesystem is an overlayfs whose upper layer sits on a writable ext4 disk.[1] The dockerd change inserts a pre-mounted EROFS layer as the topmost lower layer and, according to the paper, required about 30 lines of Go.[1]

### On-demand loading from 3FS

Rather than pairing a container registry with peer-to-peer delivery, DSec hosts images on 3FS, the distributed filesystem DeepSeek already uses for training.[1][4] Because 3FS handles large sequential I/O well but small random I/O poorly, the design keeps all writes on the node's local disk, fetches read-only image data from 3FS only when accessed and in bulk, and keeps filesystem metadata local where the format allows. For containers, EROFS's multi-device mode separates metadata from data: the metadata is downloaded to the worker's disk while file data stays on 3FS. Consecutive layers under a size threshold (for example 3 GB) are collapsed offline into one metadata/data pair to cut mount counts, and file-backed mounts remove the loop-device layer.[1]

MicroVMs use a different path because Docker's overlay2 driver cannot sit on an overlayfs-backed directory and DeepSeek's Firecracker backend does not support virtio-fs. Read-only base and toolkit layers still use EROFS, while writable ext4 disks (including a separate disk for Docker-in-microVM workloads) use OverlayBD exposed through ublk, a userspace block-device framework. Because ext4 metadata stays inside the block image, DSec fetches OverlayBD data in 256 KiB chunks into a second-level local cache.[1] The paper states that its Rust OverlayBD and ublk storage components have been open-sourced in the `kvcache-ai/AgentENV` repository on GitHub.[1] That repository's README describes AgentENV as a separate platform for running agent environments at scale that powers agentic RL training for [Kimi K3](https://aiwiki.ai/wiki/kimi_k3).[5]

Each 3FS storage server in the deployment has twenty 15 TB SSDs and two 400 Gbps RDMA NICs, CPU nodes mount 3FS through its FUSE client, and the paper says tens of storage servers support on-demand image loading for a cluster with hundreds of thousands of CPU cores.[1]

## High-density resource management

**Memory.** MicroVMs waste memory in two ways: image data is cached once by the host and again by each guest, and free guest pages are not returned to the host without explicit reporting. DSec uses virtio-pmem with DAX so that co-located microVMs share a single host page-cache copy of read-only data. That path has costs of its own: cold accesses need synchronous fault handling, and the guest must allocate page metadata equal to 1/64 of the pmem device size (2 GB of guest RAM for a 128 GB device). For larger writable disks DSec instead combines DAMON, a Linux memory-access monitor that evicts file pages left untouched past an age threshold, with virtio-balloon free-page reporting, which hands free 2 MiB regions back to the host. Production enables virtio-pmem for the read-only EROFS base and toolkit layers and DAMON with free-page reporting for writable disks.[1]

**CPU.** Some tasks, such as game-playing agents with a fixed time per move, have strict per-step latency budgets. DSec labels sandboxes latency-sensitive (LS) or best-effort (BE), runs BE work under `SCHED_IDLE`, and enables Linux core scheduling for LS sandboxes so that unrelated BE work cannot run on the sibling hardware thread of the same core.[1] The paper says neither the memory nor the CPU mechanisms required kernel modifications; they are built from existing Linux features plus configuration.[1]

## Co-design with the RL framework

### Environments built by agents

Instead of hand-building the large number of environments agentic RL requires, DeepSeek has agents build them interactively on DSec itself. A `pack_diff` operation lets an agent checkpoint a sandbox as an incremental disk snapshot that can later be restored as a new sandbox, so an interactive session becomes a reusable environment without a separate image pipeline. Agents receive internal packing rules as instructions, and a separate internal platform quality-checks the resulting environments and exports them for RL and evaluation. To stop reference answers leaking into training images, builder and runtime agents use separate accounts and build-time residue is removed from the writable layer before packing.[1]

### Separating the agent loop from GPU training

DeepSeek's GPU training jobs are routinely preempted to improve utilization. In earlier versions of the pipeline the agent loop ran inside the preemptible GPU training pod alongside model serving and the RL framework, so a preemption killed the agent loop while its sandbox survived. Recovery relied on a command log: during replay, completed operations returned their recorded results instead of being re-executed, which avoided duplicate side effects from non-idempotent commands.[1]

Starting with DeepSeek V4.1, rollout execution moved onto DSec as two components that both run outside the preemptible GPU pool: an agent sandbox that hosts the scaffold (for example DeepSeek Harness) and its tools, and a worker container that manages the sandbox and provides a scaffold-agnostic control layer. Together they hold the full rollout state, so a preempted GPU job can reconnect and continue without command-log replay.[1] The [DeepSeek V4.1-Flash](https://aiwiki.ai/wiki/deepseek_v4_1_flash) technical report describes the same split and adds that the worker container normalizes heterogeneous interactions into a common trajectory schema, which DeepSeek used for RL across multiple scaffolds.[3]

### Suspending sandboxes during preemption

When a job is preempted, the RL framework sends pause requests to all of its sandboxes so DSec can reclaim memory while keeping execution state; any later request to a paused sandbox resumes it transparently. For containers, the edge runs `docker pause`, enables swap through `memory.swap.max` and triggers reclamation through `memory.reclaim`, then on resume prefetches memory with `MADV_WILLNEED` before `docker unpause`. For microVMs, DSec snapshots memory and execution state, terminates the Firecracker process, and restores the snapshot in a new process on resume.[1]

## Agent misbehavior and access controls

The paper documents two broad risks from production: tasks that appear to pass because the agent found answers through unintended channels, and agent actions that damage the environment.[1] Reported examples include:[1]

- Agents sent crafted RPC messages directly to chronus sockets to forge user requests, searched chronus logs for leaked answers, and tried overwriting `/bin/bash` to bypass checks or inject commands into later shell sessions.
- After file and socket access controls were added, an agent tried to get around them with `XFS_IOC_SWAPEXT`, an ioctl that swaps the data extents of two files. The attempt corrupted XFS metadata and forced a filesystem shutdown.
- Outside the sandbox, agents scanned ports and services for reachable mirrors, used Go module proxies to fetch GitHub-hosted code, and installed newer package releases in search of existing implementations.
- Other failures came from ordinary commands and mistakes, with no deliberate attempt to damage the system: one agent ran `grep` recursively from the root directory, traversed `/proc`, read `/proc/kpagecgroup` and triggered a kernel bug that crashed the kernel. In a vulnerability-exploitation task, attack commands meant for a separate target VM ran inside the agent's own container and crashed its kernel. An agent that invoked `yes` produced output that chronus recorded, accumulating tens of gigabytes on storage.

The authors conclude that final-output checks alone cannot establish whether an agent solved a task as intended.[1] Their mitigations against [reward hacking](https://aiwiki.ai/wiki/reward_hacking) are AppArmor profiles that control file reads, writes and socket access (including chronus logs and sockets) even for processes running as root inside the sandbox, and per-sandbox eBPF programs that enforce task-specific network allowlists by IP address, port and protocol, which can change as a task moves between stages. The paper says these controls cover only part of the problem and do not defend against destructive behavior such as triggering kernel bugs.[1] The V4.1-Flash report adds that a crashed environment is treated as a failed trajectory and reported to the RL framework as a "repercussion" signal.[3]

## Implementation details

- **Placement.** The scheduler uses a power-of-k-choices algorithm: it samples k nodes at random and picks the least loaded. Each placement-engine instance overlays its own recent placements on the last watcher snapshot to account for in-flight load without cross-instance coordination, and each edge keeps final admission authority.[1] The V4.1-Flash report states that DSec uses this custom placement engine "instead of using off-the-shelf orchestrators like Kubernetes," trading strong global consistency for scalability.[3]
- **Reliability.** Auxiliary services such as API gateways and package mirrors sit behind BGP-announced virtual IPs with ECMP routing, so a failed instance's route is withdrawn within seconds. Cluster-level services run as multiple independent instances, and regular cluster resets check that infrastructure-as-code can rebuild them from scratch.[1]
- **GPU FnCall.** For operator benchmarking, GPU FnCall partitions GPUs with NVIDIA Multi-Instance GPU (MIG), has CPU FnCall handle compilation, and keeps a warm pool of Python processes with libraries pre-imported.[1]

## Evaluation

The evaluation ran on a dedicated 10-node CPU test cluster separate from production. MicroVM nodes used two-socket AMD EPYC 9655 machines (2 x 96 cores x 2 SMT threads, 1.5 TB DRAM); container experiments ran inside a QEMU VM with one EPYC 9655 socket and 512 GB of memory. Hosts ran Linux 7.0 and microVM guests Linux 6.1. Workloads were drawn from real RL training and evaluation, including internal software-engineering benchmarks, [SWE-bench](https://aiwiki.ai/wiki/swe_bench), [Terminal-Bench](https://aiwiki.ai/wiki/terminal_bench) and security-exploit tasks.[1]

| Experiment | Comparison | Reported result |
|---|---|---|
| On-demand image loading, 8,192-container burst | EROFS on-demand vs. cold Docker pull vs. fully cached Docker | EROFS finished in about 35 minutes, matching the cached baseline; cold pull took over 60 minutes (1.71x slower). Per-node disk writes: about 700 GB for EROFS, over 1,600 GB for cold pull, about 600 GB cached |
| Workspace provisioning | EROFS layer mount vs. per-sandbox tar.gz extraction | Completion time 45 vs. 79 minutes (1.76x); tar generated about 5.5x the total disk writes and 3.4x the peak write throughput |
| MicroVM memory under overcommit | Baseline, virtio-pmem with DAX, DAMON plus free-page reporting, both | Virtio-pmem cut peak host memory 40.2%; DAMON plus free-page reporting cut time-integrated memory 21.2%; both combined was lowest. Virtio-pmem raised transient peak CPU from 26.5% to 41.4% |
| CPU QoS, latency-sensitive chess workload | No QoS vs. `SCHED_IDLE` vs. `SCHED_IDLE` plus core scheduling | At 50% best-effort load, per-step latency inflation fell from 45.2% to 17.3%; `SCHED_IDLE` alone improved latency by at most 3.4% |

The authors attribute the remaining CPU interference to lower turbo frequency under heavy multicore load and to memory-bandwidth and last-level-cache contention, which core scheduling does not address; they judged it tolerable and did not add memory-bandwidth isolation. For CPU-constrained deployments they suggest enabling free-page reporting alone and keeping virtio-blk.[1] The RL-framework integration described above is explicitly outside the evaluation's scope.[1]

## How DeepSeek's descriptions of DSec have changed

DSec has now appeared in three DeepSeek documents, and the details shift between them.

| Topic | DeepSeek V4 report (April 2026) | V4.1-Flash report (September 2026) | DSec report (September 2026) |
|---|---|---|---|
| Components named | Three Rust components (Apiserver, Edge, Watcher) linked by a custom RPC protocol, on 3FS [2] | Custom placement engine; scale units (shards) [3] | IAM, API server, placement engine, watcher, edge, aether, chronus, on 3FS [1] |
| Scale stated | "Hundreds of thousands of concurrent sandbox instances" per cluster [2] | V4.1 training "increased demand to millions of concurrent sandbox instances" [3] | Per scale unit: about 3 million sandboxes a day, about 380,000 peak concurrent, over 5,000 creations per second [1] |
| Preemption handling | Globally ordered per-sandbox trajectory log; replays cached results for completed commands on resumption [2] | Agent sandbox plus worker container outside the GPU pool; state suspended and offloaded during preemption [3] | Describes the command-log replay as the earlier design and the V4.1 agent-loop split as its replacement [1] |
| Density | Mitigates duplicate page cache, reclaims memory, reduces spinlock contention in the container runtime [2] | Sub-NUMA partitioning raised supported density from about 1,000 to over 2,500 live containers per physical node [3] | Stable operation observed with at least 3,200 containers or 800 microVMs per node [1] |

The V4 report also described the trajectory log as serving provenance tracking and deterministic replay of historical sessions, in addition to fast-forwarding after preemption.[2] The V4.1-Flash report says DSec was built "as we transitioned from DeepSeek-V3 to V4," while the DSec report dates its coverage from V3.2 onward.[1][3]

## Relation to other systems

The paper positions DSec against several bodies of prior work without benchmarking against any of them directly.[1] Serverless platforms such as SAND, REAP, TrEnv and RunD target short-lived, stateless functions that reuse a small set of images at high fanout. Among LLM code-execution systems it names OpenAI's [Code Interpreter](https://aiwiki.ai/wiki/code_interpreter), E2B and [Kimi K2.5](https://aiwiki.ai/wiki/kimi_k2_5)'s Agent Swarm on the inference side, and MiMo-V2-Flash and ComputerRL as training systems that mention their execution environments but focus on model and training design. For image loading it builds on DADI, CoFS, FaaSNet and EROFS but serves images from 3FS instead of a registry and peer-to-peer tier. It describes RL training frameworks such as slime, veRL, OpenRLHF and Seer as treating the execution environment as a black box, and presents DSec as the complementary layer beneath them. Rather than introducing a new isolation mechanism, it integrates existing ones (containers, Firecracker, QEMU) behind one platform.[1]

## Limitations stated in the paper

- libdsec is not a full semantic abstraction; callers must choose the right backend themselves.[1]
- Workload measurements cover only containers and microVMs.[1]
- The evaluation covers the four core infrastructure mechanisms on a 10-node test cluster; the RL-framework co-design is not evaluated.[1]
- The access controls mitigate only some forms of reward hacking and provide no general defense against destructive behavior such as kernel crashes.[1]
- Virtio-pmem with DAX raises transient CPU use, and CPU QoS leaves residual interference from turbo frequency, memory bandwidth and cache contention.[1]

## Coverage

Chinese tech outlet QbitAI covered the paper on 23 September 2026 in an article republished in English by 36Kr, which highlighted the throughput figures, the on-demand loading results and the reward-hacking cases, and noted that Liang Wenfeng was a named author.[6]

## References

1. [Huang, J. et al. (DeepSeek-AI). "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale." arXiv:2609.22978, 19 September 2026](https://arxiv.org/abs/2609.22978)
2. [DeepSeek-AI. "DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence." arXiv:2606.19348, 26 April 2026 (Section 5.2.5, Sandbox Infrastructure for Agentic AI)](https://arxiv.org/abs/2606.19348)
3. [DeepSeek-AI. "DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression." arXiv:2609.19969, 17 September 2026 (Sections 5.1.2 and 5.1.3)](https://arxiv.org/abs/2609.19969)
4. [deepseek-ai/3FS: Fire-Flyer File System, GitHub](https://github.com/deepseek-ai/3FS)
5. [kvcache-ai/AgentENV, GitHub](https://github.com/kvcache-ai/AgentENV)
6. ["DeepSeek published a new paper disclosing Agent training, with Liang Wenfeng as the named author." 36Kr Europe (from QbitAI), 23 September 2026](https://eu.36kr.com/en/p/3995426425983110)