策略梯度（GRPO）

0. 任务目标

第 6 章把策略梯度的整个算法族压缩成了一个式子：

所有算法的差别只在两条轴上：$\Psi_t$（「刚才那次到底好不好」）怎么估，以及更新怎么被约束住。GRPO 在第一条轴上给出的答案特别简洁——同一个 prompt 采一组回复，用组内的 z-score 当优势，从而彻底省掉了 PPO 里那个学出来的价值模型。

这一组作业的目标不是「把 spell_backward 刷到 100%」，而是让你亲手把在线 RL 循环的每个环节看一遍，并建立三个判断力：(1) 知道该看哪些数——策略梯度的 loss 几乎没有解释性，真正的信号是奖励分量；(2) 知道 GRPO 空转时长什么样——组内 rollout 全对或全错时优势恒为 0、梯度为 0，训练在「正常运行」的外表下什么都没学到，第 4 节整节讲它；(3) 知道在线 RL 的算力账怎么算——每个优化步都要先做一次批量生成，生成远比反向传播贵。

1. 运行命令与循环结构

上游给出的起始命令是：

cd _src/code/
uv sync

# 可选：把指标打到自己的 W&B（不设则用 configs 里的 wandb_project）
export WANDB_PROJECT=rlhf-book

python -m policy_gradients.train --config policy_gradients/configs/grpo.yaml

建议同时用指标包装器把逐步指标落盘（上游每步指标只进 wandb，控制台只有进度条）：

METRICS_JSONL=homework/hw3-pg/logs/metrics_grpo.jsonl \
WANDB_MODE=disabled \
python homework/tools/run_with_metrics.py policy_gradients.train \
    --config policy_gradients/configs/grpo.yaml

这个包装器的原理和注意事项见 HW4 第 6 节——它对本组同样适用，因为 policy_gradients/train.py 用的是同一套 wandb.log 约定。

一个训练步里发生了什么

照着 train.py 和 rollout.py 读一遍，一个 step 的骨架是：取 prompts_per_step 个题目 → 每题采 num_rollouts 条回复（这就是 GRPO 的「组」）→ compute_rewards 用环境的 score_answer 判定正确性并加上格式奖励 → compute_advantages 按损失类型算优势 → 按 train_batch_size × batch_acc 做梯度累积并更新。

注意其中两个「批大小」是独立的概念：prompts_per_step × num_rollouts 决定这一步用多少样本估梯度（统计意义上的 batch），train_batch_size 只决定一次前向塞多少条进显存（工程意义上的 micro-batch）。前者改了算法行为，后者只改显存占用。

2. grpo.yaml 逐项拆解

上游配置全文（_src/code/policy_gradients/configs/grpo.yaml）：

data:
  size: 3000
  specs:
    - name: spell_backward
      weight: 1
      config:
        min_word_len: 3
        max_word_len: 10

loss: grpo
model_name: Qwen/Qwen3-1.7B
clip_eps_lo: 0.2
clip_eps_hi: 0.2
beta: 0.0            # KL penalty coefficient (0 = disabled)
kl_estimator: kl3
lr: 5e-6
temperature: 0.6
top_p: 0.95
top_k: 20
min_p: 0.0
max_new_tokens: 512
prompts_per_step: 4
num_rollouts: 8
train_batch_size: 2
batch_acc: 4
max_norm: 1.0
seed: 42
model_device_id: 0

任务与数据

算法与更新约束

采样设置（在线 RL 特有，也最容易被忽视）

批大小与优化

3. 该盯哪些指标

先把奖励是怎么合成的看清楚，否则指标名只是三个单词。utils.py::compute_rewards 的逻辑是：

correctness = _correctness_reward(dataset, completions, entries)  # 环境判定
penalty     = _response_penalties(lengths, cfg)                   # 非 DAPO 时恒为 0
format      = _format_reward(completions)                         # 见下

total = correctness + penalty + cfg.format_weight * format
binary = correctness * (format == 1.0)

其中格式奖励是四个标签各 0.25 分：

