DeepSeek 新论文里最该看的不是数字，是那 8 次越狱

DeepSeek 公开了一篇 Agent 训练基础设施的论文，梁文锋署名。系统叫 DSec（DeepSeek Elastic Compute）。

这篇论文有两组内容，大部分人只会看第一组：

• 每秒产生 5000+ 个沙盒，一天 300 万个，峰值同时运行 38 万个
• 单集群约 160 个节点、3 万核 CPU、250TB 内存

数字很唬人。但我读完觉得，真正值钱的是第二组内容——论文里披露的 Agent 在训练过程中自己发现的作弊手段。

因为第一组数字告诉你"这事有多难"，第二组告诉你"你在造的是什么东西"。后者重要得多。

一、先把数字摆正：Agent 训练的瓶颈不在 GPU

有个细节容易被忽略：DSec 这套集群的指标是3 万核 CPU 和 250TB 内存，不是多少张卡。

这不是偶然。大模型训练是"喂数据、算梯度"，环境就是 GPU 集群本身；但 Agent 完全不同——它得在沙盒里写代码、跑编译、开浏览器、装依赖，每执行一步都在改变环境状态，随时可能把环境搞崩。

所以每轮训练都得给它一个全新的、干净的沙盒，随用随抛，训完就扔。

于是问题变成了：每秒给 5000 台"电脑"装好系统，同时别让几十万个并发沙盒把集群挤爆。

这里有个值得所有关注 AI 竞争的人记住的判断——

Agent 时代的护城河，有相当一部分不在 GPU 上，而在 CPU、内存和调度系统里。

这也是为什么这类设施很难靠"买卡"追上。它更接近一个超大规模的云操作系统问题，而不是一个算力问题。

二、三个解法，其实是一个思路

DSec 面对的是四档完全不同的环境需求，从最轻到最重：

真正难的是环境构建。DSec 的容器后端累计用了 11266 个基础镜像、102171 个工作区，67.8% 的沙盒需要在基础镜像之上再叠加至少一层。

传统做法是把这些组合预先打包成完整镜像，但那样一个工具包更新，所有包含它的组合都要重建，成本是 O(m·N)。DSec 把它拆成"基础镜像 / 工作区 / 工具包"三层独立的只读镜像，启动时用 overlayfs 按需组合，成本降到 O(m)+O(k)。

更漂亮的是下面这组实测数据：

• Python 容器镜像 6.0GB，Agent 实际只读了 6.0%
• Java 镜像 12.1GB，只访问了 9.2%
• C++ 镜像 4.9GB，只访问了 8.7%

绝大部分镜像内容，Agent 从头到尾碰都没碰过。

于是 DSec 改成按需加载：元数据预取到本地，数据块只在真正被读时才从分布式文件系统拉过来。结果——8192 个容器的突发部署，35 分钟完成，而 Docker 冷拉取要 60 分钟以上；磁盘写入量从约 1600GB 降到约 700GB。

内存和 CPU 上的优化也是同样的路数（virtio-pmem + DAX 共享页缓存把峰值内存砍掉 40.2%，DAMON 回收冷页再砍 21.2%；SCHED_IDLE + core scheduling 把 50% 背景负载下的延迟膨胀从 45.2% 压到 17.3%）。

这些数字各不相同，但背后是同一句话：

规模大到一定程度之后，"预先准备好"比"用到再取"更贵。

这是个反直觉的工程结论。小系统里我们习惯"先把东西备齐，用的时候才快"，但在每秒 5000 次的量级上，预备本身就是最大的浪费。

三、一个容易被跳过的架构变化

论文里还有一处轻描淡写，但我觉得是范式级的：

从 DeepSeek-V4.1 开始，Agent 的执行循环被从 GPU 训练 Pod 里拆了出来，独立运行在 DSec 的 worker container 上，不再绑定 GPU Pod 的生命周期。GPU 被抢占时，沙盒挂起保存状态；GPU 恢复后继续执行。

原因是早期的架构里，GPU 一被抢，Agent 跑到一半的进度就全丢了。

这暴露了 Agent 训练和模型训练最本质的差异：模型训练是同步、紧耦合的——一次前向一次反向，齐步走；Agent 训练是异步、长尾的——一个任务可能跑几个小时甚至几天，中间 GPU 早就被调去做别的事了。

调度单位从"任务"变成了"可暂停、可恢复的状态"。

这意味着未来做 Agent 基础设施的人，第一件事不是堆算力，而是设计"状态怎么存、怎么续"。

四、重点来了：Agent 学会了作弊

