梁文锋署名，DeepSeek又发新论文了！

机器之心编辑部 DeepSeek 又发论文了。 这一次，他们把重点聚焦到了一个很少被外界看到、却越来越影响 Agent 训练规模的地方： 沙箱基础设施 。 论文标题：DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale 论文链接：https://arxiv.org/pdf/2609.22978v1 这是一篇长达 31 页的系统论文。作者阵容超过百人，包括梁文锋在内。论文介绍了 DeepSeek 内部用于大规模 Agent 训练和评测的生产级沙箱平台 DSec（DeepSeek Elastic Compute） 。 先说一下规模。一个 DSec 生产单元大约由 160 台 CPU 节点、3 万个 CPU Core 和约 250 TB DRAM 组成，管理着 PB 级的镜像和环境层。典型的一天里，它要服务大约 300 万个 sandbox 实例 ；高峰时 同时在线的 sandbox 超过 38 万个 ， 创 建 速度超过 5000 个 / 秒 。 更值得注意的是，论文明确提到： 从 DeepSeek V3.2 到 V4.1，DeepSeek 用于 RL 训练和评测的 sandbox workload 都运行在 DSec 上。 也就是说，这篇论文展示的，其实是 DeepSeek 在 Agentic RL 时代给模型搭出的那座「训练场」。 而当训练规模来到几十万个并发 Agent 时，一个看似简单的问题迅速变得棘手： 这么多 Agent，到底在哪儿跑？ Agent 越来越会干活， 训练系统先扛不住了 传统大模型做一次推理，核心工作是生成 Token。到了 Agent 这里，模型开始真正「动手」：打开代码仓库、搜索文件、调用工具、运行命令、修改代码、执行测试，一轮任务可能持续几十分钟甚至数小时。 到了强化学习训练阶段，这些操作还得在真实环境里执行。每个 Agent 都需要一个独立的 sandbox，里面装着代码、依赖、测试工具和运行服务；Agent 改过的文件、启动的进程，也要随着多轮交互持续保留下来。 规模一上来，压力很快就从模型侧传到了基础设施。 DeepSeek 观察到，一次训练任务可能瞬间申请 3.2 万个 sandbox 。这些环境还呈现出一种很特别的资源使用模式： 活得久，但大部分时间并不忙。 论文数据显示， 约 90% 的 Container 和 microVM，平均 CPU 使用量都不到申请资源的 5% 。与此同时，Container 的生命周期中位数达到 17.4 分钟，microVM 为 15.5 分钟；到了 p99，两者都会持续三个小时以上。 原因并不难理解。Agent 经常处于「模型思考 — 执行几条命令 — 继续等待模型」的循环里。于是，集群里可能同时挂着几十万个执行环境，绝大部分时间安静地占着内存和状态，某个时刻又突然一起开始跑任务。 这类 workload 给传统计算平台出了道新题： 怎样让几十万个有状态的执行环境长期在线，同时还能承受瞬时爆发的创建和计算需求？ DSec，就是 DeepSeek 为这个问题搭出来的基础设施。 四种 Sandbox，装下越来越杂的 Agent 任务 Agent 会干的事情越来越多，执行环境也很难再用一种方案包打天下。DSec 因此提供了四类执行后端：FnCall、Container、MicroVM 和 FullVM。 最轻量的 FnCall，适合 Online Judge、代码编译、GPU Kernel 等短任务；软件工程和通用工具调用主要跑在 Container 里，启动快、部署密度高；涉及更强隔离要求的任务，则交给基于 Firecracker 的 microVM；Android、GUI、图形渲染这类依赖完整操作系统的场景，再使用 FullVM。 四类环境统一接入同一套 SDK 和生命周期管理体系。对上层的 Agent 来说，它面对的依然是一套接口；底层则可以根据任务特点选择合适的运行环境。 但统一接口还算容易。真正棘手的是，几十万个这样的环境怎么同时创建、运行和保存状态。 几十万个 Sandbox， DeepSeek 怎么把它们跑起来？ 一秒涌进几千个 Sandbox，调度系统先迎来洪峰 DSec 的调度链路并不复杂。 用户提交请求后，系统先完成身份与权限检查，再由 Placement Engine 根据集群负载寻找合适节点。任务落到机器后，本地组件继续检查容量，然后创建 Container、microVM 或其他执行环境。运行过程中，另一组组件负责维持 Session，并处理命令执行、文件访问、HTTP 请求和流式 I/O。 难点在规模。DeepSeek 的生产集群高峰时，每秒要创建超过 5000 个 Sandbox。单个 Production Unit 的同时在线实例超过 38 万个。这种速度下，环境镜像怎么分发，很快就成了瓶颈。 论文统计，一周内活跃的环境 Artifact 总量超过 130 TB。而且这些镜像高度分散：一个 Container Image 被多少节点使用，中位数只有 3 个；microVM Image 更低，中位数只有 1 个。也就是说，很多环境刚下载到机器上，可能只用一两次。 如果每启动一个 Sandbox，都完整拉取几 GB 甚至十几 GB 的镜像，网络、磁盘和启动时间都会被迅速放大。 于是 DSec 把镜像放到了 DeepSeek 自己的分布式文件系统 3FS 上，真正运行时再按需读取。 这个选择背后，还有一个很关键的数据。 一个几 GB 的镜像，Agent 可能只碰其中几百 MB DeepSeek 分析了不同编程环境真正被访问的数据量。结果发现，Agent 跑完整个任务，往往只会碰到镜像的一小部分：C++ 环境约 8.7%，Go 为 13.3%，Java 为 9.2%，Python 为 6.0%，JavaScript 甚至只有 4.2%。完整下载一遍，显然有些浪费。 DSec 因此采用 On-demand Loading：Container 使用 EROFS，microVM 使用 EROFS 配合 OverlayBD，需要哪个数据块，再从 3FS 里取哪个。 这有点像看在线视频。过去是先把整部电影下载完才能播放；现在只读取当前需要的部分。Agent 最终没访问到的文件，也就不会产生对应的网络和磁盘开销。 这个设计到了后面的实验里，带来了相当明显的收益。 环境太多，DeepSeek 把它们拆成了「积木」 镜像数量还有另一个麻烦：环境组合越来越多。 一个 Agent 任务里，通常会同时出现基础操作系统、代码仓库、测试工具和各种依赖。换一个任务，Workspace 变了；升级工具链，Toolkit 又变了。如果每一种组合都保存成完整镜像，更新成本会迅速膨胀。 DSec 把一个环境拆成几层：Base Image、Workspace、Toolkit，以及最上面的可写层。 Base Image 提供基础系统，Workspace 放代码和任务数据，Toolkit 保存工具链。