做模型落地这几年我越来越确定一件事预训练结束的那一刻模型距离“能交付”其实还隔着很长一条路。真正把 LLM 从“会接话的文本生成器”变成“能可靠执行任务的产品底座”的是预训练结束之后那一整套后训练Post-Training流程。这份手册我把从 SFT、偏好对齐到评测、排查的完整链路整理了一遍记录的是 2025 年 6 月这个时间点上我认为最值得参考的实践路线。它适合正在做模型微调的算法工程师、准备入局大模型训练方向的研究者也适合那些想把底座模型真正用起来的团队。1. 为什么后训练成为2025年大模型竞争的关键战场1.1 预训练决定下限后训练决定上限很多人对后训练有一个误解觉得它是“预训练之后锦上添花的步骤”或者干脆把它等同于“调教模型说话的语气”。实际情况完全不是这样。到了 2025 年基座模型之间的原始能力差距在快速缩小开源社区每过几个月就能看到一个底子相当不错的预训练权重。但同样一份权重有人做出来后训练能交付一个可用工具有人做完之后反而把模型调傻了差距全在这个环节。我见过最典型的例子同一个开源底座A 团队做出来的版本在代码补全、结构化输出、指令遵循上都很稳定B 团队做出来的版本则总是答非所问、格式混乱、遇到长上下文就“失忆”。两者用的训练方法没有本质区别但数据处理、训练策略、评估闭环这些细节完全不同。后训练本质上是一个把预训练阶段“塞”进模型里的知识激活并约束成特定行为模式的工程做得越好模型的可控性越高。预训练像是买了一仓库书后训练是把书整理成顺手可用的书架。很多团队在 7B 这种“小模型”上做扎实的后训练真实体验反而优于一个没做好对齐的 70B 大模型。这在大模型应用圈已经不算新闻了但它说明了一个事实预训练决定的是模型能力的上限后训练决定的是你实际能拿到的上限有多高。2025 年竞争的主战场已经后移了。1.2 后训练的边界早就超出了“对齐”早期谈到后训练大家脑子里的第一反应是 RLHF目的是让模型变得“安全、有用、无害”生成风格更像人。这个方向当然还在但后训练这个词的覆盖范围已经大幅扩展了。今天它至少包含以下几件事指令遵循能力、推理能力的激发、工具调用与结构化输出、多模态输入的对齐、长上下文的利用效率以及面向具体业务场景的行为定制。换句话说后训练已经从“让模型别乱说话”进化成了“让模型真正能干活”。一个模型要能够作为 Agent 去调用外部工具、按照 JSON Schema 稳定输出结果、在代码环境下完成多步推导这些都依赖预训练之后的设计与训练。单纯堆数据、堆算力并不能自动获得这些能力需要在后训练阶段明确地构造数据、选择训练策略、反复评估修正。这个变化带来的直接结果是后训练团队不再是“训练完就交差”的流水线小组而是更像产品开发团队他们需要定义模型的行为目标设计训练数据跑实验观察失败案例然后回到数据处理环节继续迭代。正因如此我觉得后训练本质上已经变成了一套软件工程问题而不是简单的模型调参问题。理解了这一点下面的流程拆解才真正有意义。2. 后训练全流程拆解从SFT到偏好优化的路线图2.1 SFT让模型从“续写”变成“回答”整个后训练链条里监督微调SFT是所有后续步骤的基石。它的核心目标是把预训练模型从“文本续写”的分布掰到“看到指令就给回答”的分布。这一步如果没做好后面做再多的偏好优化都像是在沙地上盖楼。SFT 数据的第一原则是质量而不是数量。行业内一种常见说法是“5 万到 20 万条高质量数据就能撑起一个不错的基础模型”某种程度上是成立的。相比动辄几百万条的预训练数据这个量级听起来很小但正因为小每条数据的质量都会被模型放大学习。我曾经试过在一个底座上先用 15 万条清洗干净的数据做 SFT效果比之前用 80 万条未清洗数据还稳定长回答中的“车轱辘话”明显减少。数据清洗的成本远低于训练成本花在这里的时间永远值得。具体到数据构造我会重点关注四个维度任务覆盖问答、摘要、代码、翻译、工具调用、多轮对话、结构化输出都要有不能只盯着单一场景。难度分布不能全是简单指令也不能全是复杂推理需要按照场景目标配比。做代码助手就多放复杂任务做通用客服就可以多放常见问答。格式统一prompt 和 response 的模板、分隔符、角色标记要绝对一致这直接影响模型对格式的敏感度。去重与语义去重完全相同的文本要去掉改几个字意思一样的也要去不然模型会对高频样本过拟合。还有一个很重要的实操经验seed 数据要人工精标当你需要用模型辅助生成更多指令时一定不要直接把模型生成的数据全部拿进来。我见过一些团队让大模型批量生成 SFT 数据结果模型学会了生成数据时的“口头禅”回答变得又长又空。正确的做法是生成候选之后再做一轮筛选宁缺毋滥质量筛选器的优先级高于生成器。2.2 偏好对齐RLHF、DPO、GRPO 怎么选SFT 让模型学会了“格式正确的回答”但还不能保证回答符合人类的真实偏好。这时候就需要偏好对齐。2025 年的技术路线上RLHF 依然是经典方案但已经不再是唯一选择DPO、GRPO 这类依靠隐式或组内奖励的方法正在成为主流。RLHF 的经典流程是训练一个奖励模型再用强化学习如 PPO去优化策略。它的优点是上限高表达空间大适合通用对话和复杂安全对齐。缺点也很明显流程长、超参数敏感、在线采样成本高跑崩是家常便饭。如果团队没有足够的强化学习调优经验直接用 RLHF 很容易浪费时间。DPO 则走了一条完全不同的路它绕过了显式奖励模型和在线采样直接用偏好对数据做分类式优化。因为实现简单、训练稳定它成了很多人做通用对齐的首选。但 DPO 也有自己的问题它对偏好对的多样性要求很高而且特别容易把“更长”误当成“更好”也就是所谓的长度偏置。GRPO 是 2025 年推理导向模型里非常受关注的方案。它的核心思路是在一个 group 里对多个采样结果做相对比较用组内相对奖励代替全局奖励模型。这种方式对推理、数学、代码这类答案有明确对错边界的任务特别友好因为它不需要训练一个奖励模型来“猜测”人类偏好而是直接用结果的对错或规则评分来构造偏好信号。方法核心思路适合场景成本稳定性RLHF奖励模型 PPO 在线优化通用对话、安全对齐高中等DPO偏好对直接优化通用对齐、风格调整低高GRPO组内相对奖励推理、数学、代码中等中等我个人的倾向是先别急着上整套 RLHF优先用 DPO 解决通用对话的对齐问题用 GRPO 处理推理和代码任务。如果两者配合使用要特别注意训练顺序和各自的数据配比后面会详细展开。2.3 数据配比与训练顺序真正的隐藏杠杆后训练里最容易被忽略、影响最大的变量可能就是数据配比。很多人以为把各种任务的数据一股脑混合起来就行但实际效果往往差强人意。通用指令、代码、数学推理、工具调用、安全样本彼此之间的比例关系会直接决定模型最终的行为偏向。我给一个可参考的起步比例通用指令类数据占 50% 左右代码与推理类占 30%工具调用和安全相关样本占 20%。但这个比例绝对不是固定的。如果你做的是垂直领域的客服模型通用指令可能要压缩到 20%领域数据提到 70%。关键是要先明确业务目标再回头把配比当成一个超参去调而不是满足于“看起来差不多”。训练顺序同样重要。我的习惯是 SFT 打底然后做偏好优化必要的时候在偏好优化之后再加一轮“轻量 SFT”来修复风格漂移。原因很简单偏好优化可能会让模型的表达风格发生变化AI 味变浓或者过于机械这时候用少量高质量 SFT 数据去“拉回来”是非常有效的。我在实际项目中用过这个方法效果非常明显。另一种常见做法是把 SFT 和偏好数据混合在一次训练中完成省时间但可控性较差个人只在快速验证时用。还有一个踩过的坑不要在同一轮训练里同时混合偏好数据和普通指令数据而不做采样率的调整。偏好数据如果占比过高模型很容易过度优化某些固定句式在真实场景里显得机械且缺乏逻辑变通。这类问题在评测指标上往往看不出来只有大量人工体验才能发现。3. 实操中“最吃经验”的工具链与工程细节3.1 LoRA 与全量微调的取舍做后训练首先要回答一个问题用 LoRA 还是全量微调两者没有绝对的优劣完全是成本和效果的取舍。LoRA 的优点是显存占用低、训练速度快、适合快速验证假设。我在做数据探索时基本都用 LoRA因为可以在一两张消费级显卡上把数据流程跑通先确认数据本身没有病。它也很适合小数据量场景比如给模型注入特定的输出格式或领域术语。但 LoRA 的可训练参数量太少面对需要大范围改变行为模式的复杂任务效果天花板会比较明显。全量微调的效果上限通常更高尤其是数据量够大、任务边界需要深度重塑的时候。代价是显存和算力需求直接上一个台阶。以 7B 模型为例fp16 混合精度下仅参数、梯度和优化器状态就需要约 60GB 左右的显存7B 参数约 14GB梯度约 14GBAdam 状态约 28GB这还没算激活值。而 70B 模型跑全量微调哪怕用上 ZeRO 和激活重算也至少要 8 卡百G 级显存起步。所以选择全量微调之前先确认自己的集群资源能不能支撑稳定训练。我有两条实用建议第一先用 LoRA 跑通数据流程确认数据质量与评估指标没问题再上全量微调第二LoRA 的 rank 值要跟着数据量走数据量大时可以试着拉高 rank数据量小时不要盲目加大。很多人一上来就 rank64、128 的拉满结果和 16 的版本没区别还白费算力。3.2 超参数与训练稳定性的实操笔记后训练的超参数没有一套“万能公式”但我可以给出一套经过多次实验验证的起步范围新人照着设大概率不会跑偏。学习率是最敏感的一个。SFT 阶段小模型全量微调常用 1e-5 到 2e-57B 模型如果只做轻量 SFT甚至可以压到 1e-5 附近。LoRA 通常可以放宽到 1e-4 甚至 2e-4因为可训练参数少优化器噪声更可控。偏好优化阶段要更低DPO 我常用 5e-7 到 2e-6GRPO 也在这个量级附近。不要因为 SFT 用 1e-5 效果好就把 DPO 也配成 1e-5那大概率会直接把模型原有行为打穿。batch size 对训练稳定性的影响被很多人低估。SFT 阶段可以适度加大梯度累积多几轮问题不大。但偏好优化阶段对 batch size 更敏感尤其是在做组内对比的方法里每个 group 的采样数量要足够大不然相对奖励的统计噪声会很高。warmup 步数我一般控制在总步数的 5% 到 10%或者直接设 100 到 200 步作用是让优化器先进入稳定状态。超参数SFTDPOGRPO学习率1e-5 ~ 2e-55e-7 ~ 2e-65e-7 ~ 2e-6LoRA 学习率1e-4 ~ 2e-41e-5 左右1e-5 左右batch size可偏大适中偏敏感组内采样数要足warmup100~200 步5%~10% 步数5%~10% 步数梯度裁剪1.0 常用1.0 常用1.0 常用训练过程中的稳定性问题最常见的是 loss 突然飙升和 NaN。loss spike 多半是数据里混入脏样本、学习率设置过大或者某个 batch 的数据分布异常。我的排查顺序是先看数据、再看学习率、最后查混合精度的 loss scale。NaN 问题在 fp16 下尤其常见现在主流做法是直接用 bf16 训练能规避很大一部分精度问题如果你的环境不支持 bf16那就务必开启 loss scaling 和梯度裁剪。还有一个判断过拟合的实操标准不要只盯 train loss。有些模型 train loss 降得很漂亮但生成的回答已经退化成模板复读。更可靠的做法是每隔一定步数保存 checkpoint对每个 checkpoint 做固定的评测集评分和人工抽样对比哪一步效果最好而不是等训练全部结束再回头找。3.3 评估闭环如何避免被 Benchmark 欺骗后训练领域有一个公开的秘密Benchmark 分数和真实体验不一定相关。GSM8K 刷到 95% 不代表模型真的具备推理能力HumanEval 分数高也不代表它能写好完整项目代码。我在实际项目中建立了一套三级评估体系这里分享出来作为参考。第一级是标准化 Benchmark用于和社区做横向对比但只作为参考不参与最终上线决策。第二级是内部评测集按照业务场景定制覆盖长文本理解、指令遵循、结构化输出、代码执行、工具调用、安全拒答等维度每一项设有独立的评分标准。这一级的评测集要固定版本每次模型迭代都跑同一套题保证可比性。第三级是人工抽样每周从真实对话中随机抽一批样本做 bad case 聚类把问题归类成“格式错误”“逻辑混乱”“幻觉严重”“拒答过度”等类型再回到数据和训练策略里针对性修复。一个非常有用的闭环操作把人工发现的 bad case 回填到评测集和 SFT 数据里。这样做既能防止同类问题回归也能让模型在下一轮迭代中直接看到“正确答案”。坚持做三个月后模型的可用性会有肉眼可见的提升。这也是为什么我说评估不是一个环节而是一条贯穿始终的主线。4. 常见问题与排查技巧实录4.1 损失异常与训练崩溃的排查清单做后训练最消磨耐心的就是训练跑到一半loss 突然飙升或者直接 NaN。这里我整理一个高频排查清单按优先级排列训练早期 loss 不下降先检查数据模板和 loss 拼接逻辑再确认随机种子是否固定。我踩过最蠢的一个坑是 prompt 里忘了加换行符模型学了半天都是乱码。loss 突然飙升优先怀疑这批数据里混入了坏样本。做法是把最近一个 batch 的数据单独 dump 出来人眼扫一遍往往就能发现问题。NaN 问题如果是 fp16先切 bf16 试一次如果不支持检查 loss scaling 上限和梯度裁剪阈值。显存 OOM不要一上来就开大 batch先用小 batch 把链路跑通。需要提升吞吐时优先开梯度累积再考虑激活重算最后才上 ZeRO-3因为后者的通信开销会拖慢训练。还有一条很多人容易忽略训练日志里保存的 loss 是平滑后的还是原始值我在调试时同时记录两个值避免被平滑曲线欺骗。原始 loss 有噪声是正常的但如果原始值瞬间跳高后平滑值迟迟不回落那就要果断停下来排查了。4.2 偏好优化里“看似涨点、实际无效”的坑偏好优化的评测指标往往是非常美好的但如果落到真实场景里问题很快就暴露出来。这里分享几个我反复踩过的坑。第一个是长度偏置。DPO 尤其容易出现这种情况模型学会了“回答越长越好”的倾向因为标注者在做偏好标注时往往下意识选择更详细的回答模型就把“长度”当成了“质量”。你在离线评测里看到分数上涨上线后却发现回答又长又空、关键信息被淹没。解决办法是给样本做长度归一化或者在构造偏好对时让两个回答的长度尽量接近。第二个是“格式正确但内容空洞”的伪对齐。模型学得很聪明它学会了用固定的话术兜底比如“根据您的描述您可能需要考虑以下几点”然后列一些放之四海皆准的废话。这类模型在评测集上拿分很高但用户用一次就会觉得“这模型好智障”。我后来的应对方法是在评测集里专门放一批“必须给出具体可验证答案”的问题不加分只做一票否决。第三个是对内部评测集的过拟合。后训练迭代多轮之后评测集里的题很可能会被模型“背下来”。我见过内部评测分数一路涨但线上数据完全没有提升的情况。所以评测集一定要定期塞新题、轮换旧题保持一定的不确定性。4.3 安全与可用性的平衡说到后训练安全对齐是一个绕不开的话题但很多人处理得比较粗暴在数据里堆一堆“拒绝回答”的样本结果模型变成了惊弓之鸟稍微沾点边的问题就拒答可用性大打折扣。我的经验是安全对齐不能作为一道单独的训练关卡来处理而应该在 SFT 和偏好优化阶段都做轻量注入。具体操作上可以把安全相关的偏好对和通用偏好对分开抽样、分开调节权重避免安全样本的格式特征污染整个模型。比如安全拒答的模板要足够多样不能全部都是“作为AI助手我无法回答……”否则模型会把这种句式当作万能兜底正常问题也套用上来。另一个实操心得是安全对齐的“校验”应该是统一且全量的而不是只抽样。每次模型完成迭代、准备上线前我会跑一个固定的安全测试集里面既包含对抗性较强的提示词也包含那些“看起来危险其实无害”的模糊问题。拒绝率和误杀率要同时记录任何一项超出阈值都不过线。安全是底线但可用性是生命线两者的平衡需要在工程上刻意把控。5. 后训练的未来方向我的一点个人观察5.1 数据合成与自训练的比例会继续上升合成数据在后训练里的占比这两年一直在上升。它的最大价值是可以从人工标注的瓶颈中解绑尤其在代码、数学、推理这类可以通过规则自动判分的任务里合成数据的规模可以做得非常大。但合成数据绝不是“越多越好”。模型自己生成的数据里往往隐藏着系统性的偏差和错误如果直接用会形成“自我中毒”。我看到一个比较稳妥的做法是“生成-筛选-蒸馏”三步走先生成大规模候选再用一个强筛选器把高质量样本挑出来最后用这批样本做轻量训练。很多时候从 100 万条候选里筛出 5 万条高质量数据效果比直接用 100 万条原始数据还好。这个方向的核心壁垒已经从“生成能力”转移到了“筛选能力”。谁能高效、准确地判断哪些数据是有效的训练信号谁就能在后训练的效率上占据优势。5.2 待解的几个工程问题站在 2025 年年中往回看后训练作为一个领域已经成型但它还有不少工程问题没有统一答案我简单记几个自己比较关注的方向。多模态后训练的统一范式还不成熟。文本、图像、语音、视频的数据形态差异太大目前大多数实践还是“各做各的”。超长上下文的后训练也还有很多细节值得探索如何让模型在上万字的长文本里保持注意力不漂移远不是简单加深几层网络能解决的。还有后训练流程本身的产品化现在大多数团队还是靠工程师的经验在驱动如果能沉淀成标准的平台化能力对行业的推动会非常大。后训练这个方向我的一点个人体会从最早做指令微调到现在接触推理类模型的后训练我最大的感受是这个领域的难点从来不在论文里那些漂亮公式而在那些你不做就永远想不到的“脏活累活”。数据清洗、评测集设计、坏样本聚类、偶发波动的排查这些事听起来一点都不酷但它们恰恰是决定模型能不能从 demo 变成产品的关键。如果你准备入局这个方向我的建议是先别急着上最新的算法认认真真把 SFT 数据质量做到可信任把评估闭环跑起来再谈后面的偏好优化。磨刀不误砍柴工这句话在后训练这个领域格外真实。