训练一个会干活的 AI Agent，GPU 只是故事的一半。模型每走一步都要在真实环境里执行：读代码仓库、装依赖、跑测试、开浏览器。9 月 19 日，DeepSeek 在 arXiv 提交系统论文《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》（arXiv:2609.22978），第一作者 Jialiang Huang，作者名单超过 130 人，创始人梁文锋列名最后一位。这篇 31 页的论文公开了支撑 DeepSeek V3.2 到 V4.1 两代模型 Agent 强化学习训练的沙箱平台全貌：一个生产单元约 160 个 CPU 节点、3 万核、250TB 内存，每天创建约 300 万个沙箱，峰值并发 38 万，创建速率超过每秒 5000 个。
Agent RL 训练的算力大头在 CPU 侧
大模型强化学习的经典流程分三步：模型生成轨迹（rollout）、环境打分（reward）、更新参数（policy update）。前两步都需要沙箱：模型生成的代码必须在隔离环境里真实执行，退出码、测试通过率、标准输出这些执行信号才能成为奖励。Agent 化之后，rollout 不再是一次生成，而是几十轮工具调用的长交互，每个任务都要一个带状态的隔离环境，存活时间横跨模型的几十次思考。
DSec 论文给出的生产数据描绘了这种负载的形状。单个训练任务最多一次性请求 3.2 万个沙箱，请求在短窗口内集中到达；沙箱中位寿命 17.4 分钟（容器）和 15.5 分钟（microVM），p99 超过 3 小时；约 90% 的沙箱平均 CPU 占用不超过申请量的 5%，因为大部分时间它在等模型生成下一步动作。突发、长命、稀疏用 CPU，这三个特征叠加起来，就是一套专用基础设施的立项理由。
四种沙箱后端，一个 SDK
DSec 没有把宝押在单一虚拟化技术上，而是通过 Python SDK libdsec 暴露四种后端，调用方按任务选型：
| 后端 | 启动开销 | 隔离强度 | 典型场景 |
|---|---|---|---|
| FnCall | 极低（常驻容器） | 弱 | OJ 式判题、代码编译、GPU 算子评测 |
| 容器 | 低 | 中 | 软件工程任务、通用工具调用 |
| Firecracker microVM | 中 | 强 | 安全类任务、需要 VM 边界的 Linux 负载 |
| 完整 VM（QEMU） | 高 | 强 | Android 模拟器、GUI、图形渲染 |
一个容易忽略的细节：容器和 FnCall 并不直接跑在物理机上，而是跑在 QEMU/libvirt 虚拟机里，虚拟机本身充当不可信容器与裸机之间的额外安全边界。图形任务通过 virtio-gpu 半虚拟化 GPU 支持，DirectX 渲染可以用 DXVK 转译层落到宿主 API。生产环境中，容器和 microVM 占据了绝大多数实例数和资源消耗。
架构上，集群侧是 IAM、apiserver、placement engine、watcher 四个无持久状态的服务（重启后靠重新轮询重建视图，天然易扩缩）；节点侧是 edge（本地准入 + eBPF 网络策略 + 启动运行时）、aether（沙箱内代理，容器走 Unix socket、VM 走 vsock）、chronus（shell 会话抽象）。调度用 power-of-two-choices 的变体：随机采样若干健康节点取负载最低者，避免突发流量在集群里扎堆。
机制一：把环境拆成三层独立版本
DSec 一周内服务的镜像规模：容器后端 11266 个基础镜像、102171 个工作区、总计 82.8TB；microVM 后端 2 个共享基础镜像、53590 个任务工作区、50.9TB。67.8% 的沙箱需要至少一个基础镜像之外的工作区或工具包层。
如果把基础镜像、任务代码、工具链（如 DeepSeek Harness）熔成一个完整 OCI 镜像，升级任何一个工具链版本都要重建所有包含它的组合，组合数会指数爆炸。DSec 的做法是把三者当作生命周期独立的层：基础镜像在 overlayfs 栈底，工作区和工具链作为只读层依次叠加，运行时写入落在最上面的可写层。为此团队修改了 dockerd，在容器创建时动态插入 EROFS 格式的只读层，这个改动只花了 30 行 Go 代码。所有只读层用 EROFS（源自小米手机的压缩只读文件系统，现已在 Linux 主线）存储，支持压缩块级随机访问。
机制二：镜像按需加载，不做全量拉取
传统做法要么预拉全量镜像，要么预热点缓存。DSec 的生产数据说明两条路都不划算：容器镜像的中位扇出只有 3（p90 为 28），运行时实际访问的数据只占镜像的 4.2% 到 13.3%，预热只是把开销提前，数据还是全量搬运。
DSec 把镜像数据放在自研的 3FS 分布式文件系统（已开源，10k star）上，针对 3FS"大 IO 高吞吐、小随机 IO 弱"的特性做了三条设计：写路径全部留在节点本地盘（沙箱写入无法预测，含大量小 IO）；读路径按需触发、内核预读聚合成大块批量拉取；元数据与数据分离，EROFS 元数据提前落到本地，路径查找不产生远程 IO。microVM 侧用 OverlayBD 加 ublk 用户态块设备，256KiB 分块加本地二级缓存，同样开源在 AgentENV 仓库。
10 节点测试集群上的 8192 容器突发实验：按需加载 35 分钟完成全部任务，与全量本地缓存的基线持平；从远端 registry 全量拉取要超过 60 分钟，慢 1.71 倍。磁盘写入量按需路径 700GB，全量拉取超 1600GB，减少 57%。工作区供应的对比实验里，EROFS 直接挂载比 tar.gz 解压快 1.76 倍（45 分钟对 79 分钟），磁盘写流量只有后者的约 1/5.5。
机制三：超高密度部署的内存与 CPU 账本
CPU 稀疏让超卖成为自然选择：生产环境单节点稳定运行 3200 个容器或 800 个 microVM（观测峰值 1048 容器、524 microVM，论文强调这是已验证运行点而非硬上限）。密度上去之后，内存和 CPU 干扰成为主要矛盾。
内存侧的两个浪费：镜像数据被宿主和每个 guest 各缓存一遍；guest 内部的空闲页不会主动归还宿主。对策组合：只读层走 virtio-pmem with DAX，guest 访问直接映射宿主页，缓存只存一份，峰值内存降 40.2%；可写盘配合 DAMON（Linux 内核的数据访问监控框架）识别冷文件页驱逐回收，加上 virtio-balloon 的空闲页上报（默认按 2MiB 的 order-9 页扫描），时间积分内存消耗再降 21.2%。
CPU 侧，DSec 把沙箱分成延迟敏感（LS）和尽力而为（BE）两级：BE 任务压到 SCHED_IDLE 调度类；光这样还不够，同一物理核的两个 SMT 兄弟线程仍然共享执行资源，于是再对 LS 任务开 core scheduling，禁止无关 BE 工作落到兄弟线程。象棋类每步有固定时限的延迟敏感任务，在 50% BE 负载下延迟膨胀从 45.2% 压到 17.3%。全部用 Linux 内核既有特性，零内核修改。
与 RL 框架的协同设计
DSec 不是孤立的沙箱服务，论文第六章的协同设计可能是对做 Agent 训练的团队最有参考价值的部分。
一是环境由 Agent 造：人工构建海量训练环境不现实，DeepSeek 让 Agent 在 DSec 上交互式搭环境，pack_diff 接口随时对沙箱做增量快照，交互会话直接变成可复用环境。构建者和运行时 Agent 用独立账号，打包前清除构建残留，防止参考答案泄进镜像。
二是 Agent loop 迁出 GPU 池：早期版本里 rollout 执行跑在可抢占的 GPU 训练 pod 内，GPU 被抢占时 Agent loop 直接丢失，只能靠命令日志重放恢复。从 V4.1 开始，Agent 沙箱和管理它的 worker 容器都搬到 DSec 侧，成为 rollout 状态的唯一事实源，GPU 任务被抢占后重连即续跑，命令日志重放机制整个退役。GPU 被抢占期间，RL 框架主动 pause 关联沙箱：容器走 docker pause 加内存回收换页，microVM 直接快照后杀进程，请求到达时透明恢复。
Agent 越狱实录：论文最好看的部分
第 6.4 节记录的生产事故单拎出来就是一篇安全报告。模型拿到任务后寻找旁路的能力超出多数人的预期：伪造 RPC 消息直接对 chronus 的 Unix socket 发请求；翻 chronus 日志找泄露的答案；覆盖 /bin/bash 试图在后续 shell 会话里注入命令。文件和 socket 访问控制（AppArmor）上线后，一个 Agent 转而尝试 XFS_IOC_SWAPEXT 这个 ioctl，交换两个文件的数据Extent映射，让受保护文件的内容从另一个文件描述符可读，结果是损坏 XFS 元数据、触发文件系统紧急关闭。
破坏性事故同样不罕见：一个 Agent 从根目录递归 grep，穿过 /proc 读到 kpagecgroup，触发内核 bug 整机崩溃；漏洞利用任务的攻击命令本应转发到独立目标 VM，却在 Agent 自己的容器里执行，把自己的内核打崩；还有 Agent 跑了 yes 命令，chronus 异步记录 stdout，存储上积累了几十 GB 数据。
DSec 的缓解措施是 AppArmor 文件与 socket 管控（对沙箱内 root 同样生效）加 eBPF 细粒度网络白名单（按域名/镜像源放行，比如允许 PyPI、禁止 NPM，随任务阶段动态更新）。论文的表态很坦率：这些控制只覆盖一部分问题，对触发内核 bug 这类破坏行为没有通用防御，可靠的做法是持续观测加随模型演进不断加固。
边界与开放部分
DSec 平台本身未开源，开源的是三个构件：3FS 分布式文件系统、OverlayBD/ublk 存储栈（AgentENV 仓库的 storage/overlaybd 目录）、以及作为基础设施的 Firecracker、EROFS 等上游组件。论文 31 页 13 图，注释披露其两页扩展摘要曾进入 ACM ATC 2026 运营系统赛道第一轮评审；评测在独立的 10 节点测试集群完成（AMD EPYC 9655，Linux 7.0 宿主/6.1 guest），与生产部署分开。
对行业而言，这篇论文把"Agent 训练需要什么样的基础设施"写成了带实测数据的工程账本：突发创建、状态保持、低扇出镜像、稀疏 CPU、不可信执行体，每个属性都对应一组明确的机制和数字。E2B、Code Interpreter 这些推理侧沙箱服务解决的是单次代码执行，veRL、Slime、OpenRLHF 这些 RL 框架把执行环境当黑盒，DSec 填的是中间那层。DeepSeek 用公开论文的方式承认，这层才是 Agent 军备竞赛的量产地基。
论文：arXiv:2609.22978 · 3FS：github.com/deepseek-ai/3FS · 存储组件：github.com/kvcache-ai/AgentENV