GRPO训练技巧深度评测：哪些是必须，哪些是过度设计？

GRPO 训练技巧这个话题，最近热度真的高。大模型 RL 领域里，Group Relative Policy Optimization 几乎已经成了推理训练的标准底座，但真正让一线团队头疼的不是算法本身跑不跑得起来，而是围绕算法衍生出的那一堆“进阶技巧”——KL 系数怎么调、奖励要不要裁剪、组内样本采多少个、温度该设多少、长度惩罚加不加、梯度裁剪开不开。每一条都有人说得信誓旦旦，每一条也都有踩坑翻车的案例。

我集中梳理了三篇不同团队做的消融评测工作，合计覆盖了十余项 GRPO 训练技巧。三篇工作的评测视角不太一样，但结论收敛得很有意思：大部分我们视为“必须”的复杂技巧，在严格控制的对比实验里并没有带来显著性提升；真正影响训练效果的，其实就那么几个基石，外加少数组装技巧。这篇文章就把评测方案、逐项结论和我在实际工程中的选择逻辑完整整理一遍，希望能帮你少走一点弯路。

1. 先搞明白：GRPO 为什么值得做技巧评测

1.1 GRPO 的原理与核心优势

GRPO 的全称是 Group Relative Policy Optimization，翻译过来就是组相对策略优化。它在 DeepSeek 的一些推理模型训练中被带火之后，社区里几乎把它当成了 PPO 的平替。两者的核心差别其实很朴素：PPO 需要额外训练一个 critic 网络来估计状态价值函数，也就是一个“打分老师”，每个动作之前都得问一下老师“这一步值多少分”；而 GRPO 直接把同一个 prompt 采样的 N 条 response 当成一个小组，用这 N 条 response 的奖励相互比较，减去组内均值再除以组内标准差，得到每个样本的相对优势。

这个设计有三点很实际的好处。第一，省掉了 critic 网络，训练时显存占用低一截，这对 7B 以上模型的 RL 训练非常友好。第二，critic 网络本身也是要训练的，它不准确的时候会引入价值估计偏差，GRPO 绕开了这个误差源，反而稳定一些。第三，组内相对比较天然消掉了奖励模型的绝对尺度影响，比如某个 reward model 整体给出的分数偏高或偏低，只要组内排名关系没有变化，advantage 基本不受影响。

但这里就引出一个有意思的问题：既然 GRPO 已经通过组内比较解决了很多 PPO 时代需要额外技巧去处理的问题，那为什么社区里还流传着这么多“必须加的技巧”？这正是三篇评测工作想要回答的。

1.2 为什么会有这么多“训练技巧”？

回头去看开源社区的复现过程，很多技巧其实是带着历史包袱进场的。一部分是从 PPO 时代沿袭下来的习惯，比如 ε-clip、优势归一化、reward clipping，这些东西在 PPO 里有明确的作用，但换到 GRPO 之后是不是还必要，很少有人认真做对照实验。另一部分是针对特定任务产生的 workaround，比如某个模型训练时疯狂输出长文刷分，然后就有人加了长度惩罚，这个技巧在当时的任务上确实有效，但放到别的任务上就未必。

还有一部分则是纯粹的“玄学调参”。模型不收敛的时候，大家第一反应是去调 β、调温度、调 clip 范围，调完以后指标确实动了，但没人知道是参数本身起作用，还是随机种子引起的波动。三篇评测工作的出发点都是一样的：把这些技巧逐个做开关实验，控制其他条件完全不变，用多次重复实验排除随机性，然后看最终的指标变化是否统计显著。

这里我要说一句大实话：评测技巧的必要性，比很多人想象中要难得多。因为单次训练成本高、随机性大，如果在单一任务上只跑一次实验就下结论，基本等于抛硬币定结论。三篇工作的共同优点，就是都比较认真地处理了这个问题。

2. 三篇论文的评测方案到底怎么设计的

2.1 三篇工作的研究视角各不相同

先说一个我的整体印象：这三篇工作恰好代表了评测 GRPO 技巧的三个层次，合在一起看信息量比单独看任何一篇都大。

