大模型蒸馏到底是什么？硬蒸、软蒸？

最近聊大模型，总绕不开 “蒸馏” 这个词。 一会儿说谁家模型是 “硬蒸” 出来的，一会儿又说 “软蒸” 才是真技术，还有人调侃现在行业就是 “谁家模型强就蒸谁家”。不少朋友听了一头雾水：蒸馏到底是啥？真的就是抄别人的模型吗？硬蒸和软蒸差在哪？

今天咱们不堆公式，不说面试黑话，就用最直白的话，把模型蒸馏这件事掰开揉碎讲清楚。

一、先搞懂：蒸馏，到底 “蒸” 的是什么？

很多人对蒸馏的第一个误解，是以为它像压缩文件一样 —— 把千亿参数的大模型 “压一压”，就变成了几十亿参数的小模型。 如果真有这么简单的事，大模型公司也不用烧几十亿去训练了，大家点个 “压缩” 按钮就行。

模型蒸馏的核心，从来不是复制参数，而是迁移行为。 你可以把它理解成一场 “师生教学”：能力强的大模型是老师，小模型是学生。老师不会把自己的大脑直接拆给学生，但学生可以通过观察老师的答题方式、推理过程、判断偏好，慢慢练出一套接近老师的输出能力。

整个过程的逻辑非常朴素：

1. 准备一批覆盖目标任务的问题；
2. 让强大的老师模型逐一给出回答、推理甚至判断结果；
3. 把这些输出清洗、整理成高质量的训练数据；
4. 用这批数据去训练小模型，让它模仿老师的行为；
5. 最后用评测验证效果，再反过来补充数据、优化迭代。

换句话说，蒸馏学的不是老师的 “脑子”，而是老师的 “答题习惯”。它不是一条直线的压缩过程，而是一个由数据质量驱动的闭环 —— 数据越准、越全，学生模型学到的能力就越接近老师。

二、硬蒸 vs 软蒸，差别到底在哪？

行业里常说的 “硬蒸”“软蒸”，本质区别只有一个：老师到底给了学生多少信息。

硬蒸馏：只学最终答案

硬蒸是最常见、也最粗暴的方式。 就像做选择题，老师只告诉你正确选项是 A，至于为什么选 A、其他选项错在哪，一概不说。学生要做的，就是记住 “这个问题对应这个答案”，然后学着输出相似的结果。

对应到训练里，硬蒸的数据格式通常就是简单的 “问题 - 答案” 对。它的优点非常明显：简单、成本低，哪怕只能通过 API 调用闭源模型，也能做。 但缺点也同样突出：学生只学到了 “怎么答”，没学到 “为什么这么答”，遇到稍微变形的问题，就很容易出错。

软蒸馏：连判断逻辑一起学

软蒸就高级得多。 老师不只会告诉你正确答案是 A，还会告诉你：A 的可能性是 80%，B 有 15% 的相似度，C 基本不沾边。这种带概率分布的标签，也叫 “软标签”。

学生从里面学到的，就不只是一个结论，而是答案之间的相似度和判断边界。它会知道 “虽然 B 不对，但它比 C 更接近正确答案”，对任务的理解会更细腻，泛化能力也更强。

但软蒸有一个现实门槛：它通常需要拿到模型内部的输出概率分布（也就是 logits）。而绝大多数闭源模型的 API，根本不会开放这些内部信息。所以我们常听到的 “蒸馏别家模型”，大多都不是严格意义上的软蒸，而是黑盒场景下的硬蒸馏。

顺便说清：白盒蒸馏与黑盒蒸馏

和硬蒸软蒸对应的，还有一组概念：白盒与黑盒，它说的是你能接触到老师模型的多少内部信息。

• 白盒蒸馏：能拿到模型的概率分布、中间层表示、注意力信息等内部信号，信息量大，训练效果上限更高。这种一般只用在自家模型体系里，或者基于开源模型做蒸馏。
• 黑盒蒸馏：完全看不到模型内部，只能通过 API 提问、拿到最终文本回答。闭源模型 API 都属于这种，技术门槛不高，麻烦的是成本、数据质量和合规风险。

