我最近在整理一批模型微调和蒸馏的实验记录发现这两件事虽然常常被放在一起聊但实际操作逻辑完全不同微调是让模型“懂场景”蒸馏是让模型“跑得起”。很多刚入门的朋友经常把两者混为一谈或者不知道该先做哪一步结果训出来的模型要么不懂业务要么部署不动。这篇手册就是我基于自己跑过的几十组实验做的一份偏实操的总结覆盖从方案选型、数据准备、训练参数、蒸馏策略到评估排错的完整链路。无论你是打算做垂直领域助手还是想把大模型压缩到边端设备都能从这里找到可以直接照做的路径和避坑经验。1. 微调与蒸馏两个技术的边界与配合1.1 为什么微调和蒸馏总是被放在一起谈大模型从预训练出来之后通用能力是有的但放到具体业务里往往“浑身不自在”。比如你让它处理一份制造业的设备点检记录它可能完全不知道哪些字段是关键信息你让它按企业内部的工单格式输出它大概率会自由发挥出一堆规范之外的内容。微调就是干这件事的——用一批标注好的业务数据继续训练把模型的知识分布往你的场景方向掰一掰。蒸馏则是另一条线。它关心的是“模型太大跑不动”的问题。一个数十B乃至更大规模的模型就算你微调好了放到线上需要几十张卡单次推理延迟跑到秒级业务方根本不可能接受。蒸馏的思路是让一个大模型教师把自己的预测能力尽量迁移给小模型学生让小模型在参数量小一个数量级的前提下逼近大模型的效果。这两者天然互补。微调解决“怎么做才专业”蒸馏解决“怎么用才经济”。实操中常见的高效链路是先在底座模型上做微调得到业务化的大模型再蒸馏到一个小模型上用于部署或者反过来先用一个大模型蒸馏出一个中等模型再基于业务数据对小模型微调。哪种顺序更好取决于你的资源、数据量以及终态部署环境我后面会展开讲。1.2 什么场景该微调什么场景该蒸馏很多项目一上来就问我“要不要微调要不要蒸馏”我的回答通常是反问一句你的瓶颈在效果还是成本如果你有GPU训练资源业务场景高度垂直现有模型输出完全不能用数据积累了不少标注样本那你核心要做的是微调。微调的目标是让模型生成的内容符合你的业务格式、口径和表达习惯。但如果模型本身能用就是推理太慢、显存太高、单次调用成本压不下来那你应该把精力放在蒸馏上。蒸馏的目标是用更小的模型换掉大的同时尽量留住效果。还有一类场景是既要又要边端部署、离线包分发、低延迟高并发的服务模型体积和推理速度是硬指标。这种情况下通常需要先把大模型蒸馏到比如7B、3B甚至1B级别再做任务向的微调避免直接拿一个通用蒸馏小模型去硬扛业务需求。我自己做过一次家庭网关设备上的意图识别就是把一个中等规模的通用模型蒸馏到几百兆的小模型再在少量业务数据上做二次微调效果够用且内存占用压到了设备能接受的范围。2. 微调方案的核心细节从LoRA到全参2.1 主流微调方式怎么选微调方案在实践里基本分成几条路线全参微调、LoRA系列含QLoRA、以及少量其他参数高效微调方法如Adapter。它们的核心区别在于“改多少参数”和“需要多少显存”。全参微调的效果通常是最稳的因为所有层都参与更新模型适应得最彻底但显存开销也最大。一个数十B的模型全参数微调即使采用各种优化手段单卡也很难跑起来基本要上多卡并行。如果不是资源和时间都充裕我一般不建议新手一上来就试全参。LoRA是目前性价比最高的方案。它不是直接改原模型参数而是给特定层注入低秩矩阵训练时只更新这些小矩阵。它的核心优势是显存占用小、速度快效果上很多场景已经逼近甚至持平全参微调。实际操作中需要用到的关键参数包括秩rank、缩放因子alpha、Dropout比例以及作用的目标模块。秩决定了低秩矩阵的容量太小学不进去太大又失去LoRA“省参数”的意义还要多费显存。一个比较实用的区间是8到64之间一般我起步用16或32左右先跑通再往两头探。QLoRA则是在LoRA基础上把底座的权重做4bit量化进一步压缩显存占用让一些原本跑不动的模型也能在单卡上试。代价是训练时间会变长偶尔精度上会有轻微损耗。如果你显卡比较紧张QLoRA是很实用的选择但如果你卡够多够好直接用LoRA更省心。注意不要只看训练阶段。微调完之后的合并产物还是全量参数推理时的显存占用和模型大小取决于合并后的模型。很多人训练用LoRA很快一上线发现推理照样很吃显存这个要提前评估。2.2 数据与模板工程最容易翻车的环节微调效果不好一半以上的原因是数据问题而不是训练参数。这里说的数据问题远不止数量多寡还包括格式一致性。现在多数开源底座模型的指令微调都遵循对话模板比如带system、user、assistant三段结构system定义角色和规则user放任务和输入assistant放期望输出。微调数据的格式必须与模型训练时见过的格式一致。很多人忽略了这一点自己造的模板五花八门模型在推理时根本不认结果微调完效果反而变差。数据规模上垂直领域指令微调有个常见误区——总觉得数据越多越好。实际上数千条高质量样本就足够让模型产生明显的业务化转向盲目堆到几十万条不仅训练成本高还可能出现过拟合和灾难性遗忘。我个人的经验是先把已有数据全部清洗干净去掉格式错误、答案截断、互相矛盾的样本再用规则法加人工抽检给数据分好类确保覆盖业务的常见和不常见输入。最后再按难度分层把容易混淆的样本放进去训练。2.3 训练参数设置的实操经验训练参数是一个容易被搜到一堆数字但不知道为什么的地方。我这里给一组我常用的参考配置适合LoRA微调学习率一般取1e-4到2e-4比全参微调常用的5e-5要高一点因为LoRA更新的参数规模小需要偏大的步长。批次大小per_device_train_batch_size看显存一般1到16之间多轮对话样本比较长经常只能塞小批次。训练轮数1到3轮就够第二轮开始要做数据扰动不然容易过拟合。截断长度根据你的业务输入输出定但要注意不能把回复部分截没了否则模型学到的是半句话。梯度检查点显存不够时开启速度会下降但能显著压显存。训练中要盯的不是“loss越低越好”而是loss曲线是否平滑下降、验证集上的表现何时开始变差。我见过太多人盯着训练loss一路往下冲到很低结果模型只会复读训练数据里的套话业务输出完全不能用。正确的做法是训练中定期保留checkpoint在固定的评测集上对比找到最佳checkpoint而不是最后一个checkpoint才是最好的。3. 蒸馏实验的设计要点把知识“搬”过去的学问3.1 蒸馏的底层逻辑知识蒸馏这个概念可以这样理解大模型不仅知道“这个问题的标准答案是什么”还知道“哪些答案看起来也不差”。前者是硬标签后者是软预测。软预测里包含了模型对相似类别、边界样本的判断倾向这种“暗知识”是蒸馏能让学生模型超过直接在大模型标注数据上训练的关键。蒸馏的核心步骤是计算软标签之间的差异常用KL散度来衡量。温度T在这里起一个软化分布的作用温度越高预测概率分布越平滑类别之间的细微差异被放大更容易把教师模型的判断倾向传递给学生。我常用的蒸馏损失包含两项一项是学生与教师的soft目标之间的KL散度另一项是学生与真实标签之间的标准交叉熵。实际损失可以写成一个带权组合[ L \alpha \cdot T^2 \cdot KL(\text{soft}) (1-\alpha) \cdot CE(\text{hard}) ]这里的alpha控制软标签与硬标签的权重一般从0.5开始调。T的常见范围是3到10之间过高的温度会把分布推得过平反而丢失信息过低的温度就等于直接模仿硬标签蒸馏失去意义。3.2 教师与学生模型的选择蒸馏效果的上限基本由教师模型决定但教师模型不是越大越好关键看它在你目标数据上的表现。如果一个超大模型在你的业务数据上输出质量不高它的软标签里其实全是噪声学生的训练就是在学坏习惯。我建议蒸馏前先在业务评测集上把教师模型的输出质量和格式稳定性跑一遍确认它真的“懂”你的场景再做蒸馏。学生模型的选择要考虑同源和异源两种情况。同源蒸馏教师和学生出自同一模型家族通常更顺滑因为两者的词表和输出空间一致学生容易拟合教师的分布。异源蒸馏则更容易出现“学生学到一些老师的东西但表达不自然”的尴尬需要更多数据来弥补。另外不要太激进。把70B级别的模型直接压到几百M容量差距太大学生根本装不下教师的知识最后只能学到皮毛。我一般的策略是逐级压缩比如先70B蒸馏到13B再评估一次再从13B蒸馏到3B左右。逐级压缩的效果通常比一步到位好很多数据不足时尤其明显。3.3 蒸馏策略与损失函数的搭配蒸馏的实现基本分离线蒸馏和在线蒸馏两大类。离线蒸馏就是先让教师模型把所有训练数据的输出全部跑一遍存好软标签再拿这批离线数据训练学生。好处是简单、教师推理可以并行缺点是面对新数据还得再跑一遍教师。在线蒸馏则是教师和学生同步训练学生每步都看到教师当前状态的输出。这种方法对数据时效性要求高的场景更友好但训练复杂度高不好调试。我在多数实验里优先用离线蒸馏因为可复现性强教师输出一旦存好后续学生模型的调参成本会低很多。在做蒸馏损失的时候还有一个很容易忽略的细节教师预测的soft目标需要除以T进行缩放。如果忘记缩放KL散度会被人为放大损失数值变得不稳定。另外当标签本身存在噪声时要适当降低hard loss的权重让学生更多地依赖教师的软输出这样反而能学到更鲁棒的知识。4. 实验流程从基线评估到数据构建再到训练上线4.1 先做基线再谈优化很多人拿到项目就直接开始微调或者蒸馏这是最容易走弯路的地方。动手之前务必先建立基线拿底座模型直接在你的评测集上跑一批输出记录各项指标的起点。这个基线不是用来发论文的而是用来定位问题的量级。我在一次对话模型微调项目里第一轮基线跑完发现模型对业务场景完全不了解回答里全是通用话术格式匹配率只有三成。这个基线数据让我明确了重点先解决领域指令跟随问题和格式问题。如果不做基线我可能一上来就调训练参数、调学习率方向完全错误。基线评估集的构建也有讲究。至少准备三类数据一类是高频常规场景一类是边界困难场景一类是格式约束严格场景。每一类几十条就够不必多但要精准。评测集要固定不要每次调参都换数据否则无法横向对比。4.2 一条较完整的微调和蒸馏流水线基于我的项目经验整理一条可复用的流水线适合从大模型到小模型部署的完整过程第一步清洗数据。把原始语料里的长篇废话、错误字段、重复内容全部清掉每条样本尽量控制在一个完整语义单元内让模型能学到清晰的任务映射。第二步指令化并规整模板。统一使用system、user、assistant格式system里写清楚角色限定和输出要求user里放输入assistant里放目标输出。如果目标输出有固定格式一定要在system里强调。第三步微调大模型。我一般先跑一轮LoRA微调学习率1.5e-4左右训练1到2轮在评测集上看效果。如果格式和内容还没对齐检查数据模板和标注质量而不是急着调参数。第四步做一次蒸馏前的教师效果验证。把微调后的模型在评测集上完整跑一遍人工翻看几十条输出确认没有系统性的错误。这一步过滤掉那些“看起来很努力其实方向错了”的模型。第五步离线蒸馏。用微调后的大模型当教师生成训练数据集的soft目标然后训练学生模型。学生模型的初始化可以选底座原版小模型也可以选一个已经在通用语料上蒸馏过一次的小模型。后者的收敛速度通常会更快。第六步学生模型的二次微调。蒸馏完成后在小模型上用少量业务数据再做一轮LoRA微调这一步是弥补蒸馏过程中可能丢失的任务细节尤其在格式要求严格的场景里非常有效。第七步全面评估和上线压测。对比学生模型和教师模型在评测集上的效果差距同时测推理延迟、显存占用和吞吐量确认达到上线标准。4.3 硬件配置和训练资源参考先坦白说蒸馏训练的资源需求并不比微调低太多。你以为学生模型小就省资源但实际上你要先跑教师模型推理生成soft目标这一步同样需要大显存。我常用的做法是教师模型用半精度批量推理分块生成soft目标存到磁盘然后再加载学生模型开始训练这样相对省卡。如果你手里只有一块4090级别的卡建议先从QLoRA微调起步模型规模控制在13B以内蒸馏阶段学生模型控制在3B以内。如果你想做更大规模的实验比如教师模型超过70B人工生成soft目标这一步基本要分布式推理至少准备4到8张卡并行。预算有限的情况下也可以找一些开源的蒸馏数据集直接使用省掉教师推理步骤但要仔细核验数据质量。提示软标签文件不要只存概率分布建议一并存下教师模型的输出文本。后续人工抽检、分析错误模式都要用到。5. 评估体系与效果验证别被Loss骗了5.1 自动化指标里的坑机器学习的常规评估套路是看指标但生成式模型的指标设计充满陷阱。第一个坑是ROUGE或BLEU。它们基于n-gram重叠对语义等价但表达不同的输出几乎无感。比如“请退回到首页”和“返回主页面”字面差异大但语义完全一致ROUGE会打低分。这类指标只能做粗筛绝对不能作为最终决策依据。第二个坑是Loss与效果的Gap。训练loss下降不代表生成质量上升尤其是蒸馏场景里学生可能把教师的概率分布复现得相当接近但采样出来的文本因为一个词的概率变化导致整句不对。我建议训练结束后做生成评测而不是拿损失函数来证明一切。第三个坑是困惑度Perplexity。模型对训练数据拟合得越好PPL越低但不代表生成文本正确。高PPL可能只是因为数据分布本身和业务场景差距大。PPL适合做训练曲线监控不适合做上线决策。5.2 人工评估与业务留出集自动化指标顶多帮你抓到明显倒退真正的判断还是要靠人工评估。我做一个微调或蒸馏实验都会抽出一部分业务留出集这些数据在训练中绝不会出现。评估时把基线模型、教师模型、学生模型的输出混杂在一起不标模型名让业务方或者熟悉业务的同事去打分。评估维度我常用四个准确性、相关性、格式合规性和有害性。准确性看事实有没有错相关性看回答是否切题格式合规性看字段、结构是否符合业务预期有害性看有没有输出攻击性、歧视或危险内容。每个维度按1到5分打分。比较不同模型的均值和中位数同时也要看极端低分情况尽量避免上线后偶发一句非常离谱的输出。人工评估的另一个价值是发现训练数据的问题。如果好几个模型的输出都错在同一类案子上说明评测集或训练数据的这一类样本本身就有问题需要回炉。5.3 蒸馏收益的量化方式既然做蒸馏就要把收益量化清楚否则没法向项目相关方交代。我的评估维度包括模型体积、单次推理延迟的P50和P95、峰值显存占用、吞吐量以及效果指标对比如人工评分均值、格式合规率等。把这些数据整理成一个对照表训练和部署的取舍就有了依据。举个例子有一次我把某个通用大模型蒸馏到一个小模型效果指标上人工评分下降了约8%但单次推理延迟从800毫秒降到60毫秒显存占用减少到原来的七分之一吞吐量提升了一个数量级。这种收益对比出来后业务方很快接受了效果上的小损失因为这个模型上线的实际场景对延迟极其敏感。如果蒸馏后效果损失太大先别急着下结论。检查一下是不是soft目标生成时的温度太高或者太低是不是学生模型的容量过于不匹配还有是不是hard loss权重太高导致学生过度拟合噪声标签。逐项调整后再重新蒸馏往往还能挽回很大一部分效果。6. 常见问题与排查技巧实录6.1 训练过程常见故障实战中遇到最多的三个训练故障显存溢出、Loss不下降、Loss降了但输出乱。显存溢出基本是批次大小、序列长度和模型规模三者的组合问题。排查时先看单条样本的最大长度再看梯度检查点开关最后考虑LoRA秩大小。实在不行就开混合精度训练fp16或bf16。有些特定硬件对bf16支持更好精度损失也更小。Loss不下降时先检查学习率是否太低再看数据模板是否统一最后看训练集标签是否有大量重复文本。经常有团队拿了几万条数据开训结果数据里几千条重复模型被重复样本带偏Loss看似下降但验证集一直不涨。Loss降了但输出乱一般是训练轮数太多导致过拟合或者是截断策略把回复截断了。可以用温度稍高的解码参数temperature调大一点先测试如果是过拟合导致的随机乱码可以拉低temperature观察是否缓解。6.2 效果正确但指标不动时的排查项有一种情况很迷惑人工看着输出变好了但自动化指标纹丝不动。出现这种情况先别怀疑模型先怀疑评测脚本和评测数据。我排查顺序是先看解码参数是否一致如temperature、top_p、max_new_tokens再看评测数据是否有空格、标点等预处理差异最后看评测指标本身和业务目标的匹配度。很多时候“指标不动”只是因为评测集太小或者指标对语义不敏感模型产生了真实提升但指标口径捕捉不到。6.3 蒸馏后输出异常蒸馏后学生模型可能出现几种典型异常。一种是输出空洞化所有回答都变得笼统、没有细节。这通常是因为温度太高soft target太平滑学生只学到了“安全的平均”没学到具体的判断。把温度调低一些或者增加hard loss的权重就能缓解。另一种是输出偶尔“翻车”大部分时候正常但个别输入产生完全崩溃的输出。这种往往来自教师模型的soft target本身就带有噪声学生在学的时候把这些噪声也学会了。解决办法是清洗soft目标对教师模型明显输出低质量的样本直接过滤掉不再进入学生模型的训练。还有一种情况是学生模型的多轮对话能力退化。如果你用的底座模型本身是多轮对话模型但蒸馏数据里全是单轮指令学生就容易丢掉多轮上下文能力。处理方式是蒸馏数据里混入一些带历史对话的样本保持数据比例均衡。结尾一点个人体会写到这里我把微调和蒸馏实验里大部分值得注意的地方都过了一遍。最后想多说一句实验记录比实验结果本身更重要。我每次跑一组微调或蒸馏都会把教师、学生、数据分布、所有关键参数、评测输出完整存档这个习惯帮我避开了很多“复现不出效果”的坑。也不是每次实验都能成功有几次蒸馏后的学生模型效果明显不如直接用原版底座小模型做前缀提示那种时候坦然承认方案不行比硬调参数更有价值。希望这份手册能帮你少走一点弯路把实验做成确定性的工程而不是碰运气。