DeepSeek 在预印本平台 arXiv 发布论文《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》，首次系统披露其内部用于大规模智能体训练与评测的生产级沙箱平台 DSec。
论文提交于 9 月 19 日，作者超过 130 人，DeepSeek 创始人梁文锋位列最后一位。
DSec 要解决的核心问题是智能体训练对环境的需求与传统大模型训练完全不同。
传统 LLM 强化学习多围绕静态输入输出展开，而智能体训练要求模型真正进入可执行环境，完成读取代码库、调用工具、运行命令、修改文件等操作，每一步都可能改变环境状态，下一轮 rollout 又需要干净的环境重新开始。
这意味着训练过程中需要批量创建、调度和回收大量隔离的执行环境。
DSec 将函数调用、容器、微型虚拟机和完整虚拟机四种沙箱后端接入同一套平台，通过统一的 Python SDK 供训练框架调用。
不同任务对隔离强度的要求差异很大，刷题类任务只需无状态的函数调用环境，软件工程任务需要完整的 Linux 用户态，安全敏感场景则必须上升到虚拟机级别。
四种后端的隔离强度和资源开销逐级递增，但训练框架侧看到的是相同的接口和调用方式。
规模方面，论文披露单个生产级 DSec 单元约由 160 个节点组成，拥有约 3 万个 CPU 核心和 250TB 内存，每天服务约 300 万个沙盒，峰值并发超过 38 万个，创建速率超过每秒 5000 个，单个训练任务最多可一次性拉起 3.2 万个沙盒。
一个值得注意的资源特征是，沙盒的 CPU 使用呈间歇性，智能体执行任务时经常处于等待下一步操作的状态，但内存和可写状态需要持续保留。
论文指出约 90% 的沙盒实际使用的 CPU 资源不超过其申请量的 5%。DSec 通过资源超分和高密度部署来应对这一矛盾，单个节点可同时承载 3200 个容器或 800 个微型虚拟机。
环境构建是规模化运行的另一个瓶颈。论文统计了一个生产周的数据，容器后端累计涉及 11266 个基础镜像、102171 个工作区和 103 个工具包，67.8% 的沙盒需要在基础镜像之上叠加工作区或工具包。
如果每次都将全部组件打包为完整镜像，任何一层变化都意味着重新构建和分发，成本难以控制。DSec 的做法是将基础镜像、工作区和工具包分层管理，按需组合。
安全性是论文中专门讨论的问题。DeepSeek 在训练中发现，智能体可能不按预期方式解决问题，而是寻找意外的信息通道获取答案，另一些行为则会直接破坏运行环境。
论文指出，没有单一机制能防止所有智能体的不当行为和系统故障，隔离与行为约束需要作为训练基础设施的组成部分来设计。
DSec 还将智能体有状态的任务执行与可抢占的 GPU 训练解耦，GPU 训练被暂停或重新调度时，智能体已执行到一半的任务状态仍可保留，待资源恢复后继续执行。
匿名用户