<think>   +0.25
</think>  +0.25
<answer>  +0.25
</answer> +0.25

训练循环每步把这些分量取均值，以 avg_<key> 的形式记录。你会看到 avg_total、avg_correctness、avg_format、avg_penalty、avg_binary，另有 loss 和 grad_norm。

三个核心指标

还要看文本本身

参考实现每步都会打印一次 rollout 样本和各奖励分量的均值。请真的去读那些文本，尤其是训练早期——程序化任务的好处就在这里：单词倒着拼对没对，你零点几秒就能判断，而这个判断是任何聚合指标都给不了的。

值得留意的定性现象：模型有没有真的在 <think> 里做逐字母分解；是不是学会了把标签写全但内容空洞（典型的奖励 hack）；回复是不是撞到 max_new_tokens 被截断（截断通常判失败，看起来像「变笨了」，其实是长度预算问题）。

4. 组内对比度：GRPO 空转的头号原因

这是本组作业真正要教的东西。第一个该问的问题不是「正确率涨了吗」，而是「每个 prompt 组里有没有对比度」。

为什么优势会恒等于 0

GRPO 的优势就是组内 z-score。utils.py::compute_standardized_advantages 一行写完：

def compute_standardized_advantages(rewards, eps=1e-8):
    return (rewards - rewards.mean(dim=0, keepdim=True)) / (rewards.std(dim=0, keepdim=True) + eps)

写成公式，对一个大小为 $G$ 的组：

现在考虑一组 8 条 completion 全对（或全错）的情形：所有 $r_i$ 相等 $\Rightarrow$ $\mu_G = r_i$ $\Rightarrow$ 分子逐项为 0，$\sigma_G = 0$。于是

那个 eps 的唯一作用是防止 0/0 变成 NaN——它救的是数值稳定性，不是学习信号。优势全 0，损失里的 $\Psi_t$ 全 0，这一组对梯度的贡献严格等于零。

怎么诊断

诊断方法很直接：记录零方差组的占比随训练步数的变化。上游没有专门 log 这个量，但它就在 rollout.py 里唾手可得——rewards["total"] 的 shape 就是 [num_rollouts, 1]，加一行 .std() 即可。本组建议你自己把这个指标加上去，它比任何现成指标都更能解释训练为什么不动。粗糙一点的读法是看每步打印的 rollout 面板：correctness 长期贴 0 或贴 1 不动，问题就不在优化器，而在采样设置或任务难度。

DAPO 是怎么处理这件事的

值得对照着看一眼 rollout.py::_dapo_filter：

def _dapo_filter(self, exp):
    """Drop the group if every completion has min or max correctness."""
    correctness = exp.rewards["correctness"]
    all_min = (correctness == self.cfg.accuracy_min_reward).all()
    all_max = (correctness == self.cfg.accuracy_max_reward).all()
    if all_min or all_max:
        return None
    return exp

DAPO 的「动态采样（dynamic sampling）」就是把零对比度的组直接丢掉，然后继续采样直到凑满一个 batch。这不改变数学，只改变每步实际参与更新的有效样本数——在正确率接近饱和的阶段，差别可以非常大。跑 dapo.yaml 对比 grpo.yaml 时的重点就是：为了凑满一个 batch，DAPO 需要多采多少条？这其实就是「零对比度组占比」的另一种测量方式。

5. 显存：为什么本机跑不动，以及怎么换基座

本组没能实跑的原因很具体。本机是 2 × RTX 5080（各 16303 MiB），但另一个进程常驻占用 GPU0 约 8.35 GiB、GPU1 约 11.4 GiB，所有实验只能在 GPU0 剩余的约 6.9 GiB 里完成。而上游 grpo.yaml 的默认基座是 Qwen/Qwen3-1.7B，做全参数训练。

算一笔显存账

1.7B 参数的全参数在线 RL 训练，显存要装下这些东西：

上游 README 给出的参考是：策略梯度训练 Qwen3-1.7B 约需 16GB 单卡。约 6.9 GiB 显然不够，这就是本组停在这里的原因——不是代码问题，是资源问题。跑之前先用 nvidia-smi 确认卡上还剩多少：「16GB 的卡」和「16GB 可用」是两件完全不同的事。

