DeepSeek 首度公开 V4.1 Agent 训练”大本营”：一个分片每天跑 300 万个沙盒

训练一个可靠的 Agent 大模型，光有算法远远不够——还得有一个能让它在真实环境里反复试错、又坏不了的生产线。

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

一分钟速览

• DSec 是什么：支撑 DeepSeek-V4 全部训练、评测与数据预处理流程的沙盒基础设施。
• 四种执行后端：FnCall、Container、MicroVM、Full VM，通过统一 Python SDK（libdsec）按需选择。
• 按需加载提速：集中创建 8192 个容器时，任务完成时间从 60 多分钟缩短至约 35 分钟，磁盘写入量减少约 57%。
• 超高密度部署：约 90% 的沙盒平均 CPU 用量不超过申请量的 5%，生产环境超卖率超过 50 倍。
• 规模惊人：单个分片约 160 台服务器、3 万 CPU 核心、250 TB 内存，每天服务约 300 万个沙盒，峰值并发超过 38 万个。

为什么 Agent 训练需要一个”沙盒工厂”

要训练一个可靠的 Agent 大模型，需要它能在真实环境里反复地试错：阅读代码、修改文件、安装依赖、执行测试、运行服务。这些操作会不断改变环境，沙盒必须在多轮交互中持续保留状态。

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

四种执行后端，按需选隔离强度

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

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

把环境拆成三块，更新不再”牵一发动全身”

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

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

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

数据说话：按需加载省了多少

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

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

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

超卖 50 倍，怎么做到的

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

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

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

与 Agent 的攻防：安全是长期课题

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

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

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

趋势洞察

DSec 的价值不只在于”快和省”。它把 Agent 训练的底层设施——环境构建、状态保留、资源调度、安全隔离——打包成了一套可复用的平台。当模型能力竞赛进入深水区，谁能把训练基础设施做得更高效、更安全，谁就更有可能在下一轮迭代中抢到先手。DeepSeek 这次罕见地公开”大本营”，某种程度上也是在展示自己在工程层面的肌肉。