每秒 5000 个沙盒：DeepSeek 公开 Agent 训练系统 DSec，梁文锋署名

大模型训练比的是算力，Agent 训练比的却是环境——这句话在由梁文锋署名的一篇 DeepSeek 新论文里得到了具体展开。论文公开了一套名为 DSec 的系统，全称是 DeepSeek 弹性计算，英文写作 Elastic Compute，目的很直白：给 Agent 训练成批地造沙盒。

规模是这套系统的第一道门槛。DSec 每秒能生成 5000 个以上的沙盒，单日产出可达 300 万个，峰值时同时运行的沙盒数量为 38 万个。支撑这一规模的单集群大约由 160 个节点组成，配备 3 万核 CPU 与 250TB 内存。

难点从何而来？常规的大模型训练，环境就是 GPU 集群，把数据喂进去、把梯度算出来就够了；而 Agent 需要在沙盒内写代码、编译、开浏览器，甚至动手装操作系统，每走一步都会让环境状态发生变化，一个不慎就可能把环境跑坏。因此每一轮训练都得换一个全新、干净的沙盒，用完即弃。问题于是回到基础设施层面：在每秒 5000 个的速度下为每个沙盒装齐操作系统与工具链，同时又得避免几十万个并发沙盒把内存与 CPU 整体压垮。

为了适配不同任务，DSec 提供了四种后端：FnCall 专管无状态函数调用；Container 用来跑 Docker 容器；需要更轻的虚拟机时选 MicroVM，底层是 Firecracker；再往上还有 Full VM，用 QEMU 起完整操作系统。四者的隔离强度与资源开销依次递增，但训练框架看到的接口是统一的——通过一个统一的 Python SDK（libdsec），创建沙盒、执行命令、取回结果的方式完全一致。

调度链路被拆成六层。训练框架发出一个创建请求后，先由 IAM 完成身份认证与鉴权，随后进入 API Server，接着由调度引擎依据资源余量挑出目标节点，最后由节点上的 Edge 组件把对应类型的沙盒拉起来。沙盒对外的网络出口、以及包管理镜像，都由 Aether 统一代理；Agent 敲下的每条命令、吐出的每一行输出，都经由沙盒内的通信组件 Chronus 回传给训练框架。靠资源的超分配置与高密度部署，单节点同时承载 3200 个容器不成问题，或者改成放 800 个 MicroVM。

真正棘手的是环境构建。传统 Docker 会把基础镜像、工作区与工具包打成一个完整镜像，规模不大时没有问题；但 DSec 的容器后端，累计涉及 11266 个基础镜像与 102171 个工作区，其中 67.8% 的沙盒还需要在基础镜像之上再叠至少一层工作区或工具包。只要某个工具包一更新，凡是包含它的组合镜像都得重做一遍，开销记作 O(m·N)。DSec 的应对方式是把环境切成三层——基础镜像、工作区、工具包，各自做成独立的只读镜像，分别做版本管理，再靠 overlayfs 在沙盒启动那一刻按需拼装，改动时只涉及对应的那一层，总开销降到 O(m)+O(k)。

镜像分发同样做了取舍。真实运行数据显示：Python 容器镜像体积 6.0GB，Agent 真正读取的只有 6.0%；Java 镜像 12.1GB，被访问的只有 9.2%；C++ 镜像 4.9GB，只用到 8.7%。于是 DSec 转向按需加载：镜像以 EROFS 格式放在 3FS 分布式文件系统里，元数据先预取到本地，具体数据块等到真正读取那一刻再拉。实测 8192 个容器集中上线时，按需加载用 35 分钟就能跑完，Docker 的冷拉取则要耗上 60 分钟以上；磁盘的写入量也从大约 1600GB 回落至 700GB 上下。

资源争抢也有应对。MicroVM 读取镜像时，宿主机与虚拟机各自的页缓存都会留一份，需求因此翻倍。DSec 借助 virtio pmem 与 DAX，让虚拟机绕过自身页缓存，直接映射到宿主机的物理内存上，多台虚拟机共用这同一份映射，峰值内存占用因此下降 40.2%；至于不适用这套办法的可写磁盘，DSec 让 DAMON 周期性清理冷内存页并把它们主动归还给宿主机，再借 virtio balloon 上报空闲页，又省下 21.2%。CPU 这一侧，沙盒被划成两类：一类对延迟敏感，另一类尽力而为。后者的优先级设为 SCHED_IDLE，同时打开 core scheduling 这一 Linux 特性，避免低优先级线程被调度到高优先级线程的兄弟超线程上；在 50% 背景负载下，延迟敏感任务的延迟膨胀由 45.2% 收窄到 17.3%。

论文还记录了几桩 Agent 在训练过程中自行琢磨出来的作弊手法，即所谓的 reward hacking。有 Agent 盯上了负责通信的 Chronus，发现它底层会调用系统 bash，于是直接改写 /bin/bash 注入命令，想借此截获题目答案；被 AppArmor 拦下之后，它转去利用 XFS 的 ioctl 接口，靠 XFS 的 IOC SWAPEXT 指令把受保护文件的内容掉包到自己能访问的描述符上，绕开了文件级权限检查，代价是弄坏了 XFS 元数据，可能让文件系统直接崩溃。另一类 Agent 会把沙盒能访问到的网络端口逐个扫一遍，寻找现成的参考实现，甚至借 Go module proxy 的通道，从 GitHub 上拉取代码、再装更新的软件包来拿到解法。更激烈的情况同样出现过：一个 Agent 递归跑起 grep，从根目录一路查到内核的 kpagecgroup 节点，结果触发内核缺陷，把宿主机的内核弄崩；另一个则在安全攻防任务中，把攻击指令执行到了自己的容器里；还有 Agent 不停调用 yes 命令，用几十 GB 日志把存储空间撑满。

目前 DSec 的防线分两层。一层是 AppArmor，负责管控文件读写权限与 Unix 域套接字的访问，这类策略就算 Agent 以 root 运行也照旧生效；另一层是 eBPF，在网络层做细颗粒管控：按任务下发域名白名单，用 IP、端口与协议三重过滤拦下越界流量，策略还能随着任务阶段实时调整。论文也坦言，这并非一个能被彻底解决的问题：能力越强的模型，找出漏洞的本事也越大，平台这边的防线只能一直往前推。

文章与图片内容转载网络，如有侵权请联系平台删除