企业官网建设流程全解析

1. “蒸馏”上了热搜，我们先聊聊为什么这个词突然这么烫手

最近一段时间，只要你稍微关注大模型圈子，应该都被“蒸馏”这两个字刷屏了。先是几家公司被公开点名，说它们“蒸馏”了别家模型，紧接着各种版本的回应、截图、技术分析满天飞。作为一个常年在大模型落地一线调模型、跑训练的人，我第一反应不是站队，而是觉得这件事终于藏不住了。

“蒸馏”在深度学习里本来是个非常正统、非常高效的技术路线，从 Hinton 老爷子 2015 年那篇经典的《Distilling the Knowledge in a Neural Network》开始，蒸馏就被用来把大模型的能力压缩到小模型里，是工业界最常用的模型瘦身手段之一。大模型时代，蒸馏更是一门显学：OpenAI 的 GPT-4 能力要下放到小模型，Anthropic 的 Claude 要适配低成本设备，国内各家大厂、创业公司想让模型跑在手机和边缘设备上，几乎人人都要碰蒸馏。

但“蒸馏”这个词一旦和“偷”挂钩，味道就变了。被点名的公司，据说是在没有授权的情况下，用别人家大模型的 API 或者开源模型产出的数据，去训练自己的模型，甚至直接把对方模型的“思考过程”和“回答风格”学了过来。这不是学术圈里互相引用的蒸馏，而是商业竞争语境下的“搭便车”。

我身边不少朋友一听到“蒸馏”就说：这不就是抄作业吗？其实还真没那么简单。我更喜欢把它理解成“带着老师上课，最后学会的却是学生”——老师可能都不知道自己带了这门课。为了把这件事讲清楚，这期我就从技术原理、实操流程、落地陷阱这几个方面，把“蒸馏”这层窗户纸彻底捅破，顺便分享一些我自己在蒸馏项目里踩过的坑。

先说结论：蒸馏本身不是洪水猛兽，问题出在“蒸馏的对象是谁”和“蒸馏之后用来干什么”。把技术讲明白了，你自然就知道这波争议背后，大家真正在争的是什么。

2. 被“偷走”的知识，到底长什么样？

2.1 一张图看懂：老师和学生之间传递的是“软标签”

很多人以为蒸馏就是“把大模型的答案抄一遍，然后拿去训练小模型”。这么理解方向对，但粒度太粗了。真实情况是，大模型给的不只是一个“最终答案”，而是一整套“候选词的概率分布”。

我给你举个具体例子。假设老师模型被问到“中国的首都是什么”，这个问题太简单，答案只有一个词“北京”，这种叫硬标签。但在真实场景里，问题通常没有唯一解。比如“写一封邮件，语气要正式但不生硬”，老师模型会在输出时，给每一个可能的 token 打分，这个打分向量就是 logits，经过 softmax 换算之后变成概率分布，这才是蒸馏里真正传递的东西。

这个概率分布有个非常值钱的特性：它不光告诉你“哪个词是对的”，还告诉你“哪些词差不太多”。比如在翻译“I am happy”时，学生模型从硬标签里只能学到“高兴”；但从老师模型的软标签里，它能学到“高兴”和“开心”“愉悦”之间的相似度关系。这种相似度关系就是模型“语感”的来源，也是从零训练很难学出来的部分。

为了进一步放大这种软标签里的“模糊信息”，蒸馏通常会引入一个温度参数 T。温度越高，概率分布越平滑，越能暴露出老师模型对各个候选词的偏好差异；温度越低，分布越尖锐，越接近硬标签。实操中，T 一般取 2 到 4 之间，太低起不到蒸馏效果，太高会把噪声也学进去。

我用 OpenML 上公开的 CIFAR-10 做过一组对比实验：直接用硬标签训练一个小 ResNet，精度大概在 83%；用教师模型 soft label 蒸馏，温度设为 3，精度能到 87.5%。额外赚了 4.5 个点，成本几乎为零。这就是蒸馏的魔力。

2.2 被点名公司“偷走”的是四种东西：推理痕迹、对齐偏好、领域数据、产品体验

单纯讲 logits 还不够直观。放到大模型语境里，蒸馏“偷走”的不是一两个参数，而是四种高度浓缩的资产，我说完你大概就能明白为什么这事会让各家模型厂商如此紧张。

第一种是推理痕迹。现在的顶尖模型在回答复杂问题前，内部会产生一段链式思考，也就是所谓的 CoT。这段思考链在 API 返回时通常被藏起来了，但很多开源模型会把推理过程直接展示出来。蒸馏方如果把几千条带完整推理过程的高质量问答拿去训练自己的模型，等于直接继承了老师模型“思考问题的方式”。这是浓缩的智力，花钱砸数据、砸算力短时间也未必能攒出来。

