边缘设备部署为何偏爱蒸馏模型

我最早接触模型蒸馏，是出于一个很朴素的需求：手里那块开发板跑不动我想用的模型。

那会儿我试过直接把大模型往边缘设备上塞，结果要么内存爆掉，要么推理慢到让人怀疑人生。后来有人跟我说，你干嘛不蒸馏一个小的？我当时的第一反应是：蒸馏？是把大模型压缩一下吗？

不是。这个误解我踩了很久，这里先把它讲清楚，因为理解错了，后面全歪。

蒸馏不是压缩，是“请教”

蒸馏里有两个角色：教师模型和学生模型。教师大、训练充分、表现好；学生小、结构可能完全不一样、推理便宜。

关键点在于，它们之间没有参数上的继承关系。学生不是把老师切掉一块，也不是把老师的文件压小。老师的作用只是被“请教”——对同一批输入，老师输出什么，学生就学着输出什么。

打个我自己的比方：这就像学写文章。我不会去背老师的脑神经连接，我大量读他写过的段落，慢慢体会他用词、断句、结构的偏好。老师写得好，我就有更好的模仿对象；老师写得一般，我也很难学到更高水平。

软标签才是真正值钱的东西

蒸馏里我最喜欢的一个概念叫软标签。

假设任务是判断一张图是猫还是狗。普通训练数据给的是硬标签：这是猫，那是狗，非此即彼。学生只知道对错。

但老师给出的是一个概率分布，比如猫 0.9、狗 0.08、狐狸 0.02。这个分布除了告诉学生答案是猫，还偷偷透露了更多：这张图在老师看来有点像狗，有一点点像狐狸，但绝不像汽车。

“不像什么”这件事，在硬标签里是完全丢掉的。软标签把老师对类别之间相似性的判断传给了学生，学生学到的不是一个个孤立的答案，而是一张“谁离谁更近”的关系图。信息密度高得多，小模型那点容量才抓得住重点。

为什么边缘设备就是偏爱它

说白了，核心动机是部署成本。大模型能力强，但对算力、内存、能耗的要求高，手机、摄像头、车载设备、工业传感器这类边缘环境根本放不下。小模型参数少、推理快，能在本地算完，数据不用传到云端，延迟低，隐私风险也小。

还有两个我实际用下来很爽的点。一是专注：如果老师本身就在某个垂直领域训练过，学生就能集中学这个领域的判断方式，不用背通用大模型那一身包袱。二是迭代节奏：先用大模型探效果上限，再蒸馏出能落地的小模型，从研究到产品这条路顺得多。

别指望它是缩小版复制品

这点必须泼盆冷水。蒸馏出来的小模型继承的是老师输出里体现的行为模式，不是老师内部全部的知识。老师在行的任务上，学生通常接近；老师本身就不行、或者训练数据没覆盖到的地方，学生也没法凭空补上。

能力损失多少，真不是一句“掉几个百分点”能概括的。它取决于老师多强、学生容量多大、任务多复杂、数据够不够。任务需要长链条推理或者大量世界知识时，小模型的短板会明显暴露。学生容量太小，甚至会出现“教了但装不下”的尴尬。

还有个容易忽略的点：学生很难超越老师。模仿的上限就是老师给的信号质量。老师在某些样本上判断错了，学生可能照单全收。实践中会用真实标签、数据筛选之类的办法缓解，但模仿这个基本方向不变。

该用和不该用的分界线

我现在的判断标准很简单：任务边界清晰、对延迟成本隐私或离线有硬要求、老师在这个任务上已经靠谱——那就上蒸馏。移动端图像分类、语音唤醒、文本审核初筛、工业质检里的缺陷识别，都挺合适，这些任务不需要通用对话能力，只要在特定输入上稳定给判断。

反过来，如果任务本身要最高精度，或者需要广泛的开放域推理，那就别硬蒸，直接用大模型或者换别的加速手段更省心。蒸馏也不是免费的，你得先有个训练好的老师，还得搭一套额外的训练流程，最后还得认真评估学生到底能不能用。

想清楚这条分工线：老师负责探能力上限，学生负责把其中一部分能力带到真实设备上。搞明白这点，你就知道它为什么会在边缘部署里长期占一席之地，也知道它的边界到底在哪。