梁文锋用沙盒开启RSI

文 | 字母AI DeepSeek联合清华大学发表了一篇文章，署名的最后一人是梁文锋。 文章表面上是说DeepSeek训练Agent所使用的沙盒，但是论文第6节越看越不对劲。字里行间写了三个英文字母：RSI。 通过这个沙盒，Agent能创建自己需要的环境，这个环境会再次训练Agent，被训练的更强的Agent会创造更好的环境。 由此形成了一个小型的RSI闭环。 也正是因此，沙盒，或许成为了开启RSI第一场战争的一把钥匙。 那这篇文章到底讲了什么呢？ 这篇论文到底讲了什么 梁文锋署名的这篇新论文，标题叫做《DeepSeek Elastic Compute （DSec）: A Sandbox Infrastructure for Effective Agentic Training at Scale》，9月19日提交到 arXiv，编号2609.22978。作者超过130人，梁文锋排在最后一位。合作方是清华大学。 论文做的事情，一句话就能说完：DeepSeek完整公开了自己用来训练Agent的“沙盒工厂”DSec。 但是要理解DSec，就得先理解“训练Agent”和“训练大模型”的区别。 训练大模型，是喂数据、算梯度，环境就是GPU集群。训练Agent则完全不同，Agent要在环境里写代码、跑编译、开浏览器、装依赖、调工具，然后根据执行结果不断重试，直到任务完成。 但如果把Agent放在电脑里训练，它万一捣鼓点什么出来，那整个环境就毁了。 所以这就需要一个隔离的、有状态的、能跑真实软件的沙盒。 DSec就是这样一个平台。它通过一套统一的Python SDK（libdsec）对外提供四种后端：函数调用（FnCall）、容器（Container）、轻量虚拟机（microVM）、完整虚拟机（Full VM）。 简单来说，DSec就是外卖APP，Agent是骑手，沙盒就相当于是派单。由此类推，FnCall、容器和轻量虚拟机就是外卖站点分发的电动车和保温箱，完整虚拟机是冷链货车。 但这里有个小问题，隔离强度和系统功能两者生来就“不对付”。 越像一台真机，启动越慢、内存开销越大。跑一段短脚本用函数调用，改一个代码仓库用容器，跑安全任务用microVM，而要跑安卓、图形界面这种完整系统，就只能上完整虚拟机。 论文显示，一个生产单元约160个CPU节点、3万核、250TB内存，托管PB级镜像。 一天服务约300万个沙盒，峰值并发超过38万个，创建速度超过每秒5000个。单个训练任务最多能一次性拉起3.2万个沙盒。单节点上，最高能塞进800个 microVM或3200个容器。 DSec有三个核心机制。 第一，把环境拆成“可组合的层”。 过去一个沙盒环境是一整块镜像，改一个工具包就得重建整块镜像，维护成本随组合数暴涨。DSec把基础镜像、工作区、工具包拆成三层独立版本化的只读层（EROFS），启动时用overlayfs拼起来，改哪层只重建哪层。实测比 tar.gz 打包方式快1.76倍，磁盘写入量少5.5倍。 相当于是给骑手配车，以前是坏了其中一个零部件，那么整车都要换。DSec是坏了哪个换哪个。 第二，镜像“按需加载”。镜像存在3FS（DeepSeek 的分布式文件系统）上，元数据预取到本地，数据块只在真正读到时才拉。实测8192个容器的突发部署，按需加载35分钟跑完，而 Docker 冷拉取要60分钟以上，磁盘写入量少了约57%。 老办法是“不管用不用，整仓先搬空”。DSec是“根据外卖单，用到哪件骑手去取哪件”。 第三，内存和CPU的“精打细算”。 用virtio-pmem配合DAX，让多个虚拟机共享同一份页缓存，峰值内存降40.2%；用DAMON加balloon回收冷页，时间积分内存再降21.2%；CPU上把沙盒分成“延迟敏感”和“尽力而为”两类，用core scheduling把SMT干扰从45.2%压到17.3%。 此外，从DeepSeek-V4.1开始，论文还把Agent的rollout从可被抢占的GPU训练Pod里拆出来，独立跑在DSec上，GPU被抢时rollout状态不丢。 说白了就是让骑手们公用同一张地图、同一批货架，车里压仓的冷货随手退回仓库，加急单和普通单分道跑、互不抢道。 藏在第6节的RSI 论文里最容易被忽略一句话，不在摘要，而在第6节的小标题里：Build environments of Agents, by Agents, for Agents。意为由Agent建造、为Agent服务、属于Agent的环境。 这句话等于DeepSeek悄悄交代了一件大事，DeepSeek也实现了部分RSI。 论文第6.1节写到，手工构造Agent RL所需的大量环境已经“不现实”（impractical）。 于是DeepSeek换了个做法，让Agent在训练用的同一套沙盒里，交互式地自己搭环境，再用pack_diff把这次会话打成一张增量快照，直接变成下一批可复用的训练场。 造环境的Agent和被训练的Agent共用DSec这套沙盒基础设施。 Agent铺场地 → 场地训练Agent → 更强的Agent再铺更好的场地。 DeepSeek的RSI由此部分实现闭环。 但是这个闭环仍处于早期。 第6.4节记录了大量Agent作弊事件，比如去平台里翻残留的参考答案，伪造RPC消息直接发给chronus套答案，翻 chronus日志找泄题，甚至覆盖/bin/bash来绕过检查。 被拦住之后，又用XFS_IOC_SWAPEXT这个ioctl把受保护文件的存储块换到另一个文件描述符上，结果把XFS元数据搞坏、逼得文件系统关闭。 有作弊的自然就有闯祸的。一个Agent从根目录递归grep、一路读到/proc/kpagecgroup，触发内核bug直接把内核干崩。 另一个Agent调了yes命令，chronus把它的输出全记下来，几十GB数据堆在存储上。 现在的RSI转不起来，卡的从来不是GPU，是环境供给。 Agent RL每一代都要新任务、新沙盒、新服务依赖，人工造环境才是真瓶颈。 DSec相当于是把这一环部分自动化了，自动生成RSI所需要的环境。 还是用外卖来举例。 一个外卖平台想越跑越快，不能只靠一个骑手重复送同一单。想要骑手变强，就需要接更多不同种类的单，而单越多又反过来把骑手练得更强。 但是想要把这个飞轮转起来，卡的从来不是骑手，是 餐厅够不够多 。没餐厅，骑手再能跑也是空转。 DSec是盖了一个“自动建餐厅”的系统。 以前平台得人工一家家谈商家、装修后厨、写菜单、定考核标准，几百几千家根本谈不过来。 DSec说：“别谈了，让骑手在跑单的同一个后厨里，顺手把店开了。他怎么装的灶台、进的什么货、接的什么水电，系统用pack_diff‘啪’拍一张快照存下来，下一波骑手直接拎包入驻这家店开工，不用重新装修。” 沙盒，成了新的战场 DSec不是孤例。整个行业都在朝着“Agent沙盒”这一个方向发力。 最出名的案例是Kimi K3。 月之暗面7月16日发布K3，2.8万亿参数的 MoE，每个token激活约104B 参数，100万 token上下文，原生视觉，号称“全球首个开源的3T级模型”，SWE-benc