很多人觉得大模型很强但真到落地部署那天就头疼了。一个 70B 级别的开源模型光权重就要占 140GB 显存左右普通机器根本扛不住就算用量化压到 4bit也还是要大几十 GB。可是产品又确实需要理解能力那怎么办这个矛盾我这两年反复遇到最后真正稳定解决问题的还是知识蒸馏。知识蒸馏说白了就是让一个强但笨重的大模型当“老师”把一个轻量的小模型当“学生”用老师的输出去教学生。学生模型不直接看原始标签而是去模仿老师的预测分布把大模型“脑子里那套判断逻辑”尽可能搬进小模型。这样小模型在体积、推理速度上都能便宜很多能力却比直接用小数据训练的小模型高一大截。这篇文章我想和你聊清楚两件事一是蒸馏为什么有效、温度参数到底在干什么二是给出一套我实测过、能直接复现的完整实战流程——从选模型、准备数据集、生成软标签到写蒸馏损失、跑训练、做评估。适合正在做大模型落地、想把模型塞进边端设备或者只是对“怎么压缩模型”感兴趣的工程师。1. 为什么需要蒸馏大模型与小模型的天平1.1 大模型的能力与小模型的成本先别急着写代码把场景理清。大模型确实聪明但它的聪明是有代价的。以我常用的开源 72B 模型为例fp16 推理单卡至少需要 144GB 显存普通人手里无非就是一张 4090 或者几块消费级卡跑 7B 都要抠抠搜搜。如果目标是塞进手机 App、小程序、树莓派这类端侧环境那内存和算力就更紧张别说 72B1.5B 都得掂量掂量。于是大家自然会想到几条路量化、剪枝、蒸馏。量化是把权重从 fp16 变成 int8/int4模型体积和显存确实降下来了但量化主要是在“存储和计算精度”上做文章模型的参数量没变推理时的访存开销依然不低。剪枝是把那些不重要的参数直接删掉能压缩规模可一旦剪多了能力崩塌得很厉害而且和高层语义能力相关的部分很难判断哪一块“不重要”。蒸馏是另一条思路不保留原模型的结构而是训练一个新模型去模仿原模型的行为。它是一个“重新学习”过程小模型的结构可以完全重新设计参数量可以少一个数量级以上但学到的“知识”是老师模型精心整理过的。1.2 知识蒸馏到底在解决什么问题很多人刚接触蒸馏时会问既然已经有标签了直接让小模型用标签训练不就行了吗为什么要绕一圈去学老师的输出关键就在“标签”本身。常规训练里数据集的标签是硬标签(hard label)比如一张图片是猫标签就是“猫”。但现实世界的问题往往是模糊的一张图里有一只猫蹲在沙发上你说它是“猫”还是“猫沙发”大模型不会只给一个确定答案它会给出一个概率分布——“猫 0.83布偶猫 0.07狗 0.02”这就是软标签(soft label)。软标签里的信息密度比硬标签高太多了。0.83 和 0.07 之间的差值本身就暗含了模型的判断逻辑为什么它觉得是猫而不是狗这中间的知识是硬标签完全无法表达的。蒸馏的本质就是让老师模型把这些隐藏的判断逻辑当作“知识”传递给学生模型。我打一个比方你会做一道菜学徒直接照着菜谱学也能做出七分味道但如果你把火候把握、何时放盐、颠勺力度这些经验全部讲给他听他做出来的菜可能就有九分。菜谱是硬标签经验是软标签蒸馏就是在教经验。2. 知识蒸馏核心原理不只是“抄答案”2.1 软标签与温度 THinton 在 2015 年经典论文中提出了知识蒸馏框架核心公式围绕软标签展开。原始的 softmax 输出是这样的[ q_i \frac{\exp(z_i / T)}{\sum_j \exp(z_j / T)} ]这里的 (z_i) 是模型最后一层的 logits未归一化的输出T 是温度参数。T1 时就是普通 softmax。T 越大概率分布越平滑类别之间的差异会被“摊开”那些原本很小的概率也有了学习意义T 太小分布就越接近 one-hot相当于又退回了硬标签。实际选择时T 并不是越大越好。太高了所有类别概率都趋于均匀学生模型分不清重点太低了学生又只能学到“结果”学不到“逻辑”。我常用的区间是 2~6。分类任务我通常用 3~4生成任务调整得会更频繁有时候会到 5 以上。参数经验可以这样记T 越低知识越“锐利”学生学得快但容易学偏T 越高知识越“平滑”学生能看到更多关联信息但噪声也会增大训练初期可以把 T 设高一点让分布更平滑、梯度信息更多训练过程中再逐渐降温T max(2, initial_T * decay_step)这样既学到了结构又不会因为过度平滑导致收敛困难。2.2 蒸馏损失的计算与权重有了软标签损失函数也就变成两部分硬标签分类损失 蒸馏损失。蒸馏损失我用 KL 散度来衡量学生输出和教师输出之间的差异公式是[ L_{distill} KL(softmax(z_t / T) \parallel softmax(z_s / T)) \cdot T^2 ]为什么要乘上 (T^2)这不是经验拍脑袋而是数学上的必然softmax 的梯度本身带 (1/T) 因子经过 KL 反向传播后梯度会变成 (1/T^2)如果不乘回来T 设置得越大梯度越小训练几乎走不动。我初学蒸馏时就忘了乘这个系数T5 的时候训练 loss 死活不降排查了半天才发现是这个细节。总损失一般写成[ L \alpha \cdot L_{distill} (1-\alpha) \cdot L_{hard} ](\alpha) 控制蒸馏损失在总损失中的占比。在 Hinton 原版论文里(\alpha) 取 0.7但实际使用要结合实际任务调节。我做过一组对照实验同一份数据集、同一个学生模型不同 (\alpha) 的最终效果差距非常大(\alpha)蒸馏损失占比测试集准确率0.3较低偏向硬标签学习87.1%0.5均匀89.4%0.7偏向蒸馏学习91.2%1.0纯蒸馏不看硬标签88.6%(\alpha1.0) 的时候反而下降了这说明硬标签信息在训练中仍然起到锚定作用完全丢掉会在某些输入下让学生模型产生明显偏见。我现在的做法是 (\alpha) 设成 0.7 左右并且在训练后期逐步增大等比退火让训练早期以“跟住老师”为主后期再把真实标签信息补进来效果比固定值稳定。2.3 常用蒸馏变体logits 蒸馏只是起点上面这一段是 Hinton 经典方案也就是 logits 蒸馏。它实现简单、兼容性最好但有个天然缺陷它只能让学生的“最终输出”贴近老师中间层学到的语义表征是否一致它管不到。所以在更复杂的场景里工程界常用几种变体特征蒸馏Feature-based Distillation让学生模型某个中间层的输出对齐教师模型对应层的输出常用的对齐函数有 L2 loss 或 cosine similarity。这需要教师和学生的 hidden size 一致或者至少能映射到同一空间。它能让学生学到中间表示但副作用是教师和学生结构差异较大时强行对齐中间层反而会限制学生的表达。关系蒸馏Relational Distillation不再对齐输出本身而是对齐“输出之间的关系”。比如取一批样本比较教师在样本间计算出来的相似度矩阵让学生也保持这个相似关系。这个思路在少样本、跨结构蒸馏场景里特别有效因为关系比绝对值更泛化。自蒸馏Self-Distillation让一个模型自己教自己用训练后期较“成熟”的 checkpoint 去指导早期 checkpoint 的学习。它不需要额外的教师模型工程上常常用来稳定训练、加速收敛。如果只是做端侧小模型任务又比较单一比如文本分类、情感判断、意图识别我建议从 logits 蒸馏起步性价比最高。只有发现学生模型在某些能力上明显跟不上时再考虑特征蒸馏或关系蒸馏。3. 一次完整实战教师 72B学生瘦身到 0.5B3.1 方案选型教师、学生、数据集怎么定纸上谈兵够多了下面进入正题。这是最近一次我实际做过的项目需要把一个大模型部署到一台低配 CPU 服务器上要求支持中文情感/意图四分类准确率尽量高同时单条推理时间不超过 100ms内存占用 1GB 以内。基于这个约束我做了以下选型教师模型Qwen2.5-72B-Instruct我用 vLLM 部署4bit 量化后放在两卡 A100 上。选择它的原因是这个模型在中文理解、文本分类这类任务上表现扎实知识面广输出的置信度分布也比较稳定是个好老师。学生模型Qwen2.5-0.5B-Instruct这是我很常用的小模型基座约 5 亿参数fp16 权重约 1GBINT8 量化后约 500MB纯 CPU 推理也不至于太吃力。更关键的是 Qwen 家族结构统一教师和学生共享相似的分词器和部分模型结构蒸馏时 logits 对齐特别自然。如果不用 Qwen也可以用 LLaMA-3.2-1B 或者国产的 MiniCPM 系列做学生基座核心原则只有一条学生模型的 vocab 结构尽量和教师一致否则对齐 logits 前还要做 embedding 映射麻烦得很。数据集我自建了一个四分类语料包含正面、负面、中性、疑问四类约 3 万条这 3 万条来自公开爬虫语料和人工改写覆盖电商评论、客服对话、社区帖子和新闻短句四类场景。蒸馏阶段我并不依赖原始硬标签的质量但要求数据本身尽量贴近真实部署场景避免教师在一个学生根本不会遇到的输入分布上教学。这里有个重要原则蒸馏用的数据分布必须和实际部署时的输入分布一致。如果用一堆百科句子做蒸馏部署时却要处理口语化的客服消息学生模型大概率会翻车。数据范围宁可窄一点也不要“宽而不实”。3.2 软标签生成用最小代价获得高质量训练目标确定了教师模型后第一件事不是训练而是把所有训练数据的软标签跑出来。我直接用 vLLM 批量推理向教师模型发送 3 万条样本通过 logits 返回每个类别的概率分布。如果要输出 logits 而不是采样文本可以在 vLLM 的 sampling_params 里设置logprobs4一次性返回四个类别的 logprobs。软标签我会保存成一个.npz文件里面每一行是(text, teacher_logits)。这一步有两点要注意第一教师模型一定要用 fp16 或 fp32 跑不要用 INT4/INT8 量化版本。教师模型精度每损失一点软标签里的知识就会失真学生学到的就是“二手失真知识”。我做教师推理时直接用 vLLM 的 fp16不做量化。第二如果数据集很大没必要全部生成软标签后再训练。可以用“动态蒸馏”每轮训练取一个 batch实时让教师模型前向计算 logits然后立刻计算蒸馏损失。优点是不占额外磁盘缺点是每步都要调教师模型训练效率低。我的习惯是先离线生成全部软标签训练时直接读文件这样学生训练完全和教师解耦速度也快。离线生成软标签那段代码示意如下# pseudo code: 使用 vLLM 批量生成软标签 from vllm import LLM, SamplingParams teacher LLM(modelQwen/Qwen2.5-72B-Instruct, tensor_parallel_size2, max_model_len4096) sampling_params SamplingParams( temperature0.0, logprobs4, # 只返回四个类别的 logprob max_tokens1 # 分类任务只需要一个 token ) texts load_all_texts(train_data.jsonl) results teacher.generate(texts, sampling_params) for idx, result in enumerate(results): # 从 result.outputs[0].logprobs 中解析出四分类 logits logits_dict parse_logprobs(result) # 保存为 npz供训练使用 save_one_row(idx, texts[idx], logits_dict)这段代码没什么复杂逻辑就是在批量调用教师模型的接口。注意max_tokens1不要随意加大分类任务只预测最后一个位置的 token加大长度只会浪费显存和推理时间。3.3 蒸馏训练核心代码学生模型我用 HuggingFace Transformers 加载优化器用 AdamW学习率 5e-5 起步线性衰减warmup 500 步。损失函数按上一节写的蒸馏损失实现温度 T 初始设为 4训练中期衰减为 2。完整的核心训练逻辑大概长这样import torch import torch.nn.functional as F from transformers import AutoModelForSequenceClassification, AutoTokenizer from torch.utils.data import DataLoader, Dataset class DistillDataset(Dataset): def __init__(self, texts, teacher_logits, labels): self.texts texts self.teacher_logits teacher_logits self.labels labels def __len__(self): return len(self.texts) def __getitem__(self, idx): return { text: self.texts[idx], teacher_logits: torch.tensor(self.teacher_logits[idx], dtypetorch.float32), label: self.labels[idx], } def distillation_loss(teacher_logits, student_logits, labels, temperature4.0, alpha0.7): # 硬标签交叉熵 ce_loss F.cross_entropy(student_logits, labels) # 蒸馏 KL 散度 teacher_probs F.softmax(teacher_logits / temperature, dim-1) student_log_probs F.log_softmax(student_logits / temperature, dim-1) kl_loss F.kl_div(student_log_probs, teacher_probs, reductionbatchmean) # 乘以 T^2 以抵消梯度中的 1/T^2 因子 kl_loss kl_loss * (temperature ** 2) # 加权求和 total_loss alpha * kl_loss (1.0 - alpha) * ce_loss return total_loss, ce_loss, kl_loss model AutoModelForSequenceClassification.from_pretrained( Qwen/Qwen2.5-0.5B-Instruct, num_labels4 ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-0.5B-Instruct) optimizer torch.optim.AdamW(model.parameters(), lr5e-5) # 训练循环关键部分 for epoch in range(3): for step, batch in enumerate(train_loader): text batch[text] teacher_logits batch[teacher_logits].cuda() labels batch[label].cuda() encodings tokenizer(text, paddingTrue, truncationTrue, max_length128, return_tensorspt).to(cuda) student_logits model(**encodings).logits total_loss, ce_loss, kl_loss distillation_loss( teacher_logits, student_logits, labels, temperaturemax(2.0, 4.0 * (0.9 ** epoch)), alpha0.7 ) optimizer.zero_grad() total_loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step()这段代码我几乎每次做蒸馏都会复用只是换数据集和模型路径。你第一次跑时建议直接把alpha0.7和temperaturemax(2.0, 4.0 * (0.9 ** epoch))这两行原样保留。有个细节batchmean这个 reduction 方式是按 batch 大小做了归一化的和你在很多博客里看到的sum不同。sum会随着 batch size 增大而线性增大loss 数值不稳定batchmean更平稳。我在代码里特意用了batchmean也是踩过坑之后改的。另外注意max_length128是我基于分类任务的实际输入长度制定的如果你的输入更长可以动态调整为 256 或 512代价是训练速度变慢。分类任务一般 128 足够用不要盲目加大。3.4 训练配置与显存控制学生只有 0.5B 参数fp16 下单卡随便跑但很多人的显卡其实不会太好我这里给一个针对 16GB 显存的配置模板照着用即可配置项推荐值备注Student modelQwen2.5-0.5B-Instruct约 1GB 显存Batch size3216GB 显存无压力梯度累积2等效 batch 64精度fp16开启 mixed precision 训练学习率5e-5线性 warmupdecay最大长度128分类任务够用训练 epoch3~5多轮容易过拟合视验证集决定如果你的显存只有 8GB那就把 batch size 降到 16梯度累积改成 4也能跑动只是训练时间会拉长。实际测下来 3 万条数据、3 个 epoch一张 4090 大约 30~40 分钟就能训完完全在可接受范围内。训练完成后把学生模型用model.save_pretrained(student_model)保存再顺手把它导出成 ONNX 或者 GGUF 格式。我这次的部署目标是 CPU 服务器所以我导出为 GGUF 并用 llama.cpp 推理单条推理延迟约 60ms内存占用 800MB满足需求。学生模型在测试集上跑出来的准确率直接微调的小模型是 84.6%蒸馏后提升到了 91.2%而教师的准确率是 98.3%。虽然没有完全追上教师但考虑到参数量差了 140 倍91.2% 已经是我能接受的结果。4. 训练时最容易踩的坑与排查方法4.1 蒸馏半天没提升先查这四个指标蒸馏后效果不佳是最常见的挫败来源。我自己的经验遇到“学生成绩怎么还不如直接微调”的情况先按顺序排查检查一教师软标签的质量。如果教师模型本身准确率只有 80%软标签信息就是“带噪”的学生学得再好上限也不高。所以首先保证教师模型在目标任务上的表现足够好。如果教师能力不足可以换更大的基座、做全参微调或者加一层高质量精标数据把教师先抬起来。检查二学生容量是不是太小。200M 的学生和 0.5B 的学生学习上限完全不同。如果任务偏复杂硬要压到 200M那不是蒸馏能解决的问题。判断方法很直接把学生模型换成教师同规模的模型做一次小规模蒸馏如果效果明显提升说明是学生容量瓶颈建议放宽模型规模需求。检查三温度 T 和 alpha 是否合理。T 太高学生学到过于平滑的分布不够聚焦T 太低又退化成硬标签。alpha 也是我之前做过 alpha1.0 的实验纯蒸馏不学硬标签结果测试集反而掉分。多用几个 T 和 alpha 的组合做小规模消融实验比盲目训练效率高得多。检查四数据分布是否过于单一。如果一个类别的样本在蒸馏集里占 90%学生模型会直接把这个类别的概率拉高完全失去细粒度判断能力。建议每个类别的样本尽量均衡至少不能有某一类占比超过 70%。4.2 损失发散或极不平滑学习率、温度与梯度裁剪训练中 loss 突然变成 NaN或者出现剧烈震荡先别怀疑代码有问题大多离不开这几个原因学习率过大。0.5B 模型用 5e-5 起步是安全的但如果你换成 1e-4 甚至更高很容易在训练初期就发散。学生模型从随机初始化到一个稳定状态需要一个平稳过程。建议先用 1e-5 跑几百步看到 loss 平滑下降再调回 5e-5。蒸馏乘子没加。忘了乘 (T^2)在 T 设得比较大的时候梯度就会过小训练 loss 停留在高位降不下去。这个问题很难一眼发现所以我自己在蒸馏损失函数里把T ** 2写在最显眼的位置并加了注释。KL 散度数值不稳定。如果教师的 logits 里有极端值softmax 后可能出现近似 0 的概率KL 计算时出现 log(0) 报错。我的做法是在teacher_probs上加一个极小项teacher_probs torch.clamp(teacher_probs, min1e-8)既避免 NaN也不影响整体方向。batch size 太小导致梯度噪声大。蒸馏损失比常规 CE 对噪声更敏感batch size 低于 8 时loss 曲线会非常抖动。保险起见 batch size 保持 16 以上配合梯度累积达到等效 32~64。顺便提一句梯度裁剪clip_grad_norm_(max_norm1.0)几乎是必备的。蒸馏训练早期KL 梯度偶尔会冒出很大的尖峰不裁剪的话一个 step 就能把权重打飞模型直接废了。4.3 软标签本身的偏见问题这是一个容易被忽视、但实际影响很大的点。教师模型虽然是“强者”但它也有自己的偏见。比如在情感分类任务里如果部署数据偏向某一类表达风格比如很多口语化的负面评价教师的软标签可能对“中性”和“负面”区分得不够学生学完也会继承这个问题。我在实践里通常这样规避人工抽检 200 条软标签看教师预测错误的样本集中在哪些类型上。如果有明显的系统性错误比如某个类别被整体判偏我会把这部分数据的软标签人工修正或者从训练集里剔除。有时候甚至可以把这部分样本的硬标签权重放大让硬标签在总损失里占更高比例用真实标签把教师的偏见纠正回来。软标签是“大概率正确的经验”但它不是“绝对真理”。尤其在学生容量比教师小很多的情况下错误经验会被快速放大所以训练前做好软标签质量审计非常值得投入时间。4.4 部署阶段的小优化蒸馏训练完成不等于项目结束。学生模型在端侧部署时我还会做两件小事第一导出成 ONNX 或者 GGUF 格式。HuggingFace 的 PyTorch 模型直接上生产环境太重了用torch.onnx.export或llama.cpp的转换脚本把模型压成 GGUF单项速度能快 3~5 倍。我在 CPU 服务器上实测ONNX Runtime 的延迟比 PyTorch 直接推理低不少。第二做一次 INT8 量化。学生模型已经很小再做量化损失也不大。0.5B 的模型 fp16 大约 1GBINT8 大约 0.5GB如果目标是 1GB 以内内存部署这一步几乎是必做项。量化后准确率一般只掉 0.2~0.5 个百分点完全可接受。我一个很深的体会是蒸馏模型不是训完就结束了部署链路里“压缩-导出-量化”这三步做好了最终效果才能从“实验室不错”变成“生产环境可用”。说实话知识蒸馏不是一个炫技型技术它没有太多复杂公式也没有特别酷炫的网络结构改进。它的价值在于把“大模型的能力”从一个昂贵容器里倒进一个便宜容器里而且这个倒腾过程是可复用、稳定、有理论支撑的。我自己做下来最深的体会是蒸馏的效果七分在数据与教师质量三分在训练技巧。教师模型强、软标签分布贴实际场景、学生容量选得合理这三点做好了哪怕损失函数只用最简单的 KL 散度结果都不会差。反过来如果教师羸弱、数据分布歪斜再精巧的蒸馏方法也救不回来。回到最开始的问题大模型怎么落地到端侧、本地、低配环境知识蒸馏给了一个非常务实的答案。每次训练完看到一个几十 MB 或几百 MB 的小模型却能复现出大家伙七八成功力的时候那种满足感确实是做模型压缩的人才能懂的。
很多人觉得大模型很强但真到落地部署那天就头疼了。一个 70B 级别的开源模型光权重就要占 140GB 显存左右普通机器根本扛不住就算用量化压到 4bit也还是要大几十 GB。可是产品又确实需要理解能力那怎么办这个矛盾我这两年反复遇到最后真正稳定解决问题的还是知识蒸馏。知识蒸馏说白了就是让一个强但笨重的大模型当“老师”把一个轻量的小模型当“学生”用老师的输出去教学生。学生模型不直接看原始标签而是去模仿老师的预测分布把大模型“脑子里那套判断逻辑”尽可能搬进小模型。这样小模型在体积、推理速度上都能便宜很多能力却比直接用小数据训练的小模型高一大截。这篇文章我想和你聊清楚两件事一是蒸馏为什么有效、温度参数到底在干什么二是给出一套我实测过、能直接复现的完整实战流程——从选模型、准备数据集、生成软标签到写蒸馏损失、跑训练、做评估。适合正在做大模型落地、想把模型塞进边端设备或者只是对“怎么压缩模型”感兴趣的工程师。1. 为什么需要蒸馏大模型与小模型的天平1.1 大模型的能力与小模型的成本先别急着写代码把场景理清。大模型确实聪明但它的聪明是有代价的。以我常用的开源 72B 模型为例fp16 推理单卡至少需要 144GB 显存普通人手里无非就是一张 4090 或者几块消费级卡跑 7B 都要抠抠搜搜。如果目标是塞进手机 App、小程序、树莓派这类端侧环境那内存和算力就更紧张别说 72B1.5B 都得掂量掂量。于是大家自然会想到几条路量化、剪枝、蒸馏。量化是把权重从 fp16 变成 int8/int4模型体积和显存确实降下来了但量化主要是在“存储和计算精度”上做文章模型的参数量没变推理时的访存开销依然不低。剪枝是把那些不重要的参数直接删掉能压缩规模可一旦剪多了能力崩塌得很厉害而且和高层语义能力相关的部分很难判断哪一块“不重要”。蒸馏是另一条思路不保留原模型的结构而是训练一个新模型去模仿原模型的行为。它是一个“重新学习”过程小模型的结构可以完全重新设计参数量可以少一个数量级以上但学到的“知识”是老师模型精心整理过的。1.2 知识蒸馏到底在解决什么问题很多人刚接触蒸馏时会问既然已经有标签了直接让小模型用标签训练不就行了吗为什么要绕一圈去学老师的输出关键就在“标签”本身。常规训练里数据集的标签是硬标签(hard label)比如一张图片是猫标签就是“猫”。但现实世界的问题往往是模糊的一张图里有一只猫蹲在沙发上你说它是“猫”还是“猫沙发”大模型不会只给一个确定答案它会给出一个概率分布——“猫 0.83布偶猫 0.07狗 0.02”这就是软标签(soft label)。软标签里的信息密度比硬标签高太多了。0.83 和 0.07 之间的差值本身就暗含了模型的判断逻辑为什么它觉得是猫而不是狗这中间的知识是硬标签完全无法表达的。蒸馏的本质就是让老师模型把这些隐藏的判断逻辑当作“知识”传递给学生模型。我打一个比方你会做一道菜学徒直接照着菜谱学也能做出七分味道但如果你把火候把握、何时放盐、颠勺力度这些经验全部讲给他听他做出来的菜可能就有九分。菜谱是硬标签经验是软标签蒸馏就是在教经验。2. 知识蒸馏核心原理不只是“抄答案”2.1 软标签与温度 THinton 在 2015 年经典论文中提出了知识蒸馏框架核心公式围绕软标签展开。原始的 softmax 输出是这样的[ q_i \frac{\exp(z_i / T)}{\sum_j \exp(z_j / T)} ]这里的 (z_i) 是模型最后一层的 logits未归一化的输出T 是温度参数。T1 时就是普通 softmax。T 越大概率分布越平滑类别之间的差异会被“摊开”那些原本很小的概率也有了学习意义T 太小分布就越接近 one-hot相当于又退回了硬标签。实际选择时T 并不是越大越好。太高了所有类别概率都趋于均匀学生模型分不清重点太低了学生又只能学到“结果”学不到“逻辑”。我常用的区间是 2~6。分类任务我通常用 3~4生成任务调整得会更频繁有时候会到 5 以上。参数经验可以这样记T 越低知识越“锐利”学生学得快但容易学偏T 越高知识越“平滑”学生能看到更多关联信息但噪声也会增大训练初期可以把 T 设高一点让分布更平滑、梯度信息更多训练过程中再逐渐降温T max(2, initial_T * decay_step)这样既学到了结构又不会因为过度平滑导致收敛困难。2.2 蒸馏损失的计算与权重有了软标签损失函数也就变成两部分硬标签分类损失 蒸馏损失。蒸馏损失我用 KL 散度来衡量学生输出和教师输出之间的差异公式是[ L_{distill} KL(softmax(z_t / T) \parallel softmax(z_s / T)) \cdot T^2 ]为什么要乘上 (T^2)这不是经验拍脑袋而是数学上的必然softmax 的梯度本身带 (1/T) 因子经过 KL 反向传播后梯度会变成 (1/T^2)如果不乘回来T 设置得越大梯度越小训练几乎走不动。我初学蒸馏时就忘了乘这个系数T5 的时候训练 loss 死活不降排查了半天才发现是这个细节。总损失一般写成[ L \alpha \cdot L_{distill} (1-\alpha) \cdot L_{hard} ](\alpha) 控制蒸馏损失在总损失中的占比。在 Hinton 原版论文里(\alpha) 取 0.7但实际使用要结合实际任务调节。我做过一组对照实验同一份数据集、同一个学生模型不同 (\alpha) 的最终效果差距非常大(\alpha)蒸馏损失占比测试集准确率0.3较低偏向硬标签学习87.1%0.5均匀89.4%0.7偏向蒸馏学习91.2%1.0纯蒸馏不看硬标签88.6%(\alpha1.0) 的时候反而下降了这说明硬标签信息在训练中仍然起到锚定作用完全丢掉会在某些输入下让学生模型产生明显偏见。我现在的做法是 (\alpha) 设成 0.7 左右并且在训练后期逐步增大等比退火让训练早期以“跟住老师”为主后期再把真实标签信息补进来效果比固定值稳定。2.3 常用蒸馏变体logits 蒸馏只是起点上面这一段是 Hinton 经典方案也就是 logits 蒸馏。它实现简单、兼容性最好但有个天然缺陷它只能让学生的“最终输出”贴近老师中间层学到的语义表征是否一致它管不到。所以在更复杂的场景里工程界常用几种变体特征蒸馏Feature-based Distillation让学生模型某个中间层的输出对齐教师模型对应层的输出常用的对齐函数有 L2 loss 或 cosine similarity。这需要教师和学生的 hidden size 一致或者至少能映射到同一空间。它能让学生学到中间表示但副作用是教师和学生结构差异较大时强行对齐中间层反而会限制学生的表达。关系蒸馏Relational Distillation不再对齐输出本身而是对齐“输出之间的关系”。比如取一批样本比较教师在样本间计算出来的相似度矩阵让学生也保持这个相似关系。这个思路在少样本、跨结构蒸馏场景里特别有效因为关系比绝对值更泛化。自蒸馏Self-Distillation让一个模型自己教自己用训练后期较“成熟”的 checkpoint 去指导早期 checkpoint 的学习。它不需要额外的教师模型工程上常常用来稳定训练、加速收敛。如果只是做端侧小模型任务又比较单一比如文本分类、情感判断、意图识别我建议从 logits 蒸馏起步性价比最高。只有发现学生模型在某些能力上明显跟不上时再考虑特征蒸馏或关系蒸馏。3. 一次完整实战教师 72B学生瘦身到 0.5B3.1 方案选型教师、学生、数据集怎么定纸上谈兵够多了下面进入正题。这是最近一次我实际做过的项目需要把一个大模型部署到一台低配 CPU 服务器上要求支持中文情感/意图四分类准确率尽量高同时单条推理时间不超过 100ms内存占用 1GB 以内。基于这个约束我做了以下选型教师模型Qwen2.5-72B-Instruct我用 vLLM 部署4bit 量化后放在两卡 A100 上。选择它的原因是这个模型在中文理解、文本分类这类任务上表现扎实知识面广输出的置信度分布也比较稳定是个好老师。学生模型Qwen2.5-0.5B-Instruct这是我很常用的小模型基座约 5 亿参数fp16 权重约 1GBINT8 量化后约 500MB纯 CPU 推理也不至于太吃力。更关键的是 Qwen 家族结构统一教师和学生共享相似的分词器和部分模型结构蒸馏时 logits 对齐特别自然。如果不用 Qwen也可以用 LLaMA-3.2-1B 或者国产的 MiniCPM 系列做学生基座核心原则只有一条学生模型的 vocab 结构尽量和教师一致否则对齐 logits 前还要做 embedding 映射麻烦得很。数据集我自建了一个四分类语料包含正面、负面、中性、疑问四类约 3 万条这 3 万条来自公开爬虫语料和人工改写覆盖电商评论、客服对话、社区帖子和新闻短句四类场景。蒸馏阶段我并不依赖原始硬标签的质量但要求数据本身尽量贴近真实部署场景避免教师在一个学生根本不会遇到的输入分布上教学。这里有个重要原则蒸馏用的数据分布必须和实际部署时的输入分布一致。如果用一堆百科句子做蒸馏部署时却要处理口语化的客服消息学生模型大概率会翻车。数据范围宁可窄一点也不要“宽而不实”。3.2 软标签生成用最小代价获得高质量训练目标确定了教师模型后第一件事不是训练而是把所有训练数据的软标签跑出来。我直接用 vLLM 批量推理向教师模型发送 3 万条样本通过 logits 返回每个类别的概率分布。如果要输出 logits 而不是采样文本可以在 vLLM 的 sampling_params 里设置logprobs4一次性返回四个类别的 logprobs。软标签我会保存成一个.npz文件里面每一行是(text, teacher_logits)。这一步有两点要注意第一教师模型一定要用 fp16 或 fp32 跑不要用 INT4/INT8 量化版本。教师模型精度每损失一点软标签里的知识就会失真学生学到的就是“二手失真知识”。我做教师推理时直接用 vLLM 的 fp16不做量化。第二如果数据集很大没必要全部生成软标签后再训练。可以用“动态蒸馏”每轮训练取一个 batch实时让教师模型前向计算 logits然后立刻计算蒸馏损失。优点是不占额外磁盘缺点是每步都要调教师模型训练效率低。我的习惯是先离线生成全部软标签训练时直接读文件这样学生训练完全和教师解耦速度也快。离线生成软标签那段代码示意如下# pseudo code: 使用 vLLM 批量生成软标签 from vllm import LLM, SamplingParams teacher LLM(modelQwen/Qwen2.5-72B-Instruct, tensor_parallel_size2, max_model_len4096) sampling_params SamplingParams( temperature0.0, logprobs4, # 只返回四个类别的 logprob max_tokens1 # 分类任务只需要一个 token ) texts load_all_texts(train_data.jsonl) results teacher.generate(texts, sampling_params) for idx, result in enumerate(results): # 从 result.outputs[0].logprobs 中解析出四分类 logits logits_dict parse_logprobs(result) # 保存为 npz供训练使用 save_one_row(idx, texts[idx], logits_dict)这段代码没什么复杂逻辑就是在批量调用教师模型的接口。注意max_tokens1不要随意加大分类任务只预测最后一个位置的 token加大长度只会浪费显存和推理时间。3.3 蒸馏训练核心代码学生模型我用 HuggingFace Transformers 加载优化器用 AdamW学习率 5e-5 起步线性衰减warmup 500 步。损失函数按上一节写的蒸馏损失实现温度 T 初始设为 4训练中期衰减为 2。完整的核心训练逻辑大概长这样import torch import torch.nn.functional as F from transformers import AutoModelForSequenceClassification, AutoTokenizer from torch.utils.data import DataLoader, Dataset class DistillDataset(Dataset): def __init__(self, texts, teacher_logits, labels): self.texts texts self.teacher_logits teacher_logits self.labels labels def __len__(self): return len(self.texts) def __getitem__(self, idx): return { text: self.texts[idx], teacher_logits: torch.tensor(self.teacher_logits[idx], dtypetorch.float32), label: self.labels[idx], } def distillation_loss(teacher_logits, student_logits, labels, temperature4.0, alpha0.7): # 硬标签交叉熵 ce_loss F.cross_entropy(student_logits, labels) # 蒸馏 KL 散度 teacher_probs F.softmax(teacher_logits / temperature, dim-1) student_log_probs F.log_softmax(student_logits / temperature, dim-1) kl_loss F.kl_div(student_log_probs, teacher_probs, reductionbatchmean) # 乘以 T^2 以抵消梯度中的 1/T^2 因子 kl_loss kl_loss * (temperature ** 2) # 加权求和 total_loss alpha * kl_loss (1.0 - alpha) * ce_loss return total_loss, ce_loss, kl_loss model AutoModelForSequenceClassification.from_pretrained( Qwen/Qwen2.5-0.5B-Instruct, num_labels4 ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-0.5B-Instruct) optimizer torch.optim.AdamW(model.parameters(), lr5e-5) # 训练循环关键部分 for epoch in range(3): for step, batch in enumerate(train_loader): text batch[text] teacher_logits batch[teacher_logits].cuda() labels batch[label].cuda() encodings tokenizer(text, paddingTrue, truncationTrue, max_length128, return_tensorspt).to(cuda) student_logits model(**encodings).logits total_loss, ce_loss, kl_loss distillation_loss( teacher_logits, student_logits, labels, temperaturemax(2.0, 4.0 * (0.9 ** epoch)), alpha0.7 ) optimizer.zero_grad() total_loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step()这段代码我几乎每次做蒸馏都会复用只是换数据集和模型路径。你第一次跑时建议直接把alpha0.7和temperaturemax(2.0, 4.0 * (0.9 ** epoch))这两行原样保留。有个细节batchmean这个 reduction 方式是按 batch 大小做了归一化的和你在很多博客里看到的sum不同。sum会随着 batch size 增大而线性增大loss 数值不稳定batchmean更平稳。我在代码里特意用了batchmean也是踩过坑之后改的。另外注意max_length128是我基于分类任务的实际输入长度制定的如果你的输入更长可以动态调整为 256 或 512代价是训练速度变慢。分类任务一般 128 足够用不要盲目加大。3.4 训练配置与显存控制学生只有 0.5B 参数fp16 下单卡随便跑但很多人的显卡其实不会太好我这里给一个针对 16GB 显存的配置模板照着用即可配置项推荐值备注Student modelQwen2.5-0.5B-Instruct约 1GB 显存Batch size3216GB 显存无压力梯度累积2等效 batch 64精度fp16开启 mixed precision 训练学习率5e-5线性 warmupdecay最大长度128分类任务够用训练 epoch3~5多轮容易过拟合视验证集决定如果你的显存只有 8GB那就把 batch size 降到 16梯度累积改成 4也能跑动只是训练时间会拉长。实际测下来 3 万条数据、3 个 epoch一张 4090 大约 30~40 分钟就能训完完全在可接受范围内。训练完成后把学生模型用model.save_pretrained(student_model)保存再顺手把它导出成 ONNX 或者 GGUF 格式。我这次的部署目标是 CPU 服务器所以我导出为 GGUF 并用 llama.cpp 推理单条推理延迟约 60ms内存占用 800MB满足需求。学生模型在测试集上跑出来的准确率直接微调的小模型是 84.6%蒸馏后提升到了 91.2%而教师的准确率是 98.3%。虽然没有完全追上教师但考虑到参数量差了 140 倍91.2% 已经是我能接受的结果。4. 训练时最容易踩的坑与排查方法4.1 蒸馏半天没提升先查这四个指标蒸馏后效果不佳是最常见的挫败来源。我自己的经验遇到“学生成绩怎么还不如直接微调”的情况先按顺序排查检查一教师软标签的质量。如果教师模型本身准确率只有 80%软标签信息就是“带噪”的学生学得再好上限也不高。所以首先保证教师模型在目标任务上的表现足够好。如果教师能力不足可以换更大的基座、做全参微调或者加一层高质量精标数据把教师先抬起来。检查二学生容量是不是太小。200M 的学生和 0.5B 的学生学习上限完全不同。如果任务偏复杂硬要压到 200M那不是蒸馏能解决的问题。判断方法很直接把学生模型换成教师同规模的模型做一次小规模蒸馏如果效果明显提升说明是学生容量瓶颈建议放宽模型规模需求。检查三温度 T 和 alpha 是否合理。T 太高学生学到过于平滑的分布不够聚焦T 太低又退化成硬标签。alpha 也是我之前做过 alpha1.0 的实验纯蒸馏不学硬标签结果测试集反而掉分。多用几个 T 和 alpha 的组合做小规模消融实验比盲目训练效率高得多。检查四数据分布是否过于单一。如果一个类别的样本在蒸馏集里占 90%学生模型会直接把这个类别的概率拉高完全失去细粒度判断能力。建议每个类别的样本尽量均衡至少不能有某一类占比超过 70%。4.2 损失发散或极不平滑学习率、温度与梯度裁剪训练中 loss 突然变成 NaN或者出现剧烈震荡先别怀疑代码有问题大多离不开这几个原因学习率过大。0.5B 模型用 5e-5 起步是安全的但如果你换成 1e-4 甚至更高很容易在训练初期就发散。学生模型从随机初始化到一个稳定状态需要一个平稳过程。建议先用 1e-5 跑几百步看到 loss 平滑下降再调回 5e-5。蒸馏乘子没加。忘了乘 (T^2)在 T 设得比较大的时候梯度就会过小训练 loss 停留在高位降不下去。这个问题很难一眼发现所以我自己在蒸馏损失函数里把T ** 2写在最显眼的位置并加了注释。KL 散度数值不稳定。如果教师的 logits 里有极端值softmax 后可能出现近似 0 的概率KL 计算时出现 log(0) 报错。我的做法是在teacher_probs上加一个极小项teacher_probs torch.clamp(teacher_probs, min1e-8)既避免 NaN也不影响整体方向。batch size 太小导致梯度噪声大。蒸馏损失比常规 CE 对噪声更敏感batch size 低于 8 时loss 曲线会非常抖动。保险起见 batch size 保持 16 以上配合梯度累积达到等效 32~64。顺便提一句梯度裁剪clip_grad_norm_(max_norm1.0)几乎是必备的。蒸馏训练早期KL 梯度偶尔会冒出很大的尖峰不裁剪的话一个 step 就能把权重打飞模型直接废了。4.3 软标签本身的偏见问题这是一个容易被忽视、但实际影响很大的点。教师模型虽然是“强者”但它也有自己的偏见。比如在情感分类任务里如果部署数据偏向某一类表达风格比如很多口语化的负面评价教师的软标签可能对“中性”和“负面”区分得不够学生学完也会继承这个问题。我在实践里通常这样规避人工抽检 200 条软标签看教师预测错误的样本集中在哪些类型上。如果有明显的系统性错误比如某个类别被整体判偏我会把这部分数据的软标签人工修正或者从训练集里剔除。有时候甚至可以把这部分样本的硬标签权重放大让硬标签在总损失里占更高比例用真实标签把教师的偏见纠正回来。软标签是“大概率正确的经验”但它不是“绝对真理”。尤其在学生容量比教师小很多的情况下错误经验会被快速放大所以训练前做好软标签质量审计非常值得投入时间。4.4 部署阶段的小优化蒸馏训练完成不等于项目结束。学生模型在端侧部署时我还会做两件小事第一导出成 ONNX 或者 GGUF 格式。HuggingFace 的 PyTorch 模型直接上生产环境太重了用torch.onnx.export或llama.cpp的转换脚本把模型压成 GGUF单项速度能快 3~5 倍。我在 CPU 服务器上实测ONNX Runtime 的延迟比 PyTorch 直接推理低不少。第二做一次 INT8 量化。学生模型已经很小再做量化损失也不大。0.5B 的模型 fp16 大约 1GBINT8 大约 0.5GB如果目标是 1GB 以内内存部署这一步几乎是必做项。量化后准确率一般只掉 0.2~0.5 个百分点完全可接受。我一个很深的体会是蒸馏模型不是训完就结束了部署链路里“压缩-导出-量化”这三步做好了最终效果才能从“实验室不错”变成“生产环境可用”。说实话知识蒸馏不是一个炫技型技术它没有太多复杂公式也没有特别酷炫的网络结构改进。它的价值在于把“大模型的能力”从一个昂贵容器里倒进一个便宜容器里而且这个倒腾过程是可复用、稳定、有理论支撑的。我自己做下来最深的体会是蒸馏的效果七分在数据与教师质量三分在训练技巧。教师模型强、软标签分布贴实际场景、学生容量选得合理这三点做好了哪怕损失函数只用最简单的 KL 散度结果都不会差。反过来如果教师羸弱、数据分布歪斜再精巧的蒸馏方法也救不回来。回到最开始的问题大模型怎么落地到端侧、本地、低配环境知识蒸馏给了一个非常务实的答案。每次训练完看到一个几十 MB 或几百 MB 的小模型却能复现出大家伙七八成功力的时候那种满足感确实是做模型压缩的人才能懂的。
