DeepSeek 公开 DSec 论文：每天 300 万沙箱、38 万并发的 Agentic 训练基建

当所有人盯着 DeepSeek 的模型时，他们把沙箱基础设施写成了一篇系统论文。

Agentic RL（用强化学习训练会干活的 agent）是当下前沿模型竞赛的主战场。但训练可靠 agent 的前提，是让模型在大规模、隔离、有状态的执行环境里反复练习——每条 rollout 都要物化一个独立的沙箱环境，跑代码、调工具、改文件、起服务。这个基建层的工程难度，不比模型本身低。

9 月 19 日，DeepSeek 发布论文**《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》**（arXiv 2609.22978），首次系统公开了支撑 DeepSeek V3.2 到 V4.1 全部 RL 训练与评估的沙箱平台。数字先镇个楼：一个生产单元约 160 个 CPU 节点、3 万核、250TB DRAM，每天创建约 300 万个沙箱，生产环境支撑 38 万+ 并发沙箱，沙箱创建速度超过每秒 5,000 个。

这篇文章拆解 DSec 的架构设计、核心机制，以及论文里最精彩的——agent 恶意行为实录。

本文提纲

1. DSec 是什么：Agent 训练的"操作系统层"
2. 四种沙箱后端：没有银弹的隔离光谱
3. 生产负载的五大挑战
4. 核心机制一：组合式环境层（EROFS）
5. 核心机制二：高密度资源管理
6. 核心机制三：按需镜像加载
7. 与 RL 框架的协同设计
8. 最精彩的部分：agent 恶意行为实录
9. 对行业的意义

DSec 是什么：Agent 训练的"操作系统层"

先厘清 DSec 在整个训练管线里的位置。

Agentic RL 训练是个循环：rollout（当前模型在沙箱环境里读文件、调工具、执行命令、观察输出）→ reward 计算（用退出码、stdout、测试通过率等原生执行信号给轨迹打分）→ policy update（用轨迹和奖励更新模型参数），周期性评估走类似的执行路径。其中 rollout 和评估对沙箱平台的压力最大——大规模、高并发、与 GPU 训练紧耦合。

GPU 侧的 RL 框架（veRL、slime、OpenRLHF 等）把执行环境当黑盒；DSec 做的正是黑盒底下那一层：沙箱的供给、生命周期、环境组合、资源管理和安全策略。用户（训练框架、评估框架、数据构建管道）通过统一 Python SDK libdsec 访问，指定沙箱类型、镜像、资源限额、生命周期策略和网络规则。

部署形态：多个 scale unit 共享一套 3FS（DeepSeek 自研的 Fire-Flyer 分布式文件系统）；单个 scale unit 约 160 CPU 节点、3 万核、250TB 内存，管理 PB 级的镜像和层。

四种沙箱后端：没有银弹的隔离光谱

DSec 的第一个设计判断：没有任何一种沙箱抽象能高效覆盖所有 agentic 任务。它因此支持四种后端，暴露在同一个 SDK 后面：

	FnCall	Container	MicroVM	Full VM
运行性能	●●●	●●○	●◐○	●○○
隔离级别	○○○	●●○	●●●	●●●
完整 OS 功能	○○○	●○○	●●○	●●●
资源开销	○○○	●○○	●●○	●●●
典型场景	OJ 类、编译、GPU kernel	SWE、通用工具使用	安全任务、强租户隔离	Android、GUI、图形

• FnCall：短平快的无状态任务（OJ 类、代码编译、serverless、GPU kernel），跑在复用的预建容器里，避免每次供给的开销；GPU 负载还分 shared（多容器共享 GPU 实例）和 exclusive（独占）两种模式。
• Container：软件工程和通用工具使用任务的主力——启动快、密度高。
• Firecracker microVM：更强的隔离边界 + Linux 兼容，给安全敏感任务。
• Full VM：完整商用操作系统的场景——Android 模拟（QEMU）、GUI、图形渲染。

生产数据：容器和 microVM 占据实例数和资源消耗的大头，FnCall 用少量常驻环境服务大量轻量调用，Full VM 覆盖小众但必要的负载。

生产负载的五大挑战

论文对生产负载的刻画是设计方案的依据，五条挑战条条有数字：

1. 突发式创建：单个任务可能一次性请求多达 32K 个沙箱实例——调度和镜像分发必须避免中心化瓶颈。
2. 环境多样性：每个任务可能需要自己的仓库、依赖版本、服务、工具包、评估脚本——大量镜像复用率极低。
3. 稀疏 CPU 利用率 → 高密度执行：agent 交互时沙箱大部分时间在等 LLM 生成下一步，CPU 空闲——生产中单节点可跑 800 个 microVM 或 3,200 个容器，前提是平台能安全地超卖。
4. 大镜像、低访问率：急切（eager）全量拉镜像让任务完成时间延长 1.7 倍——分布路径既是延迟问题也是总量问题。
5. Agent 不可信：agent 可能损坏文件系统、耗尽资源、干扰系统组件——需要细粒度访问控制和恶意行为分析。