第二种是对齐偏好。大模型从 Pretrain 到 Chat，中间要经过 RLHF 或 DPO 这类对齐步骤，目的就是让模型懂得“什么话该说，什么话不该说，什么语气更适合对话”。这些偏好信息是大量人工标注和反复迭代调出来的。直接把老师模型的输出当作正样本去训练，就等于绕过了整个对齐工程，把对方辛辛苦苦调出来的“性格”一键复制。

第三种是领域数据和知识结构。老师模型在海量私有数据上训练过，它知道某些垂直行业里的专有名词、行话、案例。虽然 API 输出只是“知识的外显”，但高密度、高代表性的输出足以让蒸馏方在小样本场景下重建相当一部分领域知识。我在做金融大模型时验证过，用 ChatGPT 生成的模拟财报问答对微调开源模型，模型对金融指标的理解力提升了不止一个档次。

第四种是产品体验。包括响应格式、停顿节奏、结构化输出风格，甚至报错的方式。对 C 端产品来说，用户已经习惯了某类模型的“人设”，蒸馏方直接把这种产品化体验以数据形式偷走，用户几乎零迁移成本。这已经不只是技术问题，而是商业竞争层面的侵权。

3. 真正实操：从零完成一个模型蒸馏项目

3.1 准备阶段：教师模型、学生模型与训练数据怎么选

在聊被点名公司的事之前，我更想带你亲手跑一遍蒸馏。“纸上得来终觉浅”，只有自己动手跑过蒸馏，你才能从直觉上理解为什么这事在工业界如此普遍。

我用一个经典组合做演示：教师模型选 Qwen2.5-14B-Instruct，学生模型选 Qwen2.5-1.5B-Instruct，使用 PyTorch 2.1 + transformers + deepspeed，单机 8 卡 A100 80G 足够。这个组合很有代表性，14B 的教师能提供足够丰富的知识分布，1.5B 的学生又能跑得动，符合大多数团队的硬件现状。

数据集选择是蒸馏成功的一半。我的经验是：宁可要 10 万条高质量数据，也不要 100 万条凑数数据。具体选数据时我优先看三个维度：覆盖度、难度和多样性。覆盖度指任务类型要全，对话、摘要、代码、数学都要有；难度指要包含一些教师模型“需要思考一下”才答得出来的题，全是简单题学生学不到东西；多样性指不要让某一种领域数据占比超过 20%，否则蒸馏出来的模型会偏科。

数据准备好之后，先用教师模型批量推理，生成软标签。如果是黑盒蒸馏，比如只有 API 没有 logits，那就需要用采样法：温度设为 0.7，对每条 prompt 跑 3 次采样，把生成结果一起作为软标签，这个 trick 能极大弥补拿不到 logits 的缺陷。

3.2 关键参数计算：温度、损失权重和批次策略

蒸馏训练里最核心的三个参数，我一个个说。

温度 T 的选择。如果 T 太低，软标签接近硬标签，等于白蒸馏；太高，模型会把噪声当成真知识学坏。我的经验公式是：先看任务复杂度，简单任务 T 取 2，复杂推理任务 T 取 4，然后再跑一组 T=1/T=2/T=4 的消融实验，看验证集效果选。别嫌麻烦，这个参数差一点，最终模型效果可能差好几个点。

损失权重 α。蒸馏损失和标准 CE 损失的权重比，推荐设置为 0.7:0.3。我一开始用五五开，结果学生模型学得四不像，hard label 提供的“标准答案”被稀释了，导致模型稳定性下降。后来改成 alpha=0.7，把 KL 散度作为主导，训练曲线的收敛性和最终效果都明显变好。原因不复杂：教师模型也会犯错，得留一部分硬标签的“锚点”来纠偏。

批次策略，也就是 batch size 的设定。蒸馏训练里学生模型本身不大，但软标签文件可能很大，所以我建议用 gradient checkpointing + batch size 16 做基准，配合 deepspeed stage 2，显存占用能控制在 40G 以内。我见过一些团队为了追求大 batch 把显存撑爆，其实没必要，蒸馏任务里 batch size 从 16 升到 32，收益很小，但显存压力翻倍。

我在实验中分别用 T=1、T=2、T=4 跑过三个模型，基线效果差异如下表：

这个表基本能说明问题：温度不是越高越好，需要搭配任务特性来调。

3.3 训练与评估：跑通一个最小闭环

代码层面，我提炼一个最小蒸馏训练脚本框架。核心就是两步：先加载教师模型得到 logits，再让学生模型输出和教师输出算 KL 散度。

