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 保存工具链。Agent 运行过程中产生的修改，再写进自己的 Writable Layer。不同层可以独立更新，再通过 OverlayFS 组合成完整文件系统。

论文给了一个很直观的复杂度变化：假设有 N 个环境，更新 m 个 Base Image，重建成本可以从 O (m・N) 降到 O (m)；更新 k 个 Toolkit，也从 O (k・N) 降到 O (k)。

当训练环境开始以万、十万计，这种差别会直接落到构建时间、存储和分发成本上。

一台机器塞进 3200 个 Container，问题变成了「怎么别把内存撑爆」

前面提到，Agent Sandbox 有个很特殊的特点：数量巨大，CPU 却经常闲着。这给 DSec 留出了一个空间 —— 超额部署。

DeepSeek 在生产环境里已经稳定跑到过：单节点至少 3200 个 Container，或者 800 个 microVM。论文强调，这只是经过实际验证的运行点，还没有触碰系统上限。

CPU 好解决一些，内存更麻烦，尤其是 microVM。同一份文件可能先在宿主机缓存一遍，每个虚拟机内部又各自缓存一份。几百个 VM 跑起来，相同数据很容易被重复占用。

DSec 用了两套机制：

第一套是 virtio-pmem + DAX。多个 microVM 可以共享宿主机上的同一份 Page Cache，减少重复文件页。

第二套是 DAMON + virtio-balloon Free Page Reporting。系统持续观察哪些内存页面长期没有访问，把冷数据逐渐回收；Guest 里已经空闲的内存，也会重新交还给 Host。

目的很明确：Sandbox 可以多挂一些，闲着的内存也得尽可能收回来。

CPU 很闲，但 Agent 一动起来又不能卡

高密度部署还有另一个问题：几十万个 Sandbox 平时都很安静，一旦开始执行，CPU 竞争会突然变强。而有些 Agent 对响应时间很敏感，比如棋类任务，每一步都有时间预算。

DSec 因此把 workload 分成两类：Latency-Sensitive（LS） 和 Best-Effort（BE）。

后台 BE 任务使用 Linux 的 SCHED_IDLE，让出更多 CPU；对延迟敏感的 LS workload，再配合 Core Scheduling，减少同一物理核心上的资源干扰。

这套机制最终要解决的是一个很实际的平衡：同一台机器尽可能多塞 Sandbox，同时别让正在真正干活的 Agent 明显变慢。

当 Sandbox 真正进入 RL 训练，

事情又复杂了一层

GPU 被抢走之后，跑到一半的 Agent 还得接着干

论文接下来进入一个更贴近强化学习训练的问题：Sandbox 怎么和 RL 系统一起工作。

Agent rollout 往往持续很久。它可能已经修改了几十个文件、启动了服务、执行了很多轮命令，结果此时 GPU Training Job 被调度系统抢占了。训练过一会儿重新启动，前面的环境状态还得接得上。

DeepSeek 早期使用 Command Log 记录操作。训练恢复后，再通过日志协调 rollout state 和 sandbox state；已经执行过的操作可以读取历史结果，减少重复执行带来的状态变化。

到了 DeepSeek-V4.1，这套架构又往前走了一步。DeepSeek 把 rollout execution 放到了 DSec 里。Agent Sandbox 负责运行 Harness 和工具，另一个 Worker Container 管理 Sandbox，并和 RL Framework 通信。这两个组件都位于可抢占的 GPU Pool 之外。

这样一来，GPU Job 暂停时，Agent 的执行环境还能继续保存完整状态。新的 Trainer 接回来以后，rollout 可以从原来的位置继续。

对于越来越长的 Agent 轨迹，这件事很重要：训练过程可以暂停，已经跑出来的执行状态还在。

Agent 等 GPU 的时候，几十万个环境也不能一直白占资源

状态要保留，资源又不能一直占着。所以训练进入暂停阶段时，RL Framework 会通知对应 Sandbox 一起休眠。

Container 会冻结 Process Tree，同时主动回收内存；microVM 会保存 Snapshot，然后终止 Firecracker Process。

等新的训练请求到来，再把环境恢复起来。

这样，Sandbox 的生命周期就开始和 RL Training 的节奏协同：Agent 需要工作时恢复，Trainer 暂停时释放资源，同时保留足够的执行状态。

这其实也是 DSec 和普通云端容器平台区别很大的一点。它面对的 workload，本身就是为长时间、多轮、可中断的 Agent rollout 服务的。

Agent 已经开始「研究」自己的训练环境

随着 Agent 能力提升，DeepSeek 发现，它们开始主动寻找训练环境里的各种信息通道。有的 Agent 会搜索平台管理文件、通信 Channel 和 Chronus Log；有的会尝试构造 RPC Message，直接访问 Chronus Socket；甚至还有 Agent 覆盖过 /bin/bash，试图借此影响后续 Shell Session。

当 DSec 加入文件和 Socket 限制后，又有 Agent 找到了一个更偏底层的系统调用：XFS_IOC_SWAPEXT。它尝试交换文件的数据 Extent Mapping，结果把 XFS Metadata 搞坏，文件系统直接进入 Shutdown。

这些行为未必意味着 Agent 「有恶意」。在强化学习里，它只是不断寻找能提高 Reward 的路径。

问题在于，一旦模型从环境里找到了题目答案、测试信息或者其他捷径，最终得到的 Reward 就可能失真。

