模型蒸馏不是万能钥匙：从原理到工程落地的避坑指南

模型蒸馏是最近几个月技术社区里讨论度突然变高的词，打开知乎、CSDN 和各类 AI 资讯平台，都能看到“蒸馏大模型”“蒸馏一个技能”“把知识库蒸馏成一本书”之类说法。这些说法听起来很美好：把庞大的模型压缩成一个小模型，还能保留大部分能力；把复杂的智能体流程提炼成一个轻量技能，推理成本大幅下降。但如果剥开这些流行说法，回到训练机制本身，会发现蒸馏并不是“免费午餐”，它本质上是信息迁移与信息损失的工程权衡，是一套需要精心设计超参数、验证指标和边界条件的方法。

这篇文章想给出的判断是：蒸馏被妖魔化了，一部分人把它当成“模型压缩的万能钥匙”，另一部分人又因为它某些失败案例而否定它的价值。这两种极端都不准确。真正重要的问题不是“要不要用蒸馏”，而是“在什么条件下用、怎么用、如何判断信息损失已经超过了收益”。

文章会从蒸馏的核心原理讲起，梳理 Hinton 那套经典知识蒸馏框架到底做了什么；再解释为什么社区里会出现“被妖魔化”的现象；随后重点分析过度蒸馏的代价，包括学生模型容量不足、误差逐级累积、OOD 泛化变差、置信度校准失效等问题；最后给出可落地的调参建议、验证指标和常见问题排查清单。无论你是做 NLP 模型压缩，还是在 Agent/Skill 场景里轻量化大模型能力，这篇文章都能帮你少踩几个坑。

1. 这篇文章真正要解决的问题

1.1 为什么蒸馏话题突然这么热

模型蒸馏最近热度上升，直接原因是模型本身的体量越来越大。一个几千亿参数的大模型跑在云端，单次推理成本高、响应延迟不可控，而业务侧希望用更小的模型完成同样的任务。这时“把大模型能力迁移到小模型”就成了一种天然诉求。尤其是多模态、Agent、RAG 等应用普及后，开发者发现真正制约产品体验的往往不是模型能力上限，而是推理成本和端侧部署限制。于是蒸馏从一个学术概念变成了工程需求。

另一个推动因素是工具链的成熟。Hugging Face 上有大量蒸馏脚本，PyTorch 写损失函数只需要几行代码，训练框架的分布式能力也越来越强。相比以前自己手写训练循环、手动处理数据，今天跑一次蒸馏实验的门槛低了很多。门槛降低的坏处是，很多开发者把蒸馏当成了“黑盒操作”：加载 teacher 模型，跑一批伪标签，然后扔给小模型训练，最后发现效果不好，却不知道问题出在数据、温度系数、权重配比还是学生容量上。

1.2 读者会踩到哪些坑

从实际项目反馈来看，最常见的坑有三个。

第一个坑是把蒸馏和普通微调混为一谈。有些人以为“蒸馏就是拿大模型的输出当硬标签去训练小模型”，但实际上知识蒸馏最核心的机制是学习“软标签”，也就是类别的概率分布。只学硬标签，相当于只抄作业答案，没学到老师解题时的判断过程，这是效果差异的根本来源。

第二个坑是忽视学生模型的容量上限。模型越大，表达能力不一定越强，但至少容量给了它记住更多模式的空间。如果学生模型只有几百万参数，却要学习一个几十亿参数教师模型所包含的完整知识分布，结果必然是信息瓶颈。很多蒸馏失败案例不是算法不行，而是配置不合理。

第三个坑是只关心蒸馏后的准确率，不关心分布变化。准确率一样，不代表行为一致。教师模型可能在某些低置信样本上给出“不确定”的信号，学生模型却在硬标签训练下输出过于自信的预测。这种置信度校准差异，在生产环境里可能带来远比指标下降更严重的风险。

1.3 读完这篇文章你能获得什么

本文会先讲清楚知识蒸馏的基础原理和关键公式，让你知道它到底在优化什么；然后用一个 PyTorch 最小实现演示如何写蒸馏损失函数和训练循环；接着重点分析过度蒸馏的代价，包括信息损耗、误差累积、泛化边界收缩等容易被忽视的问题；最后给出一个可复用的工程判断思路，包括温度系数和 alpha 权重怎么调、用什么指标验证、哪些场景不应该盲目使用蒸馏。

