Nimendra's Notes 🪴

DeepSeek Elastic Compute (DSec)

Properties1
descriptionDeepSeek’s DSec platform provides isolated, stateful sandboxes for agent training.

7 min read

ai agents deepseek reading/researchpaper distributedsystem cloud

AI Agent Sandbox

Agent sandboxes need a computer

An AI agent may inspect a repository, edit files, install packages, run tests, read failures, and repeat. Each action relies on state from earlier steps.

Think of the LLM as the brain and the DSec sandbox as the temporary computer it operates.

The sandbox keeps files, dependencies, and services available between actions. It may sit idle while the model generates its next action, yet a training job can request thousands of sandboxes at once. Tasks also vary in OS, tooling, and isolation requirements.

DSec must launch these environments quickly, control resource use, isolate untrusted work, and preserve rollout state through training interruptions.

Workload demands

These workloads set six requirements for the sandbox:

  • Bursty creation: A production job can request up to 32,000 sandboxes. Slow placement and setup delay rollouts.
  • Sparse CPU use: About 90% of container and microVM sandboxes use no more than 5% of their requested CPU capacity on average. DSec can overcommit CPU, but it must still manage memory use and interference.
  • Long-lived state: Median sandbox lifetimes are 15–17 minutes, and the 99th percentile exceeds three hours. CPU may sit idle while the sandbox retains memory, caches, and modified files.
  • Many distinct environments: In one production week, DSec served over 100,000 container workspaces and more than 50,000 microVM workspaces. Different tasks often used different images.
  • Untrusted actions: Agents can exhaust resources, damage their environment, seek answers through unintended channels, or trigger host and guest bugs.
  • Training interruptions: GPU jobs may be preempted during a rollout. DSec must preserve the environment and agent state so training can resume.

FnCall and containers favor startup speed and density. MicroVMs and full VMs provide stronger isolation or broader OS support.

DSec architecture

Running FnCall and containers inside QEMU/libvirt VMs adds a guest-kernel and network boundary between untrusted workloads and bare metal.

SDK interface

Sandbox backends

BackendMain purposeStrengthLimitation
FnCallShort, mostly stateless jobs such as online-judge tasks, compilation, utility code, and GPU kernelsLowest startup overhead because it uses pre-created containersNot intended for long-lived, stateful agent sessions
ContainerSoftware-engineering and general tool-use agentsFast startup and very high packing densityShares the host kernel, so isolation is weaker
MicroVMSecurity-sensitive tasks and workloads needing a VM boundaryStronger isolation while keeping Linux compatibilityMore memory overhead and slower startup than containers
Full VMAndroid, GUI, graphics, or workloads requiring a complete OSFull operating-system functionality and strongest system fidelityHighest resource overhead

Compose environments instead of rebuilding them

A task environment combines:

Base OS + workspace/repository + toolkit + agent’s runtime writes

A monolithic image bundles these parts together, so a toolkit change can require rebuilding every workspace image that contains it. DSec stores the base image, workspace, and toolkits in independently versioned layers, then combines them at startup. Operators can update one layer without rebuilding each workspace.

For containers, DSec uses OverlayFS to merge read-only lower layers and direct runtime writes to a writable upper layer. The immutable layers use EROFS, a read-only filesystem with compression and random access. MicroVMs use read-only EROFS layers too, with a writable ext4 disk on top.

Why use filesystem layers?

A compressed archive must be unpacked into each sandbox. That repeats CPU work and disk writes during a burst. DSec can mount a read-only filesystem layer without extracting every file for every sandbox.

Load image data on demand

Runtime access touched only 4.2%–13.3% of the data in the sampled language images. Fetching every image in full would move data the task never reads.

DSec stores image data on 3FS and fetches read-only data on demand. It keeps small, irregular writes on local storage. For container images, metadata stays local where possible and file data arrives in larger chunks. MicroVM writable disks use OverlayBD with local caching to reduce repeated remote reads.

On-demand Container Loading in AWS Lambda also loads image data on demand. Lambda deduplicates flattened blocks across images; DSec fetches EROFS data from 3FS and composes versioned layers.

Manage CPU and memory at high density

The paper reports production operation at 3,200 containers or 800 microVMs per node. These are observed operating points, not hard limits.

While the model chooses its next action, sandboxes can retain file caches and process state. MicroVM file data may be cached on both the host and guest, so idle CPU does not free that memory.

Memory

For memory reclamation, DSec uses two mechanisms:

  • virtio-pmem with DAX maps read-only image data through host-backed pages, reducing duplicate host/guest page caching.
  • DAMON plus virtio-balloon free-page reporting identifies cold guest pages, reclaims them inside the guest, then reports free memory back to the host.

CPU quality of service

DSec separates workloads into latency-sensitive (LS) and best-effort (BE) classes. BE work runs with Linux SCHED_IDLE, so it yields to LS work. Linux core scheduling also prevents unrelated BE work from running on the sibling SMT thread of the same physical core as an LS task.

Preserve rollouts across training preemption

A rollout depends on earlier actions: inspect files, edit, run tests, read the output, then continue. If preemption stops the agent loop, recovery must preserve that state without rerunning commands that have side effects.

DSec runs the agent loop outside the preemptible GPU pool. An agent sandbox hosts the scaffold and tools; a worker container manages the sandbox and coordinates the rollout. The resumed training job can reconnect to the retained state.

When training pauses, the RL framework can ask DSec to suspend sandboxes and reclaim memory:

  • Containers: DSec pauses the process tree, enables swapping, and reclaims memory. On resume, it prefetches data asynchronously and unpauses the container.
  • MicroVMs: DSec snapshots guest memory and execution state, then terminates the Firecracker process. It restores the snapshot when the sandbox is needed again.

Like Durable Execution, DSec lets workflow progress outlive a process or training job. The worker and sandbox retain live state, so recovery does not replay completed actions.

Security boundaries for untrusted agents

The authors report agent attempts to inspect logs for residual answers, forge internal requests, bypass file protections, and reach unintended external sources. Agents also crashed kernels or filled storage with large command outputs, sometimes by accident and sometimes while pursuing a task.

DSec applies several controls:

  • AppArmor policies restrict file reads and writes, and access to Unix sockets, including platform-managed logs and communication channels.
  • Per-sandbox eBPF network rules allow only task-approved destinations and protocols. Rules can change as a task moves between stages.
  • Isolation and monitoring help contain failures, but the authors emphasize that these controls are not a general defense against destructive behavior or kernel bugs.

An agent that reads an answer from a log may pass a task without learning the intended skill. DSec’s OS and network controls complement the practices in agent guardrails: prompts direct behavior, while system boundaries restrict tool access.

Production scale

The paper reports a production unit of about 160 nodes. It served roughly 3 million sandboxes per day, with over 380,000 concurrent sandboxes and more than 5,000 creations per second.

Graph View