TL;DR

DeepSeek Elastic Compute separates stateful agent execution from preemptible GPU training. Its sandbox platform combines on-demand image loading, composable filesystem layers, memory reclamation, and CPU scheduling to support large bursts of long-running agent workloads.

Why it matters

Environment startup, retained rollout state, and idle sandbox memory can limit agentic RL throughput even when model inference is fast. DSec documents how a production execution platform addresses these constraints independently of the policy-training algorithm.

Key findings

  1. 01

    The authors report that one production unit spans nearly 160 CPU nodes, serves about 3 million sandbox instances per day, reaches roughly 380,000 concurrent sandboxes, and exceeds 5,000 creations per second. These are deployment observations, separate from the 10-node evaluation cluster.

  2. 02

    For an 8,192-container burst in the evaluation cluster, on-demand EROFS image loading completes the workload in about 35 minutes versus over 60 minutes for cold eager Docker pulling. Reported disk writes fall from over 1,600 GB to about 700 GB per node.

  3. 03

    In a separate workspace-provisioning experiment with prerecorded tool calls replacing LLM generation, composable EROFS layers reduce completion time from 79 to 45 minutes versus tar extraction, a reported 1.76× speedup.

  4. 04

    The system moves the agent loop and its worker outside the preemptible GPU pool so training can reconnect to preserved rollout state. Complementary memory mechanisms share guest page-cache data and reclaim idle pages; virtio-pmem with DAX reduces peak host memory by 40.2% in the reported Firecracker comparison.

  • The measured experiments cover infrastructure mechanisms on a dedicated 10-node CPU cluster. RL-framework integration is explicitly outside their evaluation scope; these numbers are not end-to-end RL training speedups or model-quality gains.

  • Production concurrency and creation rates are author-reported deployment figures, not independently reproduced benchmark results. Hardware, image distributions, and workload reuse affect transfer to other systems.

  • The 1.76× provisioning result uses deterministic prerecorded tool calls, and the 40.2% memory result compares specific Firecracker configurations. Neither should be generalized to arbitrary agent workloads.

  • Memory sharing can increase transient CPU utilization. CPU isolation also leaves interference from turbo frequency, memory bandwidth, and shared cache; the report does not establish zero-overhead isolation.

Scaling dimensions

Models, methods & benchmarks

Algorithms
On-demand image loading, Stateful rollout execution, Sandbox memory reclamation
Benchmarks
Infrastructure workloads, SWE-bench, Terminal-Bench

Topics

Read the original sourcearXiv ↗