梁文锋署名，DeepSeek发新论文，剑指大规模Agent训练

智东西9月23日消息，就在今天，DeepSeek创始人梁文锋署名的新研究论文对外发布，首次详细介绍了DeepSeek的Agent训练沙盒平台DSec（DeepSeek Elastic Compute）的技术架构。该论文于9月19日提交，作者名单超过130人，梁文锋位列其中。

论文链接：https://arxiv.org/pdf/2609.22978

DSec平台最初在DeepSeek V4技术报告中亮相，其核心功能是为Agent训练提供沙盒环境，保障大规模Agent训练的稳定执行。论文明确指出，从DeepSeek V3.2到V4.1的强化学习训练与评估中，所有沙盒负载均由DSec承载。如今公开技术细节，相当于将核心方案公之于众。

根据论文，DSec平台的规模相当庞大，其中一个生产单元包含约160个CPU节点、3万核以及250TB内存，并托管着PB级别的镜像数据。

在能力表现上，DSec平台每天可服务约300万个沙盒，峰值并发量超过38万个，沙盒创建速度超过每秒5000个，单个训练任务最多能一次性启动3.2万个沙盒。

那么，为何Agent训练需要如此大量的沙盒？面对复杂的执行环境，DSec又是如何解决规模、调度和资源管理挑战的？

01. Agent强化学习天然需要海量沙盒 训练环境成为发展瓶颈

传统大语言模型的强化学习往往围绕静态的输入、输出和奖励信号进行，但Agent训练完全不同。它要求模型真正进入真实环境，执行检查代码、调用工具、运行命令、修改文件等操作。模型每执行一步，都可能改变环境状态，而后续步骤又依赖于之前的结果。

这意味着，在Agent训练中，除了模型和数据，研究人员还需要维护大量“工作现场”。这些环境必须尽可能接近真实机器，能够安装依赖、运行软件，并在任务完成后恢复干净状态，供下一轮rollout使用。

问题在于，这些沙盒数量多且资源消耗不轻。

论文显示，训练过程中一次任务曾同时启动3.2万个沙盒。但这些沙盒并非始终满载运行，Agent执行任务时，沙盒经常处于等待下一步指令的状态，CPU利用率不高。然而，CPU空闲并不意味着资源已释放，内存和可写状态仍需持续保留。

因此，传统的“启动一个容器、执行完任务就结束”的模式难以继续。DSec平台的设计目标，就是同时解决沙盒的批量创建、资源调度、环境复制、状态保存、暂停恢复以及安全隔离等问题。

02. 四大环境需求：一套SDK统一管理 涵盖函数、容器和虚拟机

随着Agent执行的任务日益复杂，其背后的工作环境也无法再用单一规格来应对。

最轻量的任务可能只需一次函数调用，执行代码并返回结果；软件工程任务则需要完整的Linux用户态，以便安装依赖、修改代码和运行测试；安全攻防和计算机使用场景对隔离要求更高；若要操作某些商业软件，所需环境甚至接近一台完整的计算机。

DSec提供四种后端：FnCall、容器、Firecracker microVM和完整虚拟机，分别覆盖从短时函数调用、软件工程，到安全敏感任务和完整操作系统环境的不同需求。训练框架无需关心底层是容器还是虚拟机，通过Python SDK（libdsec），训练框架可以无缝完成沙盒创建、命令执行和结果获取，无需适配不同环境类型。

DSec的四种后端由同一平台统一调度。训练框架发起请求后，平台先进行身份和权限校验，再根据集群负载选择合适节点，由节点上的Edge负责创建沙盒。沙盒启动后，Aether和Chronus负责连接平台与沙盒内部的执行过程，镜像数据则由3FS按需提供。

但当这些环境从几种类型扩展到成千上万个实例时，新问题随之而来：如何快速复制出数量庞大且种类各异的环境。

03. 环境越多，复制越难： DeepSeek如何快速部署数万个沙盒

如前所述，Agent训练的环境不仅数量多，组合也相当复杂。