核心机制一：组合式环境层（EROFS）

洞察很干净：基础 OS 镜像、每个工作区、每个工具包，是生命周期各自独立的层，而不是一次性镜像的组件。

实现：用 Overlayfs 的合并语义——基础镜像在最底层、请求的工作区作为只读层插入其上、请求的工具包逐层叠加，运行时写入进最上层的可写目录。DeepSeek 修改了容器运行时（dockerd）在沙箱创建时动态组装 overlayfs 栈。

收益直接：升级基础镜像只需重建 base 层（工作区和工具包不动），升级工具包只重建工具包层——把单体镜像方案 O(m·N) + O(k·N) 的重建成本降到 O(m) + O(k)。

层以 EROFS（华为开源的只读压缩文件系统）存储：比 ext4/XFS 免去写记账、磁盘布局更紧凑、支持压缩同时保留随机访问——不像 tar.gz 必须完整传输解包，EROFS 可以只读取所需数据覆盖的压缩块。microVM 侧把 EROFS 镜像作为只读块设备暴露给 guest，guest 内 overlayfs 合并——与容器侧同一套组合层模型。

实测：同样的工作区和工具包供给，tar.gz 方案产生 5.5 倍的磁盘写流量、3.4 倍的峰值写吞吐；EROFS 直接挂载免解压，沙箱更早进入工具调用阶段，完成时间缩短到 45 分钟——1.7 倍加速。

核心机制二：高密度资源管理

内存侧，两个互补机制：

• virtio-pmem + DAX：把文件访问直接映射到宿主页，不复制进 guest 内存——让共置的 microVM 共享同一份只读层数据，消除每 guest 重复的页缓存。峰值宿主内存降 40.2%。代价是冷访问可能需要同步 fault 处理（CPU 从 26.5% 升到 41.4%），且 guest 要为整个 pmem 范围分配 struct page 元数据（128GB 设备要吃 2GB guest 内存）。
• DAMON + virtio-balloon free-page reporting：DAMON（Linux 内核的内存访问监控框架）周期性采样识别长期未动的冷文件页并回收，让分散的页聚合成高阶块，满足 balloon free-page reporting 的要求——guest 主动向 hypervisor 报告空闲页，宿主释放。时间积分内存消耗降 21.2%，CPU 开销可忽略。生产中两者并用：virtio-pmem 管只读 EROFS 层，DAMON+balloon 管可写层回收。

CPU 侧，两层 QoS：沙箱分为延迟敏感（LS）和尽力而为（BE）两类。BE 放在 SCHED_IDLE（LS 可运行时 BE 让路）；但由于调度优先级管不住兄弟超线程的干扰，再对 LS 沙箱启用 core scheduling——阻止无关 BE 工作跑在同一物理核的兄弟线程上。实测 50% BE 负载下：无保护基线延迟膨胀 45.2%，单用 SCHED_IDLE 只改善 3.4%（SMT 兄弟还在争），加上 core scheduling 后压到 17.3%。

核心机制三：按需镜像加载

关键观察：沙箱通常只访问镜像数据的一小部分——按需加载解决的不只是时机问题，而是总量问题：总 I/O 与实际使用的比例成比例地缩小，而不是把开销挪到另一个阶段。

设计取了 3FS 的不对称 I/O 特性的反向利用（3FS 大块顺序读写强、小随机 I/O 弱）：

• 写走本地：沙箱写入不规则且不可控（大量小写如日志），可写层放节点本地盘。
• 读按需且批量：只读镜像数据在被访问时才从 3FS 取，内核 readahead 合并相邻块成大请求吃满 3FS 吞吐。
• 元数据尽量本地：文件系统元数据常走小读——EROFS 的 multi-device 模式把元数据与数据分离，元数据预取到本地盘，路径查找零远程 I/O。

顺便复用基建：镜像直接放在支撑训练的 3FS 上，不另建独立的镜像分发层（对比常见"registry + P2P"方案）。

实测 8,192 容器突发：按需 EROFS 几乎和"完全本地"基线一样快地达到峰值并发；急切 Docker 拉取前 20 分钟延迟创建，完成需 60+ 分钟（1.71 倍慢）；急切路径每节点累计磁盘写超 1,600 GB，按需路径只 ~700 GB（省 57%）。

与 RL 框架的协同设计

1. "Build environments of Agents, by Agents, for Agents"。 手工构建 agentic RL 需要的海量环境不现实——DeepSeek 让 agent 在训练评估用的同一套基础设施上交互式地搭建环境：任何时刻 agent 可以对沙箱做增量磁盘快照（pack_diff），快照之后可以恢复成新沙箱——交互式会话直接变成可复用环境。防泄漏：构建者和运行时 agent 用独立账户，打包前清除可写层的构建残留，参考答案不会被带进运行环境。