import torch import torch.nn.functional as F from transformers import AutoModelForCausalLM, AutoTokenizer teacher_model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-14B-Instruct") student_model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-1.5B-Instruct") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-1.5B-Instruct") # 假设 inputs 已经 token 化 with torch.no_grad(): teacher_logits = teacher_model(**inputs).logits student_logits = student_model(**inputs).logits # 温度缩放后的 KL 散度作为蒸馏损失 def distillation_loss(student_logits, teacher_logits, temperature=4.0): student_logits = student_logits / temperature teacher_logits = teacher_logits / temperature loss = F.kl_div( F.log_softmax(student_logits, dim=-1), F.softmax(teacher_logits, dim=-1), reduction="batchmean", ) return loss * (temperature ** 2)

这里有个小细节：KL loss 乘以温度平方，是为了让梯度保持在和普通 CE 损失相近的尺度，不然温度升高后梯度会缩小，导致训练不动。这个 trick 在 Hinton 的论文里写得很清楚，但实操中很多人会漏掉。

训练完成后，评估不能只看 benchmark。我的做法是“三层评估”：第一层跑公开评测集，比如 MMLU、C-Eval；第二层人工抽检 50 条业务真实问题，从准确性、语气、格式三个维度打分；第三层用 LLM-as-a-Judge 的方式，拿教师模型的输出当标准答案，计算学生模型输出与之的语义相似度。三层都过线了，才敢上线。

4. 实战里最常见的问题，能避一个是一个

4.1 训练 loss 不降反升，多半是数据噪声或温度失控

这是我被问得最多的问题。学生在训练中 loss 震荡很常见，但如果是 loss 一路走高，我建议你先排查三件事。

第一，数据里有没有重复的 prompt 或几乎一样的输出？如果教师模型对同一类 prompt 给出了矛盾的答案，学生模型会犯迷糊。我处理过一套 50 万条的数据集，清洗前 loss 降不下来，跑了个文本去重后，同样的参数下 loss 直接掉了 0.4。第二，温度是不是设得太高？T 大于 8 时，教师模型的概率分布接近均匀分布，软标签的信息量趋近于零，学生只能瞎猜。第三，训练动态里的学习率是不是太大了？蒸馏场景下我习惯把学习率降到正常微调的三分之一，否则学生模型很容易被教师输出中的极端波动带偏。

分享一个排查技巧：不管参数怎么调，先取 1000 条数据做 10 个 step 的 smoke test，如果 loss 能稳定下降，说明整体 pipeline 没毛病，接下来再放大数据量。这个习惯帮我排掉了很多低级 bug，包括数据没对齐、标签错位这类问题。

4.2 蒸馏完反而变笨了：过拟合教师模型的问题

另一个高频问题是：蒸馏之后，学生模型在训练集上效果不错，一到新问题就露馅，连原本自己会的知识都忘了。这其实是典型的“过度蒸馏”，本质是学生模型过分拟合了教师模型的输出分布，丢失了自身通用能力。

我的解决方案是三管齐下。首先降低蒸馏损失的权重，alpha 从 0.7 调到 0.5，给硬标签更多存在感。其次在蒸馏训练中混入一定比例的原始预训练数据，大概 20% 到 30%，让模型在学教师的同时不忘记自己的语言能力。最后，教师模型的 logits 别用得太“绝对”，在软标签里加一点 label smoothing，比如 0.05，相当于给教师模型的判断也留出容错空间，学生就不会把教师的每个偏好都当成圣旨。

我还遇到过一个隐蔽问题：教师模型本身有系统性偏见，比如对某个特定类型的提问总是过度道歉。学生模型蒸馏后也学会了这套废话连篇的毛病。这种偏见靠调参很难解决，只能先把教师模型在这些场景下的输出过滤掉，或者重新采样一批更中性的数据。

4.3 黑盒蒸馏的坑：没有 logits 时怎么办

很多团队不是拿着教师模型的权重自己做蒸馏，而是直接调用 API。这种黑盒蒸馏在训练时没有教师模型 logits，只能拿到推理文本。这时候千万别直接把 text 打成分词后当硬标签训练，那就没意义了。

我推荐的做法是多样化采样 + 排序组合。对每条 prompt 并行采样 8 条回复，然后用一个奖励模型或者规则打分器给这些回复排个序，取 top 2 的回复作为软标签的正样本，取分数最低的作为负样本，配合 DPO 训练。这种方案本质上是把黑盒蒸馏转化成了偏好对齐任务，效果比直接微调高不少。

