企业官网建设流程全解析

今天早上刷到“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, reduction="batchmean") * (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 做产品时把“数据血缘”当成一等公民

第三个瞬间，是靠数据血缘意识救了自己一次。现在我做任何一个涉及训练数据的项目，都会顺手维护一份数据清单，记清楚每条数据的来源、授权类型、收集时间、处理方式和合规责任人，然后存成一张表，类似这样：

这张表看着朴素，但它在关键时刻能救命。一旦有人质疑你的模型数据有问题，你能在十分钟内说清楚“哪些数据可以用、哪些不能用、用了会怎样”，而不是慌乱地翻聊天记录和代码仓库。数据血缘意识的本质，是把你对数据的信任从“感觉没问题”升级为“有据可查没问题”，这是大模型时代工程师的基本职业素养。

5.4 从这则热点到日常：我给自己定的三条原则

这则“7家中国公司被点名蒸馏”的新闻，对我个人而言最大的价值，是逼着我梳理出了一套日常行动的底线。

第一条，不蒸馏任何我没有确认授权的模型。哪怕对方是开源的，我也会先看一眼授权文件里有没有关于模型输出训练的限制条款，再决定是否动手。

第二条，产品层如实标注模型名称。我的产品用了哪个厂商的模型、哪个开源底座、哪个自研微调，全部在文档里写清楚，不给用户误判的空间。用户也许不在乎，但我在乎——因为一句含糊的“自研大模型”，就能让团队从一个技术问题滑向信任问题。

第三条，先想清楚“是否需要自研模型”再动手。需求真的简单到调API就能满足，那就老老实实调API；只有长期产品路线确实需要自有模型时，才去规划自研、蒸馏、微调的路径。不是每条业务线都需要一个“自己的大模型”，很多时候“调得好”比“自己做”更理性，也更安全。

写到这里，那则热搜的热度已经退去大半，但“蒸馏”这个词引发的思考不会褪色。它让我想起那句话：技术本无罪，但你的每一次调用、每一行训练日志、每一个上线开关，都在替你的判断写下证词。希望我们在谈到“偷”这个词的时候，心里都能坦然说一句：我没有。