GRPO 训练排查：
先分清策略坍塌与训练崩溃，再决定改哪一层

先建立共同认知：坍塌是分布变窄，崩溃是某一步的工程/数值事故；两者的证据不在同一张曲线上。

GRPO 用同一 prompt 的一组回答做基线，而不是训练一个 critic。对第 i 条回答，组内 advantage 是：

减均值决定「谁比同组平均更好」，除以 std 决定「这组差异按多大音量进入训练」。两个操作合起来有一个硬边界：组内所有 reward 相同，分子就是 0，不管 std 是不是 0，advantage 都是 0（core_algos.py:326）。这时这一组没有任务梯度；它既可能是「模型已经全对」，也可能是「模型已经全错」。

还有一个容易混淆的配置边界：rollout.n 默认是 1（verl/trainer/config/rollout/rollout.yaml:135）。当一组只有一条样本时，verl 把该组的 mean 设为 0、std 设为 1（core_algos.py:316-317），advantage 退化成原始 reward，组内基线消失。这不是策略坍塌，也不是数值崩溃，而是配置错误：你以为在跑 GRPO，实际没有组内比较。

已有工作给的是两种镜头：一种解释算法层为什么会变窄，一种暴露工程层具体哪个张量坏了；两者都不能单独完成诊断。

所以顺序不是二选一，而是先工程、后算法：工程层是 0/1，能被穷尽排除；算法层是目标函数的倾向，只能设计上缓解。这个顺序来自笔记的工程实践，原论文没有把它写成流程；本页把它和代码里的实际故障点对齐。

GRPO 的 advantage 公式给出一个硬边界；其余症状要沿 rollout → logprob → advantage → update 的信号链分层。

把「策略坍塌」和「训练崩溃」落到可操作判据，先记住三件事：

• 组内全同 → advantage 0。这是数学结果，不是故障类型。它说明这一组没有比较信号；要判断是坍塌还是数据太简单，得看它随时间怎么变、以及全对/全错各占多少。
• 单样本组 → 没有组基线。rollout.n=1 时 verl 走 len(id2score[idx]) == 1 分支，mean=0、std=1（core_algos.py:316-317），advantage 就是原始 reward。GRPO 文档明确要求把 rollout.n 设成大于 1（docs/algo/grpo.md:29）。
• σ 归一化可以关。norm_adv_by_std_in_grpo 默认 True（verl/trainer/config/algorithm.py:737）；Dr. GRPO 把它设为 False（docs/algo/grpo.md:62）。关掉只减均值，advantage 落在原始 reward 差的范围内；这不是「修复」，是换一种权重结构。

表 1（本页归纳，不是论文表格）：症状到类别的映射。「坍塌 / 崩溃」是笔记的工程分类；每一行的判据都指向可查的原文或源码，不把分类本身当成论文结论。

表里的 § 指 DAPO / DeepSeekMath 章节；代码行号对应 verl@7de8f2e。最后一行的因果链是工程推断，不是原文结论。

自己动手：G 和 p 怎么改变「零方差组」的自然占比

DAPO §3.2 要过滤 accuracy 为 0/1 的组（Eq.11）；全对组 advantage 为 0 是原文点名的例子，全错组由同一公式同样为 0。§4.1 用 G=16、每批 512 个 prompt。把二值 reward 近似成「每条回答独立、以概率 p 正确」，一组全同的概率就是 pG + (1−p)G。默认 G=16、p=0.90 时：全对组 18.53%，全错组 0.0000%，零方差合计 18.53%；512 个 prompt 中约 417.1 个仍有组内比较信号。

actor/entropy、actor/ppo_kl、actor/grad_norm 各自来自不同阶段；默认配置还会让某些检查静默失效。

verl 一个 step 的顺序是：rollout 生成（ray_trainer.py:1508-1526）→ reward（:1560-1567）→ old_log_prob 前向并算 entropy（:1584-1600）→ ref_log_prob（:1620-1622）→ advantage（:1627-1667）→ update_actor（:1689-1690）→ update_weights（:1715-1716）。这决定了每个指标对应哪一版策略。

actor/ppo_kl 不是到 reference 的 KL：它是 mean(-(log_prob - old_log_prob))，且 log-ratio 在 exp 前被 clamp 到 [-20,20]（core_algos.py:1254-1258）。到 reference 的 KL 有两条路：algorithm.use_kl_in_reward=True 时记 actor/reward_kl_penalty（ray_trainer.py:100-115）；actor.use_kl_loss=True 时记 kl_loss（verl/workers/utils/losses.py:181-182）。三个名字不能混着读。

actor/grad_norm 是裁剪前的 norm（transformer_impl.py:735 的 docstring；:748-752 调 clip 函数并拿到返回值），由 trainer 在 ray_trainer.py:1788 读取。非有限时 FSDP engine 会 zero_grad 并跳过 optimizer.step（:765-769）——进程不一定挂，但这一步没有更新。日志里只出现一次 WARN 和连续出现 WARN，含义完全不同。

表 2（本页归纳）：verl@7de8f2e 的指标与代码位置；不是论文表格。

表 3（本页归纳）：会改变诊断结论的默认值；行号对应 verl@7de8f2e。