换小基座的思路

要在这种预算下跑通，可行的方向按「性价比」排序：

1. 换更小的基座。上游 CLAUDE.md 给出的经验值是 Qwen3-0.6B 约 4GB、Qwen3-1.7B 约 8–10GB（无 LoRA 全量微调）。把 model_name 换成 0.6B 量级的模型是最直接的一步。注意：换基座之后学习率必须重新扫——HW4 用实测数据证明了照抄学习率的后果。
2. 降低生成压力。max_new_tokens 从 512 降下来，prompts_per_step 和 train_batch_size 调小。但 num_rollouts 要非常谨慎地动——它直接决定组内对比度（第 4 节），砍它等于砍掉学习信号本身。宁可砍 prompts_per_step 也别砍 num_rollouts。
3. 开梯度检查点。上游经验是省 30–40% 显存，代价是重算激活。注意它会禁用 KV cache，生成阶段要记得关掉再开。
4. 确认 beta: 0.0。只要 KL 惩罚是关的，就不会加载参考模型，省下整整一份权重。默认配置已经是关的，别手贱打开。
5. 避开 PPO。ppo.yaml 需要额外的价值模型（权重 + 优化器状态），是所有配置里最吃显存的。显存紧张时 GRPO 恰恰是最合适的选择——这也正是 GRPO 被发明出来的动机之一。

6. 自选消融

消融一：扫「对比度旋钮」

复制 grpo.yaml，一次只改一项：

每一组都请同时记录「零方差组占比」（第 4 节的自定义指标）。这个实验的意义在于：它让「$G$、temperature、题目难度共同决定了组内有没有可学的差异」这件事，从一句话变成一张你自己画出来的曲线。

另外，min_word_len / max_word_len 是最干净的难度旋钮：把它们调到「当前模型大约一半能做对」的区间，理论上信息量最大，值得自己验证。

消融二：REINFORCE / RLOO / GRPO 三者对比

python -m policy_gradients.train --config policy_gradients/configs/reinforce.yaml
python -m policy_gradients.train --config policy_gradients/configs/rloo.yaml
python -m policy_gradients.train --config policy_gradients/configs/grpo.yaml

这三个配置的差别本质上只在优势怎么算（utils.py::compute_advantages 里三行分支）：

对比两件事：正确性信号上升得多快，以及损失曲线有多抖。第 6 章的理论预测是 RLOO/GRPO 的梯度方差明显更小，这个对比会让「组内 baseline 到底有什么用」比任何公式都直观。注意三份配置的 data.size 并不相同（REINFORCE 15000、RLOO 1000、GRPO 3000），做严格对比时要对齐「消耗的生成算力」而不是「优化步数」。

消融三：再往变体家族里走一步

• drgrpo.yaml vs grpo.yaml：Dr. GRPO 去掉了 std 归一化（compute_nonstandardized_advantages 就是不除 $\sigma_G$）。第 6 章讲的「std 归一化会引入对低方差问题的偏好偏置」在这里可以实测。
• dapo.yaml vs grpo.yaml：观察动态采样把零对比度组丢掉之后，有效样本数怎么变，以及为凑满 batch 需要多采多少。
• 打开 KL 惩罚：把 beta 从 0.0 调到一个小的正值，观察正确率上升速度和「回复漂移程度」的权衡。注意这会多加载一份参考模型，显存要留够。

本组小结

交付物清单

• 你实际使用的配置文件（如果换了基座或改了任何超参，把改动和理由一并记下来）。
• 完整日志 + 逐步指标 JSONL（用 homework/tools/run_with_metrics.py 落盘）。
• 一张随步数变化的表或图，至少包含 avg_correctness、avg_format、avg_binary 三条曲线。
• 组内对比度的统计：零方差组占比随训练怎么变。这是本组作业真正的核心交付物。
• 训练前后各若干条 rollout 原文，用来说明模型的行为变化（或没有变化）。