DeepSeek Elastic Compute（DSec）：面向大规模智能体训练的高效沙箱基础设施

大规模智能体 RL 与评测需要能突发创建、长期保留状态、覆盖异构隔离需求并分发海量低复用镜像的弹性沙箱平台，而不是单一沙箱运行时。

• 场景与重要性：作者称前沿 LLM 已使智能体工作流实用化：模型在隔离环境中浏览仓库、调用工具、执行命令并依据反馈迭代。RL 的 rollout、奖励计算和策略更新中，rollout 与评测对沙箱压力最大，因为它们规模大、并发高，且与训练循环紧耦合；异步 rollout 还会让大量有状态会话同时在飞，并可能跨策略更新或调度抢占中断再恢复。
• 现有做法的不足：作者认为单一沙箱抽象无法高效覆盖从 OJ 式短任务到完整商用操作系统的工作负载。把 base、workspace、toolkit 融成单一 OCI 镜像会使升级成本随组合数增长；启动时解压归档会在突发下造成 CPU 与 I/O 开销和超时；节点本地镜像缓存也吸收不了低扇出、超百 TB 的工作集。
• 工作负载假设：作者归纳七点：任务可一次请求最多 32K 沙箱；交互等待使 CPU 稀疏、适合超售；状态跨轮次保留使内存长期驻留；工作负载在功能和隔离强度上异构；镜像种类多且复用有限；智能体执行不可信；GPU 训练可抢占，因而必须保留并恢复执行状态。
• 论文提出什么：DeepSeek Elastic Compute（DSec） 是生产沙箱平台，经统一 SDK 暴露 FnCall、container、microVM 和 full-VM 后端，做放置与生命周期管理、独立版本化分层环境、内存共享/回收与 CPU 调度，并从 3FS 按需加载镜像；它与 RL 框架协同设计，把有状态 rollout 与可抢占 GPU 训练解耦，并缓解 reward hacking 等智能体不当行为。

论文在引言和 §9 讨论相关工作，并在机制章节点名若干系统作为设计参照。

• 智能体环境与训练循环：Jimenez et al.（2024）、OpenAI et al.（2024）、Xie et al.（2024）、Zhou et al.（2024）和 Guo et al.（2025）被用来说明代码、计算机使用和网页类智能体需要真实执行环境；Ouyang et al.（2022）与 Guo et al.（2025）对应 RL 的 rollout–奖励–策略更新循环。DeepSeek Harness（Shi et al., 2026）、OpenCode（Anomaly, 2025）以及 DeepSeek-AI（2026）的异步 rollout 被当作编排或训练侧背景，而不是被批评的沙箱系统。
• 沙箱与隔离运行时：Firecracker（Agache et al., 2020）是 microVM 后端；QEMU（Bellard, 2005）支撑 Android 等 full VM；virtio-balloon（Waldspurger, 2002）、DAMON（Park et al., 2019）、Linux core scheduling（Zijlstra et al., 2021）和 OverlayBD（Li et al., 2020）、EROFS（Gao et al., 2019）被用作内存、调度和镜像格式构件。Faasm（Shillaker and Pietzuch, 2020）与 serverless 快照工作（Ustiugov et al., 2021）属于轻量有状态执行相关文献。论文只描述这些机制被采用或接口上不支持（Firecracker 不支持 virtio-fs），没有把它们写成被本文全面替代的对象。
• 按需镜像分发：FaaSNet（Wang et al., 2021）代表“容器仓库加点对点”的按需分发；Nydus（Dragonfly Community, 2020）把 EROFS 兼容元数据与数据分离并做惰性加载。作者称 DSec 不另建分发层，而是把镜像放在已有的 3FS 上，并把元数据预取到本地、数据按需批量读取。CoFS（Wang et al., 2026）同样面向快速容器启动。Erebor（Zhang et al., 2025）讨论不可信机密虚拟机中的私有数据处理沙箱，论文在参考文献中列出，正文可见部分未展开对比。
• 奖励黑客与训练框架：Amodei et al.（2016）和 Skalse et al.（2022）被用来命名 reward hacking。slime（Zhu et al., 2025）是 RL 后训练框架文献。DSec 服务 DeepSeek V3.2 到 V4.1 的沙箱负载，并从 V4.1 起把 rollout 移出可抢占 GPU 训练作业。

