DeepSeek 梁文锋署名的 DSec 论文，9月19号提交。作者名单超过130人。论文里给了一组数字，一个生产单元约160个CPU节点、3万核、250TB内存，托管PB级镜像。

单条任务最多一次拉起3.2万个沙盒。这个量级跟平时本地跑模型完全不是一个思路。

论文里提到沙盒经常处于等待下一步操作的状态，CPU利用率不高。但CPU闲着，内存和可写状态还是占着，不能释放。这话看着像常识，但写进论文里就变成了一组必须花钱解决的账。不对，应该是变成了一组必须靠调度策略绕开的限制。

Agent RL 的 rollout 需要环境保持可恢复状态。跑完一轮，现场得拆掉，重新装干净，交给下一轮。跟静态数据集对模型输出的那种训练不一样，中间每一步都会改环境状态，下一步又建立在前面的结果之上。

从 V3.2 到 V4.1 的 RL 训练和评测，所有沙盒负载都跑在 DSec 上。论文里写这句话的时候，大概知道读者会去算单日300万个沙盒这个数。38万峰值并发、每秒5000个创建速度，这些数字摆出来，问题就不是沙盒本身了，是调度。

传统起一个容器跑完一个任务的思路接不住这个量。CPU间歇性空闲、内存持续占据，这个状态分布本身就是个调度问题，不是算力问题。所以论文标题里写的是 sandbox infrastructure，而不是 sandbox。

DSec 第一次出现是在 V4 技术报告里，当时没展开。这次单独一篇论文，算是把实现细节放出来了。

说真的，这些数字拿来跑本地工作站的人没什么用。32G 显存的机器开几个浏览器标签页都嫌挤，跟 PB级镜像不在一个数量级。但论文里有句话值得留意：沙盒不是越轻越好，可写状态和内存占用才是成本主体。