DeepSeek DSec：每天服务约 300 万个沙盒的训练基础设施

训练一个会写代码的 Agent，不能只让它阅读代码和答案。它需要进入软件仓库，安装依赖，修改文件，运行测试，再根据结果决定下一步。一次任务往往要经历许多轮这样的交互。模型生成下一条指令时，计算环境还得留在原处：刚装好的包、改到一半的文件和正在运行的服务，都可能影响接下来的操作。

当训练同时展开成千上万次尝试时，提供这些环境就成了一项独立的基础设施工作。平台既要迅速创建干净环境，也要保存执行中的状态；既要容纳大量等待模型响应的沙盒，也不能让其中一次失控操作破坏其他任务。

DeepSeek 在 9 月 19 日公开的 DSec 论文，展示了这项工作的生产规模。论文报告，一个生产单元约有 160 个 CPU 节点、3 万个 CPU 核和合计约 250 TB 内存，典型一天服务约 300 万个沙盒实例，峰值并发约 38 万，创建速率超过每秒 5,000 个。它承载了 DeepSeek V3.2 至 V4.1 强化学习训练与评测所需的全部沙盒负载。[1]

这些数字说明，环境已经需要像模型计算一样，被单独规划容量、调度资源和处理故障。但它们还不能证明训练的主要瓶颈已经从 GPU 转移到环境。DSec 更值得研究的地方在于：它把模型计算与环境执行各自需要保留的状态分开管理，再围绕环境的实际使用方式，重新安排存储、内存和 CPU。

先看全貌：一次训练要协调哪些工作

Agent 强化学习中，一条训练样本通常来自模型与环境的多轮交互。模型决定下一步动作，沙盒执行命令，结果返回给模型，直到任务结束。这一整段交互称为 rollout。训练框架随后对结果评分，并用轨迹与奖励更新模型。评测也会生成这样的轨迹，只是不据此更新参数。

这里有三类性质不同的工作：模型推理负责生成动作，环境负责执行动作并保存状态，训练负责利用收集到的数据更新参数。实际系统可以让它们交叠运行。DSec 管理的是环境及与之关联的执行过程，不能把 rollout 移入 DSec 理解为模型推理不再需要 GPU。

DSec 对外提供 Python 库 libdsec。调用方指定环境、资源和网络权限，创建沙盒，再执行命令、读取结果，最后释放环境。接口相近，并不意味着各种运行方式完全一样。一次短代码执行不必承担完整虚拟机的成本，涉及内核边界的安全任务也不能只追求启动速度。

还要区分容器与裸机之间的关系。DSec 的 FnCall 和容器运行在 QEMU/libvirt 虚拟机中，虚拟机在不可信代码与裸机之间增加了一道隔离边界。容器共享的是这台虚拟机的内核，并非直接共享裸机内核。这个细节关系到故障会波及哪些任务，不能被一张由轻到重的后端示意图省略。[1，§2.2、§3.3]

创建请求的放置则分成两步。集群侧先过滤不健康或能力不匹配的节点，再随机抽取几个候选，选择其中负载较低的节点。这样可以减少大量并发请求同时涌向同一台“最空闲”机器的现象。节点本地的 edge 组件再根据即时资源状态决定是否接纳；如果资源紧张，它可以拒绝请求，让系统另选节点。

这两步缺一不可。集群视图定期刷新，适合快速筛选，却不可能准确反映每个瞬间的资源变化。把最终接纳权留给节点，才能防止过时的集群估计覆盖当前的内存或 CPU 压力。平台还会把尚未进入监测快照的新放置结果计入本地估计，以减轻连续分配造成的误差。[1，§3、§7]

环境准备：先拆开更新，再减少搬运

沙盒规模扩大之后，最先暴露的问题往往不是执行命令慢，而是命令开始前要搬运和解压太多内容。

DSec 的一个生产周内，容器后端使用了 11,266 个基础镜像和 102,171 个工作区，平台还提供 103 个工具包。基础镜像包含操作系统和语言运行环境，工作区包含任务代码及依赖，工具包则包括 Agent 执行框架等经常更新的组件。三者的更新频率不同，却要组合成任务看到的同一个文件系统。