诊断本身也有算力代价。actor/entropy 不需要额外采样：它和 old_log_prob 在同一个前向里算（ray_trainer.py:1300）。动态采样则要额外生成：DAPO §3.2 说每批的采样成本是动态的，要一直采样到 batch 被非 0/1 正确率的组填满；verl 的 filter_groups 需要 refill_fn 替换被淘汰的组（replay_buffer.py:178-179），不是免费的开关。DAPO §4.2 / Figure 6 报告在其设置下总训练时间没有显著受影响、收敛所需 step 更少；这个结论依赖「生成被长尾样本主导、同步、非流水线」等条件，不能直接搬到所有异步系统。

一张图把症状分流：先读 rollout 原文，再验概率一致性与数值路径，最后才动 clip、采样和学习率。

图上的 0/1 检查顺序可以展开成：概率一致性（同一批 token 在训练侧两次、推理侧一次）→ 梯度累积等价性 → 逐 token mask → 数值路径的第一个 NaN/Inf → optimizer / reward。这个顺序的关键不是「优雅」，而是每一层都有通过条件：ratio 的分子分母不是同一套概率口径时，后面的 clip fraction、KL、lr 扫描都失去原义。

如果只能做一件事，先做权重没变时的 ratio 检查（笔记的 A/B/C 检查）：冻结权重、关 dropout、固定 RNG，同一批 token 在训练侧前向两次、在推理侧前向一次。训练侧两次不一致，查训练框架自身的可重复性；训练侧和推理侧不一致，查两套实现的概率口径。权重没动但大量 token 已经撞 PPO clip，说明训练目标把实现差异误读成了策略更新 工程判断——这时应先停训修口径，而不是调 clip。

Table 1 是逐项叠加的结果，能说明这些处置改变了训练，不说明每一项都独立有效；DeepSeekMath 的 Maj@K / Pass@K 则说明单看一条准确率不够。

表 4（本页转录 DAPO Table 1）：AIME24 avg@32。原文的 progressive techniques 按行叠加；「较上一行」是本页按相邻两行算的差值，不是原文的独立消融。

Naive GRPO → DAPO 共 +20 分（50 − 30）。每一行是在前一行基础上加一项，所以「+2」是 Clip-Higher 在这个顺序、这组数据上的边际结果，不是它单独的因果效应 推断（依据：Table 1 的 progressive 叠加结构）。

原文的主结果是 DAPO 50 对 DeepSeek-R1-Zero-Qwen-32B 47（§1、§4.2、Figure 1），但 47 来自另一套 R1 配方，50 来自 DAPO 的叠加配方，两者不是同一组控制变量。Table 1 内部是 progressive 叠加：naive GRPO 30 → 最终 50；50 与 47 的跨配方比较不能当成受控消融。

表 5（本页转录 DAPO §4.1）：复现实验设置。这些条件不能从数字里拆掉。

代码侧还有两个反直觉的「效果」：非有限 grad 不一定让训练挂掉——FSDP engine 会跳过这一步的 optimizer update（transformer_impl.py:765-769），所以日志里可能只有一行 WARN，曲线表现为「少更新了一步」；指标 NaN 不一定是数值爆炸——整批 abort 时 compute_data_metrics 会主动返回 NaN（score/reward：metric_utils.py:468-488；advantage：:490-499）。这两种情况都应该先看原始日志和 aborted ratio，再决定是否改算法。

什么时候别用这套二分：只有一条曲线、无法重放、或者把 OOM / 全 abort 当成算法坍塌。

• 没有通用的 entropy / 零方差百分比阈值。DAPO §4.3 只说 entropy 要维持在合适区间；verl 的过滤条件是精确 std==0（replay_buffer.py:312），不是「超过多少就报警」。先在自己的干净配置上量 baseline，再比较故障 run。
• DAPO 的四件套有明确条件。Qwen2.5-32B、长 CoT 数学、规则 reward、G=16、无 KL、prompt batch 512、εlow=0.2 / εhigh=0.28（§4.1；无 KL 见 §2.3；规则 reward 见 §2.4）。搬到 RLHF、agent 或不同模型规模前，要重新验证；Table 1 的 +8 也不是「开动态采样就一定 +8」。
• DeepSeekMath 的设置不同。G=64、KL 系数 0.04、max length 1024、batch 1024、每个探索阶段只更新一次（§4.2）。它的 Figure 7 是 Maj@K / Pass@K 的诊断，不是 collapse 的判定表；两篇论文的数字不能直接拼成同一组对照。
• OOM 不是算法坍塌。verl 文档把 micro batch 配置描述为「避免 GPU OOM」且「不应改变算法 / 收敛行为」（docs/algo/grpo.md:23；docs/start/quickstart.rst:157-162）。修 OOM 是恢复可训练性，不会修掉分布变窄。工程判断
• 全同组不一定是病。全对组通常说明这批题对当前模型太简单，或采样温度太低推断；DAPO §3.2 的动态采样会过滤它，代价是额外生成；过滤还会改变有效 prompt 分布（笔记的工程观察，不是 §3.2 原文结论）工程判断。DAPO 在其设置下报告收敛更快（Figure 6），这不等于所有数据分布都免费。
• 跳过 NaN 步不是修复。transformer_impl.py:765-769 的 zero_grad 只是防止坏更新写进参数；如果 WARN 连续出现，根因仍在概率口径、mask 或数值路径上。
• 两类会互相转化。Entropy collapse 的末端可能表现为 reward 断崖；训练崩溃也可能渐进（例如异步数据陈旧）。二分法是工作分类，不是定理；复杂情况按信号链一层层过 推断（依据：DAPO §3.1 的 collapse 现象与 verl 的工程故障点并不共享同一个时间尺度）。