最近和一位做模型部署的朋友聊天。他正在做的一件事是把一个大模型的推理能力“蒸”到一个更小的模型里换更低的服务成本和更快的响应速度。听起来很合理也很高效。但我问了他一个问题如果教师模型的能力上限摆在那里学生模型学得再好能不能超过老师他沉默了一下说正常情况下不能。这句话就是“蒸馏”这两个字最容易让人忽略的地方。过去几个月“蒸馏”在 AI 圈子里几乎成了万能词。学术论文里的知识蒸馏、工业界的模型蒸馏、智能体平台上的“蒸馏 skill”甚至还有人讨论“蒸馏一本书”来快速建知识库。好像任何能力都可以被“蒸”成一份可以复制的东西。但与此同时一个略显严肃的讨论也在流传——张一鸣为什么反对蒸馏不管这个说法是原话转述还是来自内部讨论的二手传播它作为一个公共话题能被反复提及本身就说明问题行业里有人对“蒸馏崇拜”产生了警觉。这篇文章不打算替任何人站台而是想把“反对蒸馏”这件事拆开看看看它背后的技术逻辑、商业逻辑和长期竞争逻辑到底在反对什么。1. 先搞清楚蒸馏到底在“转移”什么1.1 蒸馏不是复制而是知识迁移学术意义上的知识蒸馏Knowledge Distillation最早可以理解为一种“师生模型”机制。大模型教师在输出答案时不只是给一个正确答案还会给出在各类别上的概率分布。比如识别一张图片模型可能给“猫”打了 0.9给“豹子”打了 0.08给“狗”打了 0.02。学生模型学习的不仅仅是“这是猫”这个结论还学习教师模型那种“有点像豹子、不太像狗”的判断余量。这种软标签里包含的信息往往比一个硬性的正确结果更多。它反映的是教师模型在长年训练中形成的判断边界。学生模型通过拟合这些概率分布可以更快地学会教师的“手感”而不只是记住答案。到工业界“蒸馏”这个词被用得更泛。很多团队嘴上说的蒸馏其实就是调用一个强模型生成大量高质量问答数据再用这些数据去训练或微调一个更小的模型。这更像软标签蒸馏的“简化版”但是核心逻辑没变——把教师模型已经具备的能力迁移到学生模型上。所以理解蒸馏的第一步是知道它本质上是一种迁移。迁移意味着学生模型的起点是“别人的终点”。它能不能超过老师取决于你有没有额外注入新的数据、新的任务、新的反馈机制。如果没有那学生模型的天花板从一开始就被教师模型锁死了。1.2 为什么“蒸馏”会让人上瘾说“上瘾”可能有点重但确实每个环节都看起来太省事了。第一个诱惑是数据。训练一个强模型最难的不是模型结构而是数据。需要昂贵的人工标注、需要清洗、需要版权合规、需要大量试错。而蒸馏只需要一个已经训练好的教师模型让它开班授课一夜之间就能“生产”出海量数据。成本结构完全不同。第二个诱惑是部署。大模型动辄几百亿参数推理成本高、响应慢放到边缘设备上更不现实。蒸馏出一个几亿参数的小模型能力和大模型接近但成本可能下降一个数量级。这对线上服务来说是极具吸引力的。第三个诱惑是“能力复用”。在一些智能体平台和 skill 市场里“蒸馏 skill”已经变成一种玩法把一次成功执行任务的流程、提示词、工具调用方式沉淀下来让其他用户直接复用。这本质上也是一种蒸馏——它蒸馏的不是参数而是经验。这三个诱惑叠加在一起会让很多团队形成路径依赖遇到能力不够先想“能不能找个强模型蒸馏一下”遇到成本太高先想“能不能蒸一个小模型”。从短期效率看这无可厚非。但从长期能力积累看问题悄然埋下。1.3 蒸馏有一个容易被忽略的前提这里要先说清楚蒸馏不是万能的它有三个明显的边界。第一教师模型的错误会被“传承”。如果教师模型在某个领域有系统性偏差学生模型会把这些偏差当作正确答案学走而且因为学生模型能力更弱它甚至没有能力发现这些错误。第二学生模型不会凭空获得教师模型没有的信息。蒸馏是“重新排列和压缩”知识不是“无中生有创造”知识。教师模型不知道的东西学生模型也不会知道。第三模型输出的“毒性累积”。当一个行业里大量模型都是从一个或少数几个教师模型蒸馏而来那么这些模型在推理时产生的数据又可能成为下一代模型的训练数据。长此以往整个生态会逐渐趋同差异化和创新空间都会被压缩。这不是某个具体模型的问题而是整个信息生态的问题。2. 反对的不是技术而是“把所有希望寄托在别人的模型上”2.1 最直接的问题模型同质化如果一个行业里所有玩家都围绕同一个或少数几个教师模型做蒸馏会发生什么表面上看大家都有了自己的模型似乎是百花齐放。但打开模型一看风格、知识边界、错误模式甚至输出句式都像是同一个模子刻出来的。这不是夸张。蒸馏学习的是教师模型的概率分布概率分布里就包含了教师的语言风格、知识偏好、回答习惯。当整个行业的模型都共享同一个“教育背景”产品体验就会趋同用户在不同产品里得到的回答会越来越像。同质化的另一个风险是安全。如果所有下游模型都继承同一个教师的缺陷那么攻击者只需找到教师模型的一个弱点就等于同时攻破了数百个学生模型。这不是“多模型系统更安全”而是把鸡蛋放进了同一个篮子里。2.2 更现实的风险你被教师模型锁定蒸馏模型在设计时是省成本在运行时却可能带来隐性绑架。教师模型的 API 是别人管的。它涨价你的成本跟着涨它改变输出格式你的数据管道要跟着改它某一天把某些能力收回去你的模型能力池立即缩水。更麻烦的是如果教师模型背后的团队调整了对蒸馏行为的规则你的整个训练方案可能都要推翻重来。你蒸馏出来的学生模型看起来是你自己的但它能力的根长在别人的土壤里。这个道理做过依赖第三方服务的工程团队都会懂所有单点依赖最后都会变成事故点。2.3 为什么头部团队会更警觉如果站在头部大模型团队的视角看蒸馏还有另一层含义。对他们而言模型权重和推理输出是最核心的资产。如果竞争对手可以轻松调用你的模型用你的输出蒸馏出一个能力相近的新模型那么你投入巨额算力和数据建立的技术壁垒就被大幅削弱了。这不是说所有蒸馏行为都是恶意的但只要这种行为广泛存在就会改变行业的竞争结构。所以头部玩家反对蒸馏很容易被误解为“既得利益者为了护城河”。但从另一个角度看这种反对也是在保护一个行业的源头投入。如果大模型的价值像开源软件一样可以被任意复制那么谁还愿意承担最昂贵、最不确定的基础模型研发成本蒸馏的技术价值是高的但如果规则完全放开它对整个行业的创新供给会产生负向反馈。3. 从“蒸馏别人”到“被蒸馏”创新链条会变短3.1 蒸馏转移的是知识不是创造知识这是我认为最核心的一点。一个行业如果长期依赖蒸馏会形成一种“创新分工”少数玩家负责探索未知、训练基座模型大多数玩家负责蒸馏、落地、应用。这种分工看起来高效却暗藏风险——如果上游的探索变慢下游的蒸馏也会跟着变慢如果上游只有一家下游的所有玩家都会跟着这一家的路线走。更值得警惕的是蒸馏本身不会产生新的知识。它把教师模型已验证的知识迁移给学生但人类知识的边界并没有因此扩大。你在蒸馏一个模型时并没有学会如何解决新问题只是学会了如何更快地解决旧问题。对于一个需要在真实世界不断碰到新问题的产品团队来说这种能力积累是远远不够的。3.2 学术研究里的“模型坍缩”警告近年来学术界有一些关于“模型坍缩”Model Collapse的讨论。大意是当生成模型产出的数据越来越多地被用于训练下一代模型新的模型可能会逐渐丢失真实数据中的长尾信息最终变得单一、退化。这个讨论在实证上还有争议但它指出了一个重要的机制风险蒸馏也好合成数据也好本质上都是在让模型的“经验来源”越来越集中于模型自身。真实世界的多样性、偶发性、反常识并没有被充分注入。一个长期只吃模型数据的模型就像一个人只读自己写的日记能力会越来越闭环而不是越来越开阔。我不打算把“模型坍缩”当成一个已经被证实的事实但它作为一个风险提醒是足够有分量的。3.3 行业需要一个更良性的“知识回流”机制其实蒸馏本身并不必然导致创新枯竭。如果蒸馏是建立在海量真实数据、真实用户反馈和持续的新任务探索之上那么它可以是创新链条的一部分而不是替代品。真正危险的是“只蒸馏不建数据只管成本不管能力上限只追平别人不探索未知”。当一个行业里的大部分团队都把蒸馏当作首选路径而不是最后手段这个行业就很容易进入一种“集体抄近路”的状态。团队越抄越近能力越来越趋同而真正需要啃硬骨头的方向反而没人愿意去碰。4. 对普通开发者和 AI 应用团队来说蒸馏到底该怎么用4.1 适合蒸馏的场景蒸馏不是原罪。在以下场景里我甚至建议优先考虑蒸馏边缘端和低算力部署手机、嵌入式设备、本地私有化环境必须用小模型蒸馏是最务实的路径。任务边界明确的业务客服意图分类、内容安全审核、文档信息抽取这类任务场景稳定、范围窄、重复度高非常适合用小模型蒸馏后落地。快速验证产品需求在预算有限、时间紧的情况下用蒸馏方式快速得到一个 MVP可以有效验证业务假设避免一上来就投入大量训练资源。4.2 不适合蒸馏的场景反过来有些场景要谨慎你的核心竞争逻辑是“模型能力本身”。如果产品的壁垒就是“比别人聪明”那蒸馏出来的学生模型天花板有限很难建立长期优势。你的业务需要持续探索新问题。蒸馏模型擅长旧任务不擅长面对新问题。你需要的是持续的数据回流、任务扩展和推理能力升级而不是固定在一个教师模型的能力范围里。你的教师模型供应链不稳定。如果教师模型的提供方随时可能调整规则、价格或能力范围你的学生模型就有断粮风险。4.3 一个可复用的判断框架先跑通、再判断、最后再规模化我给团队的建议通常是这样一条路径第一步明确你蒸馏的目标。你是为了省成本还是为了获得能力还是为了快速试错这三个目标对应完全不同的技术路线。为省成本关键看压缩比和资源占用为获得能力关键看教师模型与学生模型之间的能力差距为快速试错关键是迭代速度和成本。第二步做小样本验证。先用几百条代表性样本跑一次完整的“教师产出—数据清洗—学生训练—效果评估”流程。这一步能暴露大多数问题教师输出格式不一致、数据质量不够、评估方式不准确等。不要一上来就大规模蒸馏否则你会在一个错误的方向上浪费大量算力。第三步建立长期监控。蒸馏模型上线后要持续记录错误率、输入分布漂移、异常响应。因为学生模型能力弱于教师很多问题不会立刻暴露而是随着业务数据变化逐渐显现。建议每两周做一次回归评估把新出现的长尾问题纳入下一轮训练数据。还有几个工程上的要点值得单独提醒。蒸馏数据的清洗往往比训练本身的收益更大。教师模型输出的数据里经常夹杂着幻觉、格式错误和重复内容直接拿去训练会放大这些问题。另外蒸馏时通常会用到温度参数来控制软标签的平滑程度温度越高学生模型学到的“判断模糊性”越多但这个参数不是越高越好需要结合具体任务调。不同版本的教师模型、训练框架和蒸馏工具参数含义和默认值差异很大落地前一定要确认依赖版本。4.4 蒸馏结果不如预期时先按这个顺序排查当学生模型的效果明显低于预期先别急着换模型结构或加大训练量。按照下面这个顺序走一遍大多数问题都能定位到。第一步看数据。先检查教师模型产出的原始数据有没有幻觉、格式不一致、重复样本、标签错误这些数据是学生模型唯一的“教材”教材有问题后面的训练再努力也是白费。第二步看分布。检查训练集的分布是否覆盖了真实业务输入。常见的问题是教师模型在生成数据时倾向于生成“简单问题”和“通用回答”导致学生模型在长尾场景上表现很差。这时要做的是补充真实业务样本而不是单纯增加合成数据量。第三步看参数。如果你用的是软标签蒸馏温度参数直接影响学习信号的平滑程度如果你用的是数据生成式蒸馏就要检查生成时的采样策略、最大长度、停止条件等。不同版本的工具默认值可能完全不同先确认版本再确认参数。第四步看评估。你用来对比教师模型和学生模型的评估集是否足够有代表性如果评估集本身就是合成数据那它只能说明学生模型“学会了合成数据的规律”不能说明它“具备真实场景能力”。建议在真实业务数据上建立一套独立评测集定期回归。这条链路的价值在于它把“效果不好”这个模糊的问题拆成了“数据、分布、参数、评估”四个可检查的环节。大多数蒸馏项目的问题都出在前两步而不是后两步。5. 回到那个问题反对蒸馏到底在反对什么5.1 反对的不是“蒸馏”是“只做蒸馏”我可以比较确定地说任何真正懂技术的从业者都不会反对蒸馏这个工具本身。它解决了很多真实工程问题是模型压缩、知识迁移、边缘部署的重要手段。真正值得反对的是把蒸馏当成通往行业终局的唯一路径。如果所有人都满足于蒸馏别人的模型没有人愿意做最上游的数据治理、预训练探索和评测体系建设那么这个行业的长期创新能力会被透支。一句话蒸馏适合“放大”能力不适合“创造”能力。5.2 对三类人的分别建议如果你是开发者可以放心使用蒸馏但不要混淆“蒸馏”和“自研”。你可以用蒸馏快速交付功能但要清楚自己的能力边界避免让产品成为教师模型的“同款平替”。如果你是创业者我建议把蒸馏当作“入场券”而不是“终点站”。用它快速验证产品和市场但一定要在业务运行中积累属于自己的用户反馈、真实数据和差异化场景。否则你会发现别人也能用同样的教师模型蒸出一个和你几乎一样的产品你的壁垒根本不存在。如果你是研究者我更希望你关注的是另一个问题蒸馏之后如何让学生模型具备超越教师模型的可能。比如加入新的任务目标、更强的人类反馈、更丰富的真实数据甚至让学生模型在推理过程中进行自我反思。这些方向才是真正让蒸馏从“复制”走向“进化”的关键。5.3 在行动之前先问自己三个问题我最近在做任何涉及蒸馏的决策时都会先问自己三个问题第一我的知识来源是什么是真实业务数据、用户反馈还是另一个模型的输出如果是后者我需要警惕它是否足够可靠、足够多样。第二我想达到的上限是什么我的目标只是追平教师模型还是想在某些场景下做得更好如果答案是“做得更好”我必须有额外的东西注入进去。第三如果我的教师模型明天突然消失我还能继续吗这个问题的答案决定了你是在做长期资产积累还是在做短期借用。这三个问题比任何参数调优都更能影响一个项目的长期走向。回到开头那个朋友的故事。他听完我的问题回去重做了蒸馏数据的构成加入了大量真实业务样本。几个月后再聊他说那版模型的错误率比最初版本低了不少而且开始在一些教师模型原本不擅长的细分话题上表现出更稳定的输出。那不是蒸馏的功劳而是他在蒸馏之外做了真正属于自己的事情。这大概才是“反对蒸馏”这个话题真正想告诉我们的工具可以用路要自己走。