GRPO训练技巧深度评测：40万GPU时消融实验的12项关键实践

1. 这篇评测到底测了什么

今年上半年我主要在做一件事：把账上能调度的 GPU 全部扔进同一条训练流水线，用 GRPO 给 LLM 做强化学习。这个系列的第二篇，我想写一写自己在烧掉近 40 万卡时之后真正沉淀下来的东西。不是把 GRPO 再从头讲一遍原理，而是把我在三篇论文复现和无数轮消融里反复验证过的 10 余项训练技巧逐条拿出来评测，说清楚哪些值得照抄，哪些是某些实验环境下的“局部最优”，哪些从一开始就不该碰。

先说一下这个体量。40 万 GPU 时听起来很吓人，摊到 32 张 H100 上大概也要连续跑两个多月。我复现的三篇论文，分别是 GRPO 原始出处论文、一篇以开放模型 RL 后训练为主线的工程报告、一篇以可验证奖励信号为核心的大规模消融实验。这三篇放在一起，基本覆盖了 GRPO 从算法到工程的所有关键分歧点。我把其中提到的技巧抽出来，用同一个基座模型、同一份 prompt 池、同一套评测集做消融，每次只改一个变量。这样做非常费钱，但只有这样才能把“真技巧”和“玄学”分开。

这段内容适合谁看？如果你已经在做 LLM 的 SFT，正准备往 RL 阶段走；或者你已经用 PPO 吃过一轮苦头，想换成 GRPO 但不知道哪些地方容易翻车，那这篇会有用。你不需要完整的 RL 论文基础，但最好知道 logits、token、KL 散度大概是什么。GRPO 的公式本身不难，难的是训练过程中那些不会写在论文里的细节。

先说一个整体结论：GRPO 能不能训练好，算法公式大概只占 30%，剩下 70% 是奖励设计、节奏控制、数值稳定性、采样策略这些工程细节。很多人把 GRPO 理解成“去掉 critic 的 PPO”，这句话对了一半。去掉 critic 确实能省显存、省时间，但同时也让 advantage 估计的方差变大。于是所有能压低方差、稳住分布的手段，都会成为真正决定训练效果的关键。

2. 评测方法论：不控制变量等于白测

2.1 评测协议与 40 万卡时的分配

这次评测并不是“把三篇论文的代码跑一遍就行”，而是把所有技巧拉到同一个标准线下做消融。基座模型固定为一个 7B 和 32B 的 Qwen 系模型，7B 用来跑快速消融，32B 用来做最终验证；prompt 池包含数学、代码生成和推理链路三类，总共约 5 万条。每次实验从同一个 checkpoint 出发，统一 rollout 温度、统一每步 prompt 数量、统一总优化步数，只改被测的那一个技巧。评测集用数学推理和代码生成的自定义 subset，每个配置至少跑 3 个 seed，最后取中位数。

40 万卡时里，约 33 万卡时花在三篇论文的复现和交叉验证，剩下 7 万卡时专门用来跑本文的额外消融。单个消融实验一般占 8 到 32 张 H100，跑 2 到 5 天。这个量级不是每个团队都能直接照抄，但读完之后你应该能判断哪些技巧值得花时间，哪些可以直接跳过。

评测指标没有只用 pass@1。我额外看了 pass@k、平均 response length、reward hacking 概率、训练中的 KL 散度和 GPU 利用率。有些技巧会把 pass@1 拉高一点，但会让 pass@k 坍缩；有些会让 reward 涨得很快，但抽出来看样本全是格式回复。只看一个指标很容易被误导。

2.2 本次评测的 12 项技巧清单

这项评测覆盖的技巧如下，后面每一节我会拆开细讲。

我最后把 12 项分成了三类：强烈推荐、看情况、不推荐。这个分类只代表我这三篇论文复现范围内的结论，不代表所有任务都适用。后面会说明为什么。

3. 十多项 GRPO 训练技巧逐项拆解与实测结果

3.1 Reference-Free KL：显存省了，但稳定性要付出代价

GRPO 原版的 loss 里有一项 β 乘以 KL 散度，用来约束新策略不要离 reference model 太远。这个 KL 项需要 reference model 的输出概率，在 32B 规模上相当于每次 update 都额外跑一次同规模 forward，算力成本不低。第一个让我纠结很久的技巧就是：能不能干脆不要 reference model，只用一个 entropy bonus 来替代 KL 约束。

