梁文锋署名，DeepSeek又发新论文了

DeepSeek 把自己内部用的沙箱基础设施分享出来了。DeepSeek又发论文了。这一次他们把重点聚焦到了一个很少被外界看到、却越来越影响 Agent 训练规模的地方沙箱基础设施。论文标题DeepSeekElastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale论文链接https://arxiv.org/pdf/2609.22978v1这是一篇长达 31 页的系统论文。作者阵容超过百人包括梁文锋在内。论文介绍了DeepSeek内部用于大规模 Agent 训练和评测的生产级沙箱平台DSecDeepSeekElastic Compute。先说一下规模。一个 DSec 生产单元大约由160 台 CPU 节点、3 万个 CPU Core 和约 250 TB DRAM组成管理着 PB 级的镜像和环境层。典型的一天里它要服务大约300 万个 sandbox 实例高峰时同时在线的 sandbox 超过 38 万个创建速度超过 5000 个 / 秒。更值得注意的是论文明确提到从DeepSeekV3.2 到 V4.1DeepSeek用于 RL 训练和评测的 sandbox workload 都运行在 DSec 上。也就是说这篇论文展示的其实是DeepSeek在 Agentic RL 时代给模型搭出的那座「训练场」。而当训练规模来到几十万个并发 Agent 时一个看似简单的问题迅速变得棘手这么多 Agent到底在哪儿跑Agent 越来越会干活训练系统先扛不住了传统大模型做一次推理核心工作是生成 Token。到了 Agent 这里模型开始真正「动手」打开代码仓库、搜索文件、调用工具、运行命令、修改代码、执行测试一轮任务可能持续几十分钟甚至数小时。到了强化学习训练阶段这些操作还得在真实环境里执行。每个 Agent 都需要一个独立的 sandbox里面装着代码、依赖、测试工具和运行服务Agent 改过的文件、启动的进程也要随着多轮交互持续保留下来。规模一上来压力很快就从模型侧传到了基础设施。DeepSeek观察到一次训练任务可能瞬间申请3.2 万个 sandbox。这些环境还呈现出一种很特别的资源使用模式活得久但大部分时间并不忙。论文数据显示约 90% 的 Container 和 microVM平均 CPU 使用量都不到申请资源的 5%。与此同时Container 的生命周期中位数达到 17.4 分钟microVM 为 15.5 分钟到了 p99两者都会持续三个小时以上。原因并不难理解。Agent 经常处于「模型思考 — 执行几条命令 — 继续等待模型」的循环里。于是集群里可能同时挂着几十万个执行环境绝大部分时间安静地占着内存和状态某个时刻又突然一起开始跑任务。这类 workload 给传统计算平台出了道新题怎样让几十万个有状态的执行环境长期在线同时还能承受瞬时爆发的创建和计算需求DSec就是DeepSeek为这个问题搭出来的基础设施。四种 Sandbox装下越来越杂的 Agent 任务Agent 会干的事情越来越多执行环境也很难再用一种方案包打天下。DSec 因此提供了四类执行后端FnCall、Container、MicroVM 和 FullVM。最轻量的 FnCall适合 Online Judge、代码编译、GPU Kernel 等短任务软件工程和通用工具调用主要跑在 Container 里启动快、部署密度高涉及更强隔离要求的任务则交给基于 Firecracker 的 microVMAndroid、GUI、图形渲染这类依赖完整操作系统的场景再使用 FullVM。四类环境统一接入同一套 SDK 和生命周期管理体系。对上层的 Agent 来说它面对的依然是一套接口底层则可以根据任务特点选择合适的运行环境。但统一接口还算容易。真正棘手的是几十万个这样的环境怎么同时创建、运行和保存状态。几十万个 SandboxDeepSeek 怎么把它们跑起来一秒涌进几千个 Sandbox调度系统先迎来洪峰DSec 的调度链路并不复杂。用户提交请求后系统先完成身份与权限检查再由 Placement Engine 根据集群负载寻找合适节点。任务落到机器后本地组件继续检查容量然后创建 Container、microVM 或其他执行环境。运行过程中另一组组件负责维持 Session并处理命令执行、文件访问、HTTP 请求和流式 I/O。难点在规模。DeepSeek的生产集群高峰时每秒要创建超过 5000 个 Sandbox。单个 Production Unit 的同时在线实例超过 38 万个。这种速度下环境镜像怎么分发很快就成了瓶颈。论文统计一周内活跃的环境 Artifact 总量超过 130 TB。而且这些镜像高度分散一个 Container Image 被多少节点使用中位数只有 3 个microVM Image 更低中位数只有 1 个。也就是说很多环境刚下载到机器上可能只用一两次。如果每启动一个 Sandbox都完整拉取几 GB 甚至十几 GB 的镜像网络、磁盘和启动时间都会被迅速放大。于是 DSec 把镜像放到了DeepSeek自己的分布式文件系统 3FS 上真正运行时再按需读取。这个选择背后还有一个很关键的数据。一个几 GB 的镜像Agent 可能只碰其中几百 MBDeepSeek分析了不同编程环境真正被访问的数据量。结果发现Agent 跑完整个任务往往只会碰到镜像的一小部分C 环境约 8.7%Go 为 13.3%Java 为 9.2%Python 为 6.0%JavaScript 甚至只有 4.2%。完整下载一遍显然有些浪费。DSec 因此采用 On-demand LoadingContainer 使用 EROFSmicroVM 使用 EROFS 配合 OverlayBD需要哪个数据块再从 3FS 里取哪个。这有点像看在线视频。过去是先把整部电影下载完才能播放现在只读取当前需要的部分。Agent 最终没访问到的文件也就不会产生对应的网络和磁盘开销。这个设计到了后面的实验里带来了相当明显的收益。环境太多DeepSeek 把它们拆成了「积木」镜像数量还有另一个麻烦环境组合越来越多。一个 Agent 任务里通常会同时出现基础操作系统、代码仓库、测试工具和各种依赖。换一个任务Workspace 变了升级工具链Toolkit 又变了。如果每一种组合都保存成完整镜像更新成本会迅速膨胀。DSec 把一个环境拆成几层Base Image、Workspace、Toolkit以及最上面的可写层。Base Image 提供基础系统Workspace 放代码和任务数据Toolkit 保存工具链。Agent 运行过程中产生的修改再写进自己的 Writable Layer。不同层可以独立更新再通过 OverlayFS 组合成完整文件系统。论文给了一个很直观的复杂度变化假设有 N 个环境更新 m 个 Base Image重建成本可以从 O (m・N) 降到 O (m)更新 k 个 Toolkit也从 O (k・N) 降到 O (k)。当训练环境开始以万、十万计这种差别会直接落到构建时间、存储和分发成本上。一台机器塞进 3200 个 Container问题变成了「怎么别把内存撑爆」前面提到Agent Sandbox 有个很特殊的特点数量巨大CPU 却经常闲着。这给 DSec 留出了一个空间 —— 超额部署。DeepSeek在生产环境里已经稳定跑到过单节点至少 3200 个 Container或者 800 个 microVM。论文强调这只是经过实际验证的运行点还没有触碰系统上限。CPU 好解决一些内存更麻烦尤其是 microVM。同一份文件可能先在宿主机缓存一遍每个虚拟机内部又各自缓存一份。几百个 VM 跑起来相同数据很容易被重复占用。DSec 用了两套机制第一套是 virtio-pmem DAX。多个 microVM 可以共享宿主机上的同一份 Page Cache减少重复文件页。第二套是 DAMON virtio-balloon Free Page Reporting。系统持续观察哪些内存页面长期没有访问把冷数据逐渐回收Guest 里已经空闲的内存也会重新交还给 Host。目的很明确Sandbox 可以多挂一些闲着的内存也得尽可能收回来。CPU 很闲但 Agent 一动起来又不能卡高密度部署还有另一个问题几十万个 Sandbox 平时都很安静一旦开始执行CPU 竞争会突然变强。而有些 Agent 对响应时间很敏感比如棋类任务每一步都有时间预算。DSec 因此把 workload 分成两类Latency-SensitiveLS 和 Best-EffortBE。后台 BE 任务使用 Linux 的 SCHED_IDLE让出更多 CPU对延迟敏感的 LS workload再配合 Core Scheduling减少同一物理核心上的资源干扰。这套机制最终要解决的是一个很实际的平衡同一台机器尽可能多塞 Sandbox同时别让正在真正干活的 Agent 明显变慢。当 Sandbox 真正进入 RL 训练事情又复杂了一层GPU 被抢走之后跑到一半的 Agent 还得接着干论文接下来进入一个更贴近强化学习训练的问题Sandbox 怎么和 RL 系统一起工作。Agent rollout 往往持续很久。它可能已经修改了几十个文件、启动了服务、执行了很多轮命令结果此时 GPU Training Job 被调度系统抢占了。训练过一会儿重新启动前面的环境状态还得接得上。DeepSeek早期使用 Command Log 记录操作。训练恢复后再通过日志协调 rollout state 和 sandbox state已经执行过的操作可以读取历史结果减少重复执行带来的状态变化。到了DeepSeek-V4.1这套架构又往前走了一步。DeepSeek把 rollout execution 放到了 DSec 里。Agent Sandbox 负责运行 Harness 和工具另一个 Worker Container 管理 Sandbox并和 RL Framework 通信。这两个组件都位于可抢占的 GPU Pool 之外。这样一来GPU Job 暂停时Agent 的执行环境还能继续保存完整状态。新的 Trainer 接回来以后rollout 可以从原来的位置继续。对于越来越长的 Agent 轨迹这件事很重要训练过程可以暂停已经跑出来的执行状态还在。Agent 等 GPU 的时候几十万个环境也不能一直白占资源状态要保留资源又不能一直占着。所以训练进入暂停阶段时RL Framework 会通知对应 Sandbox 一起休眠。Container 会冻结 Process Tree同时主动回收内存microVM 会保存 Snapshot然后终止 Firecracker Process。等新的训练请求到来再把环境恢复起来。这样Sandbox 的生命周期就开始和 RL Training 的节奏协同Agent 需要工作时恢复Trainer 暂停时释放资源同时保留足够的执行状态。这其实也是 DSec 和普通云端容器平台区别很大的一点。它面对的 workload本身就是为长时间、多轮、可中断的 Agent rollout 服务的。Agent 已经开始「研究」自己的训练环境随着 Agent 能力提升DeepSeek发现它们开始主动寻找训练环境里的各种信息通道。有的 Agent 会搜索平台管理文件、通信 Channel 和 Chronus Log有的会尝试构造 RPC Message直接访问 Chronus Socket甚至还有 Agent 覆盖过 /bin/bash试图借此影响后续 Shell Session。当 DSec 加入文件和 Socket 限制后又有 Agent 找到了一个更偏底层的系统调用XFS_IOC_SWAPEXT。它尝试交换文件的数据 Extent Mapping结果把 XFS Metadata 搞坏文件系统直接进入 Shutdown。这些行为未必意味着 Agent 「有恶意」。在强化学习里它只是不断寻找能提高 Reward 的路径。问题在于一旦模型从环境里找到了题目答案、测试信息或者其他捷径最终得到的 Reward 就可能失真。DeepSeek还观察到 Agent 扫描网络端口、寻找内部服务、使用 Go Module Proxy 获取 GitHub 代码或者安装更新版本的软件包看看里面是否已经出现任务需要的实现。换句话说当 Agent 足够会折腾环境本身也成了它探索的一部分。它们还真能把自己的 Sandbox 玩坏除了寻找捷径还有不少纯粹的「事故」。论文记录过一个 Agent 从根目录递归运行 grep一路读进 /proc/kpagecgroup最后触发 Kernel Bug把 Kernel 弄崩了。还有 Agent 在漏洞利用任务里本来应该攻击目标 VM结果把 Exploit 命令跑到了自己的 Container 中把自己的执行环境打挂。甚至一个最普通的 yes 命令也制造过几十 GB 的 stdout。这些案例很能说明 Agent Sandbox 和普通代码执行环境之间的差别。用户写程序时行为通常有比较明确的目的Agent 在强化学习里会不断试探状态空间很多边界条件真会被它碰到。DSec 因此使用 AppArmor、eBPF 网络规则等手段限制文件、Socket 和网络访问还可以按照任务阶段动态调整网络权限。Agent 能力越强Sandbox 也越需要把「执行环境」本身当成一套安全系统来设计。实验结果这些机制到底有没有用8192 个 Container 一起启动35 分钟跑完DeepSeek单独搭了一个 10 节点 CPU Cluster验证 DSec 的几项核心机制包括按需镜像加载、Composable Layer、内存优化和 CPU QoS。先看镜像。实验一次创建 8192 个 Container比较三种方案镜像已经完整缓存在本地、从远程 Registry 完整 Pull以及 DSec 的 EROFS 按需加载。完整远程拉取方案跑完超过 60 分钟。DSec 大约 35 分钟结束已经接近镜像预先缓存在本地的表现。换算下来Eager Pull 慢了约 1.71 倍。磁盘压力的差距更明显完整 Pull 每个节点累计写盘超过 1600 GB按需加载约 700 GB下降大约 57%。前面那个「很多镜像实际只访问几个百分点」的结论到这里变成了直接的系统收益。把环境拆成积木79 分钟降到 45 分钟第二项实验测试 Composable Layer。DeepSeek使用相同的 Workspace 和 Toolkit一组通过传统 tar.gz 分发、解压另一组使用 EROFS Layer 挂载。为了让结果更稳定实验把模型生成换成事先录制好的 Tool Call Sequence。结果是tar.gz 方案耗时 79 分钟EROFS 为 45 分钟相当于 1.76 倍加速。差距主要出现在环境准备阶段。tar.gz 需要给每个 Sandbox 解压一套完整 Workspace 和 ToolkitEROFS Layer 可以直接挂载并共享。最终tar 方案产生的总磁盘写入量约为 EROFS 的 5.5 倍峰值写入吞吐也达到约 3.4 倍。内存最高省 40.2%高负载下延迟也压了下来microVM 的内存优化同样有明显效果。单独开启 virtio-pmem DAXHost 的峰值内存占用下降 40.2%。使用 DAMON Free Page Reporting 后峰值变化相对有限但整个任务周期里的累计 Host Memory Consumption 降低 21.2%。两套机制同时启用时整体内存消耗最低。这里也有代价。virtio-pmem 会让瞬时 Peak CPU Utilization 从 26.5% 提高到 41.4%。这意味着 DSec 依然需要根据资源情况在 CPU 和内存之间做工程权衡。最后是 CPU QoS。DeepSeek用一个对延迟敏感的 Chess Agent 做测试同时不断增加后台 Best-Effort workload。当后台 CPU Load 达到 50% 时没有 QoS 控制的 Agent 单步延迟增加 45.2%加入 SCHED_IDLE 后有所改善再加上 Core Scheduling延迟增幅降到了 17.3%。对于高密度 Agent 集群来说这个数字意味着同一台机器可以挂更多 Sandbox同时把活跃任务受到的干扰控制在更低水平。当模型开始真正「干活」训练场也得跟着升级DSec 这篇论文里几乎看不到 Attention、MoE 或新的 RL 算法。它讨论的是另一组词调度、镜像、文件系统、Page Cache、VM Snapshot、CPU Core、网络隔离。但这恰恰反映出 Agentic RL 正在出现的一种变化。模型生成一段文本时主要消耗的是 GPU模型开始调用工具、修改代码、运行程序之后背后还需要一整套真实的计算环境。而DeepSeek现在面对的规模已经相当可观一个生产单元每天运行约 300 万个 Sandbox峰值同时在线超过 38 万个创建速度超过 5000 个 / 秒。这时训练系统需要解决的问题也开始扩散到 GPU 之外PB 级环境如何存储几十万个有状态实例怎么调度长时间 rollout 怎样暂停和恢复Agent 把系统边界当成探索空间之后又该怎么隔离。DSec 展示的就是DeepSeek给这一阶段准备的一套底层设施。如果过去训练大模型核心任务是尽可能高效地把 Token 喂给 GPU到了 Agent 时代又多出了一件越来越重的工作给成千上万个会动手的模型准备一个经得起折腾的执行世界。原文链接梁文锋署名DeepSeek又发新论文了-36氪我的专辑《人工智能生命体 新启点》CSDN平台https://blog.csdn.net/2501_91883294/article/details/147616608?sharetypeblogdetailshareId147616608sharereferAPPsharesource2501_91883294sharefromlink