这两年但凡跟模型沾点边的团队，几乎都绕不开AI蒸馏这个技术名词。我最早接触知识蒸馏，是因为线上服务扛不住一个大模型的推理开销——参数规模一上来，单次请求的延迟和显存占用就让人头疼，但直接换小模型又明显掉点。折腾一圈下来发现，与其自己拍脑袋设计一个小网络然后硬着头皮从头训练，不如让已经训好的大模型当“老师”，把自己学到的知识一点一点“教”给那个轻量级的学生模型。这就是知识蒸馏（Knowledge Distillation）的基本逻辑。

这篇文章不打算把论文公式从头推导一遍，而是按我在真实项目里走完一遍的流程来讲：蒸馏到底把什么能力从大模型转移到了小模型身上，温度系数该给多少，损失函数怎么组合，以及那些常规文档里不会写的坑在哪儿。适合手里已经有一个训练好的大模型、想把能力压缩到小模型上线的算法工程师，也适合刚接触模型压缩、想建立整体认知的同学。看完全篇，你至少能自己搭出一个可运行的蒸馏训练流程，并且知道每一步为什么要这么做，而不是照着别人的参数抄一遍就完事。

1. 蒸馏技术到底在解决什么问题

1.1 大模型部署的现实困境

大模型的“大”体现在参数规模上。一个十亿参数级别的模型，单精度浮点参数占4字节，光权重文件就要4GB左右，推理时还需要额外的一块显存来存激活值。放到真实业务里，这意味着三件事：第一是单机并发上不去，算力成本直线飙升；第二是响应延迟变长，很多场景对端到端延迟有硬性要求；第三是模型体积太大，终端设备根本放不进去。

我见过不少团队，模型效果做得挺漂亮，到了部署评审环节却卡住。典型的情况是：模型精度到了98%以上，但线上要求单次推理在10毫秒内完成，显存预算还被压得很低。这种时候，大家的第一反应往往是先试量化或者剪枝，可这两个手段各自的瓶颈也很明显。量化本质上是降低权重和激活值的数值精度，对已经训练好的模型做压缩，它不改变参数量和网络结构；剪枝是把不重要的通道或连接去掉，但需要重新微调才能把精度拉回来。这两个方法能做到一定程度的瘦身，可一旦目标是把模型压缩到几十分之一的规模，光靠量化剪枝根本不够。

1.2 蒸馏、量化、剪枝的分工

知识蒸馏的思路和前面两个完全不同。它不直接压缩大模型本身，而是重新训练一个更小的学生模型，让学生去模仿教师的输出行为。换句话说，量化、剪枝是在“改造已有的模型”，蒸馏是在“重新造一个更小但更聪明的模型”。这两类手段并不冲突，实际项目里经常叠加使用：先用蒸馏把一个大模型压成一个小模型，再对这个小模型做量化，进一步压缩体积和加速推理。

三者对比一下会更直观：

从定位上讲，蒸馏解决的是“模型结构层面的能力压缩”，量化解决的是“数值表示层面的存储与计算优化”，剪枝解决的是“网络结构冗余的去除”。一个完整的落地链路通常是这样：蒸馏压规模，剪枝去冗余，量化再压缩一档，最后落到推理引擎上。这条链路里蒸馏是第一道工序，也是决定最终精度上限的那一步，因此它的质量直接影响后面所有环节的收益。

2. 核心原理拆解：教师模型到底在教什么

2.1 软标签里藏着的暗知识

很多人刚接触蒸馏，最大的困惑是：学生模型明明已经用了真实标签做监督，为什么还要多此一举去模仿教师模型的输出？答案藏在“软标签”和“硬标签”的信息量差异里。

分类任务里的硬标签是one-hot形式：一张猫的图片，标签就是“猫=1，其他=0”。但一个训练充分的教师模型在softmax之后，给出的往往是这样的概率分布：猫=0.85，狗=0.12，兔子=0.02，狐狸=0.01。这个分布看起来不如硬标签“干净”，却包含了比硬标签多得多的信息。教师模型不仅告诉学生“这是猫”，还告诉它“如果它不是猫，那么它最像狗，其次是兔子”。这种类别间的相似关系，就是知识蒸馏领域里常说的暗知识（dark knowledge）。硬标签把这些关系全部抹平了，只保留一个“正确答案”；而软标签把模型对类别相似性的理解编码在了概率差值里。学生模型学到的不只是分类边界，还有特征空间中的软结构，泛化能力自然不一样。

