1. 从「蒸馏」这个词被点名说起一场关于模型能力来源的争论最近圈子里讨论度很高的一件事是几家中国大模型公司被公开点名说它们的模型存在「蒸馏」行为。消息一出评论区立刻分成两派一派觉得这是行业惯例没什么好大惊小怪另一派觉得这是「抄作业」拿别人的成果包装成自己的。作为一个长期在一线做模型训练和部署的人我看到这个新闻的第一反应不是站队而是想先把「蒸馏」这件事本身讲清楚——因为绝大多数争论其实都源于对蒸馏的理解偏差。先把结论放在前面蒸馏本身是一种正当且成熟的技术手段它不违法、不违规也不是什么见不得人的操作。真正值得讨论的是蒸馏的边界在哪里、用谁的输出做蒸馏、以及蒸馏出来的模型能不能真正解决业务问题。这三点才是这次事件的核心。我打算从技术原理、工程实践、商业逻辑三个层面把「蒸馏」这件事彻底拆开讲一遍。不管你是刚入门的大模型开发者还是正在选型的企业技术负责人看完之后应该能对「蒸馏」有一个不被人云亦云带偏的判断。文章会涉及 KL 散度、RL、ODP 这些关键词背后的实际含义也会给出可复现的蒸馏实操思路以及我在实际项目中踩过的坑。提示本文讨论的是公开的模型训练技术不涉及任何具体公司的商业机密或未公开信息所有技术细节均来自公开论文和我在实际项目中的工程经验。2. 蒸馏到底在蒸什么从 KL 散度到软标签的完整链路2.1 蒸馏的本质是「学老师的概率分布」不是「抄答案」很多人对蒸馏的理解停留在「把大模型的输出拿来训练小模型」这个说法对但太粗糙了。要真正理解蒸馏得先理解一个概念软标签soft label。假设你训练一个图像分类模型传统做法是给每张图一个硬标签比如「这是猫」。但一个训练充分的大模型它的输出往往是一个概率分布猫 0.85、狗 0.10、狐狸 0.05。这个分布里藏着大量信息——它告诉你「这张图虽然主要是猫但和狐狸也有点像」。这种信息就是所谓的「暗知识dark knowledge」。蒸馏的核心就是让学生模型去拟合老师模型的这个概率分布而不是只拟合那个硬标签。衡量两个分布差异的指标就是KL 散度Kullback-Leibler Divergence。KL 散度越小说明学生模型的输出分布和老师越接近。用生活化的类比硬标签像是老师只告诉你「这道题选 C」而软标签像是老师告诉你「C 有 85% 把握B 有 10% 可能A 基本不可能」。后者显然包含了更多可学习的信息。2.2 温度系数蒸馏里最容易被忽略的关键参数在实际做蒸馏时有一个参数几乎决定了成败那就是温度系数 T。老师模型的输出 logits 经过 softmax 时会除以温度 Tp_i exp(z_i / T) / sum_j exp(z_j / T)当 T1 时就是标准的 softmax当 T1 时分布会变得更「平滑」那些原本概率很低的类别也会获得一定的概率值暗知识就被放大了。我实测下来的经验是T 一般取 2 到 5 之间比较稳。T 太小暗知识提取不出来退化成硬标签训练T 太大分布过于平滑噪声也被放大学生模型学到的可能是老师的「犹豫」而不是「知识」。这里有个坑我踩过早期做蒸馏时我直接把 T 设成 10结果学生模型在小样本上表现极差因为老师模型在低概率区域的输出本身就是噪声放大之后反而干扰了学习。后来把 T 调到 3效果立刻正常了。2.3 蒸馏的三种典型形态logits 蒸馏、特征蒸馏、黑盒蒸馏蒸馏不是只有一种做法按学生能接触到老师的什么信息可以分成三类蒸馏类型学生能接触到的信息典型场景实现难度Logits 蒸馏老师的输出概率分布同架构缩小模型低特征蒸馏老师中间层的特征表示跨架构迁移中黑盒蒸馏只能拿到老师的输入输出对调用 API 场景高Logits 蒸馏是最经典的Hinton 那篇开山论文讲的就是这个。学生和老师共享同一套输出空间直接对齐概率分布即可。特征蒸馏要求学生去拟合老师中间层的特征比如 FitNets 那套思路。这个难度更高因为学生和老师的层数、维度往往对不上需要额外的映射层。黑盒蒸馏是这次事件里最敏感的一类。当学生拿不到老师的权重和 logits只能通过 API 调用拿到输入输出对时就只能用这些「问答对」来训练。这种做法在技术上完全可行但它的效果上限明显低于白盒蒸馏因为学生只能学到老师「说了什么」学不到老师「怎么想的」。注意黑盒蒸馏在数据获取环节最容易出问题。如果调用的是公开 API通常受服务条款约束如果是通过非正常手段批量获取那就不是技术问题而是合规问题了。这一点在做任何蒸馏项目前都必须先确认清楚。2.4 为什么 RL 和 ODP 会出现在蒸馏的讨论里热搜词里出现了 RL 和 ODP这两个词和蒸馏的关系值得单独说一下。RL强化学习在大模型训练里主要用于对齐阶段比如 RLHF。它和蒸馏的结合点在于可以用 RL 来优化蒸馏过程让老师模型生成更「适合教学」的样本而不是简单地输出原始分布。这种做法在近两年的论文里越来越常见。ODP在不同语境下含义不同在大模型蒸馏的讨论里它通常指的是一种在线蒸馏策略Online Distillation Pipeline即老师和学生同时训练、互相更新而不是先训好老师再训学生。这种做法的好处是学生能持续获得老师的「最新状态」但工程复杂度高很多对显存和调度的要求也更高。我在实际项目中用过离线蒸馏先固定老师再训学生也试过在线蒸馏。结论是如果老师模型已经足够强且稳定离线蒸馏性价比更高如果老师本身还在迭代在线蒸馏能避免学生学到过时的知识。3. 被点名「蒸馏」背后真正被偷走的是什么3.1 表面上是「能力」实质上是「数据分布和决策边界」回到标题里的问题他们到底偷走了什么从技术角度看蒸馏转移的不是某个具体的知识点而是老师模型在整个输入空间上的决策边界。一个训练好的大模型它的能力体现在它对各种输入的响应方式上——什么问题该怎么答、什么情况下该拒答、什么语境下该用什么语气。这些「行为模式」才是蒸馏真正在转移的东西。打个比方老师模型像是一个经验丰富的老医生学生模型像是一个刚毕业的医学生。蒸馏的过程就是让医学生观察老医生看诊——不是记住某一个病例的答案而是学习老医生的诊断思路和判断标准。所以如果一家公司用另一家公司的模型输出做蒸馏它「拿走」的是对方在海量数据上训练出来的决策边界。这个边界是对方投入了大量算力、数据和人力才形成的这就是为什么这件事会引发争议。3.2 蒸馏能转移什么不能转移什么这里必须说清楚一个技术事实蒸馏不是万能的它转移能力是有上限的。能转移的输出格式和风格常见问题的回答模式部分推理链路如果老师输出里包含推理过程特定领域的知识表达方式不能转移或很难转移的老师模型在训练中形成的底层表示能力对未见过的输入的泛化能力老师模型本身的「涌现能力」训练数据里隐含的长尾知识我做过一个对比实验用同一个老师模型蒸馏出两个学生模型一个用 10 万条数据一个用 100 万条数据。结果 100 万条的那个在常见任务上确实更好但在需要多步推理的复杂任务上两者的差距远小于数据量的差距。这说明蒸馏的天花板是由老师的能力上限决定的学生很难超过老师。3.3 为什么「蒸馏」在商业上是一个敏感词技术归技术商业归商业。蒸馏之所以敏感是因为它触及了一个核心问题模型能力的归属权。一家公司花了几千万甚至上亿训练出一个模型另一家公司用相对低的成本蒸馏出一个能力接近的模型这在商业上显然是不对等的。但问题在于蒸馏本身是公开技术模型输出是否受保护、在什么条件下可以使用这些在法律和行业规范上都还没有完全清晰的界定。我的判断是未来行业会逐渐形成一套关于「模型输出使用」的规范就像当年开源软件许可证一样会分化出不同的使用条款。但在规范明确之前做蒸馏项目的人需要自己把握好边界——用公开数据、用自己有权使用的模型输出、并且清楚标注模型的来源和局限。4. 如果你想自己动手做一次蒸馏完整实操路径4.1 环境准备别一上来就上大模型很多人一提到蒸馏就想着「我要蒸一个 70B 的模型」结果环境还没配好就卡住了。我的建议是先用小模型跑通全流程再考虑放大。一个最小可用的蒸馏环境大概需要一块显存 24G 以上的 GPU跑 1B 到 3B 级别的模型足够PyTorch 2.0 以上Transformers 库一个已经训练好的老师模型可以是开源模型一份任务相关的数据集如果你只是想验证蒸馏流程甚至可以用 CPU 跑一个几百 M 的小模型虽然慢但流程是一样的。4.2 数据准备蒸馏的数据质量比数量重要蒸馏用的数据核心要求是覆盖你关心的任务分布。我见过太多人随便找一堆通用语料就开始蒸结果学生模型在通用任务上还行一到具体业务场景就崩。我的做法是分三步确定任务边界先明确学生模型要解决什么问题是问答、分类、还是生成。构造种子数据每个任务类型准备 50 到 100 条高质量种子样本。用老师模型扩展把种子数据喂给老师模型收集输出形成训练集。这里有个细节老师模型的输出要保留完整的 logits 或 top-k 概率如果只保存最终文本那就退化成黑盒蒸馏了效果会打折扣。4.3 损失函数设计KL 散度加交叉熵的组合标准的蒸馏损失是两部分加权import torch import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, labels, T3.0, alpha0.7): # 软标签损失学生拟合老师的概率分布 soft_loss F.kl_div( F.log_softmax(student_logits / T, dim-1), F.softmax(teacher_logits / T, dim-1), reductionbatchmean ) * (T * T) # 硬标签损失学生拟合真实标签 hard_loss F.cross_entropy(student_logits, labels) # 加权组合 return alpha * soft_loss (1 - alpha) * hard_loss几个关键点乘以 T²这是 Hinton 论文里的做法因为 softmax 除以 T 之后梯度会缩小 T² 倍需要补偿回来。alpha 的取值我一般从 0.7 开始试如果任务有明确的硬标签且数据量大可以降到 0.5。T 的选择前面说过2 到 5 之间具体看任务。4.4 训练过程中的监控指标蒸馏训练和普通训练不一样不能只看 loss。我通常会盯这几个指标指标含义异常表现KL 散度学生和老师分布的差异持续不降说明学生容量不够学生准确率硬标签上的表现上升但 KL 不降说明在过拟合老师学生一致率两者输出相同的比例低于 70% 说明蒸馏不充分梯度范数训练稳定性突然飙升说明 T 或 alpha 设置不当我踩过的一个坑是只盯着 loss 看结果 loss 降得很好但学生模型在实际任务上表现很差。后来加了「一致率」这个指标才发现学生只是在拟合老师的低概率区域真正的高概率决策反而没学到。4.5 蒸馏后的验证别只看 benchmark蒸馏完成后最忌讳的就是只跑几个公开 benchmark 就宣布成功。我的验证流程是分布内测试用和训练集同分布的数据测看基本能力。分布外测试用没见过的任务类型测看泛化能力。边界测试故意输入一些边缘案例看学生模型会不会崩。对比测试和老师模型、和同规模从头训练的模型对比。实测下来蒸馏模型在分布内通常能接近老师的 90% 以上但分布外往往只有 60% 到 70%。这个差距是正常的也是蒸馏的固有局限。5. 蒸馏之外大模型能力获取的几条正当路径5.1 从头训练成本最高但最干净如果你有足够的算力和数据从头训练永远是最干净的路。但现实是绝大多数团队没有这个条件。一个 7B 模型的预训练成本即使在优化得很好的情况下也不是小团队能承受的。5.2 微调站在开源模型的肩膀上微调是目前最主流的做法。拿一个开源基座模型用自己的领域数据做 SFT 或 LoRA成本可控效果也不错。这条路和蒸馏的区别在于微调是在已有能力上做增量蒸馏是在复制已有能力。我个人的经验是如果你的任务是垂直领域的微调往往比蒸馏更划算因为你需要的是「专」不是「全」。5.3 知识蒸馏作为补充手段蒸馏不是非此即彼的选择它可以和其他方法组合。比如先用开源模型微调出一个领域老师再用这个老师蒸馏出一个更小的学生最后在学生上做量化部署这套组合拳我在实际项目里用过能把一个 7B 的模型压缩到 1.5B 左右推理成本降到原来的五分之一而任务准确率只掉了 3 个百分点。6. 关于这次「蒸馏」争议我的一些实际判断6.1 技术讨论不该被情绪带偏这次事件里我看到很多讨论已经脱离了技术本身变成了站队和情绪输出。作为一个技术人员我觉得有必要把几个事实摆清楚第一蒸馏是公开技术论文发了几十年不是谁发明的「歪门邪道」。第二用别人的模型输出做训练在技术社区里一直存在区别只在于是否公开、是否合规、是否标注来源。第三真正决定一个模型价值的不是它怎么来的而是它能不能解决实际问题。一个蒸馏出来的模型如果能在具体场景里稳定工作那它就有价值。6.2 对开发者的实际建议如果你是一个大模型开发者我的建议是做蒸馏项目前先确认数据来源的合规性这是底线。不要迷信蒸馏能「复制」一个模型它的上限是老师而且通常达不到老师。把蒸馏当成工具箱里的一把刀而不是唯一的解决方案。在模型卡片里如实标注训练方法和数据来源这既是职业操守也是对自己项目的保护。6.3 对企业的选型建议如果你是企业技术负责人正在考虑用蒸馏模型先做小规模验证别一上来就全量替换。关注蒸馏模型在你具体业务上的表现而不是公开榜单。评估长期维护成本蒸馏模型如果老师更新了你要不要重新蒸考虑混合方案核心任务用大模型边缘任务用蒸馏小模型。我在实际项目里最后落地的方案往往不是「全用蒸馏」或「全用大模型」而是分层部署高频简单请求走蒸馏小模型低频复杂请求走大模型。这样成本和质量都能兼顾。7. 一个容易被忽略的细节蒸馏模型的「性格」问题最后分享一个我在实际使用中发现的、很少被讨论的问题蒸馏模型会有「性格偏移」。什么意思就是学生模型虽然学到了老师的知识但它的输出风格、语气、甚至「谨慎程度」都会和老师有差异。我做过一个测试用同一个老师蒸馏出三个学生结果三个学生在面对敏感问题时的拒答率差异很大最高的 85%最低的只有 40%。这个问题的根源在于蒸馏损失函数只对齐了输出分布没有对齐「决策过程」。老师模型在训练中形成的安全边界在蒸馏时很容易被稀释。我的应对方法是在蒸馏数据里专门加入一批「边界样本」也就是那些老师会拒答或谨慎回答的输入让学生也学会这些边界。这批数据不需要多但必须有否则蒸馏出来的模型在安全性上会明显退化。这个细节常规的蒸馏教程里基本不会提但它在实际部署中非常关键。尤其是面向用户的场景一个「性格不稳」的模型带来的风险远比准确率掉几个点要大。提示如果你在做面向 C 端的蒸馏模型建议在验证阶段专门做一轮安全测试覆盖拒答、边界、诱导等场景别等上线后才发现问题。8. 写在最后蒸馏只是手段解决问题才是目的绕了一大圈回到最开始的问题他们到底偷走了什么从技术上说他们拿走的是老师模型的决策边界和输出分布。从商业上说他们拿走的是别人投入巨大成本形成的模型能力。从行业上说这件事暴露的是大模型时代「能力归属」这个还没有标准答案的问题。但作为一个每天和模型打交道的人我更想说的是蒸馏也好微调也好从头训练也好这些都只是手段。一个模型好不好最终要看它能不能在你的场景里稳定、可靠、低成本地解决问题。技术路线之争很多时候是旁观者的热闹真正做事的人关心的是手里的工具能不能把活干好。我在实际项目里用过蒸馏也用过微调也用过直接调用大模型 API。每一种方案都有它适合的场景没有哪一种是「正确」的。重要的是你要清楚每种方案的边界在哪里成本是多少风险是什么然后做出适合自己的选择。至于这次争议我的态度是技术讨论欢迎情绪站队没必要。把蒸馏的原理搞清楚把合规的边界守住把实际效果做出来比什么都强。