很多人在大模型落到具体业务时都会卡在同一个问题上通用基座聊得热闹但一放到自己的领域里就是“什么都懂一点什么都不精准”。这时候最直接的思路是微调可微调完了又发现推理成本高得离谱线上根本扛不住。于是就有了这本手册存在的意义——把“微调”和“蒸馏”这两件事放在同一条链路里一起做大模型负责消化知识小模型负责落地干活。我把它写成一本可以直接照着跑的实验手册里面是我自己反复调参、踩坑、反复验证后沉淀下来的步骤和参数适合有GPU资源、正在做垂直领域对话或内容生成落地的人。1. 整体设计从“能用”到“好用”的完整链路1.1 微调和蒸馏在链路中的位置先明确一个观念微调和蒸馏不是同一个问题的两种解法而是两个阶段。微调解决的是“能力适配”让基座模型学会你的领域语言、业务格式、问答方式蒸馏解决的是“成本适配”让一个大模型的判断力转移到一个小模型身上小模型才能被便宜、快速地部署。我习惯把整条链路画成这样通用基座 → 领域数据清洗 → 指令微调SFT→ 得到教师模型 → 构造蒸馏数据 → 训练学生模型 → 评测与上线。教师模型不必是最大的模型但一定要是微调效果稳定、评测达标的那一个。你用一个微调得很烂的教师去蒸馏只会得到一个稳定地烂的学生。这个顺序倒过来后面所有工作都会白费。这条链路最容易被忽视的是蒸馏阶段的数据生产。很多人以为蒸馏就是“拿教师模型的输出当标签”实际上这个输出需要精心设计温度、样本分布、拒绝策略否则学生模型学到的只是教师的“背诵”不是教师的“思考”。蒸馏数据集的质量直接决定学生模型的最终上限。我后面会详细展开这一块。1.2 算力评估与方案选型动手之前先算算账。我遇到过太多人拿着一块显卡就想全参数微调 70B 模型结果 OOM 之后来问我怎么办。其实算力评估很简单按参数规模估算一下就清了一个 7B 模型在 BF16 精度下权重占 14GB梯度再占 14GBAdam 优化器状态通常按 12 字节每参数估算也就是 84GB 左右。也就是说全参数微调一个 7B 模型大概需要 100GB 以上的显存单卡 A100 80G 都不一定够还得开梯度累积和激活重计算。如果你只有单卡建议直接走 LoRA 路线。LoRA 的可训练参数通常只有全部参数的 0.5% 左右优化器状态几乎可以忽略同时用 4bit 量化加载基座7B 模型的权重占用可以压到 5GB 上下单卡 24GB 就能跑起来。蒸馏学生模型时也一样如果学生是 1.5B 或 3B单卡 16GB 完全足够。我先做一个选型表给你一点直观参考方案基座规模显存需求适用场景训练时间参考QLoRA 单卡微调7B12-24GB小团队、单卡实验10万条数据约10-15小时LoRA 多卡微调14B4×40GB效果优先、预算中等10万条数据约6-8小时全参数微调7B80GB以上追求极限效果、有A100/H集群10万条数据约3-5小时全参数微调14B200GB以上大算力团队、核心任务视数据量成倍增加这里的时间是基于常见开源训练框架、8卡并行、批量大小 128 左右的估算实际因数据长度和优化器配置会有波动。核心观点只有一个先用 LoRA 把链路跑通再决定要不要进一步投算力。别一上来就追求全参微调太多项目不是死在效果上是死在算力规划上。2. 微调参数、数据与训练细节2.1 基座模型选择你的能力下限由基座决定选择基座是第一个需要认真思考的环节。我的原则很简单能用大规模高质量基座就不选小规模能用对话优化的版本就不选纯基座版本。这是因为微调本质上是在“给模型补专业课”而不是“教模型做人”。基座在通用知识、推理能力上的不足很难靠几万条领域数据补齐。具体到型号我常用的选择是“Chat版本做蒸馏数据生成Base版本做教师模型微调”。Chat版本本身已经经过一轮对齐输出格式和人类偏好更稳定适合用来生产蒸馏数据Base版本没有被额外对齐污染微调时更容易按照你的数据格式塑造风格适合当教师。当然这个组合不是固定的如果你发现 Base 版本的基础能力明显偏弱也可以直接拿 Chat 版本当教师微调。关键在于先做小样本对比实验而不是听别人怎么说。基座规模也需要和任务难度匹配。简单的意图识别、FAQ 问答1.5B-3B 的学生模型已经够用需要多步推理、复杂指令遵循的任务学生模型再小也要在 7B 量级。教师模型则最好比学生大一个量级。比如教师用 14B学生用 3B这样一个量级的差距蒸馏收益最明显。教师和学生如果一样大那叫自我蒸馏效果也有但提升有限成本上不见得划算。2.2 数据构造与清洗数量不如质量质量不如分布微调数据的构造是我踩坑最多的地方。很多人从网上抓了几十万条问答就直接开训结果模型学会了“话多”没学会“话准”。数据清洗的核心不光是去重和纠错更要看分布。我给一个基本要求领域正样本、通用负样本、格式样本三者的比例建议保持在 6:3:1。领域正样本是你希望模型在真实场景里反复用到的能力比如具体的业务问答、特定格式的文本生成通用负样本是那些模型原来就会、你希望它不要忘记的通用能力比如翻译、基础推理、闲聊格式样本则不需要太多几百条就够了目的是让模型稳定输出你定义的 JSON 或 Markdown 格式。去重这一步也不能省。我用两个层面的去重字符串层面用simhash或者编辑距离语义层面用embedding 相似度计算。字符串完全相同好处理但意思相近、表述不同的样本往往被忽略结果模型在这类样本上反复学习导致某个知识点过拟合而其他样本泛化不足。我一般把 embedding 相似度大于 0.85 的样本合并或者剔除一批这个阈值可以按数据量做调整。还有一个经常被漏掉的细节数据里不要只放“正确答案”要放“正确过程”。在多步推理场景如果一批数据只有提问和最终答案没有中间推理步骤模型学到的只是“凭感觉抄答案”一旦遇到边角情况就崩。我会在指令数据里专门加入思维链字段哪怕中间过程是教师模型生成的也比直接跳答案好。2.3 超参数和训练策略那些你需要反复验证的数值微调超参数没有“万能公式”但有一套我测试下来非常稳定的起点之后再根据 Loss 变化和评测调整。以 LoRA 微调为例参考配置如下参数参考值说明LoRA rank32太小学不动太大显存和过拟合风险增加LoRA alpha64通常设为 rank 的 2 倍LoRA dropout0.05防止小参数量上的过拟合学习率2e-4AdamW配合 10% warmup训练轮数2-3数据量少就 3数据量大就 2批大小16-32需要配合梯度累积达到等效批大小 64 以上最大序列长度2048-4096长文本任务尽量保留 context权重衰减0.01常规取值为什么 LoRA rank 不要随便开大rank 决定了低秩矩阵的表示能力理论上越大越好但实际问题在于训练数据往往不够多rank 一大参数量跟着涨模型更容易把训练集里的噪声背下来。我实际测试里10 万条指令数据以内rank 32 和 rank 64 的差别很小但 rank 64 过拟合出现的轮次更早。所以除非你的数据量已经有几十万这个量级否则 32 是一个性价比很高的选择。学习率方面很多人误以为 LoRA 学习率要和全参数微调一样用 1e-5 级别。实际上 LoRA 只训练新增的低秩矩阵可以用更大的学习率。我用 2e-4 起步如果训练集小就降到 1e-4如果模型是 14B 或者更大就降到 8e-5 左右。判断学习率是否过高的一个简单信号训练前几百步 loss 快速下降但如果下降后出现明显反弹或震荡大概率是学习率偏高。训练策略上两个容易忽略的点。第一个训练过程中一定要留一个纯随机且不参与训练的评测集每个 epoch 结束跑一遍真实业务用例不要只看训练 loss。损失降了不代表模型有效它可能只是在拟合训练集的统计规律。第二个灾难性遗忘非常常见解决方式不是用更低的学习率硬压而是在数据里掺入通用语料。我上面提到的 3 成通用负样本就是防止模型在垂直场景里变得越来越“偏科”。3. 蒸馏从大模型到小模型的知识迁移3.1 蒸馏的本质不是在复制答案而是在复制决策边界微调完成后教师模型已经具备较强的领域能力。蒸馏阶段要做的是把教师的“判断力”教给学生。很多初学者以为蒸馏就是拿教师生成的结果当作 ground truth然后让学生去拟合这些文本这个理解太浅了。真正的蒸馏不仅要学生学会输出什么还要学会在多个可能的答案之间如何分配概率。这就是软标签和温度的作用。教师模型在输出每个词时除了最高概率的 token还会给其他候选 token 一个概率分布。温度 T 的作用是把这些概率差异拉平或放大温度高分布更平滑模型能看到更多“备选表达”温度低分布更尖锐越接近最终答案。蒸馏时学生模型同时拟合温度软化后的分布和真实文本。训练 loss 通常写作 T 的平方乘以 KL 散度再加上一项标准交叉熵。温度 T 平方是为了抵消梯度在软化后变小的影响让两部分 loss 量级一致。用打车场景类比教师像一位经验丰富的老司机他不仅告诉学生“终点到了”还告诉学生“走到哪里该减速、哪些路口容易走错”。只学终点是常规训练连路径和风险一起学才是蒸馏。这也是为什么纯拿教师输出做硬标签训练的学生模型效果总是差一口气。它只学到了“结果”没学到“过程”。3.2 蒸馏数据生产从教师模型里挖掘“好的教学样本”蒸馏数据从哪里来通常有三个来源真实业务日志、人工编写的种子问题、通用指令集合。真实业务日志最宝贵但量少且噪声大种子问题可以通过教师模型批量扩写通用指令集合可以借用开源数据但要注意版权和合规。三个来源结合可以产出一批数量不小且分布相对合理的蒸馏数据。生产流程一般是这样先准备一批种子问题比如 500 到 1000 条覆盖你要做的主要业务场景。然后用教师模型针对每个种子问题生成多个变体变体生成时设置 temperature 在 0.7 到 1.0 之间让表达方式多样化避免生成大量同质样本。接着让教师模型对每个问题生成最终答案这一轮温度要降低到 0.2 左右让输出更稳定准确。最后用规则词表或一个小的分类模型过滤掉低质量输出。蒸馏数据集的比例也要讲究。教师模型也是会出错的如果直接把所有输出都当标准答案学生会把教师的长尾错误也学过来。我建议加入“拒绝采样”步骤让教师模型对同一问题生成多个候选答案再用另一个模型或者人工规则筛选出质量最高的那一个作为标签。对于高频但难答的问题至少保留 3 个不同形式的候选答案再合并。这样做出来的蒸馏数据会比一次性生成的数据干净得多。3.3 学生模型训练温度、loss 组合和步数倍率学生模型训练的超参数与普通微调略有不同核心是三个变量温度 T、蒸馏 loss 权重 alpha、训练步数。我常用的组合是 T3、alpha0.5。T 太大会让软标签过于平滑学生很难学到关键差异T 太小则软标签几乎等于硬标签蒸馏退化为普通微调。alpha 用于控制两个 loss 的平衡alpha 越大越偏向模仿教师的概率分布越小越偏向拟合真实文本。训练步数方面蒸馏往往需要比普通微调更多的步数因为学生模型要拟合的不仅是文本序列还要拟合概率分布。我一般设置蒸馏步数为微调步数的 2 到 3 倍。这听起来耗时但学生模型体积小单步成本比教师低得多整体算力消耗反而可控。另外一个容易被忽略的技巧是“师生同步评估”。训练学生模型时每几百步就在同一个评测集上同时跑教师和学生观察两者在关键样本上的差距。如果学生的输出在某个case上明显偏离教师可以追溯这一步的loss曲线和数据来源判断是样本质量问题还是训练步数不够。不要把评测留到最后才做那样排查问题的成本太高。4. 实操记录一次完整的“教师-学生”模型实验4.1 实验设置和数据准备下面记录一个我做过的模拟项目场景是某智能客服领域。目标是训练一个能理解业务知识、按固定格式回答的小模型。教师模型用了一个开源的 14B Base 版本学生模型用了一个 3B 模型实验环境是两台 8 卡 A100 的服务器一台跑教师微调一台跑蒸馏。业务数据方面我整理了约 3 万条人工标注问答覆盖退换货、物流、优惠券、投诉等高频场景。清洗后剩余 2.4 万条再补充 1 万条通用指令数据作为负样本。把格式样本控制在 1000 条左右。整体数据组合为业务正样本 1.4 万条通用负样本 8000 条格式样本 1000 条再加上业务正样本扩写的 1 万条变体样本总计约 3.3 万条。步数估算设有效批大小为 64每个样本平均长度约 800 token3.3 万条数据训练 3 轮大约需要 1500 步左右。在 8 卡 A100 上教师微调加起来大概 5 小时完成。蒸馏阶段我让学生模型在教师生成的 5 万条蒸馏数据上训练温度设为 3alpha 设为 0.5步数设置为 2500 步耗时大约 4 小时。整体链路一天以内可以跑完。4.2 微调和蒸馏的关键代码结构这里给出一个简化但完整的训练逻辑参考框架用的是开源训练组件。微调阶段核心代码如下import torch from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from transformers import Trainer, TrainingArguments base_model_path your-14b-base-model tokenizer AutoTokenizer.from_pretrained(base_model_path) model AutoModelForCausalLM.from_pretrained( base_model_path, load_in_4bitTrue, device_mapauto ) model prepare_model_for_kbit_training(model) lora_config LoraConfig( r32, lora_alpha64, lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) train_args TrainingArguments( output_dir./teacher_sft, per_device_train_batch_size4, gradient_accumulation_steps8, learning_rate2e-4, warmup_ratio0.1, num_train_epochs3, logging_steps20, save_strategyepoch, bf16True, ) trainer Trainer(modelmodel, argstrain_args, train_datasettrain_dataset) trainer.train()蒸馏训练和普通微调区别集中在 loss 计算上核心代码如下import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, labels, T3.0, alpha0.5): # 温度软化后的 KL 散度 student_soft F.log_softmax(student_logits / T, dim-1) teacher_soft F.softmax(teacher_logits / T, dim-1) kl_loss F.kl_div(student_soft, teacher_soft, reductionbatchmean) * (T ** 2) # 标准交叉熵用于拟合真实标签 ce_loss F.cross_entropy(student_logits.view(-1, student_logits.size(-1)), labels.view(-1)) return alpha * kl_loss (1 - alpha) * ce_loss需要特别说明的是训练前要把教师模型的 logits 提前存下来不要每次训练都实时跑一遍教师推理否则显存占用和训练耗时会同时膨胀。离线保存 logits 虽然会占磁盘空间一个 5 万条的数据集可能占几十 GB但换取的是训练过程的高效和稳定非常划算。4.3 评测指标与结果对比评测不能只看单个分数至少要看四样东西答案准确率、格式通过率、通用能力保留程度、推理延迟。下面是我在这个实验里的对比数据指标教师模型14B学生模型3B没有蒸馏学生模型3B蒸馏后业务答案准确率91.2%80.5%87.6%固定格式通过率96.0%88.4%94.1%通用常识F182.0%74.3%82.6%单条平均推理延迟约450ms约90ms约95ms显存占用约28GB约6GB约6GB这里最值得关注的不是业务准确率而是通用常识 F1。普通微调后的 3B 模型在垂直任务上还行但通用能力下降明显。蒸馏后的 3B 模型在垂直任务上回升同时通用能力基本对齐教师说明蒸馏不仅迁移了“专业能力”还顺手保住了“通用能力”。这个效果在多个不同领域数据上复现过不是单次运气。延迟方面3B 模型相比 14B 模型有四五倍的收益显存也从 28GB 降到 6GB。这样的降幅意味着原来一台只能部署一个 14B 模型的设备现在可以部署四五个 3B 模型还能做模型分组和负载均衡。对于在线推理服务来说这个收益通常比准确率提升更实在。5. 常见问题、排查技巧与我的踩坑记录5.1 高频问题速查表实验做多了总会碰到一些反复出现的问题。我把它们整理成一张速查表遇到类似情况可以直接对照处理问题现象可能原因排查思路与建议训练 loss 初始不降甚至升高学习率过大、数据噪声多、warmup不足先降到 1e-4 试跑 100 步观察标准化数据格式loss 降到某个值后震荡学习率偏高或 batch 偏小降低学习率先试其次增大有效 batch训练 loss 正常但评测输出乱码推理参数问题而非训练问题检查温度、repetition_penalty、max_new_tokens模型输出全部是一个格式格式样本过多或者数据重复度太高降低格式样本比例增加格式变体微调后通用能力明显下降通用负样本比例不足通用负样本至少 3 成起越多越稳蒸馏后效果和学生硬训练差不多温度太低软的分布没有起作用把 T 从 1 提高到 3重新检查 soft 目标蒸馏数据里教师答案有大量重复教师生成温度太低或 prompt 太固定提高生成温度到 0.8增加 prompt 变体学生模型在长文本上频繁重复训练长度不够或蒸馏数据偏短在蒸馏数据里混入长文本样本多卡训练速度没提升数据加载成为瓶颈提前做 tokenization 的缓存减少重复处理这张表里每一项我都踩过。最典型的坑是 loss 震荡我一度以为是模型结构问题后来把学习率从 4e-4 降到 1.5e-4问题立刻缓解。所以遇到训练异常时优先怀疑超参数而不是模型结构。5.2 关于教师输出和评测的几条实战心得最后分享几条我个人在实际操作中最受用的心得。第一个心得是“教师输出要尽量离线缓存”。蒸馏过程中如果需要反复调整学生模型参数每次重跑教师模型推理的成本太高。我会把所有教师 logits 保存为本地文件之后训练时直接读取。这样即使 T 和 alpha 改来改去也不需要重新跑一遍教师。实验迭代速度会快很多。第二个心得是“评测集要包含魔鬼样本”。很多人从评测集里抽掉了那些很难回答、连人工都要想半天的题目理由是模型答不对。这些魔鬼样本恰恰是检验蒸馏是否生效的关键。我会把教师答对、学生答错的样本单独列出来人工判断问题出在知识缺失还是表达迁移不足。如果是知识缺失补相关蒸馏数据如果是表达问题调整温度或者增加相似样本。没有这一步你很难定位学生模型的短板。第三个心得是“数据质量的红线不能碰”。我见过有人拿几千条数据就期望模型产生质变也见过有人攒了百万条数据但大部分都是从开放平台上爬来的同质文本。两相对比前者的效果往往更好。微调和蒸馏都是“数据吞吞吐吐”的活输入垃圾输出连垃圾都不如。先用几百条高质量数据验证链路再决定要不要大规模扩展是我反复验证过的最稳妥路径。这本手册到这里已经覆盖了微调和蒸馏的完整实验路径从算力评估、数据构造、超参数设置到教师模型训练、蒸馏数据生产、学生模型训练再到评测对比和问题排查。每个环节单独看都不复杂但串联起来时细节决定了最终效果能到什么程度。希望这份实验记录能帮你少绕几次弯路直接跑通自己的微调和蒸馏链路。