监控锯齿的背后：你的 GPU 不是在算，是在等
跑过 Agentic RL 的人对这条曲线都不陌生：learner 侧 GPU 利用率像锯齿， rollout 一批冲满，训练一步归零，周而复始。很多人第一反应是卡不够、显存不够，于是加卡、换 B200。但 10 月 16 日知乎上一篇 ThunderSyncRL 论文精读给出的数字更扎心：在 SWE-smith 上跑同步 GRPO，learner GPU 有 49.5% 的单步时间在空闲；论文引用的其他工作里，这个比例最高能到 81%。更具体一点：最慢的 10% 请求，能吃掉一半 rollout 时间。知乎
换句话说，你账单上接近一半的卡时，可能没花在计算上，而是花在等那条最慢的轨迹。修一个 GitHub issue，有的 agent 几轮就交 patch，有的要改几十次代码、反复跑测试，最多能拖到 300 轮。同步训练的规矩是整个 batch 的 rollout 跑完、reward 全部到齐，learner 才开始反传——这就是流水线"气泡"的来源，而它的形状由长尾决定，不由平均长度决定。知乎
业界主流解法是"转异步"，但 verl 刚把它自己推翻了一半
填空气泡的主流答案是异步训练：AReaL、verl 和 SkyRL 的 fully async 模式，思路都是让 rollout 和训练跨 step 重叠——learner 在用上一批数据更新，rollout 已经在用旧权重生成下一批。气泡确实被填上了，代价是训练数据不再严格 on-policy，也就是 policy staleness，要补重要性采样修正、过滤或者显式限制陈旧度，算法上多一层麻烦。有意思的是风向正在变。10 月 14 日另一篇 veRL 技术思想史梳理提到：2026 年 9 月 20 日的 v0.9.1 里，原来的 Fully Async Policy Trainer 和 One-Step-Off-Policy 实验模块被新的 V1 Trainer 取代、进入弃用——而这两样恰恰是 2025 年 7 月（v0.5）和 2025 年 11 月（v0.6.1）作为重点创新引进来的。一年前解决"同步训练等 rollout"的官方答案，一年后被更一般的架构收编。同期还有 Dressage 团队的实践帖（8 月 28 日）给了个可复算的算例：8 个 Engine、128 条 trajectory，长尾负载让最重 Engine 的等价 step 数从理想均衡的 1600 涨到 2600，同步 rollout batch 的完成时间就从 16s 拖到 26s，集群吞吐从 800 step/s 掉到约 492，平均 GPU 利用率直接跌到 61.5%——他们的解法是不动算法、只做 step 级在线负载均衡，把各 Engine step 分布的变异系数从最高 38% 压到 2% 以内。另一头，FlashREINFORCE 则把异步推到 single-rollout、critic-free 的极端。整个生态都在回答同一个问题，只是路线没收敛。知乎知乎知乎
第三路：气泡不是"等待"的问题，是"等待放在哪一步"的问题
ThunderSyncRL 这篇工作的切入点值得算力党细读，因为它把"重叠"和"零陈旧"这对看似二选一的矛盾拆掉了。思路一句话：先算梯度，但不急着更新权重。训练其实是两步——算梯度只读权重，optimizer step 才改权重。同步训练把等待点放在算梯度之前，放得太早；真正需要等整批数据到齐的只有后者。某条轨迹一拿到 reward 就立刻反传、把梯度攒进缓冲区，期间权重一个版本不动，整批到齐后一次性更新。所有数据仍来自同一个策略，没有陈旧，但反传和 rollout 已经并行。知乎
卡点在 GRPO 本身：advantage 要用整组 reward 的均值 μ 和标准差 σ 归一化，看起来必须等整组跑完。关键一步是代数变形，把组均值、组方差依赖从昂贵的反传挪到两个廉价标量上——梯度缓冲区先把与 μ、σ 无关的部分攒着，整组收齐后做一次标量组合，得到的梯度和同步训练完全相同。作者在 B200 和 H200 上做了回放实验验证等价性：录下同步训练连续 10 个 batch 的数据，从同一初始权重分别交给 Sync 和新调度重训，FP32 下梯度相对误差约 5×10⁻⁷，十步后参数差距低于 6×10⁻⁵，只剩浮点求和顺序的差异。实验规模是单节点 8×B200、4 卡 learner，跑 Qwen-3.8-27B 全参微调，GRPO 每步 256 条轨迹、最多 300 轮——正好是多数中小团队摸得着的配置。知乎
还要认清提速的天花板：设 rollout 耗时 R、learner 耗时 L，同步每步是 R+L，完全重叠后至少是 max(R, L)，提速上界就是 (R+L)/max(R, L)。只有两边耗时接近平衡时才接近 2×；如果你的任务是 rollout 远长于训练（agent 任务里很常见），重叠收益会明显缩水。论文自己也承认，这套方案没有和坚持 on-policy 的 RolloutPipe、换权重但控制陈旧度的 PipelineRL、单条轨迹即更新的 SAO 做直接对比。知乎
反证别忘了：低利用率叙事也要过基线这关
同一周还有另一条值得存档的信号：SambaNova 在 HotChips 2026 上放了一张 GPU 模型带宽利用率（MBU）散点图，26 个点里 19 个低于 10%，很多连 5% 都不到，用来论证"GPU 在推理上被严重浪费"。知乎 10 月 14 日有篇逐点复核的回应文，结论是这张图用的基线是错的，数量级反差具有误导性。加上 AMD 刚在 vLLM 主线合入的巨型算子解码——推理 decode 阶段每次内核启停的交接空档就能吃掉一半显存带宽，靠常驻流水线破局。"GPU 很闲"的说法横跨训练、推理、内核多个层级，但每一层的"闲"定义和分母都不一样。看任何利用率数字之前，先问基线是谁定的。知乎哔哩哔哩
按你的现状对号入座
轨迹长度方差大、任务接近 300 轮上限的（代码/工具类 agent RL）：气泡是大头。先量最慢 10% 轨迹占的 rollout 时间比，再决定改调度还是堆卡；ThunderSyncRL 这类"梯度攒算、权重慢更"的思路对不想碰 staleness 修正的人是正中靶心，但注意它还没进主流框架，需要自己动 trainer。
已经转 fully async 且加了重要性采样修正的：verl v0.9.1 的弃用提示意味着异步路线在框架层正被统一架构收编，跟进 V1 Trainer 的迁移公告比继续用旧实验模块安全。
R≫L 的超长 rollout 场景：别指望调度层重叠给你接近 2× 的收益，重点该放在控制轮数上限、做 step balance 负载均衡，或者像 CoPE 那样从算法上绕开长程采样本身。知乎
只是刷到了"GPU 利用率只有百分之几"的图想加预算的：先核对基线和口径（MBU 图争议就是现成教训），再决定掏不掏钱。
接下来值得盯的三个信号：verl V1 Trainer 对异步语义的收编细节、ThunderSyncRL 是否与 RolloutPipe/PipelineRL 补上正面对比、以及推理侧巨型算子路线会不会扩散到训练 kernel。气泡这件事，2026 年下半年已经从"玄学吐槽"变成了可以逐项定价的成本项——你的账单里那条锯齿，值多少卡时，现在是可以算出来的。