我测下来，短任务、单步数学题是可行的，收益也不小，训练速度能提升 10% 到 15%。但长任务、多步推理和代码任务会飘，尤其是当训练进行到中后期，policy 产生大量重复、格式退化的样本时，没有 KL 项兜底，模型会非常快地掉进局部最优。我的结论是不推荐完全去掉 reference model，但也不需要用完整 reference forward 跑满全过程。可以在训练早期预计算 reference logprob 并缓存，每若干更新步刷新一次，这样 KL 估算会有轻微滞后，但稳定性明显比完全没有好。

另外，如果你的显存连 reference model 都放不下，我建议检查一下是不是 optimizer state 占了太多空间。冻结的 reference model 其实不需要 optimizer state，也不参与反向传播，可以利用这一点做显存分配，而不是一上来就放弃 KL 项。

3.2 组内 Advantage 归一化：减均值还是做 z-score

GRPO 和 PPO 最大的区别在于 advantage 不是来自 critic network，而是来自同组样本之间的相对比较。最早的写法是(reward - group_mean) / group_std，也就是组内 z-score。这个公式看起来简单，但实际跑的时候很容易踩坑：当一组样本全部正确或全部错误时，group_std 是 0，advantage 要么全是 0，要么会变成无穷大。很多人用NaN排查了半天，最后才发现是这里出了问题。

我后来改成减均值之后对 std 做下限处理，也就是std = max(std, 1e-4)。这个改动在二值 reward 场景下非常重要，因为规则判分的 reward 通常只有 0 和 1，很多 group 的 std 天然偏小。只减均值不除 std 也能跑，训练更稳，但收敛会变慢。用连续 reward 或 LLM judge 的分数时，z-score 的优势会更明显，但必须配合后面说的 advantage clip，否则一个异常高分样本会把整轮参数推偏。

如果你用的是二值 reward，我推荐减均值加 std floor。如果你是做分步判分、分数范围很大，那么 z-score 加 clip 是更好的组合。

3.3 奖励设计：长度惩罚和格式惩罚不能省

三篇论文里有一个共识：规则判分优先于 LLM-as-judge。在数学数据集上，我直接用正则提取最终答案，再用符号化简做判分；在代码任务上，直接编译加单元测试。这个改动把 reward 相关成本降低了 90%，同时把 reward hacking 概率压下去很多。LLM judge 不是不能用，但很适合被模型钻空子：模型会学会输出一些看似合理但实际无效的内容来骗高分。

比判分方式更影响训练的是 format reward 和 length penalty。RL 前期模型要先学会输出可解析格式，否则规则判分算出来的 reward 全是 0，训练没有任何梯度。我的做法是给格式正确但答案错误的样本一个很小的负奖励，给格式错误的样本更大的负奖励，让模型在探索答案之前先把格式学会。

Length penalty 我默认设置是超出最大长度后，每多 32 个 token 扣 0.05。这个值不能拍脑袋定，否则模型会走向另一个极端——输出越来越短，最后变成一两行的摆烂答案。我之后加了一个最小长度约束：低于某个长度直接置零 reward，逼着模型至少写够一段完整推理。实测下来，这个组合能显著减少 response length 的坍缩。

3.4 Response-Only Token Advantage：一个隐蔽但重要的 mask

很多 naive 实现会把 advantage 广播到整个序列的每个 token，包括 prompt token。第一眼看上去没问题，因为 loss 是只对 response token 算的，但有些框架在实现时会把 prompt mask 漏掉，导致 prompt token 的 logits 也被梯度推动。这个影响很隐蔽，不是每次都能观察到，但我的消融显示：只对 response token 算 loss 的版本，数学子集 pass@1 能涨 2 个点左右，而且训练过程更稳定。

为什么 prompt token 不应该收到 advantage？因为 prompt 是模型看到的外部输入，不应当直接被策略梯度修改。如果强行让 prompt token 也走向高 reward 方向，模型会对 prompt 的表面形式产生过拟合，真正要学的是 response 的推理能力反而会被稀释。实现上只需要在 per-token logps 上乘一个 response mask，然后只对 masked positions 求平均即可。

我后来实验过一个小变体：训练最开始的前 20 步，给 prompt token 加一点熵正则，帮助它在 rollout 过程中保持多样性，之后关掉。这个变体谈不上显著提升，但也没有副作用，有兴趣可以试。

3.5 Group Size G：方差与训练成本之间的真实平衡

Group size 是 GRPO 最直观的超参数。每个 prompt 采样 G 个 response，再在这 G 个 response 里计算相对优势。理论上 G 越大，优势估计方差越低。但我实测下来 G=16 相比 G=8 的提升只有 0.5 个点左右，而 rollout 成本直接翻倍。G=4 在简单数学题上也能跑，但训练后期 pass@k 会明显变差，尤其是面对组合性较强的推理问题时。

