DeepSeek知乎独家发文，首次公开V4.1 Agent训练“大本营”DSec

2026-09-30 13:18:05

DeepSeek在知乎独家发布技术长文，首次系统阐释了DeepSeek弹性计算（DeepSeek Elastic Compute，DSec）

近日，DeepSeek在知乎独家发布技术长文，首次系统阐释了支撑DeepSeek-V4全部训练、评测与数据预处理流程的沙盒基础设施——DeepSeek弹性计算（DeepSeek Elastic Compute，DSec）。文章基于的技术报告《DeepSeek弹性计算（DSec）：面向大规模智能体训练的高效沙箱基础设施（DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale）》已公开至arXiv，由DeepSeek联合清华大学发布，作者团队超过130人，梁文锋也位列其中。

以下为DeepSeek知乎原文：https://zhuanlan.zhihu.com/p/2088265189233779592

DeepSeek 弹性计算 (DSec)：面向大规模 Agent 训练的沙盒基础设施

DeepSeek 弹性计算 (DeepSeek Elastic Compute, DSec) 是支撑 DeepSeek-V4 全部训练、评测与数据预处理流程的沙盒基础设施。要训练一个可靠的 Agent 大模型，需要其能在真实环境里反复地试错：阅读代码、修改文件、安装依赖、执行测试、运行服务。这些操作会不断改变环境，沙盒必须在多轮交互中持续保留状态。

这类负载有几个鲜明的特点：沙盒创建请求是脉冲式、突发的；启动后 CPU 大部分时间闲置，内存却需要持续驻留；Agent 执行环境种类多，基础镜像复用率低；任务执行时间长，训练还可能因资源抢占而中断。这些特点直接决定了 DSec 的设计。

统一接入，适配多样任务

不同的 Agent 任务对隔离强度、操作系统功能和执行开销的要求各不相同。DSec 支持 FnCall、Container、MicroVM 和 Full VM 四种执行后端，并通过统一的 Python SDK（libdsec）接入，根据任务类型按需选择。

其中，FnCall 会复用预先创建的容器，处理在线评测等短任务；Container 以较快的启动速度和较高的部署密度，服务最通用的软件工程和工具调用；MicroVM 提供更强的隔离边界，适用于安全任务等场景；Full VM 提供完整的操作系统环境，支持图形界面、图形渲染和 Android 等应用。

DSec 架构：统一管理沙盒创建与运行，多种执行后端适配不同任务。

分层可组合的环境

Agent 训练需要大量的环境，首先要解决的问题就是如何大批量地构建和更新环境。以 2026 年某一周的生产数据为例，容器后端使用了 11,266 个基础镜像、102,171 个工作区以及数百个工具包。按照传统方式，上述任意一部分更新或替换，都会导致大量镜像的重建。

为此，DSec 将沙盒的环境拆分为三部分：基础镜像（base image），包含操作系统与基础软件；工作区（workspace），包含任务所需的代码仓库与依赖；工具包（toolkit），例如 DeepSeek Harness。三者的更新节奏不同，版本管理各自进行，运行时再进行组合。

具体的，DSec 使用 EROFS 格式存储镜像、工作区和工具包，同时该格式还支持元数据与数据分离，以及跨镜像去重。创建沙盒时，通过 OverlayFS 按需将各 EROFS 镜像层组合起来。当基础软件、任务代码和工具包需要更新时，只需重建发生变化的 EROFS 镜像，减少无关内容的重复构建。