用生活化的方式理解：硬标签相当于把一张完整的地图浓缩成一句话“目的地在这片区域的中心”，而软标签则画出了路线和周围的参照物。后者给的信息不够简洁，但对一个初来乍到的学生来说，反而更容易找到目的地。

2.2 温度系数T的调节逻辑

要让软标签的信息充分发挥出来，得先解决一个实际问题：训练充分的教师模型，softmax之后的概率分布往往会非常尖锐——猫的概率接近1，其他类别接近0。这种接近one-hot的分布同样会把暗知识压没。解决办法是给softmax引入一个温度系数T，把logits先除以T再做softmax。

具体来说，对教师模型的logits向量z，蒸馏时使用的概率是softmax(z_i / T)。T等于1时就是普通的softmax；T大于1时，分布会被“抹平”，类别间的相对差异保留下来，但绝对值不再那么极端。T越大，分布越平坦，每个类别的概率越接近均匀分布；T越小，分布越尖锐，越接近one-hot。调T的过程，本质上是在“保留暗知识”和“避免熵太高导致噪声”之间找平衡。

这里有一个容易忽略的细节：温度系数不仅影响概率分布，还影响梯度的尺度。使用KL散度做蒸馏损失时，学生logits的梯度天然带着一个1/T²的缩放因子。如果不把蒸馏损失乘上T²，温度一高，梯度就会被压得很小，训练半天原地踏步。所以标准做法是计算完KL散度之后乘上T²再参与加权。这一行代码，很多初写的蒸馏脚本都容易漏掉，漏掉之后最典型的现象就是：蒸馏损失也在降，但验证集精度纹丝不动。

2.3 损失函数怎么组合才合理

蒸馏训练的目标函数通常由两部分组成：蒸馏损失加常规交叉熵损失。蒸馏损失用KL散度来做，衡量学生在温度T下的输出分布和教师的输出分布之间的距离；交叉熵损失用硬标签来做，保证学生不会偏离真实答案太远。两部分之间的比例由一个系数alpha控制，常见的经验值是0.7左右——七分向教师学分布，三分盯住真实标签。

为什么不能全信教师？因为教师模型本身也会有错判，完全放弃硬标签会让错误沿着分布被放大。为什么不能全用硬标签？那会退化成普通监督训练，学生永远不会知道“猫和狗更接近”这类信息。我自己在项目里试过几组alpha对照，0.7和0.5在最终精度上差距不夸张，但alpha接近1时，收敛速度会明显变慢，而且训练后期验证集上的波动更大。

另外值得提一句，实践中也有不少改用MSE来比较教师和学生logits的做法。MSE直接比较数值，训练更稳，但会平等对待所有类别，没法体现概率分布的形状差异；KL散度对分布更敏感，蒸馏效果通常更好，但需要处理好数值细节。我的经验是：分类任务优先用KL散度，回归或者特征匹配类的蒸馏用MSE更顺手。

3. 落地实操：从零搭一套蒸馏流程

3.1 教师模型的前置准备

第一步没有太多花活：选一个当前任务上效果最好的大模型当教师，冻结它的参数。教师的推理输出会作为学生的训练信号，所以教师的质量直接决定学生能达到的天花板。理论上教师越大越好，但越大推理越慢，所以实际项目中要考虑算力成本。

教师模型的softmax输出需要在每个训练step重新计算一次，这比较费算力。很多项目里的做法是先把教师对训练集的logits离线缓存下来，训练学生时直接读缓存，不再重复跑教师的forward。做缓存的时候有几个细节容易踩：一是要保证缓存时用的数据增强和实际训练学生用的完全一致，否则教师给出的是另一张图的分布，学生学了等于没学；二是建议存logits而不是存softmax之后的概率，因为logits可以在后续调温度T的时候重新计算，存了概率就把调T的灵活性丢掉了；三是数据量大的时候用npy或者hdf5分块存储，别一次性全塞进内存。

