据作者现场录音整理，按讲者脉络转述，不是逐字稿。讲者是 Google agent 基础设施方向的产品经理，中文演讲，约 12 分钟的快闪场，无问答环节；中间有一段 demo 视频没放出来。
一句话
前沿实验室的 RL 后训练已经被大规模沙箱调度卡住。Google 开源了一套专为 RL rollout 做的沙箱基础设施，她说能做到百万级并发、首条指令 1 秒内；下一代要用快照把沙箱空等的时间省掉。
论断
1. RL 训练卡在沙箱调度上
她说研究员想持续扩大 RL 训练，卡住他们的是基础设施，具体说是怎么持续调度大规模的沙箱。
“你会发现，沙箱在每一步，每一个条轨迹上都必，都必须要执行”
- 她用最简单的 RL loop 说明：任务是用 Python 输出 hello world；把打包了 Python 库的镜像放进沙箱；LLM 想完后代码放进沙箱执行；看输出对不对；再打分，可以用 LLM 当评委。
2. 规模上去后的四类问题
- 吞吐：一个任务常让模型产生 16 条 rollout。以某实验室的 RL dashboard 为例，1000 个 task 各做 16 次 rollout，单次就要启动 16000 个沙箱。她说这在前沿实验室是"非常常见的数字"，普通的 agent serving 和 inference 很少能达到这个并发。
- 镜像：训练数据常把一个 GitHub 仓库打包成镜像（比如 SWE-bench），依赖多，镜像很大。她说某份技术报告（疑为 Kimi K3）里训练了超过 150 万个镜像。
- 数据污染：传统沙箱要等几分钟才准备好；训练中内存溢出、超时会被 reward 判成任务失败。
- 空等：沙箱 80% 的时间在等模型思考，只有 15% 的时间在真正工作；前沿实验室每天百万量级的轨迹，等待期间可能是百万美元的 GPU 集群也在等。80% 和 15% 没给数据来源。
“那么你的整体的训练数据其实是被污染了，就没有正确评定这个任务是否真的完成，而是因为基础设施问题而被评判为了没有完成，这会影响到最终模型的权重输出”
3. 开源方案的三个数字
“我们可以做到百万量级同时的并发，它能够稳定持续的，我们跑了八天，它都没有崩，没有产生一个沙箱错误”
- 首条指令时间在 1 秒内，P99 延迟也在 1 秒内。
- 用预热池装填，100 万个沙箱 12 分钟填满。
- 测试用了 30 万个公开数据集镜像（如 SWE-bench）。她认为理论上能满足大部分场景，超大规模实验室今天就能用开源版本。
- 这几个数字都没给同等负载下的对照测试。
4. 上层一个 SDK，下层做缓存、控制平面和装箱
“上层是一个非常简单的 Python SDK，你只需要写你的业务代码就可以了，和这个底层的 infra 架构没有任何关系”
- 她说架构分四层，讲了三层：研究员层（数据集、算法、policy）；后端，30 万镜像部署在约 4000 个 CPU 节点上；控制平面。
- 镜像：用动态算法把镜像放在离节点更近的位置，靠缓存加快拉取和解析。
- 控制平面：API server（疑为此词）本身不是为这种规模设计的，经常崩溃或超时，他们在控制器和控制平面上做了大量调整。
- 网络 identity：批量任务乘以 16 让 identity 数量爆炸，他们收敛到 1 万个沙箱最多只需 512 个。
- 密度：一个节点能部署 60 个沙箱，她说这对超大规模很重要，能提升利用率。
- 除了 GPU，他们也在 TPU（疑为此词）上做了验证，训练一个 Qwen 模型，1 秒内完成调度和首条指令。
- demo 视频没放出来，她口述是一个看板，能看到每次 rollout 的过程、沙箱波动和耗时。
5. 下一代用快照把空等省掉
遗留问题是：大规模下有的场景需要定制脚本，在预热池下怎么做；怎么进一步提高沙箱密度、降低成本。下一代架构（疑为题目里的 Agent Substrate）用压缩快照和快速启停来做，控制平面的吞吐瓶颈用新的数据平面来突破。
“使得你每一步的优化都通过快照恢复低于亚秒级的方式，这个能够大幅提升你的沙箱密度和降低你的成本，使得你的空闲时间都被优化掉”
- 快照方案没给实测数字。
收尾三条：百万量级或更小规模的实验室，现有开源方案大部分情况下已经够用；下一代架构在开发，成本优化更好，预计这个月底发布；全部开源，欢迎国内实验室和创业者反馈。
存疑
- 150 万个镜像出自哪份技术报告没听清，疑为 Kimi K3，需对照报告核实。
- RL dashboard 的例子来自哪家实验室没听清。
- 80% 空等加 15% 工作合计 95%，剩下的 5% 没说明，可能在幻灯片上。
- 架构说是四层只讲了三层，第四层可能在幻灯片上。
- Qwen 模型的具体型号没听清。
- 现有开源项目的名字没听清。
评论