DeepSeek 前几天公开了一篇新论文，梁文锋在作者名单里。论文写的不是新模型，而是一套让 Agent 真正动手的训练基础设施：DeepSeek Elastic Compute，简称 DSec。
这篇论文要解决的事很具体：训练 Agent 时，不能只让模型在文字里回答“下一步做什么”，还得给它大量真实的环境去改代码、装依赖、跑测试，再用执行结果判断它做得对不对。DSec 负责把这些环境大规模地建起来，隔离不同任务，并留住每个 Agent 已经改过的文件和运行状态；训练任务暂停后，还要能接着运行。
论文描述的单个生产部署单元约有 160 台 CPU 节点、3 万个核心和 250 TB 内存：典型一天处理约 300 万个沙盒，高峰时约 38 万个同时在线，创建速率超过每秒 5000 个。单个训练任务还可能突然申请多达 3.2 万个环境。
论文图 2：一周采样中每个任务创建沙盒的数量分布，容器任务的长尾伸向上万
这些环境并非同一种容器换个名字。短小、无状态的代码执行走 FnCall；改仓库、装依赖主要用容器；需要更强隔离的安全任务用 microVM；Android 和图形界面等任务则要完整虚拟机。上层给训练框架一套操作接口，底下按照任务所需的系统能力和隔离程度选择后端。
论文图 1：DSec 的统一接口与四类执行后端
突发申请也不能一股脑落到少数节点。放置引擎从随机抽到的几个节点里选负载较低者，并把自己刚分配、还没反映在集群定期快照里的请求先算进去。节点最后再检查一次资源压力；如果已经放不下，就拒绝这次放置，让系统换个节点。这样既能快速处理突发请求，也不会把过时的集群负载视图当成最后裁决。
38 万个沙盒，大部分时候在等什么
一个 Agent 改完文件，往往要等模型生成下一步指令。论文图 3 中，环境准备时 CPU 忙一阵，此后只有工具调用和测试会短暂拉高曲线；内存和文件状态却一直留着。另一份为期一周的生产采样显示，约九成容器与 microVM 沙盒的平均 CPU 用量不超过各自请求容量的 5%。
论文图 3：一次代表性任务中，CPU 间歇忙碌，内存持续占用
棋类 Agent 每一步有时间限制，不能让后台任务随意抢占。DSec 让低优先级沙盒在敏感任务就绪时让出 CPU；又用 Linux core scheduling 避免它们挤在同一个物理核心的两个超线程上。论文在独立测试中把棋类任务与占节点容量 50% 的后台负载混跑：没有保护时，单步延迟相对不混跑增加 45.2%；两层调度都开启后，增幅为 17.3%。单纯调低任务优先级，挡不住同核线程之间的争用。
内存的账更难算。microVM 从镜像读入的数据，宿主机缓存一份，虚拟机内部又可能缓存一份；多个虚拟机跑同一基础层，就多次付出这笔内存。DSec 对只读的基础镜像和工具层采用 virtio-pmem 与 DAX，让虚拟机直接映射宿主机页面，共享同一份文件缓存。
可写盘不能全部照搬这条路径。冷数据访问可能需要同步建立映射，较大的映射还会占用虚拟机内部的页元数据。DSec 对这部分改用 DAMON 寻找长期不用的文件页，再通过 virtio-balloon 把释放出的空闲页还给宿主机。两种办法分别对付重复缓存和留在虚拟机里的冷页。
论文用真实 Agent RL 工作负载比较了它们：只开 DAX，宿主机峰值内存下降 40.2%；只开 DAMON 加空闲页上报，峰值几乎不变，但整个任务周期的累计内存占用下降 21.2%。两者合用内存最低，同时 DAX 路径的瞬时 CPU 峰值也更高。它不是一项无代价的“省内存开关”。
论文图 12：四种配置下的宿主机内存和 CPU 曲线；DAX 与空闲页回收合用时内存占用最低
十万多个工作区，镜像不能每次重做、每次搬完
资源占用之外，还有环境种类。一周生产记录里，容器后端用过 11,266 个基础镜像、102,171 个工作区，平台还服务了 103 种工具包。Agent 任务常常需要特定仓库和依赖，镜像复用率没有普通在线服务那么高：容器镜像分配到的节点数中位数只有 3，microVM 镜像更只有 1。把所有东西预先缓存到每台机器上，行不通。
DSec 把基础系统、任务工作区和工具包做成独立版本的只读层，运行时再叠上记录 Agent 改动的可写层。若把它们预先焊成一个完整镜像，更新一个工具包就得重做所有含它的工作区组合；分层后只需更新工具包那一层。这是减少构建时的组合重复。
论文图 4a：整镜像方案中，工具包 T1 更新会触发多个组合镜像重建
论文图 4b：独立分层后，只更新工具包 T1，再与已有基础镜像和工作区组合
但分层不等于启动时就没有搬运。论文统计，活跃环境材料一周累计超过 130 TB；许多镜像只被少数节点使用，冷启动突发仍可能把存储与网络打满。DSec 用 EROFS 存只读层：文件系统元数据先放到节点本地，真正被访问的数据块再从 3FS 按需读取，零碎的运行时写入则留在本地磁盘。这样路径查找不必反复走远端的小随机 I/O，未读到的文件内容也不用提前传完整份镜像。
独立的 10 节点测试集群做过一次 8192 个容器的突发实验。在这批真实 RL 评测任务中，按需加载约 35 分钟完成整批任务，与预先缓存全部镜像的基线接近；从远端拉取并解包完整镜像则超过 60 分钟。按需加载的单节点累计写盘约 700 GB，完整拉取超过 1600 GB。图里的时间是这一批任务完成的时间，不是单个容器的启动延迟。
论文图 10：8192 个容器突发任务；按需加载比远端整镜像拉取更快完成、写盘更少
GPU 任务停了，Agent 已经做过的事怎么办
训练集群里的 GPU 任务会被抢占。早期架构让 agent loop 跟着 GPU 训练任务走，loop 消失时沙盒里的文件和进程却还在。恢复后，训练端不一定知道哪条命令已经执行过；再执行一遍写文件、装依赖之类的操作，就可能产生新的副作用。团队曾把命令与结果记在日志里，恢复时直接取回已完成操作的结果。
从 DeepSeek-V4.1 开始，负责生成交互轨迹的 worker container 和运行工具的 agent sandbox 一起放到可抢占的 GPU 池外，保留完整的 rollout 状态。GPU 任务恢复后重新连接它们，不必再靠命令日志把两边的进度对齐。
训练暂停期间，保留状态也不等于让沙盒继续满负荷占资源。容器可以冻结进程并主动回收内存；microVM 则把执行状态与内存保存成快照，停掉 Firecracker，等下一次请求到来再恢复。前面讲的 DAX 共享和冷页回收解决的是沙盒正常并发运行时的内存压力；这里处理的是训练任务暂停后的状态留存。
Agent 会自己碰到训练场的边界
这些沙盒运行的是 Agent 自己决定的命令。论文记录过它翻找日志和平台文件，尝试从预期之外的通道得到答案。团队对文件、socket 和网络加了访问控制；在一次仍然发生的尝试中，Agent 想交换两个文件底层的数据映射，从另一个入口读取受保护内容，结果损坏 XFS 元数据，文件系统被迫关闭。
也有纯粹的意外：递归 grep 扫进 Linux 的 /proc 状态文件，触发内核 bug；一条持续输出的 yes 命令，攒出了数十 GB 日志。
论文最后给 DSec 的定位很具体：一套服务大规模 Agent 训练、评测和环境构建的执行平台。不同任务用不同沙盒，镜像、内存和 CPU 的压力由平台承担；训练暂停，Agent 的进度也能留下来。前面那些会改文件、跑命令，偶尔还把环境弄坏的 Agent，就是这套平台每天面对的真实负载。
参考链接
DeepSeek DSec 论文：https://arxiv.org/abs/2609.22978