企业官网建设流程全解析

1. 从「蒸馏」这个词说起：它到底指什么

先把话说在前头，模型蒸馏不是什么见不得人的黑科技，它是深度学习领域一个非常经典、写在教科书里的模型压缩方法。最早可以追溯到 2015 年 Hinton 那篇《Distilling the Knowledge in a Neural Network》，核心思想特别朴素：让一个小模型去模仿一个大模型的输出分布，从而把小模型的能力拉高到接近大模型的水平。

打个生活化的比方。大模型像一位经验丰富的老教授，脑子里装了几十年积累的学识，但他讲课慢、开销大、走到哪都要带一堆设备。小模型像一个刚入学的年轻助教，脑子转得快、成本低、能同时给几百个班上课，但知识储备不够。蒸馏做的事情，就是让助教跟着老教授听课，不光听教授给出的「标准答案」，还要听教授对每个问题给出的「倾向性判断」——比如教授说这道题 70% 可能是 A，25% 可能是 B，5% 可能是 C。助教学到的不只是答案本身，还有教授判断问题时的「软信息」，这才是蒸馏真正的价值所在。

这里就引出一个关键概念：软标签（soft label）。传统训练用的是硬标签，答案非黑即白，是 A 就是 A。而蒸馏用的是教师模型输出的概率分布，也就是软标签。软标签里包含了类别之间的相似性信息，比如「猫」和「狗」的概率都比「汽车」高，这种信息是硬标签给不了的。小模型通过拟合这个分布，能学到更细腻的决策边界。

那怎么衡量两个分布的差距呢？这就用到了KL 散度（Kullback-Leibler Divergence）。KL 散度衡量的是两个概率分布之间的「距离」，蒸馏的损失函数通常就是学生模型的输出分布和教师模型的输出分布之间的 KL 散度，再乘上一个温度系数 T 做平滑。温度 T 越高，分布越平滑，软标签里的「暗知识」就越容易被学生捕捉到。这个 T 一般取 2 到 20 之间，太小了软标签退化成硬标签，太大了分布太平，学生学不到重点。

所以你看，蒸馏本身是一个中性的技术手段。问题不在于「蒸不蒸」，而在于「蒸什么」和「怎么蒸」。这就引出了标题里说的那件事——7 家中国公司被点名「蒸馏」，争议的焦点其实不在蒸馏技术本身，而在于蒸馏的数据来源和使用边界。

2. 被点名的「蒸馏」争议：偷走的到底是什么

要理解这场争议，得先搞清楚大模型行业里「蒸馏」这个词在两种语境下的不同含义。

第一种是技术意义上的蒸馏，就是我上面说的，用一个大模型当教师，训练一个小模型。这是完全合规的常规操作，很多开源小模型都是这么来的，比如一些 7B、13B 的模型，背后往往有更大的教师模型在指导。

第二种是数据意义上的蒸馏，也就是用另一个大模型的输出结果作为训练数据，来训练自己的模型。这种做法在行业里有个更通俗的说法叫「合成数据训练」或者「用 AI 生成的数据训 AI」。争议就出在这里。

打个比方。第一种蒸馏像是「我请了一位名师来给我自己的学生上课，学生学到了名师的思路」。第二种蒸馏像是「我把名师的讲义、习题、答案全部抄下来，整理成自己的教材，然后拿去卖」。前者是学习，后者就涉及到知识产权和商业道德的边界了。

那被点名的公司到底「偷走」了什么？从公开讨论来看，核心争议点集中在几个方面：

第一是输出数据的规模化采集。有些公司被质疑通过 API 大规模调用其他模型的接口，把返回结果存下来当训练数据。这种做法在技术上不难实现，写个脚本批量调用就行，但问题在于，很多模型的服务条款里明确写了「禁止用输出结果训练竞品模型」。你调 API 自己用没问题，但拿去训一个直接竞争的模型，这就踩线了。

第二是数据里隐含的能力迁移。大模型的输出不只是文字，它还隐含了模型在预训练阶段学到的世界知识、推理模式、语言风格。你用它的输出去训自己的模型，本质上是在「继承」它的能力。这种继承如果没经过授权，就相当于绕过了对方投入的巨额算力和数据成本。

第三是评测基准的污染。这个更隐蔽。如果训练数据里混入了某些评测集的题目和答案，那模型在评测上的表现就会虚高，给人一种「能力很强」的错觉。这在行业里叫「数据泄漏」或者「基准污染」，是评测领域的老大难问题。

