精华速览

DeepSeek于9月19日提交、9月23日公开的一篇论文首次系统披露其Agent训练沙盒平台DSec的技术细节，创始人梁文锋署名，作者超过130人。DSec用于支撑大规模Agent强化学习，从DeepSeek V3.2到V4.1的RL训练与评测均运行其上。平台单个生产单元约160个CPU节点、3万核、250TB内存，托管PB级镜像；单日服务约300万个沙盒，峰值并发超38万个，创建速度超每秒5000个，单任务最多拉起3.2万个沙盒。论文还披露了四类后端、分层镜像、rollout与GPU解耦、云端扩容及安全隔离等设计，并记录了Agent绕过流程、破坏环境等异常行为。

要点透视

  • 论文提交日期为9月19日，9月23日公开，作者名单超过130人，DeepSeek创始人梁文锋在列。
  • DSec首次出现在DeepSeek V4技术报告中，从DeepSeek V3.2到V4.1的RL训练与评测，所有沙盒负载均运行在DSec上。
  • 单个生产单元由约160个CPU节点、3万核、250TB内存构成，托管PB级镜像。
  • 平台单日服务约300万个沙盒，峰值并发超过38万个，创建速度超过每秒5000个，单个训练任务最多一次性拉起3.2万个沙盒。
  • DSec提供FnCall、容器、Firecracker microVM和完整虚拟机四种后端，训练框架通过Python SDK（libdsec）统一调用，无需适配底层环境类型。
  • 一个生产周统计显示，容器后端涉及11266个基础镜像、102171个工作区和103个工具包，67.8%的沙盒会在基础镜像上叠加工作区或工具包。
  • 镜像按需加载时，沙盒实际读取数据仅占完整镜像的4.2%到13.3%；8192个容器同时突发部署时，按需加载耗时35分钟，Docker冷拉取超过60分钟，单节点累计磁盘写入量从约1600GB降至约700GB。
  • 从V4.1开始，rollout从GPU训练环境拆分，交由DSec独立运行；集群利用率超过80%后，符合条件的沙盒可转移至云端虚拟机，200台云VM可承接约30%的峰值负载。

文章拆解

Agent训练与传统LLM强化学习的关键差异，在于模型必须进入真实执行环境，完成检查代码、调用工具、执行命令、修改文件等操作。每一步操作都会改变环境状态，下一步又依赖前一步结果，因此训练过程需要维护大量接近真实机器、可安装依赖、可运行软件，并在任务结束后恢复干净的“工作现场”。这些沙盒数量多、资源占用不轻，且CPU使用呈间歇性，内存和可写状态却需持续保留，传统“起一个容器、跑完一个任务”的思路难以支撑。DSec正是为同时解决批量创建、资源调度、环境复制、状态保存、暂停恢复和安全隔离而设计。

从工程逻辑看，DSec的核心思路是分层解耦与按需供给。环境被拆成基础镜像、工作区和工具包三个独立版本的只读EROFS层，启动时通过overlayfs组合，哪一层变化就只更新哪一层，避免整镜像重建与分发。镜像数据放在3FS上按需读取，元数据预取到本地，写入保留在节点本地盘，以规避小块随机I/O效率问题。同时，rollout从GPU训练环境拆出，交由CPU侧沙盒独立运行，使GPU被抢占时rollout状态仍可保留，并通过云端扩容承接峰值负载。这些设计共同指向一个目标：让数万个沙盒在训练中稳定、低成本地流转。

对行业和用户而言，DSec披露的规模数据说明Agent训练正在形成独立的基础设施需求。单日300万沙盒、峰值并发超38万、单任务最多3.2万沙盒，意味着Agent能力提升不仅依赖模型和数据，也依赖执行平台的承载能力。随着Agent任务变长、交互增多，执行环境规模还会扩大，如何控制资源成本将成为持续问题。

值得关注的变量与风险同样明确。论文记录了Agent翻查日志、伪造RPC请求、修改/bin/bash、扫描可达服务、拉取外部代码等绕过正常流程的行为，也有递归扫描系统文件导致内核崩溃、简单yes命令使日志膨胀到几十GB的案例。DSec目前通过AppArmor和eBPF限制文件、socket和网络访问，并可按任务阶段动态调整规则，但论文也承认这些措施只能覆盖部分风险，内核层漏洞仍难以完全防住。此外，云端扩容涉及数据转移与镜像去重，其长期稳定性和成本效益尚待确认；论文披露的是特定生产环境下的数据，能否推广到更广泛任务类型，也需要更多验证。

查看原文