无需微调的知识蒸馏:将前沿模型的能力提取到更廉价的推理路径中
一个拥有 7.7 亿参数的模型在它擅长的任务上击败了一个拥有 5400 亿参数的模型,这听起来似乎是不可能的。但这正是经过蒸馏的 T5 模型在对抗 few-shot PaLM 时所取得的成就——仅使用了 80% 的训练样本,模型尺寸缩小了 700 倍,且每次推理成本仅为几分之一美分,而不再是数美元。这其中的秘诀并非更好的架构或更巧妙的训练方案。而是利用大模型生成标注数据,并用这些数据来训练小模型。
这就是知识蒸馏(Knowledge Distillation)。而且,你并不需要通过微调教师模型来使其生效。
大多数工程师在需要一个既能保持特定任务表现又更便宜的模型时,首先会想到微调(Fine-tuning)。微调是一个显而易见的选择:选择一个能力强大的基座模型,在你的领域数据上更新其权重,然后发布。但微调需要两样很多团队都不具备的东西:(1) 大规模的高质量人工标注示例,以及 (2) 决定微调哪种基座模型——这会让你被锁定在该模型的尺寸、成本和能力上限中。蒸馏则绕过了这两个问题 。你利用前沿模型本身来生成训练数据,并在不触动教师模型(Teacher Model)权重的情况下,用这些数据训练一个更小的学生模型(Student Model)。
蒸馏的具体作用
核心思路很简单:在一组大规模输入上运行你昂贵的前沿模型(教师模型),收集其输出,然后训练一个更小的模型(学生模型),使其在你特定的任务分布上复制这种行为。
这与微调有本质的区别。微调是通过在新数据上进行梯度下降来更新现有模型的权重。而蒸馏则是利用教师模型的输出作为监督标签,从头开始(或从预训练检查点)训练一个独立的、更小的模型。你永远不需要通过教师模型进行反向传播,也永远不需要访问其内部细节。如果教师模型是闭源 API(如 GPT-4、Claude、Gemini),你仍然可以通过将 API 响应视为标注数据来进行蒸馏。
训练目标结合了两种信号:
- 任务损失 (Task loss):学生模型是否产生了正确的答案?
- 知识转移损失 (Knowledge transfer loss):学生模型的输出分布是否接近教师模型?
第二种信号正是神奇之处。你不是训练学生模型去简单地匹配正确答案,而是训练它去匹配教师模型在所有可能输出上的完整概率分布。这种软监督(Softer Supervision)为每个示例提供了更多信息,因为教师模型的分布编码了其不确定性以及关于哪些答案是合理的隐含知识。
在实践中,对于基于 API 的黑盒教师模型,你通常只能访问最终输出,而无法访问完整分布,因此你会回退到纯粹的任务损失 。这依然有效,但思维链提取(Chain-of-thought extraction)能极大地改善效果。
思维链提取:性能倍增器
在推理任务中,仅针对教师模型的原始答案训练学生模型效果平平。针对教师模型的推理轨迹(Reasoning traces)——即得出每个答案的完整思维链——进行训练,可以产生表现显著提升的学生模型,通常所需的示例数量会减少 3 到 5 倍。
具体流程:不要用“X 的答案是什么?”来提示你的教师模型,而是用“请一步步思考。X 的答案是什么?”来提示它。你收集完整的推理轨迹,而不仅仅是最终的结果。然后,你训练学生模型同时生成推理轨迹和最终答案。
这是因为推理任务涉及教师模型压缩在其输出概率分布中的隐式中间步骤。仅针对最终答案训练的学生模型必须从头开始重建这些步骤。而针对推理轨迹训练的学生模型则直接接收了教师模型的解题策略。
DeepSeek-R1 蒸馏系列在大规模应用中证实了这一点。通过使用来自其前沿推理模型的约 80 万个思维链样本,他们训练了一系列参数从 15 亿到 700 亿不等的小型学生模型。70B 的学生模型在数学、代码和科学基准测试中几乎达到了与教师模型持平的水平。32B 的学生模型取得的成绩甚至可以与尺寸是其三到四倍的模型相媲美。
对于构建生产系统的工程师来说,实际的启示是:如果你的任务涉及多步推理,千万不要跳过推理轨迹。收集原始答案并疑惑为什么蒸馏模型表现不佳,是一个常见且可以避免的错误。
合成数据流水线
生成训练数据是蒸馏过程中最昂贵且最容易出错的部分。流水线如下:
- 设计精细的教师模型提示词,以引导出高质量的输出,包括针对推理任务的思维链指令。
- 生成 10 万到 100 万个示例,通过在多样化且具有任务代表性的输入上运行教师 API。
- 基于质量进行过滤,使用针对你特定领域的自动化正确性标准。
- 训练学生模型,在过滤后的数据集上训练,使用简单的、经过成本优化的提示词。
- 在预留的基准测试集上验证,然后再进行部署。
过滤步骤的重要性超出了大多数团队的想象。研究一致表明,质量胜过数量:一个由 20 万个经过仔细验证的示例组成的数据集,其表现优于 100 万个未经过滤的示例。学生模型会学习训练数据中存在的任何模式——如果这些模式包含教师模型的错误、歧义或低置信度输出,学生模型也会忠实地学习这些。
数据生成中的两个常见错误:
- 多样性不足:如果你从同一狭窄的提示分布中生成所有训练示例,学生模型会过度拟合该分布,并在推理时输入略有不同时表现糟糕。
- 使用基于 LLM 的质量过滤器:通过要求另一个 LLM 对质量进行评分来过滤训练数据会引入该 LLM 的偏见。特定领域的正确性检查——如在真实数据库上运行生成的 SQL、针对单元测试检查代码、使用符号求解器验证数学——要可靠得多。
一个经常让工程师感到惊讶的发现是:在推理任务上,将训练 Token 从 2500 万扩展到 1.5 亿有时“几乎没有带来任何改进”。一旦你用高质量的示例覆盖了任务分布,增加更多低质量的示例就毫无帮助了。瓶颈从数据数量转向了数据质量。
决策框架:何时进行蒸馏,何时为大模型付费
只有在特定条件下,蒸馏才具有经济效益。如果判断错误,代价将非常高昂。
在以下情况下进行蒸馏:
- 在狭窄、重复的任务类别(路由、分类、结构化提取、简单问答)上,每月有超过 100,000 次 API 调用
- 你的任务分布稳定——你在生产环境中看到的输入与生成训练数据时的输入相似
- 你可以容忍 1-5% 的准确度损失,以换取 5-10 倍的成本降低
- 延迟至关重要:自托管的 7B 模型可以实现 API 调用无法达到的低于 100ms 的 P99 延迟
在以下情况下不要进行蒸馏:
- 每月 API 支出低于 5,000 美元(构建蒸馏流水线的工程成本超过了节省的费用)
- 你的用例不断推陈出新——用户提出的问题是教师模型未曾训练过的,或者包含对抗性输入以及快速演进的领域
- 必须保证最高的准确度(如医疗、法律、安全关键型应用)
- 你的任务分布是异构的且难以表征
当条件成熟时,经济效益非常显著。在狭窄的分类任务上,如果每月 有 1,000 万次 API 调用,使用 15 美元/百万 token 的尖端模型与 0.40 美元/百万 token 的自托管蒸馏模型相比,每年的成本差异约为 110 万美元。一个耗资 50,000 美元构建的蒸馏流水线大约在两周内就能收回成本。
当条件不成熟时,蒸馏就是一个陷阱。在训练分布上达到教师模型 97% 准确度的 7B 学生模型,在真实用户不可避免生成的分布外输入上,准确度可能仅为 60-80%。
OOD 问题:蒸馏无法解决的难题
蒸馏中最常被低估的失效模式是分布外(Out-Of-Distribution, OOD)降级。蒸馏模型学习的不是推理——它学习的是在训练分布上复制教师模型的行为。当测试输入超出该分布时,学生模型的性能会大幅下降,有时降幅甚至超过 20 个百分点。
这在生产环境中造成了一个危险的陷阱:蒸馏模型在你的评估基准(采样自与训练数据相同的分布)上表现出色,上线后立即遇到不符合这些模式的用户输入。
解决方法是在发布前进行明确的 OOD 评估。收集与训练数据刻意不同的示例——不同的表述方式、不同的领域、边缘案例、对抗性输入——并衡量准确度的下降程度。如果降幅超过了你的团队承受范围,那么蒸馏对于该任务来说就不是合适的工具。
对于注重 OOD 鲁棒性的任务,有三种方法比纯蒸馏效果更好:
- 混合路由:将简单的、分布内的查询路由到蒸馏模型,将其余查询路由到尖端模型。这可以在不牺牲 OOD 覆盖的情况下削减 40-60% 的 API 成本。
- 蒸馏到更大的学生模型:70B 的学生模型比 7B 的泛化能力强得多。虽然成本节省较少,但依然可观(对于最小的模型,分别为 18 倍对比 37 倍)。
- 结合蒸馏与微调:先从尖端模型进行蒸馏,然后使用特定领域的数据对生成的学生模型进行微调。蒸馏得到的基线比通用的预训练检查点能为微调模型提供更好的起点。
三个导致生产失败的误区
教师模型越大,学生模型越好。 这是错误的。教师模型的准确度随模型规模增加而提升,但学生模型的准确度并不会按比例提升。一个在特定领域表现出色的、经过任务对齐的 13B 教师模型,通常比通用的 540B 模型能培养出更好的学生模型。在投入数据生成预算之前,请先在你实际的任务分布上评估多个教师模型。
蒸馏会转移对齐。 教师模型的安全属性并不一定会可靠地转移到学生模型上。如果你的教师模型经过训练会拒绝某些请求或保持特定的语调,不要假设学生模型也会继承这些属性。请对学生模型进行明确的审计。
顺序级联会累积质量。 先从尖端模型训练一个大型学生模型,再从大型学生模型训练一个较小的学生模型,其效果不如直接从尖端模型训练小型学生模型。每个迁移步骤都会丢失信息。请直接进行蒸馏。
2025 年的新变化
最近有三个动态值得关注。
上下文内蒸馏 (In-context distillation):不训练新模型,而是将教师模型的能力蒸馏到上下文示例中——即精心设计的演示。当这些演示包含在提示词中时,能引导较小的基础模型产生接近教师模型的行为。无需训练。代价是每次推理调用都会产生这些演示带来的上下文长度成本,但对于没有机器学习基础设施的团队,这能以极小的工程开销解锁类似蒸馏的成本节约。
多教师框架:传统的针对单一教师的训练正逐渐被“委员会方法”取代,即由多个专业教师贡献训练信号,并根据学生模型在每个教师领域的表现进行加权。在异构任务套件上,多教师学生模型的表现优于单教师学生模型 3-5 个百分点。
推理模型蒸馏:从推理优化型教师(显式训练以产生长篇、逐步推理过程的模型)进行思维链(Chain-of-Thought)蒸馏,比从标准的指令遵循模型进行蒸馏更能有效地迁移推理能力。产生 DeepSeek-R1 蒸馏系列的 80 万条推理过程,如果来自标准的聊天模型而非推理模型,所培养出的学生模型表现会差得多。
专才的权衡
理解蒸馏的核心在于明确你在构建什么,以及你不在构建什么。你不是在构建一个通用模型。你是在训练一个专才,使其在你的特定工作负载上复制通才的行为。
当面对合适的问题——稳定、高吞吐量、窄任务分布——时,蒸馏是 AI 工程师工具箱中最具成本效益的工具之一。一个 770M 的模型在预定任务上以极低的成本击败 540B 的模型,这并非魔法。这是当你为一个小模型在完全正确的分布上提供完全正确的训练信号时会发生的结果。
当你需要真正的泛化能力——新颖的问题、快速演变的领域、对抗性用户——时,蒸馏会以可预测的方式失败。在构建流水线之前识别出你处于哪种情况,才是真正的工程工作。
- https://link.springer.com/article/10.1007/s10462-025-11423-3
- https://research.google/blog/distilling-step-by-step-outperforming-larger-language-models-with-less-training-data-and-smaller-model-sizes/
- https://arxiv.org/html/2410.18588v1
- https://yage.ai/share/llm-distillation-misconceptions-en-20260414.html
- https://arxiv.org/pdf/2601.18734
- https://arxiv.org/html/2603.25562v1
- https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/distillation-turning-smaller-models-into-high-performance-cost-effective-solutio/4355029
- https://galileo.ai/blog/knowledge-distillation-ai-models
- https://medium.com/@jsmith0475/a-detailed-technical-comparison-of-fine-tuning-and-distillation-in-large-language-models-cccbe629dcba
- https://arxiv.org/abs/2512.02543
- https://arxiv.org/pdf/2106.05945
- https://leanlm.ai/blog/llm-cost-optimization
- https://introl.com/blog/inference-unit-economics-true-cost-per-million-tokens-guide