我个人的判断是，这场争议的本质不是「蒸馏」这个技术有问题，而是数据来源的合规性和能力迁移的边界没有清晰的行业共识。大模型时代，什么算「合理使用」，什么算「侵权」，法律和行业规范都还在追赶技术发展的脚步。作为从业者，我的态度很明确：技术可以学，方法可以用，但数据来源必须干净，这是底线。

3. 蒸馏的技术原理拆解：从 KL 散度到温度系数

既然要聊蒸馏，那就把技术细节讲透。这一节我尽量用大白话把蒸馏的核心机制说清楚，不管你是刚入门还是已经做过微调，都能有所收获。

3.1 教师-学生框架的基本结构

蒸馏的标准框架包含两个模型：教师模型（Teacher）和学生模型（Student）。教师模型通常是大模型，参数量大、能力强，但推理慢、部署成本高。学生模型通常是小模型，参数量小、速度快，但单独训练的话能力有限。

训练过程是这样的：把同一批数据同时喂给教师和学生，教师输出一个概率分布（软标签），学生也输出一个概率分布，然后计算两个分布的 KL 散度作为损失，反向传播更新学生的参数。教师模型的参数是冻结的，不参与更新。

这里有个细节很多人会忽略：教师模型不一定非要是一个完整的大模型。在实际工程里，教师可以是多个模型的集成（ensemble），也可以是同一个模型在不同训练阶段的快照。集成蒸馏的效果往往比单教师更好，因为多个教师的软标签平均之后，噪声更小，信息更稳定。

3.2 温度系数 T 的作用与选择

温度系数 T 是蒸馏里最关键的参数。它的作用是把 softmax 的输出分布「平滑化」。公式是这样的：

softmax(z_i / T) = exp(z_i / T) / sum(exp(z_j / T))

当 T=1 时，就是标准的 softmax。当 T>1 时，分布变得更平滑，原本概率很低的类别也会分到一些概率，这些「小概率」里往往藏着教师模型的「暗知识」。当 T<1 时，分布变得更尖锐，接近硬标签。

T 怎么选？我的经验是：

• 对于分类任务，T 一般取 2 到 10 之间。
• 对于语言模型这种输出空间极大的任务，T 可以取到 20 甚至更高，因为词表动辄几万，分布本身就很稀疏，需要更高的温度才能让软标签携带足够的信息。
• T 太大也不行，分布太平了，学生学到的信号会被噪声淹没。

实际调参的时候，我一般会先固定 T=4 跑一版 baseline，然后以 2 的步长上下扫，看验证集上的表现。这个参数对最终效果的影响比学习率还敏感，值得多花时间。

3.3 损失函数的组合策略

蒸馏的损失通常不是单一的 KL 散度，而是「蒸馏损失 + 学生自身的任务损失」的加权组合：

L = alpha * KL(student_soft, teacher_soft) + (1 - alpha) * CE(student_logits, hard_label)

其中 alpha 是权重系数，CE 是交叉熵损失。这个组合的意义在于：KL 散度让学生学教师的「软判断」，交叉熵让学生学真实标签的「硬答案」。两者结合，学生既能继承教师的能力，又不会完全偏离真实任务。

alpha 一般取 0.5 到 0.9 之间。如果教师模型质量很高，alpha 可以调大一些；如果教师本身有噪声，alpha 就要调小，多依赖真实标签。

3.4 蒸馏与微调的区别

很多人会把蒸馏和微调搞混，这里必须澄清一下。

微调（Fine-tuning）是在一个预训练好的模型基础上，用特定领域的数据继续训练，让模型适应新任务。微调不涉及模型结构的变化，也不涉及教师-学生框架。

蒸馏（Distillation）是训练一个小模型去模仿大模型，核心是模型压缩和能力迁移。蒸馏出来的学生模型，结构可以和教师完全不同，参数量也可以小很多。

两者可以结合使用：先蒸馏得到一个小的基座模型，再对这个基座做领域微调。这种「先蒸后调」的流程在实际工程里很常见，尤其是需要把模型部署到边缘设备上的场景。

4. 大模型蒸馏的实操流程：从数据准备到部署

光讲原理不够，这一节我把一个完整的蒸馏流程拆开，给你一套可以直接参考的操作方案。需要说明的是，以下步骤是基于行业常见实践整理的，具体参数需要根据你的任务和数据做调整。

4.1 数据准备：蒸馏的燃料

蒸馏对数据的要求和普通训练不太一样。普通训练只要有输入和标签就行，蒸馏还需要教师模型对每条输入的输出分布。

