番外：模型蒸馏：把大模型的能力倒进小模型里

过去一两年，AI 圈里经常会出现一种说法：

某某模型是不是蒸馏了 GPT？
某某国产大模型是不是把 Claude、GPT、Gemini 的输出混在一起训出来的？
某个小模型怎么突然在数学、代码、推理上这么强？

类似传闻也会围绕一些国内外模型出现，比如有人会猜测腾讯混元、DeepSeek、Qwen、Llama 系列的某些版本是否使用过其他强模型的输出。这里面有些是严肃的技术讨论，有些是竞争对手之间的商业攻防，也有不少只是「看起来很像」之后的猜测。

要理解这些讨论，首先要把「蒸馏」这件事讲清楚。

一句话概括：

模型蒸馏就是让一个更小、更便宜、更容易部署的学生模型，去学习一个更大、更强、更昂贵的教师模型的行为。

一、为什么叫「蒸馏」？

「蒸馏」这个词来自化学：把混合物加热，利用不同成分的沸点差异，把想要的成分提取出来。

在机器学习里，这个比喻大概是：

教师模型：大、慢、贵，但能力强
学生模型：小、快、便宜，但能力弱
蒸馏过程：让学生模型模仿教师模型在大量输入上的输出
目标：把教师模型中对任务有用的行为，压缩进学生模型

经典知识蒸馏由 Hinton、Vinyals 和 Dean 在 2015 年系统化提出。他们当时关心的问题很朴素：一个模型集成或大模型虽然效果好，但部署太重，能不能把它学到的判断方式转移给一个小模型？

蒸馏的关键，不只是让学生模型学习「正确答案」，更要让学生模型学习教师模型对所有候选答案的「判断分布」。

例如图片分类任务中，最终答案可能只告诉你：

这是一只猫。

但教师模型的输出，可能会给出更细的概率：

猫：0.84
狐狸：0.08
狗：0.05
汽车：0.0001

这些「错误答案之间的相对概率」其实包含很多知识。它告诉学生模型：猫和狐狸、狗在视觉特征上比猫和汽车更接近。这个信息比单独一个正确答案更细腻、丰富。

这就是蒸馏的第一层含义：学生模型需要学习教师模型的泛化方式，而不只是记住训练集答案。

二、经典蒸馏是怎么做的？

最经典的知识蒸馏通常出现在分类任务里。

流程大致如下：

1. 先训练或选择一个强教师模型
2. 准备一批训练样本，可以有标签，也可以没有标签
3. 把样本喂给教师模型，拿到教师模型输出的概率分布
4. 训练学生模型，让它的输出分布尽量接近教师模型
5. 如果有真实标签，再同时让学生模型学习真实标签

这里有一个很重要的概念叫「软标签」。

普通监督学习，用的一般是「硬标签」，它一般来自人类专家的打标：

正确答案 = 猫

蒸馏用的是「软标签」，它来自教师模型输出的概率分布：

猫 0.84，狐狸 0.08，狗 0.05，汽车 0.0001 ...

数学上，教师模型会输出 logits，也就是进入 softmax 之前的一组分数。蒸馏时通常会引入一个 temperature，让概率分布变得更「软」：

当 temperature 变大时，原本非常尖锐的概率分布会被摊平。学生模型就不只是看到「猫是正确答案」，还会看到「狐狸比汽车更像猫」。

训练目标可以理解成两部分：

其一：学生模型要接近教师模型的软输出
其二：学生模型也要接近真实标签

这也是为什么蒸馏经常比单纯用标注数据训练小模型更有效。教师模型把自己的「相似性结构」「边界判断」「不确定性」一并传给了学生。

三、LLM 时代的蒸馏有什么不同？

到了大语言模型时代，事情变复杂了。

传统分类模型的输出空间比较明确，比如 1000 个类别。教师模型可以给出每个类别的概率。学生模型只要学习这个概率分布就行。

但 LLM 的输出空间是整个 token 词表，而且每一步都在预测下一个 token。理论上，你当然可以做 token-level 蒸馏：

给定上下文 x
教师模型输出下一个 token 的概率分布
学生模型学习这个概率分布
重复到每一个生成位置

