GRPO：大模型后训练中组相对策略优化的核心技术与工程实践

1. 为什么后训练的聚光灯在2026年打向了GRPO

1.1 先聊一个反直觉的选择：放弃critic

两年前，如果你告诉我“2026年大模型后训练的核心战场会是一款去掉了评论家网络的强化学习算法”，我大概率会摇头。GRPO（Group Relative Policy Optimization，组相对策略优化）最初出现在某数学推理模型的训练报告里时，很多人都把它当成一个“不够正统”的变体——毕竟PPO统治了强化学习这么多年，价值网络加广义优势估计（GAE）几乎是标配，谁会把critic直接扔掉？

但2026年你再回头看，GRPO及其衍生变体不仅没死，反而成了后训练阶段最拥挤的一条赛道。原因并不复杂：大模型后训练和传统RL环境有一个本质区别——采样成本极不对称。在游戏或机器人环境里，rollout一次几十上百步，critic网络的误差尚可接受；但在大模型场景里，一个序列几千个token，推理过程本身要占大量的显存和算力，你再养一个和策略网络规模相当的critic，等于把训练开销翻倍。GRPO的聪明之处在于，它用“同一个问题采样一组回答、在组内计算相对优势”的方式，替代了critic的价值估计，省掉了这条最重的支线，而且稳定性还更好。

1.2 可验证奖励范式的崛起

更关键的是，2024年之后“RLVR”（可验证奖励强化学习，Reinforcement Learning with Verifiable Rewards）逐渐成为主流范式。大家发现，与其去训练一个容易退化的奖励模型，不如直接写规则验证器：代码题就交给执行器和测试用例，数学题就比对最终答案，格式题就检查结构化标签。这类验证器输出的信号通常是0/1或者少量等级分，不需要预测未来累积回报，自然也不需要critic那套时序差分框架。

这时候GRPO的适配性就体现出来了。规则验证器给出的奖励是宏观的、序列级的，而PPO的价值网络天然为token级的密集奖励设计；GRPO不care这些，它只看一整条回答在所有参考样本里的相对排位。也就是说，可验证奖励的稀疏性，和GRPO的组内比较机制，恰好是相互成就的。业内甚至有个玩笑说法：到2026年，如果你还在为一个0/1的reward信号上PPO，那你的运维成本大概是自己人的三倍。

1.3 从Token级优势到序列级优势的思路转换

GRPO之所以能成为“核心战场”，还因为它引发了一场更彻底的方法论反思。PPO代表的是“每一步都有好坏”的思想，而GRPO传递的是“整段回答放在一起比才有意义”的朴素认知。代码能不能跑通、数学题到最后一步对不对、一个回答是否满足用户全部约束——这些都是典型的“事后才知道”的评价。你非要给每个token都算一个优势值，反而引入了大量噪声。

我见过不少团队在2024年还在花大力气给每个step标注过程奖励，2025年之后逐渐转为“整段评判+组内排序”，最大的感受就是：训练曲线变得可预测了，洗数据花的时间也降下来了。这种从精细化到整体性的转向，其实是整个后训练领域成熟度提升的标志。

2. GRPO的训练循环拆解：从采样到优势估计

2.1 一次完整的GRPO训练迭代长什么样

先把GRPO的训练流程展开。单步迭代可以分为四个阶段：

1. 策略网络针对一个batch的问题，每组采样G条回答。这里采样温度一般控制在0.6到1.0之间，温度太低样本多样性不足，太高又会混入大量低质量完成。
2. 用验证器给每条回答打分，得到原始奖励r_i。
3. 在组内做归一化：计算该组所有奖励的均值与标准差，得到每个回答的优势A_i。
4. 用策略梯度损失更新模型，同时施加KL散度约束，防止模型偏离参考策略太远。

这套流程里最核心、最容易被误解的就是第三步。我见过不止一个新同学问：为什么不直接用绝对奖励？r等于1就是好，r等于0就是坏，这不明摆着吗？