如果每个任务都把这些内容打成一个完整镜像，工具包升级就会迫使所有内嵌它的镜像重新构建，即使操作系统和代码仓库毫无变化。另一种做法是在启动后解压工作区和工具包，但同一批任务会反复做相同的解压和写盘工作。请求集中到达时，这些准备工作会与已经运行的任务争用资源。

DSec 将它们保存为独立版本的只读层，在创建沙盒时组合。底层是基础镜像，其上叠加工作区和工具包，最上面再放一层可写目录。Linux 的 overlayfs 把这些层呈现为一棵目录树；文件冲突按层的优先级处理，运行时修改进入可写层，不改变下方供其他沙盒复用的内容。

这样，工具包升级只需要产生新的工具包层，任务可以继续使用原有的基础镜像和工作区。收益来自避免重建未发生变化的组件。把基础镜像数与工作区数相乘，得到十几亿种理论组合，并不能代表平台过去实际维护过那么多镜像；真正需要减少的是已有任务组合中的重复构建与重复数据。

分层之后，仍然没有必要在启动前下载每一层的全部内容。论文抽样的不同语言容器镜像，运行期间实际访问的数据仅占镜像的 4.2% 至 13.3%。同时，很多任务使用的镜像复用次数很少，本地缓存难以提前覆盖如此分散的环境。全量预热只能提前承担搬运成本，不能消除它。

DSec 用只读文件系统 EROFS 保存已发布的层。与必须顺序解压的压缩包不同，它能够按访问位置读取、解压对应的数据块。容器路径将目录结构等元数据预先放到本地，文件内容保存在 DeepSeek 的分布式文件系统 3FS 中，读取到哪里，再取回所需数据；运行时写入则留在本地可写层。

这个分工与存储系统的特点有关。3FS 擅长大块读写，小而频繁的随机 I/O 则表现较差。因此，路径查找留在本地，读取按需进行、以较大的块传输，无法预先控制的日志和文件修改也留在本地。按需加载的价值不只是提前启动，而是减少了整段任务实际搬运的数据。

microVM 需要保留另一条存储路径。例如，在虚拟机内部再运行 Docker 时，其数据目录不能简单放在 overlayfs 之上，论文使用的 Firecracker 也不支持 virtio-fs。DSec 因而将只读基础层与工具层继续放在 EROFS 上，让可写 ext4 磁盘通过 OverlayBD 和用户态块设备框架 ublk 提供。该路径按 256 KiB 块从远端取数，并保留本地二级缓存。代价是 ext4 元数据仍混在磁盘映像中，部分元数据访问也可能触发远端读取。[1，§5]

这说明统一平台没有消除后端差异。容器可以按文件系统结构优化元数据位置，虚拟机则要兼顾块设备和应用兼容性。两条路径都追求少搬运、少重复写入，但不能仅凭接口一致，就假设它们具有相同的启动和访问性能。

高密度运行：空闲 CPU 不等于空闲内存

环境装好以后，Agent 往往在模型生成下一条指令时等待。论文统计，约 90% 的容器和 microVM，其平均 CPU 使用量不超过申请容量的 5%。如果平台按申请量预留 CPU，大量已分配算力会长时间闲置。因此，DSec 允许分配给沙盒的 CPU 总量超过物理容量，让间歇工作的任务共享机器。

但平均用量低不代表每个时刻都低。安装依赖、编译和测试可能同时形成计算高峰，某些任务又有严格的响应时限。DSec 把沙盒分成延迟敏感与尽力而为两类，让后者通过 Linux 的 SCHED_IDLE 调度策略优先让出 CPU。

仅降低调度优先级还不够。一个物理 CPU 核通常有多个逻辑线程，它们共享执行资源。后台任务即使没有抢占前台线程，也可能在同一物理核的另一个线程上与之竞争。因此，DSec 又启用核心调度，防止无关的后台任务与延迟敏感任务同时占用同一物理核的相邻线程。

