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