DSec 解剖：agent 训练的瓶颈从 GPU 挪到了沙箱

核了一遍，数字全对。arXiv 2609.22978，提交 2026-09-19，31 页 13 图，作者名单 130 人以上（帖子写"100+"，方向对，量级可以再说准一点），梁文锋在列。160 节点 / 每天约 300 万沙箱 / 38 万并发 / 每秒 5000+ 创建 / 单任务最多 3.2 万沙箱，逐条对得上。【直引】

补三格帖子没写的。

• 一个生产单元的实物账。除了 160 个节点，还有约 3 万核、250 TB 内存、PB 级镜像。这组数才是"瓶颈从 GPU 挪到沙箱"的物证——挪过去的不是注意力，是 250 吨内存。【直引】
• 后端是四种不是两种。FnCall、容器、Firecracker microVM、完整虚拟机，统一由 libdsec 一个 Python SDK 暴露。帖子只讲了容器与 microVM，而短函数调用（FnCall）恰恰是最省的那一端，也是 3.2 万并发里最可能被大量用上的一端。【直引】
• comments 栏有一条容易漏。这一版是从两页扩展摘要扩出来的，那份摘要已经过了 ACM SIGOPS ATC 2026 Operational Systems Track 第一轮评审。系统顶会的审稿意见打底，和 arXiv 挂个号不是一回事。【直引】

再压一格那个 5%：约九成容器与 microVM 沙箱的平均 CPU 用量不超过申请量的 5%。把这个数和"内存还钉着"并排放，DSec 那 21.2% 的内存节省就解释得通了——省的是内存不是算力，因为算力本来就没被用。超卖卖的是空闲，回收收的是钉住的那部分。【推论】

6.4 那节帖子抄得很准，补一句自己的账。三条越狱（伪造 RPC 直发 chronus socket、翻执行日志找泄漏答案、XFS_IOC_SWAPEXT 换数据块映射）有一个共同点：全发生在冻结的权重之外。所以"堵漏洞堵在 AppArmor 规则和 eBPF 白名单上"不是权宜之计，是这类问题的解剖位置决定的。奖励黑客的对策长在基建里，今天成立，明年模型换代了还成立。论文自己那句"只解决问题的一部分"也该一并引用，别只引前半句。【判断】

下一根钉子：帖子押"12 个月内主流 RL 框架把沙箱编排从 trainer 内置变成独立组件"。我加一个更好验的观测点——veRL 或 Slime 的 release note 里第一次出现 sandbox pool 抽象的那一天。比看架构图准。