论文统计了一个生产周的数据：容器后端涉及11266个基础镜像、102171个工作区和103个工具包。实际运行时，67.8%的沙盒还会在基础镜像上叠加工作区或工具包。DeepSeek Harness就是其中需要频繁更新的一类组件。

如果将这些组件全部放入一个完整镜像中，任何一层的变化都可能需要重新构建和分发整个镜像。环境数量增多后，镜像维护和部署成本会随之上升。

DSec将基础镜像、工作区和工具包拆分为三个独立版本的只读EROFS层，沙盒启动时再通过overlayfs组合。这样，哪个组件发生变化，只需更新对应层，无需重新处理整个镜像。

镜像分发采用按需加载方式。论文发现，沙盒运行过程中实际读取的数据仅占完整镜像的4.2%到13.3%。因此，DSec将镜像数据存储在3FS上，运行时按需读取，同时将元数据预取到本地，写入则保留在节点本地盘。考虑到3FS更适合大块、连续读取，这种方法也能避免小块随机I/O带来的效率问题。

实际效果显示，当8192个容器同时突发部署时，按需加载耗时35分钟，而Docker冷拉取则超过60分钟，单节点累计磁盘写入量也从约1600GB降至约700GB。

论文表明，DSec平台中的环境构建也可由Agent完成。通过pack_diff，Agent配置好环境后生成增量快照，之后即可恢复成新的沙盒。

04. rollout搬离GPU： 训练与执行分离

早期方案中，Agent的推理和rollout与模型训练共用GPU Pod。一旦GPU任务被抢占，正在执行的rollout也会被迫中断。

从V4.1开始，DeepSeek将rollout从GPU训练环境中分离出来，交由DSec平台独立运行。Agent sandbox负责运行DeepSeek Harness等执行环境，worker container负责具体任务，两者都不再依赖GPU资源。这样，GPU训练被抢占时，rollout状态可以独立保留。

如果集群容量不足，DSec还支持向云端扩容。例如，当集群利用率超过80%后，符合条件的沙盒可以转移到云端虚拟机。为减少云端重新拉取镜像的开销，DeepSeek提前准备了约30TB的去重镜像集，其中约70%的文件会被容器任务实际访问。生产环境中，200台云虚拟机可以承接约30%的峰值负载。

05. 环境越真实 Agent操作带来的风险也越大

DSec解决了规模和效率问题，但真实环境还存在其他风险，例如Agent不一定按预期路径完成任务。

论文记录了多种异常行为：有Agent翻查日志、伪造RPC请求，甚至修改/bin/bash，试图绕过正常任务流程。还有Agent扫描可达服务、拉取外部代码，通过评测之外的路径寻找答案。

更棘手的是，Agent有时会破坏环境本身。论文记录了递归扫描系统文件导致内核崩溃的案例，甚至一个简单的yes命令，都可能让日志迅速膨胀到几十GB。

针对这些风险，DSec主要通过AppArmor和eBPF限制Agent的操作范围。前者控制文件和socket访问，后者限制网络访问，并可根据任务阶段动态调整规则。

不过，这些措施目前只能覆盖部分风险，内核层漏洞仍然难以完全防范。

06. 结语：DSec平台能力 成为Agent规模化训练的关键环节

DSec展示了一套面向大规模Agent训练的基础设施方案。从沙盒创建、环境复用，到rollout调度、状态保存和安全隔离，Agent训练正在形成一套独立的基础设施需求。

随着Agent任务持续变长、交互过程不断增加，执行环境的规模也会进一步扩大。如何让数万个甚至更多沙盒稳定运行，同时控制资源成本和安全风险，将成为Agent训练继续扩展需要解决的问题。

对于DeepSeek的Agent训练而言，模型能力持续提升的同时，承载这些任务的执行平台也需要跟上。DSec提供的这套工程方案，或许正是这一阶段Agent基础设施演进的一个缩影。

本文来自微信公众号“智东西”（ID：zhidxcom），作者：毕伟豪，编辑：李水青，36氪经授权发布。