第一篇偏纯消融，核心方法是把每一项常用技巧当作一个开关，逐个关闭或者打开，然后看单一任务指标的变化。它覆盖的技巧数量最多，基本把社区里流传的“必备技巧”一网打尽，用的是 7B 量级的基座模型，任务集中在数学推理和指令遵循上。它的优点是控制变量做得干净，缺点是任务面相对窄，有些结论未必能迁移到代码生成或者自由对话场景。

第二篇偏训练稳定性分析，它的切入点不是最终指标，而是训练过程中的 KL 散度、策略熵、梯度范数、reward 曲线形态。它提出了一个很有价值的观点：很多技巧对最终收敛精度影响不大，但对训练过程的稳定性影响很大，而稳定性又会直接影响 checkpoint 的选择难易度——如果你的训练曲线剧烈震荡，你很难判断第几个 epoch 的模型适合做 final checkpoint。这篇工作更偏工程实践，读起来特别有共鸣。

第三篇做的是跨模型规模、跨任务类型的验证。它在 1.5B、7B、14B 三个量级的模型上跑同一组技巧开关，任务覆盖数学、代码和通用对话。它的结论是最有参考价值的：技巧的有效性高度依赖基座模型的 SFT 质量和任务类型。换个说法，某些技巧在小模型上有效，在更大模型上反而没意义；在数学任务上有效的技巧，在通用对话上可能是负优化。

2.2 评测基线、任务与对照组设计

三篇工作的基准设置大同小异，这也是它们结论能互相映证的前提。

基座模型一律使用完成 SFT 后的模型，不直接拿预训练模型做 RL，因为 GRPO 需要模型已经具备一定的指令跟随和格式生成能力。参考模型则直接使用同一个 SFT checkpoint，冻结之后用来计算 KL 散度。

任务选择上有一个共同标准：必须用可自动评估的指标。数学推理用的是答案验证或公式等价性判断，代码生成用的是单测用例通过率，通用对话则通过一个独立的奖励模型打分。选任务时有一个隐性要求——不能只用那种奖励函数本身能完全刻画的任务，否则评测的其实是奖励函数的设计水平，而不是 GRPO 训练技巧本身。

对照组设计方面，三篇工作都遵循“一次只动一个变量”的原则。比如测温度策略时，组大小、β、学习率、梯度裁剪、训练步数、随机种子全部固定；测组大小时，温度和其他超参数一律不动。这个原则看起来很简单，但实际操作中特别容易破功，因为改一个参数经常会连带影响训练步数、batch 配置、显存利用率，有些团队图省事就顺手改了别的设置，对比实验就不干净了。

2.3 统计有效性与计算成本

第三层是统计显著性处理。数学推理和代码生成任务的评估方差其实不小，同一个 checkpoint 在不同随机种子下训练，最终指标能差出 3 到 5 个百分点。如果评测时只跑一次实验，一个技巧带来的 1 个百分点提升完全没有说服力。

三篇工作都做了多次种子重复，并报告均值加标准差。其中一篇还额外做了一个很有参考价值的分析：如果只看单次实验，大约有接近一半的“技巧有效”结论是非显著的；但把重复实验做起来之后，真正稳定的技巧只剩几个。换句话说，坊间流传的很多“必加技巧”，有很大概率是单次实验运气好造成的误判。

代价就是计算成本很高。据我估算，这三篇工作的总计算量大约相当于几万张卡时的规模，个人开发者很难完整复刻。但好在我们不需要自己跑这么大规模的消融，直接借鉴它们的结论做工程选型就够了。

3. 10 余项 GRPO 训练技巧逐项拆解

这一部分是全文的重头戏。我不是简单罗列技巧，而是把每一项的提出动机、实现方式、评测结论和工程判断放在一起讲清楚。

3.1 约束与正则类：KL、奖励裁剪、长度惩罚

**KL 散度约束（β）**是 GRPO 里最核心的约束项。实现上，策略模型每个 token 输出的分布要和参考模型的输出分布计算 KL 散度，然后乘上一个系数 β 加进损失函数。它的作用是防止模型在 RL 训练中偏离初始 SFT 模型太远，从而保护输出的可读性和多样性，避免模型为了刷 reward 而彻底放飞自我。

