1. 大模型知识蒸馏到底在解决什么问题我最早接触知识蒸馏这个概念还是Hinton在2015年那篇Distilling the Knowledge in a Neural Network。当时的思路很朴素大模型学到的知识能不能通过软标签迁移给一个小模型让小模型在部署时既有接近大模型的效果又不会因为参数量太大而跑不动。这套teacher-student的思路在BERT时代已经被验证过很多次像DistilBERT、TinyBERT、MiniLM都是经典案例。到了大模型时代知识蒸馏这件事变得更加重要但玩法已经完全变了。过去蒸馏的是模型参数和表征能力现在蒸馏的对象变成了推理能力、指令跟随能力、甚至是对齐人类偏好的能力。与此同时大模型的推理成本高得离谱——一个70B的模型部署在线上光是显存占用和每token的延迟就是一笔很实在的成本。这也是为什么我在工作中经常被问到类似“16G显存能不能本地部署千问模型”这类问题本质上大家关心的都是同一件事有没有办法在效果损失可控的前提下把模型规模降下来。这篇文章我想聊聊我对大模型知识蒸馏综述的解读。我会从蒸馏范式的分类出发结合一些论文里的关键方法讲清楚白盒蒸馏、黑盒蒸馏各自的原理和适用场景再补充一些我在实际项目中踩过的坑和判断标准。如果你正在做大模型落地、模型压缩、或者本地化部署这篇内容应该能给你一个相对完整的参考框架。1.1 从传统蒸馏到大模型蒸馏的演变逻辑传统蒸馏的核心机制可以概括为教师模型和学生模型共享同一个任务目标教师输出logits作为软标签学生模型在硬标签之外额外学习软标签里的分布信息。软标签的价值在于它包含了类别间的相似性信息比如“这张图是猫”和“这张图是狗”教师的输出可能给狗打了0.3的概率这个“0.3”就暗示了猫和狗在特征空间上的接近程度。学生学到了这层关系泛化能力自然比只学硬标签要好。到了大模型时代有两个根本性的变化。第一大模型的任务形式变成了开放式的文本生成而不是固定的分类任务logits空间巨大直接对齐logits在计算上和语义上都很难说通。第二教师模型的规模往往大到无法本地加载你根本拿不到logits很多时候只能通过API调用拿到的是生成的文本。这就催生出了两种迥异的蒸馏范式白盒蒸馏和黑盒蒸馏。我理解的白盒蒸馏是你能够访问教师模型的内部状态包括logits、隐藏层特征、注意力分布等。这种方式在技术上更“原教旨”但受限于模型的可访问性。黑盒蒸馏则纯粹以教师生成的文本为监督信号学生模型去模拟教师的行为。黑盒蒸馏是目前大模型蒸馏的主流形态因为绝大多数时候你只有OpenAI或者国产大模型API的调用权限你看到的只是一段返回文本。1.2 大模型时代的蒸馏为什么值得重新审视大模型蒸馏的意义远不止省显存这么简单。我给你举几个我实际遇到过的场景。第一个场景是私有化部署。很多企业内部不允许调用外部API数据安全红线卡得很死但业务侧又确实需要大模型的推理能力。这时候只能本地部署而本地部署的硬件条件通常不太宽裕。蒸馏一个7B甚至3B的专用小模型效果可能比直接部署一个32B通用模型更贴合业务因为蒸馏出来的模型是“偏科”的它只擅长教师擅长、你也需要的那些能力。第二个场景是推理延迟。我做过一个实时客服项目线上要求首token延迟必须控制在200毫秒以内。拿一个70B模型做推理量化都压不住延迟。最后我们的方案就是离线用大模型蒸馏一个6B模型出来专精客服问答延迟和效果都达标了。第三个场景是成本。API调用成本随着调用量增长是非常夸张的。如果流量集中在某些高频场景蒸馏一个专用小模型部署在自建机房边际成本几乎可以忽略不计。所以知识蒸馏从来不是一个纯粹的学术概念它直接关系到模型能否落地、能否规模化。理解了这一点再看论文里那些方法就会有完全不一样的代入感。2. 白盒蒸馏当你能拿到教师内部状态时白盒蒸馏在综述里的定义是学生模型在训练过程中可以访问教师模型的内部表示包括logits、隐藏状态、甚至注意力图。这种范式在BERT时代是主流但在大模型时代由于模型体积和架构差异直接套用传统方法会遇到很具体的难题。2.1 logits蒸馏中的容量差距和分布不匹配logits蒸馏本身不复杂就是把教师的输出分布作为训练信号让学生去拟合。但在大模型场景下第一个坑就是容量差距capacity gap教师是70B学生只有7B能力差着一个数量级。早期研究比如Hinton那套做法直接搬到LLM上很快就发现一个现象——小模型在学大模型时会因为“学不动”而产生困惑最终效果甚至不如只用真实标签做SFT。为什么会这样核心原因在于分布不匹配。大模型的输出分布非常尖锐很多token的概率集中在极少数候选上小模型的容量不足以表达这么复杂的信息分布。用学术一点的话说前向KL散度会让学生模型去覆盖教师分布的所有模式但如果教师分布里有大量低概率噪声区域学生会被这些噪声带偏。解决这个问题的关键论文之一是我印象比较深刻的MiniLLM它提出用反向KL散度替换前向KL散度。这个替换听起来只是数学形式上的小改动内在逻辑完全不同。反向KL是让学生分布尽量落在教师分布的高概率区域规避低概率区域的干扰。类比一下前向KL像是让学生把老师讲的所有内容都记下来哪怕老师说的废话也要记住反向KL则是让学生去模仿老师讲得最自信、最核心的部分。对于容量有限的学生来说抓重点比全部覆盖要合理得多。还有一篇值得提的是GKDGeneralized Knowledge Distillation它把蒸馏和策略梯度统一到了一个框架里。GKD的核心想法很直接传统序列生成的蒸馏是逐token独立计算KL散度但这忽略了序列生成本身是自回归的——一个token的错误会连锁影响后续token。GKD让教师与学生共享一部分推理路径配合on-policy的数据生成方式这样学生学到的不是教师在固定参考答案上的输出而是教师对“学生自己生成内容”的反馈训练分布和推理分布更一致。如果你要做白盒蒸馏我建议优先搞清楚的几个点是你选的学生模型结构和教师差异大不大。如果词表不一致logits对齐会很麻烦通常需要先做embedding映射。KL散度方向的选择是有讲究的前向KL适合教师学生能力差距小的情况反向KL更适合差距大的场景。温度参数决定了软标签的平滑程度温度太高会把噪声放大太低又退化成了硬标签一般从2到4之间调。2.2 隐藏状态蒸馏与特征对齐的取舍除了logits白盒蒸馏还可以对齐教师和学生的隐藏状态。这个思路在BERT时代就有比如TinyBERT就是同时对齐embedding层、中间层和输出层。到了LLM时代隐藏状态蒸馏面临的计算开销问题更大因为LLM的层数动辄几十层逐层对齐的训练成本非常可观。实际项目中我很少看到有人对大模型逐层做特征对齐。原因有两方面一是计算代价太高二是收益不明显。LLM的中间层表征本身就高度抽象硬生生让一个小模型去对齐大模型的中间表征反而可能限制学生的表达能力。如果你确实要做隐藏状态蒸馏我的建议是只对齐最后几层不要从第一层就开始对齐。前几层的表征任务相对基础学生靠自己也能学好强行对齐只会增加优化难度。综述里也提到部分工作还会选择每隔几层做一次对齐而不是逐层做本质上就是在对齐成本和收益之间找平衡。白盒蒸馏还有一个变体值得一提就是对注意力图的对齐。这个方法在小模型上有一定效果因为注意力分布往往携带了token之间的依赖关系信息。但在我的实践中这种收益通常只有在任务非常单一、数据量非常大的时候才能体现出来通用场景下性价比不高。3. 黑盒蒸馏大多数大模型蒸馏的真实形态黑盒蒸馏是大模型时代最接地气、也是工程上最常用的一种范式。它的设定非常符合现实约束你只有教师模型的API访问权限能拿到的只有模型生成的文本。学生模型需要从这些文本中学习教师的“行为”。3.1 指令蒸馏从Alpaca到Evol-Instruct黑盒蒸馏里最有影响力的工作之一就是Alpaca。它做的事极简单用OpenAI的API生成52K条指令数据然后用这些数据去微调LLaMA-7B。没有复杂的蒸馏损失函数没有隐藏状态对齐就是纯SFT。它的意义在于证明了“API生成的文本”这一监督信号本身就足够强大可以让学生模型学会指令跟随。但Alpaca有一个明显的局限数据多样性不足。它的种子指令只有175条由人类编写虽然质量不错但覆盖的任务类型有限。后来的WizardLM提出了Evol-Instruct方法用LLM自己来“进化”指令——把简单指令一步步改写成更复杂、更多样化的指令。比如把“写一段自我介绍”进化成“写一段面向AI领域招聘官的技术型自我介绍要求体现你的项目经验和模型选型思路”。Evol-Instruct给我的启发是黑盒蒸馏的核心竞争力其实在数据而不在模型训练方法。同样的教师API你用一堆低质量文本去蒸馏模型再强也白搭但如果你能构造出高质量、覆盖面广的指令数据哪怕是相同的SFT流程蒸馏效果可能要好上一大截。另一个代表性的工作是Self-Instruct它提出了一种自举式的指令生成方案先用少量种子指令让教师生成新指令再经过筛选加入指令池不断迭代扩充。这种方式可以让蒸馏数据的规模做得很大同时保持一定的多样性。不过从我的实操经验来看Self-Instruct生成的数据噪声比例明显高于人工筛选的数据需要在后续数据清洗上多花功夫。3.2 思维链蒸馏让推理能力真正迁移指令蒸馏解决的是“听话”的问题但如果你的业务需要模型具备推理能力光靠指令跟随数据是不够的。这就是思维链Chain-of-Thought, CoT蒸馏发挥作用的地方。CoT蒸馏的想法很直接教师模型在做推理题时除了给出最终答案还会给出详细的推理步骤。这些推理步骤就是极好的教学材料。学生模型学会了生成这些推理过程自然也就学会了教师的部分推理能力。综合综述里的讨论我比较认可的做法是Teachers在生成CoT数据时会同时采样多条推理路径再通过最终答案的正确性筛选出高质量的推理轨迹最后让学生模仿这些筛选后的轨迹。这种做法的本质是把教师的推理能力当作一个“黑盒采样器”学生不只是学单一答案而是学习“如何一步步推理得到答案”这件事。有一个容易踩的坑必须提醒不要盲目追求CoT数据的数量。我发现如果教师生成的推理过程有错误即使最终答案是对的学生学到这个错误推理后模型在遇到类似问题时也会复现这个错误。所以CoT数据的质量筛选比指令数据更重要宁可少一点也不要脏。3.3 利用反馈信号做蒸馏超越简单模仿黑盒蒸馏的进阶形态是不满足于让模型仅仅模仿教师的输出文本而是让模型理解“什么样的输出更好”。这里的关键是引入偏好反馈。如果有多个模型对同一问题的回答你可以让教师模型对这些回答进行排序然后把排序信息作为监督信号。学生模型在训练时不仅学习优势回答的内容还要学会区分回答质量的高下。从技术上讲这种做法的训练目标和RLHF基于人类反馈的强化学习有一定的相似性区别在于反馈由教师模型代替人类给出成本更低、规模可以做得更大。我在实际项目中体会这种带反馈的蒸馏方式尤其适合对话类和内容生成类场景。赶上一个电商客服项目我用了教师模型对历史回答做质量打分然后用打分信息训练一个偏好模型再配合奖励信号做蒸馏最终学生模型在用户满意度指标上比纯SFT高出不少。这其实就是综述里提到的“distillation beyond imitation”的工程化落地。4. 蒸馏数据的工程化数据质量问题即上游问题我在这个领域的实操体会是很多人把大模型蒸馏当成一个模型训练问题但真正拉开差距的往往是数据工程。一样是黑盒蒸馏有人蒸馏出来的模型效果跟教师差不了太多有人蒸馏出来的模型满嘴胡话差就差在数据管线上。4.1 种子数据的质量与扩增比例做指令蒸馏时种子数据集的选择至关重要。如果你准备用Self-Instruct或者Evol-Instruct这类方法扩增数据我建议先盘一盘种子数据的三个维度任务覆盖度、标注质量、指令复杂度。任务覆盖度决定学生模型的泛化边界。种子指令只覆盖了50种任务蒸馏出来的模型大概率也只能在50种任务附近的分布上表现良好。标注质量直接决定教学信号的上限种子数据里如果混入了错误指令扩增的时候错误会被成比例放大。指令复杂度则影响数据的训练效率如果种子指令全部是“帮我写一首诗”这种简单任务模型学会的能力边际会很有限。扩增比例方面我个人的经验是1:10到1:50之间比较安全。扩增倍数太小数据多样性不足扩增倍数太大教师生成数据的噪声会迅速累积蒸馏效果反而变差。做大模型蒸馏数据质量曲线往往是先升后降的不要一味堆量。4.2 去重、清洗与质量筛选我在一次蒸馏任务中生成过20万条数据做了基础清洗之后剩12万再做一次语义去重之后只留了5万多条。有意思的是用这5万多条数据训练出的模型在评测集上的表现反而优于用全部20万条训练的版本。原因其实不复杂。大模型生成的文本天然带有重复模式同一个知识点换个问法可能生成了上百条高度相似的数据模型反复看这些相似样本过拟合风险很高。另外教师模型在生成时经常会出现“自我更正后又错了”的情况这类带噪声的数据如果不洗掉学生学了等于没学。我的清洗pipeline一般是这样的顺序先做基础过滤去掉空文本、超短文本、明显截断的样本这类问题在批量生成时极其常见。再做语义去重用embedding算一下相似度相似度超过阈值的只保留一条。最后做质量打分可以借助一个通用评分prompt让教师模型的API来打分或者直接用人工抽检。质量分偏低的样本直接丢弃。有条件的话对关键业务场景的数据做人工复核这部分数据质量要求最高不放心就多花人力。4.3 数据配比与课程学习还有一个容易被忽略的细节数据集的配比。业务场景中通常有多个子任务比如客服场景有意图识别、有知识问答、有情绪安抚、有多轮对话管理不同子任务的数据难度差异很大。如果混在一起训练模型的学习节奏会被简单数据带偏难任务学得不够好。我后来采用的做法是参考课程学习curriculum learning的思路先让模型学简单任务建立基础能力再逐渐引入复杂推理任务和多轮对话数据。训练过程分段进行每段配比不同效果比一次性混合所有数据要好。5. 蒸馏之后评估、部署与进一步压缩蒸馏完模型不是终点它还需要经过严谨的评估才能上线评估结果也会直接影响部署方案和后续优化方向。5.1 蒸馏模型的评估维度学术上对大模型蒸馏效果的评估通常分两大类一类是任务特定的评估比如在MMLU、GSM8K、HumanEval等基准上对比教师、学生与其他基线模型的分数另一类是通用能力的评估考察模型在开放域对话、指令跟随、安全性等方面的表现。在工程落地时我建议在上述之外再增加两个评估维度一是分布外泛化能力就是拿一些蒸馏数据里几乎没有覆盖的任务样本去测试看模型能不能顶住二是长尾场景的鲁棒性比如客服场景里的方言、错别字、口语化表达这类输入往往在标准评测集里很难看到。特别注意一点蒸馏后模型的评测分数和教师模型比通常会有一定下降这是正常的。关键是区分“合理的下降”和“能力崩塌”。如果教师能回答的问题学生大面积回答不了说明蒸馏数据覆盖度不够如果学生的回答风格偏离教师风格比如该简洁的回答变成长篇大论说明蒸馏训练不够充分。这两种问题需要不同的处理路径。5.2 蒸馏、量化、剪枝的取舍蒸馏出来的模型还有进一步压缩的空间常见的手法是量化和剪枝。量化是把FP16的权重转成INT8甚至INT4换取显存和推理速度的提升。剪枝则是删除模型中不重要的神经元或层。从收益上看蒸馏和量化是能叠加的。比如你蒸馏出一个7B模型再配合4bit量化部署在推理速度和显存占用上非常可观。但有一点需要注意蒸馏是训练阶段做的事情量化是推理阶段做的事情两者组合时务必在量化后重新做一次效果评估。我遇到过蒸馏后模型量化完效果崩掉的情况找了一圈原因发现是量化导致的激活值异常最终通过混合精度方案才解决问题。剪枝在大模型上的应用相对少一些因为LLM的结构冗余度没有小模型那么高剪完容易伤筋动骨。我的建议是优先蒸馏其次量化最后才考虑剪枝。这个优先级基本符合性价比排序。5.3 蒸馏模型部署的工程细节模型部署这个环节看起来只是把模型加载起来提供API服务但你实际跑一遍就会发现坑不少。第一显存预留。7B模型FP16加载大约需要14GB显存4bit量化后可以压到6GB以内但推理过程中的KV cache还会额外占显存。部署前务必根据并发量估算KV cache占用预留足够buffer否则线上运行一段时间后容易OOM。第二推理引擎的选择。我常用的方案是vLLM它对连续批处理做了深度优化吞吐量在高并发场景下优势明显。如果对显存占用更敏感也可以考虑llama.cpp的GGUF方案配合CPU或者小显存推理都很灵活。第三服务稳定性。模型服务上线前要做好压测重点关注首token延迟、token吞吐量、并发上限和错误率。如果出现长尾问题的模型回复时明显变慢要检查是不是prompt过长导致prefill时间过长这类问题需要从prompt长度控制入手。6. 实操心得与常见坑这部分我分享一些散装经验都是我在实际项目中一步步试出来的。6.1 什么时候该用知识蒸馏先说你最该做的判断你的项目适不适合做蒸馏如果你有一笔不小的API预算且业务流量不大直接用大模型API最省事别折腾蒸馏。蒸馏是一次性投入数据生成、清洗、训练、评估、部署整个链路跑下来的人力成本和时间成本都不低。但如果你有下面几个特征之一蒸馏就非常值得考虑业务流量大API调用费用已经成了显著成本项。数据敏感不能出内网必须本地部署模型。推理延迟要求高大模型在线推理顶不住。有专属业务领域通用大模型的泛化能力有些浪费需要专职的小模型。我见过不少团队眼红蒸馏的效果却忽略了自己的业务阶段结果折腾一个月蒸馏算下来还不如直接买API划算。工具没有好坏只有适不适合。6.2 常见坑与排查思路第一个坑学生模型容量太小蒸馏效果反而比SFT差。这种情况多见于拿3B模型去蒸馏70B教师。排查思路是先确认教师能力是否远超学生如果本身差距过大建议先换大一点的学生容量或者改用反向KL类的目标函数。第二个坑蒸馏数据噪声过高学生学到的是教师的口胡样本。排查思路是抽检训练数据看有多少比例是明显错误的输出。我一般会给自己定个红线数据错误率超过5%就直接推翻重做数据集。第三个坑训练时loss确实在降但评测效果没提升。这种情况往往是数据集和评测集分布不匹配。排查思路是看训练集中是否包含了评测集的任务类型如果没有单独补一批该任务的数据再微调。第四个坑训练效率极差卡在超长序列上。CoT蒸馏的数据通常很长训练时显存占用和耗时都会翻倍。常用的优化手段有梯度累积、序列长度截断、混合精度训练以及把长序列按比例混入保证模型接触长文本的同时不至于训练过慢。这些都是我在实践中反复踩过的。知识蒸馏不是一个“跑个脚本就行”的简单操作它更像一条完整的数据流水线加上一套精心调校的训练流程。你把它当成一个系统工程来做把数据质量放在第一位很多问题其实会自然消失。最后再分享一个我个人的判断不要说蒸馏模型注定比教师差这取决于你在什么维度上比。如果你把范围收窄到某个业务领域一个精心蒸馏出来的7B模型完全可以在该领域击败通用的70B模型。这也是我坚持认为蒸馏是大模型落地的核心工程手段之一的原因。