# 解读 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](https://arxiv.org/abs/2609.22978)）介绍了他们在生产中使用的 sandbox 平台。 先说结论。这篇论文最值得借鉴的是五点： 1. **sandbox 申请的资源大多用不上**：约 90% 的 sandbox 平均只用到申请 CPU 的 5% 以内，所以可以大幅超卖，但要用 CPU 核心调度保护对延迟敏感的任务。 2. **镜像不要整个拉取**：一个 sandbox 实际只会读到镜像的 4%–13%，按需加载比全量拉取快得多。 3. **调度可以很简单**：power-of-k 随机选节点，加上本地的「在途」记录，最终由节点自己决定接不接受。 4. **RL 需要任务级操作**：训练被抢占或结束时，整批暂停、恢复或结束一个任务的所有 sandbox。 5. **要防智能体作弊**：论文记录了真实的 reward hacking 和越权事件，sandbox 需要专门防护。 下面逐项展开。我们的开源项目 [OpenDsec](https://github.com/Kernflux/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](/blog/posts/self-hosted-e2b)。 ## 延伸阅读 - 论文：[arXiv:2609.22978](https://arxiv.org/abs/2609.22978) - [OpenDsec 核心概念](/docs/concepts) - [OpenDsec 与 E2B、Daytona、Modal 对比](/docs/compare) - [快速开始](/docs/quickstart)：在一台 Linux 机器上装好 OpenDsec *OpenDsec 是 Kernflux 的开源项目，与 DeepSeek 没有关联。文中关于 DSec 的内容均来自上述论文。*