更关键的是 prompt batch size。有些人只盯着 group size，忽略了同一个优化 step 里要有足够多的 prompt。如果只拿 16 个 prompt，每个 prompt 生成 8 个 response，那么一个 step 只有 128 个样本，优势统计意义很差。我这边每次优化 step 至少覆盖 256 到 512 个 prompt，先把 prompt 数量提上来，再考虑要不要把 G 从 8 提到 16。

如果你用的是 LLM judge 这类 noisy reward，那么 G=16 是更合理的选择，因为 judge 分数本身的噪声很大，组内样本少了压不住方差。如果用的是规则判分且任务边界清晰，G=8 就是我的首选。

3.6 Policy Clip 与 Advantage Clip：两层防护缺一不可

GRPO 没有 value network，所以没有 PPO 那一套 value clip，但 policy ratio clip 必须要做。ratio 是当前策略和旧策略的 logprob 差值取指数，如果这个值不加以限制，单次更新很容易把模型推过头。我测了 0.1、0.2、0.3 三档，0.2 最稳。0.1 太保守，训练收敛明显变慢；0.3 早期上升快，但经常在后期出现 loss 反弹。

Advantage clip 是另一层防护，经常被人忽略。z-score 之后的 advantage 已经做了归一化，但碰到极端高分或极端低分样本时，归一化后的数值仍然可能非常大。我会在 z-score 之后再 clamp 到 ±5 或 ±3。二值 reward 场景用 ±5 就够，连续 reward 和 judge reward 用 ±3 更稳。注意顺序：先归一化再 clip，最后才能乘到 per-token logprob 上。如果顺序反了，clipping 会把 reward 本身的真实差异也磨掉。

3.7 Minibatch 与梯度累积：GRPO 工程落地的第一道坎

40 万卡时实验里，最折磨人的其实不是算法，而是长序列内存爆炸。一个标准的 GRPO 训练 step，会把 prompt 和 response 拼成一个很长的 batch，然后在策略模型上做 forward 和 backward。response 一旦超过 2000 token，8B 模型还能勉强撑住，32B 模型直接 OOM。

我最后用的是 minibatch 加梯度累积。先在一个较大的逻辑 batch 上计算 advantage，拆成多个 micro-batch 做 forward 和 backward，梯度累积一定步数后再更新参数。micro-batch 的分法不按样本数量，而是尽量让每个 micro-batch 的总 token 数接近，避免有的 micro-batch 特别长、有的特别短。grad clip 建议固定在 1.0 到 2.0，GRPO 的 advantage 来自组内比较，天然会有 outlier，不 clip norm 会把权重推飞。

关于 sequence packing，我测过，确实能提升吞吐，但 block-diagonal mask 和 response 边界处理非常容易出错。如果你的序列长度方差太大，packing 的收益才值得做；大多数场景下把 max response length 限制住其实更省事。

3.8 Prompt 难度课程：什么时候该给模型“上难度”

Reinforcement Learning 不是永远都要“越难越好”。很多人把 SFT 数据直接拿来做 RL，里面大量样本模型已经能答对，GRPO 里这些样本的 advantage 全为 0，等于白跑。我改成了按当前 checkpoint 的 pass@1 给 prompt 分档，采样权重为 easy:medium:hard = 1:2:3。pass@1 可以 rollout 时直接从 reward 里统计，不需要额外推理。

这个技巧在中等难度任务上效果明显，能减少约 20% 的训练步数。但在统一难度的 benchmark 上优势不明显，反而容易因为 hard 样本比例过高导致 loss 过大，模型崩掉。所以 curriculum 一定要配合 KL 约束一起用，hard 样本比例不要一次性拉得太高。比较好的做法是让 hard 比例线性慢慢增加，而不是第一步就直接 80% hard。

Prompt 质量比数量更影响最终效果。把那些重复度过高、模板化严重的数据在进 RL 前清洗掉，比后期调任何超参数都有效。

3.9 Entropy Bonus 与温度退火：防止模型过早变成复读机

RL 中后期模型很容易出现分布坍缩，尤其是 reward 信号集中在某一种正确格式上时。policy 的 logits 会变得越来越尖峰，pass@k 掉得很快。我在 loss 里加了一个小 entropy bonus，系数 1e-4 到 1e-3，让 response token 的分布不要过早坍缩。这个技巧不会显著改变最终 pass@1，但对 pass@k 和样本多样性有很大帮助。