三篇评测对这个技巧的结论非常一致：KL 约束必不可少，去掉之后模型大概率在几十步内进入 reward hacking 状态，具体表现是输出变成无意义的格式花样。β 的取值比是否加 KL 约束更重要。乙类的 β 范围通常在 0.01 到 0.1 之间，具体要看奖励模型的尺度。有一个简单的对齐技巧：先跑一小段步数，观察 KL 散度的增长速度，如果 KL 在几百步内涨到 2 以上，β 大概率偏小了；如果 KL 始终压在 0.1 以下，β 可能偏大导致学习过慢。

**奖励裁剪（reward clipping）**是 PPO 时代的常见做法，把 reward 限制在某个区间内，防止极端值主导梯度。但 GRPO 的 advantage 是组内相对值，天然对 reward 的绝对尺度不敏感。三篇工作的评测结论是：在数学推理和代码生成任务上，reward clipping 不仅没有带来稳定的正向收益，反而在部分任务上让指标轻微下降。原因是裁剪操作本身损掉了奖励的排序信息——本来两个样本的 reward 差距是 10 倍，裁剪之后差距缩小，组内优势的区分度就下降了。

这并不意味着 reward clipping 完全没用了。如果某个任务的 reward model 存在偶发极端值，比如出现几百倍的异常高分，那么组内 z-score 计算会被这个异常值主导，其他样本的优势几乎全部变成负的。这种情况下裁剪是有价值的。所以我的结论是：默认不裁剪，除非你的 reward 分布确实存在病态长尾。

**长度惩罚（length penalty）**是社区里最常被过度使用的技巧。提出动机非常实际：很多奖励函数与输出长度存在隐式耦合，模型学到“多写就能多得一点分”之后，就会疯狂堆字数，训练时间变长、推理延迟变高。长度惩罚就是在 reward 上减去一个与长度成正比的项，抑制这个趋势。

评测结论比较微妙：长度惩罚在代码生成任务上有效，因为有单测用例，输出越长不一定越对，反而容易引入更多错误；但在数学推理任务上效果不稳定，因为某些数学题的中间推导步骤确实越长越充分，惩罚太强会让模型放弃必要的推理过程。工程上的建议是分两步走：先训练一个不带长度惩罚的版本，观察响应平均长度的变化曲线，如果长度膨胀超过正常水平的 20%，再考虑加一个温和的惩罚项，系数从低往高调。

3.2 训练动态类：梯度裁剪、学习率调度、EMA、熵奖励

**梯度裁剪（gradient clipping）**在 GRPO 训练中的价值被三篇工作一致认可。RL 的 loss 面比 SFT 陡峭得多，尤其是 KL 约束失效或者优势估计出现极端值时，梯度范数可以轻松翻几倍。如果不加裁剪，一个 batch 的异常数据可能把模型权重推出正常区域，后面几十步都在修复。三篇评测里做了裁剪阈值 0.5、1.0、2.0 和无裁剪的对照组，结论是无裁剪在全部任务上都出现了不同程度的训练崩溃或指标震荡。

我用一个词形容梯度裁剪的性质：免费保险。它的实现成本几乎为零，对最终指标没有明显副作用，但在训练稳定性上的收益非常确定。所以无论你的基线配方多精简，这一项我建议默认打开。

学习率调度是一个有意思的争议点。SFT 阶段几乎所有团队都用余弦退火或 warmup 加线性衰减，大家把这个习惯也带到了 RL 阶段。三篇工作分别比较了恒定学习率、余弦退火、cosine with restarts 三种策略，结论是：在 GRPO 训练中，恒定学习率的表现并不比余弦退火差，部分任务上反而略优。

原因在于 SFT 和 RL 的目标函数性质完全不同：SFT 是对静态数据集做损失优化，后期用小学习率微调是有利的；而 RL 训练中数据分布和策略分布同时在演化，后期过早把学习率降下去，会让策略失去对采样分布的适应能力。如果你用的是标准 GRPO，我建议先用恒定学习率配合梯度裁剪跑一个短实验，如果训练曲线不够平滑，再换余弦退火不迟。