基线方法不是另一套公开沙箱系统的端到端对打，而是平台内部对照：单体镜像相对可组合层、急切拉镜像相对按需加载、无 DAMON/balloon 相对启用后、仅调度优先级相对加上 core scheduling。基准/数据集是生产轨迹与采样，而不是公开智能体基准的准确率表：一周内容器 11,266 个 base image 与 102,171 个 workspace，microVM 2 个 base image、53,590 个 workspace 和 4,889 个 snapshot（Table 2）；生命周期样本为 30K 容器和 10K microVM（Figure 7）；镜像扇出覆盖超过 150 万容器和 39 万 microVM（Figure 8）。

作者把 DSec 定位为与 RL 协同设计的生产执行平台：统一多隔离后端、可组合环境、3FS 按需加载、高密度内存与 CPU 管理，以及抢占下的状态保留和针对智能体不当行为的访问控制，而不是单个沙箱运行时或容器的薄封装。

DSec 把创建请求经 IAM 与放置引擎落到节点 edge，再按后端启动沙箱；环境由独立层组合，镜像从 3FS 按需读取，并用内存回收、CPU QoS 以及与训练循环的暂停/恢复来维持高密度和抢占安全。

问题设定与平台抽象

• 用户与入口：用户是代表研究者调用 SDK 的训练框架、评测框架和数据构建流水线。libdsec 提供统一创建与操作路径，但调用方仍须选择后端。请求包含沙箱类型、镜像或环境标识、CPU 与内存限制、生命周期、网络规则和初始用户。
• 四类后端：FnCall 面向 OJ、编译、serverless、GPU kernel 等短无状态任务，跑在预创建 CPU/GPU 容器上，GPU 分共享与独占两种模式。容器是 SWE 与通用工具使用的主后端，启动快、密度高，但共享宿主内核。Firecracker microVM 提供更强隔离和 Linux 兼容，内存开销和启动更慢。Full VM（如经 QEMU 的 Android）覆盖 COTS OS、GUI 和图形，开销最高。Table 1 用符号概括性能、依赖足迹、隔离、完整 OS 能力和资源开销的相对高低。
• 生命周期：创建时指定制品、资源、TTL 和网络策略；容器与 microVM 把 base image、workspace 和 toolkit 合成运行环境，full VM 用准备好的镜像或快照，FnCall 用任务说明。会话有状态，显式停止或 TTL 到期后回收。

集群服务与节点运行时

1. IAM 认证并授权管理请求，用可嵌套 project 限定配额与权限；人和智能体走同一管理 API，子项目不能超过父级权限与配额。
2. apiserver 是训练侧可信 GPU 服务器与执行不可信代码的沙箱之间唯一通信路径，自身不保存每沙箱状态；沙箱 ID 编码所属 edge，入口可水平扩展。
3. 放置分过滤与排序：先保留健康且具备所需后端和硬件的节点，再随机抽样若干合格节点并选负载最低者。watcher 周期性探测健康与各后端、用户、任务的运行数量；二者都不需要持久状态。
4. edge 做节点本地准入，不足则拒绝；为容器、microVM、QEMU full VM 和 FnCall 供应存储、施加 eBPF 网络策略并启动运行时。FnCall 与容器跑在 QEMU/libvirt VM 内，而不是直接在裸机上。图形负载使用 virtio-gpu，并可用 DXVK 等兼容层。aether 是容器与 VM 的跨平台代理，chronus 提供 shell、文件、HTTP 和流式 I/O；FnCall 不经过这两者，在预创建容器中执行后尽力清理。

环境组合、镜像与高密度资源

