去年我做了一个工业质检方向的项目，模型在验证集上的表现相当不错，准确率做到了98%以上，团队里大家都很满意。结果到了部署阶段，问题全来了。客户的产线用的是普通工控机，CPU计算，没有独立显卡，推理延迟要求压在200毫秒以内。当时那个模型单张图片就要跑1.5秒，模型文件超过300MB，压根塞不进那台设备。那段时间我试了量化、试了剪枝，精度都有明显损失，折腾了快两周都没找到合适的方案。最后让我跳出困局的，就是模型蒸馏——用一个结构大幅缩减的学生模型去学大模型的知识，体积直接缩到原来的十分之一，推理延迟降到了100毫秒内，精度只掉了不到1个百分点。那次之后，我对蒸馏这门技术的看法完全变了：它不是一个锦上添花的优化手段，而是很多真实业务里"能不能落地"的关键。
1.1 手握一个大模型却上不了线，是一种什么体验
那段时间我就天天对着那个300MB的模型发呆，训练的时候有多爽，部署的时候就有多痛。模型的参数量大，意味着特征提取能力强，但也意味着计算量大、内存占用高，在边缘设备上根本跑步起来。身边不少做算法的朋友也有类似的经历：实验室里各种刷榜的模型，一谈到上线就偃旗息鼓。要么裁剪后精度崩了，要么量化后行为异常，要么换了轻量网络重新训练，怎么调都追不回来。其实，这个问题的本质不在于模型选型，而在于我们缺少一种"把已有知识高效迁移到小模型"的手段。
我后来复盘这个项目，发现当时的思考路径不太对。我们想着要去重新训练一个小模型，把它当成一个从零开始的新任务，却忽略了大模型的预测结果本身就携带了大量有用信息。一个训练好的大模型，面对一张图片，它输出的不仅仅是一个类别标签，还有各类别的概率分布。这个分布里包含着"这张图为什么像某个类别"的细腻信息，比如"虽然预测为A类，但也有20%的可能性是B类，因为它们有某个共同特征"。这种信息是标注数据远远表达不出来的，而模型蒸馏，恰好就是把这些信息榨出来，喂给那个小模型。
1.2 模型蒸馏到底解决的是哪一类问题
蒸馏不是单一技术，而是一整套知识迁移的方法论。它解决的，是模型能力上限和部署资源下限之间的错配问题。
举个直观的例子。一个在云端跑得好好的大模型，推理一次可能需要几百毫秒甚至几秒，这在离线场景没关系，但在实时交互系统里就是灾难。而小模型虽然跑得快、体积小，单靠原始数据从零训练，精度很难追平大模型，因为小模型的容量有限，自己摸索规律的能力天然偏弱。蒸馏的思路就是让小模型不直接去啃原始数据，而是跟着大模型的"思路"走，把大模型已经提炼好的知识拿过来，降低学习难度。
我在项目中实际感受到的是，蒸馏带来的收益是双重的。表面上是把小模型的精度抬上去了，本质上其实是让模型之间的知识可以跨结构复用。对于做工程的人来说，这意味着模型选型不必再被算力绑死；对于做算法的人来说，这意味着更小的模型也能承载足够强的能力，部署的灵活性大幅提高。这篇文章，我就从蒸馏的核心原理讲起，再结合我实际踩过的坑，完整拆解AI模型蒸馏在不同场景下的应用思路和实操细节，希望能给你提供一个可以直接参考的落地路径。
2. 蒸馏技术核心拆解：知识是凭什么"迁移"过去的
2.1 师生框架：教师教学生，但学生不是抄作业
模型蒸馏的基本结构是师生框架，也叫Teacher-Student结构。教师模型就是那个已经训练好的大模型，学生模型就是我们要获得的小模型。训练的时候，学生模型不只看真实标注，还要模仿教师模型的输出。
这里有一个很多人容易误会的点：学生模型不是在"抄"教师模型的答案。教师模型输出的类别标签，和学生模型自己预测的类别标签，可能是一样的，但如果只看最终标签，学生能学到的信息非常有限。蒸馏的精髓在于"暗知识"的传递，也就是教师模型在输出概率分布时暴露出来的那些细微差异。
举个例子，识别手写数字时，一个"2"的图片，教师模型可能会输出：数字2的概率是0.85，数字3的概率是0.10，数字7的概率是0.05。这个分布告诉我们，在教师模型看来，数字2和3长得有点像，数字2和7也有一定的相似之处。这种"相似关系"正是数据标注里不存在的信息。如果学生模型只看到硬标签"2"，它学会的就是"这图是2"；但如果它同时看到了那个软的分布，它就能知道"2跟3有某种形态上的关联"。当学生模型遇到没见过的新写法时，这种对相似性的理解，能帮它做出更接近人类直觉的判断。
在训练时，学生模型的损失函数一般由两部分组成：一部分是学生模型预测与真实硬标签之间的交叉熵，保证基础分类能力；另一部分是学生模型预测与教师模型软标签之间的差异度，通常用KL散度来衡量，目标是让分布尽量接近。这两个损失通过一个权重系数组合起来，系数配比往往就是调优的关键点之一，后面我会专门展开讲。
2.2 温度系数和软标签：蒸馏的精髓所在
讲蒸馏，绕不开温度系数这个概念。教师模型输出的原始概率分布，往往是尖锐的，也就是说最大值可能接近0.98，其余的都特别小，几乎趋于0。这种"过于自信"的分布给学生模型提供的有效信息太少，因为接近0的那些概率，在小数值下看不出差别。
解决办法是给softmax加一个温度参数T。在标准的softmax计算中，除以温度T之后再归一化，得到一个新的概率分布。当T大于1时，分布会变得平缓，各个类别的概率差异变小；当T等于1时，就是标准的softmax；当T小于1时，分布会更尖锐。
为什么平滑后的分布反而更有效？因为平缓分布能放大那些细微的相似信息，把这些关系更清楚地暴露给学生模型。如果说原始的尖锐分布是"答案"，那么加温后的软分布就是"答题思路"。在蒸馏过程中，通常取T大于1，但具体数值需要根据任务调整。我常用的做法是先取T=3做一组对比实验，再看效果往高或往低调，而不是一上来就固定一个值。
KL散度在这里就是衡量两个分布的差异。学生模型在蒸馏训练时，会不断调整自己的参数，让输出的分布逐渐靠近教师模型加温后的分布。直观理解，就是两个分布的重合度越高，学生学得越像老师。这个概念的实操意义在于：蒸馏本质上训练的是一个"分布逼近"问题，而不是一个简单的分类问题，所以对学生模型输出层的设计、激活函数的选择，都和普通训练有些区别。
2.3 三种蒸馏形式和实际取舍
蒸馏在工程落地中，主要演化了三种形式：离线蒸馏、在线蒸馏、自蒸馏。
离线蒸馏是最经典的做法，也是工业落地最常用的一种。先训练好一个大模型，固定住参数不动，然后让它给一批数据生成软标签，再用这些软标签去训练小模型。好处是流程清晰，训练成本可控，大模型只需要推理一次，软标签可以预先存成文件。缺点是教师模型和学生模型训练阶段分离，学生学到的是教师某一时刻的知识快照。
在线蒸馏则是教师模型和学生模型同时训练，或者用多个模型相互学习，好处是可以边训边更新知识，但工程复杂度高，稳定性也更难控制。在业务项目中，除非离线蒸馏效果实在不够，我一般不太建议一上来就做在线蒸馏，坑比较多。
自蒸馏就更特殊一些，它让模型自己教自己。典型做法是同一个模型在不同训练阶段互相学习，或者把模型的深层层知识蒸馏给浅层。这种方式的好处是不需要额外的教师模型，但收益往往不如异结构蒸馏那么明显。我的建议是，如果项目时间紧、目标只是"在不大幅改模型结构的前提下提高性能"，可以先试试自蒸馏；如果你的核心诉求是"压缩模型体积、加快推理速度"，那离线蒸馏的师生方案几乎是最稳妥的选择。
3. 模型蒸馏的四大典型应用场景
3.1 移动端与边缘设备部署：把大模型"装进口袋"
移动端和边缘设备是蒸馏应用最密集的领域。手机、智能摄像头、工业控制板、车载设备，这些场景的共同特征是计算资源有限、内存有限、功耗有限，但对模型能力的要求却越来越高。
我那个工业质检项目就是一个典型的边缘部署案例。产线摄像头拍下图片后，需要在本地完成瑕疵检测，不能依赖云端，因为产线网络不稳定，而且图片数据涉及客户的生产工艺，不方便上传。这种情况下，一个300MB的大模型根本跑不动，而蒸馏出来的50MB以下的小模型，既满足延迟要求，又能在本地完成推理，还保护了数据隐私，一举多得。
移动端场景中，蒸馏还有一个隐藏的好处：小模型的功耗控制。模型每做一次推理，都会消耗设备电量，推理次数一多，功耗差距就很明显。早些年我用过一个蒸馏出来的轻量级模型放在一个随身检测设备上，续航比原先跑大模型的方案多出一截。用户可能感知不到模型结构的变化，但"续航变长了"这件事，本身就是蒸馏带来的直接价值。
具体操作上，移动端蒸馏有几个注意点。第一，教师模型和学生模型的输入分辨率最好保持一致，避免因为预处理差异引入额外的精度损失。第二，蒸馏完成之后，仍然可以叠加量化、剪枝等压缩手段，因为蒸馏改变的是"模型内部的知识状态"，压缩改变的是"模型的计算方式"，两者并不冲突。第三，要重点验证小模型在目标设备上的实际推理速度，不能只看参数量减少了多少倍，因为有些结构在移动端上并不友好。
3.2 实时低延迟业务：推理速度就是用户体验
在线业务是蒸馏的另一个重要应用场景。广告点击率预估、个性化推荐、智能客服、实时语音识别，这类系统对推理延迟非常敏感。用户体验层面，推荐系统晚返回100毫秒，用户的点击意愿就会显著下降；智能客服多转半秒，用户可能就失去了耐心。
这类系统早期常用复杂的深度模型，效果虽好，但服务端压力大，单机吞吐量低。后来业界逐步采用蒸馏方案：白天用大模型做离线训练和数据标注，产出一批高质量的软标签，晚上批量执行蒸馏，把小模型训练好，白天上线服务。这样线上的推理由小模型承担，大模型的角色从"在线预测者"变成了"离线教师"。
我参与过某智能推荐项目的蒸馏改造，效果非常直观。原始的深度排序模型，单次推理大概需要12毫秒，在高并发下服务端CPU经常拉满。蒸馏后的模型延迟降到3毫秒，同样的机器配置可以支撑比原来多三倍的流量，而推荐效果指标几乎持平。最明显的变化就是后端扩容压力骤减，运维那边的告警也少了。值得注意的是，在线业务的数据分布变化较快，蒸馏出的学生模型往往需要跟上新数据的节奏。所以，这类场景要做"周期性蒸馏"甚至"增量蒸馏"，不能指望一个模型管一年。
增量蒸馏的做法也不复杂：每周或每月用最近的日志数据，让教师模型重新生成软标签，用微调的方式刷新学生模型。我建议把蒸馏训练流程完全自动化，做成一个定时任务，尽量减少人工介入，否则后期维护成本会高到让你怀疑人生。
3.3 数据敏感环境：蒸馏也能当"隐私缓冲带"
很多人没注意到，蒸馏在数据隐私保护方面其实有独特的价值。有些场景下，原始数据非常敏感，比如医疗影像、金融交易记录、生物特征数据，这些数据不能直接交给第三方处理，或者不能大规模集中保存。
这时候，蒸馏提供了一种思路：把大模型部署在数据持有方本地，数据不出域，只让大模型输出针对这些数据的软标签。外部团队拿到的是已经"蒸馏过"的知识，而不是原始数据，基于这些软标签训练小模型，仍然能获得接近大模型的能力。
这等价于在数据流通和知识利用之间加了一道缓冲。原始数据不会离开本地，但模型的知识可以。当然，必须说清楚，这种方案不能完全杜绝信息泄露风险，因为软标签仍然可能携带数据的某些特征，但相比直接传输原始数据，暴露面已经小了很多。如果你所在的项目有严格的数据合规要求，设计架构时可以考虑这种"本地教师加外部学生"的模式。
与此同时，知识蒸馏也被用在联邦学习的场景里。多个参与方各自拥有本地数据，不想共享原始数据，但希望共同训练出一个好模型。这种情况下，蒸馏可以辅助不同参与方交换"知识信号"而不是"数据内容"。具体做法是每个参与方在本地训练自己的模型，然后把预测分布发送给中心服务器，中心服务器利用这些分布信息进行聚合，再下发给各参与方继续训练。这样既保护了数据不出本地，也实现了类似联合训练的效果。
3.4 多任务整合与模型运维优化
很多系统里，不同业务共用一套基础模型，但也会各自挂载一些专用模型。模型一多，运维成本跟着涨，每次更新要部署多个模型，资源浪费也严重。蒸馏在这里可以承担一个"整合器"的角色：把多个专用大模型的知识，浓缩进一个统一的学生模型里。
比如某智能语音助手，早期有独立的唤醒词模型、指令识别模型、情感分析模型，三个模型分布在三个模块里。后来我们尝试用蒸馏的方式，让一个轻量级的多任务模型同时学这三个大模型的知识，训练时对每个任务分别计算蒸馏损失，再进行加权求和。最终一个学生模型同时承担了三个任务，整体性能比三个单独训练的轻量模型都要好，而且维护时只要部署一个模型，资源占用也降下来了。
这种多任务蒸馏的关键在于损失函数的权重配比。不同任务的难度不同，损失量级也不同，如果直接相加，量级大的任务会压过其他任务。我当时踩过的坑是没有对各个任务的损失做归一化，结果唤醒词任务学得很好，情感分析的精度却明显下滑。后来把每个任务的损失除以一个固定的缩放系数，让它们的初始量级大致相同，再把权重交给实验去调，整体效果才平衡下来。
从运维角度看，多任务蒸馏还带来一个额外的好处：模型版本管理变简单了。以前更新三个模型需要分别测试、灰度、回滚，现在只要管一个模型，发布流程少了一大半。业务侧提出新需求时，也只需要在教师侧增加一个对应的大模型或专项能力，重新蒸馏一次，学生模型就更新到位，开发和上线周期显著缩短。
4. 蒸馏实操全流程：从选型到上线的完整记录
4.1 第一步：选学生模型，别急着拍脑袋
很多人在蒸馏项目里犯的第一个错误，就是学生模型选得过于随意。有人直接拿了最轻量级的分类网络，有人干脆把大模型的层数砍一半，这些做法都不太对。学生模型的选择不应该基于"参数少"，而应该基于"任务适配、容量够用"。
我通常的建议是，先明确部署环境的约束条件，比如目标设备的算力、内存储器和允许的推理延迟，然后根据这些约束反推学生模型的结构。打个比方，如果目标设备是手机，那就优先选择移动端友好的算子结构；如果是服务端，可以用一些更常规的轻量网络。关键是不要盲目追求极端小体积，因为学生模型的容量一旦过低，即使教师教得再好，它也"装不下"那么多知识，最后还是以精度损失收场。
选好结构后，有一个容易被忽略的细节：学生模型的输入预处理要和教师模型保持一致。包括图像的缩放方式、归一化参数、序列模型中的词典大小等，这些如果不一致，教师生成的软标签和学生模型的输入对不上，蒸馏效果直接打折。
4.2 第二步：训练配置与损失函数设计
蒸馏训练的关键配置有三个：温度系数T、硬标签损失权重和软标签损失权重、训练数据的组成。
温度系数T上，我一般先取3跑一轮基线，然后做小范围搜索。我在实践中的经验是：图像分类任务里T在2到6之间比较合理；而某些结构化任务，比如推荐排序，T取小一点效果反而好，因为这类任务中类别间的细微差异不如视觉任务那么重要。
损失权重的比例也值得细调。常用的组合是把软标签损失权重设成0.7，硬标签损失设为0.3，很多任务在这个配比附近就能拿到不错的效果，但具体数字还要看任务的量级。如果有精力，可以画出一条"学生模型精度随权重变化"的曲线再决定，我就见过有任务在软标签权重为0.9时效果反而最好的情况。
训练数据的组成同样马虎不得。理想情况是先用无标签或弱标签数据让教师模型生成软标签，用这批数据做一轮预训练，再用真实标注数据做融合训练。教师模型对无标签数据的预测分布，往往比人工标注更丰富，能帮助学生模型学到更强的泛化能力。在工业项目里，我经常用线上日志中未标注的数据来做蒸馏，效果往往比只用标注数据好不少。
下面给一个简单但完整的蒸馏训练代码示意，使用PyTorch风格：
import torch import torch.nn as nn import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, labels, T=3.0, alpha=0.7): # 软标签损失: 学生与教师的分布差异 soft_loss = F.kl_div( F.log_softmax(student_logits / T, dim=1), F.softmax(teacher_logits / T, dim=1), reduction="batchmean" ) * (T * T) # 硬标签损失: 学生与真实标注的交叉熵 hard_loss = F.cross_entropy(student_logits, labels) return alpha * soft_loss + (1 - alpha) * hard_loss代码里乘上T的平方，是一个很容易被忽略的细节。因为软标签的梯度量级和T的平方成反比，如果不乘回来，温度系数一调大，梯度就变得特别小，训练效率会明显下降。这个坑我踩过一次，当时调高温度后模型几乎不更新，排查了半天才发现是这里的问题。
4.3 第三步：评估、调优与上线验证
蒸馏训练完成后，不能只看验证集准确率就直接上线。我认为完整的评估流程至少包含三个层面。
第一层是常规指标对比。把学生模型和教师模型在同样的验证集上分别测一遍，看精度差距是否在可接受范围内。第二层是行为分布对比。重点观察学生模型在不同数据切片上的表现是否存在偏差，比如某一类样本的召回率是否明显下降，这个在传统指标里看不太出来，但对业务影响却很大。第三层是性能压测。直接跑目标设备上的推理延迟、吞吐量、内存占用等数据，这些数据才是决定能不能上线的硬指标。
我在那个工业质检项目里，专门搭建了一个分发嵌入式的评测脚本，把模型丢进去后会自动跑完以上三层的指标，生成一份对比报告。后来养成了习惯：每次蒸馏调参后都跑一遍这个流程，而不是等到最后才一次性验证。这样即使过程中有环节出问题，定位起来也快得多。
上线之后也别忘了做真实流量的小流量实验。线上数据分布和离线数据集往往存在差异，小流量实验能及时暴露出学生模型在真实场景中的不适感。如果指标波动较大，回头检查是否数据分布漂移，或者需要继续补充蒸馏数据，甚至可以回到温度系数和损失权重上重新调整。
5. 踩坑实录：蒸馏项目里最常见的5个问题
5.1 蒸馏完精度反而大跌，问题出在哪
蒸馏效果不理想，不少人第一反应是"蒸馏没用"，但大多数时候是训练条件没设对。
最常见的原因是教师模型本身就不够强。蒸馏的底层逻辑是"学生学教师"，要是教师模型在困难样本上经常犯迷糊，那学生模型自然也学不到什么有价值的信息。做蒸馏之前，务必先确认教师模型在目标验证集上的表现是否满足要求，如果教师本身就一般，蒸馏很难帮你变出花来。
第二个常见原因是学生模型容量过低，实在装不下教师的知识。这种情况出现的典型表现是：蒸馏损失一直降不下去，学生模型的输出分布和教师差别很大。解决思路是适当增大学生模型的宽度，比如增加通道数或嵌入维度，而不是盲目加深网络。
还有一个容易被忽略的原因是蒸馏数据分布太单一。我碰到过一个项目，蒸馏数据全部来自同一时间段，结果学生模型对这段时间之外的数据泛化得很差。后来把训练数据改成多时段、多渠道的混合样本，效果才恢复正常。蒸馏数据最好覆盖教师模型可能遇到的各种真实分布，宁多勿少。
5.2 温度系数调来调去没感觉是怎么回事
温度系数是蒸馏里最玄学的参数之一。调了没感觉，通常不是参数的问题，而是别的地方没有配置对。
我建议在调温度之前，先确认三个条件。一是教师模型的软标签是否已经保存并正确加载；二是KL散度的缩放是否已经处理，也就是代码里T的平方有没有乘回去；三是学生模型是否已经收敛到一个合理的基线水平，如果学生模型的训练状态还很不稳定，温度变化的影响会被噪声淹没。
如果这些都没问题，那就可以正式调温度了。实用方法是用一组固定的学生模型结构和训练配置，对T的取值范围做网格搜索，比如取1、2、3、5、7等几个值，每个值跑相同的训练轮数，然后对比验证集指标。不要单独靠一两次实验就下结论，因为温度不同会导致训练过程略微不同，需要多次观察趋势。
另外，温度系数的选择在不同任务里差异很大。图像分类和语音识别对温度更敏感一些，而排序类任务往往用小温度效果更好。别拿其他项目的参数直接套用到你的场景里。
5.3 学生模型训练不稳定的处理
在蒸馏训练过程中，学生模型的loss曲线出现明显震荡、甚至不下降的情况，也不在少数。
我碰到的头号原因是学习率设置得太大。蒸馏训练和普通训练的loss曲线形态不太一样，软标签损失往往在训练初期就有较清晰的下降方向，但学习率过大容易过头。我通常会把学习率调到普通训练的十分之一到三分之一，然后观察loss曲线是否稳定下降。
另一种情况是教师模型和学生模型输出层的表达空间不一致，导致分布对齐非常困难。比如教师用了大词表，学生用小词表，或者教师和学生用了完全不同的激活函数。遇到这种情况，可以在学生模型的输出层后面加一个线性适配层，把学生的输出维度映射到和教师一致的空间，蒸馏完成后再把适配层丢掉。
如果训练数据量特别大，也可以考虑用分批的软标签缓存，而不是每次都重新计算教师模型的输出，否则训练速度会受到教师模型推理速度的拖累，浪费时间也影响调试节奏。
5.4 软标签和硬标签的配比怎么定
软标签权重和硬标签权重之间的比例，直接决定了学生模型是"更像教师"还是"更贴近真实标注"。这个问题没有一个通用答案，但有一套可复制的调法。
我的经验是，先用默认可行的配比跑通流程，比如软标签0.7、硬标签0.3，确认整体效果达标后，再做消融实验。消融的做法很简单：固定其他所有配置，分别尝试0.5/0.5、0.8/0.2、0.9/0.1等几组配比，观察验证集精度的变化。注意每次只改这一个变量，否则实验结果不具有可比性。
另外要留意，硬标签损失的权重不能太低。如果完全依赖软标签，学生模型会丢失真实标注中的约束信号，有可能在特定类别上出现偏差。我个人的经验是，保留至少0.1到0.3的硬标签权重，学生模型的稳定性会好很多。
5.5 离线蒸馏与在线蒸馏怎么选
这里给个直接参考：大多数工业场景优先选用离线蒸馏方案，原因有三个。
第一，离线蒸馏的流程可拆分、可追踪。大模型先生成软标签，这一步可以作为独立的中间产物保存，问题排查时很容易定位是哪一步出了问题。第二，训练成本可控。软标签可以预生成，训练学生模型时不需要反复调用教师模型，能省下大量计算资源。第三，部署简单。教师模型一旦固定，知识和学生模型互不干扰，不会因为在线联合训练中的波动影响最终产物。
在线蒸馏适合那些数据分布极度动态、或者教师模型本身也需要持续更新的场景。比如某些实时推荐场景中，用户兴趣变化很快，离线蒸馏可能跟不上节奏。但这时候要做好心理准备，要投入更多的调参精力和训练资源，不是一条轻松的路。
6. 实操心得与后续扩展思路
6.1 我对蒸馏的三个核心体会
做了这么多蒸馏项目，我觉得有三个体会比技术细节更重要。
第一个，蒸馏核心不在于"压缩"而在于"知识复用"。不要只盯着模型体积减小了多少倍，而要去关注小模型到底从大模型里学到了什么、学到了多少。如果学生模型的知识迁移到位了，哪怕体积没减小多少，它的精度提升和泛化能力变化都是实打实的收益。
第二个，别把蒸馏和其他压缩手段对立起来。蒸馏可以配合量化、剪枝、算子优化一起用。我在实际项目中经常是"先蒸馏再量化再剪枝"，每一步小幅压缩，累加起来的效果相当可观。很多团队谈压缩就只想到量化，等到量化效果不佳时才想起蒸馏，其实顺序反了，蒸馏应该尽量靠前，让模型先适应小体积的约束，再处理数值精度和结构稀疏性。
第三个，建立一套自动化的蒸馏评估流程比调任何参数都重要。蒸馏涉及多个可调因子和多个评估维度，如果每次手动改参数、手动跑评测，效率会非常低。把训练、评测、报告生成串成一条流水线，我后面适应新任务的时候，很多工作都是直接复用那套流程框架，很少从头再来。
6.2 接下来的扩展思路
蒸馏这个方向后续还有很多可以玩的点。一个比较有潜力的方向是跨模态蒸馏，比如让一个多模态大模型去教一个轻量级的单模态模型，实现在图片、文本、语音之间的知识迁移，这种能力在移动端的多模态交互上非常实用。
另一个方向是把蒸馏和自监督学习结合起来。利用大量无标签数据做自监督预训练，再用蒸馏的方式把教师模型的知识注入学生模型，可以减少对人工标注的依赖，对于数据标注成本高的行业来说，价值很明显。
还有个思路是在蒸馏中引入高效的架构搜索，自动搜索出的学生模型结构往往比手工设计的更贴合目标硬件的计算特性。虽然计算成本会高一些，但换来的推理性能提升通常很值得。
最后提醒一句，任何蒸馏方案都要结合你的真实业务场景来设计。别因为算法很酷就直接上，先问清楚你手头到底有什么数据、部署在哪里、性能瓶颈是延迟还是体积，把这些约束条件列出来，蒸馏方案自然就有了方向。