数据准备分三步：

第一步，收集输入数据。这些数据可以是你自己的业务数据，也可以是公开数据集。关键是输入要覆盖你关心的任务分布。比如你要蒸一个客服对话模型，那输入就应该是真实的用户问题，而不是随便找一堆新闻文本。

第二步，跑教师模型生成软标签。把输入数据批量喂给教师模型，保存每个位置的输出 logits 或者概率分布。这里有个工程上的坑：logits 的存储开销很大。如果词表是 5 万，序列长度是 512，那一条样本的 logits 就是 5万 × 512 个浮点数，按 float32 算就是 100MB 左右。一万条样本就是 1TB。所以实际工程里通常只存 top-k 的概率和对应的 token id，k 一般取 10 到 50 就够了。

第三步，数据清洗和过滤。教师模型的输出不一定都是对的，有些样本教师自己就答错了，或者输出分布很平（说明教师也不确定）。这些样本要过滤掉，否则学生学到的是噪声。我一般会设一个置信度阈值，比如教师输出的最大概率低于 0.5 的样本直接丢弃。

4.2 学生模型的选择与初始化

学生模型的选择取决于你的部署目标。如果目标是手机端，那可能得选 1B 以下的模型；如果是服务器端，7B 到 13B 都可以考虑。

学生模型的初始化有两种策略：

• 随机初始化：从头训，适合学生和教师结构差异很大的情况。
• 用教师的部分层初始化：比如取教师的底层若干层作为学生的初始化，适合学生是教师的「缩小版」的情况。

我个人的经验是，如果学生和教师的架构同源（比如都是 Transformer decoder），用教师的部分层初始化能显著加快收敛。如果架构不同，那就老老实实随机初始化。

4.3 训练配置与关键参数

训练配置这块，我把关键参数列个表，方便你对照：

这里重点说下学习率。蒸馏的学习率要比普通训练小，因为软标签提供的梯度信号比硬标签更「柔和」，学习率大了容易震荡。我一般从 2e-5 开始试，如果 loss 下降太慢再往上调。

4.4 蒸馏效果的评估方法

蒸馏完了怎么知道效果好不好？不能只看 loss，得看实际任务指标。

我一般会做三组对比：

1. 学生 vs 教师：看学生能恢复到教师多少能力。一般能到 90% 以上就算成功。
2. 学生 vs 同规模从头训练的模型：看蒸馏带来的增益。这个增益通常在 5 到 15 个百分点。
3. 学生 vs 学生（不同蒸馏配置）：做消融实验，看哪个参数最关键。

评估集一定要用教师没见过的数据，否则教师可能「背过答案」，学生跟着学就虚高了。

5. 蒸馏之外：大模型能力迁移的几种路径

蒸馏只是大模型能力迁移的一种方式。实际工程里，还有几种常见路径，我一起说了，方便你根据场景选。

5.1 微调：最直接的领域适配

微调是用领域数据继续训练预训练模型。和蒸馏的区别在于，微调不涉及教师-学生框架，就是拿一个现成模型接着训。

微调的关键是数据质量。我见过太多团队，数据量堆到几十万条，但标注质量参差不齐，训出来的模型还不如用几千条高质量数据微调的效果好。数据质量 > 数据数量，这是铁律。

微调还有个坑是灾难性遗忘。模型在学新任务的时候，会把原来的通用能力忘掉。解决办法是混合训练：把领域数据和一部分通用数据混在一起训，比例大概是 1:1 到 1:3。

5.2 提示工程：不改变模型参数的轻量方案

提示工程（Prompt Engineering）是通过设计输入提示来引导模型输出，不改变模型参数。这是成本最低的方案，适合快速验证场景。

提示工程的核心是「把话说清楚」。我总结了一个模板：角色 + 任务 + 约束 + 示例。比如：

你是一个专业的客服助手。请根据用户问题给出回答。 要求：回答不超过 100 字，语气友好，不要编造信息。 示例： 用户：怎么退货？ 回答：您可以在订单页面点击「申请退货」，填写原因后提交，我们会在 24 小时内处理。

这个模板看起来简单，但实际用起来效果比随便写一句「回答用户问题」好很多。

5.3 RAG：外挂知识库的方案

RAG（Retrieval-Augmented Generation）是把外部知识库检索和模型生成结合起来。模型本身不记住知识，而是在回答时实时检索相关文档，把文档内容作为上下文喂给模型。

