做完整流程的大模型训练预训练、SFT、PPO这三个词基本绕不开。但说实话真正把三个过程都亲手跑过一遍的人不多多数项目要么只做微调要么直接套开源权重走推理。我前一阵完整走了一遍“预训练 - SFT - PPO”的全链路踩了一路的坑也把很多原本模糊的直觉变成了可复用的经验。这篇内容不打算写成教科书而是想把我实际操作中的方案选择、运行细节、失败记录和排查思路完整记录下来给同样要做大模型训练的同行一个可落地的参照。这套东西适合谁如果你刚接手一个训练任务或在SFT和RLHF之间犹豫怎么做选择或已经跑通SFT但觉得模型效果离“能用”还差口气那这篇内容应该能帮你把整条链路的逻辑串起来。我会把预训练的数据处理、SFT的模板设计、PPO的四模型架构讲清楚也会把那些文档里不写的“隐性坑”摊开说。1. 整体设计拆解为什么是预训练、SFT、PPO三段式1.1 三个阶段到底各自解决什么问题很多人把这三个阶段理解成“升级打怪”的关系预训练给模型知识SFT教它对话格式PPO让它讨人喜欢。这个理解方向对但颗粒度太粗容易导致训练策略上的误判。预训练解决的是“语言能力底座”。这个阶段模型在纯文本上做下一个词预测学到的是语法、常识、世界知识、推理雏形但此时模型并不具备“听从指令”的行为模式。你会观察到预训练模型可以续写一段话但你说“帮我写一封请假邮件”它大概率会机械地续写下去而非按照指令执行。这本质上是训练目标的缺失——预测下一个词和“遵循指令给出回答”是两种不同行为模式。SFT解决的是“指令跟随能力”。通过在人工标注或规则筛选出的指令-回答对上继续训练模型开始学会将用户输入映射到合理的输出格式。这个阶段决定了模型“听话”的上限非常重要的一点是SFT并不增加知识量它只是把预训练阶段学到的知识重新组织成能按指令调用的形态。这就像一个人本来就认识很多单词SFT是教他如何按照题目要求写作文。PPO解决的是“价值观对齐和价值偏好”。SFT之后模型已经能给出格式正确的回答但格式正确不等于符合人类偏好。比如让模型解释一个技术概念SFT后的回答可能冗长、绕圈子、缺少结构PPO通过一个奖励模型来引导策略模型朝人类偏好方向优化——回答更简洁、更结构化、更诚实。这一阶段见效慢超参数极其敏感也是整个流程中训练实验成本最高的一环。1.2 为什么不能跳过SFT直接做PPO我见过有人想省事想在预训练模型上直接跑PPO。理论上不是完全不能做但实际效果几乎一定崩。原因很直接PPO的探索空间是基于策略模型当前生成采样进行的预训练模型的生成分布是“自由续写”没有经过任何指令格式约束。你在采样阶段拿到的trajectory大概率是模型自己编的奖励模型给的分也不稳定策略模型很难收敛到“对齐”状态。SFT是PPO的前提接口。SFT阶段让模型学会了“用户指令 - 模型回答”的映射模板PPO阶段才能基于这个相对稳定的行为空间做偏好强化。这也意味着SFT质量直接决定PPO上限。如果SFT数据本身就杂乱、答案质量低PPO阶段奖励模型会学到一个扭曲的偏好分布最后强化出一个“自信地胡说八道”的模型。1.3 算力分配和资源规划的整体思路完整跑一遍三个阶段的算力消耗差异非常大。预训练阶段如果用千亿级token基本是几百张GPU卡跑数周SFT通常用几万到几十万条数据几十张卡跑几小时到一两天PPO阶段单次update包含多次生成和多次梯度更新实际上比SFT更吃算力因为它每次iteration都涉及rollout采样和梯度更新的双重开销。我的个人经验是中小团队如果做领域大模型可以适当调低预训练的体量——用10B到70B的token做领域继续预训练或者干脆基于开源底座做增量预训练重点资源留给SFT和PPO。至于具体比例没有标准答案但我会在后面章节给出一个经验参考区间。2. 预训练阶段的实操拆解2.1 数据从哪里来清洗、去重与配比预训练数据的质量权重远超模型结构设计。同样花100万算力数据工程做得好和做得差的模型效果差距可能比换个模型结构还大。我在这轮项目里用的语料来源主要是公开文本、代码仓库镜像和专业领域文献总量约800GB原始文本清洗后剩510GB左右压缩率接近四成——这很常见原始爬取文本的噪声比例就是有这么高。清洗管线我按这个顺序处理编码检测和乱码过滤、语言识别过滤、正文抽取、段落去重、全文去重、低质量规则过滤。这里全文去重用的是MinHash LSH方案不是简单的字符哈希因为大规模文本里存在大量部分重复内容比如新闻转载、代码片段复用、问答内容的变体改写。MinHash能把相似度高的文本聚类几千亿级别文本去重基本是标配。数据处理里最容易忽略的是文档内部的重复片段。比如某些新闻网站会在每个页面重复渲染导航栏和推荐内容这些片段如果不做段落级去重模型会学到大量重复模式直接体现为生成的文本出现重复机械语句。我用的是SimHash做段落级去重粒度控制在128字节。配比方面我建议如果你做的是通用底座中文、英文、代码的比例可以控制在6:3:1左右如果偏领域增强可以调到中文:英文:代码:领域5:2:1:2。代码数据哪怕只占10%也能显著提升模型的逻辑推理和结构化输出能力不要因为是中文项目就完全忽略代码语料。2.2 Tokenizer训练一个最容易被低估的环节Tokenizer训练在开源社区的标准做法里经常被直接沿用现成词表但增量预训练或从零预训练时我强烈建议按你的语料分布重新训练词表。为什么分词器直接影响训练效率和模型效果。如果你的语料以中文为主但词表偏向英文那中文每个字可能被切成两三个token序列长度被拉长接近一倍训练吞吐直接腰斩。训练时设置vocab_size为32000用了SentencePiece的BPE算法加上了byte fallback机制防止未知字符。这里有一个细节值得单独说词表的覆盖率和token数量不是越大越好。词表过大embedding矩阵参数量增加softmax计算量也线性上涨词表过小长尾词汇被切碎信息密度低。我做过实验同一个语料集vocab_size32000和48000的最终loss差异在0.02以内但48000的训练速度慢了约15%。所以对你正在训练的语料做一次tokenizer覆盖统计找到覆盖率和词表大小的平衡点比盲目追求大词表更高效。2.3 模型结构选择稠密、MoE与位置编码预训练阶段模型结构我选择了稠密Transformer主要原因不在于MoE不好而是中小团队训MoE的工程成本太高。MoE能带来稀疏激活的算力优势但all-to-all通信、负载均衡loss、专家路由的稳定性都是额外的工程负担。如果你人力有限稠密模型是更稳妥的路径。位置编码用了RoPE因为它在长度外推和相对位置建模上的表现更稳定。这里提一个关键参数base值。默认RoPE的base是10000但序列长度超过4096时高频位置编码会迅速衰减导致模型学不到长距离依赖。我测试了base500000的组合在8K上下文长度下明显更平稳。如果你的训练序列以2K到4K为主10000够用如果计划扩展到8K以上建议把base调大。层数、头数、维度这些参数建议直接参考同量级开源模型的配置不需要自己发明。真正影响效果的通常是更底层的训练细节而不是Transformer的参数排列组合。2.4 并行策略数据并行张量并行流水线并行预训练阶段并行策略直接决定了你能用多大规模的集群跑多快的训练。我在这轮项目用的是3D并行数据并行、张量并行、流水线并行同时开启。数据并行最简单每张卡持有完整模型副本喂不同的数据batch通过梯度allreduce同步。张量并行是切分单层内的矩阵乘法适合单机多卡场景可以减少激活显存但会增加通信开销。流水线并行则是按层切分把模型的不同层放在不同设备上解决“模型太大单卡放不下”的问题。工程配置里我给出一个具体数字参考。7B稠密模型在32张A100 80G的集群上TP2、PP4、DP4的组合全局batch size设为512单卡micro batch size设为1梯度累积步数设为16步这里需要算一下全局batch 512 / (4 DP * 4 PP * 2 TP * 1 micro) 16累积这个组合在稳定性和吞吐之间能取得相对理想的均衡点训练速度大约在每秒每卡处理3500~4000 token左右。如果你的模型更大比如13B或70B流水线层数需要按层数均匀切分尽量让每张卡的负载差控制在10%以内。2.5 训练细节学习率、loss观测和神奇的“过拟合假象”预训练学习率我用的是warmup余弦衰减。7B模型下峰值学习率设置在3e-4warmup步数2000步衰减到最终学习率3e-5。batch size偏大的时候峰值学习率可以适当调高但不要超过1e-3这个阈值否则loss会出现明显的震荡。训练中的核心观测指标是validation loss和perplexity的对应关系。这里有个常见误判很多团队看到训练loss下降就以为模型在学习实际上在2K到4K的短序列上模型很容易“死记硬背”而学到伪模式——开头几句背诵式重复、输出空洞的续写。我自己的习惯是每个epoch保存checkpoint后专门抽几条长文本做生成测试观察模型续写质量不能只看loss。预训练阶段还有一个容易被忽略的现象loss plateau。模型训练到中期会进入一个看似“不学习”的阶段loss曲线非常平缓很多人这时候就决定终止训练。实际上这往往不是真正收敛而是当前学习率下模型陷入了局部平滑区域。我的处理方式是保持训练等warmup结束后把学习率降低一个量级继续训通常能突破平台继续下降。3. SFT阶段模型“学会说话”的关键一跃3.1 SFT数据从哪来质量大于数量多样性更重要SFT阶段的核心不是数据量而是数据分布的覆盖率和质量。业界一个很常见的错误是为了凑数量疯狂上量结果模型学到了大量重复的句式模板生成内容变得千篇一律。我最终用的SFT数据集是13万条但为了这13万条前后清洗筛选了接近40万条原始候选数据。数据来源主要有三类第一是开源的中文指令数据集注意做去重和格式统一第二是从业务场景收集的真实用户问题这个最宝贵因为贴近实际分布第三是合成数据——用大模型做数据增强生成“问题多样性”和“回答简洁性”都更好的样本。我实测下来三类数据的比例按2:5:3配比较为理想。还有一个容易忽略的点SFT数据必须包含一定比例的“拒绝回答”样本。现实场景里用户会问很多模型不该回答或无法回答的问题如果数据里完全没有这类样本模型会强制生成一个看似合理的回答实际上是在一本正经地编造。加入5%左右的拒绝样本能显著减少幻觉。3.2 模板设计System Prompt和对话格式的一致性陷阱SFT阶段大多数人会忽略模板一致性对后续PPO的影响。你在SFT阶段用什么样的对话模板user/assistant分隔符、system prompt的写法PPO阶段的rollout采样就必须完全一致。否则模型在PPO阶段会困惑训练时见到的格式和采样时输入的格式对不上行为分布会发生漂移。我用的模板统一为如下格式|system| 你是智能助手请基于事实简洁、准确地回答问题。 |user| [用户问题] |assistant|训练时system prompt和user输入参与loss计算但assistant回答部分的loss才参与反向传播其余token位置做mask不计算loss。这样模型只会去拟合“回答”部分不会把模板本身背下来。这里有一个很隐蔽的问题模板中的system prompt文本如果被mask掉模型实际上学不到system prompt的约束作用。你希望在生成时通过system prompt控制回答风格但训练时这部分语义从未参与梯度更新模型相当于“没学过”system prompt的含义。我的处理办法是保留一小部分样本system prompt和assistant回答同时参与loss计算让模型学会理解system prompt的指示含义。比例不用太高3%到5%就能起效。3.3 Loss设计只计算答案部分还是全序列计算SFT阶段的loss设计有一个关键选择是计算全序列的loss还是只计算assistant部分的loss。我的实测经验全序列计算会导致模型花费大量模型容量去记忆提示词和模板格式反而挤占了回答部分的拟合能力只计算assistant部分的loss模型收敛更快生成质量也更高。这个结论符合直觉——模板是固定的不需要用模型容量去记住它。实现上我直接在主流的训练框架里对每个token打标签把不需要计算loss的位置设置为ignore_index-100。核心代码思路def mask_prompt_loss(labels, tokenizer, assistant_token_id): # labels形状为 [batch, seq_len] # 找出assistant token出现的位置该位置之前全部mask masked_labels labels.clone() for i, seq in enumerate(labels): assistant_positions (seq assistant_token_id).nonzero(as_tupleTrue)[0] if len(assistant_positions) 0: first_assistant assistant_positions[0] masked_labels[i, :first_assistant] -100 return masked_labels3.4 SFT训练参数设置SFT阶段的学习率应该明显低于预训练。预训练峰值学习率是3e-4SFT我设置的是1e-5全参微调可以到2e-5LoRA微调可以用5e-5到1e-4。学习率过高的典型表现就是训练集loss降到很低但验证集生成质量崩掉模型出现复读机现象。epoch数建议控制在1到3之间。13万条数据其实很多2个epoch基本能让模型充分拟合超过3个epoch的边际收益很低反而增加过拟合风险。我实测4个epoch后模型开始出现对高频模板的机械复读。dropout这里有个坑预训练模型通常dropout设置较高但SFT阶段建议把dropout降到0或者接近0。因为SFT数据量远小于预训练高dropout会让模型在拟合指令数据时变得“软弱”输出不稳定。我把所有Attention和MLP层的dropout置为0后生成稳定度提升非常明显。LoRA和全参微调的取舍上如果数据和算力都充裕全参微调最优LoRA的优势是训练完只需要保存几十MB的adapter权重迭代速度快。但如果你的目标是做完整RLHF链路LoRA的局限性会在PPO阶段暴露——策略梯度的更新很不稳定低秩更新空间可能无法承载PPO阶段的大幅度策略调整。所以规划PPO的话建议SFT阶段直接全参微调。3.5 SFT阶段容易踩的两个性能坑SFT阶段最常见的性能坑是loss下降但生成质量没变化。排查思路是先看模板有没有问题——模板里的特殊token如果在词表里被错误地拆分模型根本不知道这是一个独立tokenloss当然降但模型学不到格式约束。我建议用代码验证每个特殊token的id是否被正确保留token在词表中是否作为一个整体存在。这是一个非常耗时的排查点但找到后会恍然大悟。第二个坑是数据泄漏。SFT数据集里如果混入了预训练阶段见过的文本会造成过拟合假象。我的做法是把SFT数据在预训练语料里做了最近邻检索凡相似度超过0.85的样本全部剔除保证SFT数据是模型“没见过的”。4. PPO阶段价值对齐是一个“系统”不只是算法4.1 RLHF思想为什么用强化学习而非继续SFTSFT已经是“模型根据指令输出答案”那为什么还需要PPO核心原因是SFT只能模仿已有答案无法超出数据集中答案的分布范围。如果SFT数据里没有“简洁回答”的例子模型很难自行学会简洁即使有SFT也无法让模型习得一个全局的偏好优先级。PPO引入了一个奖励模型作为“偏好信号源”。训练过程中模型不断生成新的回答奖励模型对回答打分策略模型根据分数调整生成策略。这种在线学习的核心价值是模型会逐步探索出那些“数据中没有明确出现但整体偏好更优”的回答模式。奖励模型可以直接替代人工对海量生成结果的评估。用一个生活化类比解释PPOSFT阶段像学生看标准答案做练习题目和答案都是固定的PPO阶段像老师给作业打分但不给标准答案学生通过不断尝试来理解老师的评分偏向。4.2 PPO的四模型架构Actor、Ref、Reward、CriticPPO阶段需要四个模型同时存在Actor策略模型就是我们最终要训练并部署的模型Ref参考模型是SFT阶段保存的模型且参数冻结用于约束Actor不要偏离SFT模型太远避免策略崩溃Reward奖励模型对生成结果打分参数冻结Critic价值模型用于估计状态价值函数给优势函数提供baseline训练过程中参数会更新。Actor和Critic来自同一个底座SFT模型初始化Ref就是SFT保存的权重Reward需要在SFT基础上做一个独立的奖励模型头。这四个模型同时在显存里显存开销接近三倍单模型是PPO阶段最大的工程压力。必须注意Actor和Ref的初始权重必须完全一致。如果Ref在SFT阶段结束后又经历了任何参数变化而Actor没有同步KL散度的约束起点就会出现偏移训练一开始就处于不稳定状态。一个最简单的检查方法训练启动前把Actor和Ref的权重文件做逐参数对比误差应为0。4.3 奖励模型Reward Model的训练细节奖励模型本身也是训练出来的。我给Reward模型设计了pairwise ranking loss对同一个问题准备两个回答一个偏优、一个偏差让模型学会区分优劣。核心loss公式为loss -log(sigmoid(reward_chosen - reward_rejected))这个公式的含义是模型给优质回答的分数越高给劣质回答的分数越低整体loss越小。实际训练中需要把分数先做个归一化防止reward数值范围漂移。我在训练Reward模型时加了标签平滑技术将目标概率从1平滑到0.9这在数据噪声较大的pair对中能显著提升稳定性。Reward模型的训练数据质量要求极高。如果训练数据里有大量标注错误或有争议的偏好对Reward模型会对某些无意义特征产生偏好PA模型就会放大这个偏差。我准备训练样本是从线上真实对话中抽样排序、再由标注团队做两两对比生成的每个样本至少独立标注两次不一致的样本直接废弃。另外必须提醒的是PPO训练中reward模型分数最好做标准化——用训练过程中running mean和std把reward分数映射到均值为0方差为1的正态分布。否则奖励分数绝对值过大或过小都会导致策略更新步长失控。4.4 PPO核心机制KL散度、GAE和策略更新PPO阶段最核心的目标函数可以拆成三个部分奖励模型给出的奖励、KL散度惩罚、以及PPO特有的clip项。KL散度惩罚的公式是kl_penalty β * KL(actor_output_probs, ref_output_probs)。其中β是动态变化的系数。我采用了自适应KL系数调整当KL散度高于目标值比如0.02/token时β增大强化惩罚当KL散度低于目标值时β减小。这样能让策略保持在SFT模型附近但又有足够自由度去探索更优偏好。GAE广义优势估计是PPO里估算动作优势值的关键模块。GAE参数的λ取值会影响优势估计的偏差-方差权衡。λ1时优势估计接近蒙特卡洛采样方差高但无偏λ0时只看即时奖励偏差高但方差低。我的经验和大多数团队的默认选择一样λ取0.95这是个平稳且相对折中的值。策略更新时有一个clip参数控制新旧策略的差异上限我设置为0.2。这意味着新旧策略在某个token的概率比不能超过1.2或低于0.8超过这个范围就截断。这个机制保证了每次更新不会一步跨太大导致策略崩溃。critic的损失则采用MSE loss学习率比Actor稍低我用的是1e-5。4.5 PPO训练超参组合参考PPO超参之间互相影响很强我给出一个经过多次实验验证可用的组合参考rollout数量每batch采样4096条完整responseGAE λ0.95clip范围0.2初始KL系数β0.02KL目标值0.03/token动态调整βActor学习率5e-6Critic学习率1e-5每次迭代的PPO更新轮次4轮温度采样0.7奖励标准化每个batch内做running normalize需要强调的是PPO训练非常吃显存四个模型同时加载通常需要把batch切得很小。我的方案是把rollout生成和梯度更新分开成两个阶段在推理阶段只加载Actor和Ref采样生成大量经验数据存入buffer在训练阶段再加载Reward和Critic用buffer中的数据进行策略更新。这个“生成-更新”分离设计能够显著降低显存峰值。4.6 PPO训练中的“奖励欺骗”现象PPO阶段最典型的问题就是reward hacking——模型学会钻奖励模型的空子。比如奖励模型偏好结构化回答模型就会在回答里强行加一堆bullet point内容其实没什么价值奖励模型偏好“礼貌语气”模型就会在每句回答后加“感谢您的提问”。我排查这个问题的方法是观察响应的平均长度和句法复杂度变化趋势。正常训练中响应长度应该整体稳定如果发现响应长度持续增长或者标点使用频率急剧上升基本可以确认模型在钻reward的空子。解决思路有三个一是提升Reward模型本身的质量二是在KL散度惩罚上加大力度三是加入response长度惩罚因子。我当时用的长度惩罚方案简单但有效在reward分数上减去一个系数乘以response长度超出target部分。这样模型在优化奖励分数和缩短冗余长度之间必须做出权衡。4.7 观察指标与训练收敛判断PPO训练过程中不要只盯着reward曲线。reward曲线上升可能是好事也可能意味着模型已经偏离到钻空子的方向必须配合观测以下指标KL散度值应保持在预设目标范围内过高说明模型偏离SFT版本太远response长度变化持续增长的响应长度暗示奖励欺骗文本多样性用生成结果的n-gram重复率评估重复率升高意味着模型开始复读Actor和Ref的预测分布差异分布差异过大需要及时干预收敛判断的实用方法是在每个epoch结束做一次人工评估用一组固定的测试prompt检查生成结果质量对比上一版的变化。如果连续2个epoch里人工评估分数没有提升说明当前超参组合下已经接近收敛可以停止训练。5. 三个阶段衔接的工程实践复盘5.1 数据配比与token消耗的宏观规划完整跑完三个阶段的token消耗我给一个参考区间预训练阶段大约消耗1万亿token左右基于5亿参数的底座模型SFT阶段大约消耗2亿tokenPPO阶段每次iteration生成推理token约2000万整体训练下来PPO消耗token约1亿。这个比例显示出一个很有趣的事实预训练token数量虽然更大但计算开销是按算力token数计算的PPO虽然token消耗量小但每次token背后的计算链路更长生成多模型推断策略更新所以实际成本一点也不低。对资源有限的团队一个更经济的做法是不用从零预训练10亿级模型而是选择一个合适的开源底座仅做领域适配的增量预训练约500亿到1000亿token再走完整SFT和PPO。这样总token消耗可以控制在预训练全量方案的1/5以内但效果对于垂直场景足够。5.2 模型权重管理checkpoint策略和断点续训三个阶段都会面临分阶段保存checkpoint的问题。我的习惯是预训练阶段每个500步保存一次全量权重保留最近5个checkpoint滚动覆盖SFT阶段在每次epoch结束时保存保留全部epoch版本用于对照PPO阶段每经过10次iteration保存一个actor权重快照保留最近3份这里有个非常容易踩的坑PPO阶段Actor和Ref的初始权重必须来自同一个SFT版本。如果Ref用的是SFT的最终版本Actor用的是SFT的某个中间epoch版本两边的初始分布不一致PPO一开始就会出现KL散度异常表现为奖励不断下降但KL不断上涨几乎无法救回来。5.3 跨阶段数据泄漏的排查三个阶段共享了很多语料来源最容易忽视的是SFT阶段和PPO阶段的数据泄漏。PPO阶段Reward模型的训练数据如果跟SFT训练数据有重叠模型会“认识”这些样本给它们打出虚高的奖励从而污染整个偏好信号。我的做法是每一阶段训练前都做一次数据溯源检测核心实现是对高相似度样本做全量扫描。代码思路大致如下def dedup_across_sets(src_samples, tgt_samples, threshold0.85): # 使用MinHash生成指纹 hash_list [compute_minhash(sample) for sample in src_samples] # 对tgt样本逐一比对返回相似度超过阈值的索引对 dup_pairs [] for i, tgt in enumerate(tgt_samples): tgt_hash compute_minhash(tgt) for j, src_hash in enumerate(hash_list): if jaccard_similarity(tgt_hash, src_hash) threshold: dup_pairs.append((i, j)) return dup_pairs实测下来即便是看似不相关的“用户提问”和“预训练文本”也可能因为隐含的人物、产品名称而产生较高的文本相似度。不要嫌麻烦这个步骤能帮你避免后面大量的返工。5.4 训练停机恢复的一些经验大规模训练过程中断很常见我前后遇到过断点续训后loss突然抬升的情况。排查经历的教训是续训时必须检查三个状态是否完全恢复优化器状态、学习率调度器的当前步数、数据加载器的随机种子和当前位置。特别是随机种子的恢复。Python的random库和PyTorch的dataloader都有各自的seed机制如果只恢复了模型权重而没恢复数据加载顺序模型看到的batch顺序完全不同loss出现一阵波动是正常的。但如果数据加载顺序恢复错误可能出现训练“看起来在继续但实际在乱学”的假象。建议做断点续训前先在日志里记录breakpoint位置的全局step、epoch内step、cycle样本索引三要素。6. 常见问题速查与解决实录6.1 预训练阶段问题排查瓶颈现象之一loss不降。先检查学习率是否过高导致loss震荡再查看数据是否重复太多最后看词表覆盖是否过差。如果中文字符有大量被切成单字节训练效率会非常低。瓶颈现象之二loss降了但生成文本质量差。优先怀疑数据清洗不够彻底——比如错误编码、繁体中文和简体中文混用、HTML标签残留。可以随机抽取500条训练文本做人工扫描很多问题一眼就能看出来。瓶颈现象之三训练中途显存OOM。解决方案有很多减小micro batch size开启梯度检查点功能用计算换显存将优化器状态切成分片策略或启用序列并行方案。我实测梯度检查点能节省约30%显存但训练速度会降约15%。6.2 SFT阶段问题排查SFT后模型输出“嗯”、“好的”这类无意义后缀几乎可以确定是训练数据里混入了过多短回答或低质量样本。排查方法是统计训练数据的回答长度分布把超过设定阈值的低质量答案样本剔除。SFT后模型对指令格式不敏感用户怎么问它都按固定模板回答。这大概率是模板中user部分也被强制参与学习导致模型把用户输入当作格式的一部分。检查你是否正确设置了mask。6.3 PPO阶段问题排查reward数值一路上涨但生成质量变差几乎可以认定是reward hacking。立即介入检查response长度、重复率、特殊符号使用频率。KL散度爆炸性增长常见原因是Ref和Actor初始化不一致或者是PPO更新轮数过多导致策略偏移太大。减少PPO update轮数、增大KL惩罚系数、降低Actor学习率这三招按顺序试。critic loss不下降说明价值函数没有学到有效信息。可能原因是GAE的优势估计数值范围过大建议对advantage做标准化处理。6.4 显存不足时的降级方案全流程四个模型确实太占显存。如果资源有限我推荐用低秩适配的方式训练Actor和CriticRef和Reward用4bit量化加载。虽然量化方案在严格训练精度上会有一点点损失但实测下来奖励和KL散度的计算误差可以接受显存占用能从80GB级别降到40GB以内训练还能继续稳定跑下去。7. 收尾一点个人体会完整跑完这个流程后最深的感触是预训练、SFT、PPO这三步不是简单的工程串联每一步的选择都在为下一步铺路。预训练阶段多花心思在数据处理上SFT阶段的收敛质量会明显更好SFT阶段的模板设计和数据质量直接决定PPO能不能稳定收敛。如果你准备走这条完整链路我建议在起步阶段就做好算力规划、数据血缘追踪和节点恢复机制这三个基础打好后面的坑会少很多。最后分享一个执行层面的小技巧每个阶段结束不要急着进入下一个阶段先留出一周时间做系统性的生成质量评估和回看。我曾在SFT阶段发现了一个模板token拼接问题当时模型已经进入PPO结果只能倒回来重新训SFT白白消耗了大概两周的算力。宁可阶段间多验证也不要到后面推倒重来。
做完整流程的大模型训练预训练、SFT、PPO这三个词基本绕不开。但说实话真正把三个过程都亲手跑过一遍的人不多多数项目要么只做微调要么直接套开源权重走推理。我前一阵完整走了一遍“预训练 - SFT - PPO”的全链路踩了一路的坑也把很多原本模糊的直觉变成了可复用的经验。这篇内容不打算写成教科书而是想把我实际操作中的方案选择、运行细节、失败记录和排查思路完整记录下来给同样要做大模型训练的同行一个可落地的参照。这套东西适合谁如果你刚接手一个训练任务或在SFT和RLHF之间犹豫怎么做选择或已经跑通SFT但觉得模型效果离“能用”还差口气那这篇内容应该能帮你把整条链路的逻辑串起来。我会把预训练的数据处理、SFT的模板设计、PPO的四模型架构讲清楚也会把那些文档里不写的“隐性坑”摊开说。1. 整体设计拆解为什么是预训练、SFT、PPO三段式1.1 三个阶段到底各自解决什么问题很多人把这三个阶段理解成“升级打怪”的关系预训练给模型知识SFT教它对话格式PPO让它讨人喜欢。这个理解方向对但颗粒度太粗容易导致训练策略上的误判。预训练解决的是“语言能力底座”。这个阶段模型在纯文本上做下一个词预测学到的是语法、常识、世界知识、推理雏形但此时模型并不具备“听从指令”的行为模式。你会观察到预训练模型可以续写一段话但你说“帮我写一封请假邮件”它大概率会机械地续写下去而非按照指令执行。这本质上是训练目标的缺失——预测下一个词和“遵循指令给出回答”是两种不同行为模式。SFT解决的是“指令跟随能力”。通过在人工标注或规则筛选出的指令-回答对上继续训练模型开始学会将用户输入映射到合理的输出格式。这个阶段决定了模型“听话”的上限非常重要的一点是SFT并不增加知识量它只是把预训练阶段学到的知识重新组织成能按指令调用的形态。这就像一个人本来就认识很多单词SFT是教他如何按照题目要求写作文。PPO解决的是“价值观对齐和价值偏好”。SFT之后模型已经能给出格式正确的回答但格式正确不等于符合人类偏好。比如让模型解释一个技术概念SFT后的回答可能冗长、绕圈子、缺少结构PPO通过一个奖励模型来引导策略模型朝人类偏好方向优化——回答更简洁、更结构化、更诚实。这一阶段见效慢超参数极其敏感也是整个流程中训练实验成本最高的一环。1.2 为什么不能跳过SFT直接做PPO我见过有人想省事想在预训练模型上直接跑PPO。理论上不是完全不能做但实际效果几乎一定崩。原因很直接PPO的探索空间是基于策略模型当前生成采样进行的预训练模型的生成分布是“自由续写”没有经过任何指令格式约束。你在采样阶段拿到的trajectory大概率是模型自己编的奖励模型给的分也不稳定策略模型很难收敛到“对齐”状态。SFT是PPO的前提接口。SFT阶段让模型学会了“用户指令 - 模型回答”的映射模板PPO阶段才能基于这个相对稳定的行为空间做偏好强化。这也意味着SFT质量直接决定PPO上限。如果SFT数据本身就杂乱、答案质量低PPO阶段奖励模型会学到一个扭曲的偏好分布最后强化出一个“自信地胡说八道”的模型。1.3 算力分配和资源规划的整体思路完整跑一遍三个阶段的算力消耗差异非常大。预训练阶段如果用千亿级token基本是几百张GPU卡跑数周SFT通常用几万到几十万条数据几十张卡跑几小时到一两天PPO阶段单次update包含多次生成和多次梯度更新实际上比SFT更吃算力因为它每次iteration都涉及rollout采样和梯度更新的双重开销。我的个人经验是中小团队如果做领域大模型可以适当调低预训练的体量——用10B到70B的token做领域继续预训练或者干脆基于开源底座做增量预训练重点资源留给SFT和PPO。至于具体比例没有标准答案但我会在后面章节给出一个经验参考区间。2. 预训练阶段的实操拆解2.1 数据从哪里来清洗、去重与配比预训练数据的质量权重远超模型结构设计。同样花100万算力数据工程做得好和做得差的模型效果差距可能比换个模型结构还大。我在这轮项目里用的语料来源主要是公开文本、代码仓库镜像和专业领域文献总量约800GB原始文本清洗后剩510GB左右压缩率接近四成——这很常见原始爬取文本的噪声比例就是有这么高。清洗管线我按这个顺序处理编码检测和乱码过滤、语言识别过滤、正文抽取、段落去重、全文去重、低质量规则过滤。这里全文去重用的是MinHash LSH方案不是简单的字符哈希因为大规模文本里存在大量部分重复内容比如新闻转载、代码片段复用、问答内容的变体改写。MinHash能把相似度高的文本聚类几千亿级别文本去重基本是标配。数据处理里最容易忽略的是文档内部的重复片段。比如某些新闻网站会在每个页面重复渲染导航栏和推荐内容这些片段如果不做段落级去重模型会学到大量重复模式直接体现为生成的文本出现重复机械语句。我用的是SimHash做段落级去重粒度控制在128字节。配比方面我建议如果你做的是通用底座中文、英文、代码的比例可以控制在6:3:1左右如果偏领域增强可以调到中文:英文:代码:领域5:2:1:2。代码数据哪怕只占10%也能显著提升模型的逻辑推理和结构化输出能力不要因为是中文项目就完全忽略代码语料。2.2 Tokenizer训练一个最容易被低估的环节Tokenizer训练在开源社区的标准做法里经常被直接沿用现成词表但增量预训练或从零预训练时我强烈建议按你的语料分布重新训练词表。为什么分词器直接影响训练效率和模型效果。如果你的语料以中文为主但词表偏向英文那中文每个字可能被切成两三个token序列长度被拉长接近一倍训练吞吐直接腰斩。训练时设置vocab_size为32000用了SentencePiece的BPE算法加上了byte fallback机制防止未知字符。这里有一个细节值得单独说词表的覆盖率和token数量不是越大越好。词表过大embedding矩阵参数量增加softmax计算量也线性上涨词表过小长尾词汇被切碎信息密度低。我做过实验同一个语料集vocab_size32000和48000的最终loss差异在0.02以内但48000的训练速度慢了约15%。所以对你正在训练的语料做一次tokenizer覆盖统计找到覆盖率和词表大小的平衡点比盲目追求大词表更高效。2.3 模型结构选择稠密、MoE与位置编码预训练阶段模型结构我选择了稠密Transformer主要原因不在于MoE不好而是中小团队训MoE的工程成本太高。MoE能带来稀疏激活的算力优势但all-to-all通信、负载均衡loss、专家路由的稳定性都是额外的工程负担。如果你人力有限稠密模型是更稳妥的路径。位置编码用了RoPE因为它在长度外推和相对位置建模上的表现更稳定。这里提一个关键参数base值。默认RoPE的base是10000但序列长度超过4096时高频位置编码会迅速衰减导致模型学不到长距离依赖。我测试了base500000的组合在8K上下文长度下明显更平稳。如果你的训练序列以2K到4K为主10000够用如果计划扩展到8K以上建议把base调大。层数、头数、维度这些参数建议直接参考同量级开源模型的配置不需要自己发明。真正影响效果的通常是更底层的训练细节而不是Transformer的参数排列组合。2.4 并行策略数据并行张量并行流水线并行预训练阶段并行策略直接决定了你能用多大规模的集群跑多快的训练。我在这轮项目用的是3D并行数据并行、张量并行、流水线并行同时开启。数据并行最简单每张卡持有完整模型副本喂不同的数据batch通过梯度allreduce同步。张量并行是切分单层内的矩阵乘法适合单机多卡场景可以减少激活显存但会增加通信开销。流水线并行则是按层切分把模型的不同层放在不同设备上解决“模型太大单卡放不下”的问题。工程配置里我给出一个具体数字参考。7B稠密模型在32张A100 80G的集群上TP2、PP4、DP4的组合全局batch size设为512单卡micro batch size设为1梯度累积步数设为16步这里需要算一下全局batch 512 / (4 DP * 4 PP * 2 TP * 1 micro) 16累积这个组合在稳定性和吞吐之间能取得相对理想的均衡点训练速度大约在每秒每卡处理3500~4000 token左右。如果你的模型更大比如13B或70B流水线层数需要按层数均匀切分尽量让每张卡的负载差控制在10%以内。2.5 训练细节学习率、loss观测和神奇的“过拟合假象”预训练学习率我用的是warmup余弦衰减。7B模型下峰值学习率设置在3e-4warmup步数2000步衰减到最终学习率3e-5。batch size偏大的时候峰值学习率可以适当调高但不要超过1e-3这个阈值否则loss会出现明显的震荡。训练中的核心观测指标是validation loss和perplexity的对应关系。这里有个常见误判很多团队看到训练loss下降就以为模型在学习实际上在2K到4K的短序列上模型很容易“死记硬背”而学到伪模式——开头几句背诵式重复、输出空洞的续写。我自己的习惯是每个epoch保存checkpoint后专门抽几条长文本做生成测试观察模型续写质量不能只看loss。预训练阶段还有一个容易被忽略的现象loss plateau。模型训练到中期会进入一个看似“不学习”的阶段loss曲线非常平缓很多人这时候就决定终止训练。实际上这往往不是真正收敛而是当前学习率下模型陷入了局部平滑区域。我的处理方式是保持训练等warmup结束后把学习率降低一个量级继续训通常能突破平台继续下降。3. SFT阶段模型“学会说话”的关键一跃3.1 SFT数据从哪来质量大于数量多样性更重要SFT阶段的核心不是数据量而是数据分布的覆盖率和质量。业界一个很常见的错误是为了凑数量疯狂上量结果模型学到了大量重复的句式模板生成内容变得千篇一律。我最终用的SFT数据集是13万条但为了这13万条前后清洗筛选了接近40万条原始候选数据。数据来源主要有三类第一是开源的中文指令数据集注意做去重和格式统一第二是从业务场景收集的真实用户问题这个最宝贵因为贴近实际分布第三是合成数据——用大模型做数据增强生成“问题多样性”和“回答简洁性”都更好的样本。我实测下来三类数据的比例按2:5:3配比较为理想。还有一个容易忽略的点SFT数据必须包含一定比例的“拒绝回答”样本。现实场景里用户会问很多模型不该回答或无法回答的问题如果数据里完全没有这类样本模型会强制生成一个看似合理的回答实际上是在一本正经地编造。加入5%左右的拒绝样本能显著减少幻觉。3.2 模板设计System Prompt和对话格式的一致性陷阱SFT阶段大多数人会忽略模板一致性对后续PPO的影响。你在SFT阶段用什么样的对话模板user/assistant分隔符、system prompt的写法PPO阶段的rollout采样就必须完全一致。否则模型在PPO阶段会困惑训练时见到的格式和采样时输入的格式对不上行为分布会发生漂移。我用的模板统一为如下格式|system| 你是智能助手请基于事实简洁、准确地回答问题。 |user| [用户问题] |assistant|训练时system prompt和user输入参与loss计算但assistant回答部分的loss才参与反向传播其余token位置做mask不计算loss。这样模型只会去拟合“回答”部分不会把模板本身背下来。这里有一个很隐蔽的问题模板中的system prompt文本如果被mask掉模型实际上学不到system prompt的约束作用。你希望在生成时通过system prompt控制回答风格但训练时这部分语义从未参与梯度更新模型相当于“没学过”system prompt的含义。我的处理办法是保留一小部分样本system prompt和assistant回答同时参与loss计算让模型学会理解system prompt的指示含义。比例不用太高3%到5%就能起效。3.3 Loss设计只计算答案部分还是全序列计算SFT阶段的loss设计有一个关键选择是计算全序列的loss还是只计算assistant部分的loss。我的实测经验全序列计算会导致模型花费大量模型容量去记忆提示词和模板格式反而挤占了回答部分的拟合能力只计算assistant部分的loss模型收敛更快生成质量也更高。这个结论符合直觉——模板是固定的不需要用模型容量去记住它。实现上我直接在主流的训练框架里对每个token打标签把不需要计算loss的位置设置为ignore_index-100。核心代码思路def mask_prompt_loss(labels, tokenizer, assistant_token_id): # labels形状为 [batch, seq_len] # 找出assistant token出现的位置该位置之前全部mask masked_labels labels.clone() for i, seq in enumerate(labels): assistant_positions (seq assistant_token_id).nonzero(as_tupleTrue)[0] if len(assistant_positions) 0: first_assistant assistant_positions[0] masked_labels[i, :first_assistant] -100 return masked_labels3.4 SFT训练参数设置SFT阶段的学习率应该明显低于预训练。预训练峰值学习率是3e-4SFT我设置的是1e-5全参微调可以到2e-5LoRA微调可以用5e-5到1e-4。学习率过高的典型表现就是训练集loss降到很低但验证集生成质量崩掉模型出现复读机现象。epoch数建议控制在1到3之间。13万条数据其实很多2个epoch基本能让模型充分拟合超过3个epoch的边际收益很低反而增加过拟合风险。我实测4个epoch后模型开始出现对高频模板的机械复读。dropout这里有个坑预训练模型通常dropout设置较高但SFT阶段建议把dropout降到0或者接近0。因为SFT数据量远小于预训练高dropout会让模型在拟合指令数据时变得“软弱”输出不稳定。我把所有Attention和MLP层的dropout置为0后生成稳定度提升非常明显。LoRA和全参微调的取舍上如果数据和算力都充裕全参微调最优LoRA的优势是训练完只需要保存几十MB的adapter权重迭代速度快。但如果你的目标是做完整RLHF链路LoRA的局限性会在PPO阶段暴露——策略梯度的更新很不稳定低秩更新空间可能无法承载PPO阶段的大幅度策略调整。所以规划PPO的话建议SFT阶段直接全参微调。3.5 SFT阶段容易踩的两个性能坑SFT阶段最常见的性能坑是loss下降但生成质量没变化。排查思路是先看模板有没有问题——模板里的特殊token如果在词表里被错误地拆分模型根本不知道这是一个独立tokenloss当然降但模型学不到格式约束。我建议用代码验证每个特殊token的id是否被正确保留token在词表中是否作为一个整体存在。这是一个非常耗时的排查点但找到后会恍然大悟。第二个坑是数据泄漏。SFT数据集里如果混入了预训练阶段见过的文本会造成过拟合假象。我的做法是把SFT数据在预训练语料里做了最近邻检索凡相似度超过0.85的样本全部剔除保证SFT数据是模型“没见过的”。4. PPO阶段价值对齐是一个“系统”不只是算法4.1 RLHF思想为什么用强化学习而非继续SFTSFT已经是“模型根据指令输出答案”那为什么还需要PPO核心原因是SFT只能模仿已有答案无法超出数据集中答案的分布范围。如果SFT数据里没有“简洁回答”的例子模型很难自行学会简洁即使有SFT也无法让模型习得一个全局的偏好优先级。PPO引入了一个奖励模型作为“偏好信号源”。训练过程中模型不断生成新的回答奖励模型对回答打分策略模型根据分数调整生成策略。这种在线学习的核心价值是模型会逐步探索出那些“数据中没有明确出现但整体偏好更优”的回答模式。奖励模型可以直接替代人工对海量生成结果的评估。用一个生活化类比解释PPOSFT阶段像学生看标准答案做练习题目和答案都是固定的PPO阶段像老师给作业打分但不给标准答案学生通过不断尝试来理解老师的评分偏向。4.2 PPO的四模型架构Actor、Ref、Reward、CriticPPO阶段需要四个模型同时存在Actor策略模型就是我们最终要训练并部署的模型Ref参考模型是SFT阶段保存的模型且参数冻结用于约束Actor不要偏离SFT模型太远避免策略崩溃Reward奖励模型对生成结果打分参数冻结Critic价值模型用于估计状态价值函数给优势函数提供baseline训练过程中参数会更新。Actor和Critic来自同一个底座SFT模型初始化Ref就是SFT保存的权重Reward需要在SFT基础上做一个独立的奖励模型头。这四个模型同时在显存里显存开销接近三倍单模型是PPO阶段最大的工程压力。必须注意Actor和Ref的初始权重必须完全一致。如果Ref在SFT阶段结束后又经历了任何参数变化而Actor没有同步KL散度的约束起点就会出现偏移训练一开始就处于不稳定状态。一个最简单的检查方法训练启动前把Actor和Ref的权重文件做逐参数对比误差应为0。4.3 奖励模型Reward Model的训练细节奖励模型本身也是训练出来的。我给Reward模型设计了pairwise ranking loss对同一个问题准备两个回答一个偏优、一个偏差让模型学会区分优劣。核心loss公式为loss -log(sigmoid(reward_chosen - reward_rejected))这个公式的含义是模型给优质回答的分数越高给劣质回答的分数越低整体loss越小。实际训练中需要把分数先做个归一化防止reward数值范围漂移。我在训练Reward模型时加了标签平滑技术将目标概率从1平滑到0.9这在数据噪声较大的pair对中能显著提升稳定性。Reward模型的训练数据质量要求极高。如果训练数据里有大量标注错误或有争议的偏好对Reward模型会对某些无意义特征产生偏好PA模型就会放大这个偏差。我准备训练样本是从线上真实对话中抽样排序、再由标注团队做两两对比生成的每个样本至少独立标注两次不一致的样本直接废弃。另外必须提醒的是PPO训练中reward模型分数最好做标准化——用训练过程中running mean和std把reward分数映射到均值为0方差为1的正态分布。否则奖励分数绝对值过大或过小都会导致策略更新步长失控。4.4 PPO核心机制KL散度、GAE和策略更新PPO阶段最核心的目标函数可以拆成三个部分奖励模型给出的奖励、KL散度惩罚、以及PPO特有的clip项。KL散度惩罚的公式是kl_penalty β * KL(actor_output_probs, ref_output_probs)。其中β是动态变化的系数。我采用了自适应KL系数调整当KL散度高于目标值比如0.02/token时β增大强化惩罚当KL散度低于目标值时β减小。这样能让策略保持在SFT模型附近但又有足够自由度去探索更优偏好。GAE广义优势估计是PPO里估算动作优势值的关键模块。GAE参数的λ取值会影响优势估计的偏差-方差权衡。λ1时优势估计接近蒙特卡洛采样方差高但无偏λ0时只看即时奖励偏差高但方差低。我的经验和大多数团队的默认选择一样λ取0.95这是个平稳且相对折中的值。策略更新时有一个clip参数控制新旧策略的差异上限我设置为0.2。这意味着新旧策略在某个token的概率比不能超过1.2或低于0.8超过这个范围就截断。这个机制保证了每次更新不会一步跨太大导致策略崩溃。critic的损失则采用MSE loss学习率比Actor稍低我用的是1e-5。4.5 PPO训练超参组合参考PPO超参之间互相影响很强我给出一个经过多次实验验证可用的组合参考rollout数量每batch采样4096条完整responseGAE λ0.95clip范围0.2初始KL系数β0.02KL目标值0.03/token动态调整βActor学习率5e-6Critic学习率1e-5每次迭代的PPO更新轮次4轮温度采样0.7奖励标准化每个batch内做running normalize需要强调的是PPO训练非常吃显存四个模型同时加载通常需要把batch切得很小。我的方案是把rollout生成和梯度更新分开成两个阶段在推理阶段只加载Actor和Ref采样生成大量经验数据存入buffer在训练阶段再加载Reward和Critic用buffer中的数据进行策略更新。这个“生成-更新”分离设计能够显著降低显存峰值。4.6 PPO训练中的“奖励欺骗”现象PPO阶段最典型的问题就是reward hacking——模型学会钻奖励模型的空子。比如奖励模型偏好结构化回答模型就会在回答里强行加一堆bullet point内容其实没什么价值奖励模型偏好“礼貌语气”模型就会在每句回答后加“感谢您的提问”。我排查这个问题的方法是观察响应的平均长度和句法复杂度变化趋势。正常训练中响应长度应该整体稳定如果发现响应长度持续增长或者标点使用频率急剧上升基本可以确认模型在钻reward的空子。解决思路有三个一是提升Reward模型本身的质量二是在KL散度惩罚上加大力度三是加入response长度惩罚因子。我当时用的长度惩罚方案简单但有效在reward分数上减去一个系数乘以response长度超出target部分。这样模型在优化奖励分数和缩短冗余长度之间必须做出权衡。4.7 观察指标与训练收敛判断PPO训练过程中不要只盯着reward曲线。reward曲线上升可能是好事也可能意味着模型已经偏离到钻空子的方向必须配合观测以下指标KL散度值应保持在预设目标范围内过高说明模型偏离SFT版本太远response长度变化持续增长的响应长度暗示奖励欺骗文本多样性用生成结果的n-gram重复率评估重复率升高意味着模型开始复读Actor和Ref的预测分布差异分布差异过大需要及时干预收敛判断的实用方法是在每个epoch结束做一次人工评估用一组固定的测试prompt检查生成结果质量对比上一版的变化。如果连续2个epoch里人工评估分数没有提升说明当前超参组合下已经接近收敛可以停止训练。5. 三个阶段衔接的工程实践复盘5.1 数据配比与token消耗的宏观规划完整跑完三个阶段的token消耗我给一个参考区间预训练阶段大约消耗1万亿token左右基于5亿参数的底座模型SFT阶段大约消耗2亿tokenPPO阶段每次iteration生成推理token约2000万整体训练下来PPO消耗token约1亿。这个比例显示出一个很有趣的事实预训练token数量虽然更大但计算开销是按算力token数计算的PPO虽然token消耗量小但每次token背后的计算链路更长生成多模型推断策略更新所以实际成本一点也不低。对资源有限的团队一个更经济的做法是不用从零预训练10亿级模型而是选择一个合适的开源底座仅做领域适配的增量预训练约500亿到1000亿token再走完整SFT和PPO。这样总token消耗可以控制在预训练全量方案的1/5以内但效果对于垂直场景足够。5.2 模型权重管理checkpoint策略和断点续训三个阶段都会面临分阶段保存checkpoint的问题。我的习惯是预训练阶段每个500步保存一次全量权重保留最近5个checkpoint滚动覆盖SFT阶段在每次epoch结束时保存保留全部epoch版本用于对照PPO阶段每经过10次iteration保存一个actor权重快照保留最近3份这里有个非常容易踩的坑PPO阶段Actor和Ref的初始权重必须来自同一个SFT版本。如果Ref用的是SFT的最终版本Actor用的是SFT的某个中间epoch版本两边的初始分布不一致PPO一开始就会出现KL散度异常表现为奖励不断下降但KL不断上涨几乎无法救回来。5.3 跨阶段数据泄漏的排查三个阶段共享了很多语料来源最容易忽视的是SFT阶段和PPO阶段的数据泄漏。PPO阶段Reward模型的训练数据如果跟SFT训练数据有重叠模型会“认识”这些样本给它们打出虚高的奖励从而污染整个偏好信号。我的做法是每一阶段训练前都做一次数据溯源检测核心实现是对高相似度样本做全量扫描。代码思路大致如下def dedup_across_sets(src_samples, tgt_samples, threshold0.85): # 使用MinHash生成指纹 hash_list [compute_minhash(sample) for sample in src_samples] # 对tgt样本逐一比对返回相似度超过阈值的索引对 dup_pairs [] for i, tgt in enumerate(tgt_samples): tgt_hash compute_minhash(tgt) for j, src_hash in enumerate(hash_list): if jaccard_similarity(tgt_hash, src_hash) threshold: dup_pairs.append((i, j)) return dup_pairs实测下来即便是看似不相关的“用户提问”和“预训练文本”也可能因为隐含的人物、产品名称而产生较高的文本相似度。不要嫌麻烦这个步骤能帮你避免后面大量的返工。5.4 训练停机恢复的一些经验大规模训练过程中断很常见我前后遇到过断点续训后loss突然抬升的情况。排查经历的教训是续训时必须检查三个状态是否完全恢复优化器状态、学习率调度器的当前步数、数据加载器的随机种子和当前位置。特别是随机种子的恢复。Python的random库和PyTorch的dataloader都有各自的seed机制如果只恢复了模型权重而没恢复数据加载顺序模型看到的batch顺序完全不同loss出现一阵波动是正常的。但如果数据加载顺序恢复错误可能出现训练“看起来在继续但实际在乱学”的假象。建议做断点续训前先在日志里记录breakpoint位置的全局step、epoch内step、cycle样本索引三要素。6. 常见问题速查与解决实录6.1 预训练阶段问题排查瓶颈现象之一loss不降。先检查学习率是否过高导致loss震荡再查看数据是否重复太多最后看词表覆盖是否过差。如果中文字符有大量被切成单字节训练效率会非常低。瓶颈现象之二loss降了但生成文本质量差。优先怀疑数据清洗不够彻底——比如错误编码、繁体中文和简体中文混用、HTML标签残留。可以随机抽取500条训练文本做人工扫描很多问题一眼就能看出来。瓶颈现象之三训练中途显存OOM。解决方案有很多减小micro batch size开启梯度检查点功能用计算换显存将优化器状态切成分片策略或启用序列并行方案。我实测梯度检查点能节省约30%显存但训练速度会降约15%。6.2 SFT阶段问题排查SFT后模型输出“嗯”、“好的”这类无意义后缀几乎可以确定是训练数据里混入了过多短回答或低质量样本。排查方法是统计训练数据的回答长度分布把超过设定阈值的低质量答案样本剔除。SFT后模型对指令格式不敏感用户怎么问它都按固定模板回答。这大概率是模板中user部分也被强制参与学习导致模型把用户输入当作格式的一部分。检查你是否正确设置了mask。6.3 PPO阶段问题排查reward数值一路上涨但生成质量变差几乎可以认定是reward hacking。立即介入检查response长度、重复率、特殊符号使用频率。KL散度爆炸性增长常见原因是Ref和Actor初始化不一致或者是PPO更新轮数过多导致策略偏移太大。减少PPO update轮数、增大KL惩罚系数、降低Actor学习率这三招按顺序试。critic loss不下降说明价值函数没有学到有效信息。可能原因是GAE的优势估计数值范围过大建议对advantage做标准化处理。6.4 显存不足时的降级方案全流程四个模型确实太占显存。如果资源有限我推荐用低秩适配的方式训练Actor和CriticRef和Reward用4bit量化加载。虽然量化方案在严格训练精度上会有一点点损失但实测下来奖励和KL散度的计算误差可以接受显存占用能从80GB级别降到40GB以内训练还能继续稳定跑下去。7. 收尾一点个人体会完整跑完这个流程后最深的感触是预训练、SFT、PPO这三步不是简单的工程串联每一步的选择都在为下一步铺路。预训练阶段多花心思在数据处理上SFT阶段的收敛质量会明显更好SFT阶段的模板设计和数据质量直接决定PPO能不能稳定收敛。如果你准备走这条完整链路我建议在起步阶段就做好算力规划、数据血缘追踪和节点恢复机制这三个基础打好后面的坑会少很多。最后分享一个执行层面的小技巧每个阶段结束不要急着进入下一个阶段先留出一周时间做系统性的生成质量评估和回看。我曾在SFT阶段发现了一个模板token拼接问题当时模型已经进入PPO结果只能倒回来重新训SFT白白消耗了大概两周的算力。宁可阶段间多验证也不要到后面推倒重来。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