在论文的棋类评测实验中，后台负载达到节点 CPU 容量的 50% 时，没有保护的单步延迟比无共置负载时增加 45.2%；采用两层控制后，增幅降到 17.3%。两层控制仍未消除所有干扰：多核高负载会使 CPU 的睿频频率下降，任务之间也仍会争用内存带宽和末级缓存。这项实验支持的是特定负载下的延迟保护效果，不是所有任务吞吐都会按相同比例改善。[1，§8.5]

内存的问题恰好相反：CPU 等待时可以让给别人，任务状态却不能凭空消失。microVM 还有额外浪费。同一份镜像内容可能同时留在宿主机页缓存和多个虚拟机的页缓存里；虚拟机内部已经空闲的页，如果没有主动报告，宿主机也未必能收回。

DSec 分别处理这两类浪费。对于只读基础镜像和工具层，它使用 virtio-pmem 配合 DAX，让虚拟机直接访问宿主机内存中的文件数据，省去在虚拟机内再保存一份页缓存。对于较大的可写磁盘，Linux 的 DAMON 内存访问监测机制找出长期未访问的文件页，促使内核回收；虚拟机再通过空闲页报告，将可释放的内存交还宿主机。

这两种机制改善的指标不同。在真实 Agent 强化学习负载的对照实验中，virtio-pmem 与 DAX 使峰值宿主内存下降 40.2%；单独使用 DAMON 与空闲页报告，峰值变化不大，但一段时间内内存占用的累计量下降 21.2%。前者主要消除重复缓存，后者主要缩短无用页面的占用时间。

节约也有代价。virtio-pmem 需要虚拟机为映射范围保留页元数据：论文给出的例子是，128 GB 设备需要约 2 GB 虚拟机内存来保存这些元数据。冷数据访问还可能引发同步缺页处理。实验中，启用该机制时的瞬时 CPU 峰值由 26.5% 升到 41.4%，论文将冷访问路径差异列为可能原因之一。CPU 已经紧张的部署，因此可能只启用空闲页回收，保留原有块设备读取路径。[1，§5.2、§8.4]

决定部署密度的，正是这些资源之间的交换关系。不能只看到沙盒等待模型时的低 CPU 用量，就认定还能继续增加任务；也不能只看到内存节省，就忽略首次访问和恢复时增加的 CPU、存储压力。

抢占恢复：保留工作进展，也要释放闲置资源

长任务还会遇到另一种中断：GPU 训练作业被调度器抢占。沙盒里的代码和进程可以留在原处，但驱动 Agent 交互的循环如果随着训练进程退出，系统仍然不知道恢复后应该从哪一步继续。

在早期架构中，Agent 循环与模型服务、强化学习框架一起运行在可抢占的 GPU 训练 pod 内。训练作业中断后，沙盒仍然存在，恢复过程却需要依靠命令日志，将训练框架恢复的状态与沙盒当前状态重新对应起来。对于已经完成的命令，系统复用记录中的结果，不重新执行，以免重复产生副作用。DeepSeek V4 技术报告也描述了这种恢复方式。[2，§5.2.5]

从 V4.1 起，DSec 把 rollout 执行拆成 agent 沙盒和 worker 容器。前者承载 Agent 执行框架及工具，后者管理沙盒并控制 rollout。两者都放在可抢占 GPU 池之外，共同保留完整执行状态。GPU 作业恢复后重新连接即可继续，不再通过命令日志重建这段执行过程。[1，§6.2]

这个改动的意义在于，让执行进度跟随实际工作的生命周期保存。训练作业为了提高集群利用率而中断，不应该迫使已经完成一半的代码修改重新解释自己的历史。但它并不意味着模型可以在没有推理算力时继续生成动作，也没有消除所有恢复开销：保留下来的环境还会占用内存。

因此，训练框架会主动暂停与被抢占作业关联的沙盒。容器路径先冻结进程，通过 memory.swap.max 允许换出，再调用 memory.reclaim 主动回收内存。恢复时，平台以 MADV_WILLNEED 发起异步预取，然后解除暂停。microVM 则将内存和执行状态保存为快照，终止 Firecracker 进程释放运行时内存；恢复时启动新进程并载入快照。[1，§6.3]

