1. 大模型后训练的整体设计思路与方案选型1.1 为什么后训练是大模型落地的最后一公里预训练模型像是一个博览群书但不太会聊天的学者知识储备足够但输出风格、指令遵循能力、安全边界都不可控。后训练要解决的核心问题就是把一个“什么都懂一点但不太听话”的基座模型调教成一个“能按指令干活、输出稳定、边界清晰”的可用产品。这个过程大致分三步走SFT 教会模型“怎么说话”奖励建模教会模型“什么算说得好”PPO/GRPO 这类强化学习算法则让模型在探索中真正把“说得好”变成默认行为。我见过不少团队一上来就想直接上 RL跳过 SFT 或者 SFT 数据随便凑几千条结果训练曲线剧烈震荡最后归因到“RL 不稳定”。实际上绝大多数不稳定根源都在 SFT 阶段埋下的。SFT 决定了模型的输出分布起点RL 只是在这个起点附近做微调。起点歪了后面怎么调都费劲。1.2 SFT、奖励模型、RL 三者的分工与衔接SFT 的本质是行为克隆用高质量的“指令-回答”对做监督学习让模型学会基本的对话格式和任务模式。这个阶段的数据质量远比数量重要几千条精标数据往往比几十万条噪声数据效果好。奖励模型则是把人类偏好“压缩”成一个可微分的标量函数它不直接生成文本只负责打分。PPO 和 GRPO 这类算法就是拿奖励模型的分数当信号去优化策略模型的生成行为。三者的衔接有个容易被忽略的细节SFT 数据的分布要和 RL 阶段的任务分布对齐。如果 SFT 只教了问答RL 却想让模型学会写代码那策略模型在 RL 初期的探索空间会非常大训练效率极低。我的做法是SFT 阶段就覆盖目标任务的 80% 以上场景RL 只负责在已有能力上做偏好对齐和边界收紧。1.3 从 PPO 到 GRPO 的演进逻辑PPO 在大模型 RLHF 里用了很久它的核心是 Actor-Critic 架构需要同时维护策略模型、价值模型、奖励模型和参考模型四个网络。显存占用大、训练不稳定是常态。GRPO 的出现本质上是把价值模型这个“中间商”去掉用组内相对优势来替代绝对价值估计。同一个 prompt 采样多条回答用组内奖励的均值和标准差做归一化直接算出每条回答的优势值。这个改动看起来简单但影响很大。省掉价值模型后显存占用下降约 25% 到 30%训练速度提升明显。更重要的是组内归一化天然适配“同一问题多个回答比较”的场景和人类偏好的相对性更契合。不过 GRPO 也有代价它需要每个 prompt 采样多条回答采样成本比 PPO 高。实际选型时如果显存紧张、任务偏好差异明显GRPO 更合适如果采样预算有限、需要精细的逐步信用分配PPO 仍有优势。1.4 Reference 锚点在整个后训练中的角色Reference 模型是 RL 阶段的“锚”它通常是 SFT 后的模型副本参数冻结不更新。KL 散度惩罚项就是拿当前策略和 Reference 做比较防止策略跑偏太远。这个设计很关键没有 Reference 锚定策略模型会为了拿高奖励而输出奖励模型“喜欢”但人类看着别扭的文本也就是常说的 reward hacking。Reference 的更新策略也有讲究。固定不动是最常见的做法但如果 SFT 模型本身质量一般Reference 太“弱”会导致 KL 约束形同虚设。有些团队会定期用当前策略更新 Reference或者用多个 Reference 做插值。我的经验是Reference 至少要和 SFT 最终模型保持一致如果 SFT 阶段有多个 checkpoint选验证集表现最好的那个当 Reference不要用训练末期的过拟合版本。2. SFT 机制的核心细节与实操要点2.1 SFT 数据构造质量、多样性、难度的三角平衡SFT 数据不是越多越好这是我最想强调的一点。早期我也迷信数据量后来发现 5000 条精标数据在指令遵循任务上能打过 50000 条自动生成的数据。质量体现在三个方面回答准确、格式规范、风格一致。多样性则要求覆盖不同任务类型、不同输入长度、不同难度层级。难度这个维度最容易被忽略全是简单样本会让模型学不到推理能力全是难题又会让模型在简单任务上表现退化。我的做法是按 3:5:2 的比例分配简单、中等、困难样本。简单样本保证基础格式和常见问题中等样本覆盖主要业务场景困难样本提升推理和边界处理能力。每个任务类型至少 200 条低于这个数模型很难稳定学会。数据来源上人工标注优先模型生成加人工审核次之纯模型生成的数据只适合做格式冷启动。2.2 训练配置学习率、批次、序列长度的选择逻辑SFT 的学习率通常比预训练小一到两个数量级常见范围是 1e-5 到 5e-5。学习率太大模型会快速过拟合到 SFT 数据丢失预训练知识太小则收敛慢且容易陷入局部最优。我一般从 2e-5 开始试如果 loss 下降太慢就调到 5e-5如果验证集 loss 很快反弹就降到 1e-5。批次大小受显存限制但有个经验值全局批次不要小于 32否则梯度噪声太大。序列长度要覆盖 SFT 数据中 95% 以上的样本截断太多会让模型学不到长文本处理能力。如果显存不够优先用梯度累积而不是减小批次。训练轮数通常 2 到 3 轮就够超过 3 轮过拟合风险很高验证集 loss 会明显上升。2.3 损失函数与掩码策略只学该学的部分SFT 的损失函数是标准的交叉熵但关键在于 loss mask。对话数据里system prompt 和 user 输入部分不应该计算 loss只对 assistant 的回答部分计算。这个细节很多新手会忽略导致模型学会了“复述问题”而不是“回答问题”。具体实现上构造 labels 时把非 assistant 部分的 token 设为 -100PyTorch 的 CrossEntropyLoss 会自动忽略这些位置。如果是多轮对话每一轮的 assistant 回答都要计算 loss但前面的对话历史不计算。这个掩码策略直接影响模型是学会“对话”还是学会“续写”。2.4 SFT 阶段的常见坑与规避方法第一个坑是数据泄漏验证集和训练集有重叠导致验证指标虚高。我的做法是用 prompt 的哈希值做去重确保同一个问题的不同回答不会跨集合分布。第二个坑是格式不一致有的回答带 markdown有的不带模型会学得混乱。统一格式模板哪怕模板简单一点也比混乱强。第三个坑是忽略特殊 token比如 pad token 和 eos token 的处理处理不当会导致生成停不下来或者提前截断。还有一个隐蔽的坑是学习率预热。SFT 数据量小预热步数设太大模型还没预热完就训练结束了。我一般把预热步数设为总步数的 3% 到 5%数据量特别小的时候直接关掉预热。3. PPO 与 GRPO 的算法拆解与实现细节3.1 PPO 在大模型 RLHF 中的适配改造原始 PPO 是为连续控制设计的搬到语言模型上需要几处关键改造。首先是动作空间语言模型的动作是词表上的概率分布不是连续值。其次是价值模型原始 PPO 的价值网络输出单个标量语言模型的价值模型通常和策略模型共享底层只在最后加一个 value head。第三是奖励设计语言模型的奖励通常在序列末尾给一个标量而不是每步都给。PPO 的裁剪目标函数是核心它限制了新旧策略的概率比在 [1-ε, 1ε] 范围内。ε 通常设 0.1 到 0.2。这个裁剪防止单次更新步子太大是 PPO 稳定性的来源。但语言模型里token 级别的概率比乘积容易数值不稳定实践中常用对数概率差来做裁剪。3.2 GRPO 的组内归一化机制与优势计算GRPO 的核心改动是去掉价值模型用组内相对奖励替代。具体流程是对每个 prompt 采样 G 条回答分别用奖励模型打分然后对 G 个分数做归一化得到每条回答的优势值。归一化公式是 (r_i - mean(r)) / std(r)。这个优势值直接乘到对数概率上作为策略梯度的权重。这个设计的巧妙之处在于它不需要价值模型来估计基线组内均值天然就是基线。而且组内归一化自动适应了不同 prompt 的奖励尺度差异有的 prompt 奖励普遍高有的普遍低归一化后都变成相对比较。不过 G 的选择有讲究太小比如 2方差大太大比如 16采样成本高。我一般用 4 到 8任务难度大就用 8简单任务用 4。3.3 KL 惩罚项的计算与 Reference 锚点博弈KL 惩罚项是策略模型和 Reference 模型之间的 KL 散度乘以系数 β 后加到奖励里。β 的选择是个博弈太大策略不敢偏离 Reference学不到新东西太小策略跑偏reward hacking 严重。常见范围是 0.01 到 0.1。我的经验是SFT 模型质量高就设小一点0.01 到 0.03质量一般就设大一点0.05 到 0.1。KL 的计算有两种方式一种是精确计算每个 token 的 KL另一种是用采样估计。精确计算更稳定但显存占用大采样估计省显存但有方差。实践中常用 k3 估计器它在 β 较小时偏差小。Reference 锚点的博弈还体现在更新频率上固定 Reference 最简单但策略跑远后 KL 约束会失效。有些实现会每隔一定步数用当前策略更新 Reference但这会引入新的不稳定性需要谨慎。3.4 采样策略与批次组织效率与稳定性的权衡RL 阶段的采样是瓶颈。每个 prompt 要采样多条回答采样长度、温度、top-p 都影响训练效果。温度太高回答质量差奖励信号噪声大温度太低回答多样性不足组内优势区分度低。我一般用 0.7 到 1.0 的温度top-p 用 0.9 到 0.95。批次组织上PPO 通常把多个 prompt 的回答拼成一个大批次但每个 prompt 的回答长度不同padding 会浪费显存。GRPO 因为要组内比较必须保证同一 prompt 的多条回答在同一个批次里。我的做法是按长度分桶同一桶内的 prompt 一起采样减少 padding 浪费。采样阶段用 vLLM 或类似的高效推理引擎比 HuggingFace 原生生成快 5 到 10 倍。4. 实操过程与核心环节实现4.1 环境准备与依赖版本锁定后训练对环境敏感版本不匹配会导致各种诡异错误。我用的组合是 PyTorch 2.1 以上、Transformers 4.36 以上、TRL 0.7 以上、DeepSpeed 0.12 以上。如果要用 vLLM 做采样vLLM 版本要和 Transformers 兼容否则 tokenizer 行为不一致会导致概率计算错误。显存方面7B 模型做 PPO 需要至少 4 张 40G 的卡GRPO 因为省了价值模型3 张 40G 可以跑起来。如果显存不够用 LoRA 微调策略模型Reference 用全精度但冻结这样显存能降到 2 张卡。不过 LoRA 的 RL 训练稳定性不如全参数需要更小的学习率和更大的 KL 系数。4.2 SFT 训练脚本的关键参数配置以下是一个可参考的 SFT 训练配置片段基于 HuggingFace Trainertraining_args TrainingArguments( output_dir./sft_output, num_train_epochs3, per_device_train_batch_size4, gradient_accumulation_steps8, learning_rate2e-5, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_strategyepoch, evaluation_strategyepoch, bf16True, gradient_checkpointingTrue, max_seq_length2048, remove_unused_columnsFalse, )关键点是remove_unused_columnsFalse因为 SFT 数据里有 labels 列默认会被移除。gradient_checkpointingTrue省显存但慢 20% 左右。bf16比fp16稳定优先用 bf16。4.3 奖励模型训练与校准奖励模型通常用 Pairwise 数据训练输入是一个 prompt 和两个回答输出是哪个更好的偏好概率。损失函数是 Bradley-Terry 模型的负对数似然。训练完后要做校准确保奖励分数的分布合理。我一般会留一个校准集检查奖励模型对明显好和明显差的回答是否能给出区分度足够的分数。奖励模型的过拟合很常见因为偏好数据往往有标注者偏差。缓解方法是加入一定比例的“平局”样本让模型学会处理难以区分的情况。另外奖励模型的输出最好做归一化减掉均值除以标准差这样 RL 阶段的奖励尺度更稳定。4.4 GRPO 训练循环的完整实现GRPO 的训练循环大致如下对每个 batch 的 prompt用当前策略采样 G 条回答用奖励模型给每条回答打分计算组内均值和标准差得到优势值计算当前策略和 Reference 的对数概率计算 KL 惩罚组合成最终损失反向传播更新策略。for batch in dataloader: prompts batch[prompts] with torch.no_grad(): responses policy.generate(prompts, num_return_sequencesG, temperature0.8) rewards reward_model(prompts, responses) rewards rewards.view(-1, G) advantages (rewards - rewards.mean(dim1, keepdimTrue)) / (rewards.std(dim1, keepdimTrue) 1e-8) advantages advantages.view(-1) log_probs policy.log_prob(prompts, responses) ref_log_probs reference.log_prob(prompts, responses) kl log_probs - ref_log_probs loss -(advantages * log_probs - beta * kl).mean() loss.backward() optimizer.step()实际实现里还要处理 padding、mask、梯度裁剪等细节。梯度裁剪的 max_norm 一般设 1.0防止梯度爆炸。4.5 训练监控与关键指标解读RL 训练要盯几个指标奖励均值、KL 散度、回答长度、策略熵。奖励均值应该缓慢上升然后趋于平稳如果突然飙升大概率是 reward hacking。KL 散度应该保持在 β 对应的合理范围内如果持续增大说明策略跑偏。回答长度如果突然变短可能是模型学会了“少说少错”。策略熵下降太快说明探索不足下降太慢说明学习效率低。我习惯每 50 步打印一次这些指标并保存 checkpoint。如果奖励上升但人工评估变差立即回滚到上一个 checkpoint。这个“奖励-人工”背离是 RL 训练最危险的信号说明奖励模型被钻了空子。5. 常见问题与排查技巧实录5.1 训练不收敛或奖励震荡的排查路径奖励震荡最常见的原因是学习率太大或批次太小。先降学习率到 1e-6 试如果还震荡增大批次或梯度累积。另一个原因是 KL 系数太小策略跑得太远奖励模型失效。把 β 调大 2 到 3 倍试试。还有可能是奖励模型本身不稳定检查奖励模型在验证集上的排序准确率低于 60% 的话先重新训练奖励模型。GRPO 特有的问题是组内奖励全相同优势值全为零梯度消失。这通常发生在任务太简单或太难的时候。简单任务所有回答都对奖励没区分度太难任务所有回答都错也没区分度。解决方法是调整任务难度分布或者用动态采样跳过优势值全零的组。5.2 Reference 模型导致的 KL 异常处理KL 散度异常增大通常是 Reference 和策略的 tokenizer 不一致或者 Reference 加载时精度不对。检查两者的 tokenizer 配置是否完全一致包括特殊 token 的 id。如果 Reference 用 fp16 加载而策略用 bf16KL 计算会有偏差统一精度。还有一种情况是 Reference 本身质量差策略稍微偏离就产生大 KL。这时候要么换更好的 SFT checkpoint 当 Reference要么把 β 调小给策略更多空间。但 β 调小有 reward hacking 风险需要配合人工评估。5.3 显存不足与训练速度优化显存不足优先用梯度检查点、LoRA、DeepSpeed ZeRO 三个阶段。ZeRO-2 优化梯度和优化器状态ZeRO-3 还优化参数但通信开销大。单机多卡用 ZeRO-2 通常够多机多卡才需要 ZeRO-3。采样阶段用 vLLM 的 PagedAttention显存利用率比 HuggingFace 高很多。训练速度优化上把采样和训练分开到不同 GPU 组采样用推理优化引擎训练用 DeepSpeed。数据加载用多进程num_workers 设为 CPU 核数的 70% 左右。日志和 checkpoint 保存不要同步做用异步保存避免阻塞训练。5.4 常见错误速查表错误现象可能原因排查方法解决方案loss 变 NaN学习率太大或梯度爆炸检查梯度范数降学习率加梯度裁剪奖励不上升KL 系数太大或奖励模型差检查 KL 值和奖励模型准确率降 β重训奖励模型回答长度骤降奖励偏好短回答检查奖励模型对长度的偏好加长度惩罚或调整奖励显存 OOM批次太大或序列太长检查显存占用峰值减批次开梯度检查点生成重复文本温度太低或 top-p 太小检查采样参数调高温度到 0.8 以上KL 突然飙升Reference 不一致对比 tokenizer 和精度统一配置重载 Reference5.5 独家避坑经验分享第一个经验是SFT 阶段就要开始记录验证集的人工评估结果不要只看 loss。loss 低不代表模型好用很多时候 loss 降了但模型变得啰嗦或格式混乱。第二个经验是RL 训练前先用小规模数据跑通全流程确认奖励模型、KL 计算、采样都没问题再上大规模。我见过太多团队直接上全量数据跑了三天发现 KL 计算有 bug全部重来。第三个经验是GRPO 的 G 值不要设太大4 到 8 足够。设 16 的话采样成本翻倍但效果提升有限。第四个经验是Reference 模型不要用训练末期的 SFT checkpoint用验证集最好的那个。训练末期的模型往往过拟合当 Reference 会把策略也带偏。第五个经验是奖励模型的输出最好做 running normalization减掉滑动均值除以滑动标准差这样奖励尺度稳定KL 系数不用频繁调。最后说一个关于 PPO 和 GRPO 选择的实际体会。如果团队显存充足、追求精细控制PPO 仍然可靠如果显存紧张、任务偏好差异明显、采样预算够GRPO 是更现代的选择。两者没有绝对优劣关键看资源和任务匹配度。我在实际项目里7B 以下模型用 GRPO 居多13B 以上因为显存压力反而更倾向 PPO 加 LoRA 的组合。这个选择没有标准答案跑通小规模实验看哪个稳定就用哪个。