1. 为什么2025年还需要一本“后训练手册”如果你在过去一年里真正动手训过模型大概率会有一种割裂感预训练的门槛被开源社区拉得越来越低几百张卡就能跑出一个能说人话的底座但真正决定一个模型能不能上线、能不能卖钱、能不能在业务里扛住压力的几乎全在**后训练Post-Training**这一段。我身边做应用落地的朋友十个里有八个卡在同一个地方——底座选好了SFT数据也标了DPO也跑了结果模型要么变得又犟又啰嗦要么在评测集上分数漂亮、一到真实场景就露馅。这份《LLM Post-Training Handbook》想解决的就是这种“知道有这些技术名词但不知道什么时候用哪个、参数怎么调、坑在哪”的状态。它不是一篇论文综述而是一份可以放在手边、边做边翻的实操手册。适合三类人一是刚从传统机器学习转过来、第一次接手对齐任务的工程师二是带小团队做垂直领域模型、预算有限但要求效果的产品技术负责人三是已经跑通过一轮SFT、想搞清楚DPO、PPO、GRPO这些方法到底差在哪的进阶玩家。我自己的判断是2025年这个时间点特别关键。一方面开源底座的能力已经足够强很多场景下你不需要从零预训练后训练成了性价比最高的一环另一方面后训练的工具链在过去一年里快速收敛像TRL、Unsloth、Axolotl这些框架把很多脏活封装掉了但封装得越好越容易让人忽略底层逻辑出了问题完全不知道怎么排查。所以这份手册的定位很明确把后训练从“玄学调参”拉回到“可解释的工程流程”。下面我会按照一份手册该有的结构把整体设计思路、核心方法拆解、完整实操流程、常见问题排查这几块讲透。每一块都会给出我实际踩过的坑和对应的处理方式能直接抄的配置我会尽量给全。2. 后训练整体设计与方法选型思路2.1 后训练到底在解决什么问题先把概念理清楚。预训练做的是“压缩世界知识”让模型学会预测下一个token后训练做的是“把知识变成可用的行为”让模型知道在什么场景下该说什么话、不该说什么话、以什么格式说。这两件事的目标函数完全不同所以你不能指望预训练阶段顺便把对齐也做了。后训练通常包含三个层次我习惯按“由浅入深”排指令微调SFT教模型听懂指令、按格式输出。这是最基础的一层数据质量决定上限。偏好对齐Preference Alignment让模型的输出更符合人类偏好比如更有用、更无害、更诚实。DPO、PPO、GRPO都属于这一层。推理增强Reasoning Enhancement针对数学、代码、逻辑推理等任务通过拒绝采样、过程奖励、强化学习等方式提升模型的“思考深度”。这三层不是必须全做而是根据你的场景选。比如做一个客服问答机器人SFT加轻量DPO就够了做一个数学解题助手那推理增强这一层绕不开。2.2 方法选型的核心权衡成本、稳定性、效果选方法的时候我一般看三个维度算力成本、训练稳定性、最终效果上限。这三者往往互相制约没有哪个方法全面占优。方法算力成本稳定性效果上限适用场景SFT低高中所有场景的起点DPO中中高中高有偏好数据、想快速对齐PPO高低高有奖励模型、追求极致效果GRPO中高中高推理任务、无需价值网络拒绝采样微调中高中高推理增强、数据可自动生成这张表是我自己用下来的体感不是绝对结论。比如DPO在数据质量高的时候效果可以逼近PPO但数据一脏就容易崩PPO效果上限高但调参难度和算力消耗让很多小团队望而却步。GRPO是这两年比较火的方向它去掉了PPO里的价值网络用组内相对奖励来估计优势显存占用和调参复杂度都降了一截特别适合推理类任务。2.3 为什么我把SFT数据质量放在第一位我见过太多团队SFT数据随便找开源数据集拼一拼然后花大力气调DPO的beta参数结果怎么调都不对。问题根本不在对齐阶段而在SFT阶段模型就没学好。SFT数据的核心不是“多”而是“一致”。什么叫一致就是同样类型的指令输出格式、语气、详细程度要统一。比如你做一个法律咨询助手有的样本回答得像法条有的像聊天模型学完就会精神分裂。我一般会做三件事去重和清洗用embedding做语义去重把相似度超过0.9的样本合并或删掉。格式归一统一system prompt、统一输出结构比如都用markdown、都带引用来源。难度分层把简单指令和复杂指令分开训练时按课程学习的方式逐步加入。提示SFT阶段如果发现loss下降很快但生成质量没提升大概率是数据太简单或者重复太多模型在背答案而不是学行为。2.4 对齐阶段的方法组合策略实际项目里我很少只用一种方法。比较稳的组合是SFT打底 DPO快速对齐 拒绝采样补推理。如果算力充足且追求极致再把DPO换成PPO或GRPO。为什么这么组合SFT让模型先具备基本能力DPO用相对低的成本把偏好拉正拒绝采样则针对特定能力比如数学做定向增强。这三步下来大部分场景的效果已经能打。PPO和GRPO我一般留到“DPO效果不够、且团队有RL调参经验”的时候才上。这里有个经验不要在同一次训练里混用多种对齐方法。我试过SFT之后直接接PPO结果模型在训练后期出现严重的reward hacking生成一堆讨好奖励模型但毫无信息量的废话。后来改成SFT→DPO→拒绝采样每一步单独评估问题就少很多。3. 核心细节解析与实操要点3.1 SFT阶段的数据构造与训练配置SFT看起来简单但细节最多。我按数据、模板、超参三块讲。数据构造方面每条样本至少包含三部分system prompt、user input、assistant output。system prompt决定模型的角色和行为边界我建议在SFT阶段就把system prompt写清楚不要留空否则模型学不会区分不同角色。user input要覆盖真实场景的分布不能全是教科书式的问题。assistant output要控制长度太长的样本会让模型学会啰嗦太短的又学不到细节。一个我常用的数据配比是通用指令占40%领域指令占50%边界case占10%。边界case包括“不知道答案时怎么回复”“用户要求做违规操作时怎么拒绝”这类很多团队会忽略但上线后恰恰是这些场景最容易出问题。训练模板方面不同底座模型的chat template不一样一定要用官方推荐的格式。我见过有人用Llama的template去训Qwen结果模型连基本的对话轮次都分不清。如果你不确定直接看tokenizer的apply_chat_template方法输出什么就照着那个来。超参配置我一般从这几个值起步# SFT 起步配置参考 learning_rate 2e-5 # 小模型可以到5e-5大模型建议1e-5到2e-5 num_epochs 3 # 数据质量高的话2轮就够多了容易过拟合 batch_size 64 # 全局batch根据显存调整 warmup_ratio 0.03 # 预热比例防止初期震荡 lr_scheduler cosine # 余弦衰减稳定 max_seq_length 4096 # 根据任务需要不要盲目拉长注意SFT的epoch不是越多越好。我实测下来超过3轮之后模型在训练集上的loss还在降但生成多样性明显变差开始出现“复读机”现象。3.2 DPO的beta参数与数据配对技巧DPO的核心思想是直接用偏好数据优化策略模型跳过奖励模型。它的损失函数里有一个关键参数beta控制模型偏离参考模型的程度。beta越大模型越保守beta越小模型越激进。我一般从beta0.1开始试如果发现模型输出变得很奇怪比如重复、乱码就调大到0.3如果发现对齐效果不明显就调小到0.05。这个参数没有理论最优值只能靠实验。DPO的数据是成对的同一个prompt下一个chosen回答和一个rejected回答。配对质量比数量重要得多。我踩过的坑是chosen和rejected的差异太小比如只是措辞不同模型学不到有效信号。好的配对应该是在有用性、安全性、格式遵循度上有明显差距。另外DPO对数据里的噪声很敏感。如果rejected里混进了其实还不错的回答模型会学到错误的偏好。我一般会做一轮人工抽检把模棱两可的配对删掉。宁可数据少一点也要保证每一对都是清晰的。3.3 GRPO在推理任务上的落地要点GRPOGroup Relative Policy Optimization这两年被讨论得很多核心改动是去掉了PPO的价值网络用一组采样输出的平均奖励作为基线。这样做的好处是显存占用低、训练稳定特别适合数学和代码这类有明确对错的任务。落地GRPO有几个关键点奖励函数设计数学题可以用答案匹配代码题可以用单元测试通过率。奖励函数要尽量稠密不要只有0/1否则训练信号太稀疏。组大小group size一般设4到8太小了基线估计不准太大了显存吃不消。KL惩罚系数GRPO里通常用KL散度约束模型不要偏离参考模型太远系数一般设0.01到0.05。我实测下来GRPO在数学推理任务上比DPO提升明显但前提是奖励函数设计得好。如果奖励函数有漏洞模型会很快学会钻空子。比如你用“答案包含某个关键词”作为奖励模型就会在输出里堆砌关键词。3.4 拒绝采样微调的流程与筛选标准拒绝采样微调Rejection Sampling Fine-Tuning是我个人最喜欢用的推理增强方法因为它简单、稳定、可解释。流程是用当前模型对一批prompt生成多个回答用奖励模型或规则筛选出最好的那些再用这些数据做一轮SFT。筛选标准决定了效果上限。我一般用三层筛选正确性筛选答案必须正确这是硬门槛。格式筛选输出必须符合要求的格式比如带推理步骤、带最终答案标记。简洁性筛选在正确的前提下选最短的那个避免模型学会啰嗦。提示拒绝采样可以迭代多轮每轮用上一轮筛选出的数据微调再用新模型生成下一轮数据。我一般做2到3轮再多收益就很小了。4. 完整实操流程与关键环节实现4.1 环境准备与工具链选型后训练的工具链这两年收敛得很快我目前的主力组合是训练框架TRLHuggingFace做SFT和DPOverl或OpenRLHF做PPO/GRPO。加速库FlashAttention-2 DeepSpeed ZeRO-3显存不够就上LoRA。数据管理自己写脚本做清洗和去重用embedding模型算相似度。评测lm-evaluation-harness跑标准benchmark自己写脚本跑领域评测。环境配置上我建议用conda建独立环境把CUDA、PyTorch、FlashAttention的版本对齐。这一步看起来琐碎但版本不匹配导致的报错能占掉你一半的调试时间。# 环境创建参考 conda create -n posttrain python3.10 conda activate posttrain pip install torch2.3.0 --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.42.0 trl0.9.0 peft0.11.0 pip install flash-attn --no-build-isolation4.2 SFT到DPO的完整流水线我以一个垂直领域问答助手为例走一遍完整流程。第一步数据准备。收集领域问答对清洗后得到约5000条SFT数据。每条数据统一成system/user/assistant三段式system prompt写清楚角色和边界。第二步SFT训练。用LoRA微调rank设16alpha设32target modules覆盖q_proj、k_proj、v_proj、o_proj。训练2轮学习率2e-5全局batch 64。第三步生成偏好数据。用SFT后的模型对一批prompt生成2到4个回答人工或用一个更强的模型打分选出chosen和rejected构造约2000对DPO数据。第四步DPO训练。beta设0.1学习率5e-6训练1到2轮。DPO阶段的学习率要比SFT小一个量级否则容易把SFT学到的能力冲掉。第五步评测与迭代。用领域评测集和通用benchmark同时评估看是否出现“对齐税”alignment tax即通用能力下降。如果下降明显减少DPO的训练量或调大beta。4.3 参数计算与显存估算显存是后训练最现实的约束。我一般用这个公式粗估训练显存 ≈ 模型参数 × 精度字节 × 4 激活值 优化器状态以7B模型、bf16精度、全量微调为例参数显存约14GB优化器状态Adam约56GB激活值取决于batch和序列长度通常20到40GB。加起来80GB以上单卡A100都紧张。所以实际项目里我几乎都用LoRA或QLoRA。LoRA的显存占用主要来自底座模型和激活值优化器状态只针对LoRA参数所以7B模型用LoRA在24GB卡上就能跑。QLoRA进一步把底座量化到4bit显存再降一半但训练速度会慢一些。注意LoRA的rank不是越大越好。rank 16到64覆盖大部分场景再大收益递减还容易过拟合。4.4 训练监控与早停策略训练过程中我重点看三个指标loss曲线、梯度范数、生成样本质量。loss曲线要平滑下降如果出现剧烈震荡先检查学习率和batch size。梯度范数如果持续很大说明训练不稳定可以加梯度裁剪一般设1.0。生成样本质量需要定期抽样我一般每500步生成一批人工看有没有退化。早停策略上我不只看验证集loss更看生成质量。有时候验证loss还在降但生成已经开始重复或跑偏这时候就该停了。我一般设一个patience连续3次评估生成质量没提升就停。5. 常见问题与排查技巧实录5.1 模型输出重复、啰嗦怎么办这是SFT阶段最常见的问题。原因通常有三个数据里有大量重复样本、训练epoch太多、解码参数不对。排查顺序先看训练数据去重了没有再看epoch是不是超过3最后检查解码时的repetition_penalty和temperature。我一般把repetition_penalty设1.1temperature设0.7top_p设0.9。如果数据没问题、epoch也不多那可能是模型本身的问题。有些底座模型在SFT后就是容易重复这时候可以换一个底座试试。5.2 DPO后模型变“犟”了怎么处理DPO之后模型变得不听指令、或者对所有问题都给出很长的回答这是典型的过度对齐。原因是beta太小或者训练轮数太多模型偏离参考模型太远。处理方法调大beta到0.3减少训练轮数到1轮或者在DPO数据里加入一部分“简洁回答”的偏好对让模型学会该短就短。5.3 推理任务上GRPO不收敛的排查GRPO不收敛我一般按这个顺序查奖励函数是否有漏洞模型是不是在钻空子比如输出里堆关键词。组大小是否太小组内样本太少基线估计不准调到8试试。KL系数是否合适太大模型学不动太小模型跑飞从0.01开始调。学习率是否太大GRPO的学习率一般比SFT小1e-6到5e-6比较稳。5.4 常见问题速查表问题现象可能原因处理方式输出重复数据重复、epoch多、解码参数去重、减epoch、调repetition_penalty对齐后变犟beta小、训练多调大beta、减轮数GRPO不收敛奖励漏洞、组小、KL不当查奖励、调组大小、调KL通用能力下降对齐税减DPO量、混入通用数据显存不够全量微调上LoRA/QLoRA、减batch训练loss震荡学习率大、batch小降学习率、加warmup5.5 几个我踩过的坑第一个坑是用错chat template。早期我直接拿Alpaca的格式去训Qwen结果模型连多轮对话都处理不了。后来养成习惯训练前一定先打印tokenizer的template输出确认。第二个坑是DPO数据里混入了噪声。有一批rejected其实质量还行模型学完之后变得畏首畏尾什么都不敢答。后来我加了一轮人工抽检把模棱两可的配对全删了效果立刻好转。第三个坑是忽略评测的分布偏移。标准benchmark分数很高但真实用户的问题分布完全不同。后来我建了一个真实场景的评测集每次训练后都跑一遍才真正能判断模型有没有变好。6. 后训练之后评测、部署与迭代6.1 评测体系怎么搭才靠谱后训练的评测不能只看一个分数。我一般搭三层评测通用能力层MMLU、GSM8K、HumanEval这些标准benchmark看有没有对齐税。领域能力层自己构建的领域评测集覆盖真实场景的问题分布。行为层安全性、格式遵循度、拒绝能力这些用规则或小模型自动评估。三层都过了才认为这一轮训练是有效的。任何一层明显下降都要回去查原因。6.2 部署时的量化与推理优化训练完的模型要部署通常需要量化。我一般用GPTQ或AWQ做4bit量化精度损失在可接受范围内。推理框架用vLLM或TGI吞吐量比原生transformers高一个量级。量化后一定要重新评测因为量化可能让模型在某些任务上明显退化。我遇到过量化后数学能力掉一大截的情况后来换了量化方法才解决。6.3 持续迭代的数据飞轮后训练不是一次性的而是一个持续迭代的过程。我的做法是部署后收集真实用户的反馈点赞、点踩、修正定期把这些数据清洗后加入下一轮训练。这样就形成了一个数据飞轮模型越用越好。飞轮的关键是反馈数据的质量。用户点踩不一定代表模型错了可能是用户自己理解有误。所以我会加一层人工审核只把确认有问题的样本加入训练集。这个流程跑顺之后你会发现后训练不再是“一次性调参”而是一个可以持续优化的工程系统。这也是我写这份手册最想传达的东西后训练的方法会不断更新但“数据质量优先、分阶段验证、持续迭代”这套工程思路是能长期复用的。我个人在实际操作中的体会是后训练最难的从来不是某个算法的公式推导而是把数据、训练、评测、部署这几个环节串成一条稳定的流水线。每次出问题先别急着换方法回头看看数据干不干净、评测准不准、流程有没有断点往往问题就出在这些地方。