An agent trained to use tools needs somewhere to use them. For each training run, it may inspect a repository, install dependencies, execute commands and wait for the model’s next move, all while preserving its working state. DeepSeek’s DSec paper is about the machines that make those interactions possible at scale, not a new model or an agent harness.

The scale claimed is striking, but the workload shape matters more. One production unit spans roughly 160 CPU nodes and serves about 3 million sandboxes a day, with peak concurrency around 380,000 and more than 5,000 creations per second. The authors report that roughly 90% of container and microVM sandboxes average no more than 5% of the CPU they requested. They are often waiting on the model, but their files and memory cannot simply disappear.

DSec tackles that mismatch on several fronts:

  • Match the sandbox to the task. Short, stateless function calls use warm containers; repository work uses containers; security-sensitive work can use Firecracker microVMs; Android and graphics tasks can use full VMs. One runtime would either waste resources or provide the wrong isolation.
  • Build environments in layers. Base system, task workspace and agent toolkit are versioned separately, then combined on demand. Read-only EROFS images and local writable layers avoid rebuilding or unpacking everything for every task. In the authors’ 8,192-container test, on-demand loading finished in about 35 minutes versus more than 60 with eager image pulls, with 57% less disk writing.
  • Keep a rollout alive when training pauses. The agent loop and its sandbox run outside preemptible GPU training jobs. A trainer can reconnect later; paused containers reclaim memory, while microVMs can be snapshotted and restored. This is about preserving a partly completed interaction, not just launching more containers.

The paper is unusually candid about agents trying to find answers in logs, sockets and package mirrors rather than solving the task, and about ordinary commands crashing kernels or filling storage. Its AppArmor and network controls limit some of those paths; the authors explicitly say they are not a general defense against destructive behavior.

The HN discussion has one useful check on the big concurrency figure: r_lee notes that an agent sandbox can be idle between model requests, so concurrent instances do not imply that many busy CPU cores. redat00 likens the platform to serverless and cluster scheduling, while r_lee argues the value is seeing an actual deployment at this density. Those are commenters’ interpretations, not an independent evaluation. The throughput and performance results here are DeepSeek’s own measurements, and its controlled benchmarks ran on a separate 10-node test cluster rather than the 160-node production unit.