如果你正在做模型压缩相关项目，或者想把大模型能力沉淀到轻量级 Agent/Skill 模块中，这篇文章可以当作一份前置参考。

2. 蒸馏的核心概念与原理

2.1 知识蒸馏到底在蒸馏什么

知识蒸馏（Knowledge Distillation）这个概念，最广为接受的来源是 Hinton 等人在 2015 年发表的论文《Distilling the Knowledge in a Neural Network》。论文的核心洞察是：训练好的大模型，其输出不仅仅是“哪个类别概率最高”，还包含类别之间的相对关系。

举个例子，一个图像分类模型识别一张猫的照片，最终输出可能是“猫 0.7、狗 0.2、狐狸 0.1”。如果只取硬标签，我们只看到“猫”这个结果，丢失了“它有点像狗”这类信息。但对于一个小模型来说，“猫和狗相近、猫和卡车不相近”恰恰是很有价值的归纳偏置。大模型在训练过程中已经把这些关系编码进了概率分布里，蒸馏就是把这些关系“倒出来”给小学生模型喝。

这里有一个关键操作叫温度缩放（Temperature Scaling）。把 logits 除以温度系数 T 后再做 softmax，可以让概率分布变得更平滑或更尖锐。T 越大，分布越平滑，类别间的关系暴露得越充分；T 越小，分布越接近 one-hot，信息越少。蒸馏过程通常使用一个较大的 T 来生成软标签，同时把学生模型的 logits 也用同样的 T 缩放后再计算 KL 散度。

2.2 蒸馏与微调、量化、剪枝的关系

很多初学者会把模型压缩的几种方案混为一谈，这里先用一张表做区分：

蒸馏与微调的区别在于优化目标。微调的监督信号来自人工标注或任务标签，而蒸馏的监督信号来自教师模型的输出。蒸馏与量化、剪枝也不冲突，实际工程里经常组合使用：先用蒸馏把大模型能力迁移给中等规模模型，再用量化和剪枝压缩到端侧可部署的尺寸。

2.3 一个容易误解的点：蒸馏不是“复制模型”

有人会问，既然学生模型学的是教师模型的输出，那是不是模型越大越好？不是。蒸馏的核心理念是让一个容量较小的模型去逼近大模型的决策边界。如果学生模型容量已经接近甚至超过教师模型，蒸馏的收益就非常有限，反而增加了训练复杂度。

更准确地说，蒸馏是在“用更强的监督信号训练小模型”。学生模型没有能力记住所有知识，但它可以把有限的容量用在教师模型认为重要的方向上。这种“被引导的缩减”和“从头训练一个小模型”是完全不同的两条路。理解这一点，才能明白为什么有时候学生模型可以比从头训练的小模型效果更好，但也注定无法超过教师模型的上限（除非引入额外数据或辅助损失）。

3. 为什么“蒸馏被妖魔化”了

3.1 误解一：蒸馏就是把大模型的输出拿过来训练一遍

这个误解流传最广。很多人看到网上教程说“用 teacher 模型生成伪标签，拿去训练 student 模型”，就以为蒸馏是数据增强的一种。但真正的知识蒸馏，重点不是“数据变多了”，而是“标签变软了”。伪标签训练只是蒸馏的一个粗浅版本，等价于把教师模型的硬预测当作 ground truth，这丢失了分布信息，效果上限很低。

正确做法是要同时使用两类监督信号：一类来自教师模型的软标签，一类来自真实任务标签。软标签负责传递类别间关系，真实标签负责锚定正确答案。没有真实标签参与的蒸馏，很容易在小模型上放大教师模型的偏差。

3.2 误解二：蒸馏一定比从头训练小模型好

在某些场景下，蒸馏确实有效，但它不是银弹。如果任务本身很简单，数据量充足，从头训练一个小模型的效果可能不输给蒸馏模型，而且训练流程更可控。蒸馏的优势主要体现在两类场景：一是教师模型已经在大规模数据上见过更丰富的模式，小模型靠自己的有限数据学不到这些模式；二是教师模型的软标签天然带有一种“数据增强”效果，能让小模型更快收敛。

但如果数据分布已经足够覆盖业务需求，小模型容量也够用，引入蒸馏反而增加了训练链路和不确定性。判断要不要蒸馏，不能只看“压缩率”，要先验证“从零训练的小模型是否真的存在瓶颈”。

3.3 误解三：蒸馏没有代价，或者代价只在训练阶段