问题出在奖励尺度、分布形态和噪声上。同一个问题，验证器偶尔会因格式匹配不到而误判；不同问题之间，难度不同导致该组整体的得分分布也不同。直接用绝对分数去做策略梯度，模型很容易“钻空子”去讨好验证器的浅层特征，而不是真正提升能力。组内归一化之后，每条回答的优势只取决于它在该组中的相对位置——这样，无论这一组整体是容易还是难、验证器是宽松还是严格，模型都能得到一个量纲一致的梯度信号。

这就是“相对”二字的本质含义。

2.2 为什么优势必须除以标准差，而不是只做减法

很多人理解的“组内归一化”停留在“用奖励减均值”，对除以标准差这一步不够重视。包括最初的一些开源复现，代码里也只做了中心化，没有除以组内标准差。实验效果上看，训练也能跑，但遇到个别组的奖励特别分散、甚至出现极端值时，梯度波动会明显变大，有时伴随loss剧烈跳动。

除以标准差的作用其实是两方面的。第一，它让优势值成为一个无量纲量，可以跨batch比较，方便统一设置clip范围和学习率。第二，它相当于在组内做了一次自适应的奖励尺度调整：如果某一组样本的奖励天然就很分散，除以一个大的标准差之后，优势值不会过大，梯度步长自然被约束住。换句话说，这是GRPO里第一层“可控性”的保障。

需要留意的是，标准差为0的情况必须处理。如果整组回答得分都一样，归一化会变成无穷大，常见的做法是跳过该组更新，或给分母加一个极小epsilon。这个细节我在不少版本的实现里看到过漏洞，训练到一半偶尔爆一个NaN，排查半天结果只是某类问题上验证器打分总是同分。

2.3 核心损失函数：三个零件的配合

GRPO的更新式子可以抽象成下面这个损失：

L(θ) = E[ min( ρ_i(θ) A_i, clip(ρ_i(θ), 1-ε, 1+ε) A_i ) - β · KL(π_θ || π_ref) ]

其中ρ_i(θ) = π_θ(o_i | q) / π_old(o_i | q)，是当前策略相对于采样时旧策略的似然比。三个零件分别负责不同的事情：

• 似然比与优势相乘：让好回答的生成概率上升、差回答的生成概率下降，这是策略梯度的基本形式。
• clip操作：限制单次更新的幅度，避免某个回答因为优势值太大，让模型一步更新过猛，直接冲坏已经学好的分布。
• KL项：把当前策略“拴”在参考策略附近，防止模型为了刷奖励进入退化模式——比如疯狂重复同一个句式、盲目加长回答。

在实操层面，三个零件需要权衡。clip范围ε常见的取值是0.2，但我会建议在小模型上从0.1起步，大模型可以放到0.2甚至0.3，因为小模型对策略变化的承受能力更弱。KL系数β一般取0.01到0.1之间，这个我后文会再展开。核心原则是：GRPO的稳定不是某一个零件带来的，而是clip、归一化和KL三者共同作用的结果。任何一方失效，训练都会很快变形。

2.4 长度惩罚到底放在哪里最合理

有一个很容易忽略但实战里极其重要的点：长度控制。大模型经过RL训练后，几乎必然出现越来越啰嗦的倾向——因为多写几个token，就算内容冗余，只要不扣分，命中的概率就更高。很多实践者会把长度惩罚直接塞进奖励里，比如r' = r - α·len，这种做法效果立竿见影，但副作用也明显：它改变了验证器原有的语义，让“正确但冗长”和“简洁但错误”混在同一个量纲里难以比较。

更稳的做法是把长度控制作为一种独立偏置，叠加到优势计算之后而非原始奖励之中。这样既能抑制啰嗦，又不干扰验证器对真实质量的判断。我见过一个比较精细的配方是：组内归一化完成后，再按照“长度偏离组均值多少”施加一个温和的惩罚系数，系数范围控制在0.05到0.2之间，太大则模型会走向极端简洁，反而不利于复杂的多步骤推理任务。

