1. 从「点名」说起蒸馏争议到底在吵什么「蒸馏」这个词最近被推到了风口浪尖起因是有报道称几家中国公司被点名说它们通过某种方式「拿走」了别人家大模型的能力。消息一出技术圈立刻分成两派一派觉得这就是常规的知识迁移手段另一派觉得这是赤裸裸的能力窃取。我先把结论放前面——蒸馏本身是中性技术争议的核心从来不是「能不能蒸」而是「蒸了什么、怎么蒸的、蒸完之后拿去干什么」。要理解这件事得先搞清楚大模型蒸馏到底在做什么。你可以把一个大模型想象成一位经验极其丰富的老教授他脑子里装着海量知识但请他出山成本极高——推理一次要烧掉大量算力。而蒸馏就是让一位年轻学生去「听老教授讲课」把老教授的输出也就是 logits 或者生成的文本当作学习材料训练出一个体积更小、跑得更快、但能力接近老教授的学生模型。这个过程在学术上完全正当Hinton 在 2015 年就提出了知识蒸馏的经典框架十年来一直是模型压缩的主流手段。那为什么这次会引发争议关键在于蒸馏的「原料」来源。如果老教授是你自己花钱请的、或者公开授课允许旁听那学生去学没问题。但如果老教授是别人家的商业模型你通过 API 大量调用、把它的输出攒下来当训练数据这就踩到了灰色地带。争议点集中在三个层面第一调用对方 API 生成的数据所有权归谁第二用这些数据训练出的模型是否构成了对原模型能力的「实质性复制」第三如果学生模型被拿去商用是否损害了原模型厂商的商业利益。我个人的判断是这次被点名的几家公司大概率不是简单粗暴地「抄输出」而是走了更隐蔽的路线——比如用对方模型的输出做数据合成再混合自己的数据做微调。这种做法在技术上很难被直接抓包因为最终模型里已经看不到原始输出的痕迹了。但难抓包不代表没问题这就像你把别人的书读了一遍用自己的话重写了一遍版权上可能擦边道德上却很难说完全干净。提示蒸馏和微调经常被混为一谈但两者不是一回事。微调是在已有模型基础上用特定数据继续训练改变的是模型的行为倾向蒸馏是让小模型去模仿大模型的输出分布改变的是模型的能力上限。这次争议里两者都有涉及但核心矛盾在蒸馏。2. 蒸馏的技术底牌logits、软标签与 KL 散度要真正看懂这场争议光知道「蒸馏是让学生模仿老师」还不够得深入到技术细节里看看蒸馏到底「偷」走了什么。这里涉及几个关键词logits、软标签、KL 散度、温度系数。我尽量用大白话把它们串起来。2.1 硬标签和软标签的区别假设你在训练一个图像分类模型任务是区分猫和狗。传统的监督学习用的是硬标签——这张图是猫标签就是 [1, 0]那张图是狗标签就是 [0, 1]。模型学到的信息非常有限它只知道「这是猫」不知道「这有多像猫」。而大模型蒸馏用的是软标签也就是老师模型输出的概率分布。比如老师看到一张图输出可能是 [0.85, 0.15]意思是「85% 是猫15% 是狗」。这个 0.15 看似没用其实包含了大量信息——它告诉学生模型这张图虽然主要是猫但有一些狗的特征。这种「类间相似性」的信息就是蒸馏的核心价值。在大语言模型场景下软标签就是每个 token 位置上的完整概率分布也就是logits。老师模型对「今天天气真___」这个句子可能在「好」上给 0.6「不错」上给 0.25「棒」上给 0.1其他词分摊剩下的 0.05。学生模型要学的就是复现这个分布而不是只学「填好」这一个答案。2.2 KL 散度衡量两个分布有多像那怎么衡量学生模型学得像不像用的就是KL 散度Kullback-Leibler Divergence。它的作用是计算两个概率分布之间的差异值越小说明两个分布越接近。蒸馏的损失函数通常由两部分组成一部分是学生模型和真实标签的交叉熵另一部分是学生模型和老师模型输出分布之间的 KL 散度。用公式表达大概是这样# 蒸馏损失函数的典型形式 loss alpha * cross_entropy(student_logits, true_labels) (1 - alpha) * KL_divergence(softmax(student_logits / T), softmax(teacher_logits / T)) * T * T这里的T是温度系数作用是让概率分布变得更「软」。温度越高分布越平滑类间相似性信息越丰富温度越低分布越尖锐越接近硬标签。实践中 T 通常取 2 到 20 之间具体要看任务。2.3 为什么大模型蒸馏比传统蒸馏更敏感传统蒸馏里老师模型是自己训练的学生模型也是自己部署的整个流程闭环可控。但大模型蒸馏的敏感点在于老师模型往往是别人的商业资产。你通过 API 调用拿到的 logits可能只暴露了 top-k 个 token 的概率甚至只给了采样后的文本信息是不完整的。但即便如此通过海量调用仍然可以逼近老师的输出分布。这就引出一个关键问题蒸馏到底「偷」走了什么我的理解是偷走的是老师模型在海量数据上训练出来的「泛化能力」和「知识压缩」。老师模型见过的东西、学到的模式、形成的推理能力都隐含在它的输出分布里。学生模型通过模仿这个分布相当于走了捷径跳过了从零预训练的海量算力消耗。蒸馏要素传统蒸馏大模型蒸馏敏感点老师来源自研模型第三方商业模型资产归属数据获取内部数据集API 调用生成使用条款输出信息完整 logits可能只有 top-k 或文本信息完整度训练成本中等极低相对预训练成本套利法律风险低高合规边界注意很多团队在做蒸馏时会先用老师模型生成大量合成数据再用这些数据做监督微调。这种做法绕开了 logits 的直接获取但本质上仍然是能力迁移只是证据链更难追溯。3. 被点名的七家公司可能踩了哪几条线虽然报道没有披露完整细节但结合行业常见做法我梳理了几条最可能被踩到的线。这些线不是非黑即白的法律条文而是技术社区和商业伦理层面的灰色地带。3.1 第一条线API 滥用与条款违反几乎所有商业大模型的 API 服务条款里都有一条类似「禁止使用本服务输出训练竞争模型」的规定。这条规定的法律效力在不同司法管辖区不一样但至少构成了合同违约。如果一家公司通过 API 大量调用某模型把输出攒下来做训练数据这就直接违反了条款。问题在于怎么界定「大量」和「竞争模型」调用一百万次算不算大量训练出来的模型如果只做内部使用、不对外商用算不算竞争这些边界非常模糊。我了解到的情况是有些公司会通过多个账号、多个 IP 分散调用规避单账号的速率限制和监控这种做法在技术上不难实现但明显是有意规避。3.2 第二条线合成数据的「洗白」路径更隐蔽的做法是数据合成。具体流程是用老师模型生成一批问答对然后用另一个模型可能是开源的对这些问答对做改写、扩增、过滤最后得到一批「看起来像是自己生产」的训练数据。这批数据经过多轮清洗后原始来源的痕迹已经非常淡了。这种做法的技术合理性在于合成数据本身是行业公认的有效手段很多开源模型都在用。但争议点在于如果合成数据的「种子」完全来自某一家商业模型且生成量巨大那就相当于把对方的能力「洗」了一遍装进自己口袋。这就像你把一本英文书翻译成中文再翻译回英文虽然文字不完全一样但内容还是那本书的。3.3 第三条线模型指纹与能力复现技术社区里还有一种更硬核的检测手段——模型指纹。每个大模型在训练过程中都会形成一些独特的「怪癖」比如对某些特定 prompt 的异常反应、对某些 token 的偏好、在特定任务上的错误模式。这些指纹就像人的笔迹一样很难完全抹掉。如果学生模型在某些指纹特征上和老师模型高度相似那就构成了能力复现的强证据。我见过一些技术分析文章通过对比两个模型在数百个精心设计的 prompt 上的输出分布用统计方法判断它们是否存在「血缘关系」。这种分析虽然不是法律证据但在技术社区里很有说服力。3.4 第四条线RL 与 ODP 的介入热词里出现了RL强化学习和ODP可能是某种优化或数据管道缩写这提示我们蒸馏可能不是单纯的监督学习。现在很多团队会用RLHF或者DPO这类方法让模型在人类偏好数据上做对齐。如果偏好数据本身也是从老师模型那里「蒸馏」来的——比如用老师模型给两个回答打分然后拿这个打分去训练学生——那蒸馏的链条就更长了。这种「蒸馏 RL」的组合能力迁移效率极高但同时也让溯源变得极其困难。你很难说清楚最终模型的能力到底来自哪里因为中间经过了太多层变换。4. 蒸馏、微调、部署一条完整的技术链路聊完争议咱们回到技术本身。不管争议怎么收场蒸馏作为一项技术在实际工程里是有明确应用场景的。我把它和微调、部署串成一条链路讲讲一个团队从拿到基座模型到上线服务通常会怎么走。4.1 基座选择开源还是闭源 API第一步永远是选基座。如果预算充足、对能力要求极高直接用商业 API 是最省事的——不用管 GPU、不用管并发、不用管运维。但问题也很明显成本随调用量线性增长数据要出自己机房而且能力上限被对方卡死。如果选择开源基座比如 Qwen、Llama 系列好处是可控、可微调、可私有化部署。但代价是你得自己搞定 GPU 集群、推理框架、并发优化。我见过不少团队在这条路上踩坑最后发现运维成本比 API 费用还高。维度商业 API开源自部署初始成本低高GPU 采购/租赁边际成本随调用量增长基本固定数据隐私数据出域完全可控能力上限受限于厂商可通过微调突破运维复杂度低高适合场景快速验证、低频调用高频调用、数据敏感4.2 微调让基座模型「入乡随俗」选好基座后下一步通常是微调。微调的目的不是让模型变聪明而是让它「懂你的业务」。比如你做一个法律问答助手基座模型虽然通用能力强但不懂你们律所的内部术语和文书格式这时候就需要用领域数据做微调。微调的技术选型现在很成熟了全量微调效果最好但成本最高LoRA和QLoRA是性价比最高的方案。LoRA 的思路是在原模型旁边挂一个小矩阵只训练这个小矩阵不动原模型参数。这样显存占用大幅降低训练速度也快很多。QLoRA 更进一步把原模型量化到 4-bit连推理带训练一起省显存。# LoRA 微调的典型配置 from peft import LoraConfig, get_peft_model lora_config LoraConfig( r16, # 秩越大能力越强但参数越多 lora_alpha32, # 缩放系数 target_modules[q_proj, v_proj], # 作用在注意力层 lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config)4.3 蒸馏把大模型的能力「压缩」进小模型微调之后如果你发现模型太大、推理太慢、成本太高就可以考虑蒸馏。蒸馏的典型场景是你有一个 70B 的模型效果很好但线上服务需要 7B 的模型才能扛住并发这时候就用 70B 当老师7B 当学生做一轮蒸馏。蒸馏的数据从哪来最干净的做法是用自己的业务数据让老师模型生成回答然后拿这些回答训练学生。这样既避免了版权问题又能让学生的能力贴合业务。如果业务数据不够可以用老师模型生成一批通用数据做补充但要注意控制比例别让通用数据淹没了业务数据。4.4 部署从实验室到生产环境模型训好了最后一步是部署。部署环节的坑一点不比训练少。推理框架选vLLM还是TensorRT-LLM量化用GPTQ还是AWQ并发怎么调显存怎么分这些都是实打实的工程问题。我个人的经验是vLLM在大多数场景下是首选它的 PagedAttention 机制对显存利用非常高效吞吐量比朴素实现高好几倍。如果追求极致延迟可以考虑 TensorRT-LLM但配置复杂度高很多。量化方面AWQ 在精度和速度的平衡上做得比较好GPTQ 生态更成熟但有时精度损失略大。提示部署时一定要做压力测试别只看单条推理的延迟。真实场景下并发一上来显存碎片、KV Cache 管理、批处理策略都会成为瓶颈。我见过太多团队在实验室跑得好好的一上线就崩。5. 蒸馏争议背后的行业焦虑技术讲完了咱们再往深一层看。这次「点名」事件之所以引发这么大反响本质上反映的是行业里的几重焦虑。5.1 算力焦虑预训练的门槛越来越高大模型预训练的成本是天文数字。一次完整的预训练动辄几千张 GPU 跑几个月电费都是千万级别。这种门槛把绝大多数团队挡在了门外。蒸馏提供了一条「捷径」——不用自己预训练直接模仿别人的成果成本可能只有预训练的百分之一甚至千分之一。这种成本套利是争议的经济根源。如果蒸馏完全合法合规那意味着后来者可以用极低成本追平先行者先行者的巨额投入就打了水漂。但如果完全禁止蒸馏又会让技术扩散受阻不利于整个生态的发展。这个矛盾短期内无解。5.2 创新焦虑能力复现 vs 真正创新另一个焦虑是蒸馏出来的模型到底算不算「创新」如果一家公司的核心竞争力就是「把别人模型蒸一遍」那它到底创造了什么价值这个问题在技术社区里争论很激烈。我的看法是蒸馏本身不构成创新但蒸馏之后的工程优化、场景适配、产品化可以构成创新。就像你不能因为一个人读了别人的书就说他没学问关键看他读完书之后做了什么。如果只是复读机式地复现那确实没价值如果在此基础上解决了特定场景的问题那就是有价值的。5.3 合规焦虑规则不清导致人人自危最让从业者头疼的其实是规则不清。现在没有任何一部法律明确规定「大模型蒸馏的边界在哪里」。服务条款是一回事法律是另一回事技术社区的道德评判又是第三回事。三套标准不统一导致大家都在猜。我认识的一些团队现在做蒸馏时非常谨慎会专门请法务评估会保留完整的数据来源记录会避免直接使用竞品的输出。但即便如此也没人能保证百分之百安全因为规则本身还在演化中。6. 如果你要做蒸馏这几条实操建议能帮你避坑假设你是一个技术团队的负责人现在要做一个蒸馏项目以下是我基于实际经验总结的几条建议。这些建议不构成法律意见但能帮你在技术和合规之间找到平衡。6.1 数据来源要「干净可追溯」第一条也是最重要的一条所有训练数据的来源必须可追溯。如果你用了老师模型的输出要明确记录是哪个模型、哪个版本、通过什么方式获取的、获取时遵守了什么条款。如果条款禁止用于训练那就别用。如果条款模糊宁可不用也别赌。我见过一些团队为了省事直接从网上爬了一批「模型对话数据」结果这些数据本身可能就是别人蒸馏的产物用起来风险极大。数据来源的「血统」在蒸馏项目里比什么都重要。6.2 蒸馏比例要控制别让「老师味」太重第二条是技术层面的蒸馏数据在总训练数据里的占比要控制。如果学生模型 90% 的训练数据都来自老师那它本质上就是老师的复制品不仅法律风险高能力上限也被老师锁死了。合理的做法是把蒸馏数据控制在 30% 到 50% 之间剩下的用自有数据、开源数据、合成数据补充。这样做的另一个好处是学生模型能学到老师没有的东西形成差异化能力。我做过一个对比实验纯蒸馏的学生模型在通用任务上接近老师但在垂直领域明显不如混合训练的学生模型。6.3 保留「能力指纹」的差异第三条比较微妙有意识地让学生模型和老师模型保持差异。这不是为了规避检测而是为了真正的能力独立。具体做法包括在蒸馏时加入噪声、使用不同的温度系数、混合多种老师模型的输出、在蒸馏后做额外的领域微调。这些操作会让最终模型的能力分布和老师产生可观测的差异既降低了法律风险也让模型更有自己的「个性」。从工程角度看这其实是好事——一个完全复刻老师的模型价值远不如一个有自己特点的模型。6.4 合规审查要前置别等做完再补最后一条是流程层面的合规审查要前置到项目立项阶段。别等模型都训完了、要上线了才想起来问法务「这个能不能用」。那时候沉没成本已经很高改起来非常痛苦。我的建议是在项目启动时就明确三件事数据来源清单、使用条款对照表、风险预案。如果某个数据源的风险太高宁可换方案也别硬上。技术方案可以调整法律风险一旦爆发就是致命的。风险等级数据来源建议低自有业务数据、明确开源许可数据可放心使用中开源模型输出、条款允许的 API 输出控制比例保留记录高条款禁止的 API 输出、来源不明的爬取数据避免使用极高竞品核心能力直接复现坚决不做7. 从「偷」到「学」蒸馏的正当用法争议归争议蒸馏作为技术本身是有巨大价值的。我想在最后聊聊它的正当用法也算是给这个被污名化的技术正名。7.1 模型压缩让大模型跑在边缘设备上最正当的用法就是模型压缩。你有一个 70B 的模型效果很好但手机、车机、IoT 设备根本跑不动。这时候用蒸馏把它压缩到 7B 甚至 1B让边缘设备也能用上大模型能力这是实实在在的技术进步。这种场景下老师模型是你自己的学生模型也是你自己的没有任何争议。7.2 能力迁移把通用能力迁移到垂直领域第二种正当用法是能力迁移。通用大模型什么都懂一点但什么都不精。你可以用通用模型当老师把它的通用能力蒸馏到一个垂直领域的小模型里再叠加领域数据微调。这样得到的小模型既有通用模型的泛化能力又有领域模型的专精能力性价比极高。7.3 教学相长用蒸馏做模型诊断第三种用法比较冷门但很有价值用蒸馏做模型诊断。当你尝试把一个大模型蒸馏到小模型时如果某些能力怎么都蒸不过去说明这些能力可能依赖于大模型的参数量或特定结构。这反过来能帮你理解大模型的能力来源对模型可解释性研究很有帮助。我做过一个实验把同一个老师模型蒸馏到不同大小的学生模型上发现推理能力在 3B 以下急剧下降但记忆能力在 1B 以上就能保留得不错。这个发现让我对「大模型能力到底存在哪里」有了更直观的认识。7.4 蒸馏的边界什么能做什么不能做最后划一下边界。能做的用自己的模型蒸馏、用明确许可的模型蒸馏、用开源模型蒸馏、蒸馏后做实质性改进。不能做的违反服务条款蒸馏、大规模复制竞品能力、蒸馏后冒充原创、用蒸馏规避算力投入却宣称自研。这条边界不是法律划的是技术社区的共识。共识可能比法律更严格但也更灵活。作为从业者我倾向于把标准定得比法律高一点这样睡得踏实。提示如果你不确定某个蒸馏方案是否合规一个简单的判断方法是——假设这个方案被公开披露你是否能坦然解释每一步的合理性如果不能那就别做。8. 我个人的几点体会做了几年大模型相关的工作蒸馏这个技术我用过很多次也见过它被滥用。我的体会是技术本身没有原罪关键看用的人怎么用。同样一把刀厨师用来切菜歹徒用来伤人不能因为有人伤人就禁刀。这次「点名」事件我觉得对行业是好事。它把蒸馏的合规问题摆到了台面上逼着大家去思考边界在哪里。以前很多人是「闷声蒸」现在至少会想一想「这样蒸行不行」。这种反思本身就是进步。另一个体会是真正的竞争力从来不是「蒸」出来的。你可以蒸来一个模型但蒸不来数据飞轮、蒸不来用户反馈、蒸不来工程能力、蒸不来产品理解。那些靠蒸馏走捷径的团队短期可能跑得快长期一定跑不远。因为蒸馏的天花板就是老师模型而老师模型也在进化你永远慢一步。最后一个体会是关于技术人的自我要求。我们做技术的容易陷入「能实现就行」的思维。但技术是有外部性的你的一个技术选择可能影响整个生态。在做蒸馏之前多想一步「这个做法对行业是加分还是减分」可能比多想一步「这个做法能不能跑通」更重要。这个领域变化太快今天的争议明天可能就有新答案。但有些原则是不变的尊重他人的劳动成果、保持技术的透明度、追求真正的创新而非表面复现。这些原则不会因为技术迭代而过时。