**指数移动平均（EMA）**是一种常见的模型权重平滑手段，做法是维护一份权重参数的滑动平均版本，每个训练步用新权重和历史平均权重做加权合并，最终评测用 EMA 后的权重。三篇评测对 EMA 的判断比较分化：第一篇认为 EMA 对最终 benchmark 指标影响很小，第二篇认为 EMA 最大的价值不在指标，而在 checkpoint 选择的鲁棒性——特别是在训练后期震荡明显时，EMA 版本的权重普遍没有出现灾难性遗忘。

我的判断是：EMA 不是必需品，但如果你被“训练曲线震荡导致 checkpoint 选择困难”这个问题困扰过，加上它很值。注意，EMA 应该和原始权重并行维护，评测时两个版本的指标都要记录，不能直接默认 EMA 更好。

**熵奖励（entropy bonus）**是对抗策略熵崩塌的常用手段。模型训练久了之后，输出分布会越来越极端，几乎每次采样都生成相同套路的内容，这就叫熵崩塌。熵崩塌的坏处是探索能力下降，同时模型对训练数据的覆盖变窄，泛化能力受损。熵奖励就是在损失函数里加一个与策略熵成正比的项，鼓励模型保持一定的输出多样性。

三篇评测的结论是：由于 GRPO 的 KL 约束本身就在保护模型的输出分布，熵奖励的边际价值比在 PPO 里要小。只有当采样温度偏低、组内多样性不足导致 advantage 区分度差的时候，熵奖励才体现出正向作用。所以建议把它作为一个监控指标而非默认损失项：实时关注策略熵曲线，如果熵在训练后期塌到初始值的 30% 以下再考虑加。

3.3 采样与组设计类：组大小、温度、动态过滤

组内采样数量 G是 GRPO 特有的超参数，直接决定 advantage 估计的稳定程度。G = 4 时，组内只有 4 个样本参与均值与标准差计算，估计的方差偏大；G = 64 时，估计方差很小，但计算成本呈线性上涨。三篇工作都做了 G 的阶梯评测，结论高度一致：G 从 4 提升到 8 带来的收益在数学任务上很明显，从 8 到 16 仍然有正向收益，但幅度缩小；从 16 到 32，大多数任务只看到零点几个百分点的变化，完全不值得翻倍的采样成本。

这里有一个重要的工程解释：G 越大，不仅能降低 advantage 估计的方差，还能提高奖励模型排序的置信度。但同样的 prompt 生成 32 条 response 时，很多 response 在语义上是重复的，边际信息增益很低。所以组大小的甜点区间基本在 8 到 16，如果显存紧张，取 8 是足够稳妥的起点。

采样温度是一个经常被忽略、但对训练影响极大的参数。很多人直接把推理时的默认温度 0.7 搬过来用，这其实是有问题的。GRPO 的探索机制完全依赖组内采样的多样性：如果温度太低，组内样本的差异变小，advantage 的区分度变差，模型很难学到稳定的偏好信号。

评测结果显示，温度在 0.9 到 1.2 之间时，组内多样性最健康，训练收敛速度更快；低于 0.6 时，训练曲线明显变慢，最终指标略降。温度超过 1.5 时，虽然探索性更强，但低质量样本占比增高，训练噪声变大。所以采样温度建议不要低于 0.8，同时要把温度与 G 联动考虑——温度低时适当增大 G 来弥补多样性。

**低质量样本过滤（动态采样策略）**是高阶技巧里很有争议的一项。具体做法是：训练过程中实时计算每个 response 的奖励，如果低于某个阈值就直接丢弃，不参与 advantage 计算，理由是低质量样本会给策略带来噪声更新。

评测结论很有意思：过滤策略在训练早期有一定帮助，能加速第一个阶段的学习；但随着训练推进，它的副作用逐渐显现——过滤掉的样本中往往包含那些“答对了但过程复杂长尾”的困难样本，模型会越来越回避困难问题，最终在更难的任务上表现平庸。在数学任务上，持续开启过滤的模型最终准确率比关闭过滤的平均低 1 到 2 个点。所以我对这项技巧的建议是：如果你想用，只在训练前 20% 的步数内启用，并且过滤阈值要设得非常温和，宁可漏掉噪声，不要误伤困难样本。

3.4 损失目标变体：优势归一化与 ε-clip