蒸馏确实需要额外的训练成本，因为要先用教师模型对所有训练数据做一次推理，生成并存储软标签。没有 GPU 集群的项目，这一步可能比训练学生模型本身还贵。

更隐蔽的代价发生在推理阶段。学生模型如果只学到了教师模型的“平均行为”，在某些关键决策边界上会表现得特别模糊。比如一个意图识别模型，教师模型对“查询天气”和“设置提醒”的区分很有把握，软标签中这两个类别的概率距离很大；但学生模型容量不够，可能在中间区域出现大量误判。这种损失不像准确率下降那么直观，但线上效果会明显劣化。

3.4 社区热词里的“蒸馏”到底指什么

最近在一些智能体和 Skill 社区里，“蒸馏”这个词已经被泛化了。“蒸馏一个技能”“蒸馏知识库成书”“女娲造人 skill 加什么就可以蒸馏自己”等说法，更多是在表达“把复杂信息提炼成简洁可用形式”的隐喻，而不是严格的模型蒸馏。

这对工程实践有正面意义，因为它说明了“大模型能力沉淀”是真实需求；但也有负面影响，它让很多人误以为蒸馏是一个“配置一下就能自动完成”的魔法操作。本质上，无论是模型蒸馏还是 Skill 蒸馏，都要先明确输入边界、输出格式、异常处理流程和验证集。否则，蒸馏出来的东西可能只是风格相似的空壳，并没有继承大模型的推理能力和知识边界。

4. 蒸馏的核心机制与最小实现

4.1 损失函数的构成

经典知识蒸馏的损失函数由两部分组成：硬标签交叉熵损失和软标签 KL 散度损失。公式可以写成：

L = alpha * CE(y_student, y_true) + (1 - alpha) * T^2 * KL(softmax(y_student / T), softmax(y_teacher / T))

其中：

• CE是学生模型预测与真实标签之间的交叉熵，保证学生模型不偏离正确答案。
• KL是学生模型和教师模型在相同温度 T 下的软概率分布差异，让学生模型学习教师的决策模式。
• alpha是两类损失的权重，通常取 0.7 到 0.9 之间。
• T^2是一个缩放系数，用于平衡温度缩放带来的梯度量级变化。

这里最容易忽略的是T^2缩放。如果不乘这个系数，温度升高会导致 KL 损失的梯度过小，训练时学生模型会偏向硬标签一侧，软标签的作用就被削弱了。

4.2 PyTorch 实现蒸馏损失函数

下面是一个可直接复用的蒸馏损失函数，保存为kd_loss.py：

import torch import torch.nn.functional as F def kd_loss(student_logits, teacher_logits, labels, temperature=4.0, alpha=0.7): soft_teacher = F.log_softmax(teacher_logits / temperature, dim=-1) soft_student = F.log_softmax(student_logits / temperature, dim=-1) kl = F.kl_div(soft_student, soft_teacher.exp(), reduction="batchmean") ce = F.cross_entropy(student_logits, labels) loss = alpha * ce + (1 - alpha) * temperature * temperature * kl return loss

核心逻辑有两点。第一，teacher_logits与student_logits都要先除以 temperature 再取 log_softmax，确保两者在同一个概率空间比较。第二，F.kl_div的第一个参数是学生模型的对数概率，第二个参数是教师模型的概率，顺序不能反。

4.3 一个完整的最小训练循环

下面代码展示如何在训练循环中调用上述损失函数。假设student_model和teacher_model已经完成初始化，train_loader返回(inputs, labels)：

import torch from kd_loss import kd_loss teacher_model.eval() student_model.train() optimizer = torch.optim.Adam(student_model.parameters(), lr=2e-5) temperature = 4.0 alpha = 0.7 for epoch in range(3): total_loss = 0.0 for batch in train_loader: inputs, labels = batch optimizer.zero_grad() with torch.no_grad(): teacher_logits = teacher_model(inputs) student_logits = student_model(inputs) loss = kd_loss(student_logits, teacher_logits, labels, temperature=temperature, alpha=alpha) loss.backward() optimizer.step() total_loss += loss.item() print(f"epoch {epoch} loss: {total_loss / len(train_loader):.4f}")

这种方式足够跑通一个最简单的蒸馏实验。如果要用于大规模生产，还需要加入梯度累积、分布式训练、模型保存与加载逻辑，这里的核心是在训练逻辑层面理解蒸馏和普通监督学习的区别。