RAG 的好处是知识可以随时更新，不用重新训练模型。适合知识更新频繁的场景，比如新闻问答、产品文档助手。

RAG 的难点在检索质量。检索不准，模型拿到的上下文就是错的，回答自然好不了。我一般会用「向量检索 + 关键词检索」的混合方案，向量检索负责语义匹配，关键词检索负责精确匹配，两者结合效果更稳。

5.4 几种路径的对比与选型

选型逻辑很简单：先看部署环境，边缘设备优先蒸馏；再看知识更新频率，频繁更新优先 RAG；最后看任务复杂度，简单任务提示工程就够，复杂任务上微调。

6. 实操中踩过的坑与排查技巧

这一节是我自己踩坑踩出来的经验，文档里不会写，但实际做的时候一定会遇到。

6.1 蒸馏 loss 不下降的几种原因

原因一：温度 T 设错了。T 太小，软标签退化成硬标签，蒸馏退化成普通训练；T 太大，分布太平，梯度信号太弱。解决办法是扫一遍 T，看 loss 曲线。

原因二：教师模型本身不行。如果教师在自己任务上表现就一般，那学生学到的也是半吊子。蒸馏之前先评估教师，教师不行就先换教师。

原因三：alpha 权重失衡。alpha 太大，学生完全跟着教师走，忽略了真实标签；alpha 太小，蒸馏没起到作用。建议从 0.7 开始试。

原因四：学习率太大。软标签的梯度比硬标签柔和，学习率大了容易震荡。把学习率降到 1e-5 试试。

6.2 学生模型「学歪了」怎么办

「学歪了」的表现是：在训练集上 loss 很低，但验证集上表现很差。这是过拟合的典型症状。

解决办法有几个：

• 加数据：最直接，但成本高。
• 加正则：dropout、weight decay 都可以上。
• 早停：验证集 loss 不降了就停，别硬训。
• 数据增强：对输入做扰动，让模型学到更鲁棒的特征。

我个人的经验是，蒸馏场景下过拟合往往是因为训练数据太少。蒸馏的数据效率虽然比普通训练高，但也不是万能的，几千条数据想蒸出一个好模型，不现实。

6.3 部署时的性能优化

蒸馏出来的模型最终是要部署的，部署时的性能优化也很关键。

量化：把 float32 转成 int8，模型体积缩小 4 倍，推理速度提升 2 到 3 倍，精度损失通常在 1% 以内。这是性价比最高的优化手段。

算子融合：把多个连续的操作合并成一个，减少内存访问。比如 LayerNorm + Linear 可以融合，Attention 里的 QKV 计算可以融合。

KV Cache：自回归生成的时候，把之前算过的 key 和 value 缓存起来，避免重复计算。这是大模型推理的标配优化。

批处理：把多个请求攒在一起推理，提高 GPU 利用率。但要注意延迟和吞吐的权衡，batch 太大延迟会上去。

6.4 常见问题速查表

7. 关于这场争议，我的一些个人看法

聊完技术，回到标题里那件事。7 家中国公司被点名「蒸馏」，这件事在行业里引起的讨论，其实反映了一个更深层的问题：大模型时代，能力迁移的边界在哪里。

我的看法是，技术本身没有原罪。蒸馏、微调、RAG，这些都是工具，工具怎么用取决于人。用干净的数据、合规的方式做能力迁移，这是正常的工程实践；用别人的输出大规模训练竞品，这就越界了。

作为从业者，我觉得有几条底线是必须守的：

第一，数据来源要可追溯。你用的每一条训练数据，来源是什么，授权范围是什么，心里要有数。别等到出事了才去查。

第二，尊重服务条款。用别人的 API，就按别人的规则来。条款里写了不能训竞品，那就别训。这不是技术问题，是契约精神。

第三，评测要诚实。别往训练数据里掺评测集，别在评测上做手脚。模型能力不行就承认，回去继续优化，别搞虚的。

这场争议对行业来说未必是坏事。它让更多人开始关注数据合规、能力边界这些之前被忽视的问题。大模型行业要健康发展，光靠技术突破不够，还得有规则和共识。

最后说个我自己的体会。做模型这些年，我越来越觉得，技术能力决定你能走多快，但合规意识决定你能走多远。那些在数据来源上偷懒的团队，短期可能跑得快，但长期一定会付出代价。老老实实做数据、做标注、做合规，慢是慢了点，但走得稳。

如果你也在做大模型相关的项目，我的建议是：把数据合规当成和模型效果同等重要的事情来抓。别等到被点名了才后悔。