DeepSeek DSec 单集群日均三百万沙箱,按需加载写盘少 57%

DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale

Jialiang Huang, Hongxuan Tang, Jingchang Chen, Yuxuan Liu, Yixiao Chen, Yuan Cheng, Yi Tao, Jingli Zhou, Yupeng Chen, Haoyu Chen, Jiarui Wang, Shengkai Lin, Chuqi Zhang, Bryan Lee Teng, Lian Guo, Zhe Fu, Wenjun Gao, Yisong Wang, Liang Zhao, Zehao Wang, Ziwei Xie, Yongqiang Guo, Peixin Cong, Ziyi Gao, Shuiping Yu, Hanwei Xu, Zuofan Wu, Zhizhou Ren, Yuyang Zhou, Bowei Zhang, Zhihuan Huang, Qihao Zhu, Lei Wang, Tianle Lin, Han Yu, Jiewen Hu, Dejian Yang, Shuo Yang, Shanghao Lu, Shaoyuan Chen, Junjie Qiu, Zhangli Sha, Yinmin Zhong, Yongtong Wu, Shiyu Wang, Wei Liu, Bingzheng Xu, Longhao Chen, Qiushi Du, Yuzhen Huang, Shirong Ma, Yaohui Wang, Mingshu Chen, Tongrui Xiong, Y. C. Yan, Haowen Luo, Haofen Liang, Xiaokang Zhang, Weihao Zeng, Runxin Xu, Peiyi Wang, Jinhua Zhu, Ruoyu Zhang, Wenkai Yang, Qi Tang, Jiping Yu, Tian Ye, Ruizhe Pan, Honghui Ding, Xiaodong Liu, Lingxiao Luo, Zhihong Shao, Yuhan Wu, Jibai Lu, Wen Liu, Haoling Zhang, Jingcheng Hu, Yaoyang Ye, Chaofan Lin, Zhaochen Zhang, Jianan Tong, Hengxu Wu, Zhihao Li, Yicheng Wang, Luyao Wang, Yuzhuo Bai, Lingyue Fu, Ruifan Xu, Y. Z. Wang, Zonglin Li, Mingqi Wei, Haiyang Shen, Chengyuan Zhang, Chao Jin, Zili Zhang, R. H. Yang, Xinbo Xu, Jian Zhou, Ruidong Zhu, Yuzhe Guo, Zelun Pan, Shaoheng Nie, Erhang Li, Shuhan Lin, Zheng Liu, Anshuo Chen, Zilong Lyu, Sinuo Cao, Rui Yu, Chuhao Wang, Junyi Guo, Junxiao Song, Kaifeng Chen, Menghao Ye, Junxian Li, Di Wu, Haiyang Ma, Yilun Wang, Haoran Yang, Yizai Cai, Shichun Liu, Yiping Wang, Junbo Sun, Shicheng Xu, Xiao Bi, Ying He, Yichao Zhang, Mingxing Zhang, Liyue Zhang, Panpan Huang, Wenfeng Liang

cs.DC

2026-09-19

DeepSeek 的 DSec 给 agent RL 提供弹性沙箱:约 160 节点日均 300 万实例、峰值超 38 万并发。按需加载相对全量拉取完成时间从 60 分钟压到 35 分钟,写盘少 57%。

这篇在解决什么

Agent 训练要让模型进真实环境:翻仓库、跑命令、开浏览器、改文件,再拿退出码和测试通过率当奖励。环境必须隔离、带状态、能撑住长对话。一次作业最多要 3.2 万个沙箱,镜像种类多、复用少,节点本地缓存吃不下。沙箱在等模型出下一步时 CPU 很闲,内存和可写状态却一直占着。GPU 训练还会被抢占,rollout 不能跟着死。

这不是再包一层容器运行时能打发的。DeepSeek 把沙箱做成生产级弹性平台 DSec,从 V3.2 用到 V4.1。

方法

用户走 Python SDK libdsec,自己选后端。FnCall 吃短无状态任务(OJ、编译、GPU kernel),跑在预创建容器里。容器是软件工程和工具调用的主力,启动快、密度高,但和宿主机共享内核。Firecracker microVM 隔离更强,内存和启动更贵。全虚拟机走 QEMU,覆盖 Android、GUI、图形渲染。生产里容器和 microVM 占实例和资源的大头。

集群侧:IAM 鉴权,apiserver 做入口且不存沙箱状态,placement 先过滤健康节点再随机抽几个挑最闲的,watcher 探活。节点上的 edge 做本地准入。容器和虚拟机里跑 aether 代理加 chronus shell 会话;FnCall 不走这条路径。FnCall 和容器落在 QEMU/libvirt 虚拟机里,多一层内核和网络隔离。