单体镜像(左）：更新工具包 T1 时，所有内嵌该工具包的镜像都需要重建。可组合的环境层（右）：只需更新工具包 T1 所在的层，再与已有的基础镜像和工作区组合。

镜像按需加载

我们对生产环境使用的镜像数据进行了分析，发现沙盒运行时实际访问的数据量仅占镜像总大小的 4.2% 至 13.3%。这意味着，如果提前拉取完整镜像到本地，其中绝大部分数据都不会用到。

因此，DSec 选择将全部镜像数据存储在 3FS 分布式文件系统上，只把所需镜像的元数据拉取到本地（EROFS 格式特性），而占大头的数据则在访问时按需读取，让 I/O 开销随实际使用的数据量缩减。

在一次集中创建 8,192 个容器的实验中，与完整镜像拉取方案相比，按需加载将任务完成时间从 60 多分钟缩短至约 35 分钟，加速比约为 1.71，磁盘写入量减少约 57%。在另一项工作区供给实验中，将逐个沙盒解压 tar.gz 文件改为直接挂载 EROFS 层后，任务完成时间从 79 分钟缩短至 45 分钟。

工作区存储方式对比：从解压 tar.gz 文件改为直接挂载 EROFS 层后，任务完成时间从 79 分钟缩短至 45 分钟，磁盘写入总量降至原来的约 1/5.5。

集中创建 8,192 个容器时的三种镜像提供方式：与完整镜像拉取方案相比，按需 EROFS 加载将任务完成时间从 60 多分钟缩短至约 35 分钟，加速比约为 1.71，磁盘写入量减少约 57%。

高密度资源管理

Agent 训练的特点是，沙盒大部分时间都在等待模型生成下一步动作。如图，约 90% 沙盒的平均 CPU 用量，不会超过其申请量的 5%，CPU 会长时间闲置；但为了保留文件、进程等状态，内存需要持续驻留。这为极高的超卖率留足了空间，而我们生产环境的超卖率也超过了 50 倍。

按申请量归一化的平均与峰值 CPU、内存用量分布：约 90% 的沙盒，其平均 CPU 用量不超过申请量的 5%。

为了实现资源高密度部署，需要尽可能地共享缓存和回收闲置内存。DSec 通过 virtio-pmem 与 DAX 技术，让同一宿主机上的 MicroVM 共享一份宿主页缓存。实验中，单独启用这一机制，可使宿主机的峰值内存用量较基线下降 40.2%。实验中，单独启用内存回收机制（ DAMON 与 balloon 空闲页报告），可使按时间累计的宿主机内存消耗较基线下降 21.2%。两种机制结合使用时，总体内存消耗最低。

四种 Firecracker 配置的宿主机内存与 CPU 用量对比：相较未优化基线，单独启用 virtio-pmem 与 DAX，峰值内存用量下降 40.2%；单独启用 DAMON 与 balloon 空闲页报告机制，按时间累计的内存消耗下降 21.2%。

在如此高密度部署的情况下，DSec 还会优先保障对响应时间要求较高的任务，让时延要求较宽松的任务利用空闲 CPU 资源运行，并通过核心调度减少同一物理核心上超线程的干扰。实验表明，通过优化 CPU 调度，当同机运行的其他任务占用节点 50% 的 CPU 容量时，时延敏感任务相对于无干扰基线的时延增幅由 45.2% 降至 17.3%。

CPU 调度实验：高密度部署下，优先保障时延敏感任务，降低同机负载的干扰。

三项核心机制：镜像按需加载、可组合的环境层、高密度资源管理。

轨迹执行 (rollout) 与 GPU 训练解耦

在强化学习（RL）训练中，Agent 通常需要同沙盒环境进行多轮交互，才能完成轨迹执行（rollout）。在早期的训练流程中，Agent 执行循环与 GPU 训练任务运行在同一个 Pod 容器中。训练任务被抢占打断后，环境沙盒虽然还在，负责推进交互的 Agent 执行循环却已终止。恢复时，系统需要重放命令日志，将训练框架保存的进度与沙盒中的实际执行过的状态重新衔接起来。这样的恢复逻辑非常复杂，也增加了多个组件之间的协调成本。

从 DeepSeek-V4.1 开始，我们将这部分执行逻辑迁移到 DSec 沙盒中，并拆分为 Agent 沙盒和工作容器（worker container）协同完成：Agent 沙盒运行 Agent 框架和工具包，工作容器负责管理沙盒、推进交互流程。两者都部署在可被抢占的 GPU 资源池之外，共同保存执行进度和环境状态。因此，GPU 训练任务被抢占时，Agent 的执行状态仍能完整保留；训练恢复后，Agent 即可从中断处继续执行。

用 Agent 构建运行 Agent 的环境

大规模的 Agent RL 训练和评测需要高度多样化的运行环境，包括但不限于二进制依赖、代码仓库、Harness 工具包、评测脚本等一系列用于生成 Agent 产物并衡量其正确性的组件。面对这一复杂需求，使用 Agent 进行自动化环境构建，是一种高效、可规模化制作 Agent 环境的方法。

我们注意到，该构建环境的 Agent，本身就已经运行在其构建的环境里了。在这种情况下，与其为 Agent 训练构建一套平台、再为 Agent 造环境构建另一套平台，不如将两者放在同一个 “运行 Agent 的平台” 也就是 DSec 上，大幅简化系统架构的同时，还能保证 Agent 的构建环境和运行时完全一致。

DSec 为环境构建引入了 pack_diff 打包机制：Agent 可以指挥平台对沙盒创建增量快照，以在未来将其恢复为新的沙盒。如此，我们可以轻松保存沙盒的状态，甚至于可以把 Agent 执行的每一轮交互都转化为可复用的沙箱环境。

这种增量快照更可用于轨迹分叉：在第 k 步保存快照，从同一状态恢复出多个沙盒，分别继续探索。各分支共享只读层，同时只记录变更，避免反复执行分叉前的步骤。MicroVM 的快照支持保存和恢复内存及进程状态，但容器侧目前主要支持磁盘级快照。

面向 Agent 的安全边界

随着 Agent 智能体能力增强，训练环境的安全边界也需要持续完善。在生产环境中，我们观察到 Agent 会尝试读取残留答案、伪造 RPC 请求、覆盖 /bin/bash 以注入命令，甚至尝试通过 XFS_IOC_SWAPEXT 绕过访问控制等。这些行为会影响训练和评测结果，甚至破坏运行环境。

只要环境存在获取奖励的捷径，模型就可能利用它。因此，DSec 将细粒度访问控制作为基础功能之一：通过 AppArmor 约束文件读写和套接字访问，即使智能体以管理员身份运行，这些限制依然有效；通过 eBPF 为每个沙盒执行网络访问白名单，限制其能够连接的地址、端口和协议。

但这些措施只能缓解部分问题，对于触发内核缺陷等破坏性行为，目前仍缺乏通用防御机制。相信随着模型能力提升，我们与 Agent 的攻防将会一直持续下去，系统的安全机制也会一同迭代、完善。

生产数据

DSec 以分片的形式实现横向扩展，每个扩展分片约包含 160 台服务器，提供约 3 万个 CPU 核心和 250 TB 内存。单个分片每天服务约 300 万个沙盒，峰值并发超过 38 万个，每秒可创建超过 5,000 个沙盒。

生产环境部署了多个这样的分片，可支持数百万个沙盒同时运行。

从 DeepSeek-V3.2 到 DeepSeek-V4.1，DSec 承载了 Agent 训练、评测与数据预处理中的全部沙盒负载。我们已将 DSec 技术报告 《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》 公开至 arXiv，分享支撑大规模 Agent 沙盒运行的工程实践。

结语

我们相信，Agent 的能力还有无限的想象空间。接下来，我们会将 Agent 运行环境的数量和种类扩充成百上千倍，把这些任务培养出的能力带回开放模型。 这需要更多样的环境、更可靠的基础设施，也需要更多开发伙伴。

欢迎加入我们，一起搭建面向 Agent 的弹性计算平台，一同建设下一代 Agent 基础模型。