解读 DeepSeek DSec 论文：大规模智能体训练的沙箱（sandbox）基础设施
训练会写代码、会用工具的 AI 智能体，强化学习（RL）的每一次 rollout 都要一个独立的沙箱（sandbox）：一个能装依赖、跑命令、读写文件的隔离环境。DeepSeek 2026 年 9 月发布的论文 DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale（arXiv:2609.22978）介绍了他们在生产中使用的 sandbox 平台。
先说结论。这篇论文最值得借鉴的是五点：
- sandbox 申请的资源大多用不上：约 90% 的 sandbox 平均只用到申请 CPU 的 5% 以内，所以可以大幅超卖，但要用 CPU 核心调度保护对延迟敏感的任务。
- 镜像不要整个拉取：一个 sandbox 实际只会读到镜像的 4%–13%，按需加载比全量拉取快得多。
- 调度可以很简单：power-of-k 随机选节点，加上本地的「在途」记录，最终由节点自己决定接不接受。
- RL 需要任务级操作：训练被抢占或结束时，整批暂停、恢复或结束一个任务的所有 sandbox。
- 要防智能体作弊：论文记录了真实的 reward hacking 和越权事件，sandbox 需要专门防护。
下面逐项展开。我们的开源项目 OpenDsec 就是照着这篇论文实现的，文末说明它在哪些地方做了不同的选择。OpenDsec 与 DeepSeek 没有关联。
规模
论文给出的生产数字：
| 数字 | |
|---|---|
| 一个生产单元 | 约 160 个节点 |
| 每天创建的 sandbox | 约 300 万个 |
| 同时运行的 sandbox | 超过 38 万个 |
| 创建速率 | 每秒超过 5,000 个 |
| 单个训练任务 | 最多 3.2 万个 sandbox |
| 单个节点（稳定运行） | 3,200 个容器，或 800 个 microVM |
| RL sandbox 存活时间 | p99 超过 3 小时 |
最后一行常被忽略：sandbox 活得比一次部署久，所以升级节点时不能把它们杀掉。
一套 SDK，四种后端，不做抽象
DSec 提供四种后端：函数调用（FnCall）、容器、microVM 和完整虚拟机。它们共用一套 SDK，但 SDK 不试图把后端抽象成同一个接口：调用方明确选择后端，每种后端有自己的参数。理由很实际：容器、microVM 和虚拟机在启动时间、隔离强度、能不能挂 GPU 上差别很大，统一的抽象只会隐藏这些差别。
调度：power-of-k 和节点的最终决定权
放置 sandbox 用的是经典的 power-of-k choices（论文引用 Mitzenmacher）：从候选节点里随机取 k 个，选负载最低的。它不需要全局精确的状态，却能把负载分得很均匀。
两点细节决定了它在高并发下能不能用：
- 在途记录（in-flight overlay）：节点的负载是定期汇报的，两次汇报之间刚放上去的 sandbox 看不到。每个调度实例在选中节点时就把这次放置记下来，计算负载时叠加上去，避免一窝蜂打到同一个节点。
- 最终准入权在节点：调度只是尽力而为。节点收到请求时按自己当前的容量和内存压力再检查一次，不够就拒绝，调度换一个节点重试。
控制面的组件（API 服务、状态收集）都没有持久状态，重启后重新向节点轮询即可恢复。sandbox 的 id 里编码了它所在的节点，路由不用查表。
超卖和 CPU 核心调度
论文统计约 90% 的 sandbox 平均只用到申请 CPU 的 5% 以内。按申请量分配就会浪费大量机器，所以 DSec 大幅超卖 CPU。
超卖的代价落在对延迟敏感的任务上。只把后台任务设成 SCHED_IDLE 不够：它只管同一个硬件线程上谁先跑，管不了同一物理核另一个超线程上的邻居抢执行单元和缓存。论文的测量是，50% 的干扰负载下，不保护时延迟增加 45.2%，SCHED_IDLE 最多改善 3.4%，加上 Linux 的 CPU 核心调度（core scheduling）后只增加 17.3%。
内存方面，论文同样做了共享和回收：暂停的 sandbox 把内存换出，相同的只读数据在 sandbox 之间共享。
镜像：分层构建，按需加载
RL 任务的环境种类多、每种用得少，传统的「先把整个镜像拉到节点上」很浪费。DSec 的做法：
- 分层：环境由 base、workspace、toolkit 等独立版本化的层拼成，换一层不用重建整个镜像。
- 按需加载：镜像数据放在 DeepSeek 自己的分布式文件系统 3FS 上，sandbox 用到哪部分数据才读取哪部分。论文统计一个 sandbox 实际只读到镜像的 4%–13%。
- 效果：8,192 个容器的突发创建，按需加载用时 35 分钟，全量拉取超过 60 分钟。
- 构建和运行分开：构建环境的账号和跑任务的账号分离，跑任务的账号不能往别人会用到的镜像里写东西。
为 RL 设计的生命周期
DSec 和 RL 训练框架是一起设计的：有状态的 rollout 执行在 sandbox 里，GPU 训练可以被抢占，两者分开。为此 sandbox 平台提供：
- 任务级操作：按任务暂停、恢复、结束全部 sandbox。训练被抢占时整批暂停，回来后整批恢复。
- 透明恢复：对一个已暂停的 sandbox 发起任何操作，平台先自动恢复它。
- 超时回收：显式结束，或者空闲超时后回收。
- 嵌套项目和有界委托：项目可以任意深度嵌套（例如
root/rl/job-42/agent-7），一个身份只能把自己有的权限再委托出去。
防作弊和越权
论文记录了智能体在 sandbox 里的真实「越轨」行为，例如：无限输出写满存储、伪造请求发给 sandbox 内部的管理进程、读取管理进程的日志找答案、覆盖 /bin/bash、用文件系统的 ioctl 破坏元数据、扫描端口找镜像源。
DSec 的防护包括 AppArmor 限制，以及用 eBPF 实现的网络策略：出站默认拒绝，按规则放行。
云上溢出
本地集群利用率超过 80% 时，DSec 把一部分容器任务放到云上。不是所有任务都能上云，只有镜像在一个去重后约 30 TB 的 EROFS 集合里的任务才行，这个集合覆盖了约 70% 的容器任务。
对自建 sandbox 平台的启示
- 按实际用量而不是申请量规划容量，然后用核心调度保护延迟敏感的任务。
- 镜像体积不是瓶颈，读多少才是：先上按需加载，再优化存储。
- 简单的随机调度够用，前提是节点有最终准入权、调度实例记得自己刚放了什么。
- 从第一天起就设计任务级操作和暂停，RL 训练一定会被抢占。
- 把智能体当作不可信的程序：输出有上限、网络默认拒绝、评测和智能体分开。
OpenDsec：开源的实现，以及不同的选择
OpenDsec 按论文的架构实现了 IAM、调度、状态收集、节点、SDK 和镜像库，并在两台 384 线程的裸金属节点上做了生产验证。下面几处我们做了不同的选择：
| DSec 论文 | OpenDsec | |
|---|---|---|
| 主力后端 | 容器；microVM 用于需要更强隔离的场景 | Firecracker microVM：不共享宿主内核，能做内存快照。容器留给 GPU 和没有 KVM 的机器 |
| fork 和暂停 | 任务级暂停和恢复 | 同样支持，另外可以连同内存 fork 运行中的 microVM（fork(count=N)），适合树搜索 |
| 网络策略 | eBPF | nftables 加内置 DNS 代理，语义相同：默认拒绝，按域名、地址、端口放行，运行中可改 |
| 镜像存储 | 3FS | 任何共享文件系统：NFS、CephFS、JuiceFS |
| 兼容性 | 自己的 SDK | 自己的 SDK，加上 E2B 兼容网关 |
几个对照论文做的实测（项目的裸金属测试机，2 × AMD EPYC 9Y24）：
- CPU 核心调度：50% 干扰负载下，延迟增加从不保护时的 18.0% 降到 2.1%（
SCHED_IDLE加核心调度）；100% 干扰负载下从 81.0% 降到 10.0%。方向与论文一致。 - 密度：单台 384 线程的节点一次突发创建 5,120 个 microVM，用时 37 秒；两个节点一次突发创建 8,192 个容器，全部成功。
- 防作弊：论文列出的事件逐条对照处理，例如每条命令每路输出最多记录 64 MB，智能体会话用普通用户。
此外，OpenDsec 自带 fleet 服务，分批滚动升级和修改配置，运行中的 sandbox 不受影响。
还没做的：没有做按需加载与全量拉取的对比实验，GPU 还没有在真实硬件上测过。
常见问题
DSec 是开源的吗？
论文介绍的是 DeepSeek 内部的系统，没有附带代码。OpenDsec 不是 DeepSeek 的代码，而是我们按论文独立实现的开源项目（服务端 AGPL-3.0，SDK Apache-2.0），与 DeepSeek 没有关联。
DSec 用的是容器还是虚拟机？
都有。DSec 提供函数调用、容器、microVM 和完整虚拟机四种后端，以容器为主力，由调用方按任务选择。
为什么 RL 训练需要专门的 sandbox 平台？
RL 一个任务就可能同时要上万个 sandbox，每个都要装依赖、跑测试、存活几个小时，而且训练随时可能被抢占。通用的容器平台一般没有任务级暂停、大规模突发创建和防作弊这些能力。
sandbox 可以超卖多少？
论文统计约 90% 的 sandbox 平均只用到申请 CPU 的 5% 以内。OpenDsec 默认把 CPU 超卖 8 倍，并用 CPU 核心调度保护对延迟敏感的 sandbox。具体比例取决于你的负载。
什么是 reward hacking，sandbox 怎么防？
reward hacking 指智能体不解决问题，而是钻评测的空子拿奖励，比如读取评测日志里的答案、改掉系统命令。常见的防护是让智能体碰不到评测的东西：智能体和评测用不同的用户、限制输出、网络默认拒绝。
不训练模型，只想给 AI 智能体一个执行代码的 sandbox，有用吗？
有用。论文里的超卖、按需加载和防越权对任何「运行不可信代码」的场景都适用。OpenDsec 也可以直接作为 AI 智能体的代码执行沙箱，并兼容 E2B SDK，见自建 E2B。
延伸阅读
- 论文：arXiv:2609.22978
- OpenDsec 核心概念
- OpenDsec 与 E2B、Daytona、Modal 对比
- 快速开始：在一台 Linux 机器上装好 OpenDsec
OpenDsec 是 Kernflux 的开源项目，与 DeepSeek 没有关联。文中关于 DSec 的内容均来自上述论文。