上一篇文章详细拆解了PPO后训练中的四个角色：actor作为接收策略损失（policy loss）更新的主策略，critic则专为PPO/GAE提供价值基准（value baseline）。那么一个更深入的问题随之而来——GRPO为何能直接舍弃critic这一路径？

核心要点在于：GRPO并非完全没有baseline，而是将baseline从可学习的critic value替换为同一提示（prompt）下多条响应（response）的组内相对奖励（group-relative reward）。如此一来，优势函数（advantage）的计算不再需要values字段，系统层面自然省去了value forward和critic train两条路径；但相应的代价也出现了——rollout.n、奖励方差、组内样本质量以及长度偏置变得尤为关键。

首先来看GRPO的核心闭环流程。阅读此图时，请特别关注uid字段：它将同一prompt下的多条response绑定为一个组，使得后续的相对奖励（relative reward）能够进行有意义的比较。

GRPO的组内相对奖励（group-relative）闭环示意图

此图对应于examples/grpo_trainer/README.md中关于GRPO的描述：通过组采样（group sampling）为同一输入生成多条补全（completion），然后利用组内平均奖励作为baseline，增强高于平均值的response，抑制低于平均值的response（examples/grpo_trainer/README.md:5-9）。同时，README还将actor_rollout_ref.rollout.n列为GRPO的关键调控参数，并指出总轨迹数为train_batch_size * rollout.n（examples/grpo_trainer/README.md:21-23）。

1. 组采样（group sampling）是去除critic的前提条件

GRPO的前提并非“每个prompt只生成一条response”，而是“同一prompt需生成多条response”。在RayPPOTrainer.fit()中，训练器会给原始样本添加uid字段，然后将gen_batch按rollout.n进行重复（repeat）；生成完成后，主batch也按照相同的倍数重复，并与rollout输出执行union()操作（verl/trainer/ppo/ray_trainer.py:1330-1407）。

这一步骤使DataProto中形成了一种结构：多行样本共享同一个uid，但各自的responses、reward和logprob各不相同。GRPO的baseline正是源于这种结构。如果没有这样的分组，只有单条response，那么组内平均便失去了统计意义；源码中规定，如果某个uid仅有一个score，则将mean设为0、std设为1，这是一个兜底方案，并非理想的训练形态（verl/trainer/ppo/core_algos.py:314-321）。

这也解释了为何GRPO对rollout吞吐量更为敏感。去除critic后，系统虽减少了一条训练链路，但每个prompt需要生成多条response，这导致rollout阶段的token数量、长尾response以及reward调用次数均被放大。

2. 源码分叉点在于advantage计算，而非actor损失函数

PPO与GRPO的actor更新机制都同样会通过策略损失（policy loss）进行。真正的差异在于advantage的计算方式。

compute_advantage()中的GAE分支会将token_level_rewards、values和response_mask传递给compute_gae_advantage_return()，然后将结果写回advantages和returns（verl/trainer/ppo/ray_trainer.py:166-182）。而GRPO分支则仅将token_level_rewards、response_mask以及data.non_tensor_batch["uid"]传递给compute_grpo_outcome_advantage()（verl/trainer/ppo/ray_trainer.py:183-195）。

下图展示了资源路径的差异。重点强调：GRPO所省略的不是reward、old logprob或actor update，而是critic value与critic train。

PPO与GRPO资源路径对比图

在资源层面，这一差异非常直接。PPO/GAE需要先调用_compute_values()获取values，然后在更新阶段调用_update_critic()训练value model（verl/trainer/ppo/ray_trainer.py:1130-1142，verl/trainer/ppo/ray_trainer.py:1247-1272）。而GRPO的advantage分支并不消费values，因此在它的必要路径中不包含这两步。

3. GRPO的字段依赖范围更窄

判断一个算法在工程实现中是否可以省略某个worker，最可靠的方式并非查看算法名称，而是分析它消费了哪些字段。

compute_grpo_outcome_advantage()首先沿response维度对token_level_rewards求和，得到每条response的outcome score；接着按照index（即uid）将同组score收集起来，计算组内的均值（mean）和标准差（std）；最后将归一化后的标量乘以response_mask，广播为token级别的advantages，并将同一张量同时作为returns返回（verl/trainer/ppo/core_algos.py:267-331）。

下图单独列出了字段依赖关系。看图时请留意红色叉号：values是PPO/GAE的输入，而非GRPO分支的输入。

GRPO的DataProto字段依赖图

这也定义了GRPO的工程边界：它仍然需要old_log_probs来构建actor loss，需要response_mask来限定有效token，需要reward来提供outcome score；唯一不同的是，它不再需要critic来预测一个value baseline。

4. 去除critic后，压力转向采样、奖励与长度管理

GRPO的收益显而易见：少了一个value model，减少了一次value forward，省去了一条critic train链路，同时降低了显存占用和调度复杂度。然而，这些收益并非没有代价。

第一，rollout.n成为了同时影响算法质量与系统吞吐量的关键参数。n值过小，组内相对比较将不稳定；n值过大，生成过程、reward、logprob以及DataProto字段都会被放大。README中将data.train_batch_size * rollout.n明确指定为总轨迹数，正是出于这个原因（examples/grpo_trainer/README.md:21-23）。

第二，reward的方差变得至关重要。GRPO利用组内reward的相对差异来引导actor的更新方向。如果同组response的reward完全相同，relative advantage将趋于退化；如果reward中存在较大噪声，模型则会跟随噪声进行更新。

第三，长度偏置问题将更加明显。compute_grpo_outcome_advantage()将outcome reward的相对标量乘到每个有效response token上（verl/trainer/ppo/core_algos.py:329-331）；而actor loss又通过loss_agg_mode聚合token loss（verl/trainer/ppo/core_algos.py:1141-1199）。长答案与短答案在token维度上的权重差异，无法被critic自动抵消。

最后一张图将这些权衡汇总在一起。它与前面“去除critic”的讨论形成互补：舍弃了哪条路径，就需要在相应环节加强管理。

GRPO去除critic后的权衡全景图

从系统角度审视，GRPO将复杂性从value model转移到了rollout、reward以及loss聚合上。它使得角色架构更轻量，但同时也凸显了样本组织、reward形态以及长度处理的重要性。

小结：GRPO去除的是critic路径，而非训练约束

GRPO能够去除critic，是因为其advantage并非来自value model，而是来自同一prompt下多条response的相对reward。源码中的证据十分明确：GRPO分支不读取values，而是读取token_level_rewards、response_mask和uid。

但这并不意味着GRPO简单到没有系统问题。它只是将critic的建模与训练成本，转换为了组采样（group sampling）、reward可靠性、rollout吞吐量、长度偏置以及loss聚合等方面的工程约束。

下一篇将继续沿着这些约束进行探讨：DAPO-style方案和Dr. GRPO并非新增一个worker，而是在GRPO的主线上处理过长的reward、advantage归一化以及token/sequence聚合所带来的长度偏置问题。

本文源码索引