环境拆成可独立版本化的层:底是操作系统基础镜像,中是任务仓库,上是工具包(例如 DeepSeek Harness)。运行时改 dockerd,创建时动态叠 overlayfs。不可变层做成 EROFS,可压缩还能随机读。microVM 把 EROFS 当只读块设备,客户机里同样 overlay。一周生产数据:容器 11266 个基础镜像、102171 个工作区,合计 82.8 TB;microVM 2 个基础镜像、53590 个工作区,50.9 TB。103 个工具包,67.8% 的沙箱至少还要一层工作区或工具包。

镜像放 3FS。容器把元数据拉到本地,文件数据按访问从 3FS 读;写落本地盘。microVM 可写盘走 OverlayBD 加 ublk,256 KiB 分块加二级本地缓存。采样显示运行时只碰到镜像数据的 4.2% 到 13.3%。

密度靠超卖。约 90% 沙箱平均 CPU 不超过申请量的 5%。生产里单节点稳定过 3200 个容器或 800 个 microVM。microVM 用 virtio-pmem + DAX 让只读层共享宿主机 page cache,再用 DAMON 加 virtio-balloon 把冷页还回去。CPU 上延迟敏感任务走 core scheduling,尽力而为任务放 SCHEDIDLE,避免 SMT 兄弟线程互抢。

和 RL 框架绑在一起。V4.1 起 agent 循环搬出可抢占 GPU 池,worker 容器加 agent 沙箱当 rollout 状态的唯一真源。抢占时 pause:容器 docker pause 再 memory.reclaim,microVM 打快照后杀掉 Firecracker。环境由 agent 在同一套设施上交互构建,packdiff 做增量快照。网络策略按任务用 eBPF 白名单,文件和套接字用 AppArmor,用来堵从日志、内部 socket、包管理镜像里偷答案。

本地利用率超 80% 时,把镜像依赖落在 30 TB 共享集里的任务卸到云虚拟机。200 台云机吃掉约 30% 的峰值溢出。

结果

单规模单元约 160 个 CPU 节点、3 万核、约 250 TB DRAM,日均约 300 万沙箱,峰值并发约 38 万,创建速率超过每秒 5000。容器中位寿命 17.4 分钟,microVM 15.5 分钟,两者 p99 都超过 3 小时。

评测在独立 10 节点集群上,工作负载来自内部软件工程、SWE-bench、Terminal-Bench 和安全题。8192 个容器突发:按需 EROFS 约 35 分钟跑完,对齐本地缓存基线;冷 Docker 拉取超过 60 分钟,慢 1.71 倍。每节点累计写盘从超过 1600 GB 降到约 700 GB,少约 57%,接近本地基线的约 600 GB。

工作区用 EROFS 挂载对比 tar.gz 解压:端到端 45 分钟对 79 分钟,快 1.76 倍;tar 路径总写盘约 5.5 倍,峰值吞吐约 3.4 倍。

内存:virtio-pmem 峰值比基线低 40.2%;DAMON + 空闲页上报把时间积分内存降 21.2%;两者一起最低。pmem 会把瞬时 CPU 从 26.5% 抬到 41.4%,CPU 紧的部署可以只用回收、留 virtio-blk。

CPU:50% 尽力而为负载下,无保护时延迟敏感棋类任务每步变慢 45.2%;只设 SCHEDIDLE 最多好 3.4%;加上 core scheduling,膨胀压到 17.3%。剩下的主要是睿频下降和末级缓存/内存带宽争用,他们没再做带宽隔离。

为什么重要

Agent RL 的瓶颈经常不在 GPU 算子,在「同时活着的真实环境」够不够、镜像起得是否拖训练环。DSec 把这件事写成可超卖、可抢占恢复、可按任务控网的集群产品。对已经在用 E2B、Code Interpreter 一类推理沙箱的人,这篇给的是训练侧量级:单作业 3.2 万实例、镜像低扇出、状态要跨抢占活着。

工程判断很具体:3FS 随机小 IO 差,所以写本地、读按需、元数据尽量本地。这是平台报告,不是新隔离原语论文。

局限与存疑

评测只覆盖 §5 的基础设施,§6 的抢占恢复和防 reward hacking 没有对照数字。评测集群 10 节点,和生产 160 节点不是同一套。延迟数字来自棋类 agent,外推到 GUI 或编译要另测。

作者承认访问控制挡不住内核漏洞:agent 递归 grep 进 /proc 触发过内核崩溃;有人用 XFSIOCSWAPEXT 绕过文件保护,直接把文件系统打挂。stdout 被 chronus 全量记录时,yes 能写出几十 GB。防作弊是持续加固,不是一次策略能收口。

论文没给成本账,也没和 E2B、RunD 等系统做同负载头对头。云突发只接得住镜像落在那 30 TB 集合里的容器任务。

术语

原文与代码

社区讨论

相关论文

全部论文解读