如果你拥有教师模型的 logits，这种做法很自然。

问题是，大多数闭源大模型 API 并不会把完整 logits 暴露给你。你通常只能拿到最终文本，最多拿到少量 logprob 信息。因此，LLM 时代最常见的蒸馏形式变成了另一种：

准备大量问题或任务指令
让强模型生成高质量回答
把这些「问题-回答」作为训练数据
拿去监督微调一个较小的学生模型

这叫 sequence-level distillation，或者更宽泛地说，是行为蒸馏。

它不要求学生模型逐 token 匹配教师模型的完整概率分布，而是让学生学习教师模型在某类任务上的最终行为：

用户这样问时，应该这样答。
要求 JSON 时，应该严格输出 JSON。
遇到数学题时，应该分步骤求解。
遇到危险请求时，应该拒绝并给出安全替代。
写代码时，应该给出可运行、可解释的实现。

所以在 LLM 语境里，大家口中的「蒸馏」经常不是严格的经典知识蒸馏，而是一大类用强模型生成训练信号的做法。

四、一个典型的 LLM 蒸馏流程

如果把它拆成工程流程，LLM 蒸馏大概会长这样：

目标定义 -> 学生模型选择 -> 任务集构造 -> 教师生成 -> 数据过滤
        -> 监督微调 -> 偏好对齐 -> 评测对比 -> 部署监控

逐步展开看。

1. 先定义要蒸馏什么能力

蒸馏不是「做一个小号 GPT」这么抽象。

真正可落地的目标通常更具体：

客服问答
代码补全
SQL 生成
数学解题
合同审阅
医疗分诊
广告文案生成
企业知识库问答
多轮工具调用
固定格式的数据抽取

目标越清晰，蒸馏越有效。

因为学生模型容量有限，不可能把教师模型的所有能力都装进去。你需要决定：哪些能力值得学，哪些能力不重要，哪些边界必须保留。

2. 选择学生模型

学生模型通常来自一个已经预训练好的开源或自研基础模型。

例如：

7B / 8B：便宜、快，适合单机或低成本服务
14B / 32B：能力更强，成本仍可控
70B 级别：接近强模型体验，但部署成本明显更高
MoE 模型：总参数大，但每个 token 只激活部分专家

蒸馏不是从零训练。它通常建立在一个已经有语言能力和世界知识的基础模型上，再用教师数据把某些行为「推」到目标形态。

3. 构造任务分布

这是最容易被低估的一步。

你要让教师模型回答什么问题，学生模型最后就会更像什么样的系统。

如果任务集全是考试题，学生模型会更像考试机器；如果任务集全是客服对话，它会更像客服助手；如果任务集全是代码修 bug，它会更像代码助手。

一个好的任务集通常需要覆盖：

常见问题
长尾问题
困难问题
边界问题
格式约束
多轮上下文
错误输入
拒答场景
领域术语
真实用户表达

这也是为什么蒸馏不是单纯「买很多 API token 然后开跑」。真正值钱的是任务分布设计、数据治理和评测体系。

4. 让教师模型生成答案

教师可以是一个模型，也可以是多个模型。

多教师蒸馏很常见：

数学题让擅长推理的模型答
代码题让擅长代码的模型答
中文写作让中文能力强的模型答
安全拒答让对齐更稳的模型答
再用一个 critic 模型做质量评审

这样做的好处是可以融合多个教师的优势。

但坏处也很明显：不同教师模型的风格、边界、事实判断可能互相冲突。你需要一个仲裁机制，决定哪个答案进入训练集，哪个答案被丢掉。

5. 清洗、过滤和去重

这一环节非常关键。

教师模型也会犯错。它可能幻觉，可能输出格式不稳定，可能在复杂题上给出看似有理但实际错误的推理。

所以蒸馏数据通常需要过滤：

格式校验：JSON 是否合法，代码是否可运行
事实校验：引用是否真实，答案是否可验证
一致性校验：多次采样答案是否一致
安全校验：是否包含不该学习的内容
去重校验：是否和评测集、训练集高度重合
质量评分：由人类、规则或模型评审打分