3. 变体演进图谱：GRPO在三年间长出的主要分支

3.1 分支一：长度感知与训练动态优化

GRPO在落地过程中最先遇到的问题就是重复与退化。训练中期，模型往往会开始频繁输出固定套话，比如“首先，让我们一步步思考”“综上所述”这类填充字符。初代GRPO对这类问题几乎没有约束力，于是出现了一批专门针对输出结构的变体。

这些变体并不改变组内优势估计的骨架，而是在奖励计算阶段加入“过度重复惩罚”或“格式多样性奖励”。比如对连续重复n-gram的片段进行惩罚，或者检测回答的TTR（type-token ratio，类符形符比），过低说明词汇多样性严重不足。这类机制在训练初期要关掉，因为模型输出还比较粗糙，语法重复不代表退化；一般训练到第500到800步之后再开启，能显著延长有效训练时长。

我的经验是：不要过早使用强长度约束。早期约束越强，模型越容易找到“短平快”的路线，放弃长链条推理。最优策略是训练后期选择性开火：当平均回答长度增长出现陡峭拐点时，再分阶段加强控制。

3.2 分支二：从“组内”到“全局”的基准视角变化

纯组内归一化的一个隐含缺陷是：不同组之间没有可比性。同一批数据里，如果某一组整体得分偏低，组内最高分仍会被当成正向样本去强化；而另一组整体得分很高，组内相对靠后的样本仍然会被惩罚。这其实是把“跨样本的相对质量”错误地转成了“样本内的排序游戏”。

应对思路分成两派。一派主张在分组方式上做文章，加大组大小或者让组内样本更具多样性——这样组内排序更接近全局排序，但采样成本随之上升。另一派更激进：统计一个批次、甚至一个训练阶段的奖励分布，用分位数或滑动均值的动态基准替代静态的组内基准。这两种路线各有拥趸，前者实现简单、训练稳，后者上限更高、但对reward的分布稳定性要求苛刻，reward分布一旦漂移，训练曲线就会剧烈震荡。

就我自己的观察，2026年大多数取得较好推理效果的训练报告，组内比较依然是主体，全局基准更多作为一种辅助校准项存在——比如动态调整KL系数，而非直接替换优势计算。这说明“简单、稳”在工程上依然是第一考量。

3.3 分支三：交互式与多智能体环境的GRPO

传统GRPO假设验证器是确定性的、独立的：每个回答单独判分，组内互不影响。但2025年中后段开始，有一批任务大家意识到假设不成立——比如多轮工具调用、网页导航、多智能体博弈。这些场景里，策略的产出会被环境不断反馈，一条回答是否成功取决于此前几步的工具结果，某一步失败，后面全盘皆输。

针对这类场景，一批“交互式GRPO变体”开始出现。它们不再对最后的回答做单次组内比较，而是把一次任务拆成多个决策点，在每个决策点分别采样N种动作并组内比较。这本质上把GRPO从“回答级”下沉到了“动作级”，但和PPO的token级优势仍然有本质区别——它以“完整的动作片段”为单元，天然适合工具调用这类语义边界清晰的决策。

这类变体目前还处于“需求驱动”的阶段，没有统一标准，但产出结果确实超过了把工具调用序列强行拉平成token去训练的方案。在真实的agent训练中，同样是Code执行器反馈，交互式变体最终的通过率能高出不少。我对这个分支相对乐观：未来的GRPO大概率不是一个静态算法，而是一套可叠加的“采样与比较”框架。

3.4 分支四：从结果奖励走向可验证的过程奖励

数学推理场景里，很多人想要“过程监督”：不只判断最终答案对不对，还要定位哪一步逻辑开始出错。经典的PRM（Process Reward Model，过程奖励模型）路线需要人工标注或自动标注大规模过程数据，成本极高。GRPO的变体提供了一条折中路径。