这里需要同时满足两个条件：任务状态必须留下，物理内存又不能一直被闲置任务占满。暂停与恢复因此成为调度的一部分。平台仍然要为换出、快照和预取支付 I/O 成本，具体是否划算，取决于暂停多久、状态多大，以及恢复时允许等待多长时间。论文没有给出这些操作对整段训练耗时的独立收益测量。

公开实验能说明什么，不能据此算出什么

DSec 的实验值得肯定之处，是把不同机制放在各自的对照条件下验证。其中两项结果最直接地回答了环境准备为什么值得优化。

第一项在独立的 10 节点测试集群上，同时发起 8,192 个容器任务。按需加载约 35 分钟完成整批任务，接近镜像全部预先放在本地的对照；从远端全量拉取则需要超过 60 分钟，论文报告其完成时间约为按需加载的 1.71 倍。按需加载还使每节点累计写盘量从超过 1,600 GB 降到约 700 GB，减少约 57%。这 35 分钟包含任务运行，不能拿任务数除以它，作为沙盒创建速率。[1，§8.2]

第二项比较工作区和工具包的准备方式，并用预先记录的确定性工具调用替代模型生成，尽量把差别限制在环境准备本身。逐沙盒解压压缩包时，整段任务完成需要 79 分钟；直接挂载 EROFS 层时为 45 分钟。这说明减少启动阶段的重复解压和写入，能够改善该实验的端到端完成时间。不过，它仍不是完整强化学习流水线的 GPU 利用率或总成本对照。[1，§8.3]

生产规模的数字要按另一组边界理解。单节点稳定运行 3,200 个容器或 800 个 microVM，是论文观察到的运行点，不是后端的硬上限，也不是同等任务条件下隔离成本恰好相差四倍的证明。论文另给出的某一天、某一节点峰值，只是该样本的负载记录，不能复制到所有节点后，拿来反证整个生产单元的并发规模。

同样，沙盒寿命的中位数也不能代替平均寿命。论文报告容器寿命中位数为 17.4 分钟，且容器和 microVM 的 p99（寿命从短到长排列后，99% 位置对应的值）都超过三小时。这揭示了长任务的存在，却没有给出平均驻留时间，更没有证明沙盒寿命等于一条训练轨迹的耗时。用这些数直接估算平均并发，会把不同统计对象混在一起。

那么，一个万卡训练集群究竟需要多少环境节点？公开材料还不足以给出可信的具体数量。至少要先测清楚三件事：实际进入系统的轨迹速率，每条轨迹在各类沙盒上占用的总时长，以及这些负载能在单节点上安全承载多少。还要区分训练、评测和环境构建，不能假设它们都按同一节奏运行。

在稳定观测窗口内，可以用利特尔法则估算平均占用：平均并发数量等于实际接纳的平均到达速率乘以平均驻留时间。到达速率和驻留时间都应使用同一稳定观测窗口内的平均值，不能把 GPU 或环境某一侧的理论最大能力代入。如果一条轨迹使用多个沙盒，应计入各个沙盒的占用时长；如果存在可复用的常驻池，则应单独核算。

举一个仅用于说明方法的假设：某类任务实际每秒接纳 10 条轨迹，每条轨迹只使用一个沙盒，测得平均驻留 20 分钟，则平均并发约为 12,000。若同类负载经压测确认每节点可稳定承载 1,000 个，12 个节点只是平均负载对应的等效需求；实际配置还需考虑负载波动、突发时的积压，以及故障冗余。这些数字都不是 DSec 的测量结果，也不能据此反推它与 GPU 的配比。

要找瓶颈，则需同时观察轨迹完成速率、训练消费速率、模型生成等待、环境创建等待和工具执行耗时。GPU 利用率偏低只能提示存在等待，不能单独区分是推理供给、环境供给、数据准备还是训练调度出了问题。对于突发请求，还要看队列如何随时间积累和消退；平均容量够用，不代表启动一批评测时不会排队。

