这两天大模型圈子里最热闹的话题莫过于一批中国团队被曝出用“蒸馏”的方式复刻了海外闭源模型。热搜词“大模型”和“蒸馏”绑在一起几乎刷屏了技术社区的首页。作为一个天天跟模型打交道的人我想先给个结论蒸馏本身一点都不神秘它就是 AI 圈用了快十年的标准技术动作真正值得掰扯的是“蒸馏到底从大模型身上拿走了什么以及哪些拿走的方式会踩线”。这篇文章我不点名、不站队就用从业者的视角把蒸馏的里里外外讲透——它是什么为什么大家都在做争议的焦点在哪以及如果你想合规地做一次蒸馏实操上该注意什么。这篇文章适合三类人看正在做垂直模型、私有化部署的工程师想搞懂“模型蒸馏”这个概念的产品经理或技术管理者以及单纯被热搜吊起胃口、想知道大模型行业在吵什么的围观群众。读完你会明白这几天刷屏的“偷模型”传闻本质上是技术、商业和合规三股力量撞在一起的结果。1. 先搞清楚蒸馏到底是个什么技术1.1 一个比喻老师解题学生学思路先抛开所有公式用一句话描述知识蒸馏Knowledge Distillation让一个能力很强但体型庞大的“教师模型”把自己解决问题的“思路”教给一个体型小巧的“学生模型”。这个比喻不是随便打的它精准对应着蒸馏的核心机制。教师模型不仅会给出最终答案还会给出每个候选答案的“信心程度”。比如你问它“苹果和梨哪个更甜”它不会只报一个“梨”而会给出类似“梨 80%、苹果 15%、不确定 5%”这样的分布。对普通用户来说这种分布是多余的但对学生模型来说这正是最珍贵的“解题思路”——它让学生知道在教师眼里苹果和梨并不是完全无关的两个类别它们在“甜度”这个维度上很接近。我做蒸馏项目时的感受是这就像老工程师带新人光告诉新人“最后用方案 B”是不够的得把“为什么不用方案 A、方案 C方案 B 的边界条件是什么”全讲一遍新人才会在遇到类似问题时自己举一反三。蒸馏里的“软标签”soft label就是教师的完整解题思路而“硬标签”hard label只是标准答案。需要强调的是这个技术早在 2015 年就被 Hinton 团队正式提出论文标题就叫《Distilling the Knowledge in a Neural Network》。它从一开始就是公开的、正大光明的学术方法用在模型压缩、边缘设备部署、移动端推理这些场景里完全是标准操作。所以“蒸馏”这个词本身不丑丑的从来不是技术是某些用法。1.2 从 logits 到软标签白盒、黑盒与温度要真正理解蒸馏得看懂模型最后那一层到底输出了什么。大模型在输出最终答案前会先产生一组称为 logits 的原始分数代表它对每个可能词或类别的“偏好程度”。这组分数经过 softmax 之类的归一化后才变成我们看到的概率。关键点来了直接用原始概率做软标签效果往往不好。原因在于模型训练得越好它对正确答案的置信度就越高其他类别的概率会被压到接近 0等于又把“软标签”变回了“硬标签”学生啥也学不到。这时候就需要一个“温度参数 T”来把分布“摊开”。T 的作用很直观T 越大概率分布越平坦那些原本被压到 0 的微小概率会被放大教师的“思考痕迹”就显形了。T 越小分布越尖锐越接近硬标签。实际操作中T 一般取 2 到 4 之间效果较好——温度太低学不到隐藏知识温度太高会把噪声也当知识学进去。如果按“能不能看到教师模型内部结构”来分蒸馏还能分成白盒蒸馏和黑盒蒸馏。白盒蒸馏能拿到教师模型的 logits、中间层特征甚至权重适用于开源模型黑盒蒸馏则是只调用 API把返回的文本或概率当作监督信号适用于闭源模型。最近被热议的“蒸馏事件”大部分发生在黑盒蒸馏的范畴——你拿不到对方的权重但你可以用对方的 API 批量生成数据再拿去训练一个小模型让它“神似”那个闭源大模型。1.3 别把蒸馏和微调、RAG 混为一谈很多人一看到“用 API 数据训练模型”就觉得是微调其实蒸馏和微调是两条不同的路。微调Fine-tuning是在已有模型基础上用标注好的业务数据去调整权重目标是把模型适配到特定领域模型本体的规模和能力边界基本不变。蒸馏的目标则是“缩小模型体积、保留能力”它关注的是模型之间的知识迁移。RAG检索增强生成就更好区分了——它根本不改模型权重而是在推理时先从外部知识库检索相关内容再拼进上下文让模型生成答案。RAG 解决的是“模型不知道”的问题蒸馏解决的是“模型太大用不起”的问题。我用一个表格把这几个概念摆在一起方便对比对比维度微调蒸馏RAG核心目标适配特定任务/领域压缩模型规模、迁移能力引入外部知识、减少幻觉是否改变权重是是学生模型单独训练否需要的数据领域标注数据教师模型的输出/软标签知识库文档模型规模基本不变明显缩小不变典型场景客服模型、法律模型端侧部署、低成本推理企业知识问答这个区分特别重要因为网上很多讨论把三者搅在一起仿佛任何“用大模型生成数据再训练小模型”的行为都是蒸馏。严格来说只有当你以“缩小模型、迁移教师泛化能力”为主要目标时的训练才叫蒸馏如果只是拿生成数据去做领域微调那叫合成数据微调技术上更接近微调。搞清概念才不会被热搜带偏。2. 为什么大家前赴后继做蒸馏成本与场景的双重驱动2.1 从头训一个大模型有多贵蒸馏有多便宜我先给一组让我自己都肉疼的估算。从头预训练一个千亿参数级别的大模型算力成本按当下的市场行情动辄是千万美元量级加上数据清洗、对齐、人类反馈强化学习RLHF这些环节总投入可能要翻两三倍。这不是普通公司能玩得起的游戏哪怕是融资充裕的明星创业公司烧完这笔钱也不一定训得出能打的模型。蒸馏的逻辑就完全不一样了。假设你调用市面上某个顶级大模型的 API每百万 token 收费几十块钱你用它的 API 批量生成几百万条高质量的指令问答数据总成本可能只需要几万到几十万元人民币。然后用这批数据去微调一个 7B 到 14B 的开源底座模型训练成本也就是几张 A100 跑几天的事。对预算有限的团队来说这条路的性价比高得不像话。我见过不少创业团队就是靠这个“API 生成数据 小模型微调”的组合拳在三四个月内做出一个垂直领域能打的模型。他们不关心这算不算蒸馏也不关心学术定义只关心一个事实用十分之一的成本拿到了一个“八成相似”的模型业务能跑起来客户愿意付费。这就是蒸馏在商业世界最原始的驱动力。2.2 蒸馏后的模型在真实业务里是什么体验光算成本还不够还得看蒸馏后的模型在实际部署中到底香不香。我自己做过一个项目教师模型是某个 100B 级别的闭源 API学生模型是蒸馏出来的 7B 开源底座。对比结果非常直观指标教师模型API 调用蒸馏后的学生模型本地部署参数量约 100B7B单次推理延迟秒级含网络请求百毫秒级显存需求无云端约 16GBINT8 量化后单次调用成本按 token 计费电费可忽略数据隐私数据出域完全本地能力对齐度100%约 80%-90%延迟从秒级降到百毫秒级这个体验差异是质的飞跃。做实时语音助手、客服机器人或者边缘设备上的智能应用时用户根本等不起一次 API 往返的几秒时间。而且本地部署意味着数据不用出域对金融、医疗、政务这些对数据合规极度敏感的行业来说这一步就是生死线。当然蒸馏后的模型不是没代价的。我实测下来学生模型在复杂推理、长文本理解和创造性写作上跟教师模型的差距会明显拉大。你让它写一段 500 字的行业分析它可能逻辑还算通顺你让它做一道需要用多个工具协作的复杂任务它就有点力不从心了。所以蒸馏更适合“任务聚焦、场景固定”的业务而不是指望它变成全能选手。2.3 免费 API 与“蒸馏一本书”需求端早就被点燃了再看热搜词里那些“免费大模型 API”“用 AI 蒸馏一本书”“大模型私有化部署”之类的词你就会发现需求端已经比学术界跑得更远了。现在市面上有不少免费或低价的模型 API很多人第一反应不是“拿来用”而是“拿来生成数据再训练我自己的模型”——这是很多开发者真实的心态恰好也是蒸馏争议的温床。“用 AI 蒸馏一本书”这个玩法也很有意思。传统想法是把一本书变成 RAG 知识库但蒸馏的思路是让大模型把整本书的内容读一遍然后用问答形式把它“消化”后的理解吐出来再用这些问答对去微调一个小模型。这样做出来的模型你看不到书原文但它回答问题时满嘴都是那本书的“味道”。我做过类似项目效果比 RAG 好在“不需要每次检索”坏在“容易把书里的错误也学进去”。多模态大模型也开始被盯上了。蒸馏文本模型已经不够有人开始蒸馏图文模型用 API 生成“图像 描述”的配对数据再去训练自己的小多模态模型。这个趋势一旦规模化技术争议会从文本扩展到图像、音频边界问题只会更复杂。3. 争议焦点被“点名”到底动了谁的奶酪3.1 真正被转移的是“概率分布”不是代码先说一个很多人误解的地方通过 API 做黑盒蒸馏根本拿不到对方的模型权重、结构或训练代码你能拿到的只有输出文本和概率。那“偷走”的到底是什么答案是概率分布背后的“行为模式”。教师模型在成千上万个问题上给出的回答风格、推理顺序、措辞习惯、对模糊问题的处理方式被完整地“压缩”进了学生模型的权重里。学生模型虽然没有复制代码却复刻了行为。这就好比一个厨师去餐厅吃饭尝遍了所有菜回家凭记忆和味觉把招牌菜复刻了个八九成——你说他偷了菜谱吗没有你说他偷了手艺吗说不清。这种“说不清”正是争议的核心。从知识产权角度看模型输出本身是否受版权保护全世界都还没有成熟判例。蒸馏出来的学生模型算侵权衍生品还是独立创作不同法域可能有完全不同的答案。我做技术多年最深的体会是技术问题往往有明确答案但法律问题经常没有——这也是为什么这类事件一旦被曝光大家只能靠舆论和商业手段来解决。3.2 服务条款、授权边界与商业护城河虽然法律模糊但商业规则其实很清晰。几乎所有头部闭源模型 API 的服务条款里都白纸黑字写着“不得使用服务输出训练竞争性模型”。也就是说哪怕蒸馏行为在法律上可能不构成侵权在合同层面也可能构成违约。被抓住之后轻则封号重则被起诉索赔。再说商业护城河。闭源厂商花了几十亿美金训练出来的模型如果被人用几百万的 API 调用费就“复制”走了核心能力那商业逻辑就崩了。所以你会发现头部厂商这两年做了很多防御性动作限制单账号调用频率、对异常请求模式进行风控、在模型输出里嵌入难以察觉的水印、甚至针对疑似批量生成数据的请求做降质响应。行业内有没有具体案例有但细节不适合展开说你只需要知道厂商和蒸馏者之间已经形成了一场“军备竞赛”。这里我必须强调一句我不站队。如果一家公司真的靠 API 蒸馏复刻了别人的闭源模型并商业化那合同的约束是真实存在的但从纯技术演进的角度看蒸馏又是整个行业都在用的正常方法。这两件事不矛盾只是很多人喜欢把它们搅在一起讨论。3.3 模型坍缩与生态多样性远虑比近忧更值得讨论比法律和商业更值得讨论的其实是“模型坍缩”Model Collapse这个长期问题。如果大量公司都不再训练自己的底座模型而是蒸馏少数几个顶级闭源模型会怎样想象一下全行业的学生模型都从三五个教师模型那里“继承”知识那么这几个教师的错误、偏见、盲区就会被批量复制。更糟糕的是当下一波蒸馏的数据源不再是人类文本而是这些学生模型生成的文本时误差会一级一级累积最终导致整个生态的能力塌方。学术界已经有人在研究这个现象结论并不乐观。还有就是创新动力的问题。如果蒸馏的性价比永远高于原创训练那理性的商业公司都会选择蒸馏愿意砸钱探索全新架构、全新训练范式的公司会越来越少。这对行业长期发展不是好事。不过我也不觉得这会导致行业停滞——历史上每一次“低成本抄袭路径”出现都会催生新的护城河比如更强的数据飞轮、更精细的领域适配、更极致的推理优化。4. 实操指南如何合规地做一次模型蒸馏4.1 一条完整的蒸馏流程从选老师到交作业批判了半天回归本质蒸馏技术本身是中性且高效的关键是“怎么合规地做”。我基于自己的项目经验整理出一条完整的蒸馏流程每一步都有明确的合规考量。第一步选教师模型。优先选择许可协议明确允许蒸馏和再创作的开源模型比如 Llama、Qwen、DeepSeek 等系列。虽然它们也是别人辛苦训练的成果但开源协议已经画好了红线你只要在红线内操作就没问题。如果确实要用闭源 API务必逐行读服务条款确认“用输出做模型训练”是否被允许。第二步构造任务数据集。用你自己的业务数据、用户脱敏日志、行业公开数据来构造指令集而不是直接抓取教师模型的问答库。这一条是很多翻车案例的根源——贪图省事直接把别人的对话记录拿来训练数据版权先出问题。第三步批量生成软标签。调用教师模型对每一道题生成带温度系数的响应并把 logits 或概率分布保存下来。如果你的教师是开源的这一步可以离线完成成本更低如果是闭源 API注意控制调用频率别触发风控。第四步清洗与过滤。这一步千万别省。蒸馏数据里常见的坑包括重复样本、低质量回答、中文语境下特有的“AI 味”套话、涉及隐私的文本残留。我一般会跑几道过滤程序文本去重、长度过滤、关键词黑名单过滤再加一轮人工抽检。第五步训练学生模型。用 KL 散度损失配合少量硬标签把软标签中的“教师思考痕迹”迁入学生模型。训练完成后用一套和训练集不重叠的评测集做对比看学生模型和教师模型的能力对齐度。第六步版本与合规记录。把教师模型版本、蒸馏数据来源、训练参数、许可协议截图都存好。万一有争议这套记录就是你自证清白的底线。我在团队里定过规矩没有合规记录的蒸馏模型不允许上生产环境。4.2 三个关键参数和一个损失函数蒸馏工程的成败很大程度取决于三个参数。第一是温度 T我之前提过取 2 到 4 比较合适但具体看任务分类任务可以稍低生成任务可以稍高。第二是损失权重 λ它控制“模仿教师”和“学习正确答案”之间的平衡一般从 0.5 起步如果学生模型学歪了就调低 λ 让硬标签多拉一拉。第三是学生模型的容量也就是参数量——7B 去学 100B 的知识本来就吃力别指望它能全覆盖要提前做好能力取舍。如果你想看具体的损失函数核心就是这一行loss CE(hard_labels, student_logits) lambda * T^2 * KL(soft_teacher_probs, soft_student_probs)其中T^2是为了平衡温度缩放带来的梯度量级变化工程实现时一定要记得乘上否则梯度会被压得太小训练半天没啥效果。这个细节我踩过坑一开始没乘 T^2蒸馏出来的模型表现得像没训练过一样。另外还有两个实战技巧。一是“温度退火”训练前期用较高的 T 让学生广泛学习训练后期把 T 降到接近 1让学生在精读标准答案的路上再走一段。二是数据混合软标签数据固然好但别完全丢掉硬标签数据按 7:3 或 8:2 的比例混合训练模型稳定性和准确率都会更好。4.3 决策清单你的场景到底值不值得蒸馏不是所有场景都适合蒸馏。我在动手前会先过一遍决策清单省得白费功夫你是不是需要降低推理成本如果业务量不大、API 费用能承受蒸馏的意义就小。你是不是需要本地化或私有化部署如果是蒸馏几乎是必经之路因为开源的通用小模型往往不够贴合业务。你的任务是不是足够聚焦蒸馏适合“垂直深耕”不适合“全能博学”。你手里有没有高质量的业务数据没有的话光靠教师模型的输出学生模型容易“知其然不知其所以然”。你有没有合规授权不管是开源协议还是商业合同先确认再动手。我建议头一次尝试的团队别上来就蒸馏 7B 或 13B先用 0.5B 到 1B 的小模型跑通全流程看看数据质量、训练稳定性、评测方法有没有问题。跑通了再放大规模成本可控心态也稳。5. 漫话式收个尾蒸馏背后的行业冷思考5.1 蒸馏会加速“大模型白菜价”吗我的判断是会而且已经在发生。蒸馏把“百亿级模型的能力”向“十亿级模型的成本”压缩等于把原本只有大厂用得起的智能批量发给了中小团队。这带来的直接后果是模型推理价格的持续下探以及垂直场景模型的快速普及。从产业分工来看行业正在分层少数几家巨头负责训练超大底座模型大多数公司则通过蒸馏、微调、RAG 等手段把底座模型变成各种行业解决方案。这不是坏事恰恰说明技术开始走向普及和实用化。但底层模型厂商也不会坐以待毙。他们会把重心从“卖 API 按 token 收费”转向“卖更深的模型能力 专属服务 数据飞轮”甚至开始提供官方蒸馏工具包把“蒸馏”变成一种可控制的增值服务。毕竟拦不住就别拦不如收编。5.2 未来的蒸馏一定是“看得见的蒸馏”最后说点前瞻性的。我觉得蒸馏这件事最终会走向“看得见的蒸馏”——模型卡片上会标注“基于哪个教师模型蒸馏而来”训练数据里会保留可信溯源信息评估报告里会把能力对齐度和授权情况写得明明白白。技术侧也会更成熟多教师蒸馏同时学多个大模型的优点、动态温度策略、蒸馏与 RAG 的结合、蒸馏与主动学习的结合都会成为新常态。治理侧的“数据水印”“分布指纹”这些技术也会逐步落地让模型能力的归属不再是糊涂账。我个人在实际操作中最大的体会是蒸馏模型的价值从来不只是“便宜替代”而是它逼着团队去思考一个极其本质的问题——你的业务到底需要模型的什么能力想清楚这个你才能在教师模型的能力图谱里精准地“切走”一块而不是一股脑地把人家的优点缺点全盘接收。最后再分享一个小技巧如果你要做蒸馏先从业务日志里挑 100 条最难的问题分别问教师模型和学生模型逐条对比回答质量。这个“百问对比法”比跑一堆标准指标更直观也更能说服你的老板或客户为这个方案买单。等技术成熟了、流程合规了你会发现蒸馏不过是一把好用的工具真正能决定你走多远的永远是数据、场景和判断力。