3.2 学生模型的结构设计

学生模型的选择，本质上是在“部署约束”和“学习能力”之间做权衡。一个常见误区是先挑一个看起来够轻量的网络，跑完发现精度不行，就回头怀疑蒸馏没用。其实蒸馏不是魔法，学生模型的参数上限决定了它的能力极限——一个只有几万参数的微型网络，再好的教师也教不出大模型的泛化能力。

我给项目选学生结构时，会比较两个维度：第一是推理延迟和内存是否满足业务指标，这个直接圈定候选结构范围；第二是在同等规模下，优先选表达能力和训练稳定性更好的结构。比如图像分类任务，从ResNet-50蒸馏到ResNet-18，往往能保留教师95%以上的精度；如果压缩到MobileNet这类为端侧设计的结构，就最好配合特征蒸馏这类更细的监督信号，光靠输出层蒸馏可能不太够。

3.3 训练配置与关键代码

核心训练逻辑其实很简洁。我用PyTorch写一个蒸馏训练流程，代码量不大，但每个参数都有讲究。

import torch import torch.nn as nn import torch.nn.functional as F import torch.optim as optim def distill_loss(student_logits, teacher_logits, labels, T=4.0, alpha=0.7): # 计算KL散度之前，把教师和学生的输出都用温度T软化 teacher_prob = F.softmax(teacher_logits / T, dim=1) student_log_prob = F.log_softmax(student_logits / T, dim=1) # 用T*T修正温度带来的梯度缩放 kd_loss = F.kl_div(student_log_prob, teacher_prob, reduction='batchmean') * T * T ce_loss = F.cross_entropy(student_logits, labels) return alpha * kd_loss + (1 - alpha) * ce_loss def train_student(teacher, student, train_loader, val_loader, epochs=30): teacher.eval() for p in teacher.parameters(): p.requires_grad = False optimizer = optim.Adam(student.parameters(), lr=1e-3) scheduler = optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=epochs) for epoch in range(epochs): student.train() running_loss = 0.0 for images, labels in train_loader: # 教师模型的logits可以提前缓存；这里是逐batch计算的写法 with torch.no_grad(): teacher_logits = teacher(images) student_logits = student(images) loss = distill_loss(student_logits, teacher_logits, labels, T=4.0, alpha=0.7) optimizer.zero_grad() loss.backward() optimizer.step() running_loss += loss.item() * images.size(0) scheduler.step() # 每个epoch结束后在验证集上评估一次 student.eval() correct = total = 0 with torch.no_grad(): for images, labels in val_loader: preds = student(images).argmax(dim=1) correct += (preds == labels).sum().item() total += labels.size(0) print(f"epoch {epoch+1}: acc = {correct / total:.4f}")

代码本身不复杂，但有几个点值得展开。一个是loss公式里的T*T乘回去，前面说过，这是必修项，漏了基本等于白训。另一个是KL散度的reduction参数，我用了batchmean，它按batch大小做平均，这样梯度尺度和batch size解耦，调大batch时不用重新调学习率。再有就是核心超参的初始取值：T从4.0起步，alpha设0.7，通常能在多数分类任务上跑出不错的结果。注意这两个参数的最优值其实和任务、数据分布、模型结构都相关，先用保守值把流程跑通，再做小范围搜索。

3.4 效果评估与验收标准

蒸馏训练结束后的评估，不能只看一个准确率。我自己的验收清单一般包含四项：学生模型在验证集上的精度以及和教师的差距；模型参数量与体积对比；端到端推理延迟和显存占用；最重要的——同一个结构从头训练的baseline精度对比。最后一项是判断蒸馏是否有效的核心：如果某个小模型直接用硬标签训练能拿到90%的准确率，蒸馏之后还是90%，那说明蒸馏流程没起作用或者参数没调对，得回头排查。

