GRPO 相关的实战内容我再熟悉不过了。过去一年我把这套算法从复现到改参数再到魔改踩过的坑比看过的论文还多。它能在 2026 年成为大模型后训练的核心战场不是偶然——当你把策略梯度里的价值网络整个扔掉、用组内相对比较代替绝对评分时整个训练系统的显存和稳定性一下子变了样。这篇文章我会把 GRPO 的原理、变体、落地参数和真实翻车经验一次性倒出来。1. 从 PPO 到 GRPO后训练主航道切换的底层逻辑1.1 PPO 时代每个 token 都养着一套评论家网络最早做 RLHF 的时候大家默认的选择是 PPO。PPO 需要两个模型同时跑一个策略模型负责生成回答一个价值模型critic负责给每个 token 预测优势值。这个价值模型不是个轻量小网络它通常和策略模型同规模训练时占用的显存、计算量和反向传播开销几乎等于再训了一个模型。更麻烦的是价值模型对奖励的拟合在稀疏奖励场景下极不稳定。尤其在代码生成、数学推理这类任务里整段输出可能只有最终结果给出一个 0 或 1 的奖励价值模型要在每个 token 上预测未来累积奖励本质上是在做无梯度的时序信用分配。结果就是 critic 的 loss 掉不下去优势估计噪声大策略更新像是在布朗运动里找方向。某开源团队当时跑 70B 级别的 PPO一台八卡 A100 机器仅仅拉起策略、参考、价值三个模型就基本没剩下多少显存给 batch 和 KV cache 了。1.2 GRPO 把评论家换成了同班同学成绩单GRPO 的做法在直觉上非常朴素与其用一个价值函数去凭空估计绝对优势不如在一个采样组里对多个输出做横向比较。对同一个 prompt 采样 G 条回答计算每条回答的奖励然后在组内做标准化[ A_i (r_i - mean(r)) / std(r) ]。这个矩阵式的操作替代了整个 critic 网络。数学上GRPO 的更新仍然服从梯度上升只是优势函数从绝对价值预测换成了组内相对位置。它的好处可以从三层理解。第一显存开销直接少了一个策略规模模型加它的优化器状态这意味着同样硬件条件下可以塞更大的 batch 或更长的序列。第二基线估计无参数不会因为 critic 欠拟合而产生系统性偏差。第三语义上更贴近人类评价方式我们判断 AI 回答好不好从来不是用绝对分而是看完几个候选后说第 2 个明显比第 1 个顺眼。1.3 组内比较为什么特别适配大模型对齐这里有一个容易被忽视的点大模型 RL 阶段的奖励信号通常来自另一个奖励模型或规则验证器它的分布会随着训练进行不断漂移。PPO 的价值网络一直试图追踪这个漂移但它更新慢、误差大。GRPO 的组内标准化天生免疫绝对尺度的漂移——只要同一个组里的 G 条回答使用同一套奖励打分无论全部 1 还是全部 10减均值除标准差之后的结果一模一样。这一点给训练稳定性带来的提升比大多数算法层面的小技巧都有效。一个前提需要明确组内比较有效的前提是采样出的 G 条回答之间差异足够大。如果策略模型已经坍缩成只会输出同一种模板组内方差趋近于零那 A_i 会变成无穷大或除零错误这是训练崩溃的典型前兆。所以后续很多变体的核心工作都是在修复组内比较这个框架在不同场景下的缺陷。2. GRPO 变体全景每个改版都对应一个具体痛点2.1 长度崩溃与 LenGRPO 类长度感知归一化GRPO 跑推理任务时最常见的问题就是 length hacking。模型发现答案写得更长、步骤更多即使最终结果错误过程中也可能蒙对几个中间步骤让整体奖励变高。而在组内标准化时长答案天然会获得更高的奖励分导致策略迅速趋向于生成冗长、重复、看似严谨但没有实际进展的内容。某次代码生成实验里策略模型在 2000 步时平均回答长度从 300 token 涨到 1800 token通过率却从 62% 跌到 48%这就是一个教科书级的长度崩溃案例。LenGRPO 的核心修正是把长度因素从奖励里剥离在计算组内基线时先把所有样本按长度分桶同一长度桶内再算均值和标准差。这就避免了长答案因为长度获利的基线偏移。实际实现时需要根据当前 batch 的长度分布动态决定桶宽过细会导致每个桶样本数太少、方差估计不可靠过粗又起不到剥离作用。我一般把 G8 的组按 256 token 步长分成桶保证每个桶至少 3 个样本。2.2 奖励噪声与 WRPO 的加权平滑策略GRPO 对奖励噪声的敏感度比想象中高得多。图生文任务里同一个 prompt 生成 8 条回答奖励模型给出 3.1、3.2、7.8、3.0、3.3、3.4、3.5、3.2 这样的分数7.8 这个离群值会把组内标准差拉到很大导致其余 7 条回答的优势值全部被压缩到接近 0策略更新几乎停摆。WRPO加权奖励 GRPO的做法不是简单剔除离群值而是引入奖励权重因子 ( w_i 1 / (1 k \cdot |r_i - \tilde{r}|) )对偏离组内中位数的样本做软降权。k 的取值通常 0.1 起步奖励分布宽时上调到 0.5。实测下来用中位数而不是均值计算中心点效果更好因为均值本身会被离群值污染。这套修改在奖励模型分数不可信或训练早期波动大的场景下收益非常明显。2.3 训练后期熵塌陷与解耦裁剪类方案所有基于策略梯度的算法都面临同一个问题随着训练推进策略熵会持续下降模型输出的多样性越来越差。一旦熵降到接近零采样出的 G 条回答几乎相同组内方差消失标准化失效然后训练崩溃。原始 GRPO 对 token 概率的裁剪区间是固定的比如 0.2但它没有区分正优势 token 和负优势 token。解耦裁剪方案做了两件事一是把正负优势的裁剪区间分开正优势用更宽的区间允许模型每轮多走一步负优势用更窄的区间防止模型因为一个坏 token 大幅改变整个分布二是对优势值绝对值过高的 token 做额外的 clip-higher 限制避免少数极端正样本把策略拉飞。按我的经验解耦裁剪是把 GRPO 训练长度从几百步安全推进到几千步的关键开关。2.4 组内排序的极简改造GSPO 的 softmax 替代GSPO 是另一种有趣的方向不把奖励标准化成绝对数值而是用组内 softmax 把奖励转成概率分布然后做监督排序。它在视频生成、长文档摘要这类奖励信号稀疏且不可比的任务里效果比标准化好。原因在于 softmax 对组内相对顺序更敏感而对绝对差值不敏感一个 0.2 分的优势会被放大成 55% 的选中率模型能更快学到偏好哪个回答而不是追着数值跑。但它的缺点是梯度信号被 softmax 饱和区压制训练初期如果分数差距过大会直接饱和。我个人的选型经验可以总结成下表变体方向核心改动适用场景主要风险原版 GRPO组内 Z-score奖励分布稳定的通用对齐长度崩溃、熵塌陷LenGRPO长度分桶归一化数学推理、代码生成桶宽难调WRPO离群降权奖励噪声大权重系数敏感解耦裁剪非对称 clip长训练、防熵塌陷与 KL 系数耦合GSPO组内 softmax 排序视频、摘要排名类饱和失梯度带 KL 预算的引导动态调整 KL 系数对齐安全要求高收敛慢3. 实战复盘我在四个 GRPO 训练实验里翻车的全过程3.1 翻车一组内样本数太少引发的方差雪崩有一轮对话意图识别实验我为了省显存把组内采样数 G 从 8 砍到 2。结果显示策略在 3000 步内 loss 持续上升生成回答开始出现乱码。排查过程从奖励模型开始逐步排除先检查奖励模型输出分布正常接着打印每个 step 的优势值发现标准差经常出现极端值。原因在于 G2 时组内标准差只有两个样本的偏差而被采样的两个回答恰好都是高分时标准差趋近 0归一化后优势值变成几十上百梯度步长爆炸。这也让我理解了为什么大多数开源实现默认 G8组内统计量的方差随 G 增大而降低但 G 越大采样成本越高。G4 是一个稳定性和成本都还可以接受的底线G8~16 是训练效果最好的区间。如果显存确实不够正确的做法是减小 batch size 而不是减组数或者直接用梯度累积维持等效 batch。3.2 翻车二KL 正则系数把策略逼成了复读机GRPO 的目标函数里包含一个 KL 惩罚项用来约束策略模型不能离参考模型太远。一次实验中我把 KL beta 设成 0.1偏大策略模型为了保证 KL 小很快学会把参考模型的输出近乎原样输出甚至出现了连续三段重复同一句话的现象因为重复输出本身跟参考模型分布很接近KL 极低但整体生成质量和多样性完全毁掉了。复盘时我把 KL 的惩罚系数拆开看发现问题出在 token 级别 KL 的平均会导致亲密度高的 token 帮亲密度低的 token 买单。解决办法有三条我最终选了动态 KL训练开始时 beta 设为 0.05每 500 步根据平均 KL以自然对数形式调整一次 beta如果 KL 超过 2.0 就增大 beta低于 0.5 就减小 beta。这套逻辑其实借鉴了自适应 KL 控制的成熟做法但实现简单有效。3.3 翻车三采样温度固定导致奖励分布不健康另一个低价踩的坑是采样温度从头到尾固定。GRPO 的组内标准化高度依赖采样的多样性。如果温度过低组内回答几乎都是同一个高概率路径奖励方差接近零如果温度过高组内全是不连贯的垃圾文本奖励均值被拉低真实好的回答被压成负优势。实践里我现在采用温度退火策略训练前 10% 步数用较高的温度比如 1.0鼓励探索中间 70% 逐步降到 0.7后 20% 固定在 0.6 左右保证稳定性。但这里有一个必须配套的检查每个 step 记录组内奖励方差如果方差低于阈值比如 0.01触发警告说明采样多样性完蛋了当前时刻的温度设置立即失效。3.4 翻车四长度惩罚和奖励函数里埋着两套标准最后一个翻车是代码生成任务里我在奖励函数里加了长度过长就扣分的规则同时又在训练集里保留了一堆原本就喜欢写超长答案的样本。结果是策略模型在奖励函数和训练数据之间激烈冲突损失曲线震荡了一个星期。到后来排查才恍然大悟长度扣分与组内标准化天然叠加规则本身就破坏了后面归一化的意义。正确做法是把长度惩罚直接放在模型的输入 prompt 里提示请尽量简洁或者用 LenGRPO 那种分桶归一化从机制上解决绝不要在奖励函数里手工加惩罚项。因为任何手工惩罚都会在归一化后被再次放大。4. 落地施工显存估算、参数选择和实验组织4.1 显存成本的一个朴素算法很多刚开始做 GRPO 的人拿着一个 7B 模型就在单卡上跑很快发现 OOM然后开始盲目换小模型。这里给一个粗糙的估算方法假设模型权重占 M训练时你需要同时驻留策略模型、参考模型和优化器状态。策略模型不仅是推理还要反向传播激活和优化器状态通常是权重量的 3~4 倍。所以总显存不含 KV cache 和 batch大约等于 ( M_{策略} \times 4 M_{参考} \times 1 M_{优化器} \times 2 )。一个 7B 模型 fp16权重 14GB策略部分 56GB参考 14GB优化器 28GB总计 98GB。单卡 A100 80GB 跑不下需要至少两张卡分片。如果你实际只用了 40GB 就起来了那大概率是没有开梯度检查点或者优化器状态被降到了 fp16这会影响数值稳定。做资源规划的时候把 batch 和 KV cache 额外加 30%-50% 的余量就不会在半夜 OOM。4.2 超参数基线从可以直接抄的表开始GRPO 的超参数比 PPO 少很多但敏感度依然很高。我用于 13B 模型做数学推理任务的基线参数可以直接作为你的起点参数推荐值备注组数 G8~16组内统计稳定性核心KL beta 初始0.02~0.05必须配动态调节优化器AdamWlr 调低更稳学习率2e-6 到 5e-6超过 1e-5 极易崩溃采样温度0.7早期探索可到 1.0策略 clip epsilon0.2配合解耦裁剪每 prompt 训练 epoch2~4超过 6 必过拟合微批次大小64 prompt每 prompt 采 G 条最大序列长度2048~4096长 CoT 任务需上调4.3 实验组织从单次运行到可复现的迭代链路跑了三个月 GRPO 后有一个方法论层面的教训别把每个超参数变动都单独开一次训练那样既浪费算力又分不清效果来源。我在自己的实验模板里做了固定流程——每个实验固定数据版本 基础检查点两个变量其他任何修改都明确记录在训练日志里每个实验只改一个维度G 或 beta 或裁剪每次实验跑完先看四张图训练 loss、组内奖励标准差、平均输出长度、KL 散度。四张图一起看才能定位问题如果 KL 涨且长度涨是长度崩溃如果 reward 方差下降但 KL 正常是采样温度问题如果 loss 上升但 KL 平稳大概率是奖励函数出了 bug。这套排查逻辑比任何先进解释工具都实用因为它直接对应 GRPO 的四个核心变量。数据版本必须固定否则换了一版数据之后你会完全搞不清楚效果变化来自数据还是算法。4.4 训练框架选型的取舍我在不同阶段用过的训练框架不只是三个。早期的框架在组件灵活性上有优势但分布式切分和长序列支持较弱适合单机 7B~13B中期采用的框架在 3D 并行上做得成熟70B 级模型能在大规模集群上稳定跑但对自定义改造成本高——用它的内置配置不写代码很难接入新的变体后期这个问题解决得最好的是一个支持自定义 policy 更新的框架它把采样、评分、更新通过可编程接口连接我可以直接把 LenGRPO 的分桶逻辑嵌进 reward 归一化组件。我的建议是先确认你的核心任务是快速验证 GRPO 变体想法还是把成熟的 GRPO 流程大规模上线前者选灵活型框架后者选并行度高的框架。两者一般很难是同一个。框架的文档质量和示例代码数量远比它声称支持的算法列表更有参考价值。一个凉掉的框架源码里往往藏着你真正需要理解的实现细节。5. 2026 年核心战场的四个判断5.1 可验证任务 RL 会成为算法竞技主场推理模型后训练有两个大方向一个是靠人工偏好数据做对齐另一个是靠在数学、代码、可靠基准测试这类有明确对错的任务上做强化学习。后者会被验证器verifier和授权规则深度重构。GRPO 天然契合这个场景因为可验证任务给出的是 0/1 奖励组内标准化加上规则验证就能形成闭环不需要额外训练奖励模型整个系统的可扩展性和透明度都会提升。但要注意这类任务里的终局奖励非常稀疏往往一整段长思考过程只对应一个分数。这种情况下 GRPO 的组内标准化容易把差异集中在最终结果是否正确的二分上导致中间 token 信号几乎全零。为了让中间步骤也能学到东西我预计会出现更多基于过程监督的中间奖励函数以及把验证器从只看结论升级为监督推理步骤合法性与关键节点的混合奖励结构。5.2 后训练栈会分化成三层基建到 2026 年后训练基础设施的形态会逐渐清晰我理解的分层是这样的最底层是采样和分布式更新引擎负责把大模型在集群上高效跑起来中间层是奖励与数据反馈总线承载规则验证器、奖励模型、离线偏好数据集这些信号源能实时组合成统一的奖励函数上层是策略优化算法库GRPO 及其变体在这里变成模块化组件使用者可以像拼积木一样切换标准化方式、KL 策略和裁剪规则。对从业者而言现在学 GRPO 不仅仅是为了掌握一个算法而是在为这个三层栈打基础。算法细节就算过时采样引擎和奖励总线的理解不会过时。我在社区里见过很多研究员改一个奖励函数要改十几个文件牵扯采样、缓冲、更新三个模块。等基建分层完成之后这些事情会被封装成配置项。5.3 多模态与长上下文场景在重构组的概念过去 GRPO 的组内比较只发生在文本空间一条回答是一连串 token。到了多模态和长视频生成场景输出对象变成图片、视频帧或超长文档组内标准化的对象不再是简单的标量奖励而是多维评价语义一致性、视觉质量、时序连贯性、指令跟随程度这些指标可能同时出现。这些场景下组的构建方式也在变化。传统 GRPO 同一个 prompt 采多条独立回答但在视频任务里完整性差的多条输出几乎没有可比性。我预判会出现分层组的做法先在粗粒度上比较主题和结构再在细粒度上比较局部动作和细节质量不同粒度使用不同的基线。长上下文任务则更关注令牌偏移和公平长度控制LenGRPO 这类长度感知方法会进一步演化。5.4 低资源复现和算法透明化会成为社区兴奋点算力垄断再厉害依旧有很多小团队在想办法用更低的成本复现大模型后训练。GRPO 的一个显著优势是它比 PPO 省一个模型这本身就是低资源友好的信号。2026 年会有更多围绕如何在一小块 GPU 集群上稳定跑 GRPO的内容出现包括梯度检查点策略、权重卸载时机、组规模与显存的量化关系这些细节都会从论文走向工程手册。我个人的判断是不太会出现一个把 GRPO 彻底颠覆的新算法。GRPO 的组内比较思想实在太简单、太符合偏好学习的直觉了它更像一个框架后续的创新都会像 GSPO、LenGRPO、WRPO 一样在框架内部填充新组件。谁能让这些组件组合更灵活、更稳定地适配各种任务谁就能掌握后训练的核心竞争力。从第一次在单卡上跑通一个 7B 模型的 GRPO到后来在集群上指挥几十亿参数的长程训练这个算法给我最大的意外是它的思想如此简单却能把强化学习后训练的整个系统门槛拉下来一大截。如果你正要入局大模型后训练我建议直接从 GRPO 开始先跑通一条完整链路再动手改组件把变体的权衡取舍都亲手验证一遍。这条路走完之后你看主流后训练论文的视角会彻底改变。