三、行业 “互相蒸馏”，是公开的秘密吗？

聊蒸馏就绕不开一个话题：现在大模型厂商，真的都在互相蒸吗？

为什么大家都想 “蒸” 别人的模型？

答案很现实：从零训练一个顶尖大模型，成本太高了。算力、数据、工程、对齐，每一项都是天文数字的投入。 但如果用别人已经训练好的强模型 API，批量生成问答数据，再用来训练自己的小模型，成本会低得多。相当于用别人的技术积累，做自己的训练数据。 也正因为如此，行业里一直有个灰色共识：谁家模型效果好，谁家就会成为被采样、对齐、蒸馏的目标。

技术可行，不代表合规

但这件事从来不是 “各凭本事” 这么简单。 几乎所有闭源大模型厂商，都在服务条款里明确限制：禁止用自动化方式批量提取模型输出，也禁止用输出内容训练与自身有竞争关系的模型。OpenAI、Anthropic 的条款里都写得非常清楚。

换句话说：

• 用自家大模型蒸馏自家小模型，完全没问题；
• 用开源模型、授权数据做蒸馏，也没问题；
• 但批量调用闭源 API，拿别人的输出训练竞品模型，很可能直接违反服务协议。

过去几年，这类争议也从没停过：从 DeepSeek 爆火时被外媒质疑不当使用 OpenAI API，到 Anthropic 公开点名国内公司通过大量账号批量交互提取模型能力，再到马斯克在法庭上承认 “这是 AI 公司间的普遍做法”…… 灰色地带一直存在，但我们不能因此说 “所有公司都在互相蒸馏”—— 行业里依然有很多团队坚持从零做自研，不能一竿子打死。

四、蒸馏的常见玩法，远不止抄答案

很多人以为蒸馏就是 “拿问答对训模型”，其实根据学习目标不同，蒸馏的玩法非常多，工程价值也完全不一样。

1. 响应蒸馏：最基础的 “抄答案”

就是最常见的问答对训练，让小模型学习大模型的最终输出。简单粗暴，落地快，很多垂直领域小模型，本质上就是高质量指令数据加微调的结果。缺点是学生只学结论，不学逻辑。

2. CoT 蒸馏：连解题思路一起学

CoT 也就是思维链。这种方式会要求老师模型把推理过程也完整写出来，比如先分析题目考点、再排除错误选项、最后得出结论。 学生模型学到的就不只是答案，还有完整的解题路径，对数学、代码、复杂问答这类任务提升非常明显。当然它也有坑：如果老师的推理过程错了，学生也会把错误思路一起学进去，所以数据清洗至关重要。

3. 偏好蒸馏：学老师的审美

大模型的能力不只是回答问题，还包括判断 “什么是好回答”。 同一个问题给两个不同答案，让老师模型判断哪个更好、好在哪。学生模型学习这种偏好判断，就能在对齐上更接近强模型的输出标准。

4. Self-Instruct：让老师自己出题

训练数据不够怎么办？可以让强模型自己生成题目、生成答案、生成变体，低成本扩充数据集。 但要注意：生成的数据不等于高质量数据。大模型生成的内容很容易同质化，还会自带偏见和错误。真正有价值的，是生成之后的筛选、去重、评测和人工抽检环节。

5. 领域蒸馏：最务实的工程选择

对于绝大多数应用开发者来说，最值得关注的其实是领域蒸馏。 不用想着复刻一整个通用大模型 —— 那不现实，也没必要。只针对某一个具体任务做蒸馏就够了：比如只蒸客服意图分类、只蒸代码评审建议、只蒸 RAG 检索结果排序。 全量复刻强模型难如登天，但把它在一个小任务上的表现迁移过来，性价比极高，也是工程里最常见的做法。

五、蒸馏不是魔法，这些东西它学不来