很多蒸馏项目失败，不是因为学生模型不行，而是因为把脏数据、错数据、风格混乱的数据喂进去了。

6. 监督微调学生模型

拿到高质量的「指令-回答」数据后，就可以对学生模型做 SFT，也就是监督微调。

训练目标很直接：

给定用户问题，让学生模型生成教师答案。

从 next-token prediction 的角度看，就是让学生模型在这些样本上最大化教师答案的概率。

比如训练样本是：

用户：解释一下什么是 RAG。
教师：RAG 是 Retrieval-Augmented Generation 的缩写……

学生模型要学会：在类似上下文后，应该接出类似质量、类似结构、类似边界的回答。

7. 做偏好对齐

如果只是 SFT，学生模型可能已经像教师了，但还不一定稳。

接下来可以继续构造偏好数据：

同一个问题，生成多个候选答案
让教师模型、人类标注员或 reward model 判断哪个更好
用 DPO / RLHF / RLAIF 等方法进一步对齐

这一步让学生模型不只是模仿某个答案，而是学习「什么样的答案更值得输出」。

8. 评测、上线和监控

最后要验证三个问题：

能力有没有接近教师？
成本和延迟有没有显著下降？
风险有没有被一起蒸馏进来？

评测不能只看通用榜单。对于产品团队，真正重要的是目标场景：

客服解决率
代码通过率
SQL 执行正确率
JSON 合法率
工具调用成功率
拒答准确率
人工接管率
每千次请求成本
P50/P95 延迟

蒸馏的目标不是在所有榜单上打败教师，而是在目标任务上用更低成本获得足够好的体验。

五、为什么要做蒸馏？

最直接的答案是：钱。

大模型推理很贵。参数越多、上下文越长、输出越长、并发越高，成本就越明显。

如果一个业务每天只调用几千次，直接用最强闭源模型可能很舒服。但如果每天调用几千万次，单位 token 成本、延迟、限流和稳定性都会变成大问题。

蒸馏能带来几类价值。

1. 降低推理成本

一个 7B 或 14B 模型的推理成本，可能远低于一个 100B 甚至更大模型。

如果目标任务足够固定，蒸馏后的小模型可以用很低的成本完成大部分请求。强模型只在困难样本、低置信样本或兜底场景里出现。

产品架构上可以变成：

普通请求 -> 小模型
复杂请求 -> 大模型
高风险请求 -> 大模型 + 人工审核

这比所有请求都打到最强模型上更经济。

2. 降低延迟

小模型通常更快，尤其适合：

实时输入补全
客服秒回
移动端本地推理
语音对话
IDE 代码补全
高并发 API

有时候用户体验的瓶颈不是「模型差一点」，而是「模型慢半秒」。在这些场景里，蒸馏后的学生模型可能比教师模型更适合产品。

3. 本地化和私有化部署

很多企业不希望核心数据离开自己的环境。

这时，一个可私有化部署的小模型很有价值：

企业内网知识问答
金融、医疗、政务场景
离线设备
边缘计算
隐私敏感工作流

蒸馏可以把强模型帮助生成的数据，转化为一个可控、可部署、可审计的内部模型。

前提是数据来源、教师模型授权和训练流程都合规。

4. 专门化能力更稳定

通用大模型什么都会一点，但产品场景往往要的是「某件事稳定做好」。

例如一个合同审阅助手，不需要会写诗、讲冷笑话、解高等数学。它需要稳定识别条款风险、输出固定格式、引用原文、给出修改建议。

蒸馏可以把模型行为收窄：

更懂领域术语
更遵守输出格式
更少跑题
更少废话
更符合产品语气
更容易被评测和监控

这也是很多垂直模型存在的意义。

5. 把昂贵标注变便宜

高质量人工标注很贵，尤其是数学、代码、法律、医疗这种需要专家的领域。

教师模型可以作为「初级标注员」或「数据生成器」：

生成题目
生成答案
生成解释
生成反例
改写用户表达
补充边界样本
给候选答案打分

