今天早上刷到“7家中国公司被点名‘蒸馏’”这条消息时我正在跑一个模型微调实验屏幕上的loss曲线刚降到0.4。“蒸馏”这个词在AI圈子里本来有正经的技术含义——知识蒸馏用大模型当老师教小模型是压缩模型的主流手段。可一旦和“被点名”“偷走”摆在一起味道就变了。大部分人第一反应是这些公司偷了别人的模型第二反应是蒸馏不是论文里天天写吗怎么就成了偷这两问其实指向了同一个要害同一个词在实验室里是中性技术在商业战场上却可能是侵权手段。被点名的7家公司具体做了什么现在流传的信息多半是转述和猜测我也没有办法把完整的名单和证据链贴出来给你看。但有一点毋庸置疑这则消息能炸出这么大的讨论恰恰说明“蒸馏”二字的模糊地带已经大到让整个行业不安了。所以这篇漫话不讲名单、不站队只想把三件事聊透蒸馏这项技术到底是怎么回事风波里的公司可能“偷”了什么以及我们这些天天跟大模型打交道的人怎么才能不稀里糊涂地踩进同一片泥潭里。1. 当“蒸馏”从实验室术语变成争议热搜词1.1 我最初看到“蒸馏”二字时的第一反应先说技术本尊。知识蒸馏是Hinton在2015年前后系统提出来的一套方法核心思路非常朴素大模型学得又准又稳小模型学不好那就让大模型出手“带”一下小模型。怎么带大模型在产出答案时不光给出最终答案还会给出每个候选词的概率分布。比如让一个大模型回答“中国的首都是哪里”它内部可能认为“北京”概率0.9“南京”概率0.05“另一个地方”概率0.02余下零星概率摊在别的词上。训练时不要求小模型只盯着正确答案“北京”学而是把大模型的完整概率分布也拿过来当“软标签”让小模型模仿那种“北京基本稳了但南京也没完全排除”的微妙判断。这里的关键参数叫温度T。温度越高概率分布越平滑把一个确定的答案摊开成“几成把握”的细节温度越低越接近“非黑即白”的硬标签。用小模型去拟合这种软化的判断往往比直接喂标准答案学得更快、更稳。打个生活化比方老师傅带徒弟如果只告诉徒弟“这个零件要磨到0.01毫米精度”徒弟得自己摸索很久但如果老师傅一边磨一边说“这里手感差一点点你听这个声音到八分火候了就别再用力”徒弟就容易上手。大模型当老师传的正是这种“手感层面的犹豫”。听上去蒸馏是一个纯技术、纯良性的词。我自己也做过不止一次模型压缩用7B的老师去教3B的学生效果好的时候能保留老师九成以上的能力推理成本直接腰斩。所以我看到“被点名蒸馏”时第一反应是愣了一下这年头做蒸馏也算违规了1.2 为什么一个技术名词会被当成“偷”的代名词答案在于技术本身无所谓好坏用在什么场景下才决定性质。实验室里的知识蒸馏用的是自己训练或者明确拿到授权的模型整个过程在学术框架内运行发论文、开源代码、复现实验规矩清清楚楚。可到了商业世界蒸馏有了另一种更灰色的含义——不是用大模型去“教”小模型而是用别人已经部署上线的商业大模型通过疯狂调用API批量获取它的输出再把这些输出积累成训练数据训练自己的模型甚至直接让自家产品在后台悄悄调用别人的模型冒充自研。这种方法在文献里通常叫模型提取攻击或者蒸馏攻击。它的本质是跳过正规授权渠道把别人的商用模型当成免费标注员和训练集生成器来用。这就能解释为什么“蒸馏”会从技术名词变成热搜词了。它像一把螺丝刀在螺丝拧紧的时候是好工具在撬别人门锁的时候就是作案工具。工具没变变的只是使用者有没有拿到许可以及使用者有没有在动作完成之后把原主人的痕迹擦掉。2. 大模型行业说的“偷”白嫖API产出的那一面2.1 用别人的模型生成数据再训练自己的模型界线在哪我知道很多读者会有一个困惑我每天都在调用大模型API让它帮我写文案、写代码、总结文档这算不算蒸馏如果是的话那几乎全行业都在“偷”了。这个界线问题恰恰是整场风波最核心的争议点也是被点名的公司最想辩解的地方。正常使用API本质上是一种消费行为。你出钱对方给你算力、给你模型推理结果一手交钱一手交货。这种使用方式有两个特征第一调用量符合一个正常产品的真实需求第二你拿到输出是为了直接使用而不是为了收集起来反哺另一个模型。蒸馏式滥用则是另一种模式。它的调用量往往异常——不是为了服务真实用户而是为了榨取覆盖各种边界情况的输出样本它的调用目标也是异常的——同一批问题会换个措辞反复问问出来的答案被按主题分类、清洗、去重再整理成训练集。更有甚者会把老师模型的输出连同用户的自定义指令一起存下来生成一批“用户提问标准回答”对拿去微调自己的模型。类比一下更清楚你偶尔请朋友去一家名店吃顿好的朋友觉得好吃回家自己学着做这是正常学习。但如果有人把名店的招牌菜买了几千份请化学工程师分析成分、研究火候、逆向配方然后在自家开一家几乎一模一样的新店这就不是“吃顿饭”能概括的事了。两者的本质区别不在行为本身而在两个环节数据来源是否经过授权以及最终去向是否构成对原模型商业价值的替代。只要这两条踩线哪怕是完全合法的公开API调用也可能被认定成侵权。2.2 这7家公司被点名的争议焦点大概率绕不开的三件事由于我手里并没有那份名单背后完整的证据链所以我不会在这里点名任何公司。讨论名单本身毫无意义过两天消息反转也不是没可能。真正值得关注的是这一类事件里反复出现的三种典型动作。第一种壳牌式套用。产品界面是自己做的品牌是自己起的底层引擎却是别人的模型用户提问被实时转发给上游大模型API答案回来后甚至不做任何改写就直接返回。这种情况下如果用户被告知“这是自研大模型”问题就非常严重了。这已经不只是蒸馏而是直接拿别人的模型当自己的产品卖。第二种数据飞轮式积累。通过合法渠道调用API把输出大规模沉淀成训练语料再从中蒸馏出自己的小模型。表面上每一笔调用都付了费没有违约但实际上是在用付费方式复制对方的模型能力等于花买一杯咖啡的钱搬走一整套咖啡配方。第三种能力冒充式宣传。不是直接侵权而是打擦边球。团队通过蒸馏模型做出了一个能力接近大厂旗舰模型的系统在对外宣传的时候把“接近”包装成“等同”把“借鉴”包装成“原创”让投资人、客户和用户产生误解以为他们从零训练出了一个超级模型。这三种动作单看任何一种行业内都能找到大量案例的模糊版本。但当它们被集中曝光、并被冠上“蒸馏”的名头时外界看到的就不再是技术细节而是一个信号监管方和行业生态对“借道”式做法容忍度正在快速降低。3. 他们到底“偷走”了什么拆开账本算一算3.1 第一笔账token费用与算力成本先算最直观的一笔账。被“偷”的一方损失最直接的是算力成本和API调用费的产生者。假设一个套壳问答产品每天有100万次请求每次请求的输出大约500个token。按常见商用模型API每百万输出token约15元的价格估算光是输出费用一天就是7500元加上输入token和上下文缓存一个月轻松超过30万元一年接近400万元。但这笔钱的去向很有意思花出去的钱是白嫖方付给API提供商的表面上没有亏欠。真正被“偷”的不是这笔服务费本身而是隐藏在其后的基础设施投入——训练这个模型烧掉的显卡、数据清洗的人力、算法调优的工程师时间以及为了支撑高并发而做的推理优化。API定价里只能收回一部分边际成本永远收不回模型研发的全部投入。如果白嫖方拿着这套模型和能力去融了资、发了产品、赚了钱这等于用对方几千万美元的研发成本换回自己几百万人民币的先发优势。这笔账越算越离谱。3.2 第二笔账数据质量和标注成本比算力更贵的是数据尤其是高质量的对齐数据。今天任何一个拿得出手的商用大模型都经历过一轮昂贵的数据清洗、人类偏好对齐、安全红队测试。模型在和你对话时能轻松说出“这个方案需要综合考虑成本、时间和质量”这种话背后可能是成百上千名标注员对无数条垃圾回答打过分、排过序。这些对齐经验是各家公司最大的商业秘密之一。蒸馏攻击相当于把这一整套对齐结果直接接管了。老师模型的回答已经是被调教好的“标准答案”白嫖方连标注员都不用雇直接拿这些答案当训练集。原来需要几百万标注预算才做得出来的SFT数据现在可能只需要几十万次API调用。更扎心的是老师模型还在持续进化每更新一次版本白嫖方就能蒸馏出更新的一批样本训练出来的学生模型几乎跟着老师一起进化。这种“借鸡生蛋”的效率让老老实实堆数据的团队显得像个苦力。3.3 第三笔账模型能力和商业化的时间差很多人忽略的是蒸馏偷走的最大东西其实是时间。从零训练一个大模型要多久算上数据收集、预训练、对齐、评测、迭代动辄一年起步稍有闪失就是推倒重来。而蒸馏一条路走通之后把老师模型的能力迁移到学生模型上从技术流程看可能只需要数周到数月。这意味着什么意味着被蒸馏方投入三年时间构建的技术护城河可能在一年内被对手用搬运的方式追上。护城河一旦失去效力后面所有基于模型能力的商业化计划都要重新估值融资节奏、产品路线图、团队招聘计划全部被打乱。对一个还在烧钱期的基础模型公司来说这是最致命的打击。你可以接受竞争但不能接受别人用你的肌肉和你打架。这也是为什么事件一曝光行业里愤怒的声音远远大于吃瓜的声音——大家都看到了自己未来可能面对的处境。3.4 最被低估的一笔账用户隐私与合规风险还有一笔账容易漏算而且一旦出事后果比前三笔加起来都严重用户数据。当一家产品被指控套用其他模型时用户的隐私边界瞬间就变得模糊了。用户在A产品里输入的个人信息、文档、聊天记录实际上被转交给了第三方大模型处理。用户以为自己在和一个独立产品对话实际上背后站着的是另一个公司甚至这个公司可能位于不同监管辖区。就算A公司声称对上游模型做了匿名化处理只要产品说明里没有向用户如实披露这本身就是合规瑕疵。更不用说如果上游模型服务商按服务条款有权留存和用输入数据做模型训练用户隐私就等于在两层机构之间被递来递去每一层的隐私保护承诺都要打上问号。很多卷入类似风波的团队前期注意力全放在模型效果上等到被质询时才意识到自己从来没认真看过上游API的服务条款也没跟法律顾问确认过用户数据流向。这口锅一旦扣下来不只是退款道歉这么简单可能整个产品的数据合规都要推倒重建。4. 知识蒸馏的合法玩法怎么“学”才不叫“偷”4.1 授权数据蒸馏与公开模型的正确姿势说到这儿一定会有人问那蒸馏还能不能做答案是能做而且应该做关键是你手里得有一张“合法入场券”。入场券通常有三种来源。第一种蒸馏自己训练或自己拥有完整权利的模型。内部部署一个大模型蒸馏出一个轻量版本供线上使用这是最无争议的做法。第二种蒸馏明确授权允许的公开模型比如一些公司会公开自己模型的logits和中间层输出并附带学术研究许可只要你的用途在许可范围内就可以。第三种用开源协议允许的模型做蒸馏但即使模型开源也要仔细看授权文件里是否允许将其输出用于训练其他模型别以为开源就等于全放开。这里我建议所有想动手的团队做一个简单自查拿出一张纸写下你的训练数据来源、蒸馏对象、用途范围然后逐条对照服务条款和开源协议。如果任何一条回答不上来就先停下来找法务不要急着跑实验。4.2 一个最小可复现的知识蒸馏流程伪代码为了让你更直观地理解知识蒸馏到底是什么操作我贴一段最简化的伪代码。在Hugging Face生态里核心流程大致长这样import torch import torch.nn.functional as F from transformers import AutoModelForCausalLM, AutoTokenizer teacher AutoModelForCausalLM.from_pretrained(big-teacher-model) student AutoModelForCausalLM.from_pretrained(small-student-model) tokenizer AutoTokenizer.from_pretrained(big-teacher-model) T 3.0 alpha 0.7 def distill_loss(teacher_logits, student_logits, labels): # 第一步用温度T软化两者的输出分布 teacher_soft F.softmax(teacher_logits / T, dim-1) student_log_soft F.log_softmax(student_logits / T, dim-1) # 第二步KL散度让学生的分布向老师靠拢乘T^2是为了缩放梯度的数量级 kd_loss F.kl_div(student_log_soft, teacher_soft, reductionbatchmean) * (T ** 2) # 第三步交叉熵让学生自己也能答对标准答案 ce_loss F.cross_entropy( student_logits.view(-1, student_logits.size(-1)), labels.view(-1), ignore_index-100 ) return alpha * kd_loss (1 - alpha) * ce_loss这段代码有两个容易踩坑的细节。第一老师模型和学生模型的词表大小必须一致或经过映射否则logits对不上蒸馏就无从谈起第二温度T和alpha两个超参数需要一起调T太低学生学不到老师的“犹豫感”T太高又会把答案信息全部摊平成噪声我的经验是先固定T在3到5之间再调alpha比两个一起动更容易找到手感。如果你用这套流程跑通了恭喜你你现在知道“蒸馏”本身有多无辜了——真正有问题的是那些把蒸馏用在没授权对象上的人。4.3 用AI蒸馏一本书怎么把长文本压成自己的知识库近期有一类需求特别火就是“用AI蒸馏一本书”。很多人想把几百万字的书“蒸馏”进自己本地部署的小模型里让模型能像一个读过那本书的人一样回答问题。这个思路我很欣赏但做法上有讲究。正确的操作路径大致是先把PDF或电子书转成纯文本按章节切成若干片段然后调用一个能力够强的模型逐段生成章节摘要、核心观点、关键人名和概念卡片以及一组“读者问答对”最后把这些结构化内容清洗、去重、检查错漏整理成标准的SFT格式数据用于微调一个小模型。简而言之学生模型学的不是原文而是老师模型对原文的“读书笔记”。这里特别提醒两点。第一不要未经授权就把整本书的原文灌进模型训练尤其不要指望模型输出时能逐字复述原文这既是技术上的幻觉风险也是内容版权上的红线。第二蒸馏出来的“读书笔记”无论多完美都夹带着老师模型的理解偏差建议保留原始章节编号方便随时溯源核对。用这个流程做出来的知识库实际效果会很接近你期待的样子模型知道“某本书里提到过某个概念”还会尝试用自己的话解释。而这个时候你就会发现蒸馏真正“偷”来的是老师模型的阅读能力而不是某本书本身。5. 事件之外我作为从业者重新校准的三个边界5.1 别把“能跑通”当成“可以上线”前面说了很多技术细节和行业分析最后聊点私货讲讲我自己在这件事里被震动到的三个瞬间。第一个瞬间是想起自己早先踩过的一个坑。当时我给一个小项目微调对话模型图省事直接从网上抓了一批“领域问答数据”其中有一部分明显来自某个商业模型的输出。模型跑起来效果挺惊艳我差点就部署上线了。后来整理数据溯源才发现那批数据里藏着一句模型提示词残留——那是某家商业API特有的格式。如果我当时真上线了今天被点名的名单里可能就有我。这件事给我的教训是模型效果跑通和训练数据合法合规永远是两回事。你要上线的任何模型都值得先问一句训练数据到底从哪来的每一行的来源都有凭证吗5.2 用别人的API先看清楚服务条款那几行小字第二个瞬间是我重新翻了一遍手头几个API服务条款。不翻不知道一翻吓一跳。很多大模型API的条款里都明确写了“不得使用输出内容训练与竞争性模型”“不得对模型输出进行系统性收集以构建数据集”之类的话只是它们藏在十几页法律文本的中后段平时根本没人注意到。我现在养成了一个习惯接入任何大模型API前把服务条款里关于data usage、model training、output ownership的段落单独截图存档然后跟法务或技术负责人明确项目边界。如果条款不允许我用输出微调模型那我就不碰这条线如果允许我也会把授权范围写到项目文档里避免团队里其他人顺手越界。5.3 做产品时把“数据血缘”当成一等公民第三个瞬间是靠数据血缘意识救了自己一次。现在我做任何一个涉及训练数据的项目都会顺手维护一份数据清单记清楚每条数据的来源、授权类型、收集时间、处理方式和合规责任人然后存成一张表类似这样数据来源授权方式用途限制负责人合规状态开源数据集AApache 2.0允许商用张工合规商业API输出B服务条款禁止训练模型仅用于线上推理李工禁止入训练集自采数据C用户授权协议仅限内部评测王工待法务复核这张表看着朴素但它在关键时刻能救命。一旦有人质疑你的模型数据有问题你能在十分钟内说清楚“哪些数据可以用、哪些不能用、用了会怎样”而不是慌乱地翻聊天记录和代码仓库。数据血缘意识的本质是把你对数据的信任从“感觉没问题”升级为“有据可查没问题”这是大模型时代工程师的基本职业素养。5.4 从这则热点到日常我给自己定的三条原则这则“7家中国公司被点名蒸馏”的新闻对我个人而言最大的价值是逼着我梳理出了一套日常行动的底线。第一条不蒸馏任何我没有确认授权的模型。哪怕对方是开源的我也会先看一眼授权文件里有没有关于模型输出训练的限制条款再决定是否动手。第二条产品层如实标注模型名称。我的产品用了哪个厂商的模型、哪个开源底座、哪个自研微调全部在文档里写清楚不给用户误判的空间。用户也许不在乎但我在乎——因为一句含糊的“自研大模型”就能让团队从一个技术问题滑向信任问题。第三条先想清楚“是否需要自研模型”再动手。需求真的简单到调API就能满足那就老老实实调API只有长期产品路线确实需要自有模型时才去规划自研、蒸馏、微调的路径。不是每条业务线都需要一个“自己的大模型”很多时候“调得好”比“自己做”更理性也更安全。写到这里那则热搜的热度已经退去大半但“蒸馏”这个词引发的思考不会褪色。它让我想起那句话技术本无罪但你的每一次调用、每一行训练日志、每一个上线开关都在替你的判断写下证词。希望我们在谈到“偷”这个词的时候心里都能坦然说一句我没有。