网上很多说法把蒸馏吹得神乎其神，仿佛小模型蒸一下就能追上大模型。这是不可能的。 蒸馏的效果有明确的边界，有些东西能学到，有些东西永远学不到。

能学到的：

• 常见问题的回答方式与输出格式
• 老师模型的表达风格与回答套路
• 特定领域的部分知识与推理范式
• 对答案好坏的偏好判断

学不到的：

• 老师模型的完整参数与内部推理机制
• 大模型的全部世界知识与泛化能力
• 超过学生模型容量的复杂能力

这里最核心的天花板，就是学生模型自身的参数量。 就像让小学生听大学教授讲课，听得再多也不可能立刻变成教授。他能学会一些解题技巧，但底层的知识储备和思维能力，不是靠模仿就能突破的。小模型同理，它的容量决定了能力上限，再多的蒸馏数据也跨不过这个门槛。

六、别再搞混：蒸馏、微调、量化、剪枝不是一回事

这几个词经常被放在一起说，但它们解决的根本不是同一层面的问题，很多人却容易混淆。

• 微调：让已有模型学习业务数据，解决的是「任务适配」问题 —— 比如让通用模型看懂你家的客服场景。
• 蒸馏：让小模型学习大模型的输出行为，解决的是「能力迁移」问题 —— 把大模型的能力搬到小模型里。
• 量化：降低模型参数的数值精度（比如从 FP16 降到 INT4），解决的是「推理成本」问题 —— 让模型占显存更少、跑得更快。
• 剪枝：删掉模型里不重要的结构和参数，解决的是「结构精简」问题 —— 让模型本身的规模变小。

这几者不是互斥关系，真实工程里往往是组合使用的：先用强模型生成领域数据，蒸馏出一个基础小模型，再用业务数据做微调适配，最后量化压缩之后上线部署。不用死记概念，看它解决什么问题，就一目了然了。

七、蒸馏到底用在哪？核心就是降本增效

说了这么多原理，蒸馏在实际项目里的价值，归根到底就是四个字：降本增效。它不是用来替代强模型的，而是给系统做能力分层。

1. 降低 API 成本：每天几百万次的高频调用，全用强模型成本会高得离谱。用蒸馏小模型承接 80% 的简单常见请求，复杂问题再交给大模型兜底，整体成本能降一个数量级。
2. 降低推理延迟：客服、搜索、实时交互这类场景，延迟直接影响用户体验。小模型几百毫秒就能出结果，远快于大模型的几秒级响应。
3. 端侧部署：手机、PC、本地设备跑不动千亿大模型，蒸馏后的小模型可以直接在端侧运行，不用上传数据，隐私性也更好。
4. 企业私有化部署：很多企业不能把核心数据发到外部 API，自己部署大模型又成本太高。一个针对固定任务的领域小模型，就能在内网环境里解决大部分问题。
5. RAG 与 Agent 的辅助环节：RAG 里的 Query 改写、结果重排，Agent 里的工具选择、状态判断，这些子任务根本不需要最强模型，蒸馏小模型完全可以胜任，还能大幅拉低系统的整体成本。

一个成熟的大模型系统，从来不是把所有请求都扔给最强模型，而是按难度、风险、频率做分层，让合适的模型做合适的事。而蒸馏，就是实现这种分层的核心手段之一。

写在最后

说到底，模型蒸馏从来不是什么玄乎的黑科技，它就是一种非常务实的工程方法：把大模型在特定任务上的能力，低成本迁移到更小、更快、更可控的小模型里。 它不是万能的抄作业神器，也不是行业灰色地带的代名词。技术本身没有对错，关键看用它的人 —— 是在合规边界内解决业务问题，还是抱着走捷径的心态打擦边球。

对于我们做技术的人来说，理解蒸馏的原理、边界和落地场景，比纠结 “谁家又蒸了谁家” 有意义得多。毕竟工具是死的，怎么用好工具，才是真正考验能力的地方。

互动话题：你在工程里用过蒸馏优化线上推理成本吗？效果提升明显吗？我是阿宇，期待大家的交流互动^-^