1. 从“点名”说起模型蒸馏到底动了谁的蛋糕1.1 一个让圈内人坐不住的消息前阵子圈子里传得沸沸扬扬的那件事估计不少做模型的朋友都刷到过——7家中国公司被公开点名理由都指向同一个技术动作蒸馏。消息一出各种讨论炸开锅有人喊“抄作业”有人说“行业惯例”还有人一脸懵蒸馏不是早就有的东西吗怎么突然就成了敏感词我先把话说在前头这篇不站队、不评判谁对谁错只从技术角度把“蒸馏”这件事掰开揉碎讲清楚。因为我自己在做模型微调和私有化部署的这几年里蒸馏几乎是绕不开的一环踩过的坑、省下的算力、翻过的车都够写一本小册子了。所以与其跟着情绪走不如把技术账算明白他们到底“偷”走了什么蒸馏的边界在哪里普通开发者又该怎么合规地用这个技术先把结论摆出来蒸馏本身不是偷它是一种被学术界和工业界广泛认可的知识迁移手段。真正引发争议的从来不是“蒸不蒸”而是蒸的对象、蒸的数据、蒸的授权链条这三件事有没有说清楚。搞懂这三点你再看那7家公司的处境心里就有数了。1.2 蒸馏到底是个什么东西用大白话讲很多人第一次听到“蒸馏”这个词会联想到化学里的提纯。其实大模型里的蒸馏逻辑上还真有点像——把一个大模型老师脑子里的“知识”浓缩迁移到一个小模型学生身上。举个生活化的例子。你有个特别厉害的老师傅做菜几十年火候、调味全凭经验你问他“盐放多少”他说“差不多就行”。这种“差不多”的模糊判断恰恰是老师傅最值钱的地方。现在你想让一个刚入行的徒弟也能做出八成水准的菜怎么办不是让徒弟把老师傅的菜谱背下来那是硬背效果差而是让徒弟观察老师傅做菜时的每一个动作、每一次犹豫、每一种偏好然后模仿。放到模型里老师傅的“经验”就是软标签soft label——模型输出的不是一个硬邦邦的“这是猫”而是一串概率分布“80%是猫15%是狗5%是兔子”。这串分布里藏着大量信息老师认为猫和狗有点像但和兔子差得远。学生模型学的就是这种概率分布背后的相似性关系而不是简单的对错。这就是蒸馏的核心用老师模型的输出分布作为监督信号训练学生模型。相比直接用原始数据训练蒸馏能让学生模型在更小的参数量下逼近老师的表现。这也是为什么那么多公司愿意做蒸馏——算力省了部署轻了效果还能打。1.3 为什么这件事会引发这么大的争议技术本身没问题问题出在“老师”是谁。如果老师模型是你自己从零训的或者你有明确的商用授权那蒸馏就是正常的技术操作没人能说什么。但如果老师模型是别人花了几千万甚至上亿美金训出来的你拿它的输出当训练数据这就涉及到一个灰色地带模型的输出算不算受保护的知识产权目前行业里的共识比较模糊。一方面模型输出不像源代码那样有明确的版权归属另一方面如果大规模、系统性地用某个模型的输出做蒸馏实质上就是在“复制”它的能力。这就好比你把老师傅的每一道菜都买回来分析成分、逆向配方然后开一家平价版餐厅——法律上可能挑不出大毛病但道义上和商业伦理上争议就大了。那7家公司被点名大概率就是在这个环节上没把授权链条理清楚。有的是直接调用API批量生成数据有的是用了公开但未明确授权的模型输出有的可能连自己都没意识到“这算蒸馏”。所以这件事给所有做模型的人提了个醒蒸馏之前先搞清楚你的老师模型能不能商用、输出能不能拿来训练、有没有明确的授权文件。这三条缺一条都可能埋雷。2. 蒸馏的技术账ODP、RL、KL到底在干什么2.1 从KL散度说起为什么它成了蒸馏的“度量尺”要理解蒸馏绕不开一个词KL散度Kullback-Leibler Divergence。这东西听起来吓人其实就是一个衡量“两个概率分布有多不一样”的指标。还是用老师傅的例子。老师傅做菜盐的用量分布是“3克40%4克35%5克25%”。徒弟做菜分布是“3克30%4克50%5克20%”。KL散度就是算这两个分布之间的“差距”。差距越小说明徒弟越像师傅。在蒸馏里KL散度就是损失函数的核心。训练学生模型时我们不是让它去拟合硬标签比如“正确答案是4克”而是让它去拟合老师模型的软标签分布。损失函数大概长这样# 简化版蒸馏损失 loss alpha * KL_divergence(student_logits / T, teacher_logits / T) (1 - alpha) * cross_entropy(student_logits, hard_labels)这里的T是温度参数作用是让概率分布变得更“平滑”。温度越高老师输出的分布越柔和学生能学到的“暗知识”越多。比如T1时老师可能输出“猫90%狗10%”T5时可能变成“猫60%狗30%兔子10%”。后者包含了更多类别间的相似性信息学生学起来更全面。我实测下来的经验是T一般取2到5之间比较稳。T太小软标签接近硬标签蒸馏退化成普通训练T太大分布太散学生学不到重点。这个参数没有绝对最优得根据任务和模型规模调。2.2 ODP和RL在蒸馏链路里的角色热词里提到的ODP和RL其实是蒸馏链路里两个不同层面的东西。ODPOn-policy Distillation Pipeline我理解是一种在线蒸馏的策略。传统的离线蒸馏是老师模型先把所有数据跑一遍生成软标签存下来然后学生模型慢慢学。这种方式的问题是老师生成的分布是固定的学生学到一定程度就“吃不饱”了。ODP的思路是边生成边学——学生模型在当前状态下产生输出老师模型实时给出反馈学生根据反馈调整。这有点像老师傅站在徒弟旁边徒弟每做一步师傅就点评一句而不是等徒弟做完一整道菜再打分。RL强化学习在蒸馏里的作用更多是对齐和优化。蒸馏出来的学生模型可能在模仿老师分布上做得不错但在实际任务上的表现未必最优。这时候可以用RL做一轮微调用任务奖励信号去“校准”学生模型的行为。比如在对话任务里用人类偏好数据训练一个奖励模型然后用PPO或DPO去优化学生模型的输出让它不仅像老师还更符合实际需求。这两者的结合我个人的理解是ODP解决“怎么高效学”的问题RL解决“学完之后怎么更好用”的问题。很多公司做蒸馏只做了第一步学生模型在基准测试上分数不错但一上真实场景就露馅就是因为缺了RL这一环。2.3 蒸馏、微调、量化别傻傻分不清楚经常有人把蒸馏和微调混为一谈其实它们的目标完全不同。技术手段核心目标数据需求算力消耗典型场景蒸馏能力迁移大模型教小模型老师模型的软标签中等端侧部署、低成本推理微调领域适配让通用模型懂专业领域标注数据较低医疗、法律、金融垂直场景量化压缩体积降低推理成本无需额外数据低边缘设备、移动端蒸馏是换模型微调是改模型量化是压模型。三者可以组合使用先蒸馏出一个中等规模的模型再微调适配业务最后量化部署到端侧。我做过一个项目把13B的模型蒸馏到1.3B再微调做客服问答最后量化到INT8推理速度提升了近10倍效果保留了原模型的85%左右。这个链路跑通之后成本直接降了一个数量级。3. 实操拆解一次完整的蒸馏流程长什么样3.1 准备工作老师模型、学生模型和数据动手之前先把三样东西准备好。老师模型的选择直接决定了蒸馏的上限。老师越强学生能学到的越多。但这里有个坑不是所有强模型都适合当老师。有些模型输出过于“自信”软标签分布很尖锐学生学不到相似性信息有些模型输出又太“散”学生抓不住重点。我一般会先跑一批样本看老师模型的输出熵——熵太高或太低都不理想中等熵的模型最适合蒸馏。学生模型的选择要考虑部署环境和任务复杂度。如果是端侧部署参数量最好控制在1B以内如果是服务端3B到7B是比较甜点的区间。学生模型的结构最好和老师有一定相似性比如都是Transformer解码器架构这样知识迁移更顺畅。数据准备是最容易被忽视的一环。蒸馏用的数据不一定要标注但覆盖面要广。我一般会准备三类数据通用语料保证基础能力、领域语料保证专业能力、边界样本保证鲁棒性。数据量不用太大几万到几十万条就够关键是质量要高、分布要均匀。注意如果老师模型是第三方商用模型务必确认其服务条款是否允许用输出做训练。很多API的ToS里明确禁止用输出训练竞争模型这条红线不能碰。3.2 蒸馏训练的核心参数与调参经验真正开始训练时有几个参数直接决定成败。温度T前面说过一般取2到5。我的习惯是先跑一组小实验T取1、2、3、5、10看学生模型在验证集上的表现选最优的。大多数情况下T3是个不错的起点。损失权重alpha控制软标签损失和硬标签损失的比例。如果数据有高质量标注alpha可以设小一点比如0.3到0.5让硬标签起主导作用如果标注数据少alpha设大一点0.7到0.9更多依赖老师的软标签。我一般从0.7开始调。学习率蒸馏的学习率通常比普通训练小一个数量级。因为软标签的梯度信号比较柔和学习率太大会导致训练不稳定。我常用的是1e-5到5e-5之间配合warmup和余弦退火。批次大小在显存允许的前提下尽量大。蒸馏的梯度噪声比普通训练大大批次能平滑训练过程。如果显存不够可以用梯度累积模拟大批次。# 典型蒸馏训练配置 config { temperature: 3.0, alpha: 0.7, learning_rate: 2e-5, batch_size: 64, gradient_accumulation: 4, warmup_steps: 500, max_steps: 20000, optimizer: adamw, scheduler: cosine }这套配置我在多个项目里跑过稳定性不错。但要注意不同任务的最优参数差异很大分类任务和生成任务的调参思路就不一样。分类任务更依赖软标签的相似性信息T可以大一点生成任务更依赖序列级别的分布匹配T要小一点。3.3 训练过程中的监控与早停策略蒸馏训练最怕两件事过拟合和欠拟合。过拟合的表现是学生模型在训练集上越来越像老师但在验证集上表现停滞甚至下降。这时候要看KL散度的变化——如果KL持续下降但验证指标不涨说明学生只是在“死记”老师的输出没有真正学到泛化能力。解决办法是加正则化、减小alpha、或者增加数据多样性。欠拟合的表现是KL散度下降很慢学生模型和老师差距一直很大。这通常是学生容量不够或者温度设置不当。可以尝试换大一点的学生模型或者调高温度让软标签更平滑。我一般会设一个早停策略连续3个epoch验证指标不提升就停。同时保存KL散度最低和验证指标最高的两个checkpoint最后对比选优。有时候KL最低的模型未必是实际效果最好的这个坑我踩过好几次。4. 避坑指南蒸馏路上那些没人告诉你的坑4.1 授权链条最容易被忽视的合规风险回到开头那7家公司的事。我仔细想了想他们大概率不是故意“偷”而是授权链条没理清楚。举个例子。你用某个开源模型A做蒸馏A的许可证是Apache 2.0看起来可以商用。但A本身可能是从另一个模型B蒸馏来的而B的许可证禁止商用。这时候你用A做蒸馏风险就传导过来了。更复杂的是有些模型的训练数据来源本身就有争议你用它做蒸馏等于间接使用了那些有争议的数据。我的建议是做蒸馏之前画一张授权链路图。老师模型是谁训的、用什么数据训的、许可证是什么、输出有没有额外限制。这张图理清楚了再动手。如果链路里有任何一环说不清楚宁可换一个老师模型也别冒这个险。提示开源许可证不是免死金牌。GPL、Apache、MIT、CC-BY-NC这些许可证的约束力差别很大商用前务必逐条看清楚。特别是CC-BY-NC明确禁止商用用它做蒸馏再商用风险极高。4.2 数据泄露老师模型的“记忆”会被学生继承这是一个很少被讨论但非常严重的问题老师模型在训练时“记住”的训练数据可能会通过蒸馏传递给学生模型。大模型在预训练阶段会记住大量原始文本尤其是一些重复出现的敏感信息。当你用老师模型的输出做蒸馏时这些记忆可能会以软标签的形式传递给学生。学生模型在特定提示下可能会“回忆”出老师记住的原始数据。我做过一个实验用一个在特定数据集上微调过的老师模型做蒸馏结果学生模型在某些提示下输出了和老师训练数据高度相似的片段。虽然概率不高但一旦发生就是实打实的数据泄露。防范办法有两个一是对老师模型的输出做过滤检测是否包含敏感信息二是在蒸馏数据里加入噪声降低记忆传递的概率。但说实话这个问题目前没有完美的解决方案只能尽量降低风险。4.3 能力退化蒸馏不是万能的很多人以为蒸馏就是“大模型变小模型效果差不多”实际远没那么美好。蒸馏会丢失的能力主要有三类一是长尾知识老师模型知道的冷门事实学生模型往往学不到二是推理链老师模型的多步推理能力很难通过软标签传递三是指令遵循的精细度学生模型在复杂指令下的表现通常不如老师。我做过一个对比同一个老师模型蒸馏到1/10参数量后在通用问答上保留了约80%的效果但在数学推理上只保留了不到50%。这就是蒸馏的局限——它擅长迁移“感觉”不擅长迁移“逻辑”。所以我的建议是蒸馏适合做能力兜底不适合做能力上限。如果你需要模型具备强推理能力要么用大模型要么用专门训练的推理小模型别指望蒸馏能解决所有问题。4.4 常见问题速查表问题现象可能原因排查思路解决办法学生模型输出重复温度太低软标签太尖锐检查T值观察输出熵调高T到3-5训练loss不下降学习率太小或alpha设置不当检查梯度范数调大学习率或调整alpha验证指标波动大批次太小梯度噪声大检查batch size增大批次或梯度累积学生模型“胡说八道”老师模型本身有幻觉检查老师输出质量过滤低质量蒸馏数据推理速度没提升学生模型结构没优化检查参数量和层数换更小的学生模型或量化特定任务表现差蒸馏数据覆盖不足检查数据分布补充领域数据重新蒸馏这张表是我这几年踩坑总结出来的基本覆盖了80%的常见问题。遇到新问题先对照这张表排查能省不少时间。5. 蒸馏之后部署、评估与持续优化5.1 蒸馏模型的部署选型蒸馏出来的模型最终是要落地的。部署方式的选择直接影响成本和体验。本地部署适合对数据隐私要求高的场景。用Ollama、vLLM这类工具可以把蒸馏模型跑在本地GPU上。我实测下来1.3B的蒸馏模型在单张消费级显卡上就能流畅运行延迟控制在100ms以内。如果是7B的模型需要至少16G显存延迟在300ms左右。云端部署适合流量波动大的场景。蒸馏模型体积小云端的推理成本比大模型低很多。我算过一笔账同样处理100万次请求13B模型需要4张A100蒸馏到1.3B后只需要1张T4成本差了将近20倍。端侧部署是蒸馏最大的价值场景。手机、车机、IoT设备这些算力有限的终端跑不动大模型但跑一个蒸馏后的小模型绰绰有余。我见过一个案例把对话模型蒸馏到500M参数量化后塞进车机芯片实现了离线语音助手响应速度比云端方案还快。5.2 评估蒸馏效果的几个关键指标评估蒸馏效果不能只看loss。我一般会看这几个维度任务指标比如分类准确率、生成质量分、问答F1值。这是最直接的评估但要注意测试集要和训练集分布一致否则指标没意义。KL散度衡量学生和老师输出的分布差距。KL越小说明学生越像老师。但KL小不代表效果好前面说过可能只是“死记硬背”。推理延迟蒸馏的核心收益之一就是速度。我一般会测P50和P99延迟看是否满足业务要求。鲁棒性用对抗样本和边界样本测试学生模型看是否容易崩溃。蒸馏模型在这方面通常比老师弱需要额外关注。成本包括推理成本和维护成本。蒸馏模型体积小部署成本低但如果效果下降太多省下的成本可能抵不过业务损失。5.3 持续优化蒸馏不是一次性的活很多人以为蒸馏做完就万事大吉了其实这只是开始。数据飞轮是持续优化的关键。把线上推理的bad case收集起来人工标注后加入蒸馏数据重新训练学生模型。这样迭代几轮学生模型会越来越贴近实际业务需求。老师模型的更新也要跟上。如果老师模型升级了学生模型也要重新蒸馏否则能力差距会越来越大。我一般会设一个季度一次的蒸馏更新周期保证学生模型不落后太多。混合策略也值得尝试。不是所有场景都适合纯蒸馏模型有些复杂请求可以路由到大模型简单请求走蒸馏模型。这种大小模型协同的架构能在成本和效果之间找到更好的平衡点。6. 回到那个问题他们到底“偷”走了什么6.1 技术视角下的“偷”与“学”绕了一大圈回到最初的问题。那7家公司被点名“蒸馏”他们到底偷走了什么从纯技术角度看他们偷走的是老师模型在训练过程中形成的概率分布知识。这些知识不是某一行代码、某一个参数而是模型对世界的“理解方式”——它认为哪些概念相似、哪些答案更可能、哪些推理路径更合理。这些东西是老师模型花了大量算力和数据才学到的。但“偷”这个字本身就带有价值判断。如果授权链条清晰、使用方式合规那叫“学习”和“迁移”如果授权不明、大规模商用那就叫“偷”。技术本身没有原罪有罪的是使用方式。6.2 对普通开发者的启示这件事对咱们普通开发者最大的启示不是“别做蒸馏”而是做蒸馏之前先把合规想清楚。我自己的做法是优先用自己训练的模型当老师或者用明确允许商用的开源模型。如果必须用第三方模型一定先读许可证必要时发邮件确认。蒸馏数据自己生成、自己清洗不碰来源不明的数据。这样虽然麻烦一点但睡得踏实。另外蒸馏不是唯一的降本路径。量化、剪枝、MoE架构、投机解码这些技术都能降低成本而且合规风险更小。我一般会组合使用先蒸馏压缩参数量再量化降低精度最后用投机解码加速推理。这套组合拳打下来成本能降一个数量级效果还能保留八成以上。6.3 我个人的一点体会做模型这几年我最大的感受是技术跑得越快合规越要跟上。蒸馏是个好技术它让更多人能用上大模型的能力推动了整个行业的普及。但好技术用歪了伤害的是整个生态。那7家公司的事对行业来说未必是坏事。它让更多人开始关注模型授权的边界开始思考“什么能做、什么不能做”。这种讨论比技术本身更有价值。最后分享一个小技巧如果你不确定某个蒸馏方案是否合规先做小规模实验别一上来就全量跑。小规模实验既能验证技术可行性又能评估合规风险成本还低。等确认没问题了再放大规模。这个习惯帮我避开了不少坑也推荐给你。