举一个我实际跑过的图像分类例子。教师模型是ResNet-50，验证集精度96.8%，参数量约25M；学生模型选ResNet-18，单独用硬标签从头训练精度是94.2%，参数量约11M；经过蒸馏训练后，同样的ResNet-18在验证集上做到了95.6%。精度差距从2.6个百分点缩到了1.2个点，参数量少了一半多，端到端推理时间也降低了四成以上。这个结果不算惊艳，但足够说明蒸馏的价值：结构变了、体积小了，精度没有等比例崩塌，还比同结构的普通训练高出1.4个点。

这里特别强调和baseline对比的习惯。很多团队做蒸馏喜欢报“学生比教师掉了多少点”，但这个数字信息量其实有限。真正该看的是“在完全相同的模型结构下，蒸馏训练相比普通监督训练多拿到了多少增益”。只有这个数字才能说明蒸馏这一套流程到底值不值得上。

4. 实操中踩过的坑与排查方案

4.1 温度T调不好，训练直接崩

温度T是蒸馏里最敏感的超参。我第一次跑蒸馏，把T设成10，alpha设成0.9，结果训练损失一路飘红，验证集精度惨不忍睹。后来才想明白原因：T太大时，教师模型的softmax输出变得非常平坦，每个类别的概率都差不多，KL散度几乎是在给噪声拟合；与此同时T²把梯度放大了100倍，优化过程直接不稳定。反过来，T太小会退化成硬标签训练——温度接近1时，教师输出和one-hot的区别微乎其微，学生学不到暗知识。

判断T是否合适有个经验方法：观察教师模型在温度T下的softmax输出里，次大概率的类别是否还有明显区分度。如果所有非目标类别的概率都掉到0.001以下，说明T给低了；如果最大的非目标类别只有0.02左右，同时目标类别也不突出，说明分布太散，知识被稀释了。正常从3到6的范围起步，先跑十来个epoch看验证集趋势再微调，别指望一步到位。

4.2 学生模型过小，学不动

把大模型的能力压进一个容量严重不足的小模型，是最容易踩的深坑。表面症状是：蒸馏训练loss在下降，验证集精度却一直上不去。很多团队这时候会开始怀疑T和alpha没调好，反复改参数，其实根源是学生模型的学习上限不够。容量小的模型，连拟合教师给出的软标签都吃力，更不用说从中提炼出可泛化的结构。

应对思路有三个方向。第一，在延迟和体积约束允许的前提下，优先加宽学生的通道数或隐藏层宽度，“宽而浅”的结构通常比“窄而深”更好学。第二，引入特征蒸馏，匹配教师和学生中间层的特征图，而不只是最后输出的分布，特征层面的监督信号更结构化，能帮助学生更快学到有判别力的表示。第三，采用两阶段蒸馏，先蒸馏到一个中等规模的模型，再把这个中等模型作为教师去教更小的模型，分步压缩比一步到位稳定得多。

4.3 数据增强不一致，教师瞎指挥

这是一个非常隐蔽的坑。教师模型通常是在一套固定数据增强策略下训练的，离线缓存的logits也是针对这套增强后的图片算的。如果学生模型训练时用了另一套更强的增强策略，或者改了图片尺寸、归一化参数，教师给出的软标签和学生的输入实际上不对应，蒸馏就变成了教师在学生看不到的输入上乱指挥。

更隐蔽的情况出现在线蒸馏场景。教师和学生拿同一个batch，教师那边的随机增强和学生那边的随机增强结果不同，同一次forward里两边看到的根本不是同一张图。我遇到过这种情况：蒸馏loss降得很低，但精度就是上不去，排查到最后发现是数据增强随机种子没对齐。解决方案并不复杂，保证教师和学生共用同一条数据预处理管线，离线缓存logits时严格对齐预处理流程，训练时只读缓存，不在线重复算教师forward，可以从根源上避开这个问题。

4.4 先蒸馏还是先微调

在实际业务里，蒸馏很少从零开始训一个学生模型，更多情况是把一个在大数据集上预训练过的模型蒸馏到目标领域的部署模型上。这个顺序问题看起来简单，翻车的人不少。

