1. GRPO算法核心定位与设计动机1.1 从PPO的痛点说起为什么需要GRPO搞强化学习的人都知道PPOProximal Policy Optimization在过去几年几乎成了策略优化的默认选择。但真正在语言模型对齐、推理能力增强这些场景里跑过PPO的人心里都清楚它有多“重”——你需要同时维护策略模型、价值模型Critic、奖励模型、参考模型显存占用直接翻倍不说训练稳定性还特别依赖Critic的估计质量。一旦Critic估计偏差大优势函数就失真整个策略更新方向就跑偏了。GRPOGroup Relative Policy Optimization的核心动机就一句话把Critic干掉用组内相对比较来估计优势。这个思路其实不新鲜类似的思想在REINFORCE with baseline、RLOO里都有影子但GRPO把它做成了一个端到端可落地、在大模型上真正work的方案。DeepSeekMath那篇工作里首次系统性地提出了GRPO后来DeepSeek-R1系列把它推到了推理增强的核心位置。我第一次接触GRPO是在做一个数学推理增强的项目当时用PPO跑7B模型4张A100 80Gbatch size开到64就OOM了而且训练曲线抖得厉害。换成GRPO之后同样的硬件batch size能开到256训练稳定性肉眼可见地提升。这个对比让我意识到GRPO不是“又一个PPO变体”而是从计算范式和优化目标上都做了实质性简化的方案。1.2 GRPO到底解决了什么问题传统PPO的目标函数里优势函数Â_t是通过GAEGeneralized Advantage Estimation算出来的而GAE依赖Critic网络对每个状态的价值估计V(s_t)。这意味着你需要额外训练一个和策略模型同量级的Critic参数量翻倍Critic的估计误差会直接传导到策略梯度导致高方差在语言模型场景下状态空间是离散的token序列Critic很难准确估计中间状态的价值。GRPO的做法是对同一个prompt采样一组Group输出用这组输出的奖励均值作为baseline每个输出的奖励减去均值就是它的优势。公式上就是Â_i (r_i - mean(r_1, r_2, ..., r_G)) / std(r_1, r_2, ..., r_G)其中G是组大小r_i是第i个输出的奖励。这个优势估计完全不依赖Critic纯粹靠组内比较。你可以把它理解成同一个题目让模型做G遍谁做得好、谁做得差相对差距就是优势信号。这个设计的好处非常直接对比维度PPOGRPOCritic网络必须参数量与策略模型相当不需要显存占用高4个模型低3个模型策略、参考、奖励优势估计GAE依赖V(s)组内相对奖励无偏估计训练稳定性对Critic质量敏感对组大小和奖励尺度敏感适用场景通用RL语言模型生成任务优势明显但GRPO也不是没有代价。组内采样意味着每个prompt要生成G个完整输出推理成本是PPO的G倍。所以实际用的时候G一般取4到16之间太大推理扛不住太小优势估计方差大。1.3 GRPO在算法谱系中的位置如果把强化学习算法按“是否依赖价值函数”来分GRPO属于无Critic的策略梯度方法这一支。它的近亲包括REINFORCE with baseline用滑动平均奖励做baseline但baseline是全局的不是组内的RLOOREINFORCE Leave-One-Out用留一法估计baseline和GRPO的组内均值思路非常接近DPO完全绕开在线采样用偏好数据直接优化但缺乏在线探索能力。GRPO的独特之处在于它把“组内相对比较”和“PPO的clip机制”结合了起来。目标函数里保留了PPO的clip ratio保证策略更新不会一步迈太大同时用组内标准化奖励替代GAE。这个组合让它在语言模型上既能稳定训练又能有效利用在线采样。实操心得如果你之前跑PPO总是调不好Critic或者显存不够同时装4个模型GRPO是值得认真考虑的替代方案。但前提是你的任务能定义清晰的标量奖励并且推理成本可控。2. GRPO目标函数拆解与数学原理2.1 目标函数的完整形式GRPO的目标函数看起来和PPO很像但细节上有本质区别。先看完整形式J_GRPO(θ) E[q~P(Q), {o_i}~π_θ_old(O|q)] * (1/G) * Σ_i [ min( ratio_i * Â_i, clip(ratio_i, 1-ε, 1ε) * Â_i ) - β * KL(π_θ || π_ref) ]逐项拆解q~P(Q)从prompt分布中采样一个问题q{o_i}~π_θ_old(O|q)用旧策略对q生成G个输出组成一个组ratio_i π_θ(o_i|q) / π_θ_old(o_i|q)重要性采样比率衡量新旧策略对同一个输出的概率变化Â_i第i个输出的组内相对优势clip(ratio_i, 1-ε, 1ε)PPO的clip机制防止策略更新过猛β * KL(π_θ || π_ref)KL散度惩罚项约束新策略不要偏离参考模型太远。和PPO的关键差异在Â_i的计算上。PPO的Â_t来自GAE依赖CriticGRPO的Â_i来自组内奖励标准化不依赖任何价值网络。2.2 组内优势估计的数学细节假设对prompt q采样了G个输出奖励分别为r_1, r_2, ..., r_G。GRPO的优势计算分两步第一步计算组内均值和标准差μ (1/G) * Σ_i r_i σ sqrt( (1/G) * Σ_i (r_i - μ)^2 )第二步标准化得到优势Â_i (r_i - μ) / (σ ε)其中ε是一个很小的常数通常1e-8防止除零。这个标准化操作有几个重要性质零均值Σ_i Â_i 0组内优势之和为零意味着策略更新是“有升有降”的不会整体推高所有输出的概率单位方差Â_i的尺度被归一化到1附近不受奖励绝对大小影响这对奖励尺度变化大的任务特别重要无偏性在组大小G足够大时组内均值是真实期望奖励的无偏估计所以Â_i是真实优势的无偏估计。但这里有个坑如果组内所有输出的奖励都相同比如全对或全错σ0Â_i全部为0这个组就不产生任何梯度。这在训练初期或任务太简单/太难时经常发生。解决办法后面会讲。2.3 KL惩罚项的作用与调参KL惩罚项β * KL(π_θ || π_ref)是GRPO里最需要小心调的参数之一。它的作用是约束新策略不要偏离参考模型太远防止策略为了刷奖励而输出乱码或重复无意义内容策略遗忘预训练阶段学到的语言能力奖励模型被“钻空子”reward hacking。KL散度的计算方式有两种常见选择精确KLKL(π_θ || π_ref) Σ π_θ(o|q) * log(π_θ(o|q) / π_ref(o|q))需要对整个词表求和计算量大采样近似KL用采样到的token做蒙特卡洛估计k3估计量KL ≈ (π_ref/π_θ - log(π_ref/π_θ) - 1)这个估计量无偏且方差较小。实际实现里大多数GRPO代码用的是k3估计量因为它只需要采样token的概率不需要遍历词表。β的取值经验β值效果适用场景0无约束容易reward hacking不推荐0.001-0.01弱约束策略自由度大奖励信号可靠、任务明确0.01-0.1中等约束平衡探索与稳定大多数场景的默认选择0.1-1.0强约束策略接近参考模型奖励信号噪声大、需要保守更新注意β不是越大越好。β太大时策略几乎不更新训练失去意义β太小时KL散度爆炸输出质量崩坏。建议从0.04开始试根据KL散度的实际值动态调整。2.4 clip机制在GRPO中的特殊考量PPO的clip机制在GRPO里同样保留但ratio的计算方式和PPO略有不同。PPO是token级别的ratioGRPO通常也是token级别但优势是序列级别的整个输出的奖励算出来的。这就带来一个细节同一个输出里的所有token共享同一个Â_i。这意味着如果一个输出整体奖励高它里面所有token的概率都会被推高反之亦然。这个设计是合理的因为在语言模型里我们很难精确知道哪个token贡献了最终奖励用序列级奖励做token级更新是一种粗粒度但有效的信用分配。clip的ε通常取0.2和PPO一致。但在GRPO里由于优势是标准化的ratio的波动范围可能更大有些实现会把ε调到0.1或0.3。我的经验是如果训练初期ratio经常撞到clip边界说明学习率太大或β太小先调这两个再动ε。3. 完整实操流程与关键环节实现3.1 环境准备与依赖安装先列一下我实际跑GRPO用的环境配置这套配置在单机8卡A100 80G上验证过7B模型训练稳定# 基础环境 Python 3.10 PyTorch 2.1 CUDA 12.1 transformers 4.40 trl 0.8 # HuggingFace的RL训练库内置GRPO支持 accelerate 0.28 deepspeed 0.14 # 多卡训练必备如果你不想自己从头写GRPOHuggingFace的TRL库已经内置了GRPOTrainer可以直接用。但如果你想深入理解细节或者做定制化修改建议自己实现一遍核心逻辑。我下面会给出关键代码片段。# 核心依赖 import torch import torch.nn.functional as F from transformers import AutoModelForCausalLM, AutoTokenizer from trl import GRPOTrainer, GRPOConfig3.2 数据准备与奖励函数设计GRPO的训练数据格式很简单每条数据就是一个prompt不需要标注答案只需要一个能打分的奖励函数。这比DPO需要偏好对、PPO需要奖励模型要轻量得多。数据格式示例JSONL{prompt: 计算 3x 7 22 中 x 的值。} {prompt: 解释什么是梯度下降并给出一个生活中的类比。} {prompt: 写一个Python函数判断一个字符串是否是回文。}奖励函数是GRPO的灵魂。它决定了模型往哪个方向优化。我一般把奖励函数设计成多个维度的加权和def reward_function(completions, prompts, **kwargs): rewards [] for completion, prompt in zip(completions, prompts): score 0.0 # 维度1格式正确性0或1 if has_valid_format(completion): score 1.0 # 维度2答案正确性0或1 if check_answer_correct(completion, prompt): score 2.0 # 维度3长度惩罚避免过长或过短 length len(completion.split()) if 20 length 200: score 0.5 elif length 500: score - 0.5 # 维度4重复惩罚 if has_repetition(completion): score - 1.0 rewards.append(score) return rewards实操心得奖励函数的设计比算法本身更重要。我踩过的最大坑是奖励函数太复杂多个维度互相冲突导致模型学出一个“四不像”策略。建议初期只用1-2个核心维度跑通了再逐步加。3.3 组采样与优势计算的核心代码这是GRPO最核心的部分。假设我们已经用旧策略对每个prompt采样了G个输出并算出了奖励接下来计算组内优势def compute_grpo_advantages(rewards, group_size, eps1e-8): rewards: shape (batch_size * group_size,) 每group_size个奖励属于同一个prompt rewards rewards.view(-1, group_size) # (batch_size, group_size) # 组内均值和标准差 mean rewards.mean(dim1, keepdimTrue) std rewards.std(dim1, keepdimTrue) # 标准化优势 advantages (rewards - mean) / (std eps) return advantages.view(-1) # 展平回 (batch_size * group_size,)这段代码看起来简单但有几个细节要注意std的计算PyTorch的std默认是unbiased除以G-1但GRPO论文里用的是biased除以G。实际差异不大但为了和论文一致可以用rewards.std(dim1, unbiasedFalse, keepdimTrue)eps的位置eps加在std后面不是加在分母整体上防止std为0时除零组大小为1的情况如果G1std0优势全为0训练完全无效。所以G至少为2实际建议4以上。3.4 训练循环与关键参数配置完整的训练循环大致长这样# 配置 config GRPOConfig( output_dir./grpo_output, num_train_epochs3, per_device_train_batch_size4, # 每个设备处理的prompt数 gradient_accumulation_steps8, num_generations8, # 组大小G max_new_tokens512, # 每个输出的最大长度 learning_rate1e-6, kl_coef0.04, # β clip_range0.2, # ε temperature0.9, # 采样温度 top_p0.95, logging_steps10, save_steps100, ) # 训练 trainer GRPOTrainer( modelmodel, reward_funcsreward_function, argsconfig, train_datasetdataset, ) trainer.train()关键参数的经验值参数推荐范围说明num_generations (G)4-16太小优势方差大太大推理成本高learning_rate1e-7 ~ 5e-6比PPO小因为组内标准化后梯度尺度更稳定kl_coef (β)0.01-0.1从0.04开始根据KL实际值调clip_range (ε)0.1-0.3默认0.2ratio撞边界频繁时调小temperature0.7-1.0太低组内输出太相似优势信号弱max_new_tokens256-1024根据任务输出长度定3.5 显存优化与多卡训练GRPO虽然省掉了Critic但组采样意味着推理时的batch size是训练batch size的G倍。7B模型、G8、max_new_tokens512的情况下单卡推理显存大概需要40-50G。如果显存不够有几个优化方向梯度检查点model.gradient_checkpointing_enable()省显存但慢20%左右DeepSpeed ZeRO-2/3多卡场景下用ZeRO-3把模型参数分片单卡显存能降到1/8vLLM推理把生成阶段交给vLLM速度提升3-5倍显存效率也更高减小G从8降到4显存减半但优势估计方差增大。我实际用的组合是DeepSpeed ZeRO-3 gradient checkpointing G88卡A100 80G7B模型per_device_batch_size2gradient_accumulation16总batch size256。训练速度大概每步3-4秒3个epoch跑完10万条数据大概需要2天。4. 常见问题排查与避坑指南4.1 训练不收敛或奖励不上升这是最常见的问题。排查顺序如下第一步检查奖励函数是否有信号。把模型输出和奖励值打印出来人工看几条。如果奖励全是0或者全是同一个值说明奖励函数没区分度。我遇到过一次奖励函数里的格式检查写错了所有输出都判为格式错误奖励恒为-1模型完全学不动。第二步检查组内是否有差异。如果G个输出的奖励完全一样优势全为0这个组不产生梯度。统计一下训练过程中“零优势组”的比例如果超过30%说明任务太简单或太难或者temperature太低导致输出多样性不足。第三步检查KL散度。如果KL散度在训练初期就爆炸比如超过10说明β太小或学习率太大。把β调大、学习率调小重新跑。第四步检查ratio分布。如果ratio大量撞到clip边界比如超过50%的token被clip说明策略更新太猛。调小学习率或调大β。4.2 输出重复、乱码或语言能力退化这是reward hacking的典型表现。模型发现某种重复模式能骗到高奖励就疯狂输出重复内容。解决办法加重复惩罚在奖励函数里检测n-gram重复重复就扣分加KL约束调大β让策略不要偏离参考模型太远加长度惩罚过长或过短的输出扣分人工审查定期抽样看模型输出发现异常及时调整。我踩过最坑的一次是奖励函数里有个“包含关键词就给分”的维度结果模型学会了在输出末尾堆砌关键词前面全是乱码。后来把关键词维度改成“关键词出现在正确位置才给分”问题才解决。4.3 显存溢出OOM的排查与解决OOM是工程上最烦人的问题。按以下顺序排查排查项可能原因解决办法生成阶段OOMbatch_size * G * max_new_tokens太大减小per_device_batch_size或G前向传播OOM模型参数量大、序列长开gradient checkpointing反向传播OOM梯度累积步数多、优化器状态大用ZeRO-2/3、8-bit AdamKL计算OOM同时加载策略和参考模型参考模型用CPU offload或量化提示KL计算需要同时拿到策略模型和参考模型对同一批token的概率。如果显存紧张可以把参考模型量化到8-bit或4-bit精度损失很小但显存省一半。4.4 组大小G的选择与权衡G的选择是一个典型的工程权衡G太小2-4优势估计方差大训练不稳定但推理成本低G太大16-32优势估计准确但推理成本线性增长训练速度慢G8大多数场景的甜点区方差和成本平衡较好。但这不是绝对的。如果你的任务奖励信号很稀疏比如只有0和1G需要大一些12-16才能保证组内有正有负。如果奖励是连续的、区分度高G4就够用。还有一个技巧动态组大小。训练初期用大G16保证优势估计质量训练后期策略逐渐收敛用小G4节省推理成本。这个在TRL里可以通过callback实现。4.5 常见问题速查表现象可能原因排查方法解决措施奖励不上升奖励函数无区分度打印奖励分布重新设计奖励函数奖励上升但输出变差reward hacking人工看输出加KL约束、加惩罚项训练loss震荡学习率太大看ratio和KL调小学习率、调大β零优势组比例高任务太难/太简单统计奖励方差调整任务难度、调temperature生成速度慢推理未优化profile生成阶段用vLLM、减小max_new_tokensKL散度爆炸β太小监控KL值调大β、调小学习率显存OOMbatch或序列太长看显存峰值减batch、开checkpointing、ZeRO5. GRPO的变体与扩展方向5.1 GRPO与因果强化学习的结合点最近因果强化学习Causal RL是个热词核心思路是把因果推断工具嵌入RL流程解决“相关不等于因果”的问题。GRPO和因果RL的结合点在于优势估计的因果校正。标准GRPO的组内优势Â_i (r_i - μ) / σ这个估计假设组内输出是可交换的即没有混淆变量。但在实际场景里prompt的难度、长度、领域都会影响奖励这些是混淆变量。如果不控制优势估计会有偏。一个可能的改进方向是在组内比较时对混淆变量做分层。比如按prompt难度分层在每个层内做组内标准化再加权汇总。这样得到的优势估计更接近因果效应而不是简单的相关性。这个方向目前还在研究中但思路是清晰的。如果你在做GRPO的定制化改进这是一个值得探索的点。5.2 离线GRPO与IQL的结合IQLImplicit Q-Learning是离线RL的代表算法核心是用expectile回归估计Q函数避免查询分布外动作。GRPO目前主要是在线算法需要实时采样。如果把GRPO和IQL结合一个可能的方案是用离线数据预训练一个Q函数IQL风格在线阶段用Q函数辅助组内优势估计而不是纯靠奖励均值这样可以在组大小G较小时仍然得到低方差的优势估计。这个思路的本质是用离线价值估计来弥补在线组采样的方差。工程上实现起来有一定复杂度但理论上很有吸引力。5.3 多模态场景下的GRPO适配GRPO目前主要在纯文本任务上验证。多模态场景图像文本下组采样的成本更高图像编码文本生成奖励函数也更复杂视觉质量文本质量。适配方向包括分层组采样图像层面采样少量文本层面采样多量多维度奖励分解视觉奖励和文本奖励分别标准化再加权合并跨模态KL约束分别约束视觉编码器和文本解码器的偏离程度。这些目前还没有成熟方案但GRPO的组内比较框架是通用的适配多模态只是奖励设计和采样策略的调整。6. 个人实操体会与建议GRPO是我过去一年里用得最多的RL算法从7B到32B模型都跑过。最大的体会是算法本身不复杂复杂的是奖励函数设计和工程调优。GRPO的目标函数一页纸就能写完但要让它在实际任务上work80%的精力花在奖励函数迭代和显存优化上。几个具体的建议第一先跑通小规模再放大。用1B模型、G4、100条数据先跑通全流程确认奖励能上升、输出不崩再换7B、G8、全量数据。我见过太多人直接上大模型全量数据跑了一天发现奖励函数写错了浪费大量算力。第二奖励函数从简到繁。初期只用1个核心维度比如答案正确性跑通了再加格式、长度、重复惩罚。每加一个维度都要重新验证确保新维度不会和旧维度冲突。第三监控三个核心指标奖励均值、KL散度、零优势组比例。这三个指标能覆盖90%的训练异常。奖励均值不涨说明奖励函数或学习率有问题KL散度爆炸说明β太小零优势组比例高说明任务难度或temperature需要调。第四组大小G不要死守8。根据任务调整奖励稀疏就调大奖励密集就调小训练初期调大后期调小。动态G是一个很实用的技巧。第五KL系数β用自适应。固定β很难适应训练全程。一个简单的自适应策略是如果KL 2 * target_KLβ * 1.5如果KL 0.5 * target_KLβ / 1.5。target_KL一般设0.01-0.05。最后分享一个小技巧在奖励函数里加一个“格式奖励”作为稳定器。即使任务奖励信号很稀疏格式奖励也能提供持续的梯度信号防止模型在训练初期完全学不动。等任务奖励逐渐起来后再降低格式奖励的权重。这个技巧在我做数学推理任务时特别管用训练初期模型连“把答案放在\boxed{}里”都学不会加了格式奖励后很快就稳定了。