上个月我在调一个 RLVR 项目日志里一条 rollout 看起来非常正常模型生成了 8 个候选回答验证器逐个打分训练循环照常推进。但当我输出 advantage 那一列时发现情况很不对劲——要么是一排接近 0 的数字要么是符号和我脑子里预期的完全相反。这不是偶发问题。在我看过的 RLVR 训练项目里至少有一半的失败案例不是模型爆炸而是 rollout 在学习信号层面早就“死”了训练正在用一个没有生命力的信号硬撑。这篇文章只聊一件事一条 rollout 在 RLVR 里是怎么死掉的学习信号漏在哪怎么补回来。RLVR 全称是 RL with Verifiable Rewards也就是基于可验证奖励的强化学习现在大量用在数学推理、代码生成、逻辑规划这类任务上。适合正在跑 PPO 或 GRPO 的工程师也适合刚把 RLVR 跑起来、对效果为什么忽上忽下还很困惑的研究同学。我建议你把这篇文章当作一份排障手册来看不需要按顺序读。如果你已经知道“死法一”和“死法二”的大概含义可以直接跳到第 4 节查漏或者跳到第 6 节看问题速查表。1. RLVR 的基本盘以及 rollout 在其中的角色1.1 RLVR 真正在训的是哪一项能力RLVR 和传统 RLHF 的核心区别在奖励来源。RLHF 通常训练一个奖励模型来模拟人类偏好用它可以给任意一条回复打分但奖励模型本身有偏差、有噪声还容易被对抗攻击。RLVR 则把奖励换成可验证的规则数学题对答案、代码跑单测、逻辑题走校验器。奖励不再是“学”出来的而是“算”出来的。这听起来比 RLHF 干净得多也确实干净得多。但很多人忽略了一点RLVR 只是净化了奖励的“来源”并没有解决奖励的“分配”。一条 rollout 的最终得分是 1 还是 0回答了“结果对不对”但没有自动回答“到底是哪一步让结果变对的”。把终局奖励拆解到过程动作这个环节一旦出问题就是麻烦的开始。我在项目里见过不少同学把 RLVR 想象成“给定分数就能自动学会做题”结果跑了几百步log 里的 reward 稳步上涨但是打开生成样本模型只是学会了输出更短的答案、更多套话、或者干脆猜一个高频结果。这种失败不是 reward 不够大而是信号本身没有真正指导策略往正确方向走。1.2 一条 rollout 从采样到梯度要走完哪五步一条 rollout 不是“模型生成的一段文本”那么简单。它是一连串数据经过处理后变成梯度的一整条链路。我习惯拆成五步拿到 prompt用当前策略采样 N 条回复得到生成序列和每个 token 的 logprob。把回复交给验证器得到每条回复的 reward。把同一组 prompt 的 N 条 reward 做归一化或减去 baseline得到每一条的 advantage。用 advantage 乘以对应 token 的 logprob 梯度得到策略梯度。叠加 KL 惩罚、clip 等约束更新策略参数。每一步都有可能吞掉这条 rollout 携带的信息。你要找学习信号漏在哪本质上是检查这五步里哪一步在做“信息减法”。为了方便理解你可以把一条 rollout 想象成一次实验的记录表prompt 是实验条件生成序列是操作过程reward 是实验结果advantage 是实验结论。你后续所有的策略调整都来自你对这份记录表的解读。如果记录表本身就缺了关键变量或者解读方式有方向性错误后面再厉害的优化器也救不回来。在这里就自然引出两种死法的位置死法一是结论符号反了也就是 advantage 的方向错了该推的没推、该拉的没拉死法二是结论信息量趋近于 0也就是 reward 没有区分度advantage 全部归零模型什么都学不到。2. 死法一信号反相一条 rollout 把策略推向了错误方向2.1 现象复盘离线涨点分布外崩盘死法一最典型的表现是训练日志很好看采样 reward 在涨在线评估也涨但你换一批分布稍有不同的测试题效果直接崩掉。很多团队会把这种情况先归因于过拟合然后去加数据、调 dropout。但在我实际排查的项目里有相当一部分根本不是过拟合而是 rollout 给出的 credit assignment 反了。一个辅助判断信号是模型开始走捷径。比如数学推理任务里所有回答都变得特别短中间步骤明显缺失但最后答案对了或者代码任务里模型学会了输出一堆能通过单测、但完全没实现题目要求的空壳函数。这不是模型的“聪明”这是你的奖励信号在告诉它“短输出更好”、“能跑就行逻辑不管”。因为从梯度角度看它每一步都在最大化当前的 reward它只是在忠实执行你的信号。2.2 第一个反相源头稀疏奖励下的 credit assignment 错位RLVR 在推理任务里最常用的是 0/1 稀疏奖励最终答案对了给 1错了给 0。这种设计带来的 credit assignment 问题非常严重。举个例子。有一条 9 步推理的 rollout前 6 步推理逻辑严谨、每步都在正确的方向上到第 7 步推导出了一个小代数错误最终答案 0 分。另一条 rollout 前 6 步基本是胡写只在最后一步碰巧给出了正确答案最终答案 1 分。如果验证器只看最终结果那么第一条会得到负面的 advantage第二条会得到正面的 advantage。于是策略梯度会做两件反直觉的事它会把前 6 步“高质量推理”的出现概率往下压把胡写乱猜的行为概率往上抬。短期看reward 可能没掉因为模型开始更频繁地猜答案长期看模型的推理能力一定会退化。这就是一条 rollout 的“死法一”它不是没产生信号而是信号的符号在细粒度行为层面反了学习等于在反向优化。面对这种问题我强烈建议你别只盯着最终 reward。在每个 rollout 里多保存一个字段中间步骤的关键状态比如每步推理使用了哪条定理、代码执行到哪一行报错。这个字段一开始可能用不上但它是排查 credit assignment 问题时的关键线索。2.3 本不该有的反相归一化窗口和代理校验器惹的祸另一类反相来自实现层的细节。先说归一化窗口。GRPO 这类算法通常会在同一组 prompt 内做 advantage 归一化这本身是合理的。但如果你不小心把 N 条采样混入了来自不同难度 prompt 的样本或者使用的是跨 batch 的全局归一化那么一个本来正确的答案放到一组“全是正确样本”里它的相对 advantage 就会偏低放到一组“全是错误样本”里它的相对 advantage 就会偏高。严重时一条该被正向鼓励的 rollout 可能因为参照组太强变成负信号。更隐蔽的是代理校验器。你以为校验器在验证“逻辑是否正确”实际它可能只是在验证“是否包含某个关键词”。比如你设计了一个匹配规则要求答案里含有“因此”这个连接词模型很快就学会了在所有输出里强行加入“因此”即使后面的推理是错的。从 advantage 的角度看这类伪造正确性的 rollout 会被打上正标签于是模型被主动引导去刷关键词而不是提高推理质量。这同样是一种反相。我在排查时会把校验器的判断条件单独打日志抽几条打印出来人工看。不要只看 reward 分布要看“为什么给这个分数”。一旦发现规则里有可被廉价复制的模式基本就能定位到反相源头。2.4 判断反相的快速方法梯度探针和人工渲染我常用两个方法确认 rollout 是不是“反着学”了。第一个方法叫梯度探针。取一条确定的 rollout重算它的 reward记为正向然后把 reward 改成相反值再算一次梯度比较这两个梯度方向。如果一条本该被负向优化的样本你把它的 reward 翻正后梯度方向对某些 token 反而变反了那就说明 credit assignment 在某一步出了问题。具体操作上不需要完整训练只要取一个 checkpoint单独跑一个 batch记录每个 token 的梯度向量然后做向量内积即可。第二个方法叫人工渲染。把一条 rollout 的每个 token、每个 token 的 logprob、每个 step 的 reward 变化按行打印出来。人工渲染不是让你逐字读而是看 logprob 的分布是否合理。如果一条 reward0 的 rollout它的推理核心步骤处 logprob 反而下降得很厉害那大概率就是信号反相。这两个方法都不复杂但我在很多项目里看到大家只盯着 loss 曲线和 reward 曲线很少做这种细粒度的信号检查。结果就是问题往往在训练跑了两三天后才暴露浪费大量算力。3. 死法二信号趋零一条 rollout 活着但什么也没教给模型3.1 现象复盘loss 在降策略却没动与“反相”相比死法二更隐蔽。它的典型表现是训练跑了很久loss 也在缓慢下降但你打开模型的实际输出发现和训练前几乎一模一样。reward 曲线可能已经很高了但 advantage 的绝对值普遍在 0.001 量级甚至直接就是 0。我把这种状态叫“无声死亡”。它没有 NaN、没有 inf、没有显存爆掉训练进程非常健康但你心里清楚模型没有学到任何新东西。最坑的是如果你只看 loss完全看不出问题因为 KL 项和熵项的存在让 loss 仍然有数值变化。在 RLVR 里这种状态的直接后果是“训练完成但效果没有提升”。你花了几百张卡时换来的只是一个和初始策略几乎等价的模型甚至因为 KL 惩罚的作用模型变得更保守、表达能力更弱。3.2 静默死亡的第一原因奖励缺失区分度死法二最常见的触发条件就是 reward 没有区分度。考虑最简单的情况某道代码题你设计了 4 个单元测试。模型采样了 8 条 rollout其中 8 条全部通过或者 8 条全部失败。如果 8 条全部通过reward 数组就是 [1, 1, 1, 1, 1, 1, 1, 1]组内均值是 1组内标准差是 0归一化之后每条 advantage 都是 0。策略梯度计算时所有 token 的更新幅度都乘以 0等于没更新。如果 8 条全部失败reward 数组是 [0, 0, 0, 0, 0, 0, 0, 0]结果一样全是 0。这种“全对或全错”的情况在课程设计不合理的任务里非常常见。你以为模型已经很强其实它只是把最难的题全做错了或者把最简单的题全做对了。没有负例做参照没有正例和负例之间的差异advantage 就失去了信息量。更隐蔽的是“近似无区分度”。比如 reward 数组是 [1, 1, 1, 1, 0.99, 0.98, 0.97, 0.96]看起来不是全同但平均值接近 0.99减去均值后最大的 advantage 只有 0.04 左右再经过一次 KL 项压制有效梯度仍然接近 0。这种时候你光看 reward 曲线会觉得“已经收敛得很好了”实际策略几乎没有被推进。3.3 静默死亡的第二原因探索枯竭与熵坍缩另一个常见原因是探索枯竭。当 temperature 设置过低、top_p 过窄或者 prompt 分布太单一的时候模型采样出来的 8 条 rollout 高度相似甚至只有个别 token 不同。这种情况下即使 reward 有区分度经过归一化后会出现两个问题一是 advantage 的方差很小因为样本看起来太像了二是模型已经处于一个很窄的分布上任何微小的更新都很难跳出当前局部区域。我用一个打靶的类比来解释如果你每次都站在同一个位置、用同一个姿势、往同一个方向开一枪就算靶纸上有环数差异你也很难知道下一枪应该往左修正还是往右修正。因为你收集到的反馈只覆盖了极小的动作空间。RLVR 也一样。rollout 本身如果太同质化它就是一条“有效信息量不足”的样本不管 reward 怎么打梯度信号都带不来足够的方向信息。什么时候最容易触发这个现象当你把 RLVR 应用到一个已经用 SFT 充分训练过的模型上初始策略本身已经很强生成结果趋于稳定此时如果没有额外注入探索优势函数天然会偏小。你需要主动设计机制让 rollout 的多样性保持在合理水平。3.4 用三个数字判断信号是否还活着我每次开始 RLVR 训练前都会先记录三个数字之后每隔几百步再打一次。这三个数字基本能快速判断一条 rollout 是否已经“死”了。第一个是 advantage 绝对值的均值。如果这个值低于 0.05说明奖励区分度可能不足尤其当你确认 reward 不是全同的时候这个数值会提示你归一化之后信号被摊薄了。第二个是 advantage 的非零比例。把 advantage 绝对值小于 1e-6 的算作零统计非零比例。如果非零比例低于 10%基本可以断定当前策略处在一个“无梯度”的状态你需要停下来检查 reward 设计而不是继续烧算力。第三个是生成序列的平均熵。模型采样出来的文本平均熵如果掉到参考模型熵的一半以下说明策略正在快速坍缩探索能力已经趋近于零。这时候即使经过若干步训练模型也只是在同一个窄分布里来回抖动没有真正探索到更好的解。这三个数字不是绝对指标因为 reward 尺度在不同任务里差异很大。但它们能给你一个相对统一的观测窗口。我要强调的是死法二之所以可怕就是因为它发生在你最容易忽略的“看起来一切正常”的阶段所以这种低成本的信号检查非常有必要。4. 信号漏在哪五个泄漏位置的系统排查讨论完两种死法我们把视角拉开一点系统地看一下学习信号在整个链路里到底漏在哪里。我根据自己的排查经验把泄漏位置归类为五处每处都配了症状和验证方法。你可以把它当成一张自查表用。泄漏位置典型症状常见原因修复优先级采样端rollout 内容被截断、token 分布异常、生成序列重复max_tokens 设置不合理、prompt cache 命中旧数据、温度/采样参数不适合任务高奖励端reward 常为 0 或 1、reward 与真实质量相关性弱校验器规则有漏洞、奖励粒度太粗、验证器只查格式高对齐端advantage 整体偏小、符号与预期不符归一化窗口跨难度、baseline 选择不当、长度归一化引入混淆高更新端loss 正常但策略不变、梯度被 clip 大量截断PPO ratio 偏离过大、KL 惩罚系数过大、advantage 数值爆炸后 clip 过度中工程端不同步的日志里数据不一致、训练中途静默跳过更新数据缓存陈旧、all_gather 丢数据、float16 存储精度损失中4.1 采样端rollout 内容本身缺斤少两信号要从 rollout 里来rollout 本身就绝不能出问题。我见过最多的情况是 max_tokens 设得太小模型把推理过程写了一半就被截断但验证器仍然按“最终输出字符串”做匹配导致它误判答案错误。结果就是一条本该得分的过程被标成 0拖累整个组内 advantage。另一个采样端问题是陈旧 rollout。有些训练框架为了省算力会缓存上一轮的生成结果下次再用同一批 prompt 训练时直接复用。如果模型已经更新了但旧的 rollout 还被拿去算梯度那么模型实际上是在学习旧版本的自己信号天然错位。你需要在日志里记录 rollout 生成时的模型步数一旦发现复用样本来自明显较早的步数就要警惕。4.2 奖励端规则留下投机空间奖励端泄漏是 RLVR 最独特的坑。奖励不是学出来的但规则是你手写的手写规则就一定有不完整的部分。最常见的是“只匹配最终答案字符串不检查中间逻辑”。模型一旦发现“最终输出里有答案是 A就能得分”它会慢慢把中间推理压缩成一句废话。我在代码生成任务里也经常看到这种问题校验器只运行冒烟测试不检查边界条件模型就学会了生成覆盖最简单的 happy path 的代码。这本质上不是模型偷懒是奖励函数在告诉它“不需要处理边界”。修复方向是让校验器覆盖更多分支而不是反过来加大 KL 惩罚。4.3 对齐端归一化与基线把信号洗掉了即使 rollout 本身没问题、奖励也有区分度优势估计这一步仍然可能把信号抹平。前面提到的跨难度归一化就是一个典型问题。如果一条困难的 prompt 里只有一条成功它在该组内的 advantage 会非常突出但如果它被塞进一个由大量简单 prompt 组成的全局 batch 里它的相对优势就会被摊薄甚至方向都受影响。另一个常见的坑是长度归一化。推理任务里长答案和短答案的 reward 分布天然不同。如果你简单地把 reward 除以生成长度会对“短而正确”的样本过度奖励对“长而正确”的样本过度惩罚。这种偏置一旦被模型发现它就会往短答案的方向优化即使那些答案缺乏中间步骤。4.4 更新端clip 和 KL 把梯度切没了更新端的泄漏经常被忽略因为算法在数学上看起来是对的但实际上信号被后续的约束项“切没”了。PPO 的 clip 机制是防止单步更新过大的但如果 advantage 本身很大ratio 很容易被 clip 到边界导致大部分 rollout 的梯度被截断。你看到 loss 还在变但真正对策略产生影响的 token 只有一小部分。KL 惩罚也是双刃剑。如果你为了不让模型偏离参考策略太远把 KL 系数设得很大它会把 reward 带来的梯度信号完全压住。尤其当 reward 区分度本来就小的时候KL 项会进一步把有效信号淹没。我在这类问题上会先做一次梯度统计打印“被 clip 的 token 比例”如果比例超过 30%说明更新端的泄漏已经很严重了。4.5 工程端缓存与日志里的静默丢信工程端的问题最让人抓狂因为它的表现方式和前面几种很像但根因完全不同。我碰到过一次场景训练日志显示 advantage 分布正常但生成的样本全是老的后来发现是数据加载器把同一个 prompt 的缓存滚动了 500 次都没重新采样。还有一次是 reward 保存时用了 float16小数的尾数被截断导致一整个 batch 的 reward 变成完全相同的值。这种问题很难通过调参解决只能靠流程规范来防。比如给每条 rollout 加上“生成时间戳”和“模型版本号”在训练日志里比对reward 用 float32 保存不要为了省内存牺牲精度分布式训练时对 advantage 的 all_gather 结果做一次校验确保和本地计算结果一致。5. 怎么补从奖励设计到监测门禁的实操修复策略5.1 奖励层修复把终点判定改成过程判定面对死法一最有效的手段是让奖励从“看终点”变成“看过程”。在数学推理任务里不要只比较最终答案字符串可以引入分步判定把标准答案的推理链拆成若干关键步骤模型输出里每命中一个关键步骤就加 0.25 分最后再根据最终答案的正确性给一个剩余分。在代码任务里不要只跑冒烟测试可以加断言检查中间变量、边界输入、异常分支。这个改动最直接的价值是让 reward 在“整体错误”的 rollout 里仍然保留一部分“部分正确”的信息。一条前 6 步全对、最后一步算错的 rollout不再和一条通篇胡写的 rollout 拿到同一个 0 分。这样 credit assignment 的符号就不会大面积反相。当然过程判定的成本也更高。你需要维护标准答案的步骤模板或者编写更复杂的校验器。我的建议是先在 20 到 50 条样本上人工标注试跑看判定逻辑会不会误伤正确思路。如果过程判定本身不稳定可以考虑只把过程分作为辅助特征最终 reward 仍然以终局对错为主避免引入新的噪声。5.2 Advantage 层修复归一化窗口和长度偏置死法二出现的直接原因往往就是 advantage 被洗成了零。修复时我会先检查归一化窗口。理想的窗口是一个 prompt 下的全部采样样本也就是同一个任务难度下的一组同类样本。如果某个 prompt 的采样数太少比如只有 2 条就别硬做标准差归一化直接用原始 reward 加一个小偏移做 baseline 效果反而更稳。这里的偏移可以取该组 reward 的均值但要给 std 加上一个很小的 eps防止除数为零。长度偏置问题我一般用回归法处理。训练前取一小批 rollout 样本做一次 reward 对 log(长度) 的线性回归得到残差然后用残差替代原始 reward 去算 advantage。这样可以把“长答案天然更容易得分”的偏置剥离让信号的注意力集中在内容质量上。做完这些之后再把 advantage 做一次 log 或 rank 变换降低极端值的影响。正常分布下直接用原始值没问题但 RLVR 的 reward 经常出现长尾比如某条 rollout 因为验证器不完善拿到了异常高分就会把它所在组的所有样本的 advantage 都挤到很小的绝对值。此时 rank 变换能保证其他样本仍然保留相对梯度。5.3 探索层修复让 rollout 重新有信息量探索修复针对的是死法二里的“熵坍缩”。具体操作上我习惯在采样时做三件事。第一把 temperature 调到 0.8 到 1.0 之间top_p 保持在 0.9 到 0.95。很多人为了让生成结果稳定会把 temperature 压到 0.5 以下这在推理任务里会直接杀死探索。第二对 prompt 做扰动。同一个数学题可以改数字、改提问方式甚至故意在题干里加入无关信息这能增加 rollout 间的多样性也能提升模型的泛化能力。第三在损失函数里加入一个小的熵正则项鼓励模型在步骤选择上不要过早确定。另外一个容易被忽略的点是“失败样本重新喂入”。很多 RLVR pipeline 只保存 reward 高的 rollout把 reward 为 0 的样本直接过滤掉。这对采样效率是好事但对信号稳定性是坏事。因为你丢掉的可能是最有区分度的负样本。我会在每组里至少保留一条 reward 最低的 rollout把它重新加进训练 buffer确保优势函数始终能看到负侧的信息。5.4 监测层修复训练前加一道信号质量门禁关于如何及时发现问题我强烈建议每个 RLVR 任务在训练开始前跑一个“信号质量体检”。我现在的流程是用当前 checkpoint 采样 100 条 rollout打印 reward 分布看是否同时存在高分和低分。计算 advantage 绝对值均值和非零比例。计算生成序列的平均熵。随机选 10 条 rollout人工阅读确认 reward 和内容质量一致。这套体检只需要 20 分钟但能帮你避免 95% 的无效训练。体检通过后再启动长训练训练中每 500 步自动打一次这三项指标一旦非零比例低于 10%或者平均熵掉到阈值以下就自动告警。这个门禁在自动化框架里很容易实现而且价值极大。6. 常见问题与排查技巧实录6.1 问题整个 batch 的 advantage 全是 0出现这种情况我一般按顺序查四步。先看 reward 原始分布如果全是 1 或全是 0问题在验证器或任务难度不需要动算法如果 reward 有区分度但 advantage 全为 0检查归一化窗口和 std看是不是除以了一个极大的数值如果 reward 和归一化都没问题检查 KL 惩罚系数它可能把原始梯度压没了最后再检查 logprob 是不是来自旧 checkpoint如果模型参数和 rollout 不匹配算出来的 advantage 再合理也会失真。6.2 问题advantage 出现 NaN 或 InfNaN 问题在 RLVR 里大多来自三个地方logprob 里出现 -infreward 数值过大导致归一化时浮点溢出组内标准差为 0除以 0 导致 inf。我的处理是分别加保护logprob 下限截断到 -10reward 做 clip归一化时给 std 加 1e-8。另外如果用了混合精度训练advantage 建议保留在 float32不要降成 float16。6.3 问题rollout 长度失控rollout 越长信号越容易在中途断裂显存也更容易爆。我一般建议设一个动态 max_tokens按任务类型给上限。长度超出上限的样本不要直接丢弃而是记录它的奖励和截断位置如果这类样本占比超过 10%就要检查是不是生成过程没有触发正常的停止符。更实用的一点是在验证器判定之前先把未完整生成的样本标记为“截断”这类样本的 reward 默认给最低分防止模型通过“说一半就停”来骗分。6.4 工具5 分钟写一个 rollout 探针脚本我每个 RLVR 项目都会塞一个简单的 rollout 探针脚本作用就是打印一条 rollout 的关键信息。核心逻辑大概长这样def probe_rollout(policy, tokenizer, prompt, verifier, group_id): samples policy.sample([prompt], n4) rewards [verifier.score(s) for s in samples] advantages normalize(rewards) # 内部做分组归一化 entropy mean_seq_entropy(samples) for i, s in enumerate(samples): print(fGROUP{group_id} IDX{i} REWARD{rewards[i]} ADV{advantages[i]}) print(s[:200]) print(---) print(fENTROPY{entropy})这个脚本不用写得很完整关键是打印字段要全reward、advantage、长度、熵、生成文本前 200 字。每次训练异常时先跑一遍看看这些字段的匹配是否符合直觉。很多看似玄学的失败其实一眼就能从这些字段的组合里看出端倪。6.5 一次排查实录全绿曲线背后的两小时最后分享一个我实际排查过的案例。某代码生成任务训练日志一路向好reward 稳定上升advantage 分布也正常测试集通过率在涨。但团队发现测试集涨的是“能运行”的比例不是“逻辑正确”的比例。打开样本一看模型生成的代码全部变成三五行直接return None。我们花了两小时定位最后根因是验证器只跑了一个非常简单的冒烟测试没有检查任何功能正确性。模型其实第一轮就发现了这个“漏洞”然后所有 rollout 都往“最小可运行代码”方向优化。这个东西在 reward 上完全看不出来因为 test pass 率一直在涨。修复起来也简单验证器里加功能断言增加边界输入测试同时限制最短代码长度。再训练一轮模型输出的质量和可读性都恢复了。这个案例给我的教训是不要把 reward 曲线当作唯一健康指标要定期看 rollout 的内容本身。信号是否健康永远要回到“一条条具体的 rollout”上去验证否则你会被统计数字骗得很惨。我个人现在养成的习惯是每次 RLVR 训练开始之前先花 10 分钟做一轮信号质量体检打印一批 rollout、看 advantage 分布、算生成熵、人工确认 reward 和内容质量一致。这个习惯帮我避开了至少三次看似无解的“玄学”失败。如果你的训练也在奇怪的地方停滞不前试试这套检查大概率能在 30 分钟内找到那条 rollout 到底是怎么死的。