开头前阵子圈子里最热闹的讨论莫过于“7 家公司因为蒸馏大模型被点名”这则传闻。标题起得很吓人——“他们到底偷走了什么”好像有人把 OpenAI 的模型参数当罐头一样撬走了。但如果你在 AI 行业待过几年就知道“蒸馏”这个动作本身根本不是偷它是大模型领域最日常、最正当的一种技术操作。真正让这事值得聊的不是“偷不偷”而是蒸馏到底在做什么、为什么做这件事的公司这么多、以及这项技术背后有什么门道。这篇文章我打算用大白话把这件“被点名”的技术事件讲透。不管你是做产品、做算法还是刚入门想搞懂大模型产业链都可以跟着我把蒸馏这件事的来龙去脉、实操细节、常见坑位过一遍。我会讲清楚它的原理、流程、参数选择和最常见的翻车现场也会说几句我个人实操中的体会。蒸馏不是什么黑魔法它本质上跟“老教师带新学生”没什么两样只不过这位老教师肚子里装着几十亿甚至上千亿的参数。1. 模型蒸馏到底在干嘛——不只是“压缩”那么简单1.1 从教师-学生框架说起蒸馏技术真正流行的起点是 Hinton 他们在 2015 年前后提出的“知识蒸馏”概念核心结构就是“教师-学生”框架。用一个已经训练好的、规模很大的模型来当“老师”把它的预测结果转化成另一种形式的“教学信号”喂给一个规模小得多的“学生”模型去学习。这里有个特别容易误解的地方很多人以为蒸馏就是拿大模型的输出数据集去重新训练一个小模型然后把大模型扔了。实际上蒸馏的教学信号比普通标签数据集要细腻得多。普通训练里你给模型看一张猫的图片标签就是“猫”但大模型会输出一个概率分布比如“90% 是猫、5% 是狗、3% 是狐狸、2% 是兔子”。这个分布里其实藏了很多信息——它表明了猫和狗在视觉特征上有多接近猫和狐狸又有多接近。小模型在学习时如果只盯“猫”这个硬标签就丢失了这些复杂的“相似性知识”但如果连那 5% 的狗、3% 的狐狸也一起学它就学到了大模型经过千亿级数据训练后沉淀下来的“判断逻辑”而不只是一句标准答案。所以我在跟朋友解释这件事的时候老说蒸馏不是让学生抄老师的标准答案而是让学生坐在老师旁边观察老师面对一道题时脑子里怎么权衡、怎么排除干扰项最后再把这种“做题手感”迁移到自己身上。这也是蒸馏和单纯用 API 生成数据做微调之间最本质的区别。1.2 蒸馏偷走的到底是什么那新闻标题里问“他们到底偷走了什么”我按技术逻辑拆一下。如果一个团队拿另一个大模型的输出反复跑推理再用这些输出去训练自己的小模型他们实际上偷走的并不是模型的权重文件而是大模型在无数场景下的判断偏好。什么意思呢假设老师模型是 OpenAI 某个超大规模的 GPT它的训练数据来源、训练策略、RLHF 对齐方式都决定了它在复杂指令、风格化回答、安全对齐上的表现。它的输出里隐含着这些“不可见的工程配置”。学生模型不一定能完整复刻这种能力但如果蒸馏数据量足够大、覆盖面足够广学生模型确实能学到老师模型的不少行为模式。这也就是为什么一些公司宁可花大价钱调用别人的 API 跑数据也不愿从零开始攒预训练语料——因为后者的成本是天文数字前者的成本只是电费和 API 费用。当然这里也涉及一个灰色地带不同平台的服务条款对“用输出训练竞品模型”这件事有严格限制。但从技术本质上看蒸馏本身是中性的它跟用开源数据集训练模型一样是一个再普通不过的机器学习操作。问题的关键从来不是“蒸馏这个动作是否道德”而是“蒸馏的数据来源是否符合对方的使用条款”。2. 为什么大家都在“偷偷”蒸馏——算计力账和场景账2.1 算力成本差一个数量级我自己做过这种对比测试。用一张 A100 跑一个 7B 模型推理速度大概是每秒 40~60 个 token但要训练一个 7B 模型光预训练阶段就需要几十张甚至上百张卡跑几周。蒸馏呢你只需要一个“学会输出”的老师模型加上一个被训练的学生模型前者推理出足够多样的数据后者拿这些数据做微调。一个简单的账假设我要做一个中文客服垂直模型直接训练预算可能是千万级蒸馏一个同等水平的垂直模型可能只需要百万级甚至更低。差距的核心在于老师模型已经把“通用能力”都学会了你不需要从零训练那些基础能力你只需要让老师把它的“知识地图”复述一遍学生照着地图把局部区域描得更细就行。这也是为什么很多中小团队愿意做蒸馏。不蒸馏很多团队连入局的机会都没有。你不能一边要求行业百花齐放一边又要求每个团队都烧几个亿去预训练——这不现实。蒸馏在很大程度上降低了“做模型”的门槛。2.2 垂直场景要的是“小又快”不是“大而全”另一个让蒸馏变得刚需的原因是部署场景。你在手机端、边缘端、企业私有化环境里跑模型不可能每个地方都放一个几百 GB 的量化大模型。一是显存放不下二是延时受不了。比如一个智能客服系统用户等回复的容忍时间大概是 2~3 秒但一个 70B 模型在单卡上生成的响应时间可能直接飙到 10 秒以上。蒸馏一个 7B 甚至 3B 的模型效果在垂直领域内可以逼近大模型但推理成本、响应速度、部署难度都会友好很多。我见过不少企业的做法是先用商用大模型处理各个场景的 Prompt沉淀一批高质量问答对再拿这批数据蒸馏出一个私有化小模型放进内网。这几乎已经成了企业私有化大模型部署的标准动作。所以“7 家公司被点名”这件事背后反映的其实是行业当前的核心矛盾大模型能力很强但强不等于可落地蒸馏就是那个把“强”转化为“可用”的桥梁。只要这个矛盾存在蒸馏就会一直热门下去。3. 一次完整的蒸馏实操——关键参数与配置细节3.1 从选模型到定数据范围如果你要在大模型上做蒸馏第一步不是写代码而是先把教师模型和学生模型选好。教师模型决定了你的“天花板”学生模型决定了你的“成本下限”。教师模型怎么选有几个考虑维度它在你目标场景上的效果要足够好、它的接口要方便批量调用、它的输出要稳定。学生模型的选择上目前主流选项基本是 Llama 系列、Qwen 系列、Mistral 系列的 7B 或更小尺寸版本。尤其在做中文场景时Qwen 系列通常表现更稳。选好学生模型之后紧接着要考虑“蒸馏哪些能力”是对话能力、代码能力、还是特定领域的知识问答这个目标会直接决定你采集数据的 Prompt 分布。我自己习惯的做法是先在目标场景里人工写 300 条种子 Prompt涵盖简单问题、复杂问题、对抗性 Prompt、多轮对话四类然后基于这些种子 Prompt 做扩充比如换措辞、换名词、换条件约束再把扩充后的 Prompt 批量发给教师模型。这里有个容易被忽略的点——教师模型的采样参数需要调比如 temperature 别设太高否则输出过于发散学生会学到一堆不稳定行为也别设太低否则输出全是模板化套话。3.2 软标签与温度系数的门道蒸馏算法核心是计算损失时同时对比“硬标签”和“软标签”。硬标签就是标准答案软标签则是教师模型输出的概率分布。为了把教师的“软标签”调到一个比较合理的浓度Hinton 引入了一个叫温度Temperature的系数。温度高时概率分布变得平滑学生模型能看到更多“低概率但存在”的信息温度低时分布接近 one-hot学生模型又退回到只学硬标签的状态。实操中温度的选择要结合任务来分类任务通常用 2~4生成式任务常用 1~3。温度太高会让噪声变大温度太低又会让知识蒸馏退化成普通训练。我在做生成式蒸馏时基本会把 temperature 设在 1.5 左右然后对每个 Prompt 取 6~8 条教师输出每条的解码参数稍微做点波动再把它们的概率分布取平均作为软标签。这个操作在分类蒸馏场景特别有效在生成场景相对粗糙一些但在小模型上仍然能明显提升效果。3.3 离线蒸馏与在线蒸馏的选择蒸馏可以分成两种形态。第一种是离线蒸馏教师模型的输出提前一次性生成好存成数据集再拿去训练学生模型。这种方式实现简单、便于质量控制是大多数团队的首选。第二种是在线蒸馏学生模型每训练一步教师模型就实时推理一次把当前 batch 的软标签计算出来。在线蒸馏的好处是每次迭代都能让学生“看到”最新数据适合持续更新场景缺点是代价大——你必须在训练流程里挂一个高吞吐的推理服务工程复杂度立刻上升一个量级。对小团队而言我强烈建议先做离线蒸馏。先用脚本批量调用 API产出几十万条教师输出经过清洗和去重再进入训练环节。离线方案不仅可控性高还能让你在进入训练之前就对数据质量做一次全面体检。别一上来就搞在线蒸馏除非你的工程团队真的很闲。4. 数据清洗与质量控制的实战要点4.1 教师输出不是越多越好很多人拿到教师模型的输出后第一反应是“数据量越多越好”然后盲目扩到百万条。实际上蒸馏数据的质量权重远远大于数量权重。教师模型输出几十万条后你会发现里面掺杂着大量重复和模板化内容比如“作为一个人工智能我不能……”或者“根据您的问题我将从几个方面回答”这类空话。如果直接用这些数据训学生模型模型很容易变成“废话复读机”。我的经验是数据清洗至少要过三关。第一关是去重用 MinHash 或者 SimHash 做文本去重丢掉相似度超过 0.85 的样本第二关是关键信息完整性检测确保每条样本里都包含有实质内容的回答剔除空泛回答第三关是安全过滤去掉任何越界、敏感、低俗内容。清洗完之后你会发现百万条数据里真正能用的大概只有五六成这个比例非常正常。4.2 训练数据分布要贴近真实场景清洗数据只是第一步让数据分布贴近真实场景才是决定模型好坏的胜负手。你在设计 Prompt 时如果只写“如何、什么、为什么”这类开放式问题那么学生模型在真实对话中遇到指代不明的短句、口语化表达时表现往往会很拉胯。所以我建议在采集数据前先跑一遍“场景仿真”。你把自己想象成最终用户把用户可能问的各种角度、各种语气、各种错误拼写都写进去。比如做客服模型就多混入“我东西还没到”“你们怎么搞的”“我要投诉”这种情绪化表达如果做知识问答就宁可多覆盖“解释一下”“举个例子”“说人话”这类请求好让模型学会把复杂概念讲得容易懂。数据分布的广度很大程度上决定了学生模型的“泛化手感”。4.3 混合训练与普通语料的配比蒸馏数据虽然珍贵但也不太适合拿来“独养”一个模型。实操中我更推荐通过混合比例来调配。比如我用 60% 的蒸馏数据 30% 的通用 SFT 数据 10% 的纯文本数据用于保持模型的基础语言能力这个配比可以根据场景灵活调整。这里有个容易被忽视的坑蒸馏数据通常来自同一种 Prompt 分布如果比例过高学生模型会严重偏向教师模型的输出风格导致“路径依赖”一旦遇到分布外的输入就不知道怎么回答。混合通用 SFT 数据本质上是为了对抗这种分布坍缩。我自己做训练时会在训练过程中随机丢弃一部分蒸馏数据的标签只保留文本作为普通语料送进模型。这种“半监督”式的混用会让模型在完成目标任务的同时保留更宽的感知力。5. 蒸馏常见的翻车现场与排查思路5.1 学生模型训练后效果反而下降这是蒸馏失败最常见的情况。原因基本可以归为三类教师模型选择和场景不匹配、数据清洗不到位、训练参数设置不当。如果你发现学生模型蒸馏后效果不升反降先别急着折腾模型架构回头检查数据是最靠谱的方向。有一次我用一个大模型教师蒸馏一个 1.5B 的学生模型结果发现效果比直接用小模型微调还差。后来排查后发现教师模型在生成中文回答时习惯使用长尾词、复杂句1.5B 的学生模型根本“消化不动”这种表达形态。后来我把蒸馏数据的输出改为“简化模式”同时提高训练轮次效果才回来。蒸馏不是把大模型的风格全盘拷贝而是要找到一个学生模型能学的“可理解范围”。5.2 灾难性遗忘怎么处理小模型在做蒸馏微调时特别容易出现“灾难性遗忘”。就是模型在垂直领域表现变好之后把原来的通用能力忘光了甚至连基本的中文表达都变得奇怪。解决思路有这么几个一是蒸馏数据里混入一定比例的通用数据二是训练时保持较低的学习率比如 1e-5 到 2e-5三是用 LoRA 这类参数高效微调方式只更新部分参数。我个人在蒸馏场景几乎都会用 LoRA而不是全量微调因为它本身就能起到一定的防遗忘作用。在全量微调里你更新全部参数模型会朝训练分布大幅偏移LoRA 只是在你选定的低秩子空间里做修改更容易保持原有基础。5.3 如何评估蒸馏后的模型效果最后聊一下评估。蒸馏模型的评估不能只看一个分数我会构建一个三层测试集第一层是训练集分布内测试集验证模型是否学会了“照猫画虎”第二层是分布语义相似但措辞完全不同的测试集验证模型有没有真正学到“能力”第三层是随机业务场景的对抗性测试集验证模型是不是只会背答案。这个三层评估的思路我建议所有做蒸馏的人直接抄作业。单一测试集分数高没有任何意义因为你很可能只是过拟合了教师的输出风格。只有三层测试都过了小模型才真正算是一个“能打”的模型。关于模型蒸馏这件事我自己的态度一直是它是当前大模型技术应用里最被低估的工程杠杆之一。算力预算有限的团队靠它落地产品团队靠它实现私有化个人开发者靠它跑通“先用好模型造数据再做自己的小模型”的完整链路。只是大家在学这项技术时别只盯着“谁被点名了”的新闻找乐子多花点时间研究数据清洗和软标签的细节少踩几个我踩过的坑这会比任何八卦都更有收益。