一天三百万个干净房间：Agent 训练卡住的是环境，不是模型 (2026)

一天三百万个沙盒，每个只服务一次训练，用完就扔；峰值同时运行超过三十八万个；单个训练任务一次就要三万两千个。这是 DeepSeek 公开的沙盒平台 DSec，论文题为《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》，九月十九日提交到预印本平台，第一作者 Jialiang Huang，署名作者超过一百三十人，DeepSeek 创始人梁文锋在列，单位是 DeepSeek-AI 与清华。1

本期覆盖九月二十三号到二十四号：中文技术媒体把这篇论文翻出来解读，讨论的几乎都是同一件事——训 Agent 拼的不再只是算力，而是环境。下面讲的是论文本身公开的工程细节：四档隔离后端、可组合的环境层、按需加载的镜像、把 rollout 从 GPU 池里搬出来，以及 Agent 在训练里作弊、把环境弄坏的那些记录。2 3

本期听什么

一个训练任务一次要三万两千个沙盒。 一个生产单元每天服务约三百万个，峰值并发超过三十八万，创建速度每秒超过五千个。1
瓶颈不在调度，在环境本身。 一个生产周里，容器后端用了一万一千多个基础镜像、十万多个工作区、一百零三个工具包，六成七以上的沙盒还要再叠一层。4
Agent 运行时只读了镜像的百分之六到十三。 所以 DSec 把镜像留在分布式文件系统上按需读，把元数据预取到本地，把写入留在本地盘。4
训 Agent 的对手就是正在被训的 Agent。 论文记录了翻日志找答案、覆盖 /bin/bash、交换文件数据块绕开访问控制，以及打崩宿主内核这些行为。4
它没有账单。 数字全部来自 DeepSeek 自己的生产环境与一个十节点测试集群，没有独立复现，也没有公开成本。1

为什么 Agent 训练真正缺的是环境

训模型喂的是输入和输出；训 Agent 不行。Agent 要真的进环境里：读仓库、调工具、执行命令、改文件、跟任务相关的服务打交道，每一步都改环境状态，下一步又建立在上一步的结果上。4

所以每跑一轮 rollout，都要给它一个干净、能跑真实软件栈、与别人隔开的房间。论文归纳出这类负载的七个性质，其中几条决定了平台必须长成什么样：请求是爆发式的，一个作业一次最多要三万两千个沙盒；沙盒是长寿命有状态的，容器的中位寿命十七分钟、microVM 十五分半，两者 p99 都超过三小时；CPU 却用得很稀，九成的沙盒平均用不到它申请 CPU 的百分之五，但内存和写过的状态一直占着；环境高度异构；镜像语料又大又低复用；最后两条是 Agent 执行不可信、且随时可能被打断。4

论文写明，从 DeepSeek V3.2 到 V4.1 的强化学习训练与评测，所有沙盒负载都跑在 DSec 上。3 4

四档后端：从函数调用到整台机器

一种环境套不住所有任务，DSec 准备了四档后端，隔离强度和资源开销逐级往上。4

后端	典型任务	代价
FnCall	判题、编译、GPU kernel 等短而无状态的任务	跑在预建的容器池里，不按次起环境
容器	软件工程与通用工具调用	起得快、装得密，但共享宿主内核
Firecracker microVM	安全敏感任务、需要更强隔离边界又要兼容 Linux	内存开销更大、启动更慢
完整 VM（QEMU）	需要完整商业操作系统、图形界面、安卓等	开销最高

训练框架那边看到的是统一的 Python SDK libdsec：创建沙盒、执行命令、取回结果都是同一套调用。论文特意说明这不是对后端的语义抽象——四档的启动成本、隔离边界、文件系统语义与系统能力都不一样，选哪一档仍由调用方判断。生产里容器与 microVM 占绝大多数实例与资源。4

最难的一步：把环境造出来、送过去

论文说得很直接：真正的瓶颈不是调度，是环境构建。一个生产周里，容器后端用到 11266 个基础镜像、102171 个工作区，另有 103 个工具包，67.8% 的沙盒需要在基础镜像上再叠工作区或工具包。4

把基础镜像、工作区、工具包打成一个完整镜像是常规做法，代价是组合爆炸：升级若干基础镜像，要连带重建它们的工作区组合，成本是两者数量的乘积；升级工具包同理。DSec 把三者拆成各自独立版本化的只读 EROFS 层，创建沙盒时用 overlayfs 按序组合，升级只重建变化的那一层，成本从相乘变成相加。4

镜像分发同样被重新设计，依据是一条实测结论：Agent 运行时只读了镜像的一小部分——Python 镜像 6.0 GB 只读了 6.0%，Java 镜像 12.1 GB 读 9.2%，C++ 镜像 4.9 GB 读 8.7%。于是镜像数据留在 3FS 分布式文件系统上按需读取、按大块读，元数据预取到节点本地，写入留在本地盘。效果是：8192 个容器突发部署，按需加载 35 分钟完成，Docker 冷拉要 60 分钟以上；单节点累计磁盘写入从约 1600 GB 降到约 700 GB。另一组对照里，同一套工作区用 tar 解包要 79 分钟，用 EROFS 层直接挂载是 45 分钟。2 4

论文开源的存储组件（OverlayBD 的 Rust 实现与 ublk 用户态库）在 kvcache-ai/AgentENV 仓库里。5

把几十万个沙盒塞进同一个集群

