别人看到你的数据不同体现在每个样本的生成方式上——好的蒸馏数据不是把论文题目灌进去就能跑出来的而是需要一整套“师生互动剧本”先由教师针对你的目标场景生成一批高质量答复再由你手工/规则筛选最后用模型自己生成的样本回炉。这批数据既要有覆盖面又不能全是高频任务。我习惯把一个任务的样本分成三块三分之一是教师直接从公开Benchmark里挑的高分答案三分之一是用不同Role Prompt让教师围绕同一知识点重新组织语言剩下三分之一故意在教师输出后拼接错误上下文用来考验学生模型在干扰下的稳定性。很多团队只保留教师答得漂亮的样本结果学生模型永远学不会“不完美输入下如何挣扎”的应对策略。比较意外的是蒸馏的收益对于“知识密集型”任务非常明显但让“推理密集型”任务真正受益的关键是提示模板而不是样本数量。你要教师用链式思考把整个分析过程写出来再让学生去学这个思考轨迹而不是只学最终结论。这也是很多人所谓“蒸馏失败”最常见的根源——你让学生从一段只有“是/否”的标签里学习推理怎么可能学得出推理能力所以我在准备训练数据时会强制把教师的完整推导过程保留下来哪怕是重复率极高的简单问题也不删。过程越长学生学到的内部思维协作就越深。3.2 三种常见的蒸馏损失配置数据准备好之后剩下的核心动作就是“让学生的输出分布靠近老师的输出分布”。经典的蒸馏损失通常包含两路一路是用teacher softmax概率做KL散度对齐另一路是直接用真实标签做交叉熵兜底。代码写出来大概是这样import torch import torch.nn.functional as F def distill_loss(student_logits, teacher_logits, labels, T4.0, alpha0.7): # 软化老师与学生输出 student_soft F.log_softmax(student_logits / T, dim-1) teacher_soft F.softmax(teacher_logits / T, dim-1) kl_loss F.kl_div(student_soft, teacher_soft, reductionbatchmean) * (T * T) # 硬标签交叉熵 ce_loss F.cross_entropy(student_logits, labels) return alpha * kl_loss (1 - alpha) * ce_loss这里温度T是个很有讲究的数字。T越小softmax就越接近one-hot学生基本只看到教师的最终答案T越大分布的尾巴越平学生能看到教师在错误答案之间微妙的犹豫程度。对于一般任务T4左右比较实用但对于代码生成这类正确答案基本唯一的场景T2甚至更低的温度反而更好因为你在乎的是确信的答案边界而不是想让学生学会无意义的犹豫。另一种更与现代LLM工作流匹配的蒸馏方式是让教师模型对同一组问题生成多个候选回复再让学生模型在这些候选回复间做对比学习。这种做法本质上把教师当成一个分布采样器输出的多样性本身就是训练信号。实测里多候选蒸馏对指令跟随能力的提升非常显著特别是对Prompt变化敏感的用户场景学生模型会从不同措辞里学会泛化而不是死记一个表面句式。至于蒸馏和微调在配置上的差别对比起来会非常直观对比维度直接微调蒸馏训练数据来源人工标注或原始语料教师模型生成/采样核心目标拟合真实标签拟合教师分布与标签两者对教师logits依赖不需要需要或间接需要算力成本相对低通常更高需跑教师推理输出风格可控性一般高度可控幻觉风险数据标注越好风险越低教师幻觉会直接传染典型应用领域适配、能力激活模型压缩、能力迁移3.3 训练参数里的软硬取舍蒸馏训练中另一个常见的坑是“软目标比例alpha”的选择。很多人一开始总喜欢把alpha设成0.9觉得向教师学得越多越好。实际训练时1.0的纯KL反而容易导致学生模型丢失对真实世界的常识判断——教师也会犯错特别是教师本身在长尾知识上是“自信地胡说”。我通常先跑一轮小实验alpha从0.5起步观察学生模型在硬性问答指标上的衰减速度再逐步提高软目标比例。如果某个领域你自己的标注数据本来就稀缺alpha高一些没关系但要是你有几千条高质量人工标注那硬标签交叉熵的权重要适当拉高。还要注意一点你的验证指标和蒸馏损失很可能不是同一个东西。你真正关心的是下游任务的准确率或用户满意度但训练时用的是KL散度。这两个目标并不完全一致所以训练中最常见的结果是KL一直在降但任务指标早就停止提升了。遇到这种情况别无脑加训先检查是否是温度偏高导致模型过度平滑把不同T、不同alpha的小批量实验跑一遍对比往往比你增加一倍训练步数更有效。4. 蒸馏和微调的边界感什么时候这是同一件事什么时候它们是两种活儿蒸馏和微调在工程上的边界越来越模糊但在讨论争议时大家容易把这两者混为一谈。事实是微调是“在已有模型基础上用特定语料继续训练”蒸馏则是“以另一个模型为主要监督信号来训练新模型”。它们的目标方向不同微调更接近于“给你装备新工具”蒸馏更接近于“请一位老师言传身教”。所以一个更准确的说法是你可以在蒸馏出来的学生模型上再做微调也可以在微调过程中加入教师分布约束那不是非此即彼的关系。从工作场景来看如果你的任务是让通用模型学会某个垂直领域的术语和格式直接微调就够了。因为你需要的是知识注入而不是换一种答题风格。比如做工业质检描述模型只要学会“划痕深度0.3mm属于缺陷品”的表达和判定标准直接微调几万条标注数据效果就非常好。但如果你想在10B的模型上复刻一个100B模型那种“有逼格”的回答方式比如能分步骤思考、遇到无法回答的问题能得体拒绝微调是办不到的——你应该用包含教师对复杂问题完整作答记录的语料去做蒸馏。还有一种很多人忽略的场景间接蒸馏。也就是你不直接拿教师的回答当目标而是拿一堆由教师生成的数据做清洗、改写再标注训练学生。这是实际工程里用得最多的手法因为它能把教师的“生物形态”洗掉一些让学生更像一个独立个体。著名的“用AI蒸馏一本书”就是这么个流程——先把一本书的目录拆成章节让教师模型基于每章节生成大量问答然后再用规则过滤掉重复、矛盾、超出原书范围的内容最后拿这些问答去训练小模型。这本质上是蒸馏但它已经被包装成“合成数据微调”。这也解释了为什么名单争议出来之后各家可以义正辞严地说“我们没有直接复制权重我们用的是自研语料”。可是从模型行为的角度看间接蒸馏反而更“伤”学生。因为数据经过多轮改写后学生的知识边界会崩得非常厉害——它可能把一个错误的事实学得非常坚定因为那份改写后的数据细节太逼真了。我见过有人在蒸馏医疗问答时跳过人工审核直接训练结果模型把教师幻觉里“某某药可用于某某疾病”当成金科玉律输出确定得让人害怕。所以请记住蒸馏会放大教师的盲区微调则至少能让你的标注人员把住最后一道关。实践中我的选型经验是如果预算允许尽量走“先蒸馏后微调”的两段式——先用教师数据训练出一个能力结构完整的学生再用自有的高质量标注把核心业务场景校准一遍。前者解决“会不会”后者解决“对不对”。很多团队想一步到位直接混合两种数据训练结果模型既没有完全继承教师风格又丢失了部分自有知识反而要返工。5. 嫌疑模型的“指纹”如何识别一个模型大概率蒸馏过聊完技术再回到名单事件本身。圈内人对名单还有一个非常关心的问题这些“蒸馏嫌疑”到底是怎么被看出来的虽然我们没有内部代码和训练日志但社区通常靠三类证据来推断一个模型是否经过蒸馏。这三类证据不是百分百实锤却足够引起注意。5.1 输出概率的尖峰与怪癖第一类证据藏在模型输出概率的特征里。一个真正从头训练的模型它对自己输出的置信度通常是“常态分布”的——有些问题很确定有些问题很犹豫整体概率不会全体压在某个奇怪的位置。但蒸馏出来的模型往往在两类问题上会暴露痕迹当问题与教师模型的高频训练主题重合时学生模型会非常明显地表现出“极度确信”的尖峰分布而且答案的结构和转折词风格几乎和教师一致遇到教师也拿不准的冷门问题时学生的输出概率又混乱得像随机噪声因为整个知识分布都是从教师那里复制来的教师没把握的地方传到学生手上就成了稀烂的一团。这就导致了一个有趣的现象蒸馏模型在某个领域内的答案质量非常稳定一旦跨界到教师不熟悉的领域立刻原形毕露。所以做模型评测时不要只跑那些公开Benchmark——那些题目往往早就被教师模型见过无数遍学生模型跟着占便宜。你要自己构造一批教师训练分布之外的冷门题看模型还能不能保持水准。这招说白了就是“考试时给同桌作弊遇到没复习过的综合题就会露馅”。第二种概率怪癖是答案模板的过度固化。教师模型经过指令对齐后往往形成一套固定的开头句式、递进指词和总结套路。学生蒸馏时为了降低Loss会把这种风格放大成一个更刻板的模板。比如教师可能有时说“首先”有时说“第一步”而学生在所有回答里都机械地用同一个词。这不是模型风格稳定这是学习数据里风格多样性不足的典型信号。你可以拿几百条输出做一次高频词汇统计如果连接词和引导语的重复率超过某个阈值蒸馏嫌疑就很高。5.2 长尾能力的消失与创造力的坍缩第二类证据没那么玄学直接看能力分布。蒸馏最容易被牺牲掉的就是长尾能力。一个大模型从头训练时会接触到天文数字的语料知识结构是千姿百态的蒸馏数据却只覆盖了你喂给教师的那些Prompt空间。所以学生模型的学习广度完全取决于数据构建者的策划能力。如果你让教师扮演“某个领域的专家”教师输出的样本通常会聚焦在几个高频问题上而真正冷门但同样合理的问题教师回答得少学生也就从未见过。最后模型给人的感觉就是它很懂但只懂你问它的那几类问题。这在业界有一个非常直观的表现同一个模型在通用榜单上的分数高得惊人但你拿一些非主流问题去问比如“明清时期江南的民间契约格式有哪些变体”或者“一部冷门电影的叙事结构分析”它可能瞬间退化成一个只会堆砌术语的空壳。因为教师模型自己也不是万能的学生模型把教师的这种局限性原封不动地继承了下来。用行话讲这叫“能力坍缩”。第三类证据是直接的文本重复。蒸馏的另一个常见副作用是学生会把训练数据中的高频段落背下来并在不同问题的回答里反复输出同一段内容。这不是像抄袭而是真的一字不差。我在实际排查模型时会特意把同一模型的几百条输出做两两相似度比较如果发现大量片段完全一致的输出——特别是那些逻辑通畅、措辞优美但与当前问题关系不大的长句——几乎可以断定模型从某种教师输出语料里学到了“缝合”习惯。5.3 社区里的“测谎”法到底靠不靠谱网上还有一种更业余的测法用某个模型生成的回答去问另一个模型让后者判断“这是不是你的输出”或者用困惑度去比较。说实话这些方法只能用于辅助根本谈不上证据。因为先不说开源模型的权重本身就是公开的很多团队的基座模型本来就是同一个开源检查点所谓“输出风格一致”只是正常亲缘关系。真正的社区测谎手段多半是找下毒样本——在教师训练数据里埋一批特殊指令让教师给出特定回答如果学生模型也能复现就能反向证明它用的是同一批数据训练。这类测试在近期风波中确实被大量使用了而且效果还很惊人因为一些被怀疑的模型没有完全清洗掉教师数据中的特殊标记痕迹。但从技术角度说这只能证明“训练数据里包含了教师的生成文本”不能证明“模型是偷偷蒸馏来的”。这个界限必须划清楚否则一顶帽子扣下来谁也受不了。6. 当我也把自己的模型蒸馏了一遍一些不吐不快的现实经验写了这么多理论最后想聊点更个人化的东西。作为一个从2023年就开始拿大模型输出回训小模型的实践者这几年的经历让我对蒸馏这件事又爱又怕。爱的是它确实解决了“小团队没有算力堆数据”的难题怕的是它留下的隐患往往要等到上线后才会集中爆发。第一个非常现实的体会是蒸馏不是一锤子买卖它是一个持续迭代过程。你蒸馏出来的学生模型上线后用户反馈会暴露它的大量短板你再拿着这些短板去问教师教师补数据再训练。循环往复你才能保持一个还不错的状态。很多公司被点名的模型之所以看起来“和某知名闭源模型高度相似”本质上是因为他们只做了第一轮蒸馏就匆忙发布没有追加打磨。但凡多迭代几轮模型风格早就被自家业务数据冲淡了也不会留下那么多刺眼的模板痕迹。第二个体会更难说出口越省力的方案越经不起放大镜观察。蒸馏的最快路径确实是拿教师的一批高质量输出堆在一起做监督训练。可这些高质量输出通常来自同一种Prompt模式最后的模型就像“一株嫁接在他人审美上的盆景”——远看很美近看全是问题。我自己后来改用了“老师带学生学生再教学生”的多轮流程先蒸馏第一版学生再拿第一版学生重新生成一批数据和教师数据按比例混合训练第二版。这样做出来的模型虽然部分能力弱于教师但风格上更自然、回答的上下文连贯性更扎实。虽然过程中需要多烧两倍算力但至少面对“这模型是抄的吧”的质疑时你能拿出一个属于自己的中间检查点。最后一个建议给所有正在做或准备做蒸馏的团队。无论你是出于隐私合规还是团队自尊心都别让你的蒸馏流程变成一个黑箱。我在自己项目的README里会明确写上“教师模型是什么”“合成数据怎么生成”“过滤规则是什么”。不是因为我想公开商业机密而是因为只有把过程记录下来未来出了问题你才能回溯到具体哪一步引入了教师的幻觉或偏见。这个习惯在我处理一次医疗问答模型的严重误答时直接帮我省下了两周的排查时间。更有意思的是当圈内散播“某某模型可疑”的消息时那些能公开交代训练过程的团队往往最不容易被点名因为他们的研发链路上有足够多的人工痕迹和检查节点别人一眼就能看出来这不是套壳。风波总会过去蒸馏作为一项技术也不会因为某次争议就从工具库里消失。它太高效、太省钱了任何做模型的人都抗拒不了这种性价比。但正因为如此我们才更要把蒸馏当成一个需要反复权衡的工程方案来对待——而不是一个可以用一行命令换来的“捷径”。技术在进步至于你是靠实力还是靠“借力”走到今天最终都会在模型的一举一动里留下痕迹。