人类专家再做抽检、纠错和规则设计。这样可以把纯人工数据生产，变成「模型批量生成 + 人类高价值审核」。

六、蒸馏到底能学到什么？

蒸馏能学到的是教师模型的外显行为，而不是教师模型的全部内部知识。

这句话很重要。

学生模型只能从训练数据中看到：

教师在某个输入下输出了什么
教师如何组织答案
教师如何处理格式
教师在某些场景下拒绝
教师在某些题型上采用怎样的推理样式

它看不到：

教师模型的参数
教师训练时见过的全部数据
教师内部激活和表示
教师隐藏的系统提示
教师没有在样本中表现出来的能力

所以蒸馏不是复制灵魂。

如果学生模型很小、数据覆盖不够、训练方法粗糙，它只能学到教师的表面风格。比如学会「首先、其次、最后」的结构，学会类似的拒答口吻，但真正复杂推理仍然不行。

更进一步，蒸馏还可能把教师的缺点一起学走：

幻觉
偏见
过度自信
冗长表达
错误的拒答边界
对某些 benchmark 的过拟合
特定模型的口癖和格式依赖

这就是为什么蒸馏一定要配合评测和清洗。

七、蒸馏、微调、RAG、量化有什么区别？

这些词很容易混在一起。

可以这样区分：

蒸馏和微调经常一起出现。

如果微调数据来自人类专家，那就是普通监督微调；如果微调数据主要来自教师模型，那就带有蒸馏性质。

RAG 和蒸馏也可以互补：

RAG 解决「知识在哪里」
蒸馏解决「模型怎么回答」

比如企业知识库问答可以用 RAG 找资料，同时用蒸馏让小模型学会固定的回答结构、引用格式和拒答边界。

八、为什么外界会怀疑某个模型被蒸馏？

因为很多外部信号看起来确实会让人联想到蒸馏。

例如：

小模型突然在某些能力上接近大模型
回答风格和某个闭源模型高度相似
拒答话术、格式习惯、口癖很像
benchmark 成绩快速跃升
复杂题上的错误模式相似
模型在某些英文提示下暴露类似系统习惯

但这些信号都不能单独证明蒸馏。

原因也很简单：

很多模型都学过类似的公开数据
很多团队会用相似的后训练方法
很多产品会模仿行业最佳回答风格
很多 benchmark 本身已经进入公共训练语料
很多模型都会被同一批评测题「塑形」

如果没有训练数据、API 调用记录、授权协议、内部日志或系统性水印证据，外部通常只能说「可疑」或「相似」，很难说「确定」。

以混元这类模型为例，公开技术报告里会提到合成数据、专门模型生成、响应过滤、MoE 架构、KV cache 压缩等训练实践。合成数据是现代 LLM 训练的常规组成部分，但「使用合成数据」不等于「未经授权蒸馏某个闭源模型」。这两件事不能混为一谈。

九、合规问题：能做，不代表可以随便做

技术上，蒸馏并不神秘。

真正敏感的是数据来源和授权边界。

如果教师模型是你自己训练的，或者是明确允许用于训练学生模型的开放模型，那么蒸馏通常是正常的模型压缩和产品工程手段。

但如果你通过闭源 API 大规模获取输出，再用这些输出训练一个竞争模型，就可能违反服务条款、合同约定或知识产权相关规则。

例如：

OpenAI 的企业服务协议限制使用输出开发与 OpenAI 竞争的 AI 模型。
Anthropic 的商业条款也限制访问其服务来训练竞争性 AI 模型或构建竞争产品。

这里还有几个容易踩坑的问题：

输出权属：用户可能拥有输出，但仍受服务条款限制
自动化抓取：大规模调用、绕过限流、批量采集可能违反规则
数据隐私：用真实用户输入生成训练集，可能涉及个人信息和商业机密
安全边界：把教师模型的拒答策略蒸馏错了，可能放大安全风险
来源披露：开源模型如果使用外部教师数据，社区会关心透明度和许可

所以更准确的说法是：

蒸馏是一种中性的技术；合不合适，取决于教师模型、数据来源、授权协议、使用场景和披露方式。

十、蒸馏会不会让大模型的护城河消失？