全局优势归一化指的是在梯度更新之前，对 batch 内所有组样本的 advantage 再做一次整体归一化。有团队认为这能消除 batch 之间的随机波动，让训练更平滑。但 GRPO 的 advantage 本身已经在组内做了 z-score 标准化，再做一层全局归一化等于是对已经标准化过的分布再变换一次。

评测结论非常明确：全局优势归一化没有带来稳定的收益，甚至在部分任务上降低了训练速度，因为二次归一化缩小了组间差异，某些本应获得更大更新步长的样本被压回去了。我理解这个技巧的流传背景：它是从 On-Policy 算法的工程经验里带过来的。但标准的 GRPO 实现中，组内归一化已经足够，没必要再加一层。

ε-clip同样是 PPO 遗产。PPO 用重要性采样 ratio 配合 clip 窗口来限制单次策略更新幅度，防止大步更新导致策略崩坏。GRPO 虽然也常被套上 PPO 风格的损失函数，但它的样本是当前策略即时采样的，近似 on-policy 的更新方式让 clip 的约束意义减弱了很多。

三篇工作的评测集中在同一个关键问题：“clip 参数在 GRPO 中的作用是什么？”结论是：如果每个 batch 只更新一次就重新采样，ε-clip 的影响几乎可以忽略；但如果你的实现里对同一批样本重复使用多次更新（比如 2 到 4 个 epoch），clip 就会变得很有必要。也就是说，它的必要性取决于你的数据复用策略，和 GRPO 本身关系不大。工程上更干净的做法是：除非你的显存条件强迫你复用 batch，否则坚持每个 batch 只更新一次，这样就完全不需要 ε-clip。

4. 评测结论：哪些技巧其实是过度设计

4.1 真正必要的三块基石

综合三篇工作的结论，真正能称为“基石”的只有三块。

第一是 KL 散度约束。它不只是保护生成质量的保险，更是平衡探索与利用的核心机制。没有它，GRPO 的收敛稳定性会显著下降。第二是合理的组大小与温度设置。采样策略直接决定了 advantage 的质量，这是 GRPO 的信息源头，源头质量不高，后面所有组件都很难补救。第三是梯度裁剪。它花不了多少算力，却能实实在在避免训练崩溃的常见风险。

有意思的是，这三块基石都不需要复杂实现，每一个都是训练框架默认配置里的选项。复杂性并不是必要性的同义词——大多数提升收益来自这些基础设对之后带来的稳定性，而不是某个损失函数的花样变形。

4.2 有条件适用的辅助技巧

除了基石之外，还有几个技巧属于“条件适用”，按需启用就好。长度惩罚适合在明显出现“话痨病”的任务里使用，比如代码生成和部分文本摘要任务；EMA 适合在训练曲线震荡、checkpoint 选择困难时使用；熵奖励适合在监控到策略熵异常下降时补充；采样温度需要结合组大小一起调，这是训练早期就应该确定的参数，不太适合训练中途频繁变动。

这些技巧的共性特征是：不加也不会崩，加对了能赚一点，加错了反而赔。所以我不建议一上来全部打开，而是先跑一个干净基线，根据监控指标再决定加哪一项。

4.3 可以直接从基线里划掉的技巧

按三篇评测的累计结果，我建议直接从默认基线里划掉这些：reward clipping（除非 reward 有病态极端值）、全局优势归一化、ε-clip（在你保证单次更新的前提下）、持续性的低质量样本过滤。这些技巧的共同问题不是完全无效，而是收益不稳定、偶尔有害，且增加了实现复杂度和超参数数量。每多一个可调旋钮，就多一个踩坑的可能。

我特别想强调“实现复杂度”这个维度。评测论文关注的往往是指标差异，但工程团队还要考虑维护成本。一个技巧引入之后，它的超参数需要在每次换模型、换任务时重新调，这个隐性成本比一次实验里的 1 个点指标提升要大得多。所以我的工程默认值是“能不加就不加”，直到有明确信号说明必须加。

5. 实用基线配方：给工程团队的最小可行方案

说了这么多评测结论，最终要落地到训练配置里。我给出一个结合三篇评测结论和实际工程经验的最小可行方案，适合 7B 到 14B 量级的模型在数学或代码任务上做 RL。

