大概从年初开始我就在琢磨一件事手里没有大规模集群也调不起商业API能不能就用一两张消费级显卡把一个小语言模型从零到可用的全流程完整跑一遍。最后我用代号 Xihe 把这条路走通了。整个过程压缩成一句话就是预训练练语感CPT转方向SFT教规矩PEFT省成本蒸馏借智慧DPO调偏好。这篇文章会把每个环节里我真实用过的参数、数据和调试方法摊开来讲也会把当时踩过的坑指出来。适合已经会 PyTorch 和 Transformers 基础操作、想完整走一遍 LLM 训练链路的人参考。1. 从零训一个小模型先算清“小”字怎么写很多人一说“训练语言模型”就想到动辄几千亿参数、上万张显卡的大工程。真到自己动手时反而被这套阵仗吓住了。我的看法很直接如果你只是想验证预训练、SFT、DPO 这条技术路线甚至想做一个能跑在本地、回答垂直领域问题的小助手完全不需要复刻 LLaMA 的训练规模。一个参数在 0.1B~1B 之间的小模型配上几亿到几十亿 token 的数据已经足够把整条链路跑通还能看出不同训练阶段带来的实际差异。1.1 为什么选 2 亿参数左右作为起点Xihe 的初始版本我定在 2 亿参数上下。这个体量不是拍脑袋拍的主要卡在硬件条件上我的主力机器是两张 24GB 显存的消费级显卡如果做全量预训练模型本身加上激活值、优化器状态显存压力会非常大。2 亿参数配合混合精度和梯度检查点单卡能塞下双卡还可以做一些简单的数据并行正好卡在“个人折腾”和“实验室小集群”之间的位置。另一个原因是训练速度。小模型迭代极快一轮 1 亿 token 的预训练在双卡环境下大概只需要几小时到一天。这意味着我可以频繁改数据、改超参数快速验证思路。大模型做不到这一点哪怕一次小实验都要排队等几天。做训练链路验证速度就是最大的杠杆。还有一点容易被忽略小模型的推理成本低后期做蒸馏、DPO 评估时可以不停地在本地跑生成测试不用心疼算力。项目命名为 Xihe本来就是我给自己这套流程起的代号模型不大但五脏俱全。1.2 数据、词表与 Tokenizer最容易被低估的一环真正开始准备训练数据我才意识到“模型大小”反而不是最难的部分最难的是弄到干净、多样、符合目标场景的文本语料。预训练阶段我主要用了三类开源数据通用网页清洗文本、中文百科类文本、以及一批书籍和论文语料。总量上大概收集了 20GB 原始文本去重清洗后剩下一半左右。清洗流程比模型训练本身更琐碎。我按下面的顺序来处理每一步都有明确目的去掉 HTML 标签、Markdown 标记、多余空行和零宽字符避免模型学到大量无意义格式。按 MinHash 做近似去重。重复文本会让模型背数据直接表现为 Loss 异常偏低但生成内容泛化差。过滤掉过短的句子和纯列表类文本防止数据碎片化。统一全半角符号处理掉广告、导航等噪声区块。Tokenizer 这块也花了不少时间。我直接用tokenizers库训练了一个 BPE 词表词表大小设为 32000。这个大小对中文场景比较合适太小了中文一个字要拆成多个 token序列利用率低太大了 embedding 层占用显存和内存都更多。训练词表时我特意混入了一定比例的英文代码和数学符号方便后续做代码相关的 CPT 和指令微调。词表训练好后一定要自己检查几个样本看看中文常用字、常见英文单词、数字串有没有被拆得离谱。Tokenizer 出了问题后面所有阶段都会被污染。1.3 参数量、计算量和显存的粗估公式这里分享一个我一直在用的粗估方法。对于 decoder-only 的 Transformer训练总计算量近似是6 * 参数量 * token数这个数字对应的是前向反向的标准 FLOPs。Xihe 按 2 亿参数算如果训 10 亿 token总计算量大概是 1.2e18 FLOPs。两张消费级显卡的实际 FP16 算力加起来按 80 TFLOPS 算理论上几十小时能完成但加上数据加载、通信、评估、断点保存这些开销实际一般按天计算。所以我的建议是先把训练数据量缩减到一个“能在一天内看到明显 Loss 变化”的水平再逐步扩大不要一上来就追求刷完整个数据集。显存方面可以直接套经验值全量训练时模型参数、梯度、Adam 优化器状态大约需要16 bytes * 参数量的显存2 亿参数就是 3.2GB 左右。真正吃显存的是激活值尤其是长序列和了大 batch size。序列长度 512、batch size 32 的情况下加上中间激活单卡 24GB 是够用的。如果后续把序列长度拉到 2048就必须开梯度检查点或减小 batch。计算之前先拿这个公式估一遍能少走很多弯路。2. 预训练实操先让模型把“人话”练顺预训练是整个流程的地基。这一步的目标不是让模型会回答问题而是让它学会词汇、语法、常识和基本的文本连贯性。很多初学者跳过了预训练直接拿一个开源中文模型做 SFT总觉得节省了时间但其实很多“模型怎么教都教不会”的问题根源就在预训练数据不够或者质量太差。2.1 基础超参数序列长度、batch size、学习率Xihe 预训练阶段的配置我记在下面直接抄作业可以参考超参数设置值说明模型层数 / 隐藏层16 层 / 1024 维约 2 亿参数的配置序列长度512降低显存压力足够学习语感全局 batch size64两张卡各 32配合梯度累积优化器AdamWbeta(0.9, 0.95)学习率3e-4峰值学习率Warmup 步数1000稳定训练初期学习率调度cosine衰减到峰值的 10%Weight decay0.1对 embedding 不做衰减混合精度bf16窄精度训练减少显存这里的核心原则是预训练学习率可以比微调高一个数量级。因为预训练数据量极大模型需要快速拟合文本分布到了 SFT 阶段再用小学习率慢慢修行为。峰值学习率 3e-4 对 2 亿参数的小模型是安全的如果发现 Loss 震荡优先调低而不是加大。训练时我没用 dropout这是语言模型预训练的习惯Dropout 更多是微调阶段为了防止过拟合才加的。2.2 训练过程中的监控与断点续训预训练跑起来之后我最关心的不是单步 Loss而是平滑后的 Loss 曲线和 Perplexity。可以在每 200 步打印一次日志每 2000 步做一次小样本困惑度评估。小模型训练容易出现一个假象Loss 下降很快但打开生成结果一看全是重复的套话。这时候需要看生成样本而不是只看数字。断点续训一定要做扎实。我用的是 Transformers 的 Trainer 框架自动保存设置在save_steps1000。保存内容除了模型权重还必须包含 optimizer、scheduler、RNG state这样中断后可以继续训练。考虑到我经常改数据我会在加载时检查当前步数对应的数据集位置避免续训时重复读前面的数据导致数据分布不一致。这个细节很关键很多训练中断后 Loss 反弹就是因为没有正确恢复到数据流位置。2.3 预训练阶段最容易踩的坑第一个坑是数据重复和“脏数据”导致 Loss 抖动。一开始我拿爬虫数据直接训Loss 降到 3 左右就再也下不去了打开生成结果发现模型会重复一些电商广告语。后来重新做了去重和规则过滤Loss 才继续下降。语言模型对数据分布极其敏感少量噪声数据就会在生成结果里被放大。第二个坑是序列拼接方式。小模型训练时如果把多个短文本随便拼到一个序列里模型会学到跨文本的伪关联。我的做法是在每个文档末尾加上eos分隔符再按自然边界切分尽量不让一句话被切断到两个序列。第三个坑是 bf16 下的 Loss spike。fp16 在小模型上偶尔会因为梯度溢出导致 Loss 突然飙到几十然后再也回不来。后来我把整个训练切到 bf16同时开启梯度裁剪为 1.0这个现象基本消失了。如果是老显卡不支持 bf16就老老实实用 fp32 跑别为了省显存硬上 fp16。3. CPT 继续预训练把通用模型“拉”到目标领域预训练出来的 Xihe 是一个“什么都知道一点”的通才但当我需要它专注在特定领域比如医疗文本、法律文本或者编程代码时直接 SFT 往往会发现模型缺少领域术语和表达习惯。CPT也就是继续预训练就是在通用模型基础上用大量领域语料再做一轮语言模型训练让模型先“读”够领域内容再去微调问答能力。3.1 CPT 和预训练有什么不一样表面上 CPT 和预训练都是 next token prediction但两者的目标完全不同。预训练是从零开始学语言CPT 是在已经会语言的基础上“补课”。所以 CPT 的学习率必须更低训练步数也不用太多否则模型会把之前学到的通用能力冲掉。我给 Xihe 做 CPT 时用的是大约 2GB 的领域文本包含医学问答、药品说明书、诊疗指南这类内容。目标不是让它成为专家而是让它熟悉医学术语的分布比如“适应症”“禁忌症”“不良反应”这些词在什么上下文中出现。训练设置上学习率降到 1e-4序列长度提升到 1024batch size 保持不变总共只训练了大约 2 个 epoch。这里有个很重要的判断标准CPT 阶段结束后通用能力不能明显下降。我通常会在同一个测试集上对比 CPT 前后的困惑度如果通用困惑度上涨超过 10%就说明训练步数太多或者领域数据比例太高了。3.2 数据配比与混合策略做 CPT 最忌讳的就是只拿领域数据训。如果 100% 使用医疗文本模型的语言能力会慢慢偏向医疗风格日常对话能力退化得非常快。我采用的数据配比是 70% 领域语料 30% 通用语料。通用语料可以是预训练时用过的数据也可以重新采一批百科、新闻文本。训练时我把领域数据和通用数据混合成一个个 shard每个 shard 内部做随机洗牌但保证整体比例不变。这样每个训练 batch 里都有两种来源的文本模型每一轮都能同时看到“新知识”和“旧知识”从机制上缓解灾难性遗忘。另一个容易被忽略的点是领域数据的重复检测。很多医疗语料网站之间互相抄表面上看起来 2GB 数据很多实际上可能只有几十万篇不重复的文章。我做了归一化去重之后数据量直接缩水到 1.2GB。宁可少而精不要多而杂。3.3 减少灾难性遗忘的三招如果跑完 CPT 发现通用能力明显下降可以试试这三个办法第一招是回放通用数据。我刚才说的数据混合策略本质就是回放只不过把通用数据比例提高一些比如从 30% 提高到 50%多跑一小段观察恢复情况。第二招是降低学习率。把学习率从 1e-4 降到 5e-5 甚至 3e-5CPT 虽然学得慢但对原有参数的破坏更小。领域知识不需要模型一下记住本来后续 SFT 还会强化。第三招是只训练部分层。有些实现会把模型前几层 freeze 掉只更新后面的层和 LayerNorm相当于把“通用语法能力”锁住只调整“高层语义映射”。我当时试过冻结 embedding 层和前 4 层 Transformer效果还不错但收敛速度会略慢。这三招不是互斥的实际项目中我经常用第一招加第二招的组合。核心思路就一条CPT 不是二次预训练而是有节制的领域适配。4. SFT 监督微调教模型回答问题预训练和 CPT 做完了Xihe 已经能续写文本但你问它问题它只会顺着你的问题往下编不会规规矩矩回答。SFT 阶段就是给它看大量“用户提问-标准回答”的样本让它学会对话的格式和内容。4.1 指令数据长什么样指令数据的质量直接决定了模型后续的上限。我整理了两类数据来源开源指令数据集和自造数据。自造数据主要来自一个很土但有效的方法先让一个大模型基于领域文档生成问答对再人工抽检修正。一个标准的训练样本长这样bosuser高血压患者可以服用哪些降压药/userassistant高血压患者应在医生指导下根据自身情况选择药物。常用的降压药包括 ACEI、ARB、钙通道阻滞剂、利尿剂等。具体用药需要综合考虑患者年龄、合并症和血压水平。/assistanteos这个格式本身不是唯一的但你一旦定了格式预训练、SFT、后续测试都要保持一致。我见过不少项目在 SFT 时随便换 prompt 模板结果模型生成混乱。从预训练开始就确定特殊分隔符后面所有阶段都不要改。SFT 数据量不需要幻想几十万条。对于一个小模型几万条高质量的问答对已经能带来肉眼可见的变化。我最终用了 5 万条左右覆盖知识问答、多轮对话、意图识别、文本改写四种类型。数据数量上宁缺毋滥一条答非所问的坏样本会拖累很多好样本。4.2 训练时只让模型学 Response 部分的 LossSFT 和预训练虽然都在做自回归但有一个关键细节SFT 时不能把所有 token 的 Loss 都算进去否则模型会把“问题”的内容也背下来白白浪费容量。正确做法是对标签做 mask把用户部分的标签设为 -100这样计算交叉熵时自动忽略这些位置。labels input_ids.clone() labels[user_token_mask] -100在 HuggingFace 里直接把labels传给模型就行模型只会计算非 -100 位置的 Loss。这个操作看起来简单但很容易被忽略。如果忘记 mask模型会花费大量能力去记忆用户问题最终表现是回答内容正确率下降而且更容易重复问题中的词句。另一个需要注意的点是 assistant 部分的结束符。我的格式里在回答末尾加eos这样模型能学会在回答结束后停下来而不是一直啰嗦。如果你发现模型生成内容总是戛然而止或无限续写大概率跟结束符处理有关。4.3 SFT 实操要点学习率、轮数、早停SFT 的常规配置是学习率 2e-5 到 3e-5训练轮数 2 到 3 个 epoch全局 batch size 可以比预训练小一些。因为指令数据通常只有几万条大 batch 会让模型很快见过全部数据反而容易过拟合。训练时我留了 5% 的样本作为验证集每个 epoch 结束算一次验证 Loss。如果验证 Loss 在上升而训练 Loss 还在下降就是典型的过拟合信号果断早停。小模型在 SFT 中过拟合的现象非常常见因为模型容量相对数据量来说太大了一旦反复看过太多遍同样的数据就会开始“背答案”。还有一个我踩过的坑把多个 epoch 的结果平均。有些人会训练 5 个 epoch 然后把 checkpoints 做权重平均来提升效果这种方法在 SFT 上是有效的但前提是每个 checkpoint 的验证 Loss 都在可接受范围内。如果某个 checkpoint 已经过拟合平均只会拖累整体。只选验证 Loss 最低的 checkpoint 是更稳妥的做法。5. PEFT用 LoRA 给模型“换脑子”SFT 之后的 Xihe 已经能回答问题了。但你会发现一个现实问题业务场景很多今天想适配医疗明天想适配法律后天想适配代码。每次都用全量微调成本太高而且每微调一次都要保存一个完整模型副本。这时候就该 PEFT 上场了。5.1 为什么不用全量微调全量微调的意思是所有模型参数都参与更新。对于 2 亿参数的 Xihe 其实还能接受但如果你用的是 7B 或 13B 的开源模型全量微调一张卡完全放不下而且每个任务都要存一份完整权重维护成本很高。PEFT 的核心思想是冻结原始权重只训练极少数新增参数。我用的是最普遍的 LoRA。LoRA 的原理可以用一句话说明在 Transformer 的线性层旁边加两个低秩矩阵用低秩矩阵的乘积来模拟权重更新量。推理时可以把低秩矩阵合并回原权重不增加任何额外推理耗时。对 Xihe 这种小模型LoRA 的好处更多是工程上的训练速度快、显存占用低、多个任务可以各自训一个 adapter切换时只需要加载不同的 adapter 文件。我甚至给同一个基座模型同时训了医疗问答和代码生成两个 LoRA使用场景完全不同互不干扰。5.2 LoRA 关键参数rank、alpha 和 target_modulesLoRA 最关键的三个参数是rrank、alpha缩放系数和target_modules作用目标。我给 Xihe 的 SFT 后 LoRA 适配配置如下lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, )r决定了低秩矩阵的宽度。理论上r越大表达能力越强但训练参数和显存也会增加而且过大的r在小规模数据上反而容易过拟合。从实践中看r16是多数任务的安全起点。alpha实际上是缩放系数最终生效的权重更新量为alpha / r * 低秩乘积。我习惯把alpha设为2 * r即 16 配 32。target_modules很多人只设置q_proj和v_proj觉得这样参数量少。我的经验是如果要适配一个全新领域最好把q/k/v/o四个投影层都加上。注意力层是模型捕捉语义关系最核心的地方只调其中两个投影信息通路不完全效果会打折扣。当然参数量会多一些但对应的是效果更稳。5.3 LoRA 训练与合并的实操细节用 LoRA 做 SFT 时把基座模型冻结只给 adapter 传梯度。训练时优化器状态只包含 LoRA 参数所以显存占用会小很多。如果基座模型本身已经很大还可以用量化后的基座配 LoRA也就是常说的 QLoRA把基座量化为 4-bitLoRA 保持 16-bit 训练。XLora 这套流程我后来也跑过效果基本不损失。训练完成后LoRA 权重可以单独保存只有几十 MB。但实际部署时我更喜欢把 adapter 合并回基座模型。合并操作本身很简单model PeftModel.from_pretrained(base_model, lora_path) merged_model model.merge_and_unload() merged_model.save_pretrained(xihe_lora_merged)这么做的好处是推理时不再依赖 PEFT 库直接用原生模型加载速度和稳定性都更可控。多个 LoRA 场景下我建议保留独立 adapter不要合并到同一个基座里不然就失去“切换”的意义了。6. 蒸馏拿大模型当老师把小模型教得更聪明到这里Xihe 已经经过预训练、CPT、SFT 和 LoRA 适配能完成不少任务了。但它的表现和那些动辄几十B 的大模型相比答案的流畅度、严谨度和“聪明感”还是差了一截。知识蒸馏就是让大模型当老师把它的知识搬给 Xihe 这个“学生模型”。6.1 蒸馏的本质常规训练里模型学习的是硬标签也就是“这句话只属于第 3 类”这种确定答案。但大模型输出的概率分布里藏着更多信息比如“高血压”这个词后面更可能跟“患者”还是“病人”大模型的概率分布中这些细微倾向都能体现。蒸馏就是让学生模型去拟合老师模型的软概率分布把这些“暗知识”学过来。实际操作中我让一个更大的商用或开源模型对同一批问题生成回答然后让 Xihe 学习这些回答。这里有两种做法第一种是把大模型的回答当作硬文本来做 SFT第二种是用大模型输出的 logits 分布做 KL 散度蒸馏。前者实现简单我大部分场景都用它后者收敛更稳但需要拿到老师模型的 logits工程上更麻烦。6.2 温度、KL 散度与损失权重做软标签蒸馏时温度 T 是一个绕不开的参数。温度的作用是平滑概率分布温度越高概率分布越平滑模型能学到更多“候选词”之间的关系温度太低分布接近 one-hot和硬标签没什么区别。我常用 T2 到 T4 之间。蒸馏的总损失一般是两项加权学生模型与硬标签的交叉熵 学生模型与教师软标签的 KL 散度。权重系数 alpha 通常取 0.5表示两边各占一半。如果数据里硬标签本身很干净可以调高硬标签权重如果你想让学生多学老师“回答风格”就调高 KL 项。温度在训练结束后需要调回 1因为推理时的真实分布不需要平滑。这一点新手很容易忘记导致模型生成结果过于保守。6.3 蒸馏数据怎么做才划算知识蒸馏最大的成本不是训练而是数据生成。大模型生成数据很慢而且同一个问题如果反复问太多遍生成的答案会趋向单一学生模型学到的多样性就不够。我一般控制每个问题只生成 2~3 个候选回答再结合人工抽检和规则过滤去掉空回答和明显错误的内容。另一个经验是蒸馏数据里的 prompt 要尽量贴近真实用户不要全用照本宣科的格式。用户可能说“降压药有哪些”也可能说“医生开的这个药我能不能吃”prompt 一多样学生模型才能真正泛化到真实场景而不是只记住训练时的固定模板。如果条件允许还可以把老师模型的“自我纠错”过程也生成出来比如让老师先给一版答案再说“上面哪里不对修正版本是什么”。这类数据对提升学生模型的长尾能力很有帮助但要注意控制数据长度否则训练时长会显著增加。7. DPO让模型学会说“人爱听的话”SFT 和蒸馏做完之后Xihe 基本能做到“有问必答”但它偶尔还是会输出冗长废话、立场摇摆或者语气不好的内容。要解决这类偏好问题过去的主流方案是 RLHF训练奖励模型再做强化学习。但 RLHF 实在太不稳定了奖励模型训练容易崩溃PPO 超参数又多。DPODirect Preference Optimization直接跳过了训练奖励模型的环节只用偏好对来优化策略模型非常适合在小模型上落地。7.1 从 RLHF 到 DPO简化偏好对齐传统 RLHF 需要一个奖励模型给答案打分再用强化学习算法调整策略模型。DPO 的核心思想是策略模型和参考模型之间的概率比本身就隐含了奖励信息可以直接用偏好数据构造损失函数不需要单独的奖励模型。用大白话说RLHF 相当于先请一个“评委”再让选手按评委意见反复练DPO 则是直接拿“评委的评分记录”让选手学习省掉评委这个角色。这个简化对小项目来说太友好了因为训练奖励模型本身就需要大量人工标注代价很高。我在实际使用中DPO 的训练稳定性和 SFT 差不多只要数据构造正确基本不会出现 PPO 那种奖励模型 Reward Hacking 的问题。当然 DPO 也不是万能的它对偏好数据的质量要求非常高一对烂数据可能抵消十对好数据。7.2 偏好数据构建成对样本怎么来DPO 的标准训练数据是一对样本一个是较好回答chosen一个是较差回答rejected。我需要构造出同一问题下两个质量明显有差异的回答。最简单的方式是用大模型生成两个风格不同的回答然后人工排序。我的排序标准通常考虑三个维度一是正确性错误信息必须排在劣二是相关性答非所问算劣三是风格简洁清晰优于冗长绕圈。如果一个 pair 的两个回答差异不明显我会直接丢弃因为 DPO 需要的是清晰偏好信号模糊 pair 会让梯度方向反复震荡。偏好数据量不需要太大几千对高质量 pair 就能看到效果。我用 3 万对数据做了实验发现模型在上面花太多步数后会出现一种“为了偏好而失去内容”的现象生成变得过于谨慎什么都说“请咨询专业医生”。后来把训练步数减半同时只保留差异明显的 pair效果反而更好。7.3 DPO 训练的 beta、学习率与稳定性DPO 有一个核心超参数beta它控制对参考模型的偏离程度。beta越大模型越不敢偏离参考模型训练更稳定但偏好改变也越弱beta越小模型可以更大胆地改变行为但容易跑偏。我大多数实验用beta0.1如果数据噪声大就提高到 0.2数据很干净就降到 0.05。DPO 训练时会把参考模型和策略模型都加载进显存内存开销接近两份模型。我的做法是参考模型完全不更新梯度用torch.inference_mode()包起来只保留策略模型的反向传播能省不少显存。学习率用 1e-6 到 1e-5 之间比 SFT 还要低。因为 DPO 是在 SFT 后的模型上做“微调中的微调”步子大了容易摧毁已经学到的格式和内容。训练时每隔几百步就在固定测试集上生成一些样本人工看一眼。如果发现模型变得话痨或者过于保守立刻降低 beta 或者减小学习率。别等到一个完整 epoch 跑完再检查那就太迟了。8. 常见问题与排查实录整条链路跑下来我遇到的问题远比上面写的多。这里把最典型、最容易被搜索引擎翻到的问题整理成速查表希望能让后来者少交点学费。8.1 训练 Loss 不降或突然飞升Loss 不降先看数据再看学习率最后看模型实现。一个通用排查顺序现象可能原因解决办法Loss 一直很高数据噪声大、tokenizer 词表不匹配清洗数据、重训 tokenizerLoss 缓慢下降后平台期学习率太低、数据量不足调高学习率、增加数据Loss 突然暴涨后不恢复fp16 梯度溢出换 bf16、增加 gradient clipLoss 出现周期性波动每个 epoch 重复数据打乱 shard 顺序、做去重训练 Loss 很低但生成很差数据重复、模型在背答案去重、增加数据多样性其中“Loss 很低但生成很差”是最迷惑人的情况。我在预训练阶段遇到过后来意识到是因为训练集里大量网页模板重复模型只需要背住模板就能把 Loss 刷得很低。换了去重后的数据Loss 稍微回升了一些但生成质量肉眼可见地变好了。8.2 显存不足与序列长度平衡显存不够是最常见的硬件问题尤其是当你从 SFT 切到 DPO发现要同时加载两个模型的时候。我建议按顺序尝试减小 batch size并用梯度累积补足全局 batch。开启梯度检查点用少量速度换大量显存。减小序列长度比如从 2048 降到 1024如果任务不依赖长上下文收益很大。全量微调改 LoRA冻结基座模型。基座模型量化到 4-bit再挂 LoRA。有一点要提醒序列长度影响的不只是显存还有模型对长文本的理解能力。如果你最终部署场景需要处理长文档不要在预训练阶段就把序列长度降到 256后面 SFT 再想靠短序列模型处理长文本会非常吃力。最好从头到尾保持一个能接受的序列长度比如 512 或 1024。8.3 怎么判断模型真的变好了Loss 只是训练信号不是产品指标。我在每个阶段都会准备一个固定的 20~50 条 prompt 测试集包含知识问答、开放生成、多轮对话、恶意输入等类型。每个阶段训练完手工逐条看生成结果给每一条打一个“可用/勉强/不可用”的标签。这个动作看起来很原始但比任何自动化指标都可靠。如果你想要一个自动化指标也可以用分类准确率、BLEU 等但对生成式语言模型来说这些指标很容易被“高分低质”骗过。我后来养成的习惯是每天跑完训练后随机抽 10 条生成结果粘贴到聊天软件里当普通消息发给自己看看像不像一个真人写出来的。如果一眼就能看出是模型套话说明还没训练到位。另外一个容易被忽略的评估维度是“变化幅度”。同一个 prompt 在预训练、CPT、SFT、蒸馏、DPO 之后的输出应该逐步变好。如果某个阶段之后突然变差大概率是哪一步超参数出了问题要及时回滚到上一个 checkpoint而不是继续硬着头皮往下训。最后再分享一点个人心得。整套流程跑完我最大的体会是训练小语言模型最难的不是某个算法原理而是把数据、格式、超参数和评估连成一条线。预训练、CPT、SFT、PEFT、蒸馏、DPO 每一步单独看都不复杂但它们之间互相影响前面埋的雷会在后面突然爆出来。如果你也想自己跑一遍我建议先别追求大模型、大数据从 1 亿参数的模型和几亿 token 的数据开始把链路跑通再逐步放大。每个阶段都固定好测试集记录每一版模型的输出样本你会看到模型一步步“懂事”的过程这个正反馈是坚持下去的最大动力。
大概从年初开始我就在琢磨一件事手里没有大规模集群也调不起商业API能不能就用一两张消费级显卡把一个小语言模型从零到可用的全流程完整跑一遍。最后我用代号 Xihe 把这条路走通了。整个过程压缩成一句话就是预训练练语感CPT转方向SFT教规矩PEFT省成本蒸馏借智慧DPO调偏好。这篇文章会把每个环节里我真实用过的参数、数据和调试方法摊开来讲也会把当时踩过的坑指出来。适合已经会 PyTorch 和 Transformers 基础操作、想完整走一遍 LLM 训练链路的人参考。1. 从零训一个小模型先算清“小”字怎么写很多人一说“训练语言模型”就想到动辄几千亿参数、上万张显卡的大工程。真到自己动手时反而被这套阵仗吓住了。我的看法很直接如果你只是想验证预训练、SFT、DPO 这条技术路线甚至想做一个能跑在本地、回答垂直领域问题的小助手完全不需要复刻 LLaMA 的训练规模。一个参数在 0.1B~1B 之间的小模型配上几亿到几十亿 token 的数据已经足够把整条链路跑通还能看出不同训练阶段带来的实际差异。1.1 为什么选 2 亿参数左右作为起点Xihe 的初始版本我定在 2 亿参数上下。这个体量不是拍脑袋拍的主要卡在硬件条件上我的主力机器是两张 24GB 显存的消费级显卡如果做全量预训练模型本身加上激活值、优化器状态显存压力会非常大。2 亿参数配合混合精度和梯度检查点单卡能塞下双卡还可以做一些简单的数据并行正好卡在“个人折腾”和“实验室小集群”之间的位置。另一个原因是训练速度。小模型迭代极快一轮 1 亿 token 的预训练在双卡环境下大概只需要几小时到一天。这意味着我可以频繁改数据、改超参数快速验证思路。大模型做不到这一点哪怕一次小实验都要排队等几天。做训练链路验证速度就是最大的杠杆。还有一点容易被忽略小模型的推理成本低后期做蒸馏、DPO 评估时可以不停地在本地跑生成测试不用心疼算力。项目命名为 Xihe本来就是我给自己这套流程起的代号模型不大但五脏俱全。1.2 数据、词表与 Tokenizer最容易被低估的一环真正开始准备训练数据我才意识到“模型大小”反而不是最难的部分最难的是弄到干净、多样、符合目标场景的文本语料。预训练阶段我主要用了三类开源数据通用网页清洗文本、中文百科类文本、以及一批书籍和论文语料。总量上大概收集了 20GB 原始文本去重清洗后剩下一半左右。清洗流程比模型训练本身更琐碎。我按下面的顺序来处理每一步都有明确目的去掉 HTML 标签、Markdown 标记、多余空行和零宽字符避免模型学到大量无意义格式。按 MinHash 做近似去重。重复文本会让模型背数据直接表现为 Loss 异常偏低但生成内容泛化差。过滤掉过短的句子和纯列表类文本防止数据碎片化。统一全半角符号处理掉广告、导航等噪声区块。Tokenizer 这块也花了不少时间。我直接用tokenizers库训练了一个 BPE 词表词表大小设为 32000。这个大小对中文场景比较合适太小了中文一个字要拆成多个 token序列利用率低太大了 embedding 层占用显存和内存都更多。训练词表时我特意混入了一定比例的英文代码和数学符号方便后续做代码相关的 CPT 和指令微调。词表训练好后一定要自己检查几个样本看看中文常用字、常见英文单词、数字串有没有被拆得离谱。Tokenizer 出了问题后面所有阶段都会被污染。1.3 参数量、计算量和显存的粗估公式这里分享一个我一直在用的粗估方法。对于 decoder-only 的 Transformer训练总计算量近似是6 * 参数量 * token数这个数字对应的是前向反向的标准 FLOPs。Xihe 按 2 亿参数算如果训 10 亿 token总计算量大概是 1.2e18 FLOPs。两张消费级显卡的实际 FP16 算力加起来按 80 TFLOPS 算理论上几十小时能完成但加上数据加载、通信、评估、断点保存这些开销实际一般按天计算。所以我的建议是先把训练数据量缩减到一个“能在一天内看到明显 Loss 变化”的水平再逐步扩大不要一上来就追求刷完整个数据集。显存方面可以直接套经验值全量训练时模型参数、梯度、Adam 优化器状态大约需要16 bytes * 参数量的显存2 亿参数就是 3.2GB 左右。真正吃显存的是激活值尤其是长序列和了大 batch size。序列长度 512、batch size 32 的情况下加上中间激活单卡 24GB 是够用的。如果后续把序列长度拉到 2048就必须开梯度检查点或减小 batch。计算之前先拿这个公式估一遍能少走很多弯路。2. 预训练实操先让模型把“人话”练顺预训练是整个流程的地基。这一步的目标不是让模型会回答问题而是让它学会词汇、语法、常识和基本的文本连贯性。很多初学者跳过了预训练直接拿一个开源中文模型做 SFT总觉得节省了时间但其实很多“模型怎么教都教不会”的问题根源就在预训练数据不够或者质量太差。2.1 基础超参数序列长度、batch size、学习率Xihe 预训练阶段的配置我记在下面直接抄作业可以参考超参数设置值说明模型层数 / 隐藏层16 层 / 1024 维约 2 亿参数的配置序列长度512降低显存压力足够学习语感全局 batch size64两张卡各 32配合梯度累积优化器AdamWbeta(0.9, 0.95)学习率3e-4峰值学习率Warmup 步数1000稳定训练初期学习率调度cosine衰减到峰值的 10%Weight decay0.1对 embedding 不做衰减混合精度bf16窄精度训练减少显存这里的核心原则是预训练学习率可以比微调高一个数量级。因为预训练数据量极大模型需要快速拟合文本分布到了 SFT 阶段再用小学习率慢慢修行为。峰值学习率 3e-4 对 2 亿参数的小模型是安全的如果发现 Loss 震荡优先调低而不是加大。训练时我没用 dropout这是语言模型预训练的习惯Dropout 更多是微调阶段为了防止过拟合才加的。2.2 训练过程中的监控与断点续训预训练跑起来之后我最关心的不是单步 Loss而是平滑后的 Loss 曲线和 Perplexity。可以在每 200 步打印一次日志每 2000 步做一次小样本困惑度评估。小模型训练容易出现一个假象Loss 下降很快但打开生成结果一看全是重复的套话。这时候需要看生成样本而不是只看数字。断点续训一定要做扎实。我用的是 Transformers 的 Trainer 框架自动保存设置在save_steps1000。保存内容除了模型权重还必须包含 optimizer、scheduler、RNG state这样中断后可以继续训练。考虑到我经常改数据我会在加载时检查当前步数对应的数据集位置避免续训时重复读前面的数据导致数据分布不一致。这个细节很关键很多训练中断后 Loss 反弹就是因为没有正确恢复到数据流位置。2.3 预训练阶段最容易踩的坑第一个坑是数据重复和“脏数据”导致 Loss 抖动。一开始我拿爬虫数据直接训Loss 降到 3 左右就再也下不去了打开生成结果发现模型会重复一些电商广告语。后来重新做了去重和规则过滤Loss 才继续下降。语言模型对数据分布极其敏感少量噪声数据就会在生成结果里被放大。第二个坑是序列拼接方式。小模型训练时如果把多个短文本随便拼到一个序列里模型会学到跨文本的伪关联。我的做法是在每个文档末尾加上eos分隔符再按自然边界切分尽量不让一句话被切断到两个序列。第三个坑是 bf16 下的 Loss spike。fp16 在小模型上偶尔会因为梯度溢出导致 Loss 突然飙到几十然后再也回不来。后来我把整个训练切到 bf16同时开启梯度裁剪为 1.0这个现象基本消失了。如果是老显卡不支持 bf16就老老实实用 fp32 跑别为了省显存硬上 fp16。3. CPT 继续预训练把通用模型“拉”到目标领域预训练出来的 Xihe 是一个“什么都知道一点”的通才但当我需要它专注在特定领域比如医疗文本、法律文本或者编程代码时直接 SFT 往往会发现模型缺少领域术语和表达习惯。CPT也就是继续预训练就是在通用模型基础上用大量领域语料再做一轮语言模型训练让模型先“读”够领域内容再去微调问答能力。3.1 CPT 和预训练有什么不一样表面上 CPT 和预训练都是 next token prediction但两者的目标完全不同。预训练是从零开始学语言CPT 是在已经会语言的基础上“补课”。所以 CPT 的学习率必须更低训练步数也不用太多否则模型会把之前学到的通用能力冲掉。我给 Xihe 做 CPT 时用的是大约 2GB 的领域文本包含医学问答、药品说明书、诊疗指南这类内容。目标不是让它成为专家而是让它熟悉医学术语的分布比如“适应症”“禁忌症”“不良反应”这些词在什么上下文中出现。训练设置上学习率降到 1e-4序列长度提升到 1024batch size 保持不变总共只训练了大约 2 个 epoch。这里有个很重要的判断标准CPT 阶段结束后通用能力不能明显下降。我通常会在同一个测试集上对比 CPT 前后的困惑度如果通用困惑度上涨超过 10%就说明训练步数太多或者领域数据比例太高了。3.2 数据配比与混合策略做 CPT 最忌讳的就是只拿领域数据训。如果 100% 使用医疗文本模型的语言能力会慢慢偏向医疗风格日常对话能力退化得非常快。我采用的数据配比是 70% 领域语料 30% 通用语料。通用语料可以是预训练时用过的数据也可以重新采一批百科、新闻文本。训练时我把领域数据和通用数据混合成一个个 shard每个 shard 内部做随机洗牌但保证整体比例不变。这样每个训练 batch 里都有两种来源的文本模型每一轮都能同时看到“新知识”和“旧知识”从机制上缓解灾难性遗忘。另一个容易被忽略的点是领域数据的重复检测。很多医疗语料网站之间互相抄表面上看起来 2GB 数据很多实际上可能只有几十万篇不重复的文章。我做了归一化去重之后数据量直接缩水到 1.2GB。宁可少而精不要多而杂。3.3 减少灾难性遗忘的三招如果跑完 CPT 发现通用能力明显下降可以试试这三个办法第一招是回放通用数据。我刚才说的数据混合策略本质就是回放只不过把通用数据比例提高一些比如从 30% 提高到 50%多跑一小段观察恢复情况。第二招是降低学习率。把学习率从 1e-4 降到 5e-5 甚至 3e-5CPT 虽然学得慢但对原有参数的破坏更小。领域知识不需要模型一下记住本来后续 SFT 还会强化。第三招是只训练部分层。有些实现会把模型前几层 freeze 掉只更新后面的层和 LayerNorm相当于把“通用语法能力”锁住只调整“高层语义映射”。我当时试过冻结 embedding 层和前 4 层 Transformer效果还不错但收敛速度会略慢。这三招不是互斥的实际项目中我经常用第一招加第二招的组合。核心思路就一条CPT 不是二次预训练而是有节制的领域适配。4. SFT 监督微调教模型回答问题预训练和 CPT 做完了Xihe 已经能续写文本但你问它问题它只会顺着你的问题往下编不会规规矩矩回答。SFT 阶段就是给它看大量“用户提问-标准回答”的样本让它学会对话的格式和内容。4.1 指令数据长什么样指令数据的质量直接决定了模型后续的上限。我整理了两类数据来源开源指令数据集和自造数据。自造数据主要来自一个很土但有效的方法先让一个大模型基于领域文档生成问答对再人工抽检修正。一个标准的训练样本长这样bosuser高血压患者可以服用哪些降压药/userassistant高血压患者应在医生指导下根据自身情况选择药物。常用的降压药包括 ACEI、ARB、钙通道阻滞剂、利尿剂等。具体用药需要综合考虑患者年龄、合并症和血压水平。/assistanteos这个格式本身不是唯一的但你一旦定了格式预训练、SFT、后续测试都要保持一致。我见过不少项目在 SFT 时随便换 prompt 模板结果模型生成混乱。从预训练开始就确定特殊分隔符后面所有阶段都不要改。SFT 数据量不需要幻想几十万条。对于一个小模型几万条高质量的问答对已经能带来肉眼可见的变化。我最终用了 5 万条左右覆盖知识问答、多轮对话、意图识别、文本改写四种类型。数据数量上宁缺毋滥一条答非所问的坏样本会拖累很多好样本。4.2 训练时只让模型学 Response 部分的 LossSFT 和预训练虽然都在做自回归但有一个关键细节SFT 时不能把所有 token 的 Loss 都算进去否则模型会把“问题”的内容也背下来白白浪费容量。正确做法是对标签做 mask把用户部分的标签设为 -100这样计算交叉熵时自动忽略这些位置。labels input_ids.clone() labels[user_token_mask] -100在 HuggingFace 里直接把labels传给模型就行模型只会计算非 -100 位置的 Loss。这个操作看起来简单但很容易被忽略。如果忘记 mask模型会花费大量能力去记忆用户问题最终表现是回答内容正确率下降而且更容易重复问题中的词句。另一个需要注意的点是 assistant 部分的结束符。我的格式里在回答末尾加eos这样模型能学会在回答结束后停下来而不是一直啰嗦。如果你发现模型生成内容总是戛然而止或无限续写大概率跟结束符处理有关。4.3 SFT 实操要点学习率、轮数、早停SFT 的常规配置是学习率 2e-5 到 3e-5训练轮数 2 到 3 个 epoch全局 batch size 可以比预训练小一些。因为指令数据通常只有几万条大 batch 会让模型很快见过全部数据反而容易过拟合。训练时我留了 5% 的样本作为验证集每个 epoch 结束算一次验证 Loss。如果验证 Loss 在上升而训练 Loss 还在下降就是典型的过拟合信号果断早停。小模型在 SFT 中过拟合的现象非常常见因为模型容量相对数据量来说太大了一旦反复看过太多遍同样的数据就会开始“背答案”。还有一个我踩过的坑把多个 epoch 的结果平均。有些人会训练 5 个 epoch 然后把 checkpoints 做权重平均来提升效果这种方法在 SFT 上是有效的但前提是每个 checkpoint 的验证 Loss 都在可接受范围内。如果某个 checkpoint 已经过拟合平均只会拖累整体。只选验证 Loss 最低的 checkpoint 是更稳妥的做法。5. PEFT用 LoRA 给模型“换脑子”SFT 之后的 Xihe 已经能回答问题了。但你会发现一个现实问题业务场景很多今天想适配医疗明天想适配法律后天想适配代码。每次都用全量微调成本太高而且每微调一次都要保存一个完整模型副本。这时候就该 PEFT 上场了。5.1 为什么不用全量微调全量微调的意思是所有模型参数都参与更新。对于 2 亿参数的 Xihe 其实还能接受但如果你用的是 7B 或 13B 的开源模型全量微调一张卡完全放不下而且每个任务都要存一份完整权重维护成本很高。PEFT 的核心思想是冻结原始权重只训练极少数新增参数。我用的是最普遍的 LoRA。LoRA 的原理可以用一句话说明在 Transformer 的线性层旁边加两个低秩矩阵用低秩矩阵的乘积来模拟权重更新量。推理时可以把低秩矩阵合并回原权重不增加任何额外推理耗时。对 Xihe 这种小模型LoRA 的好处更多是工程上的训练速度快、显存占用低、多个任务可以各自训一个 adapter切换时只需要加载不同的 adapter 文件。我甚至给同一个基座模型同时训了医疗问答和代码生成两个 LoRA使用场景完全不同互不干扰。5.2 LoRA 关键参数rank、alpha 和 target_modulesLoRA 最关键的三个参数是rrank、alpha缩放系数和target_modules作用目标。我给 Xihe 的 SFT 后 LoRA 适配配置如下lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, )r决定了低秩矩阵的宽度。理论上r越大表达能力越强但训练参数和显存也会增加而且过大的r在小规模数据上反而容易过拟合。从实践中看r16是多数任务的安全起点。alpha实际上是缩放系数最终生效的权重更新量为alpha / r * 低秩乘积。我习惯把alpha设为2 * r即 16 配 32。target_modules很多人只设置q_proj和v_proj觉得这样参数量少。我的经验是如果要适配一个全新领域最好把q/k/v/o四个投影层都加上。注意力层是模型捕捉语义关系最核心的地方只调其中两个投影信息通路不完全效果会打折扣。当然参数量会多一些但对应的是效果更稳。5.3 LoRA 训练与合并的实操细节用 LoRA 做 SFT 时把基座模型冻结只给 adapter 传梯度。训练时优化器状态只包含 LoRA 参数所以显存占用会小很多。如果基座模型本身已经很大还可以用量化后的基座配 LoRA也就是常说的 QLoRA把基座量化为 4-bitLoRA 保持 16-bit 训练。XLora 这套流程我后来也跑过效果基本不损失。训练完成后LoRA 权重可以单独保存只有几十 MB。但实际部署时我更喜欢把 adapter 合并回基座模型。合并操作本身很简单model PeftModel.from_pretrained(base_model, lora_path) merged_model model.merge_and_unload() merged_model.save_pretrained(xihe_lora_merged)这么做的好处是推理时不再依赖 PEFT 库直接用原生模型加载速度和稳定性都更可控。多个 LoRA 场景下我建议保留独立 adapter不要合并到同一个基座里不然就失去“切换”的意义了。6. 蒸馏拿大模型当老师把小模型教得更聪明到这里Xihe 已经经过预训练、CPT、SFT 和 LoRA 适配能完成不少任务了。但它的表现和那些动辄几十B 的大模型相比答案的流畅度、严谨度和“聪明感”还是差了一截。知识蒸馏就是让大模型当老师把它的知识搬给 Xihe 这个“学生模型”。6.1 蒸馏的本质常规训练里模型学习的是硬标签也就是“这句话只属于第 3 类”这种确定答案。但大模型输出的概率分布里藏着更多信息比如“高血压”这个词后面更可能跟“患者”还是“病人”大模型的概率分布中这些细微倾向都能体现。蒸馏就是让学生模型去拟合老师模型的软概率分布把这些“暗知识”学过来。实际操作中我让一个更大的商用或开源模型对同一批问题生成回答然后让 Xihe 学习这些回答。这里有两种做法第一种是把大模型的回答当作硬文本来做 SFT第二种是用大模型输出的 logits 分布做 KL 散度蒸馏。前者实现简单我大部分场景都用它后者收敛更稳但需要拿到老师模型的 logits工程上更麻烦。6.2 温度、KL 散度与损失权重做软标签蒸馏时温度 T 是一个绕不开的参数。温度的作用是平滑概率分布温度越高概率分布越平滑模型能学到更多“候选词”之间的关系温度太低分布接近 one-hot和硬标签没什么区别。我常用 T2 到 T4 之间。蒸馏的总损失一般是两项加权学生模型与硬标签的交叉熵 学生模型与教师软标签的 KL 散度。权重系数 alpha 通常取 0.5表示两边各占一半。如果数据里硬标签本身很干净可以调高硬标签权重如果你想让学生多学老师“回答风格”就调高 KL 项。温度在训练结束后需要调回 1因为推理时的真实分布不需要平滑。这一点新手很容易忘记导致模型生成结果过于保守。6.3 蒸馏数据怎么做才划算知识蒸馏最大的成本不是训练而是数据生成。大模型生成数据很慢而且同一个问题如果反复问太多遍生成的答案会趋向单一学生模型学到的多样性就不够。我一般控制每个问题只生成 2~3 个候选回答再结合人工抽检和规则过滤去掉空回答和明显错误的内容。另一个经验是蒸馏数据里的 prompt 要尽量贴近真实用户不要全用照本宣科的格式。用户可能说“降压药有哪些”也可能说“医生开的这个药我能不能吃”prompt 一多样学生模型才能真正泛化到真实场景而不是只记住训练时的固定模板。如果条件允许还可以把老师模型的“自我纠错”过程也生成出来比如让老师先给一版答案再说“上面哪里不对修正版本是什么”。这类数据对提升学生模型的长尾能力很有帮助但要注意控制数据长度否则训练时长会显著增加。7. DPO让模型学会说“人爱听的话”SFT 和蒸馏做完之后Xihe 基本能做到“有问必答”但它偶尔还是会输出冗长废话、立场摇摆或者语气不好的内容。要解决这类偏好问题过去的主流方案是 RLHF训练奖励模型再做强化学习。但 RLHF 实在太不稳定了奖励模型训练容易崩溃PPO 超参数又多。DPODirect Preference Optimization直接跳过了训练奖励模型的环节只用偏好对来优化策略模型非常适合在小模型上落地。7.1 从 RLHF 到 DPO简化偏好对齐传统 RLHF 需要一个奖励模型给答案打分再用强化学习算法调整策略模型。DPO 的核心思想是策略模型和参考模型之间的概率比本身就隐含了奖励信息可以直接用偏好数据构造损失函数不需要单独的奖励模型。用大白话说RLHF 相当于先请一个“评委”再让选手按评委意见反复练DPO 则是直接拿“评委的评分记录”让选手学习省掉评委这个角色。这个简化对小项目来说太友好了因为训练奖励模型本身就需要大量人工标注代价很高。我在实际使用中DPO 的训练稳定性和 SFT 差不多只要数据构造正确基本不会出现 PPO 那种奖励模型 Reward Hacking 的问题。当然 DPO 也不是万能的它对偏好数据的质量要求非常高一对烂数据可能抵消十对好数据。7.2 偏好数据构建成对样本怎么来DPO 的标准训练数据是一对样本一个是较好回答chosen一个是较差回答rejected。我需要构造出同一问题下两个质量明显有差异的回答。最简单的方式是用大模型生成两个风格不同的回答然后人工排序。我的排序标准通常考虑三个维度一是正确性错误信息必须排在劣二是相关性答非所问算劣三是风格简洁清晰优于冗长绕圈。如果一个 pair 的两个回答差异不明显我会直接丢弃因为 DPO 需要的是清晰偏好信号模糊 pair 会让梯度方向反复震荡。偏好数据量不需要太大几千对高质量 pair 就能看到效果。我用 3 万对数据做了实验发现模型在上面花太多步数后会出现一种“为了偏好而失去内容”的现象生成变得过于谨慎什么都说“请咨询专业医生”。后来把训练步数减半同时只保留差异明显的 pair效果反而更好。7.3 DPO 训练的 beta、学习率与稳定性DPO 有一个核心超参数beta它控制对参考模型的偏离程度。beta越大模型越不敢偏离参考模型训练更稳定但偏好改变也越弱beta越小模型可以更大胆地改变行为但容易跑偏。我大多数实验用beta0.1如果数据噪声大就提高到 0.2数据很干净就降到 0.05。DPO 训练时会把参考模型和策略模型都加载进显存内存开销接近两份模型。我的做法是参考模型完全不更新梯度用torch.inference_mode()包起来只保留策略模型的反向传播能省不少显存。学习率用 1e-6 到 1e-5 之间比 SFT 还要低。因为 DPO 是在 SFT 后的模型上做“微调中的微调”步子大了容易摧毁已经学到的格式和内容。训练时每隔几百步就在固定测试集上生成一些样本人工看一眼。如果发现模型变得话痨或者过于保守立刻降低 beta 或者减小学习率。别等到一个完整 epoch 跑完再检查那就太迟了。8. 常见问题与排查实录整条链路跑下来我遇到的问题远比上面写的多。这里把最典型、最容易被搜索引擎翻到的问题整理成速查表希望能让后来者少交点学费。8.1 训练 Loss 不降或突然飞升Loss 不降先看数据再看学习率最后看模型实现。一个通用排查顺序现象可能原因解决办法Loss 一直很高数据噪声大、tokenizer 词表不匹配清洗数据、重训 tokenizerLoss 缓慢下降后平台期学习率太低、数据量不足调高学习率、增加数据Loss 突然暴涨后不恢复fp16 梯度溢出换 bf16、增加 gradient clipLoss 出现周期性波动每个 epoch 重复数据打乱 shard 顺序、做去重训练 Loss 很低但生成很差数据重复、模型在背答案去重、增加数据多样性其中“Loss 很低但生成很差”是最迷惑人的情况。我在预训练阶段遇到过后来意识到是因为训练集里大量网页模板重复模型只需要背住模板就能把 Loss 刷得很低。换了去重后的数据Loss 稍微回升了一些但生成质量肉眼可见地变好了。8.2 显存不足与序列长度平衡显存不够是最常见的硬件问题尤其是当你从 SFT 切到 DPO发现要同时加载两个模型的时候。我建议按顺序尝试减小 batch size并用梯度累积补足全局 batch。开启梯度检查点用少量速度换大量显存。减小序列长度比如从 2048 降到 1024如果任务不依赖长上下文收益很大。全量微调改 LoRA冻结基座模型。基座模型量化到 4-bit再挂 LoRA。有一点要提醒序列长度影响的不只是显存还有模型对长文本的理解能力。如果你最终部署场景需要处理长文档不要在预训练阶段就把序列长度降到 256后面 SFT 再想靠短序列模型处理长文本会非常吃力。最好从头到尾保持一个能接受的序列长度比如 512 或 1024。8.3 怎么判断模型真的变好了Loss 只是训练信号不是产品指标。我在每个阶段都会准备一个固定的 20~50 条 prompt 测试集包含知识问答、开放生成、多轮对话、恶意输入等类型。每个阶段训练完手工逐条看生成结果给每一条打一个“可用/勉强/不可用”的标签。这个动作看起来很原始但比任何自动化指标都可靠。如果你想要一个自动化指标也可以用分类准确率、BLEU 等但对生成式语言模型来说这些指标很容易被“高分低质”骗过。我后来养成的习惯是每天跑完训练后随机抽 10 条生成结果粘贴到聊天软件里当普通消息发给自己看看像不像一个真人写出来的。如果一眼就能看出是模型套话说明还没训练到位。另外一个容易被忽略的评估维度是“变化幅度”。同一个 prompt 在预训练、CPT、SFT、蒸馏、DPO 之后的输出应该逐步变好。如果某个阶段之后突然变差大概率是哪一步超参数出了问题要及时回滚到上一个 checkpoint而不是继续硬着头皮往下训。最后再分享一点个人心得。整套流程跑完我最大的体会是训练小语言模型最难的不是某个算法原理而是把数据、格式、超参数和评估连成一条线。预训练、CPT、SFT、PEFT、蒸馏、DPO 每一步单独看都不复杂但它们之间互相影响前面埋的雷会在后面突然爆出来。如果你也想自己跑一遍我建议先别追求大模型、大数据从 1 亿参数的模型和几亿 token 的数据开始把链路跑通再逐步放大。每个阶段都固定好测试集记录每一版模型的输出样本你会看到模型一步步“懂事”的过程这个正反馈是坚持下去的最大动力。