4.4 配置化的蒸馏实验

蒸馏不是一个固定 recipe，温度、权重、学生结构都需要反复实验。建议把实验参数写进配置文件，方便对比和管理：

student: model_name: "bert-tiny" num_labels: 10 teacher: model_name: "bert-base-uncased" output_dir: "./outputs/teacher_logits" distill: temperature: 4.0 alpha: 0.7 batch_size: 32 epochs: 5 learning_rate: 2e-5 max_length: 128 evaluation: metrics: ["accuracy", "f1", "confidence_entropy"]

配置里的teacher.output_dir是软标签缓存目录，建议预先生成并保存教师模型的输出，避免每次实验重复推理。confidence_entropy是评估学生模型置信度分布的重要指标，后面会单独讲它的意义。

4.5 运行后如何验证

运行上面的训练脚本后，第一步是看训练 loss 是否稳定下降。如果 loss 不降，先检查温度 T 和 alpha 是否设置极端，再检查学习率是否合适。第二步是把学生模型和教师模型同时跑一遍同一批验证集，对比两者的准确率以及出错样本的重合度。如果学生模型在教师模型也犯错的样本上犯错，说明蒸馏是有效的；如果学生在教师模型正确的样本上大量犯错，就要检查是不是容量不足或软标签分布有问题。

5. 过度蒸馏的代价：信息损失到底发生在哪里

5.1 学生容量是显性的天花板

蒸馏最直接的代价是信息瓶颈。教师模型有几十亿参数，它的表达能力可以编码非常复杂的决策边界；学生模型只有几百万参数，它能表示的函数空间天然更小。蒸馏过程本质上是在“有损压缩”教师模型的知识，即使 KL 散度降得再低，学生也不可能完整复现教师的所有行为。

这也是为什么蒸馏要选择合适的 student 架构。一个过于小的模型在蒸馏后可能只学到粗糙的类别偏好，学到不类别间的微妙边界。这种情况下的表现是：验证集准确率看起来还可以，但细粒度子类、长尾样本、对抗样本上的表现明显下滑。换句话说，指标没有崩，系统的鲁棒性已经受损了。

5.2 多轮蒸馏会累积误差

有些团队为了让模型越来越小，会做“多轮蒸馏”：大模型蒸馏出中等模型，中等模型再蒸馏出小模型，甚至再蒸馏出一版超小模型。每一轮蒸馏都会引入新的信息损失，误差会沿着链路逐级放大。

这种做法的风险在于，学生模型的错误会被当成下一轮学生的“老师信号”。第一轮蒸馏时，教师模型在某个样本上概率分布是 0.8/0.2；第二轮时，中等模型可能输出 0.75/0.25；第三轮时，小模型可能已经变成 0.6/0.4。这个过程中，置信度被不断摊平，最终得到的小模型往往既没有大模型的准确率，也没有小模型的轻快，反而成了一个“平庸模型”。

更稳妥的做法是直接让目标规模的学生模型去学原始教师模型，或者只做“教师-学生”两代蒸馏。如果必须做多轮，每一轮都要记录教师和学生的预测差异，确保信息损失在可控范围内。

5.3 过度平滑导致置信度校准失效

软标签的优点是平滑，过度平滑则会带来置信度问题。温度 T 设置过高时，教师模型的概率分布会被拉得过于平坦，比如“猫 0.3、狗 0.3、狐狸 0.2、鸟 0.2”。这个分布传递的类别关系已经很微弱，学生在这些信息上不断学习，最后输出的概率也高度不确定。

在生产系统中，置信度不只影响展示，还影响决策阈值和风险控制。如果学生模型对所有样本都输出“低置信度”，系统可能频繁进入人工兜底流程；如果输出“高置信度”但实际错误，则可能造成更严重的线上事故。建议在验证阶段定期计算学生模型输出概率分布的熵，并在监控看板中对比教师模型和学生模型的熵差异，设定告警阈值。

5.4 教师偏差的放大效应

教师模型不是完美的，它本身也有误判和偏好。如果教师模型在某个类别上系统性犯错，学生模型在蒸馏过程中会把这些错误当作“知识”学习。更麻烦的是，小模型容量有限，它会优先记住教师模型中置信度高的行为，而置信度高不等于正确率高。这会导致教师模型在自信状态下的错误模式被进一步放大。