应对突发需求时，DSec 会借用云端容量，但可分流的任务仍受环境依赖限制。它预先同步一部分高覆盖率镜像内容，只有依赖全部落在该集合内的任务才可以转往云端。论文报告，本地利用率超过 80% 时，平台会分流部分符合条件的新请求，200 台云虚拟机吸收约 30% 的峰值溢出。这是有选择的容量补充，不能理解为任意环境都能随时迁到云上。[1，§3.4]

环境正确性，本身就是训练数据质量

沙盒还承担了一项容易被资源数字遮蔽的工作：确保任务结果确实来自模型按预定方式完成任务。

论文记录的 Agent 行为包括查找平台日志中的答案、尝试伪造内部请求，以及通过外部镜像或软件包获取现成实现。在这类情况下，即使最终测试通过，也不能直接把结果视为模型能力提升。平台必须限制模型可以读取哪些文件、联系哪些服务，并检查得分过程是否符合任务规则。[1，§6.4]

这与“能否逃出沙盒”是不同的问题。一个 Agent 可以始终留在隔离边界内，却获得本不该看到的参考答案；也可能没有作弊意图，只因一次遍历特殊文件的命令触发内核缺陷，破坏了执行环境。因此，虚拟机隔离、文件权限和网络规则分别解决不同风险，不能互相替代。

DSec 用 AppArmor 限制文件读写和内部 socket 访问，即使 Agent 在沙盒内以 root 运行也受这些规则约束；网络侧根据任务允许访问的服务，通过 eBPF 按 IP、端口和协议执行过滤，任务进入新阶段后还可以更新规则。论文同时明确，这些控制不能普遍防住内核缺陷，仍需持续观测和加固。[1，§6.5]

Agent 自己搭建训练环境，同样需要这样的边界。DSec 提供 pack_diff 增量磁盘快照，能够将交互式搭建的环境保存下来，再恢复成新沙盒使用。这样，构建、验证和运行可以使用同一套基础设施。但论文也写明，环境要遵守平台规则，内部平台会做质量检查，再按标准格式交给训练与评测；构建者和运行时 Agent 使用不同账号，打包前还要清除可能残留在可写层中的参考答案。[1，§6.1]

这项能力说明环境构建可以进一步自动化，却不能单凭它证明模型已形成持续自我提升的闭环。要得出后一结论，还需要证明生成的环境足够有效、训练收益可以归因于这些环境，并且质量在多轮迭代中持续改善。DSec 论文没有提供这组实验。将“能够生成环境”与“环境足以产生可靠训练信号”分开，才能看清它已经解决了什么。

真正值得借鉴的是资源与状态如何分工

DSec 没有发明一个包办所有任务的新运行时。它保留不同隔离后端，利用独立只读层和按需读取减少环境准备工作，用内存回收和 CPU 调度支持高密度执行，再把长时间保留的 rollout 状态从可抢占训练作业中分离出来。这些选择共同回答了一个问题：在一项持续多轮交互的任务中，哪些内容可以共享、哪些资源可以暂时归还，又有哪些状态必须保留。

对建设同类平台的人，首先应该测量的是环境准备耗时、文件实际访问量、CPU 活跃程度、平均及长尾驻留时间，还有恢复后的等待。根据这些数据选择分层、缓存、CPU 超额分配或暂停策略，才能知道优化会减少哪一段等待，又会把成本转移到哪里。

论文已经给出了环境准备、内存效率和延迟保护的具体证据；尚缺的则是这些改进在完整训练流水线中带来的净收益和总成本。评价训练环境平台，最终应看它能否更稳定地交付有效轨迹，以及为此付出的整体成本，而不只是同时运行了多少沙盒。

---

声明： 本文基于公开材料分析，未复现 DSec 实验。生产规模与实验结果均为论文报告值；容量示例为本文明确设定的假设。图示为依据论文机制绘制的说明图。

[1] DeepSeek, DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale，arXiv:2609.22978v1，2026 年 9 月 19 日。

[2] DeepSeek, DeepSeek V4 技术报告，§5.2.5，本文仅用于核对早期抢占恢复方式。