1. “蒸馏”上了热搜我们先聊聊为什么这个词突然这么烫手最近一段时间只要你稍微关注大模型圈子应该都被“蒸馏”这两个字刷屏了。先是几家公司被公开点名说它们“蒸馏”了别家模型紧接着各种版本的回应、截图、技术分析满天飞。作为一个常年在大模型落地一线调模型、跑训练的人我第一反应不是站队而是觉得这件事终于藏不住了。“蒸馏”在深度学习里本来是个非常正统、非常高效的技术路线从 Hinton 老爷子 2015 年那篇经典的《Distilling the Knowledge in a Neural Network》开始蒸馏就被用来把大模型的能力压缩到小模型里是工业界最常用的模型瘦身手段之一。大模型时代蒸馏更是一门显学OpenAI 的 GPT-4 能力要下放到小模型Anthropic 的 Claude 要适配低成本设备国内各家大厂、创业公司想让模型跑在手机和边缘设备上几乎人人都要碰蒸馏。但“蒸馏”这个词一旦和“偷”挂钩味道就变了。被点名的公司据说是在没有授权的情况下用别人家大模型的 API 或者开源模型产出的数据去训练自己的模型甚至直接把对方模型的“思考过程”和“回答风格”学了过来。这不是学术圈里互相引用的蒸馏而是商业竞争语境下的“搭便车”。我身边不少朋友一听到“蒸馏”就说这不就是抄作业吗其实还真没那么简单。我更喜欢把它理解成“带着老师上课最后学会的却是学生”——老师可能都不知道自己带了这门课。为了把这件事讲清楚这期我就从技术原理、实操流程、落地陷阱这几个方面把“蒸馏”这层窗户纸彻底捅破顺便分享一些我自己在蒸馏项目里踩过的坑。先说结论蒸馏本身不是洪水猛兽问题出在“蒸馏的对象是谁”和“蒸馏之后用来干什么”。把技术讲明白了你自然就知道这波争议背后大家真正在争的是什么。2. 被“偷走”的知识到底长什么样2.1 一张图看懂老师和学生之间传递的是“软标签”很多人以为蒸馏就是“把大模型的答案抄一遍然后拿去训练小模型”。这么理解方向对但粒度太粗了。真实情况是大模型给的不只是一个“最终答案”而是一整套“候选词的概率分布”。我给你举个具体例子。假设老师模型被问到“中国的首都是什么”这个问题太简单答案只有一个词“北京”这种叫硬标签。但在真实场景里问题通常没有唯一解。比如“写一封邮件语气要正式但不生硬”老师模型会在输出时给每一个可能的 token 打分这个打分向量就是 logits经过 softmax 换算之后变成概率分布这才是蒸馏里真正传递的东西。这个概率分布有个非常值钱的特性它不光告诉你“哪个词是对的”还告诉你“哪些词差不太多”。比如在翻译“I am happy”时学生模型从硬标签里只能学到“高兴”但从老师模型的软标签里它能学到“高兴”和“开心”“愉悦”之间的相似度关系。这种相似度关系就是模型“语感”的来源也是从零训练很难学出来的部分。为了进一步放大这种软标签里的“模糊信息”蒸馏通常会引入一个温度参数 T。温度越高概率分布越平滑越能暴露出老师模型对各个候选词的偏好差异温度越低分布越尖锐越接近硬标签。实操中T 一般取 2 到 4 之间太低起不到蒸馏效果太高会把噪声也学进去。我用 OpenML 上公开的 CIFAR-10 做过一组对比实验直接用硬标签训练一个小 ResNet精度大概在 83%用教师模型 soft label 蒸馏温度设为 3精度能到 87.5%。额外赚了 4.5 个点成本几乎为零。这就是蒸馏的魔力。2.2 被点名公司“偷走”的是四种东西推理痕迹、对齐偏好、领域数据、产品体验单纯讲 logits 还不够直观。放到大模型语境里蒸馏“偷走”的不是一两个参数而是四种高度浓缩的资产我说完你大概就能明白为什么这事会让各家模型厂商如此紧张。第一种是推理痕迹。现在的顶尖模型在回答复杂问题前内部会产生一段链式思考也就是所谓的 CoT。这段思考链在 API 返回时通常被藏起来了但很多开源模型会把推理过程直接展示出来。蒸馏方如果把几千条带完整推理过程的高质量问答拿去训练自己的模型等于直接继承了老师模型“思考问题的方式”。这是浓缩的智力花钱砸数据、砸算力短时间也未必能攒出来。第二种是对齐偏好。大模型从 Pretrain 到 Chat中间要经过 RLHF 或 DPO 这类对齐步骤目的就是让模型懂得“什么话该说什么话不该说什么语气更适合对话”。这些偏好信息是大量人工标注和反复迭代调出来的。直接把老师模型的输出当作正样本去训练就等于绕过了整个对齐工程把对方辛辛苦苦调出来的“性格”一键复制。第三种是领域数据和知识结构。老师模型在海量私有数据上训练过它知道某些垂直行业里的专有名词、行话、案例。虽然 API 输出只是“知识的外显”但高密度、高代表性的输出足以让蒸馏方在小样本场景下重建相当一部分领域知识。我在做金融大模型时验证过用 ChatGPT 生成的模拟财报问答对微调开源模型模型对金融指标的理解力提升了不止一个档次。第四种是产品体验。包括响应格式、停顿节奏、结构化输出风格甚至报错的方式。对 C 端产品来说用户已经习惯了某类模型的“人设”蒸馏方直接把这种产品化体验以数据形式偷走用户几乎零迁移成本。这已经不只是技术问题而是商业竞争层面的侵权。3. 真正实操从零完成一个模型蒸馏项目3.1 准备阶段教师模型、学生模型与训练数据怎么选在聊被点名公司的事之前我更想带你亲手跑一遍蒸馏。“纸上得来终觉浅”只有自己动手跑过蒸馏你才能从直觉上理解为什么这事在工业界如此普遍。我用一个经典组合做演示教师模型选 Qwen2.5-14B-Instruct学生模型选 Qwen2.5-1.5B-Instruct使用 PyTorch 2.1 transformers deepspeed单机 8 卡 A100 80G 足够。这个组合很有代表性14B 的教师能提供足够丰富的知识分布1.5B 的学生又能跑得动符合大多数团队的硬件现状。数据集选择是蒸馏成功的一半。我的经验是宁可要 10 万条高质量数据也不要 100 万条凑数数据。具体选数据时我优先看三个维度覆盖度、难度和多样性。覆盖度指任务类型要全对话、摘要、代码、数学都要有难度指要包含一些教师模型“需要思考一下”才答得出来的题全是简单题学生学不到东西多样性指不要让某一种领域数据占比超过 20%否则蒸馏出来的模型会偏科。数据准备好之后先用教师模型批量推理生成软标签。如果是黑盒蒸馏比如只有 API 没有 logits那就需要用采样法温度设为 0.7对每条 prompt 跑 3 次采样把生成结果一起作为软标签这个 trick 能极大弥补拿不到 logits 的缺陷。3.2 关键参数计算温度、损失权重和批次策略蒸馏训练里最核心的三个参数我一个个说。温度 T 的选择。如果 T 太低软标签接近硬标签等于白蒸馏太高模型会把噪声当成真知识学坏。我的经验公式是先看任务复杂度简单任务 T 取 2复杂推理任务 T 取 4然后再跑一组 T1/T2/T4 的消融实验看验证集效果选。别嫌麻烦这个参数差一点最终模型效果可能差好几个点。损失权重 α。蒸馏损失和标准 CE 损失的权重比推荐设置为 0.7:0.3。我一开始用五五开结果学生模型学得四不像hard label 提供的“标准答案”被稀释了导致模型稳定性下降。后来改成 alpha0.7把 KL 散度作为主导训练曲线的收敛性和最终效果都明显变好。原因不复杂教师模型也会犯错得留一部分硬标签的“锚点”来纠偏。批次策略也就是 batch size 的设定。蒸馏训练里学生模型本身不大但软标签文件可能很大所以我建议用 gradient checkpointing batch size 16 做基准配合 deepspeed stage 2显存占用能控制在 40G 以内。我见过一些团队为了追求大 batch 把显存撑爆其实没必要蒸馏任务里 batch size 从 16 升到 32收益很小但显存压力翻倍。我在实验中分别用 T1、T2、T4 跑过三个模型基线效果差异如下表温度推理准确率对话流畅度评分训练稳定性备注T168.2%3.2/5稳定几乎等于微调没利用软标签优势T274.5%4.1/5稳定综合性价比最高T469.7%3.8/5波动明显噪声干扰增大需要加大硬标签权重才能稳住这个表基本能说明问题温度不是越高越好需要搭配任务特性来调。3.3 训练与评估跑通一个最小闭环代码层面我提炼一个最小蒸馏训练脚本框架。核心就是两步先加载教师模型得到 logits再让学生模型输出和教师输出算 KL 散度。import torch import torch.nn.functional as F from transformers import AutoModelForCausalLM, AutoTokenizer teacher_model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-14B-Instruct) student_model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-1.5B-Instruct) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-1.5B-Instruct) # 假设 inputs 已经 token 化 with torch.no_grad(): teacher_logits teacher_model(**inputs).logits student_logits student_model(**inputs).logits # 温度缩放后的 KL 散度作为蒸馏损失 def distillation_loss(student_logits, teacher_logits, temperature4.0): student_logits student_logits / temperature teacher_logits teacher_logits / temperature loss F.kl_div( F.log_softmax(student_logits, dim-1), F.softmax(teacher_logits, dim-1), reductionbatchmean, ) return loss * (temperature ** 2)这里有个小细节KL loss 乘以温度平方是为了让梯度保持在和普通 CE 损失相近的尺度不然温度升高后梯度会缩小导致训练不动。这个 trick 在 Hinton 的论文里写得很清楚但实操中很多人会漏掉。训练完成后评估不能只看 benchmark。我的做法是“三层评估”第一层跑公开评测集比如 MMLU、C-Eval第二层人工抽检 50 条业务真实问题从准确性、语气、格式三个维度打分第三层用 LLM-as-a-Judge 的方式拿教师模型的输出当标准答案计算学生模型输出与之的语义相似度。三层都过线了才敢上线。4. 实战里最常见的问题能避一个是一个4.1 训练 loss 不降反升多半是数据噪声或温度失控这是我被问得最多的问题。学生在训练中 loss 震荡很常见但如果是 loss 一路走高我建议你先排查三件事。第一数据里有没有重复的 prompt 或几乎一样的输出如果教师模型对同一类 prompt 给出了矛盾的答案学生模型会犯迷糊。我处理过一套 50 万条的数据集清洗前 loss 降不下来跑了个文本去重后同样的参数下 loss 直接掉了 0.4。第二温度是不是设得太高T 大于 8 时教师模型的概率分布接近均匀分布软标签的信息量趋近于零学生只能瞎猜。第三训练动态里的学习率是不是太大了蒸馏场景下我习惯把学习率降到正常微调的三分之一否则学生模型很容易被教师输出中的极端波动带偏。分享一个排查技巧不管参数怎么调先取 1000 条数据做 10 个 step 的 smoke test如果 loss 能稳定下降说明整体 pipeline 没毛病接下来再放大数据量。这个习惯帮我排掉了很多低级 bug包括数据没对齐、标签错位这类问题。4.2 蒸馏完反而变笨了过拟合教师模型的问题另一个高频问题是蒸馏之后学生模型在训练集上效果不错一到新问题就露馅连原本自己会的知识都忘了。这其实是典型的“过度蒸馏”本质是学生模型过分拟合了教师模型的输出分布丢失了自身通用能力。我的解决方案是三管齐下。首先降低蒸馏损失的权重alpha 从 0.7 调到 0.5给硬标签更多存在感。其次在蒸馏训练中混入一定比例的原始预训练数据大概 20% 到 30%让模型在学教师的同时不忘记自己的语言能力。最后教师模型的 logits 别用得太“绝对”在软标签里加一点 label smoothing比如 0.05相当于给教师模型的判断也留出容错空间学生就不会把教师的每个偏好都当成圣旨。我还遇到过一个隐蔽问题教师模型本身有系统性偏见比如对某个特定类型的提问总是过度道歉。学生模型蒸馏后也学会了这套废话连篇的毛病。这种偏见靠调参很难解决只能先把教师模型在这些场景下的输出过滤掉或者重新采样一批更中性的数据。4.3 黑盒蒸馏的坑没有 logits 时怎么办很多团队不是拿着教师模型的权重自己做蒸馏而是直接调用 API。这种黑盒蒸馏在训练时没有教师模型 logits只能拿到推理文本。这时候千万别直接把 text 打成分词后当硬标签训练那就没意义了。我推荐的做法是多样化采样 排序组合。对每条 prompt 并行采样 8 条回复然后用一个奖励模型或者规则打分器给这些回复排个序取 top 2 的回复作为软标签的正样本取分数最低的作为负样本配合 DPO 训练。这种方案本质上是把黑盒蒸馏转化成了偏好对齐任务效果比直接微调高不少。还有一个更取巧的训练配方先用黑盒采样数据做一轮 SFT让学生模型“外形”先贴近老师再用奖励模型做一轮 DPO让学生模型学会“筛选”老师的最佳输出。我在 chatbot 场景测试过这个两阶段黑盒蒸馏方案能把 response 的采纳率提升 12% 左右仅次于白盒蒸馏的 15%。5. 蒸馏的边界在哪里从技术到商誉界线比你想的更模糊5.1 谁都在蒸馏区别只是“蒸馏谁”和“怎么用”这里必须说点掏心窝子的话蒸馏在 AI 圈根本不是秘密几乎所有团队都做过某种形式的蒸馏。我自己在内部项目里就用过开源模型的输出做蒸馏数据这是行业惯例。那为什么这次被点名的公司让大家如此愤怒关键在“被蒸馏方是否知情并同意”以及“蒸馏之后是否彻底替代了原模型的服务”。如果蒸馏的是开源模型比如 Llama 或 Qwen许可协议里明确允许二次利用和蒸馏那这就是技术常规操作谁都没资格指责。如果蒸馏的对象是闭源商业 API而对方服务条款明确禁止用输出去训练竞品模型这就涉嫌违反合同约定。再往上一层如果蒸馏方借着老师的品牌形象去融资、去宣传自己的技术实力这就是商誉层面的问题了。我个人的判断标准很简单问自己一个问题——“如果老师模型的团队看到了学生模型的输出会不会觉得被冒犯”如果会那大概率越界了。5.2 谁都在蒸馏区别只是“蒸馏谁”被点名的 7 家公司里有些是初创企业有些是大型平台各自的姿态和辩解也不一样。站在第三方视角看这类纷争的本质是大模型公司投入巨额成本构建的数据飞轮到底哪些部分可以被后来者复用哪些部分是商业机密目前没有统一答案各家公司条款也不一致。我认为健康的行业生态应该遵循三个原则一是遵守许可协议开源模型按许可证来闭源 API 按服务条款来这是底线二是引用标注用了别人的数据或模型做蒸馏应当在技术报告中说明数据来源学术界的 reproducibility 精神在产业界同样适用三是价值增量蒸馏不是终点蒸馏之后必须做出老师模型做不好的东西比如更低延迟、更大上下文、更垂直的能力。前阵子有人提出过一个有趣的说法蒸馏就像拜师学艺。你拜师学的是思维方式、行业门道而不是把师傅的指纹、银行卡密码全偷走。前者叫传承后者叫犯罪。这个类比虽然粗糙但话糙理不糙。5.3 对普通开发者的影响你可以怎么用蒸馏而不惹祸普通开发者和中小团队没必要因为这次新闻而“因噎废食”更不该放弃蒸馏这个效率极高的技术方案。我建议你记住以下几条红线。只对明确授权允许的模型做蒸馏。用开源模型蒸馏先看 LICENSE 里有没有“不可用于训练其他模型”的限制条款。用商业 API 的输出做数据先查阅服务条款很多大厂 API 都禁止把输出用于训练“竞争性模型”。避免全量复制哪怕是合法蒸馏也不要把教师模型在特定风格或长尾场景下的输出原封不动搬来尽量加一层自己的后处理和风格改写。记录并公开你的蒸馏来源。一旦模型做大了这种信息公开不仅是礼貌也是自保。我看到越来越多公司在发布模型卡时明确写“基于 XX 模型蒸馏遵循 XX 协议”这才是把技术清白用在明面上的做法也是对行业的正向示范。6. 写在最后我的一点个人观察从技术角度看蒸馏永远是大模型进化的加速器没有任何理由因为商业争议而否定其价值。模型压缩、能力迁移、边缘部署这些刚需场景少了蒸馏会寸步难行。但从行业的角度看这次“被点名”事件给所有从业者提了个醒技术的下游是商业商业的下游是规则。你可以跑得很快但得知道跑道在哪里。我个人的体会是与其去争论谁偷了谁不如把精力花在建立更透明的蒸馏实践上。把数据来源、训练方法、模型权重的血缘关系记录得清清楚楚既能保护自己也让整个行业少一些无意义的互撕。说不定几年之后再回头看这次“点名”反而成了中国大模型行业从野蛮生长走向规范化的一个分水岭。最后分享一个小技巧当你想要用老师模型蒸馏又担心版权问题时不妨先用老师模型生成数据再通过自己的业务数据混合重写一遍。这个过程产生的数据已经带有你的场景特色既保留了蒸馏的效率又降低了“原样照抄”的风险。这套做法我用了很久稳。