另一个更实用的做法是调整 rollout 温度。很多复现默认温度 0.7，但我在训练中期会把温度调到 0.9，让模型多一些探索空间。注意 rollout 温度和 update 时 per-token logprob 要分开记录，不要因为采样温度变了就把策略梯度里的 logprob 也跟着改。如果模型已经开始出现大规模重复输出，先别急着加 entropy，先检查 reward 是不是只剩格式分，真正的答案 reward 已经失灵了。

3.10 学习率与 KL 系数调度：不能从头到尾用一个数

固定学习率跑完整轮并不理想。我用的是 cosine schedule，32B 全参训练时峰值学习率大约是 5e-7 到 1e-6；7B 可以放大到 1e-6 到 2e-6。warmup 不用太长，20 到 50 步即可。更关键的是 KL 系数 beta。固定 beta 经常出现一个现象：训练早期 KL 冲到 0.1 以上，后边又降得非常低，模型开始放飞。

我参考自适应 KL 的做法，每 20 个 batch 统计平均 token-level KL，如果超过 0.08，就把 beta 乘 1.2；如果低于 0.01，就乘 0.8。这个规则极其简单，但几乎不需要再调参，强烈推荐。它虽然没有论文里那些漂亮的理论解释，但在实操里非常稳定。GRPO 的 KL 项不是装饰品，它是整个训练能否长期跑下去的刹车。

4. 实操：一套可改写的 GRPO 训练代码骨架

4.1 整体架构：Rollout 与训练解耦

在实际工程里，GRPO 至少要拆成两个进程。一个是 rollout engine，我用 vLLM 做批量采样，负责从当前 policy 生成 response 并统一判分；另一个是 trainer，负责在累积好的 rollout 数据上做策略更新。这两个进程不能塞在同一张卡上，否则 rollout cache 和 optimizer state 会互相抢显存。

架构上我会让 rollout 和 trainer 异步：trainer 在更新参数时，rollout engine 拿着旧参数继续采样。step 之间通过共享的 rollout buffer 传递数据。这个异步程度不需要太大，提前一个 batch 就够了，再大反而会让策略更新滞后，影响 advantage 计算的质量。

4.2 Advantage 计算的核心代码

所有 GRPO 实现到最后都会落到这段逻辑上，我把它单独抽出来讲。

import torch def compute_group_advantage(rewards: torch.Tensor): """rewards shape: [num_prompts, group_size]""" group_mean = rewards.mean(dim=-1, keepdim=True) group_std = rewards.std(dim=-1, keepdim=True) # 避免 group 内 reward 全相等时出现除 0 group_std = torch.clamp(group_std, min=1e-4) advantages = (rewards - group_mean) / group_std # 抑制极端样本带来的梯度噪声 advantages = torch.clamp(advantages, -5.0, 5.0) return advantages.flatten()

这个版本适合二值 reward。如果你用的是连续 reward 且分数范围很大，可以把 clamp 改成 ±3。千万不要在 std 为 0 时直接返回 0，这样会把一批还有学习信号的样本完全浪费掉。

4.3 策略更新的核心代码

策略 loss 的写法基本是一段标准代码，但有几个地方非常容易写错。

