智东西 作者 毕伟豪 编辑｜李水青 智东西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的RL训练与评测，所有沙盒负载都运行在DSec上，如今公开技术细节，也算是把“焚决”交出来了。 论文显示，DSec平台的规模非常庞大，其中一个生产单元由 约160个CPU节点、3万核、250TB内存构成 ，托管PB级镜像。 能力方面，DSec平台单日服务约 300万个沙盒 ，峰值并发 超过38万个 ，创建速度 超过每秒5000个 ，单个训练任务最多可以 一次性拉起3.2万个沙盒 。 ▲每个任务创建的沙盒数量分布情况 那么问题来了，为什么在Agent训练中需要数量如此庞大的沙盒？而面对复杂的执行环境，DSec又是如何解决规模、调度和资源管理问题的？ 一、Agent RL天然需要巨量沙盒，训练环境成为发展瓶颈 传统LLM训练的强化学习，很多时候可以围绕静态的输入、输出和奖励信号展开，但Agent训练和LLM完全不同，需要真正进入真实环境，实际执行检查代码、调用工具、执行命令、修改文件等任务。模型每执行一步，都可能会触发环境状态的变化，而下一步执行又建立在前面的结果之上。 这意味着，Agent训练过程中，除了模型和数据，研究人员还需要维护一大批“工作现场”，这些环境得足够接近真实机器，可以安装依赖、运行软件等，还要能在一次任务结束后恢复干净状态，交给下一轮rollout继续使用。 问题在于，这些沙盒既多又不轻。 论文中显示，训练过程中一次任务曾同时拉起3.2万个沙盒，而这些沙盒又不会跑满，在Agent执行任务时，沙盒经常处于等待下一步操作的状态，CPU利用率并不高。但CPU闲着，并不意味着资源已经释放，内存和可写状态仍然需要持续保留。 ▲CPU使用是间歇性的，内存和状态会持续被占据 因此，传统的“起一个容器、跑完一个任务”的思路就很难继续撑下去。DSec平台诞生的目的，就是同时解决沙盒的批量创建、资源调度、环境复制、状态保存、暂停恢复和安全隔离。 二、四大环境需求：一套SDK同时管理函数、容器和虚拟机 随着Agent要执行的任务越来越复杂，背后的工作环境也很难再用同一种规格“应付”。 最轻的任务可能只需要一次函数调用，执行代码、返回结果即可；软件工程任务则需要完整的Linux用户态，能装依赖、改代码、跑测试；安全攻防和Computer-use对隔离要求更高；如果要操作一些商业软件，所需的环境甚至得接近一台完整的计算机。 DSec提供四种后端：FnCall、容器、Firecracker microVM和完整虚拟机，分别覆盖从短时函数调用、软件工程，到安全敏感任务和完整OS环境的不同需求。而训练框架则不需要关心底层到底是一个容器还是一台虚拟机，通过Python SDK（libdsec），训练框架无需适配不同的环境类型，就能直接完成沙盒创建、命令执行和结果获取。 ▲DSec的提供四种后端 DSec的四种后端由同一套平台统一调度。训练框架发起请求后，平台先完成身份和权限校验，再根据集群负载选择合适的节点，由节点上的Edge负责创建沙盒。沙盒启动后，Aether和Chronus负责连接平台与沙盒内部的执行过程，镜像数据则由3FS按需提供。 ▲DSec架构 但当这些环境从几种类型扩展到成千上万个实例，新的问题也就随之出现了：如何 快速复制出数量庞大且种类不同的环境。 三、环境越多，复制越难：DeepSeek如何快速部署几万个沙盒 如前文所说，Agent训练的环境不只是数量多，组合也很复杂。 论文统计了一个生产周的数据：容器后端涉及11266个基础镜像、102171个工作区和103个工具包。实际运行时，67.8%的沙盒还会在基础镜像上叠加工作区或工具包。DeepSeek Harness就是其中需要频繁更新的一类组件。 如果把这些组件全部放在一个完整镜像中，任何一层发生变化，都可能需要重新构建和分发整个镜像。环境数量一多，镜像维护和部署的成本也会随之上升。 DSec把基础镜像、工作区和工具包拆成三个独立版本的只读EROFS层，沙盒启动时再通过overlayfs组合。这样一来，哪个组件发生变化，就只更新对应的那一层，不需要重新处理整个镜像。 镜像分发则采用按需加载。论文发现，沙盒运行