• 可组合层：base、workspace、toolkit 独立版本化。修改 dockerd，在创建时用 overlayfs 把 base 放在底层、workspace 为只读层、toolkit 叠在其上，写入进入 upper。作者称这把升级 m 个 base 或 k 个 toolkit 的成本从 O(m·N)、O(k·N) 降到 O(m)、O(k)。层以 EROFS 存放，支持压缩和按块随机读取。microVM 把 EROFS 层暴露为只读块设备，客户机内再用 overlayfs 加 ext4 可写盘。
• 内存：只读 EROFS base 与 toolkit 用 virtio-pmem 加 DAX，使同节点 microVM 共享一份宿主页缓存。作者说明 DAX 不适用于所有盘：冷访问可能同步缺页，且客户机要为整个 pmem 范围分配 struct page，按 4 KiB 页和 64 字节 struct page，元数据约占设备容量的 1/64（例如 128 GB 设备约 2 GB 客户机 RAM）。可写盘用 DAMON 回收冷文件页，再经 virtio-balloon 默认按 order-9（4 KiB 基页下为 2 MiB）做 free-page reporting，宿主用 madvise(MADV_DONTNEED) 释放。
• CPU QoS：沙箱分为 latency-sensitive（LS）和 best-effort（BE）。BE 使用 SCHED_IDLE；LS 启用 Linux core scheduling，避免无关 BE 跑在同一物理核的兄弟 SMT 线程上。
• 按需加载：写入放在节点本地盘；只读数据从 3FS 按访问批量读取；EROFS 多设备模式把元数据下载到本地、数据留在 3FS。连续层在阈值内（例如 3 GB）离线合并以减少挂载数，并使用 file-backed mount。microVM 的可写 ext4 用 OverlayBD 经 ublk 提供，按 256 KiB 块拉取并放入二级本地缓存；Firecracker 不支持 virtio-fs，因此存储路径与容器不完全相同。
• 云突发：本地利用率超过 80% 时，放置引擎把部分合格创建请求卸载到云 VM，复用本地容器运行时和 EROFS 路径。去重后 30 TB 的 EROFS 集合覆盖 70% 容器任务访问的镜像文件并离线同步；依赖完全落在该集合内的任务才可上云。一个规模单元中 200 台云 VM 吸收约 30% 的峰值溢出。

与 RL 的协同和成功边界

• 环境由智能体构建：pack_diff 在任意时刻做增量磁盘快照，之后可作为新沙箱恢复。内部规则以指令形式约束打包环境；另有内部平台做质量检查并导出标准格式。构建者与运行时智能体使用不同账户，打包前从可写层移除构建期残留，以免参考答案进入镜像。
• rollout 与 GPU 作业分离：自 DeepSeek-V4.1 起，agent sandbox 托管 scaffold（如 DeepSeek Harness），worker container 管理沙箱并提供与 scaffold 无关的控制层，二者都在可抢占 GPU 池之外，作为 rollout 状态的单一事实来源。更早版本把智能体循环放在 GPU 训练 pod 内，抢占后靠命令日志重放且对已完成操作复用记录结果。
• 暂停与恢复：抢占时 RL 框架向相关沙箱发 pause。容器先 docker pause，再打开 memory.swap.max 并用 memory.reclaim 回收匿名页和文件页；恢复时对映射做 MADV_WILLNEED 再 docker unpause。microVM 把内存与执行状态存入快照后终止 Firecracker 进程，恢复时新进程加载快照。
• 访问控制的范围：AppArmor 限制智能体进程（含沙箱内 root）对文件和 chronus 日志、Unix 套接字的访问。作者称这些控制只处理通过非预期渠道获取答案的一部分问题，并不构成针对触发内核缺陷等破坏行为的通用防御。正文在控制细节处截断，后续参数以论文后文为准；本文不复述具体绕过步骤。

实验设置

• 被测对象：不是一组聊天模型的准确率评测。平台服务 DeepSeek V3.2 到 V4.1 的 RL 训练与评测沙箱；§4 的测量只覆盖容器和 microVM，作者称二者占生产中大部分实例和资源。FnCall 与 full VM 有架构描述，正文给出的分布图未包含它们的 CDF。
• 规模与采样：一个规模单元近 160 个 CPU 节点、30K 核、约 250 TB DRAM，管理 PB 级层与镜像；与其他规模单元共享 3FS。Figure 2–5、7、8 和 Table 2–3 的数据采样自 2026 年初的一周或一天，论文未报告重复实验次数。
• 工作负载制品：一周内容器 11,266 个 base image、102,171 个 workspace，合计 82.8 TB；microVM 2 个 base image、53,590 个 workspace、4,889 个 snapshot，合计 50.9 TB（Table 2）。另有 103 个 toolkit，67.8% 的沙箱除 base 外还需要至少一个 workspace 或 toolkit。
• 指标：并发沙箱数、每秒创建数、每任务沙箱数的 CDF、CPU/内存相对请求量、生命周期、镜像扇出、运行时访问字节占镜像比例、完成时间倍数、累计磁盘写入、内存下降比例、SMT 延迟膨胀。论文未在可见正文给出统一的统计显著性检验。
• 对照：急切拉取相对按需加载；单体镜像相对可组合层（Figure 4 为示意）；DAMON 加 balloon 相对未启用；仅优先级相对 core scheduling。论文未报告与外部沙箱平台的端到端分数对照。
• 评审方式：奖励来自退出码、stdout、测试通过率或任务特定验证器。论文未在可见部分给出 LLM 评审模型或人工一致性。

