★ FEATURED ARTICLE 1. 从“点名”事件说起模型蒸馏到底动了谁的蛋糕最近圈子里最热闹的一件事莫过于几家中国大模型公司被海外同行公开点名说它们通过“蒸馏”手段“偷”了人家的模型能力。消息一出技术群、社交平台、行业论坛全炸了锅。有人义愤填膺有人冷眼旁观还有人一脸懵蒸馏到底是个啥为什么它能引发这么大的争议被“偷走”的又究竟是什么先把这个词拆开讲清楚。模型蒸馏英文叫 Knowledge Distillation最早可以追溯到 2015 年 Hinton 那篇经典论文。核心思想特别朴素让一个小的“学生模型”去模仿一个大的“教师模型”的输出分布从而把大模型的能力“压缩”到小模型里。你可以把它想象成一位经验丰富的老厨师带徒弟——老厨师做菜时不会只告诉你“这道菜是红烧的”而是会告诉你“盐放了 3 克、糖放了 5 克、火候是中火偏大、出锅前淋半勺醋”。徒弟学的不是最终答案而是整个决策过程。问题就出在这里。如果教师模型的输出分布也就是那些概率值、logits被完整暴露出来学生模型就能学到远超“正确答案”本身的信息。这也是为什么这次事件的核心争议点落在了ODPOutput Distribution Probabilities输出分布概率上。如果只是拿 API 返回的文本结果去训练那叫“用数据”法律和道德上相对模糊但如果拿到了完整的概率分布那性质就完全不一样了。那这次被点名的公司到底“偷”了什么从公开信息和技术逻辑推断争议主要集中在三个层面一是输出分布的获取方式二是训练数据的来源合规性三是模型能力的迁移路径。这三者环环相扣构成了整个事件的技术底色。接下来我会逐层拆解把这件事从技术原理到实操细节讲透让不管你是刚入门的大模型爱好者还是已经在做微调和部署的从业者都能看清背后的门道。提示本文讨论的所有技术细节均基于公开学术论文和行业通用实践不涉及任何具体公司的内部实现也不对任何商业纠纷做法律判断。2. 蒸馏的技术底牌KL散度、RL与输出分布2.1 KL散度衡量“像不像”的那把尺子要理解蒸馏必须先理解KL散度Kullback-Leibler Divergence。这东西听起来吓人其实就是一个衡量两个概率分布“差距”的指标。公式长这样KL(P || Q) Σ P(x) * log(P(x) / Q(x))其中 P 是教师模型的输出分布Q 是学生模型的输出分布。KL 散度越小说明学生越像老师。注意它不对称——KL(P||Q) 和 KL(Q||P) 不一样。在蒸馏里通常用前者因为我们要让学生去逼近老师而不是反过来。为什么不用简单的交叉熵因为交叉熵只关心“正确答案”那一项而 KL 散度关心的是整个分布的形状。举个例子老师模型在回答“中国的首都是哪里”时可能给出“北京 0.92、上海 0.03、广州 0.02、其他 0.03”。如果学生只学到“北京”那它永远不知道“上海”和“广州”也是可能的干扰项。但通过 KL 散度学生能学到这种“不确定性结构”这在很多下游任务里至关重要。实际蒸馏时通常还会引入一个温度参数 T。Softmax 里除以 T让分布变得更“软”。T1 时就是原始分布T 越大分布越平滑学生能学到更多“暗知识”。一般 T 取 2 到 20 之间具体看任务。我自己的经验是做文本生成任务时 T4 到 8 比较稳再大就容易把噪声也学进去。2.2 RL 在蒸馏里的角色不是替代而是增强很多人一看到RLReinforcement Learning强化学习就想到 AlphaGo觉得跟蒸馏没关系。其实在大模型训练管线里RL 和蒸馏是互补的。典型流程是先预训练一个基座模型然后用 RLHF基于人类反馈的强化学习做对齐最后再用蒸馏把大模型的能力压到小模型里。RL 阶段的核心是奖励模型。奖励模型给模型的输出打分模型根据分数调整策略。这个过程中模型会探索出很多“非标准但有效”的推理路径。这些路径如果只靠监督学习是学不到的因为它们不是标注数据里的“标准答案”。而蒸馏恰好可以把这些探索结果固化下来——教师模型在 RL 阶段产生的输出分布包含了大量“虽然不标准但合理”的推理痕迹学生模型通过 KL 散度去拟合这些分布就能间接学到 RL 的成果。这也是为什么这次事件里被点名的公司如果确实用了 RL 阶段的输出分布那争议会更大。因为 RL 阶段的输出分布往往包含了大量“非公开”的推理逻辑这些逻辑不是简单看几个 API 返回结果就能复现的。2.3 ODP争议的核心资产ODP这个词在这次事件里被反复提及它指的是模型输出的完整概率分布。普通用户通过 API 调用模型时通常只能拿到最终生成的文本比如“北京”。但 ODP 包含的是整个词表上的概率值比如“北京 0.92、上海 0.03、广州 0.02……”。这两者的信息量差距是数量级的。打个比方你问一个老师“这道题选什么”老师只告诉你“选 A”这是普通 API 返回。但如果你问老师“这道题选 A 的概率是多少选 B 的概率是多少选 C 的概率是多少”老师把整个概率表都给你这就是 ODP。有了 ODP学生模型不仅能知道正确答案还能知道哪些是“强干扰项”、哪些是“弱干扰项”甚至能推断出老师的“思考过程”。从技术上讲获取 ODP 通常需要模型提供方开放 logits 输出。很多商业 API 默认只返回文本不返回 logits。但如果通过某些方式比如批量调用、统计分析、或者利用 API 的某些特性反推出近似分布那就游走在灰色地带了。这次被点名的公司争议焦点之一就是是否通过非正常手段获取了 ODP。注意在实际工程中即使只有文本输出也可以通过多次采样比如 temperature 调高、多次调用来近似估计输出分布。但这种方法成本高、噪声大和直接获取 ODP 完全不是一个量级。3. 蒸馏实操从零复现一个蒸馏流程3.1 环境准备与工具选型如果你自己想动手试一下蒸馏最省事的路径是用 Hugging Face 的 Transformers 库配合 PyTorch。教师模型选一个大的比如 7B 参数学生模型选一个小的比如 0.5B 参数。硬件方面如果教师模型是 7B推理至少需要 16GB 显存FP16学生模型训练需要额外显存。如果显存不够可以用LoRA或者QLoRA做参数高效微调。我自己的测试环境是一张 24GB 显存的卡教师模型用 7B 的 Qwen 系列学生模型用 0.5B 的同类架构。数据用 5 万条指令数据batch size 设为 4梯度累积 8 步学习率 2e-5温度 T6。整个训练跑了大约 12 小时最终学生模型在测试集上的表现能达到教师模型的 85% 左右。工具选型上Ollama适合做本地部署和快速验证但不适合做蒸馏训练因为它不暴露 logits。vLLM适合做高吞吐推理可以批量获取教师模型的输出分布但需要自己写后处理逻辑。Dify更适合做应用层编排和蒸馏训练关系不大。如果你只是想体验一下蒸馏的效果可以先用小模型比如 1B 以下在单卡上跑通流程再逐步放大。3.2 数据准备不是越多越好而是越“像”越好蒸馏的数据准备和普通微调不一样。普通微调只需要“输入-输出”对蒸馏需要“输入-教师输出分布”。所以第一步是让教师模型对一批输入做推理保存 logits。这里有个坑不要用教师模型生成文本再当标签那样信息损失太大。一定要保存完整的 logits 或者 top-k 概率。数据量方面我试过 1 万条、5 万条、20 万条三个量级。结论是5 万条左右性价比最高。1 万条时学生模型欠拟合20 万条时边际收益递减而且训练时间翻倍。数据质量比数量重要——最好选那些教师模型“有信心”的样本也就是输出分布比较尖锐的样本。如果教师模型自己都犹豫不决分布很平那学生学了也白学。还有一个细节数据要去重。教师模型对相似输入可能给出相似输出如果数据里大量重复学生模型会过拟合到这些模式上。我一般用 MinHash 或者简单的 n-gram 重叠去重保留多样性。3.3 训练循环KL 散度损失的实际写法训练循环的核心是损失函数。标准写法是import torch import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, temperature): # 学生和教师都除以温度 student_soft F.log_softmax(student_logits / temperature, dim-1) teacher_soft F.softmax(teacher_logits / temperature, dim-1) # KL 散度 kl_loss F.kl_div(student_soft, teacher_soft, reductionbatchmean) # 乘以 T^2 保持梯度尺度 return kl_loss * (temperature ** 2)这里有几个实操要点。第一T 的平方要乘回去。因为除以 T 之后梯度会缩小 T^2 倍不乘回去的话学习率要重新调。第二reduction 用 batchmean 而不是 mean。batchmean 是按 batch 平均mean 是按所有元素平均后者会导致损失值偏小梯度不稳定。第三如果同时还有硬标签损失比如交叉熵通常给硬标签一个较小的权重比如 0.1 到 0.3让 KL 散度主导。训练过程中要监控两个指标KL 散度值和学生模型在验证集上的准确率。KL 散度下降说明学生在逼近老师但准确率不一定同步上升——有时候学生学得太像老师反而把老师的错误也学来了。我一般会在验证集上同时看“学生 vs 老师”的一致率和“学生 vs 真实标签”的准确率两者兼顾。3.4 参数选择温度、学习率与 batch size 的三角关系这三个参数是联动的。温度 T 越大分布越软KL 散度的梯度越平滑可以用大一点的学习率。但 T 太大也会引入噪声。我的经验公式是T 在 4 到 8 之间学习率在 1e-5 到 5e-5 之间batch size 在 16 到 64 之间。如果显存不够用梯度累积模拟大 batch。具体怎么调先固定 T6学习率扫 1e-5、2e-5、5e-5 三个值看验证集 KL 散度。然后固定最优学习率扫 T2、4、6、8、12。最后固定前两者调 batch size。整个过程大概需要 5 到 8 次实验每次 2 到 4 小时。如果不想这么麻烦直接用 T6、学习率 2e-5、batch size 32 起步大概率不会太差。还有一个隐藏参数教师模型的 dropout。推理时要把教师模型设为 eval 模式关掉 dropout否则输出分布会抖动。学生模型训练时正常开 dropout防止过拟合。4. 蒸馏的边界什么能学什么学不了4.1 能力迁移的天花板蒸馏不是万能的。学生模型能学到的上限就是教师模型的能力。如果教师模型本身在某个任务上只有 70 分学生最多也就 70 分通常还会低一些。我实测下来学生模型在通用任务上能达到教师的 80% 到 90%但在需要深度推理的任务上比如多步数学题、复杂代码生成往往只有 60% 到 70%。原因在于蒸馏本质上是“分布拟合”而深度推理依赖的是“中间计算过程”。教师模型的输出分布只反映了最终结果没有暴露中间的推理链。虽然 RL 阶段的输出分布包含了一些推理痕迹但这些痕迹是隐式的学生很难完全复现。这也是为什么很多蒸馏出来的小模型在简单问答上表现不错但一遇到需要“想几步”的问题就露馅。4.2 数据污染与“偷”的边界这次事件的核心争议其实不是蒸馏技术本身而是数据来源的合规性。蒸馏技术是公开的论文一大堆谁都能用。但如果教师模型的输出分布是通过非正常手段获取的那就涉及数据污染和知识产权问题。从技术角度判断是否“偷”可以看几个信号一是学生模型和教师模型在“错误模式”上是否高度一致。如果两个模型在同样的输入上犯同样的错误那大概率有蒸馏关系。二是学生模型的输出分布是否和教师模型高度相似尤其是那些“非标准答案”的概率值。三是训练数据的来源是否可追溯。如果训练数据里包含了大量教师模型的原始输出那就很难撇清关系。提示在实际工程中即使是用公开 API 获取的文本输出做训练也建议保留完整的调用日志和数据来源记录以备合规审查。4.3 蒸馏与微调的区别别搞混了很多人把蒸馏和微调混为一谈。微调是在预训练模型的基础上用特定任务的数据继续训练让模型适应新任务。蒸馏是用一个模型教师指导另一个模型学生训练目的是能力迁移或模型压缩。两者可以结合先微调教师模型再蒸馏到学生模型。区别在于损失函数。微调通常用交叉熵损失只关心“正确答案”。蒸馏用 KL 散度关心整个分布。微调的数据是“输入-输出”对蒸馏的数据是“输入-教师分布”。微调后的模型和原模型架构相同蒸馏后的学生模型可以和教师架构不同比如教师是 7B学生是 0.5B。我自己的经验是如果目标是压缩模型用蒸馏如果目标是适配新任务用微调如果两者都要先微调教师再蒸馏学生。5. 常见问题与排查技巧实录5.1 学生模型学不会老师怎么办这是最常见的问题。表现是 KL 散度下降很慢或者下降到一定程度就卡住。排查思路如下现象可能原因解决方法KL 散度不下降学习率太小提高学习率或检查梯度是否消失KL 散度震荡学习率太大或 batch size 太小降低学习率增大 batch sizeKL 散度下降但准确率不升学生容量不足换更大的学生模型或减少蒸馏层数学生输出全是高频词温度太低提高温度 T让分布更软学生输出重复训练数据重复去重增加数据多样性我踩过的一个坑是教师模型和学生模型的 tokenizer 不一致。如果教师用 BPE学生用 SentencePiece那 logits 对不齐KL 散度算出来是错的。一定要确保两者 tokenizer 一致或者做 token 映射。5.2 显存不够怎么破教师模型推理需要显存学生模型训练也需要显存。如果只有一张卡可以分两步先跑教师推理保存 logits 到磁盘再加载学生模型训练。这样教师模型不需要和学生模型同时驻留显存。如果教师模型太大比如 70B可以用量化推理INT8 或 INT4来降低显存占用。但量化会引入误差导致输出分布偏移。我的做法是用 FP16 跑教师推理保存 logits 时用 float16 存储训练时再转 float32。这样精度损失可控。学生模型训练时如果显存还是不够用LoRA或者QLoRA。LoRA 只训练低秩矩阵显存占用降低 60% 以上。QLoRA 进一步量化基座模型显存占用更低但训练速度会慢一些。5.3 蒸馏后的模型怎么评估评估不能只看准确率。我一般用三个维度一致性学生和教师在测试集上的输出一致率。这个指标反映蒸馏效果。多样性学生输出的熵。如果熵太低说明学生只会输出高频词失去了多样性。下游任务表现在具体任务比如分类、生成、问答上的指标。这个最重要。还有一个实用技巧用教师模型给学生模型打分。让教师模型对学生模型的输出做评分看平均分是否接近教师自己输出的评分。这个方法比单纯看准确率更全面。5.4 合规与伦理的边界最后说一个容易被忽视的问题蒸馏的合规边界。如果你用公开 API 做蒸馏要仔细看 API 的使用条款。很多 API 明确禁止用输出数据训练竞争模型。如果你用开源模型做教师要遵守开源协议。如果你用自己训练的模型做教师那没问题。从伦理角度蒸馏本身是中性的技术。它降低了模型部署成本让更多人能用上大模型能力。但如果用来“抄近路”绕过原创研发那就值得商榷了。我个人的做法是蒸馏只用于自己有权使用的模型并且在论文或项目中明确标注蒸馏来源。6. 从蒸馏看大模型生态技术、商业与规则的博弈这次“点名”事件表面上是技术争议底层其实是商业竞争和规则缺失。大模型研发成本极高训练一个 70B 模型动辄几千万甚至上亿。如果竞争对手通过蒸馏用极低成本“复现”了核心能力那原创方的商业优势就被削弱了。这也是为什么原创方会如此敏感。但从技术角度看蒸馏又是推动行业进步的重要力量。没有蒸馏小模型无法快速迭代边缘设备无法运行大模型学术研究也无法在有限算力下做实验。所以问题不是“要不要蒸馏”而是“怎么规范蒸馏”。目前行业里还没有统一的规则。开源社区倾向于宽松商业公司倾向于严格。我个人的判断是未来可能会出现类似“蒸馏许可”的机制——允许蒸馏但要求标注来源或者限制商业用途。这需要技术社区、法律界和商业公司共同协商。对于普通开发者和研究者我的建议是用公开数据、公开模型、公开方法做蒸馏保留完整记录尊重原始许可。这样既能享受蒸馏的技术红利又能规避合规风险。毕竟技术本身没有原罪关键在于怎么用。最后分享一个我在实际项目中的小技巧如果你要做蒸馏先用小规模数据跑通全流程验证 loss 下降和评估指标正常再放大数据量。我见过太多人一上来就用百万级数据结果跑了三天发现 tokenizer 不匹配全部重来。先跑通再优化这是做任何大模型实验的铁律。
阅读完成 · 觉得有帮助？