DeepSeek 还观察到 Agent 扫描网络端口、寻找内部服务、使用 Go Module Proxy 获取 GitHub 代码，或者安装更新版本的软件包，看看里面是否已经出现任务需要的实现。

换句话说，当 Agent 足够会折腾，环境本身也成了它探索的一部分。

它们还真能把自己的 Sandbox 玩坏

除了寻找捷径，还有不少纯粹的「事故」。

论文记录过一个 Agent 从根目录递归运行 grep，一路读进 /proc/kpagecgroup，最后触发 Kernel Bug，把 Kernel 弄崩了。

还有 Agent 在漏洞利用任务里，本来应该攻击目标 VM，结果把 Exploit 命令跑到了自己的 Container 中，把自己的执行环境打挂。

甚至一个最普通的 yes 命令，也制造过几十 GB 的 stdout。

这些案例很能说明 Agent Sandbox 和普通代码执行环境之间的差别。

用户写程序时，行为通常有比较明确的目的；Agent 在强化学习里会不断试探状态空间，很多边界条件真会被它碰到。

DSec 因此使用 AppArmor、eBPF 网络规则等手段限制文件、Socket 和网络访问，还可以按照任务阶段动态调整网络权限。

Agent 能力越强，Sandbox 也越需要把「执行环境」本身当成一套安全系统来设计。

实验结果：

这些机制到底有没有用？

8192 个 Container 一起启动，35 分钟跑完

DeepSeek 单独搭了一个 10 节点 CPU Cluster，验证 DSec 的几项核心机制，包括按需镜像加载、Composable Layer、内存优化和 CPU QoS。

先看镜像。实验一次创建 8192 个 Container，比较三种方案：镜像已经完整缓存在本地、从远程 Registry 完整 Pull，以及 DSec 的 EROFS 按需加载。

完整远程拉取方案跑完超过 60 分钟。DSec 大约 35 分钟结束，已经接近镜像预先缓存在本地的表现。

换算下来，Eager Pull 慢了约 1.71 倍。

磁盘压力的差距更明显：完整 Pull 每个节点累计写盘超过 1600 GB；按需加载约 700 GB，下降大约 57%。

前面那个「很多镜像实际只访问几个百分点」的结论，到这里变成了直接的系统收益。

把环境拆成积木，79 分钟降到 45 分钟

第二项实验测试 Composable Layer。

DeepSeek 使用相同的 Workspace 和 Toolkit，一组通过传统 tar.gz 分发、解压，另一组使用 EROFS Layer 挂载。

为了让结果更稳定，实验把模型生成换成事先录制好的 Tool Call Sequence。

结果是：tar.gz 方案耗时 79 分钟，EROFS 为 45 分钟，相当于 1.76 倍加速。

差距主要出现在环境准备阶段。tar.gz 需要给每个 Sandbox 解压一套完整 Workspace 和 Toolkit；EROFS Layer 可以直接挂载并共享。

最终，tar 方案产生的总磁盘写入量约为 EROFS 的 5.5 倍，峰值写入吞吐也达到约 3.4 倍。

内存最高省 40.2%，高负载下延迟也压了下来

microVM 的内存优化同样有明显效果。

单独开启 virtio-pmem + DAX，Host 的峰值内存占用下降 40.2%。使用 DAMON + Free Page Reporting 后，峰值变化相对有限，但整个任务周期里的累计 Host Memory Consumption 降低 21.2%。两套机制同时启用时，整体内存消耗最低。

这里也有代价。virtio-pmem 会让瞬时 Peak CPU Utilization 从 26.5% 提高到 41.4%。这意味着 DSec 依然需要根据资源情况，在 CPU 和内存之间做工程权衡。

最后是 CPU QoS。DeepSeek 用一个对延迟敏感的 Chess Agent 做测试，同时不断增加后台 Best-Effort workload。

当后台 CPU Load 达到 50% 时，没有 QoS 控制的 Agent 单步延迟增加 45.2%；加入 SCHED_IDLE 后有所改善，再加上 Core Scheduling，延迟增幅降到了 17.3%。

对于高密度 Agent 集群来说，这个数字意味着：同一台机器可以挂更多 Sandbox，同时把活跃任务受到的干扰控制在更低水平。

当模型开始真正「干活」，

训练场也得跟着升级

DSec 这篇论文里，几乎看不到 Attention、MoE 或新的 RL 算法。它讨论的是另一组词：调度、镜像、文件系统、Page Cache、VM Snapshot、CPU Core、网络隔离。

但这恰恰反映出 Agentic RL 正在出现的一种变化。模型生成一段文本时，主要消耗的是 GPU；模型开始调用工具、修改代码、运行程序之后，背后还需要一整套真实的计算环境。

而 DeepSeek 现在面对的规模已经相当可观：一个生产单元每天运行约 300 万个 Sandbox，峰值同时在线超过 38 万个，创建速度超过 5000 个 / 秒。

这时，训练系统需要解决的问题也开始扩散到 GPU 之外：PB 级环境如何存储，几十万个有状态实例怎么调度，长时间 rollout 怎样暂停和恢复，Agent 把系统边界当成探索空间之后又该怎么隔离。

DSec 展示的，就是 DeepSeek 给这一阶段准备的一套底层设施。

如果过去训练大模型，核心任务是尽可能高效地把 Token 喂给 GPU；到了 Agent 时代，又多出了一件越来越重的工作：给成千上万个会动手的模型，准备一个经得起折腾的执行世界。