梁文锋署名，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强化学习天然需要海量沙盒

训练环境成为发展瓶颈

传统的LLM训练中的强化学习，往往围绕静态的输入、输出和奖励信号进行，但Agent训练与LLM截然不同，它需要真正进入真实环境，实际执行检查代码、调用工具、执行命令、修改文件等操作。模型每执行一步，都可能引发环境状态的变化，而下一步执行又依赖于前一步的结果。

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

问题在于，这些沙盒数量众多且资源占用不轻。

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

▲CPU使用是间歇性的，内存和状态会持续被占据

因此，传统的“启动一个容器、运行完一个任务”的思路难以继续支撑。DSec平台诞生的目的，就是同时解决沙盒的批量创建、资源调度、环境复制、状态保存、暂停恢复和安全隔离等问题。

02.

四大环境需求：一套SDK统一管理

函数、容器和虚拟机

随着Agent要执行的任务越来越复杂，其背后的工作环境也难以再用单一规格来应对。

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

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

▲DSec提供四种后端

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

▲DSec架构

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

03.

环境越多，复制越难：

DeepSeek如何快速部署数万个沙盒

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

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

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

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

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

▲DSec将环境拆分为可组合层

实际效果显示，当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的CPU调度、内存回收、分层镜像和按需加载机制

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