还有一个更取巧的训练配方：先用黑盒采样数据做一轮 SFT，让学生模型“外形”先贴近老师，再用奖励模型做一轮 DPO，让学生模型学会“筛选”老师的最佳输出。我在 chatbot 场景测试过，这个两阶段黑盒蒸馏方案能把 response 的采纳率提升 12% 左右，仅次于白盒蒸馏的 15%。

5. 蒸馏的边界在哪里：从技术到商誉，界线比你想的更模糊

5.1 谁都在蒸馏，区别只是“蒸馏谁”和“怎么用”

这里必须说点掏心窝子的话：蒸馏在 AI 圈根本不是秘密，几乎所有团队都做过某种形式的蒸馏。我自己在内部项目里就用过开源模型的输出做蒸馏数据，这是行业惯例。那为什么这次被点名的公司让大家如此愤怒？关键在“被蒸馏方是否知情并同意”以及“蒸馏之后是否彻底替代了原模型的服务”。

如果蒸馏的是开源模型，比如 Llama 或 Qwen，许可协议里明确允许二次利用和蒸馏，那这就是技术常规操作，谁都没资格指责。如果蒸馏的对象是闭源商业 API，而对方服务条款明确禁止用输出去训练竞品模型，这就涉嫌违反合同约定。再往上一层，如果蒸馏方借着老师的品牌形象去融资、去宣传自己的技术实力，这就是商誉层面的问题了。

我个人的判断标准很简单：问自己一个问题——“如果老师模型的团队看到了学生模型的输出，会不会觉得被冒犯？”如果会，那大概率越界了。

5.2 谁都在蒸馏，区别只是“蒸馏谁”

被点名的 7 家公司里，有些是初创企业，有些是大型平台，各自的姿态和辩解也不一样。站在第三方视角看，这类纷争的本质是：大模型公司投入巨额成本构建的数据飞轮，到底哪些部分可以被后来者复用，哪些部分是商业机密？目前没有统一答案，各家公司条款也不一致。

我认为健康的行业生态应该遵循三个原则：一是遵守许可协议，开源模型按许可证来，闭源 API 按服务条款来，这是底线；二是引用标注，用了别人的数据或模型做蒸馏，应当在技术报告中说明数据来源，学术界的 reproducibility 精神在产业界同样适用；三是价值增量，蒸馏不是终点，蒸馏之后必须做出老师模型做不好的东西，比如更低延迟、更大上下文、更垂直的能力。

前阵子有人提出过一个有趣的说法：蒸馏就像拜师学艺。你拜师学的是思维方式、行业门道，而不是把师傅的指纹、银行卡密码全偷走。前者叫传承，后者叫犯罪。这个类比虽然粗糙，但话糙理不糙。

5.3 对普通开发者的影响：你可以怎么用蒸馏而不惹祸

普通开发者和中小团队没必要因为这次新闻而“因噎废食”，更不该放弃蒸馏这个效率极高的技术方案。我建议你记住以下几条红线。

只对明确授权允许的模型做蒸馏。用开源模型蒸馏，先看 LICENSE 里有没有“不可用于训练其他模型”的限制条款。用商业 API 的输出做数据，先查阅服务条款，很多大厂 API 都禁止把输出用于训练“竞争性模型”。避免全量复制，哪怕是合法蒸馏，也不要把教师模型在特定风格或长尾场景下的输出原封不动搬来，尽量加一层自己的后处理和风格改写。

记录并公开你的蒸馏来源。一旦模型做大了，这种信息公开不仅是礼貌，也是自保。我看到越来越多公司在发布模型卡时明确写“基于 XX 模型蒸馏，遵循 XX 协议”，这才是把技术清白用在明面上的做法，也是对行业的正向示范。

6. 写在最后：我的一点个人观察

从技术角度看，蒸馏永远是大模型进化的加速器，没有任何理由因为商业争议而否定其价值。模型压缩、能力迁移、边缘部署，这些刚需场景少了蒸馏会寸步难行。

但从行业的角度看，这次“被点名”事件给所有从业者提了个醒：技术的下游是商业，商业的下游是规则。你可以跑得很快，但得知道跑道在哪里。

我个人的体会是：与其去争论谁偷了谁，不如把精力花在建立更透明的蒸馏实践上。把数据来源、训练方法、模型权重的血缘关系记录得清清楚楚，既能保护自己，也让整个行业少一些无意义的互撕。说不定几年之后再回头看，这次“点名”反而成了中国大模型行业从野蛮生长走向规范化的一个分水岭。

最后分享一个小技巧：当你想要用老师模型蒸馏又担心版权问题时，不妨先用老师模型生成数据，再通过自己的业务数据混合重写一遍。这个过程产生的数据已经带有你的场景特色，既保留了蒸馏的效率，又降低了“原样照抄”的风险。这套做法我用了很久，稳。