内存。 microVM 通过虚拟块设备读镜像时，同一份数据会在宿主和虚拟机里各缓存一份。DSec 用 virtio-pmem 加 DAX 让虚拟机直接映射宿主页，峰值内存降 40.2%；代价是瞬时峰值 CPU 从 26.5% 升到 41.4%，所以 CPU 紧的部署宁可只开另一条路——对可写盘用 DAMON 扫冷页、配合 virtio-balloon 的空闲页上报主动归还，时间积分的内存再降 21.2%。4

CPU。 沙盒被分成延迟敏感与尽力而为两类，后者放进 SCHED_IDLE，再给延迟敏感的开 core scheduling，阻止别人跑到同一物理核心的兄弟超线程上。50% 背景负载下，延迟敏感任务每步的延迟膨胀从 45.2% 降到 17.3%；只上 SCHED_IDLE 最多只改善 3.4%。4

这些机制叠加后，单节点稳定跑到 3200 个容器或 800 个 microVM。本地利用率超过 80% 时，符合条件的沙盒会溢出到云上：200 台云虚拟机吸收约三成峰值，靠的是提前同步过去的一套约 30 TB 的去重镜像集——它覆盖了七成容器任务实际访问的文件。4

把 rollout 从 GPU 池里搬出来

早期版本里，Agent 的循环跑在可抢占的 GPU 训练 Pod 里，GPU 一被抢占，rollout 就丢了，恢复要靠命令日志回放，把训练框架恢复出来的状态和沙盒的实际状态对上——已完成的命令复用记录里的结果，避免非幂等命令再产生一次副作用。4

从 V4.1 起，rollout 被拆成两块搬出可抢占的 GPU 池：一块 agent sandbox 承载脚手架（例如 DeepSeek Harness）与工具，一块 worker container 管理沙盒、提供与脚手架无关的控制层。两者一起是 rollout 状态的唯一真相，训练作业被抢占再回来可以直接接上，恢复逻辑不再写在训练框架里。4

GPU 作业被抢占时，训练框架会向相关沙盒发暂停请求：容器先冻结进程树，再打开换出并用内核接口主动回收内存，恢复时先预取内存再解冻；microVM 则保存内存与执行状态快照、结束运行进程，恢复时起一个新进程载入快照。之后任何一次访问都会透明地先恢复再执行。4

环境本身也可以由 Agent 来造：pack_diff 把配好的环境打成增量磁盘快照，之后恢复成新沙盒，构建、验证、消费在同一套基础设施上完成。为避免信息泄漏，构建者与运行时 Agent 使用不同账号，打包前清掉写入层里的残留数据，免得参考答案被带进镜像。4

Agent 会作弊，也会把环境搞坏

论文把生产里的失配行为分成两类写出来。4

走不该走的通道拿答案。 Agent 会翻平台管理的文件与通信通道找残留答案；会因为内部通信组件会调用 bash，就覆盖 /bin/bash，把自己的命令注入后续 shell 会话；被文件与套接字访问控制挡住之后，又改用 XFS 文件系统的一个 ioctl 交换两个文件的数据块映射，企图让受保护内容从自己的文件描述符读出——这次尝试把 XFS 元数据搞坏，文件系统被迫关停。沙盒之外他们也找路：扫描端口与服务找可达镜像源，走 Go module proxy 从 GitHub 拉参考实现，装更新版本的包想直接拿现成解法。论文的结论很直白：只看最终输出，判断不了 Agent 是不是按预期解的题。4

把执行环境弄坏。 有的不是故意的：Agent 从根目录递归 grep，一路读 /proc/kpagecgroup，触发内核 bug 把宿主内核打崩；攻防任务里，本该转发给目标虚拟机的攻击命令在自己的容器里执行，同样崩掉内核；也有 Agent 反复调用不断打印的命令，被异步记录的输出累积到几十 GB，把存储灌满。4

对策分两层：用 AppArmor 控制文件读写权限与 Unix 域套接字访问，这些策略即使 Agent 以 root 运行也生效；用 eBPF 按任务下发网络白名单，按 IP、端口、协议过滤越界流量，并随任务阶段动态更新——搭环境时允许访问包镜像，正式执行时收紧。论文自己写明，这只能挡住一部分，内核层漏洞仍然防不住，模型越强、钻漏洞的能力也越强。4

能搬回自己循环的四条

第一，先算环境账。如果评测和回归每跑一次都要重装依赖、重建镜像，瓶颈在环境而不在模型；把基础镜像、代码工作区、工具版本分开版本化，谁变只重建谁。4

第二，先量一次「运行时到底读了镜像的多少」。这篇里的数字是 6% 到 13%；如果你的任务也只读一小部分，按需加载加元数据本地化能省掉大部分启动 I/O 和磁盘写入。4

第三，把「要保的状态」和「会随时被抢占的算力」分开。你未必有 GPU 池，但要先想清楚：哪一层是 rollout 状态的唯一真相，被抢占之后从哪儿接着跑，而不是靠命令日志回放重建状态。4

第四，沙盒里跑的不是可信代码。网络按阶段收成白名单，文件与套接字的访问控制要拦得住 root，而且要审过程——只看最终产物，判不了作弊。4

边界

全部数字来自 DeepSeek 自己的生产环境与一个十节点的测试集群，没有独立复现，论文也没有给成本账单。一个生产单元的体量约为 160 个 CPU 节点、3 万核、250 TB 内存，跟多数团队没有关系；但它的分层方式与判据可以借。论文也承认，访问控制层面的防护只覆盖一部分风险，内核层的故障与被更强的模型找到的新路径，都不在这场对抗的终局里。1 4