我最近在整理一批模型微调和蒸馏的实验记录，发现这两件事虽然常常被放在一起聊，但实际操作逻辑完全不同：微调是让模型“懂场景”，蒸馏是让模型“跑得起”。很多刚入门的朋友经常把两者混为一谈，或者不知道该先做哪一步，结果训出来的模型要么不懂业务，要么部署不动。这篇手册就是我基于自己跑过的几十组实验，做的一份偏实操的总结，覆盖从方案选型、数据准备、训练参数、蒸馏策略到评估排错的完整链路。无论你是打算做垂直领域助手，还是想把大模型压缩到边端设备，都能从这里找到可以直接照做的路径和避坑经验。
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目标，对教师模型明显输出低质量的样本直接过滤掉，不再进入学生模型的训练。
还有一种情况是学生模型的多轮对话能力退化。如果你用的底座模型本身是多轮对话模型，但蒸馏数据里全是单轮指令，学生就容易丢掉多轮上下文能力。处理方式是蒸馏数据里混入一些带历史对话的样本，保持数据比例均衡。
结尾：一点个人体会
写到这里，我把微调和蒸馏实验里大部分值得注意的地方都过了一遍。最后想多说一句：实验记录比实验结果本身更重要。我每次跑一组微调或蒸馏都会把教师、学生、数据分布、所有关键参数、评测输出完整存档，这个习惯帮我避开了很多“复现不出效果”的坑。也不是每次实验都能成功，有几次蒸馏后的学生模型效果明显不如直接用原版底座小模型做前缀提示，那种时候坦然承认方案不行，比硬调参数更有价值。希望这份手册能帮你少走一点弯路，把实验做成确定性的工程，而不是碰运气。
