前阵子“7家中国公司被点名蒸馏”这事在AI圈子里炸得不轻。我在好几个技术群和行业群里看着大家从“到底算不算偷”吵到“蒸馏和微调到底有什么区别”最后谁也没说服谁。作为一个从深度学习时代做过来、这几年一直扑在大模型工程化落地的从业者我觉得这话题里有很多被情绪掩盖的技术真相。与其跟着舆论起哄不如把蒸馏这件事的技术本质拆开看看被点名的公司到底从别人的模型里“拿走了什么”以及这个“拿走”跟大多数人理解的“抄作业”相差多远。先摆一个基本事实知识蒸馏Knowledge Distillation不是新鲜事更不是哪家公司的“发明”。2015年Hinton团队那篇《Distilling the Knowledge in a Neural Network》算给这个技术定了调子。它的初衷很朴素——把一个大而强的模型“教”出来的知识压缩转移到一个更小的模型里让小模型在资源受限的场景下也能贴近大模型的水平。当年大家讨论的是模型压缩、端侧部署这类纯工程问题谁也没想到若干年后它会变成大模型行业里一个充满火药味的词。这篇文章我想做的是把蒸馏从原理讲到实操再从实操讲到争议最后落到“被点名的公司到底偷走了什么”这个问题上。不管你是做算法的、做产品的还是吃瓜的看完应该都能对这场风波有一个比“谁偷了谁”更立体的判断。1. 模型蒸馏到底是个什么技术1.1 老师教学生软化标签与温度参数知识蒸馏字面意思就挺形象大模型当老师小模型当学生。老师把自己学到的知识通过“输出行为”传递给学生。这里面最关键的机制叫软化标签soft label。正常训练一个分类模型用的标签是硬标签hard label。比如一张图是猫标签就是[0, 1]是狗就是[0, 1]的镜像。但蒸馏训练用的目标不是原始硬标签而是老师模型输出的概率分布。大模型看到一张图可能给出[0.7, 0.2, 0.1]——它有70%的把握是猫20%觉得像狗10%觉得可能是狐狸。这个分布里藏着的就是大模型的“知识”。为什么要用软标签因为硬标签丢信息。一张“像猫的猫”和一张“极像猫的猫”在硬标签里都是猫但它们的“猫度”完全不同。这种细微差异恰恰是知识里最值钱的部分——它反映了概念之间的边界和模糊地带。小模型通过模仿这个分布学到的就不光是“这张图是猫”而是大模型对“猫”这个概念的全部理解和判断方式。这里有个温度参数T是蒸馏里最核心的超参数。把老师的logits除以T再做softmax就得到了更平滑的概率分布。T越高分布越均匀暗知识暴露得越充分T过低分布趋于尖锐跟硬标签差不多蒸馏就失去意义。实践中T一般取2到8之间具体要结合任务难度和模型规模反复试。我见过T2.5在中文分类任务上效果很好也见过T6在生成任务上才够平滑这东西没有银弹。1.2 大模型时代蒸馏的三种变体等到了大模型时代蒸馏这个概念被大幅扩展了。传统蒸馏蒸馏的是分类概率分布现在蒸馏的对象宽得多第一种是序列级蒸馏针对生成任务。老师模型对下一个token的预测分布不光是答案本身还包括它的“犹豫程度”。比如写代码时模型在“for循环”和“while循环”之间给的分布权重就是它纠结过程的体现学生模型把这个也学过来行为就更像老师。第二种是特征级蒸馏让学生的中间层特征去对齐老师的中间层特征。这种办法常见于多模态模型或者深度很大的网络因为光靠输出层对齐信息损耗太大中间层能保留更多层次化特征。第三种是轨迹蒸馏学的是老师的“思考过程”。让老师模型在生成答案前先输出推理链CoT学生模型连这条思维链一起学。2023年以后很多开源模型的效果提升靠的就是把大模型的CoT能力蒸馏进小参数模型里让7B模型也能做一些“一步一步推理”的事。你在行业里听到的“模型蒸馏”大部分指一种更粗放的用法调用一个强模型比如闭源大模型的API批量生成问答数据再用这些数据去训练或微调自己的小模型。这种方式在技术圈有个更直白的叫法——合成数据训练。后面那场争议的核心说被点名的公司“用API薅大模型答案拿去练自己的模型”指的基本就是这种做法。2. 被点名的公司到底“拿走”了什么2.1 知识还是数据一个关键辨析现在到了核心问题蒸馏到底从大模型里拿走了什么“偷走”是很重的词得先看清楚技术层面到底发生了什么。想象你是家公司想做一个擅长中文、会写代码、能处理复杂逻辑的助手模型。有两条路摆在面前。第一条自己从零开始收集数据、清洗、预训练。这不只是钱的问题——需要的算力如果你不是拥有上万张GPU的云计算巨头基本走不通。预训练一份高质量大模型硬件成本动辄上千万美元还不算数据清理、工程调优、实验验证的时间成本。更现实的问题是最优质的数据往往集中在巨头手里你根本拿不到同级别的语料。第二条调用现有强模型的API把你关心的场景问题批量喂给它把它的回答记录下来形成一份高质量问答对数据集再用这份数据微调一个开源底座模型比如Llama、Qwen、Mistral。这条路成本低得多可能只要几万美元的API费用加几张训练卡就能得到一个在特定任务上表现不错的模型。这两条路之间的差距说白了就是“造轮子”和“抄作业”的差距。被点名的公司有没有真的抄作业可以交给监管去裁决但技术路径上“问答对蒸馏”是真实存在且被广泛使用的。问题的关键在于抄到什么程度算抄大模型生成的回答本身是否构成可以主张权利的“东西”这是个很微妙的问题。从纯技术上讲蒸馏拿走的是大模型的“行为模式”——面对什么输入会输出什么回应。本质上更像一种模仿而不是复制。你没有把老师模型的权重压缩进zip拷贝走也没有把它的原始训练数据原样搬走至少常规蒸馏流程不会你拿走的是它输出行为的大量样本。但只要你问得足够多、问得足够刁钻理论上确实可以从大模型身上“提取”出很多远超正常对话范畴的东西——包括训练数据里出现过的具体文字甚至通过精心设计的prompt诱导它泄露内部指令和安全策略。这也是为什么很多闭源模型服务条款里都明确禁止批量抓取输出用于训练竞品模型。所以你说蒸馏完全没有“拿走”什么那也不对——它拿走的是行为模式有些行为模式确实具有商业价值。2.2 行业里三种蒸馏做法的合规底色抛开争论我聊聊实际操作中蒸馏是怎么做的以及每种做法的合规风险到底在哪。第一种做法我开玩笑叫“白嫖型”直接调用API把目标场景的prompt批量发给老师模型收集输出。这里有个行业里心照不宣的细节——很多团队会在prompt里故意加一句“不要提到你是AI”或者要求“以资深专家的口吻回答”目的就是让生成的数据看起来更像人类写的标注数据减少被检查出来的概率。这就是典型的灰色操作了。第二种是“合规型”使用明确开放了训练使用权限的模型。比如有些API服务商在付费条款里白纸黑字写明“输出可用于训练”或者直接使用没有任何限制的开源模型。选择这种路径的公司哪怕是用了蒸馏法律层面也站得住脚怎么说都有底气。第三种是“混合型”用大模型生成初稿再让人类专家清洗、校验、改写。这种模式介于两者之间既用了老师模型的知识又注入了人力加工。不少公司对外解释时都强调自己走的是这条路——“我们不是单纯复制我们做了大量人工加工”。这话半真半假人工整理环节确实存在但整体的数据底座还是蒸馏出来的。我自己的判断是技术本身中立但手段并不都中立。蒸馏作为一种科学方法、一种合理的技术路径没有任何问题。被点名的公司争议点在于如果是在服务条款明确禁止的情况下把闭源模型的输出当成流水线原料大规模、批量化地训练竞品模型那说它是“偷”可能有点情绪化但至少不能轻飘飘一句“技术进步”就带过去。2.3 怎么识别一个模型可能是蒸馏出来的这个角度挺有意思也是圈内人经常私下讨论的。虽然公司不会承认自己用了蒸馏但模型的行为会“露馅”。最常见的痕迹是“口癖传染”。如果你的小模型在回答风格上跟某个闭源大模型过于相似——比如相同的开场白方式、相同的过渡词习惯、甚至相同的道歉句式那大概率是蒸馏出来的。正常从零训练的模型不会有这些细碎的语言习惯因为它们的训练数据来源不同语料分布是不同的。我见过一个开源模型几乎所有回答都带着某个闭源模型特有的“严谨但啰嗦”的叙事节奏明眼人一看就知道是蒸馏的产物。第二类痕迹是“知识边界一致”。大模型的知识截止日期是有限的蒸馏出来的学生模型会把老师模型的知识截止日期原封不动继承下来。比如老师模型不知道2025年的某事件学生模型也不知道如果你发现一个模型对具体时间的“未知边界”跟某个闭源模型完全重合这基本就是蒸馏的证据。第三类更硬核叫“成员推断攻击”。你可以测试性地构造一些非常特定的prompt看两个模型的输出分布是否高度一致。如果学生模型和老师模型在一个高风险、高复杂度的问题上的答案分布达到了接近的程度这在统计上是很难用巧合解释的。业内有些团队专门做这种溯源分析甚至可以通过对比embedding相似度来估计两个模型之间的蒸馏血缘关系。这些技术手段虽然不完全严谨但足够给行业和监管提供调查方向了。3. 蒸馏的实操路径从一个真实项目说起3.1 数据构建prompt设计决定蒸馏质量聊完争议回到地上。去年我帮一家客服公司做了一个垂直领域问答模型底座用Llama 2 7B任务是处理保险条款咨询。这个项目基本走的就是蒸馏路线我把整个过程分享出来给想做蒸馏的同行一个参考。第一步是构建训练集。我们收集了大约1万条真实业务场景下的脱敏用户问题然后调用一个强模型来生成标准回答。prompt大概长这样系统提示词你是保险领域的资深客服专家请基于以下真实业务场景回答用户问题。要求准确、有条理不使用“作为AI”之类表述。回答控制在200字以内涉及具体条款时优先引用条款编号。注意几个细节。第一温度参数设到了0.2宁可损失一点多样性也要保证数据质量稳定。蒸馏数据不需要老师发挥创造力需要的是老师稳定输出一个能复现的标准答案。第二所有回答都要求结构化——先给结论再列依据最后给行动建议。格式统一的数据后面训练时会省很多心。第三我们让老师模型先输出“你是如何理解这个问题的”也就是思考过程再给最终答案。后来评测发现把思考过程一起蒸馏进学生模型模型在复杂条款问题上的表现明显更好。这1万条问题我们分了三批生成每批间隔做了人工抽检抽了大概200条发现准确率不达标就调prompt重新跑。最终产出的数据集人工校验通过率在93%左右剩下的7%主要是不够具体或者语气太AI化重新生成或者人工改写。3.2 微调配置LoRA参数与训练细节第二步是微调底座模型。训练参数我直接给配置训练框架transformers peft方法LoRA秩r16alpha32学习率2e-4cosine调度warmup 5%batch size16梯度累积到16训练轮数3轮上下文长度2048目标模块q_proj、v_proj、k_proj、o_proj、gate_proj、up_proj、down_proj为什么要用LoRA而不是全参微调两个原因。第一7B模型全参微调要8张A100才跑得舒服LoRA单张A100就能跑成本差一个数量级。第二LoRA微调后模型在通用能力上的退化明显更小做垂直蒸馏这个特性尤为重要——你要的是在特定领域变强而不是变成只懂保险的“偏科生”。LoRA秩的选择上我试过r8、16、32。r8时领域知识学习得不够充分术语准确性明显差一些r32时训练时间涨了但没带来等比例的效果提升。最后定在r16是性价比最合适的点。alpha取32是因为官方推荐把alpha设为r的两倍能减缓更新幅度过大导致的输出坍缩。训练过程里还有个容易忽略的细节数据混合比例。我们用90%的蒸馏问答数据加上10%的通用数据从开源指令数据集里采样防止模型在垂直领域过度拟合后完全丢掉通用能力。这个比例我试过95:5和80:2090:10效果最平衡——既能把领域能力拉到最高又能保住模型说人话的基本功。3轮训练大概花了4个小时单张A100显存占用42GB左右。如果你的显存不够把batch size降到8梯度累积保持住效果不会有明显变化。3.3 效果对比与成本核算训练完我们组了一个1000条真实用户问题的评估集对比了几个版本的效果模型版本答非所问率术语准确率用户满意度1-5分原版Llama 2 7B40.2%61.3%2.8蒸馏后LoRA微调8.6%84.5%4.1纯人工标注数据训练9.1%85.2%4.2蒸馏效果和纯人工标注训练几乎持平但差距在成本上。人工标注1万条高质量客服问答按平均每条3块钱算成本3万块还得等标注团队排期两周。蒸馏方案呢API生成1万条问答大概消耗2500万token按当时的计费折合不到2000块钱生成耗时一个晚上。就算加上人工抽检、清洗、改写的半天工作量总成本也不到人工标注的十分之一。这个差距就是蒸馏在行业中如此流行的根本原因——不是因为它取巧而是因为它在成本和效果之间取得了巨大优势。该不该用蒸馏在纯粹的工程视角下几乎不需要讨论大家都会用。4. 争议焦点圈内怎么看这件事4.1 支持派的逻辑技术圈里有一批人认为蒸馏无罪他们的逻辑值得一听。第一模型学习模型本来就是机器学习的常态。人类学习同样不是从零开始我们读前辈的书、仿照高手的代码风格、借鉴同行的设计思路知识就是这么传递的。学生从老师那里学东西天经地义。如果所有知识都必须“完完全全原创”那整个科学体系都得崩。第二闭源模型自己也是建立在人类公开数据之上的。最强的大模型训练数据里包含了多少公开论文、开源代码、书籍本质上全是全人类的知识积累。一个公司用公共知识训练出模型然后反过来禁止别人用这个模型的输出去训练别的模型在知识伦理上多少有些双标。第三技术现实不等人。想要一个开源好模型从零预训练是正路但成本太贵大多数中小团队根本够不着。用蒸馏补足特定领域能力是理性选择。禁止蒸馏等于直接把小玩家赶出牌桌。这种论点在开源社区、高校实验室里尤其有市场——因为他们确实是蒸馏技术的受益者。4.2 反对派的逻辑另一批人觉得这些公司的做法有原则性问题论点同样扎实。第一服务条款就是合同。注册使用闭源API时条款里写了“不得使用本服务的输出去训练与本公司竞争的模型”白纸黑字。用API蒸馏的同时违反了这个条款这不是技术问题是契约问题。你可以说条款不合理但你不能说违约了还理直气壮。第二蒸馏不完全是“学习”。商业化蒸馏很多不是在“学习知识”而是把一个完整产品的行为模式端到端复制了——包括回复风格、处理边界、产品设计逻辑。这就好比请了个专家做咨询然后把专家全部工作方式录像下来培训了一个长得一模一样的竞争对手。咨询费你是付了但这不叫正常学习。第三存在实际安全风险。用精心设计的prompt诱导闭源模型泄露内部指令、安全策略、甚至训练数据里的个人信息这已经是攻击行为不是“蒸馏”那么简单了。过去一年里好几家模型厂商确实报告过类似的漏洞而其中一部分攻击手法就是在蒸馏的名义下进行的。两边的理由我听了无数遍结论是双方都有自己的道理但又各偏一隅。蒸馏作为技术路径必须支持蒸馏作为商业行为必须合规。这两个判断不矛盾。4.3 对普通从业者的实际影响这个争议对我们这些做具体项目的人有一个实实在在的影响行业规范会收紧。被点名之后API服务商大概率会强化使用监控、引入更严格的异常检测机制。将来你再想批量调用API生成训练数据可能会遇到限流、延迟、账号风控甚至直接封号。这不是猜测经验之谈——每次类似风波后服务商第一件事就是加强风控。所以我给身边朋友的建议一直很明确如果要走蒸馏路线做垂直应用优先选择条款里明确允许训练使用的模型源或者直接用开源模型的输出来做这是最稳的路线。同时尽早建立自己的私有数据管线靠自有一手数据沉淀竞争力不要把业务的长期底座建立在“二道蒸馏”上面。蒸馏是敲门砖但真正的护城河还得是自己手里的数据和场景理解。5. 常见问题与避坑心得5.1 四个我真实踩过的坑做蒸馏这一年多我踩了不少坑挑几个最有代表性的说说。第一个坑老师太强学生太小。拿最顶尖的大模型直接蒸馏7B小模型时损失降得很快但部署后常出现“学生只会模仿语气、不会真正推理”的尴尬。原因也简单老师水平太高知识量远超学生参数容量的承载极限。我实测下来有个经验学生参数量不要低于老师能力的10%-15%。如果拿一个400B级别的模型蒸馏7B几乎是在为难它不如先蒸馏出一个34B中转模型再用这个34B模型去蒸馏7B效果反而好。知识压缩不是一次性完成的。第二个坑生成数据的一致性。批量生成问答对时同一问题可能被生成出完全不同的答案风格甚至自相矛盾。这是因为大模型生成有随机性。我的解决办法是生成时temperature降到0.3以下prompt里强制要求输出格式统一比如“先给结论再列No.1、No.2、No.3”生成完必须跑一遍去重和一致性过滤。这个步骤看着不起眼但直接决定训练集质量。第三个坑知识截止日期陷阱。蒸馏数据的知识边界是老师模型的截止时间不是你的部署时间。我们曾经蒸馏过一批数据上线后用户问一个两个月前的热点模型完全没反应后来排查才发现是老师模型的知识截止日期太早。解决方案是定期补充新数据做增量蒸馏别指望一次蒸馏管半年。第四个坑合规风险低估。技术出身的人容易觉得“我只是调了个API没干什么坏事”不会出事。但实际上批量抓取输出用于训练商用模型本身就处在灰色地带。我见过一个创业团队模型都快上线了收到服务商警告函说检测到异常调用可能违反条款要求解释数据来源最后整个产品被撤下重新整改。所以在走蒸馏路线之前先把你要用的API服务商的条款通读一遍搞清楚边界别等事后再来补救。5.2 蒸馏实操速查清单把常见问题整理成一个速查表方便大家对照自查问题可能原因解决办法蒸馏后模型答非所问学生模型容量不足换更大底座或分阶段蒸馏生成数据质量参差temperature过高、prompt不严谨降到0.3以下强制输出格式模型知识陈旧继承老师知识截止日期定期补充新数据增量蒸馏合规风险高使用禁止训练的API换开源模型或人工加工明确版权训练损失不降学习率过高、数据污染降低学习率至1e-4清洗去重通用能力退化严重数据混合比例失衡加入10%-20%通用指令数据蒸馏这件事我做了这么久体会最深的一点就是技术本身不复杂复杂的永远是判断。你选择哪条蒸馏路径、怎么处理数据、怎么对待条款每一个决策背后都是工程效率、商业利益和合规风险的多方权衡。被点名的公司到底偷走了什么答案不在技术里而在它们自己的选择里。最后再分享一个个人体会吧。我见过一些团队做蒸馏时如临大敌觉得用了蒸馏就不光彩也见过一些团队大大方方把蒸馏写进技术文档当作标准工程手段。我自己的态度是做技术可以拥抱蒸馏但做产品一定要有自己的数据积累。前者决定你跑得快不快后者决定你活得久不久。如果你能把蒸馏当成跳板而不是长期的拐杖这波大模型浪潮里你应该能站得比大多数人都稳。