企业官网建设流程全解析

前阵子“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之间，具体要结合任务难度和模型规模反复试。我见过T=2.5在中文分类任务上效果很好，也见过T=6在生成任务上才够平滑，这东西没有银弹。

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，秩r=16，alpha=32
• 学习率：2e-4，cosine调度，warmup 5%
• batch size：16（梯度累积到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秩的选择上，我试过r=8、16、32。r=8时领域知识学习得不够充分，术语准确性明显差一些；r=32时训练时间涨了，但没带来等比例的效果提升。最后定在r=16，是性价比最合适的点。alpha取32是因为官方推荐把alpha设为r的两倍，能减缓更新幅度过大导致的输出坍缩。

训练过程里还有个容易忽略的细节：数据混合比例。我们用90%的蒸馏问答数据加上10%的通用数据（从开源指令数据集里采样），防止模型在垂直领域过度拟合后完全丢掉通用能力。这个比例我试过95:5和80:20，90:10效果最平衡——既能把领域能力拉到最高，又能保住模型说人话的基本功。

3轮训练大概花了4个小时，单张A100，显存占用42GB左右。如果你的显存不够，把batch size降到8，梯度累积保持住，效果不会有明显变化。

3.3 效果对比与成本核算

训练完，我们组了一个1000条真实用户问题的评估集，对比了几个版本的效果：

蒸馏效果和纯人工标注训练几乎持平，但差距在成本上。

人工标注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 蒸馏实操速查清单

把常见问题整理成一个速查表，方便大家对照自查：

蒸馏这件事，我做了这么久，体会最深的一点就是：技术本身不复杂，复杂的永远是判断。你选择哪条蒸馏路径、怎么处理数据、怎么对待条款，每一个决策背后都是工程效率、商业利益和合规风险的多方权衡。被点名的公司到底偷走了什么，答案不在技术里，而在它们自己的选择里。

最后再分享一个个人体会吧。我见过一些团队做蒸馏时如临大敌，觉得用了蒸馏就不光彩；也见过一些团队大大方方把蒸馏写进技术文档，当作标准工程手段。我自己的态度是：做技术可以拥抱蒸馏，但做产品一定要有自己的数据积累。前者决定你跑得快不快，后者决定你活得久不久。如果你能把蒸馏当成跳板，而不是长期的拐杖，这波大模型浪潮里，你应该能站得比大多数人都稳。