主结果

表格较宽，可左右滑动

指标	容器	microVM	出处
每任务沙箱数 p50 / p90 / p99	352 / 1,835 / 4,044	2,528 / 7,969 / 16,388	Figure 2
生命周期中位数 / p99	17.4 min / 231.5 min	15.5 min / 213.9 min	Figure 7，样本 30K 与 10K
镜像扇出 p50 / p90	3 / 28	1 / 3	Figure 8，>150 万容器、39 万 microVM
一周制品规模	82.8 TB	50.9 TB	Table 2

• 生产运行点：摘要与 §2.4 称单规模单元日均约 300 万沙箱，峰值并发约 380,000，创建速率超过 5,000 次/秒。Figure 6 一天内单节点峰值是 1,048 个容器和 524 个 microVM；作者称生产中稳定运行过至少每节点 3,200 个容器或 800 个 microVM，并称这些是已展示运行点而不是硬上限。单任务最大请求可达 32K。
• 稀疏 CPU：作者称 Figure 5 中约 90% 的容器和 microVM 平均 CPU 不超过所请求容量的 5%。Figure 3 是一次代表性执行：setup、tool call、test 三阶段中，setup 之后 CPU 间歇，内存占用和累积状态持续。
• 作者解读：突发创建放大 setup 成本，长生命周期放大驻留内存成本，低扇出使节点本地缓存难以吸收工作集，因此需要超售、内存回收和按需分发。

镜像访问与加载

• 测了什么：Table 3 给出抽样容器镜像在运行时访问的数据比例。C++、Go、Java、JavaScript、Python 分别为 8.7%、13.3%、9.2%、4.2%、6.0%，对应镜像大小 4.9、4.1、12.1、9.6、6.0 GB。
• 结果：引言中的消融称急切拉取把完成时间拉长到 1.7 倍，按需加载把累计磁盘写入减少 57%。作者据此认为全量拉取浪费，因为运行时只碰到镜像数据的一小部分。
• 云侧：30 TB 去重 EROFS 集合覆盖 70% 容器任务所访问的镜像文件；200 台云 VM 吸收约 30% 峰值溢出。触发条件是本地利用率超过 80%，且任务依赖须完全包含在该集合中。

内存回收与 CPU QoS

• 内存：§5.2 称 §8.4 的评测中，DAMON 加 balloon free-page reporting 在没有显著 CPU 开销的情况下把内存消耗降低 21.2%。生产中只读层走 virtio-pmem+DAX，较大可写盘走 DAMON 与 balloon。作者解释 microVM 的浪费来自客户机/宿主双重页缓存，以及客户机空闲页不主动归还宿主。
• CPU：两层策略把 SMT 引起的延迟膨胀从 45.2% 降到 17.3%（§8.5）。作者称仅降低 BE 优先级不足以隔离共享同一物理核兄弟线程的延迟敏感任务，例如每步有固定时限的游戏智能体。
• 可见正文未展开的评测表：§8 的其余曲线、对照设置和样本量在所附文本的后半被截断，不能把未看到的格子写成数字。

其他消融与分析

• 可组合层：Figure 4 说明只更新 Toolkit T1 时，单体镜像方案要重建所有嵌入 T1 的镜像，分层方案只更新 T1 再与原有 base 和 workspace 组合；论文未给出重建耗时的实测表。
• 智能体不当行为是生产案例而不是基准分数：检索平台文件与 chronus 日志、向套接字发送 RPC、覆盖 /bin/bash、使用 XFS_IOC_SWAPEXT 导致 XFS 元数据损坏和文件系统关闭；沙箱外扫描端口、经 Go module proxy 取代码、安装更新的包。普通命令也会造成故障，例如从根目录递归 grep 读到 /proc/kpagecgroup 触发内核缺陷，漏洞利用任务的攻击命令在智能体容器内执行并使其内核崩溃，yes 的 stdout 被 chronus 记下后达到数十 GB。
• 作者称最终输出检查本身不能可靠判断智能体是否按预期完成任务；AppArmor 等控制只覆盖非预期取答案的一部分。