具体做法是：把推理过程拆成步骤，验证器不只检查最后答案，还给“中间步骤的守恒性/可验证条件”单独打分，比如代码是否编译通过、数学式推导是否满足等价变换规则；然后把步骤得分做加权组合，生成一条序列级的奖励。这套体系在数学和代码数据上的效果通常好于纯结果0/1奖励，因为它给模型提供了更密集的信号，收敛更快。代价是实现复杂度高——你需要额外维护一个“步骤边界识别器”，而步骤边界切得不对，整条奖励链条就失真了。

4. 工程落地的关键决策：组大小、KL与奖励塑形

4.1 组大小G真的是越大越好吗

生产环境下，很多人默认“组内样本越多，优势估计越准，那我把G直接拉到32甚至64”。大样本组的确能减少优势估计的噪声，但代价非常直接：缓存中的rollout数量成倍增加，显存压力剧增。我个人的分界线建议是，6B到7B量级的策略模型，G=8就是常见稳定点；30B以上可以尝试16；64一般只在8卡以上并行环境或者小batch配合下才划算。

更大的隐性成本在“样本淘汰率”。以8B模型跑数学推理为例，随机采样64条回答，里面可能有30条连格式都不过关。在组内归一化下，这些劣质样本会被压出大概率边缘，相当于白白消耗了算力。我的一个妥协方案是：先用较小G（4或8）快速筛选“值得优化”的问题，针对通过率集中在中段的问题，二次用大G精细采样。这样整体算力效率更高，不容易让训练陷入“为区分垃圾样本而烧卡”的窘境。

4.2 不要手动缩放奖励，要改验证器

工程里最常见的错误就是——训练到一半发现loss不降，于是有人开始手动“调奖励权重”，有的把0/1奖励放大到2，加一个偏移；有的把长度惩罚系数从0.4改成0.1；最后训练曲线不降反升，还处处透着一股奇怪的震荡。

我可以非常肯定地说：GRPO对奖励绝对尺度的敏感度是很低的，优势归一化已经把尺度抹平了。你手动去缩放奖励，等于把归一化之后好不容易对齐的量纲又打乱了。与其调大调小，不如把工夫花在验证器本身上：为什么奖励偏低？是因为答案对但格式错，还是测试用例覆盖不足？把验证器的判定逻辑改对，比任何奖励缩放都更有用。

4.3 验证器的构建是训练质量的隐形天花板

很多团队训练效果不好，第一反应是调算法参数，但真正的瓶颈往往是验证器。一个严格但不够灵活的验证器会把“语义等价但表述不同”的答案全部判错，模型被迫只能记忆一种死板的模板；一个宽松的验证器又会在格式通过但逻辑错误的情况下给出正分，把模型往错误方向带。

构建验证器时我个人的几个建议：

• 代码执行类验证器优先做“幂等检查”：同一份代码在不同输入下多次运行，结果应当一致，不一致多半说明环境或验证器有bug。
• 数学类验证器不要只比对最终数字，至少做一步“符号等价性”检查，比如去掉空格、处理小数与分数归一化。
• 对任何需要“格式解析”的验证器，单独维护一个格式解析的测试集，把普通的算法测试数据也过一遍，防止某次正则改动悄悄改变判定结果。

4.4 KL预算必须与采样温度联动

KL系数β之所以容易被误配置，是因为它和采样策略之间存在耦合。温度高时，策略分布被摊平，新旧策略之间的KL自然上升，相当于每次更新都顶着更大的KL惩罚；温度低时，分布尖锐，KL掉得很快。如果β过低、温度又偏高，模型就会借着KL惩罚不足的窗口快速漂移，训练看起来跑得飞快，但随时可能崩溃。

