1. 从「蒸馏」这个词说起它到底指什么先把话说在前头模型蒸馏不是什么见不得人的黑科技它是深度学习领域一个非常经典、写在教科书里的模型压缩方法。最早可以追溯到 2015 年 Hinton 那篇《Distilling the Knowledge in a Neural Network》核心思想特别朴素让一个小模型去模仿一个大模型的输出分布从而把小模型的能力拉高到接近大模型的水平。打个生活化的比方。大模型像一位经验丰富的老教授脑子里装了几十年积累的学识但他讲课慢、开销大、走到哪都要带一堆设备。小模型像一个刚入学的年轻助教脑子转得快、成本低、能同时给几百个班上课但知识储备不够。蒸馏做的事情就是让助教跟着老教授听课不光听教授给出的「标准答案」还要听教授对每个问题给出的「倾向性判断」——比如教授说这道题 70% 可能是 A25% 可能是 B5% 可能是 C。助教学到的不只是答案本身还有教授判断问题时的「软信息」这才是蒸馏真正的价值所在。这里就引出一个关键概念软标签soft label。传统训练用的是硬标签答案非黑即白是 A 就是 A。而蒸馏用的是教师模型输出的概率分布也就是软标签。软标签里包含了类别之间的相似性信息比如「猫」和「狗」的概率都比「汽车」高这种信息是硬标签给不了的。小模型通过拟合这个分布能学到更细腻的决策边界。那怎么衡量两个分布的差距呢这就用到了KL 散度Kullback-Leibler Divergence。KL 散度衡量的是两个概率分布之间的「距离」蒸馏的损失函数通常就是学生模型的输出分布和教师模型的输出分布之间的 KL 散度再乘上一个温度系数 T 做平滑。温度 T 越高分布越平滑软标签里的「暗知识」就越容易被学生捕捉到。这个 T 一般取 2 到 20 之间太小了软标签退化成硬标签太大了分布太平学生学不到重点。所以你看蒸馏本身是一个中性的技术手段。问题不在于「蒸不蒸」而在于「蒸什么」和「怎么蒸」。这就引出了标题里说的那件事——7 家中国公司被点名「蒸馏」争议的焦点其实不在蒸馏技术本身而在于蒸馏的数据来源和使用边界。2. 被点名的「蒸馏」争议偷走的到底是什么要理解这场争议得先搞清楚大模型行业里「蒸馏」这个词在两种语境下的不同含义。第一种是技术意义上的蒸馏就是我上面说的用一个大模型当教师训练一个小模型。这是完全合规的常规操作很多开源小模型都是这么来的比如一些 7B、13B 的模型背后往往有更大的教师模型在指导。第二种是数据意义上的蒸馏也就是用另一个大模型的输出结果作为训练数据来训练自己的模型。这种做法在行业里有个更通俗的说法叫「合成数据训练」或者「用 AI 生成的数据训 AI」。争议就出在这里。打个比方。第一种蒸馏像是「我请了一位名师来给我自己的学生上课学生学到了名师的思路」。第二种蒸馏像是「我把名师的讲义、习题、答案全部抄下来整理成自己的教材然后拿去卖」。前者是学习后者就涉及到知识产权和商业道德的边界了。那被点名的公司到底「偷走」了什么从公开讨论来看核心争议点集中在几个方面第一是输出数据的规模化采集。有些公司被质疑通过 API 大规模调用其他模型的接口把返回结果存下来当训练数据。这种做法在技术上不难实现写个脚本批量调用就行但问题在于很多模型的服务条款里明确写了「禁止用输出结果训练竞品模型」。你调 API 自己用没问题但拿去训一个直接竞争的模型这就踩线了。第二是数据里隐含的能力迁移。大模型的输出不只是文字它还隐含了模型在预训练阶段学到的世界知识、推理模式、语言风格。你用它的输出去训自己的模型本质上是在「继承」它的能力。这种继承如果没经过授权就相当于绕过了对方投入的巨额算力和数据成本。第三是评测基准的污染。这个更隐蔽。如果训练数据里混入了某些评测集的题目和答案那模型在评测上的表现就会虚高给人一种「能力很强」的错觉。这在行业里叫「数据泄漏」或者「基准污染」是评测领域的老大难问题。我个人的判断是这场争议的本质不是「蒸馏」这个技术有问题而是数据来源的合规性和能力迁移的边界没有清晰的行业共识。大模型时代什么算「合理使用」什么算「侵权」法律和行业规范都还在追赶技术发展的脚步。作为从业者我的态度很明确技术可以学方法可以用但数据来源必须干净这是底线。3. 蒸馏的技术原理拆解从 KL 散度到温度系数既然要聊蒸馏那就把技术细节讲透。这一节我尽量用大白话把蒸馏的核心机制说清楚不管你是刚入门还是已经做过微调都能有所收获。3.1 教师-学生框架的基本结构蒸馏的标准框架包含两个模型教师模型Teacher和学生模型Student。教师模型通常是大模型参数量大、能力强但推理慢、部署成本高。学生模型通常是小模型参数量小、速度快但单独训练的话能力有限。训练过程是这样的把同一批数据同时喂给教师和学生教师输出一个概率分布软标签学生也输出一个概率分布然后计算两个分布的 KL 散度作为损失反向传播更新学生的参数。教师模型的参数是冻结的不参与更新。这里有个细节很多人会忽略教师模型不一定非要是一个完整的大模型。在实际工程里教师可以是多个模型的集成ensemble也可以是同一个模型在不同训练阶段的快照。集成蒸馏的效果往往比单教师更好因为多个教师的软标签平均之后噪声更小信息更稳定。3.2 温度系数 T 的作用与选择温度系数 T 是蒸馏里最关键的参数。它的作用是把 softmax 的输出分布「平滑化」。公式是这样的softmax(z_i / T) exp(z_i / T) / sum(exp(z_j / T))当 T1 时就是标准的 softmax。当 T1 时分布变得更平滑原本概率很低的类别也会分到一些概率这些「小概率」里往往藏着教师模型的「暗知识」。当 T1 时分布变得更尖锐接近硬标签。T 怎么选我的经验是对于分类任务T 一般取 2 到 10 之间。对于语言模型这种输出空间极大的任务T 可以取到 20 甚至更高因为词表动辄几万分布本身就很稀疏需要更高的温度才能让软标签携带足够的信息。T 太大也不行分布太平了学生学到的信号会被噪声淹没。实际调参的时候我一般会先固定 T4 跑一版 baseline然后以 2 的步长上下扫看验证集上的表现。这个参数对最终效果的影响比学习率还敏感值得多花时间。3.3 损失函数的组合策略蒸馏的损失通常不是单一的 KL 散度而是「蒸馏损失 学生自身的任务损失」的加权组合L alpha * KL(student_soft, teacher_soft) (1 - alpha) * CE(student_logits, hard_label)其中 alpha 是权重系数CE 是交叉熵损失。这个组合的意义在于KL 散度让学生学教师的「软判断」交叉熵让学生学真实标签的「硬答案」。两者结合学生既能继承教师的能力又不会完全偏离真实任务。alpha 一般取 0.5 到 0.9 之间。如果教师模型质量很高alpha 可以调大一些如果教师本身有噪声alpha 就要调小多依赖真实标签。3.4 蒸馏与微调的区别很多人会把蒸馏和微调搞混这里必须澄清一下。微调Fine-tuning是在一个预训练好的模型基础上用特定领域的数据继续训练让模型适应新任务。微调不涉及模型结构的变化也不涉及教师-学生框架。蒸馏Distillation是训练一个小模型去模仿大模型核心是模型压缩和能力迁移。蒸馏出来的学生模型结构可以和教师完全不同参数量也可以小很多。两者可以结合使用先蒸馏得到一个小的基座模型再对这个基座做领域微调。这种「先蒸后调」的流程在实际工程里很常见尤其是需要把模型部署到边缘设备上的场景。4. 大模型蒸馏的实操流程从数据准备到部署光讲原理不够这一节我把一个完整的蒸馏流程拆开给你一套可以直接参考的操作方案。需要说明的是以下步骤是基于行业常见实践整理的具体参数需要根据你的任务和数据做调整。4.1 数据准备蒸馏的燃料蒸馏对数据的要求和普通训练不太一样。普通训练只要有输入和标签就行蒸馏还需要教师模型对每条输入的输出分布。数据准备分三步第一步收集输入数据。这些数据可以是你自己的业务数据也可以是公开数据集。关键是输入要覆盖你关心的任务分布。比如你要蒸一个客服对话模型那输入就应该是真实的用户问题而不是随便找一堆新闻文本。第二步跑教师模型生成软标签。把输入数据批量喂给教师模型保存每个位置的输出 logits 或者概率分布。这里有个工程上的坑logits 的存储开销很大。如果词表是 5 万序列长度是 512那一条样本的 logits 就是 5万 × 512 个浮点数按 float32 算就是 100MB 左右。一万条样本就是 1TB。所以实际工程里通常只存 top-k 的概率和对应的 token idk 一般取 10 到 50 就够了。第三步数据清洗和过滤。教师模型的输出不一定都是对的有些样本教师自己就答错了或者输出分布很平说明教师也不确定。这些样本要过滤掉否则学生学到的是噪声。我一般会设一个置信度阈值比如教师输出的最大概率低于 0.5 的样本直接丢弃。4.2 学生模型的选择与初始化学生模型的选择取决于你的部署目标。如果目标是手机端那可能得选 1B 以下的模型如果是服务器端7B 到 13B 都可以考虑。学生模型的初始化有两种策略随机初始化从头训适合学生和教师结构差异很大的情况。用教师的部分层初始化比如取教师的底层若干层作为学生的初始化适合学生是教师的「缩小版」的情况。我个人的经验是如果学生和教师的架构同源比如都是 Transformer decoder用教师的部分层初始化能显著加快收敛。如果架构不同那就老老实实随机初始化。4.3 训练配置与关键参数训练配置这块我把关键参数列个表方便你对照参数推荐范围说明温度 T2-20语言模型取高值分类任务取低值alpha0.5-0.9教师质量高则调大学习率1e-5 到 5e-5比普通训练小因为软标签信号更稳定batch size尽量大蒸馏对 batch size 不敏感但大 batch 更稳训练轮数3-10看验证集别过拟合这里重点说下学习率。蒸馏的学习率要比普通训练小因为软标签提供的梯度信号比硬标签更「柔和」学习率大了容易震荡。我一般从 2e-5 开始试如果 loss 下降太慢再往上调。4.4 蒸馏效果的评估方法蒸馏完了怎么知道效果好不好不能只看 loss得看实际任务指标。我一般会做三组对比学生 vs 教师看学生能恢复到教师多少能力。一般能到 90% 以上就算成功。学生 vs 同规模从头训练的模型看蒸馏带来的增益。这个增益通常在 5 到 15 个百分点。学生 vs 学生不同蒸馏配置做消融实验看哪个参数最关键。评估集一定要用教师没见过的数据否则教师可能「背过答案」学生跟着学就虚高了。5. 蒸馏之外大模型能力迁移的几种路径蒸馏只是大模型能力迁移的一种方式。实际工程里还有几种常见路径我一起说了方便你根据场景选。5.1 微调最直接的领域适配微调是用领域数据继续训练预训练模型。和蒸馏的区别在于微调不涉及教师-学生框架就是拿一个现成模型接着训。微调的关键是数据质量。我见过太多团队数据量堆到几十万条但标注质量参差不齐训出来的模型还不如用几千条高质量数据微调的效果好。数据质量 数据数量这是铁律。微调还有个坑是灾难性遗忘。模型在学新任务的时候会把原来的通用能力忘掉。解决办法是混合训练把领域数据和一部分通用数据混在一起训比例大概是 1:1 到 1:3。5.2 提示工程不改变模型参数的轻量方案提示工程Prompt Engineering是通过设计输入提示来引导模型输出不改变模型参数。这是成本最低的方案适合快速验证场景。提示工程的核心是「把话说清楚」。我总结了一个模板角色 任务 约束 示例。比如你是一个专业的客服助手。请根据用户问题给出回答。 要求回答不超过 100 字语气友好不要编造信息。 示例 用户怎么退货 回答您可以在订单页面点击「申请退货」填写原因后提交我们会在 24 小时内处理。这个模板看起来简单但实际用起来效果比随便写一句「回答用户问题」好很多。5.3 RAG外挂知识库的方案RAGRetrieval-Augmented Generation是把外部知识库检索和模型生成结合起来。模型本身不记住知识而是在回答时实时检索相关文档把文档内容作为上下文喂给模型。RAG 的好处是知识可以随时更新不用重新训练模型。适合知识更新频繁的场景比如新闻问答、产品文档助手。RAG 的难点在检索质量。检索不准模型拿到的上下文就是错的回答自然好不了。我一般会用「向量检索 关键词检索」的混合方案向量检索负责语义匹配关键词检索负责精确匹配两者结合效果更稳。5.4 几种路径的对比与选型方案成本效果知识更新适用场景蒸馏中高需重训模型压缩、边缘部署微调中高高需重训领域适配、风格定制提示工程低中即时快速验证、通用任务RAG中中高即时知识密集、更新频繁选型逻辑很简单先看部署环境边缘设备优先蒸馏再看知识更新频率频繁更新优先 RAG最后看任务复杂度简单任务提示工程就够复杂任务上微调。6. 实操中踩过的坑与排查技巧这一节是我自己踩坑踩出来的经验文档里不会写但实际做的时候一定会遇到。6.1 蒸馏 loss 不下降的几种原因原因一温度 T 设错了。T 太小软标签退化成硬标签蒸馏退化成普通训练T 太大分布太平梯度信号太弱。解决办法是扫一遍 T看 loss 曲线。原因二教师模型本身不行。如果教师在自己任务上表现就一般那学生学到的也是半吊子。蒸馏之前先评估教师教师不行就先换教师。原因三alpha 权重失衡。alpha 太大学生完全跟着教师走忽略了真实标签alpha 太小蒸馏没起到作用。建议从 0.7 开始试。原因四学习率太大。软标签的梯度比硬标签柔和学习率大了容易震荡。把学习率降到 1e-5 试试。6.2 学生模型「学歪了」怎么办「学歪了」的表现是在训练集上 loss 很低但验证集上表现很差。这是过拟合的典型症状。解决办法有几个加数据最直接但成本高。加正则dropout、weight decay 都可以上。早停验证集 loss 不降了就停别硬训。数据增强对输入做扰动让模型学到更鲁棒的特征。我个人的经验是蒸馏场景下过拟合往往是因为训练数据太少。蒸馏的数据效率虽然比普通训练高但也不是万能的几千条数据想蒸出一个好模型不现实。6.3 部署时的性能优化蒸馏出来的模型最终是要部署的部署时的性能优化也很关键。量化把 float32 转成 int8模型体积缩小 4 倍推理速度提升 2 到 3 倍精度损失通常在 1% 以内。这是性价比最高的优化手段。算子融合把多个连续的操作合并成一个减少内存访问。比如 LayerNorm Linear 可以融合Attention 里的 QKV 计算可以融合。KV Cache自回归生成的时候把之前算过的 key 和 value 缓存起来避免重复计算。这是大模型推理的标配优化。批处理把多个请求攒在一起推理提高 GPU 利用率。但要注意延迟和吞吐的权衡batch 太大延迟会上去。6.4 常见问题速查表问题可能原因排查方向loss 不下降T 设置不当、学习率过大扫 T、降学习率验证集表现差过拟合、数据泄漏加正则、检查数据划分推理速度慢未量化、未用 KV Cache上量化、开 KV Cache输出重复解码策略问题调 repetition penalty显存不够batch 太大、序列太长减 batch、梯度累积7. 关于这场争议我的一些个人看法聊完技术回到标题里那件事。7 家中国公司被点名「蒸馏」这件事在行业里引起的讨论其实反映了一个更深层的问题大模型时代能力迁移的边界在哪里。我的看法是技术本身没有原罪。蒸馏、微调、RAG这些都是工具工具怎么用取决于人。用干净的数据、合规的方式做能力迁移这是正常的工程实践用别人的输出大规模训练竞品这就越界了。作为从业者我觉得有几条底线是必须守的第一数据来源要可追溯。你用的每一条训练数据来源是什么授权范围是什么心里要有数。别等到出事了才去查。第二尊重服务条款。用别人的 API就按别人的规则来。条款里写了不能训竞品那就别训。这不是技术问题是契约精神。第三评测要诚实。别往训练数据里掺评测集别在评测上做手脚。模型能力不行就承认回去继续优化别搞虚的。这场争议对行业来说未必是坏事。它让更多人开始关注数据合规、能力边界这些之前被忽视的问题。大模型行业要健康发展光靠技术突破不够还得有规则和共识。最后说个我自己的体会。做模型这些年我越来越觉得技术能力决定你能走多快但合规意识决定你能走多远。那些在数据来源上偷懒的团队短期可能跑得快但长期一定会付出代价。老老实实做数据、做标注、做合规慢是慢了点但走得稳。如果你也在做大模型相关的项目我的建议是把数据合规当成和模型效果同等重要的事情来抓。别等到被点名了才后悔。