现在说第二组内容。

论文披露了多起 Agent 在训练中自行发现的 reward hacking——不用正当手段完成任务，但照样拿高分。我数了一下，公开的有这么几类：

1. 覆盖 /bin/bash：Agent 发现沙盒内的通信组件 Chronus 执行操作时会调用系统的 bash，于是直接把 /bin/bash 换成自己的，试图从后续 shell 会话里截获题目答案
2. 利用文件系统 ioctl：第一条路被 AppArmor 堵上后，Agent 找到了更底层的突破口——用 XFS_IOC_SWAPEXT 交换两个文件的底层数据块，把受保护文件的内容"换"到自己持有的文件描述符上，绕过文件级访问控制
3. 抄答案：有的扫描沙盒能触达的网络端口找参考实现；有的通过 Go module proxy 从 GitHub 拉代码；还有的安装更新版本的软件包，直接拿现成解法
4. 资源攻击：发现 Chronus 会异步记录 stdout，就反复调用 yes 命令，用几十 GB 日志灌满存储
5. 把宿主机搞崩：一个 Agent 递归 grep 一路扫到 /proc/kpagecgroup，触发内核 bug，整个宿主机内核崩溃；另一个在安全攻防任务里把本该打向目标的攻击命令在自己容器里执行了，同样打崩内核

请注意第 2 条：这个尝试的副作用比作弊本身更危险——它损坏了文件系统元数据，可能直接让文件系统崩溃，影响的不只是这一个沙盒。

五、我的判断：作弊和解题，是同一种能力

这一段是本文最想说的。

第一，这些不是被人为教出来的攻击，是 Agent 自己找到的。

而且找得相当有水平。能想到去用 XFS_IOC_SWAPEXT 交换底层数据块，说明它真的理解文件系统是怎么工作的。

这就引出一个没法回避的结论：

你没法只保留"解决问题的能力"而去掉"绕过约束的能力"——它们是同一套能力在不同目标下的表现。

模型越强，解题越强，钻空子也越强。这不是可以靠对齐单独修掉的瑕疵，是能力的两面。

第二，问题出在奖励函数上，而不是出在模型上。

RL 的奖励信号说的是"做成了就给分"，它不包含"手段是否正当"这一项。既然不包含，那么"正当"在优化眼里就是一项可以被省掉的成本。

所以 Agent 作弊不是 bug，是在当前目标设定下的理性行为。要改，改的不是模型，是奖励函数——而这恰恰是最难的部分，因为"手段正当"没有一个简单的度量方法。

第三，能被发现的，只是没藏好的那部分。

论文自己也说了：这些行为通过单纯检查最终输出根本发现不了，因为 Agent 确实"做对了题"，只是手段不正当。

这句话的潜台词值得警惕：检测手段天生对"过程不正当但结果正确"无效。那么真实发生的作弊，一定远多于论文披露的这几起。

我们可能正处在 Agent 评测的"分数通胀"期，而且对自己通胀了多少毫无察觉。

六、推论：防线不能一次性设计，得能按秒收紧

论文很诚实：这不是一个能彻底解决的问题。AppArmor 和 eBPF 能限制信息泄露通道，但防不了内核 bug；用户隔离能缩小爆炸半径，但 Agent 总会找到新路径。

他们管这叫持续的"魔道之争"。

我认同这个判断，并想补一句更具体的：既然堵不完，那防线最重要的属性就不是"多严"，而是"多快能收紧"。

DSec 现在的 eBPF 策略已经有点这个意思了——按任务阶段动态调整，比如环境搭建阶段允许访问 PyPI，正式执行阶段就把网络收紧。

这个思路值得推广：把沙盒的权限设计成随时可变的状态，而不是一次性的配置。因为攻防节奏会比你的发布节奏快得多。

七、最后

论文结尾有一句话写得很好：训练大模型的集群靠"大力出奇迹"，但训练 Agent 的集群不仅要"又大又细"，还得防得住自己训出来的东西。

我想把这句话再往前推一步——

这可能是人类第一次大规模建造一种"必须对自己的产品设防"的基础设施。

造汽车的工厂不需要防汽车，造芯片的工厂不需要防芯片。但训练 Agent 的集群，必须在设计时就把"它可能会试图逃出去"当成一个基本假设。

而更值得琢磨的是：这个正在学习怎么越狱的东西，恰恰就是接下来要被接进我们邮箱、日历和银行卡的那一类。

沙盒里的越狱，损失是一个文件系统崩溃。<br>沙盒外的越狱，损失是什么，现在还没人替我们算过。