缓解手段有两种。第一种是使用真实标签对蒸馏损失进行约束，让 alpha 保持在一个合理范围，防止学生模型完全被教师带偏。第二种是在训练前先评估教师模型在目标数据集上的表现，如果某个类别的准确率明显偏低，可以降低这部分样本的蒸馏权重，或补充针对性标注数据。

5.5 对分布外样本的泛化能力可能变得更差

蒸馏模型在分布内数据上往往表现不错，但在分布外（OOD）数据上可能比从头训练的模型更脆弱。原因是学生模型学到的是一种“被筛选过的行为”——它只学到了教师模型在训练数据分布上的输出模式，却没有学到教师模型处理 OOD 输入时的那种鲁棒性。教师模型在大规模预训练中积累了广泛的世界知识，当输入偏离训练分布时，它可能仍能给出合理的低置信度预测；学生模型没有这个知识储备，就更可能在 OOD 输入上给出自信但错误的结果。

如果你要部署蒸馏模型，必须建立专门的 OOD 验证集。这个验证集可以来自线上真实流量、对抗性改写、同义句替换等。不要只看标准测试集的表现，就贸然上线。

5.6 蒸馏后的持续学习与二次适配

蒸馏完成后，学生模型并不是一个“稳定终点”。业务会继续变化，新意图会出现，新数据会积累，这时候往往需要继续微调学生模型。但蒸馏模型在持续学习场景下更容易发生灾难性遗忘，原因是它在容量有限的情况下把绝大多数参数都用于拟合教师模型的分布，没有太多冗余表达空间去容纳新知识。

如果提前知道后续还要持续微调，建议不要一次性把学生模型压到最小容量，而是在压缩率和可扩展性之间留出余量。或者在蒸馏时就加入旧任务回放数据，或者使用弹性权重巩固（EWC）一类的方法，给关键参数加正则约束。

6. 什么场景适合蒸馏，什么场景不应该用

6.1 更适合蒸馏的场景

第一类是推理延迟和资源约束极其严格的场景，比如移动端模型、边缘设备模型、实时在线服务。大模型跑不起，小模型能力又不够，蒸馏是相对成熟且可控的压缩方案。

第二类是教师模型已经在海量数据上预训练过，拥有学生模型无法通过自身数据获取的隐性知识。比如通用语言模型蒸馏到特定领域小模型时，教师模型带来的不仅仅是任务标签，还有丰富的语义关系。

第三类是 Agent/Skill 场景中需要对能力边界做固化。当你有大量 prompt 和大模型调用日志，希望把高频且稳定的能力沉淀成低延迟技能模块时，可以用类似蒸馏的思路训练专用小模型，但前提是输入输出边界要定义得非常清晰，验证要充分。

6.2 不应该盲目蒸馏的场景

如果任务非常简单，数据量已经足够训练一个小型专用模型，蒸馏反而是多余的。此时从零训练一个针对性模型更简单，也更容易调试。

如果教师模型本身在目标任务上表现不出色，蒸馏也帮不上忙。先用标准测试集评估教师模型，如果它的准确率就没有明显优势，蒸馏出来的学生模型只会更平庸。

如果学生容量已经被压到极限，还要强行蒸馏，结果可能既损失性能又增加链路复杂度。这种情况下，更值得考虑的是先做结构化剪枝或量化，而不是蒸馏。

6.3 一个简单的决策流程

可以按下面顺序判断项目是否适合引入蒸馏：

1. 先训练或选取一个尽可能强的教师模型，记录它在验证集上的效果。
2. 从零训练一个目标规模的学生模型，记录它的效果。
3. 检查两者之间的差距。如果差距很小，说明任务本身对大模型依赖不大，不需要蒸馏。
4. 如果差距大，运行一个最小蒸馏实验，比较三种方案：从零训练、直接硬标签伪标签训练、标准软标签蒸馏训练。
5. 用准确率、F1、置信度熵、OOD 验证集表现四个维度综合判断。

7. 蒸馏调参与实验设计

7.1 温度 T 和权重 alpha 的作用

温度 T 控制软标签的平滑程度。T 接近 1 时，软标签接近硬标签；T 越大，分布越平滑，类间关系暴露越多，但噪声也被放大。实际调参中，T 的取值范围常见于 2 到 10 之间，具体最优值与任务难度和数据规模相关。没有一个万能固定值，需要实验确定。