def compute_policy_loss( logprobs, # 当前 policy 的 per-token logprob old_logprobs, # 采样时记录的 old logprob advantages, # shape 与 group 中每个样本对应 response_mask, # 只保留 response token clip_range=0.2, entropy_coef=0.001, ): ratio = torch.exp(logprobs - old_logprobs) clipped_ratio = torch.clamp(ratio, 1.0 - clip_range, 1.0 + clip_range) # advantage 需要广播到每个 token adv = advantages.unsqueeze(-1) loss = -torch.minimum(ratio * adv, clipped_ratio * adv) loss = (loss * response_mask).sum() / response_mask.sum() if entropy_coef > 0: entropy = -torch.exp(logprobs) * logprobs entropy_loss = (entropy * response_mask).sum() / response_mask.sum() loss = loss - entropy_coef * entropy_loss return loss

写这段代码时最容易翻车的是old_logprobs没做 detach。old_logprobs虽然是采样时算的，但如果你把它接到当前计算图上，backward 时梯度会一路传回去，整个 loss 全乱。另一个容易翻车的是response_mask的 shape 和 logprobs 不一致，尤其是做了 sequence packing 之后，mask 经常错位。

4.4 训练超参参考基线

最后给一个我实际使用过的基线配置，可以直接作为起点。

这只是起点，不是圣旨。如果你跑 1B 或 70B 模型，数值都要重新调。GRPO 对超参数不算特别敏感，真正的坑更多出现在 reward 函数和 mask 处理上。

5. 常见问题与排查技巧实录

5.1 OOM 问题排查清单

GRPO 训练最常见的第一大问题是显存溢出。记录一下我排查的顺序：先看是不是 response 太长，把 max response length 往下压；再看是不是 reference model 和 policy 同时占显存，检查 reference 是否可以用缓存 logprob 替代；接着看 optimizer state，是不是用了全参数 AdamW 32B 模型，这个状态本身可能比模型权重还大。

最后再看 rollout engine 和 trainer 是不是被安排到了同一张卡上。做异步 rollout 时，这个情况非常普遍，最后通常要独立分配 rollout 卡，而不是让两者共享。如果你的模型是 32B、max response length 是 3072，那至少需要 80GB 级别的显存才能舒服地跑起来，8B 模型在 24GB 卡上配合 CPU offload 也能勉强跑通。

5.2 Reward Hacking 的常见套路与对策

模型非常擅长找 reward 的漏洞。我见过最典型的是：数学题里模型直接输出\boxed{}空框，parser 提取答案时空字符串被判错，但格式分拿到了；代码题里模型输出一段和题目完全无关的伪代码，但只要 test case 通过，reward 就是满分。这些问题共同点是 reward 信号没有把“答案合理性”纳入进来。

我的对策是把 reward 函数用一个离线数据回放脚本先测一遍：拿一批训练中期样本，人工标好正确 reward，再跑 reward pipeline，看有多少不一致。这个环节不要省，reward function 写错一次，浪费的 GPU 时数以万计。另外，训练过程中要持续抽样本看格式分布，一旦发现模型学会了用固定模板刷 reward，立刻加强格式惩罚或降低 format reward 的权重。

5.3 NaN / Loss 突刺的排查

GRPO 的 NaN 大多来自三个地方：logprob 在 bf16 下数值溢出；group_std 为 0 时做了除法；ratio 的指数运算出现极端值。我的习惯是所有 logprob 计算和 loss 累积都保持在 fp32，模型 forward 内部可以用 bf16 加速，但涉及概率计算的部分不降精度。advantage clip 和 ratio clip 必须是默认操作，不是可选项。

如果训练中期出现 loss 突刺但没到 NaN，先看 KL 是不是在一两个 step 内快速上升。如果是，说明 policy 更新过大，把学习率降一半，或者自适应 KL beta 的上限调高一些。还有一种情况是某个异常长样本带了非常大的 advantage，梯度累积时把它单独 push 出来，改用 advantage clip 就行。

5.4 训练吞吐与 GPU 利用率低

GRPO 的 GPU 利用率通常不会像 SFT 那么高，因为 rollout 阶段本身不是满计算量。最常见的问题是 response 长度方差太大，短的只有几百 token，长的到 3000，vLLM 的 dynamic batching 容易产生气泡。我推荐在 prompt 进入 rollout 前，按预估 response 长度做分桶，同一桶内一起采样，减少相互等待。

另一个吞吐瓶颈是 rollout 和 trainer 完全串行。更新一版参数后，等 rollout 全部完成再开始下一步，中间浪费的时间非常长。一定要做成异步 pipeline：trainer 的 current batch 更新到一半时，rollout engine 已经拿着旧参数采下一批数据了。这个优化不会改变训练结果，但在 40 万卡时的量级下，可以把总墙钟时间缩短 20% 以上。

6. 我实测后保留的几个习惯

这一节算是私货。烧了这么多 GPU 之后，我留下来几个并不在论文里的小习惯。

第一个是每天不看 loss，而是抽 20 组样本看最终答案。RL loss 是个很平滑的曲线，它下降不代表模型真的在变好，有时只是 format reward 在涨。直接看输出会更容易发现问题。

第二个是所有 reward 函数必须先做离线回放测试。把历史 rollout 数据保存下来，验证 reward pipeline 的每一层是否符合预期，再上线。GRPO 的实验周期很长，reward 写错的代价是所有技巧里最昂贵的。

第三个是记录 group_std 和 token-level KL 的变化曲线。group_std 长期接近 0，说明数据太简单或者 reward 信号失效；KL 快速拉高，说明策略更新过猛。这两个指标比 loss 更能提前预警训练崩溃。

第四个是不要迷信“去掉 reference model”。省下那点显存和算力，通常会在训练中后期以更长的调参时间还回去。KL 项是 GRPO 的刹车，刹车不是限制能力，而是保证车能开得更远。

GRPO 的门槛没有想象中那么高，但每个选择都会在后续训练里被放大。把基础变量控制住，再考虑花活，这是我烧完 40 万卡时之后最想对训练新人说的一句话。