会消失一部分。

说「部分会」，是因为蒸馏确实能把某些能力扩散出去。

当强模型已经展示出某类任务怎么做，小模型就可以通过合成数据和微调快速追赶。尤其是格式化任务、垂直问答、代码样板、数学题型、工具调用模板，这些能力很容易被蒸馏和复刻。

这会让很多「只靠调用最强模型」的产品差异变小。

但护城河不会「完全消失」，因为蒸馏也有天花板。

1. 学生模型容量有限

一个小模型不可能无限吸收教师模型的所有能力。

它可以在窄任务上接近教师，但在开放域、多语言、复杂推理、长上下文、工具规划、罕见知识等场景里，容量和训练底座仍然会限制上限。

2. 教师没展示的能力学不到

蒸馏依赖样本覆盖。

如果任务集中没有覆盖某类复杂场景，学生模型就没有机会学。教师模型内部也许会，但学生没见过。

3. 数据质量比调用量更重要

简单粗暴地生成一亿条低质量样本，不一定比精心设计的一百万条好。

蒸馏的核心竞争力不只是「谁有教师 API」，而是谁更懂：

什么问题值得生成
什么答案值得保留
什么错误必须过滤
什么能力应该评测
什么体验应该优化

4. 前沿能力仍然来自预训练和系统工程

真正的前沿模型能力，仍然依赖大规模预训练、数据混合、模型结构、训练稳定性、强化学习、推理时计算、基础设施和产品反馈闭环。

蒸馏可以追赶已经显化的能力，但很难凭空创造尚未被教师展示的新能力。

十一、从产品视角怎么看蒸馏？

如果你是产品经理，没必要把蒸馏理解成一个纯算法术语。

你可以把它理解成一种产品工程策略：

先用最强模型探索正确行为，
再把高频、稳定、可评测的行为沉淀到更便宜的模型里。

这非常像产品里的标准化：

早期：靠专家手工处理
中期：总结 SOP 和模板
后期：训练新人或系统自动处理

强模型像专家，学生模型像经过训练的一线员工。

专家不可能处理每一个请求，但专家可以帮助你定义流程、制造样本、校准标准。等流程稳定后，很多请求就可以交给成本更低、响应更快的系统。

所以一个成熟的 AI 产品，未来可能不是「所有请求都打到一个最强模型」，而是一个模型组合：

小模型处理高频简单任务
中模型处理一般复杂任务
强模型处理困难任务和兜底
规则系统处理确定性约束
RAG 提供外部知识
评测系统持续发现坏 case
人工专家定期修正数据和标准

在这个架构里，蒸馏是把强模型能力产品化、规模化、成本可控化的一种重要手段。

十二、最后，怎么判断一个蒸馏项目是否靠谱？

可以问几个问题：

它蒸馏的是哪类任务，而不是笼统说「全能力」？
教师模型和数据来源是否有授权？
学生模型基座是什么，容量是否匹配目标？
训练数据如何生成、过滤、去重和审计？
有没有独立评测集，而不是只看训练分布内表现？
是否比较了教师、学生、原始基座和人工基线？
成本、延迟、成功率、安全性是否一起评估？
上线后是否持续收集失败案例并迭代？

如果这些问题答不上来，那它可能只是把「蒸馏」当成一个好听的包装词。

如果这些问题都能答清楚，蒸馏就不是玄学，而是一套非常实用的大模型工程方法。

参考与延伸阅读

• Distilling the Knowledge in a Neural Network ：Hinton、Vinyals、Dean 的经典知识蒸馏论文。
• Knowledge Distillation Using Frontier Open-source LLMs ：讨论 LLM 蒸馏、合成数据、推理链和评测陷阱。
• Hunyuan-Large: An Open-Source MoE Model with 52 Billion Activated Parameters by Tencent ：腾讯混元大模型公开技术报告，其中介绍了合成数据、MoE 和后训练等实践。
• OpenAI Services Agreement ：其中包含对使用输出开发竞争性 AI 模型的限制。
• Anthropic Commercial Terms of Service ：其中包含对使用服务训练竞争性 AI 模型的限制。