我的经验和踩坑结论是这样的：如果目标领域数据量充足，直接带着蒸馏损失做端到端训练就行；如果目标领域数据量较小，先在大规模通用数据上用蒸馏训练学生，再在目标领域上用带蒸馏损失的交叉熵做最后的微调，效果通常更稳。需要注意，微调阶段的alpha不能和蒸馏阶段完全一样。目标领域数据少，对教师的依赖反而应该降一点，把alpha调到0.4左右比较合理，否则教师在小数据上的偏见会被放大。微调轮次也不宜过多，我实测在两个epoch之后精度提升就开始放缓，继续微调反而会慢慢丢掉蒸馏阶段学到的通用特征。

5. 进阶玩法与个人心得

5.1 特征蒸馏：从学结论到学思考过程

输出层蒸馏是对“结论”的模仿，特征蒸馏则是对“思考过程”的模仿。思路很简单：在教师和学生的某一层中间特征之间加一个对齐损失，让学生的中间表示逼近教师的中间表示。这样做的优势在于，中间层的特征图往往携带了比输出分布更丰富、更结构化的语义信息，能从一个更根本的层面指导学生的学习。

实际操作时有几个细节。教师和学生网络的中间层维度往往不一致，需要先通过一个1乘1卷积或线性投影把学生的特征映射到和教师一样的维度，再做L2损失。特征层位置的选择也有讲究：太靠近输入的特征过于底层，蒸馏意义不大；太靠近输出的特征已经比较宏观，容易丢失中间结构；一般取网络中间偏后的某个特征层比较合适。和输出层蒸馏组合使用时，总损失变成三个部分：特征对齐损失、输出分布蒸馏损失、硬标签交叉熵损失。特征损失权重通常设得比较小，0.1左右起步，太大容易让学生特征学得太死，反而损害泛化。

5.2 自蒸馏：没有大教师怎么办

不是所有场景都有一个现成的大模型。有的团队手里只有一个小模型，却也希望享受蒸馏带来的泛化增益。这时候可以用自蒸馏的思路：让模型自己当自己的教师，用模型在某个训练阶段得到的预测结果去监督后续的迭代。

一个常见的实现是EMA教师。在训练学生模型的过程中，维护一个学生参数的滑动平均副本，用这个平均模型当教师。由于EMA模型相当于训练历史中多个参数状态的平均，它对单次batch的噪声不那么敏感，给出的软标签往往比当前时刻的模型更稳定。另一个更简单的做法来自重生网络的思路：先用普通监督训练得到第一代模型，再用它当教师去教一个相同结构的新模型。听起来有些循环论证，但在不少任务上确实能带来零点几个点的提升，尤其是在数据规模不大、普通训练容易过拟合的场景里。

5.3 工具链选择与个人建议

关于工具选型，我的观点是：前期不要迷信复杂框架，直接用深度学习框架原生的几行代码就能写出一个可用的蒸馏训练流程。PyTorch的KL散度接口、自动求导和分布式数据并行，足够支撑大部分蒸馏实验。等到确实需要大规模并行、需要系统化管理大量实验变体时，再考虑引入更重的训练框架，同时保留自己手里的基础版本做对照。能在框架之上跑明白原理，比一味堆工具重要得多。

做完两三个蒸馏项目之后，我对这项技术的认知有了两个明显变化。第一，蒸馏不是简单的“拷贝预测结果”，它本质上是一种正则化和特征学习的复合机制，这也是为什么它经常能让小模型超过自己普通训练的上限。第二，调蒸馏超参不能靠一次全量训练试错，成本太高。我的习惯是先在一个小规模的验证集上快速跑通流程，把T、alpha、特征损失权重这些参数的敏感性摸清楚，再上全量数据。想用好蒸馏，先学会控制实验成本，这比任何模型技巧都重要。

最后再分享一个小技巧。如果你准备在真实项目里用蒸馏，先别急着追求效果极致，用最小配置跑通全流程，然后逐个变量做对照。我第一次做蒸馏时直接上了全量数据，训练了三天，发现alpha设反了——0.7给了交叉熵，0.3给了蒸馏损失，等于认真训练了一个不带蒸馏的模型，全部白跑。后来养成习惯：任何新任务都先在小数据集上验证配置，确认损失形态和精度趋势符合预期，再放大执行。蒸馏的收益是实打实的，但前提是每一步都清楚自己在做什么，而不是把参数凑齐了就盲目开跑。