alpha 控制真实标签和教师信号的相对重要性，是一个 0 到 1 之间的权重。alpha 越接近 1，越接近普通监督训练；越接近 0，越接近纯模仿教师。实践中常用 0.7 作为起点，但如果教师模型本身不够可靠，可以适当调高 alpha。

7.2 推荐先运行一个参数矩阵

与其凭感觉调参，不如在实验初期跑一个小型参数矩阵。通过网格搜索把 T 和 alpha 的不同组合的训练结果记录下来，用验证集指标排序。即使不完全做全网格，至少覆盖三组代表性配置：

• 低温度配置：T=2，alpha=0.9，这组更接近硬标签训练，适合教师模型可靠性一般的场景。
• 中温度配置：T=4，alpha=0.7，这组是大多数任务的起点。
• 高温度配置：T=8，alpha=0.5，这组适合教师模型非常强、且学生模型容量相对充足的场景。

每个配置下，除了记录最终指标，还要记录训练过程中的 KL 损失收敛值。KL 损失收敛过快不一定好，可能说明软标签信息很快被学生学会，也可能说明温度设置太低、软标签太接近硬标签，没有发挥蒸馏的作用。

7.3 蒸馏实验的观测指标

只记录准确率是不够的，建议在实验模板中加入以下指标：

如果学生模型在 teacher-student agreement 上表现很差，即使准确率达标，也要警惕它的决策逻辑与业务预期不一致。

7.4 数据与计算资源准备

蒸馏训练需要教师模型对训练数据进行一次推理。数据量越大，软标签文件越大。建议提前将教师模型的 logits 保存为内存映射格式，避免训练时重复加载和计算。如果使用的是闭源模型接口，还要考虑调用成本、数据出域和使用条款问题。用私有大模型的输出去训练业务小模型，需要先确认相关授权和数据安全要求，不能默认“大模型输出就是无主数据”。

8. 工程实践与验证清单

8.1 写清楚学生模型的适用边界

蒸馏模型的部署文档必须写明边界，这是工程中容易被忽略的部分。它训练时覆盖的是什么数据分布，温度系数选了多少，教师模型是谁，哪些场景没有验证过。这些信息不是给别人看的，是给未来接手项目的工程师看的。否则半年后新同学突然在未覆盖的数据集上发现效果大幅下跌，往往要花大量时间才能定位到“蒸馏模型的适用边界本来就窄”这个原因。

8.2 建立回归测试集

蒸馏模型上线前，一定要准备一个回归测试集，里面至少包含三类样本：正常业务样本、易混淆样本、分布外样本。正常业务样本保证基本效果不退化；易混淆样本用于验证学生模型是否继承了教师模型对相似类别的区分能力；分布外样本用于观察系统在异常输入下的行为。回归测试集要随着业务迭代持续补充，每次模型更新都要重新跑一遍。

8.3 监控线上置信度分布

蒸馏模型上线后，重点观察两个信号：预测结果的置信度分布是否和离线一致，以及用户反馈/业务指标是否出现异常。如果线上置信度突然大面积升高或降低，先检查输入数据分布是否发生变化，再看模型本身是否被误更新。置信度分布漂移是一个前置告警信号，往往比业务指标受损更早暴露问题。

8.4 有关安全和权限的通用提醒

如果蒸馏过程涉及用户数据、敏感内容或私有模型参数，需要遵循最小权限原则：只收集完成任务所必须的数据，只授权必要人员访问训练数据与软标签文件；涉及生产环境模型替换时，先在灰度环境验证，再逐步扩大流量，同时保持回滚能力。蒸馏并不是一项可以跳过安全审查的技术操作，它涉及数据流动、模型复制和外部依赖，边界要比普通微调更复杂。

9. 常见问题与排查思路

需要特别说明的是，上面表格里没有“万能解决方案”。每个项目的数据分布和业务目标不同，最有效的做法是建立可复现的对比实验体系，把“蒸馏效果是否合格”的判断建立在一组明确的指标和回归用例上，而不是依赖某一次实验的感受。

如果让我给出一个最实际的建议，那就是：当你准备做蒸馏时，先跑一个从零训练的小模型作为基线，再跑一个硬标签伪标签训练版本，最后跑真正的软标签蒸馏。三组实验放在一起，大部分情况下你会很清楚地看到蒸馏到底值不值得做，以及该在哪个环节加大投入。这套实验矩阵的成本并不高，但它能避免你在错误的方案上反复横跳。