基座模型使用 SFT 后的 checkpoint，参考模型为同一 checkpoint 的冻结副本。组大小设为 16，采样温度 1.0，解码时使用 top_p 0.95，最大生成长度按任务类型设置为 1024 或 2048。KL 系数 β 从 0.04 起步，训练初期跑 200 步观察 KL 散度的上升速度，再决定放大还是缩小。学习率恒定在 5e-7（7B 模型），配合梯度裁剪，裁剪阈值设为 1.0。batch 大小按显存上限尽量拉大，每个 batch 内保证至少 64 组。

训练过程中的监控指标按优先级排序：KL 散度、策略熵、响应平均长度、reward 均值、梯度范数。如果 KL 在 1000 步内超过 2，降低学习率或者增大 β；如果响应平均长度持续膨胀且任务正确率没有同步上升，加温和长度惩罚；如果策略熵下降到初始值的 30% 以下，先检查温度设置，再考虑熵奖励。

下面是参数速查表，可以直接复制到你自己的实验笔记里。

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

6.1 训练曲线与评估指标的背离

最让人头疼的现象是：训练中 reward 曲线稳步上升，甚至 KL 散度也正常，但拿 checkpoint 去跑评测集，准确率不升反降。每次遇到这个问题，先不要怀疑评测脚本，先检查生成的 response 质量是不是出现了“话痨”或者“格式美化”现象。

排查思路是先抽 50 条训练中生成的 response 自己看。通常会发现模型学会了用更长的框架性语句包裹答案，或者在代码前后加了很多无关注释，而你的 reward model 恰好给这些格式加了分。这种情况不是超参问题，而是 reward hacking。解决方向从三个入手：检查奖励函数是否泄漏了格式信号、适度增加长度惩罚、加强 KL 约束。比较讽刺的是，很多人第一反应是调学习率，这基本是无效的。

6.2 KL 散度与熵的失控

KL 散度爆掉通常表现为训练几百步之后，策略模型输出的文本开始出现重复片段甚至乱码。常见原因有三个：β 设置过小、学习率过大、组内采样的 G 太小导致 advantage 噪声过大。排查顺序是先看梯度范数曲线，如果梯度范数也在同步飙升，优先调低学习率；如果梯度正常但 KL 失控，调大 β。还有一种隐蔽情况：参考模型用的是 SFT 早期 checkpoint，而基座模型是后期 checkpoint，两者初始分布就不完全一致，导致 KL 约束一开始就偏大，需要先对齐两个 checkpoint。

如果 KL 没问题但策略熵掉得很快，就要把注意力放到采样策略上。把温度从 0.7 提到 1.0 往往是效果最直接的修复。如果温度已经足够高，再考虑熵奖励——这种情况下熵奖励才有明确作用。

6.3 计算资源与采样策略的权衡

显存不够导致 G 设不上去的情况很常见。此时不建议硬扛，而是优先保证 G 不低于 8，同时把温度从 1.0 提升到 1.2，通过增强探索来部分弥补小组的方差劣势。另外一个实践技巧是控制最大生成长度。很多团队会把最大长度设为 2048 甚至 4096，白白增加了显存消耗，但实际 sample 的平均长度可能只有 800。建议先对 SFT 模型的输出长度分布做一次统计，按 95 分位数设置最大长度，显存能省出一大截。

如果连 G=8 都跑不动，还有一条路是参考模型用 LoRA 量化版，只算 KL 不做反传，显存占用会降低不少，但对最终指标的影响需要单独验证。

三篇评测看下来，我自己最大的体感是：GRPO 是一个容错率比想象中高、但上限也被基础设置锁死的算法。真正拉开训练效果差距的，不是某个花哨的损失项，而是你有没有理解采样多样性、KL 约束和梯度稳定性这三者之间的平衡关系。这也是我为什么一直建议团队先用最简配置跑通，再根据监控指标逐项加技巧，而不是第一天就把所有社区偏方全塞进训练脚本。最后再分享一个小经验：每次改动技巧或超参之后，固定随机种子跑一次“前后对比”，记录指标的同时务必截下 KL 和熵曲线，单看最终分数很难判断这个改动是好事还是碰巧。