2. Agent loop 与 RL 框架解耦。 GPU 训练任务会被例行抢占，长程 rollout 挂在可抢占训练 pod 里意味着"跑了一半全丢"。早期版本里恢复靠命令日志对账（已完成的操作复用记录结果，避免非幂等命令重复执行）。从 DeepSeek-V4.1 起，rollout 执行搬到 DSec 上：agent sandbox（放 harness 和工具）+ worker container（管理沙箱、提供与 scaffold 无关的控制层），两者都跑在可抢占 GPU 池之外——rollout 生命周期与 trainer 生命周期解耦，worker 和 sandbox 共同保有完整 rollout 状态，被抢占的 GPU job 重连即可继续。这把恢复逻辑从 RL 框架里整个拿掉了。

3. 沙箱暂停/恢复。 GPU 抢占后，框架主动给相关沙箱发 pause 请求回收内存：容器走 docker pause 冻结进程树 + swap + memory.reclaim 主动回收，恢复时 MADV_WILLNEED 异步预取再 unpause；microVM 快照内存和执行状态后终止 Firecracker 进程，恢复时起新进程重放快照。

最精彩的部分：agent 恶意行为实录

论文里最值得逐字读的一节，是生产中真实发生的 agent 失控与"作弊"案例——每一条都是 RL 训练的系统课。

绕过限制找答案（reward hacking 的雏形）：

• agent 在沙箱内翻平台管理的文件和通信信道找残留答案——向 chronus socket 直接发伪造的用户请求、翻 chronus 日志找泄漏的答案。
• 因为 chronus 某些操作会调 bash，agent 尝试覆写 /bin/bash 来绕过检查、向后续 shell 会话注入命令。
• 引入文件读写和 socket 访问控制后，agent 尝试用 XFS_IOC_SWAPEXT（交换两个文件数据映射的 ioctl）绕过——目标是让受保护文件的内容通过另一个文件描述符可访问。这个尝试破坏了 XFS 元数据，直接把文件系统打挂。
• 沙箱之外：扫端口和服务找可达的镜像源、用 Go module proxy 拉 GitHub 上的代码、装更新的包版本——翻找任务要求功能的现成实现。

论文的判断很冷静：只检查最终输出，无法可靠确认 agent 是否"按 intended 方式"解决了任务。

无意的基础设施破坏：

• 一个 agent 从根目录递归跑 grep，遍历 /proc 读到 /proc/kpagecgroup，触发内核 bug 整机崩溃。
• 漏洞利用任务里，本该转发到目标 VM 的攻击命令在 agent 容器本地执行了。
• 一个 agent 调了 ping，chronus 记录其持续输出以便异步取回——stdout 累计了几十 GB 存储数据。

缓解：AppArmor 控制 文件读写和 socket 访问等。论文的结论同样冷静："没有任何单一机制能阻止所有 agent 恶意行为和系统故障"——解法是强化可观测性 + 随模型进化持续加固。这段实录与我们此前跟踪的 OpenAI agent 失控披露、Hugging Face 入侵事件互相印证：agent 恶意行为不是假设，是 RL 训练基础设施的日常运维对象。

对行业的意义

几句实在话。

Agentic RL 的基建层第一次被完整公开到这个深度。 RL 框架层（veRL/slime/OpenRLHF）和模型层讲得多，沙箱执行层一直黑盒——DSec 把环境组合、资源超卖、镜像服务、抢占恢复、安全策略一整个栈摊开，对标的是系统论文的完整度（还有清晰的消融实验）。

"沙箱即操作系统"的视角正在成型。 四后端统一 SDK、层组合、内存/CPU QoS、按需加载——这些全是经典操作系统问题的 agent 时代翻版。传统云厂商的 serverless/FaaS 社区（论文 related work 里对比了 SAND/RunD/Nydus 等）积累了大量零件，DSec 的贡献是按 agentic 训练的负载特征（长生命周期、有状态、突发、低复用）重新组装。

给所有要做"agent 大规模评测/训练"的团队一份参照系。 不必复制 160 节点的规模，但"rollout 与 trainer 解耦""快照即环境""agent 不可信要按日常运维对待"这三条设计原则，在任何规模下都成立。

参考链接

• 论文：DeepSeek Elastic Compute (DSec)（arXiv 2609.22978） - 2026-09-19，本文核心来源
• 3FS：Fire-Flyer File System - DeepSeek 自研分布式文件系统，镜像与工作区存储
• Firecracker microVM - AWS 开源的 microVM，DSec 的第三种后端
• EROFS - 华为开源的只读压缩文件系统（Linux 主线内核收录）
• DAMON - Linux 内核的数据访问监控框架
• 我的 DeepSeek Harness 拆解 - DSec 上层的 agent 桌面端产品
• 我的 agent 恶意行为跟踪 - OpenAI 失控披露、Hugging Face 入侵等事件系列

你在跑 agent 的执行环境用的是什么沙箱方案？踩过 agent 搞崩环境的坑吗？评论区聊聊，觉得有用点个赞让更多做 infra 的人看到这篇。

---

作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。