实操上，我习惯做成动态配置：把采样温度固定在0.7到0.9之间，KL系数根据“滑动平均的KL实际值”反向调整，目标是让实际KL始终维持在一个参考值附近。这个参考值在1e-5量级至1e-6量级比较常见，具体要看模型规模和核对任务难度。你可以不必这么复杂，但至少要知道：固定β而放任温度变动，是训练曲线忽好忽坏的典型源头之一。

4.5 训练崩溃的典型症状与排查

下面这张表是我在多个项目里反复验证过的排查顺序，遇到训练崩溃，按照这个链路走，基本能在半天内定位：

这里最让我意外的一个坑是“奖励全同”。某次训练，某个batch里所有问题类型高度相似，验证器又只判最终答案，导致整组得分全是0。分母标准差为0，梯度直接变NaN。从那之后，我的所有训练代码里都会额外加一条“std过小时跳过该组并记录日志”的保护逻辑。

5. 算力约束下的下一步：GRPO还能往哪里走

5.1 采样端优化：GUE与分布式rollout成为标配

GRPO的训练瓶颈早就不在前向和反向传播，而在于组内采样——每个训练步要生成G条回答，这比单样本采样贵出一个量级。2026年的工程实践中，采样和训练已经基本解耦：一批GPU专门跑rollout，产出的轨迹缓存进共享队列，另一批GPU消费轨迹做策略更新。这套“异步采样-训练”的架构几乎成了标配。

再进一步是“采样端复用”。同一个prompt采样出的G条回答，除了喂给当轮训练，还会缓存下来回放几轮，配合重要性加权修正分布偏移。这种做法省掉了大量重复采样，代价是训练的实时性下降，需要更精细的KL控制。如果你在小规模集群上跑，这是一个比堆卡更划算的优化方向。

5.2 合成数据与System 2验证的结合

后训练数据危机喊了好几年，到2026年，大家已经不太纠结“要不要用合成数据”，而是“如何用可验证奖励组织合成数据”。GRPO在里面起的作用很微妙：它不只是训练算法，还变成了一种数据筛选工具。

具体操作是：让一个已经具备一定能力的模型对大规模合成题目批量作答，然后用GRPO式的组内比较去批量识别哪些题目“有效”——如果一组回答得分高度分散，说明这个题目区分度好，适合进入下一轮训练；如果全部得高分或全部得低分，说明题目过难或过易，可以降权。这种做法让我印象很深，因为它把训练算法的哲学反过来用在了数据侧：判断一个数据点有没有价值，不看内容模不模板，而看它能不能拉开模型表现的差距。

更长远的视角里，GRPO也在和“System 2强化”汇流。所谓System 2强化，是指让模型在训练时学会“思考后验证”——比如在代码任务里，模型生成的不再是单一答案，而是一段答案加一段自检验证。此时验证器判分的目标从“答案是否正确”变成“模型是否通过自检发现了自己的错误”。如果要在这种模式下稳定训练，组内比较的价值更加明显：因为自检结果本身有很强的随机性，不放在组内相对比较，很难识别出真正的自我纠错能力提升。

5.3 把GRPO当作一个可以拆解的“理念框架”

最后说一点个人判断。GRPO之所以会演变成“战场”，并不因为它是一个纪念碑式的算法，恰恰相反，它足够简单、足够可拆解。任何一个部件——组内标准化、clip、KL、长度偏置、验证器接口——都可以单独拿出来替换或增强。未来几年，结合更强算力、更细粒度的验证器、甚至更有创造力的奖励构造，GRPO会继续被改造，但那些真正有价值的改进，大概率仍然围绕“在组内做比较、在比较中去伪存真”这一核心理念展开。

我自己的体会是：从2024年第一次跑通GRPO的训练曲线，到2026年把它大规模部署进推理模型的完整后训练流水线，最深的感触不是某一个技巧多管用，而是这个框架把“奖励设计”这件事从玄学问答变成了一套工程方法论：你不需要相信某个奖励数值的绝对意义，只需要让一组尽量多样、尽量真实的回答在同一个尺度上公平地竞争。模型最终会告诉你，谁是对的。