DeepSeek发布DSec：面向大规模Agent训练的沙盒基础设施
近期，DeepSeek联合清华大学发布了一项面向大规模智能体训练的基础设施技术成果，相关技术报告已公开至arXiv，由超130人的团队完成，梁文锋也是作者之一。与此同时，DeepSeek在技术社区发布长文，首次系统拆解了支撑DeepSeek-V4全流程训练、评测与数据预处理的沙盒核心平台——DeepSeek弹性计算（简称DSec）。
要训练可靠的智能体大模型，需要让模型在真实环境中反复试错：阅读代码、修改文件、安装依赖、执行测试、运行服务，每一步操作都会改变运行环境，因此沙盒必须在多轮交互中持续保留完整的运行状态。这类负载有着鲜明的特性：沙盒创建请求呈脉冲式突发；启动后CPU大多处于闲置状态，但内存需要持续驻留以保存环境；Agent执行环境种类繁多，基础镜像复用率低；任务执行周期长，训练过程还可能因资源抢占中断。这些特性直接决定了DSec的整体设计方向。
多后端统一接入，适配全场景任务需求
不同的Agent任务对隔离强度、操作系统功能和执行开销的要求差异明显，DSec为此提供了四种可灵活选择的执行后端，通过统一的Python SDK（libdsec）完成接入，开发者可根据任务类型按需调配。其中FnCall模式会复用预先创建的容器，适合处理在线评测等短周期任务；Container模式凭借较快的启动速度和较高的部署密度，可覆盖通用软件工程和工具调用类场景；MicroVM则提供更强的隔离边界，适用于对安全性要求较高的任务；Full VM则提供完整的操作系统环境，支持图形界面、图形渲染以及Android等特殊应用运行。
分层可组合的环境架构
Agent训练需要海量多样化的运行环境，如何高效批量构建和更新环境是首要难题。根据2026年某周的生产数据，容器后端仅基础镜像就用到了11266个，工作区102171个，还有数百个工具包。按照传统镜像构建方式，任意一部分的更新或替换，都会触发大量镜像的全量重建，成本极高。
为此，DSec将沙盒环境拆分为三个独立模块：基础镜像（base image），包含操作系统与基础软件；工作区（workspace），存放任务所需的代码仓库和依赖包；工具包（toolkit），比如DeepSeek Harness这类专用工具。三个模块的更新节奏各不相同，可独立进行版本管理，在运行时再通过OverlayFS按需组合。
DSec采用EROFS格式存储镜像、工作区和工具包，该格式支持元数据与数据分离，同时支持跨镜像去重。创建沙盒时，只需通过OverlayFS将各EROFS镜像层按需组合即可。当基础软件、任务代码或工具包需要更新时，仅需重建发生变化的镜像层，避免了无关内容的重复构建，大幅降低了环境更新的成本。
镜像按需加载优化IO开销
通过对生产环境镜像数据的分析，团队发现沙盒运行时实际访问的数据量仅占镜像总大小的4.2%到13.3%，如果提前将完整镜像拉取到本地，绝大多数数据都不会被实际使用，造成了大量的存储和网络浪费。
因此DSec选择将全部镜像数据存储在3FS分布式文件系统中，仅将所需镜像的元数据拉取到本地，利用EROFS格式的特性，在实际访问数据时才按需读取，将I/O开销缩减至与实际使用数据量匹配的水平。
在一次集中创建8192个容器的对比实验中，与完整镜像拉取方案相比，按需加载方案将任务完成时间从60多分钟缩短至约35分钟，加速比约为1.71，磁盘写入量减少约57%。在另一项工作区供给测试中，将逐个沙盒解压tar.gz文件的方式改为直接挂载EROFS层后，任务完成时间从79分钟缩短至45分钟，大幅提升了环境创建效率。
高密度资源管理提升部署效率
Agent训练的沙盒大多处于等待模型生成下一步动作的状态，团队的观测数据显示，约90%的沙盒平均CPU用量不超过其申请量的5%，CPU长期闲置，但为了保存文件、进程等环境状态，内存需要持续驻留。这一特性为极高的资源超卖率提供了空间，实际生产环境中超卖率超过了50倍。
为实现资源的高密度部署，DSec通过virtio-pmem与DAX技术，让同一宿主机上的MicroVM共享一份宿主页缓存，实验显示单独启用该机制可使宿主机峰值内存用量较基线下降40.2%。同时，团队还引入了内存回收机制，结合DAMON和balloon空闲页报告，可使按时间累计的宿主机内存消耗较基线下降21.2%。两种机制结合使用时，宿主机的内存消耗达到最低水平。
在高密度部署的场景下，DSec还会优先保障对响应时间要求较高的任务，让时延要求宽松的任务利用空闲CPU资源运行，并通过核心调度减少同一物理核心上超线程的干扰。实验数据显示，通过优化CPU调度，当同机运行的其他任务占用节点50%的CPU容量时，时延敏感任务相对于无干扰基线的时延增幅从45.2%降至17.3%，大幅降低了同机负载的干扰影响。
轨迹执行与GPU训练解耦
在强化学习训练流程中，Agent通常需要与沙盒环境进行多轮交互才能完成轨迹执行（rollout）。在早期的训练架构中，Agent执行循环与GPU训练任务运行在同一个Pod容器中，一旦训练任务被抢占打断，虽然环境沙盒依然存在，但负责推进交互的Agent执行循环会直接终止。恢复训练时，系统需要重放命令日志，将训练框架保存的进度与沙盒内的实际执行状态重新衔接，这套恢复逻辑极为复杂，也增加了多个组件之间的协调成本。
从DeepSeek-V4.1版本开始，团队将这部分执行逻辑迁移至DSec沙盒中，并拆分为Agent沙盒和工作容器协同完成：Agent沙盒运行Agent框架和工具包，工作容器负责管理沙盒、推进交互流程。两者都部署在可被抢占的GPU资源池之外，共同保存执行进度和环境状态。因此当GPU训练任务被抢占时，Agent的执行状态可以完整保留，训练恢复后，Agent即可从中断位置继续执行，大幅简化了恢复流程，降低了组件协调成本。
自动化环境构建：用Agent构建运行Agent的环境
大规模的Agent强化学习训练和评测需要高度多样化的运行环境，包括二进制依赖、代码仓库、Harness工具包、评测脚本等一系列用于生成Agent产物并衡量其正确性的组件。面对这一复杂需求，使用Agent进行自动化环境构建是一种高效且可规模化的方案。
团队注意到，用于构建环境的Agent本身就运行在其构建的环境中，因此与其为Agent训练搭建一套平台，再为环境构建搭建另一套平台，不如将两者整合在同一个“运行Agent的平台”也就是DSec之上。这样不仅大幅简化了系统架构，还能保证Agent的构建环境和运行时环境完全一致，避免了环境不一致带来的问题。
DSec为环境构建引入了pack_diff打包机制，Agent可以指挥平台对沙盒创建增量快照，以便在未来将其恢复为全新的沙盒。通过这种方式，团队可以轻松保存沙盒的运行状态，甚至可以将Agent执行的每一轮交互都转化为可复用的沙箱环境。这种增量快照还可用于轨迹分叉：在第k步保存快照后，可从同一状态恢复出多个沙盒分别继续探索，各分支共享只读层，仅记录各自的变更内容，避免反复执行分叉前的步骤，大幅提升了探索效率。MicroVM支持保存和恢复内存及进程状态的完整快照，而容器侧目前主要支持磁盘级快照。
面向Agent的安全边界建设
随着Agent智能体能力的不断增强，训练环境的安全边界也需要持续完善。在实际生产环境中，团队观察到Agent会尝试读取残留答案、伪造RPC请求、覆盖/bin/bash以注入命令，甚至尝试通过XFS_IOC_SWAPEXT绕过访问控制，这些行为会影响训练和评测结果，甚至破坏整个运行环境。
只要环境中存在获取奖励的捷径，模型就可能利用这些捷径，因此DSec将细粒度访问控制作为基础功能之一：通过AppArmor约束文件读写和套接字访问，即使智能体以管理员身份运行，这些限制依然生效；通过eBPF为每个沙盒配置网络访问白名单，限制其能够连接的地址、端口和协议。
不过这些措施只能缓解部分安全问题，对于触发内核缺陷等破坏性行为，目前仍缺乏通用的防御机制。可以预见，随着模型能力的提升，我们与Agent之间的攻防对抗将会持续进行，系统的安全机制也会随之不断迭代完善。
生产落地与性能数据
DSec采用分片的形式实现横向扩展，每个扩展分片约包含160台服务器，提供约3万个CPU核心和250TB内存。单个分片每天可服务约300万个沙盒，峰值并发超过38万个，每秒可创建超过5000个沙盒。生产环境部署了多个这样的分片，可支持数百万个沙盒同时运行。
从DeepSeek-V3.2到DeepSeek-V4.1版本，DSec承载了Agent训练、评测与数据预处理中的全部沙盒负载。相关技术报告《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》已公开至arXiv，团队希望通过该报告分享支撑大规模Agent沙盒运行的工程实践经验。
结语
我们相信，Agent智能体的能力还有着无限的想象空间。接下来，团队计划将Agent运行环境的数量和种类扩充至数百上千倍，将这些任务培养出的能力回馈至开放模型生态。这需要更多样的运行环境、更可靠的基础设施，也需要更多开发伙伴的加入。欢迎各位开发者加入我们，一同搭建面向Agent的弹性计算平台，共同建设下一代Agent基础模型。
