grpo-rlvr-training

GRPO 与 RLVR 训练

本技能假设 finetuning-method-selection 已经将任务路由到这里，因为目标行为 具有可验证的通过/失败信号 —— 而不是 演示样本（lora-qlora-recipes）或 偏好对（preference-optimization）。 以下内容涵盖：何时 RL 才是正确的工具、 参考配方、强制性的奖励检查 关卡，以及当基础配方表现异常时 如何选择 GRPO 变体。

输入： 一个路由决策（通过 GRPO 进行 RLVR） 加上针对目标任务的一个验证器（代码执行器、测试套件、 模式检查器或评分器）。 输出格式： 一个经过验证的 GRPO 配置 —— references/grpo-memory.md 中的关键字参数值 以及 references/reward-functions.md 中的奖励函数，而非自由形式的 建议 —— 供 llm-finetuning-training-engineer 直接使用。

RL 何时适用

GRPO+RLVR 只有在任务成功与否 可由算法检查时才有价值 —— 单元测试 通过、解析器接受输出、工具调用 匹配预期模式、数学答案匹配 标准答案。如果给输出打分需要 人工判断或主观评分标准，那首先是一个 评测框架与评判校准问题 —— 参见 eval-harness-first —— 而不是直接跳到 RL 的理由。

在开启 GRPO 运行之前，确认模型 有时已经能在目标任务上成功。 RL 通过向已经奏效的样本重新加权 来锐化已有能力；它不会 从零安装一种能力。

• 模型从不成功，即使在低 温度下多次采样也是如此： 差距在于 格式或任务理解，而非策略 优化。先回到 SFT （lora-qlora-recipes），只有当 基础成功率为非零时 再回到本技能。
• 模型有时成功， 但不稳定： 这正是 GRPO 的最佳适用场景 —— 继续阅读下面的配方。

整个插件的常设规则：品味用 DPO， 推理用 GRPO。 如果信号是两个可接受输出之间的 偏好，那属于 preference-optimization，而非本技能。

配方

参考配方是 TRL 的 GRPOTrainer，配合 vLLM 支持的生成：

from trl import GRPOConfig, GRPOTrainer

grpo_args = GRPOConfig(
    output_dir="./outputs-grpo",
    use_vllm=True,
    vllm_mode="colocate",       # single GPU; "server" for multi-GPU
    num_generations=8,          # floor — fewer starves the group-relative baseline
    learning_rate=5e-7,         # settled range for GRPO
    beta=0.01,                  # KL coefficient vs the reference policy
    per_device_train_batch_size=8,
    gradient_accumulation_steps=4,
    bf16=True,
    logging_steps=10,
    seed=3407,
)

trainer = GRPOTrainer(
    model=SFT_CHECKPOINT,
    args=grpo_args,
    reward_funcs=[format_reward, correctness_reward],   # references/reward-functions.md
    train_dataset=prompts,       # prompt-only — GRPO generates its own completions
    processing_class=tokenizer,
)

trainer.train()

• vllm_mode="colocate" 在同一块 GPU 上 运行生成和训练 —— 这是单 GPU 机器的 默认值。
• vllm_mode="server" 指向一个独立的 vLLM 服务器进程，是多 GPU 路径 —— 生成和训练不会争用 同一设备。
• num_generations ≥ 8 是下限，而非 建议：GRPO 的优势估计是 相对于组均值而言的，每个提示词少于 8 个 样本会产生噪声很大的基线。
• 奖励是复合的 —— 一个格式奖励（输出 是否解析成功 / 匹配所需 结构）加上一个正确性奖励（答案 是否验证通过）。一个格式正确但错误 的答案和一个格式错误的答案不应得到 相同的分数；仅靠正确性会丢失这一 信号。
• learning_rate=5e-7 和 beta=0.01 是 确定的起始点；只有在 基础运行稳定并经过奖励检查 （见下文）后才偏离。

本配方按目标规模等级的 内存估算：references/grpo-memory.md。

检查规则

在开始正式训练运行之前，先用 50–100 条采样输出运行奖励函数，并人工阅读结果。 这是一道关卡，而不是一次性的健全性检查。

如果奖励函数的判断与该样本的人工阅读结果不一致，请先修复奖励函数。针对未经检查的奖励进行训练，或者通过调超参数来补偿某个正在悄悄打错分的奖励函数，正是运行发生奖励黑客的方式：模型会干净利落地朝错误目标优化，而这并不会以训练循环 bug 的形式暴露出来。

这项检查是 /finetune 的 Phase 1 关卡输入 —— 这里用于捕获损坏奖励函数的那 50–100 条样本阅读，正是该命令在允许 GRPO 简报继续之前所检查的内容。

可供检查对照的完整奖励函数实现 —— 精确匹配、schema 校验、单元测试执行、长度惩罚包装器，以及 rubric-as-reward 评判模式： references/reward-functions.md。

变体选择

上述基础配方是默认选项。只有在出现特定失败模式时才使用变体，不要预先使用：

失败模式	变体	原因
熵坍缩 / 退化的长思维链	DAPO	解耦裁剪边界，并放宽对长推理轨迹探索过度正则化的 KL 惩罚
奖励或输出长度无论质量如何都呈上升趋势	Dr.GRPO	移除 GRPO 的长度归一化偏差，使奖励跟踪正确性，而不是补全长度
训练专家混合模型	GSPO	将重要性采样比率移到序列级别，而不是逐 token —— 逐 token 比率在 MoE 路由上不稳定，因此这里必须使用 GSPO，而非可选

从普通 GRPO 开始。观察特定症状 —— 长 CoT 上的熵坍缩、长度与奖励的相关性，或 MoE 不稳定性 —— 然后才换入上面匹配的变体。不要在基础配方实际显示出失败模式之前就预先选择变体。

VLM RL 仅供参考

视觉语言 RL 在 v1 中不由本插件执行 —— 此处记录它是为了提供背景，而不是作为可运行路径。工具链分散在 ms-swift 和 EasyR1 派生的 fork 中，尚无一行式 TRL 命令，而且将朴素的纯文本 GRPO 应用于 VLM 往往会通过优化文本推理轨迹而忽略图像来发生奖励黑客 —— 模型学会听起来正确，却不看输入。VLM RL 运行是本研究 spike 之外的研究探索，不属于本技能支持的配方，也不是上述 The Recipe 的变体。

参考资料

• references/reward-functions.md —— 完整的 Python 奖励函数（精确匹配 正确性、schema 校验、单元测试 执行、长度惩罚包装器，以及 rubric-as-reward 评判模式），以便在任何训练运行之前 按 The Inspection Rule 进行检查。
• references/grpo-memory.md —— 按 目标规模类别进行内存估算、vLLM 睡眠模式和 优化器状态策略、Unsloth 的长上下文 RL 分块，以及针对解码密集型 rollout 的 DGX Spark 带宽注意事项。

相关技能：finetuning-method-selection 在存在可验证的通过/失败信号后路由到这里；preference-optimization 是 用于偏好对而非可验证 奖励的姊妹技能；eval-harness-first 涵盖任何并非纯 代码可检查奖励的评判器校准。在 DGX Spark 上，当安装了 dgx-spark-ops 插件时，请遵循其技能， 以获取本技能内存表未涵盖的 内存/热修复阶梯。