DeepSeek Elastic Compute (DSec)

What it claims

DSec is DeepSeek's production sandbox platform for agentic RL rollouts and evaluation. It exposes four backends (FnCall, Docker containers, Firecracker microVMs, QEMU full VMs) through one Python SDK, libdsec. The summary covers aggregate throughput. The page adds the figures that size the problem:

• A single job may request up to 32K sandboxes.
• A single node hosts up to 800 microVMs or 3,200 containers, made possible by CPU overcommit while sandboxes wait on the LLM.
• One scale unit is about 160 CPU nodes, roughly 30K cores and about 250 TB of DRAM, managing petabytes of layers and images.
• Multiple scale units share a single 3FS deployment.

How it works

The SDK is deliberately not a semantic abstraction over the backends. The caller must pick the backend, because startup cost, isolation, filesystem semantics and OS capability differ. The page maps backends to workloads:

In production, containers and microVMs dominate both instance count and resource use.

For containers and microVMs, environments are composed from a base image plus independently versioned task workspace and toolkit layers. Full VMs use prepared images or snapshots.

flowchart LR
  SDK[libdsec SDK] --> IAM[IAM / API Server]
  IAM --> PE[Placement Engine]
  W[Watcher: worker health] --> PE
  PE --> NR[Per-node runtime: Edge, Aether, Chronus]
  NR --> F[FnCall]
  NR --> C[Container]
  NR --> M[MicroVM]
  NR --> V[Full VM]
  FS[(3FS: EROFS / OverlayBD images)] --> NR

The per-node runtime components divide the work:

• Edge: lifecycle management.
• Aether: session management.
• Chronus: exec, file and HTTP.

Isolation uses AppArmor plus eBPF. Images load on demand from 3FS rather than being pulled from a registry. RL co-design keeps rollout state alive across GPU-training preemption and reclaims idle resources. It also applies per-task network policy and access controls against agent misbehavior such as reward hacking.

Evidence

• Image loading: In the paper's ablation, eager image pulling stretched completion time by 1.7× compared with on-demand loading. On-demand loading also cut cumulative disk writes by 57%. The visible text does not state the workload or cluster setting for this ablation.
• Other mechanisms: Results for memory sharing and reclamation and for latency under overcommit are only asserted qualitatively in the abstract. The §8 evaluation is not in the fetched text.

How to use it

The page shows the SDK shape (Listing 1), verbatim:

client = DSecClient()
await client.open()
args = DSecContainerRunArgs(
container_image="registry.../sphinx-9658:official",
memory_limit_mb=4096, cpu_cores_limit=4,
ttl_running_stop=300,# idle timeout
network_rules={"npm": False, "pypi": True},
init_user="root",
)
sandbox = await client.run_container(args, timeout=120)
result = await sandbox.run_shell("echo hello world")
await sandbox.stop()

The API is async. A request carries:

• the image
• CPU and memory limits
• an idle TTL
• per-registry network allow/deny rules
• the initial user

Sessions are stateful across calls. A sandbox is reclaimed when stopped explicitly or when its TTL elapses.

Limits

• Truncated text: The fetched text stops partway through §3 (architecture). The sections on workload characterization, mechanisms, RL co-design, implementation and evaluation (§4–§8) are not visible, so their details and numbers are not covered here.
• No release information: The visible text says nothing about whether libdsec or any DSec component is publicly released, and gives no licence. Treat this as a design report, not an adoptable tool, until that is confirmed.
• Container isolation: The authors state that containers share the host kernel and are not always appropriate for security-sensitive tasks.
• Backend choice: The SDK leaves backend selection to the caller.
• Untrusted agents: The page flags that agents may corrupt filesystems, exhaust resources or interfere with co-located workloads.