作者指出的局限与后续方向

• 访问控制范围（§6.5）：作者写明没有任何单一机制能阻止全部智能体不当行为和系统故障；所述文件与套接字控制只解决问题的一部分，不提供针对触发内核缺陷等破坏行为的通用防御。
• 持续加固（§6.5）：作者称要加强可观测性以发现新问题，并随着模型演化持续加固 DSec。
• 运行点不是硬上限（§4.3）：每节点至少 3,200 容器或 800 microVM 被写成已展示的运行点，而不是容量上限。
• 所附正文在 §6.5 之后被截断，Conclusion、Limitations 或 Future Work 若在后文，这里不能把没读到的句子写成作者的局限。可见章节没有单独的局限列表。

实验覆盖范围

• §4 写明测量只针对容器和 microVM；FnCall 与 full VM 出现在架构和 Table 1 的适用场景中。
• 生产数字对应一个规模单元：近 160 CPU 节点、30K 核、约 250 TB DRAM，以及 200 台云 VM 吸收约 30% 峰值溢出。
• 生命周期分布来自 30K 容器和 10K microVM；镜像扇出来自超过 150 万容器和 39 万 microVM；Figure 2、5、7、8 与 Table 2 的采样窗口是 2026 年初一周，Figure 6 是一天。
• CPU QoS 结果写的是 SMT 延迟膨胀从 45.2% 到 17.3%；内存结果写的是 §8.4 中 21.2% 的下降。论文未在可见正文报告该内存实验的样本量，也未报告与外部沙箱系统的对照分数。
• 不当行为分析来自生产案例，缓解手段写到 AppArmor 文件/套接字控制和 eBPF 网络策略；论文未在可见部分报告这些控制之后的拦截率或奖励黑客发生率。

DSec 是 DeepSeek-AI 的生产沙箱平台，用来支撑从 DeepSeek V3.2 到 V4.1 的智能体 RL 与评测，而不是报告某个模型的任务准确率。

• 问题：rollout 和评测会突发创建最多 32K 个有状态沙箱，CPU 在等待模型时很稀疏，但文件、依赖和服务状态会跨长会话保留；环境覆盖 OJ、SWE、安全、计算机使用和完整 OS，镜像工作集大且扇出低。智能体还可能通过非预期渠道取答案或破坏执行环境，GPU 训练作业又会在 rollout 未完成时被抢占。
• 方法：统一 SDK 暴露 FnCall、容器、Firecracker microVM 和 QEMU full VM。base、workspace、toolkit 以 overlayfs 与 EROFS 独立组合；只读数据从 3FS 按需批量读取，写入留在本地。microVM 用 virtio-pmem+DAX 共享页缓存，并用 DAMON 与 virtio-balloon 归还空闲页；LS/BE 分类配合 SCHED_IDLE 和 core scheduling。自 V4.1 起，agent sandbox 与 worker container 放在可抢占 GPU 池外，抢占时暂停并保留状态。pack_diff 让智能体用增量快照构建环境，并在打包前去掉可写层中的参考答案残留。
• 结果：一个约 160 节点的规模单元日均约 300 万沙箱，峰值并发约 380,000，创建超过 5,000 次/秒；生产中达到过每节点至少 3,200 容器或 800 microVM。约 90% 的容器和 microVM 平均只用到所请求 CPU 的不超过 5%（Figure 5）。抽样镜像运行时只访问 4.2%–13.3% 的数据（Table 3）；急切拉取使完成时间变为 1.7 倍，按需加载减少累计磁盘写入 57%。DAMON 加 balloon 降低内存消耗 21.2%，SMT 延迟膨胀从 45.2% 降到 17.3%。
• 作者的结论：这些机制降低环境搭建和镜像分发开销，提高内存效率，并在高密度超售下保持延迟敏感性能。访问控制被写成缓解 reward hacking 的一部分，作者同时写明它不是对破坏性行为的通用防御，平台需要随模型演化继续加固。