LLM蒸馏与微调·第一章：原理与全景

原理与全景

预训练、微调、蒸馏的关系 · 六种微调方法全拆解 · 四种蒸馏范式 · 选型决策树

1.1 预训练、微调、蒸馏：三个词说清它们的关系

在进入任何技术细节之前，我们需要先建立一个大图景。LLM的"改造"手段，本质上只有三种：预训练、微调、蒸馏。它们各自解决不同的问题，处于模型生命周期的不同阶段。

一个贯穿始终的比喻

预训练是"大学教育"——在海量通用知识上训练，让模型获得广泛的语言理解和生成能力。就像一个大学生，读了四年书，什么学科都接触过，知识面广但不够专精。Qwen2.5-72B的预训练消耗了数万亿token的语料，花费数千GPU年的算力，这就是"大学"的代价。

微调是"岗前培训"——在特定任务的数据上继续训练，让模型学会以特定的方式表达和应用已有知识。微调改变的是模型的"表达方式"，而不是"知识储备"——微调不是往模型里灌知识，而是教模型怎么把已有知识以你期望的方式输出。

蒸馏是"师徒传承"——让一个大模型（教师）把它的能力"传授"给一个小模型（学生），使小模型在参数量大幅减少的情况下，尽量保留大模型的能力。蒸馏的核心是"知识迁移"，不是简单的模型压缩。

三者的本质区别

目标

预训练：从零建立语言能力 ｜ 微调：适配特定任务/领域 ｜ 蒸馏：将大模型能力迁移到小模型

训练数据

预训练：海量无标注语料（万亿级token） ｜ 微调：中量有标注数据（千条~百万条） ｜ 蒸馏：教师模型生成的信号+原始数据

算力需求

预训练：极高（数千GPU） ｜ 微调：中等（单卡~多卡） ｜ 蒸馏：中高（需同时运行教师+学生）

输出产物

预训练：基座模型（Base Model） ｜ 微调：适配后的模型 ｜ 蒸馏：压缩后的小模型

典型耗时

预训练：数周~数月 ｜ 微调：数小时~数天 ｜ 蒸馏：数小时~数天

一个关键认知：微调不等于灌知识

这是初学者最容易犯的错误。很多人以为微调就是"把领域知识喂给模型"——但事实并非如此。

LLM在预训练阶段已经"读"过了海量文本。对于7B以上的模型来说，大多数领域的知识它其实已经见过。微调真正在做的事情是：教会模型在特定场景下，应该以什么格式、什么风格、什么逻辑来组织和输出它已经知道的内容。

举个例子：Qwen2.5-7B在预训练阶段已经见过大量医疗文本，它"知道"很多医学知识。但如果你直接问它一个医疗问题，它可能给出一个像百科全书一样的回答——这对临床医生来说并不实用。微调的作用是让它学会"以临床指南的格式回答，引用最新的诊疗方案，避免给出未经验证的建议"——这是表达方式的调整，不是知识的注入。

一个验证实验：你可以做个简单测试——用Qwen2.5-7B-Instruct直接问一个专业领域的问题，它通常能给出不错的回答，只是格式和风格可能不符合你的预期。这说明知识已经在那里了，微调只是在"调教"输出方式。

当然，如果你的领域数据在预训练语料中占比极低（比如某公司的内部业务文档），微调确实也能补充一些知识。但这不是微调的主要目的，而且用微调来灌知识的效果远不如用RAG（检索增强生成）。

微调失败的典型模式

理解了"微调是调表达"之后，就能理解为什么微调经常"翻车"：

一、数据太少（<100条）：模型学不到稳定的表达模式，微调后输出风格混乱——有时按你的格式，有时回退到原始风格

二、数据太多且单一（>10万条同质数据）：模型过拟合到训练数据的表达模式，丧失了灵活性——只能用一种方式回答，换个问法就懵了

三、数据质量差：模型学会了错误的表达模式——垃圾进垃圾出，这不是微调方法的问题，而是数据的问题

四、学习率过大：模型"忘记"了预训练的表达能力，变成一个只会死记硬背训练数据的"复读机"——这就是灾难性遗忘

一句话总结：微调是"调教"不是"灌输"。好的微调数据应该是"教模型怎么说话"，而不是"教模型说什么"。

另一个关键认知：蒸馏不等于模型压缩

蒸馏的结果确实是一个更小的模型，但蒸馏的本质不是"压缩"，而是"知识迁移"。

简单的模型压缩（比如剪枝、量化）只是减少了参数量，但不改变模型的知识来源。而蒸馏是让学生模型从教师模型的输出中学习——这意味着学生学到的不仅是"正确答案"，还有教师模型的"思考方式"（概率分布中的暗知识）。

Hinton等人在2014年的经典论文（发表于NIPS 2014 Workshop）中阐述了这个原理：假设一个图像分类模型对某张图片的预测分布中，"猫"获得了最高概率，但"狗"也获得了不低的概率，而"汽车"概率很低。硬标签只告诉你"这是猫"，但软标签（概率分布）还告诉你"这更像狗而不是汽车"。这个"更像狗而不是汽车"的信息就是暗知识（Dark Knowledge），是蒸馏真正有价值的地方。

在LLM场景下，这种暗知识更加丰富。教师模型在生成每个token时都会输出一个覆盖整个词表的概率分布，这个分布包含了教师对"哪些词更合理、哪些词不太可能"的判断。学生模型通过学习这个分布，能获得比只学习最终文本更丰富的信息。

蒸馏失败的典型模式

一、教师太强、学生太弱：72B教师的输出分布对0.5B学生来说太复杂了——就像让小学生直接学大学教材，能记住答案但理解不了推理过程。解决方案：渐进式蒸馏，或选择更小的教师

二、温度参数不当：温度太低（τ=1），教师分布太尖锐，学生学不到暗知识；温度太高（τ>5），分布太均匀，噪声淹没了信号。解决方案：τ=2~4是安全区间

三、蒸馏数据覆盖面太窄：如果只用一种类型的输入做蒸馏，学生也只会这一种。解决方案：蒸馏数据要覆盖目标场景的多种任务类型

四、只做黑盒蒸馏就期望太高：黑盒蒸馏本质是"用教师数据做SFT"，效果上限受限于文本形式的信息量。如果需要更高的蒸馏精度，必须上白盒蒸馏

一句话总结：蒸馏是"传承"不是"压缩"。好的蒸馏应该让学生学到教师的"思考方式"（概率分布），而不只是"答案"（文本输出）。

三者不是互斥的

在实际应用中，这三种手段往往是组合使用的：

先预训练，再微调——最常见的路径。Qwen2.5系列的所有Instruct模型，都是在Base模型上经过SFT和RLHF/DPO对齐训练得到的

先蒸馏，再微调——先用大模型蒸馏出一个小模型，再用领域数据对小模型做微调。在垂直领域落地中很常见

微调阶段同步蒸馏——在微调学生模型的同时，用教师模型的输出作为额外的监督信号。相当于"边学业务边有师傅指导"

蒸馏数据用于微调——用大模型生成高质量的指令数据，再用这些数据微调小模型。本质上是黑盒蒸馏

1.1 小结：预训练建立能力，微调适配表达，蒸馏迁移能力——三者各司其职。微调是"教表达"不是"灌知识"，蒸馏是"迁移知识"不是"简单压缩"。三者可以灵活组合，组合策略是实际落地中的关键决策。

1.2 微调的核心机制：参数更新方式全景

微调的核心问题是：在预训练模型的数十亿参数中，我们要更新哪些？怎么更新？不同的回答，衍生出了不同的微调方法。从"全部更新"到"几乎不更新"，形成了一个完整的谱系。

1.2.1 全量微调（Full Fine-tuning）

一句话概括：解冻模型所有参数，在任务数据上全部更新。

全量微调是最直接的微调方式。给定一个预训练模型，其参数为 W₀，全量微调在任务数据上通过梯度下降更新所有参数：W = W₀ + ΔW。

以Qwen2.5-7B为例，全量微调需要更新的参数量就是7B（76.1亿）。训练时需要存储：模型权重（FP16约14GB）+ 梯度（FP16约14GB）+ 优化器状态（Adam需要2份，约28GB）= 约56GB显存（仅模型相关部分，还不包括激活值）。

全量微调显存需求（不含激活值）

0.5B　权重~1GB + 梯度~1GB + 优化器~2GB = ~4GB

1.5B　权重~3GB + 梯度~3GB + 优化器~6GB = ~12GB

7B　权重~14GB + 梯度~14GB + 优化器~28GB = ~56GB

14B　权重~28GB + 梯度~28GB + 优化器~56GB = ~112GB

72B　权重~144GB + 梯度~144GB + 优化器~288GB = ~576GB

注意：实际训练还需要存储激活值。对于7B模型、batch_size=1、seq_len=2048，激活值约4-8GB。使用梯度检查点可以降低激活值显存，但会增加约30%的训练时间。

适用场景：数据量充足（万条以上）、任务与预训练分布差异大、有足够GPU资源、追求最佳性能。

真实案例：某AI公司用10万条代码数据全量微调Qwen2.5-14B，4×A100训练3天，HumanEval从42%提升到67%——数据充足时全量微调的上限最高。

多卡方案：DeepSpeed ZeRO将优化器状态、梯度、模型参数分片到多张卡上。ZeRO-3显存效率最高但通信开销大。FSDP是PyTorch原生方案，与PyTorch生态集成更好。

1.2.2 LoRA（Low-Rank Adaptation）

一句话概括：冻结原始参数，只训练注入的低秩矩阵。

LoRA的核心洞察是：虽然模型参数量巨大，但微调时真正需要的变化量 ΔW 可能存在于一个低维空间中。ΔW 可以用两个小矩阵的乘积来近似：ΔW = A × B，其中 A ∈ ℝ^(d×r)，B ∈ ℝ^(r×d)，r ≪ d。

训练时 W₀ 完全冻结，只更新 A 和 B。A 通常用随机高斯初始化，B 初始化为零矩阵，这样 ΔW = A × B = 0，训练开始时模型行为与原始模型完全一致。

为什么低秩近似有效？

7B模型的一个注意力权重矩阵是3584×3584，约1284万参数。为什么只需要5.7万参数（r=8时）的LoRA就能有效微调？

核心洞察来自Aghajanyan等人（ACL 2021）的研究：预训练模型的微调过程具有低秩性——即使只保留 ΔW 前0.1%的奇异值，微调效果也不会显著下降。

直觉理解：微调是在已有能力上做"微调"（字面意思），不是从零学习。一个已经学会了语言的模型，要让它适应新任务，只需要在"关键方向"上做调整——这些关键方向的数量远小于参数总量。就像一个已经会开车的人学开卡车，不需要重新学方向盘、油门、刹车的基本操作，只需要学几个关键差异点。

这也解释了为什么LoRA在数据量少时反而可能优于全量微调：低秩约束天然起到了正则化的作用，防止模型在少量数据上过拟合。

以Qwen2.5-7B的一个注意力层为例（d=3584）：原始参数12,845,056个，LoRA（r=8）只需57,344个参数，占比约 0.45%。对于整个模型，LoRA总可训练参数占比通常在 0.1%~1% 之间。

Rank（秩）的选择

r=4　~0.05%参数 ｜ 简单任务（风格迁移、格式适配）

r=8　~0.1%参数 ｜ 中等任务（指令跟随、简单问答）

r=16　~0.2%参数 ｜ 复杂任务（多轮对话、推理）← 推荐起点

r=32　~0.4%参数 ｜ 高复杂度任务（代码生成、数学推理）

r=64　~0.8%参数 ｜ 数据充足、追求极致性能

r=128　~1.5%参数 ｜ 接近全量微调的表达能力

经验法则：rank不是越大越好。当rank超过某个阈值后，性能提升会迅速递减，但训练成本线性增加。对于大多数任务，r=16~32是一个好的起点。

LoRA显存需求（r=16，FP16）

0.5B　~2GB ｜ 1×RTX 3060 12GB

1.5B　~4GB ｜ 1×RTX 3060 12GB

7B　~16GB ｜ 1×RTX 3090/4090 24GB ← 最常用

14B　~32GB ｜ 2×RTX 3090 或 1×A100 40GB

72B　~160GB ｜ 2×A100 80GB（需配合量化）

LoRA的合并与部署：训练完成后，可以将LoRA权重合并回原始模型。合并后推理行为与标准模型完全一致，没有额外的推理延迟。也可以选择不合并，以LoRA适配器的形式单独保存和加载——原始模型只需保存一份，每个任务只需保存一个很小的LoRA适配器（几MB~几十MB），推理时动态加载不同的适配器，实现"一个基座模型，多种能力"。

LoRA训练的进阶技巧

技巧1：多数据集混合训练 — 实际项目中往往需要90%领域数据 + 10%通用数据防遗忘。推荐比例9:1，大多数场景的最佳平衡。

技巧2：多轮对话微调 — 需用ShareGPT格式，cutoff_len建议4096或更高，每条数据控制在3~5轮。

技巧3：rank和target模块组合实验 — 加目标模块比加rank更有效：同样是0.2%参数，r=16+4模块（87%）优于r=32+2模块（85%）。推荐策略：先用 q_proj,v_proj, r=16 跑baseline，效果不够再加 k_proj,o_proj。

技巧4：学习率预热和衰减 — cosine调度 + 10% warmup是LoRA微调的"黄金组合"，绝大多数场景不需要调整。

真实案例：某团队用LoRA在单张RTX 4090上微调7B做客服问答，2000条数据训练2小时，回复格式准确率从61%提升到89%。

🔧 微调方法选型速查

单卡24GB，微调7B做客服问答 → LoRA (r=16)　显存够、稳定、效果够用

只有12GB显卡，还想微调7B → QLoRA (4bit, r=32)　显存省60%，效果差1%以内

4×A100，10万条数据，追求极致 → 全量微调　数据充足时上限最高

不能改模型权重（合规要求） → Prefix Tuning　只加前缀，不动权重

90%的场景选LoRA就够了。

1.2.3 QLoRA（Quantized LoRA）

一句话概括：把模型量化到4bit，再用LoRA训练。

QLoRA在LoRA的基础上增加了一层量化。核心思路：将预训练模型权重从FP16量化到4bit（NF4格式），在4bit模型上应用LoRA，LoRA部分保持FP16。

QLoRA引入了三项关键创新：

NF4（NormalFloat 4-bit）：根据正态分布的CDF来划分量化级别——在权重密集的区域（0附近）分配更多的量化级别，整体误差更小。类比：Int4像"均匀刻度的尺子"，NF4像"对数刻度的尺子"

双重量化：对量化常数本身再做一次量化，进一步减少显存占用

分页优化器：利用NVIDIA统一内存，GPU显存不足时自动将优化器状态分页到CPU内存

QLoRA显存节省效果

7B　LoRA ~16GB → QLoRA ~6GB　节省62%

14B　LoRA ~32GB → QLoRA ~10GB　节省69%

72B　LoRA ~160GB → QLoRA ~48GB　节省70%

QLoRA让7B模型的微调在一张RTX 3060 12GB上成为可能，让72B模型的微调在单张A100 80GB上可以跑起来——这在LoRA时代是不可能的。

精度损失：在MMLU、HumanEval等基准测试上，QLoRA（NF4）与全精度LoRA的性能差距通常在1%以内。

真实案例：同一客服任务，LoRA需要16GB显存，QLoRA只要6GB（RTX 3060即可），效果差距不到1%——显存不够时的最佳退路。

1.2.4 Adapter Tuning

一句话概括：在Transformer层之间插入小型适配器模块，只训练适配器。

Adapter模块结构：输入 → LayerNorm → Down-Project (d→r) → ReLU → Up-Project (r→d) → 残差连接 → 输出。残差连接确保最差情况下Adapter可以退化为恒等映射，不会破坏原始模型的能力。Adapter通常只增加原始模型 3~5% 的参数量。

Adapter vs LoRA 关键区别

插入位置　Adapter：Transformer层之间（独立模块） ｜ LoRA：并行于原始权重（旁路）

推理延迟　Adapter：有额外延迟 ｜ LoRA：无额外延迟（合并后）

参数效率　Adapter：约3~5% ｜ LoRA：约0.1~1%

推理延迟问题是Adapter Tuning最大的短板。假设模型有32层Transformer，每层插入一个Adapter，每个Adapter增加0.1ms的推理时间，那么生成1000个token的总延迟增加约3.2秒——这在实时场景中是不可忽视的。相比之下，LoRA在合并后没有任何额外推理延迟。这是Adapter在LLM场景下被LoRA取代的主要原因。

1.2.5 Prefix Tuning

一句话概括：在每层Transformer的Key和Value前拼接可训练的前缀向量。

Prefix Tuning不修改模型的任何权重，而是在输入层面做文章。在Transformer的每一层，在Key和Value矩阵前面拼接一段可训练的连续向量序列。这些前缀向量不是真实的词嵌入，而是纯参数——一组在连续空间中优化的向量。

直觉理解：Prefix就像是一种"催眠暗示"——不改模型的任何内在结构，而是在每层的注意力机制中植入一段"虚拟的上下文"，引导模型以特定方式理解和回应输入。

真实案例：某团队用Prefix Tuning让7B模型学会特定品牌的客服话术，不修改任何权重，50条示例即见效——适合"不能动模型"的合规场景。

1.2.6 Prompt Tuning

一句话概括：只在输入层添加可训练向量，比Prefix Tuning更简单但表达能力更弱。

Prompt Tuning只在输入层（Embedding层）添加可训练向量，而Prefix Tuning在每一层都添加。Prompt Tuning更简单但表达能力更弱，在小模型上效果差，不推荐。

1.2.7 六种方法全景对比

全量微调　100%参数 ｜ 显存极高 ｜ 无推理延迟 ｜ 表达力最强 ｜ 多任务差

LoRA ★推荐　0.1~1%参数 ｜ 显存低 ｜ 无推理延迟 ｜ 表达力强 ｜ 多任务好

QLoRA　0.1~1%参数 ｜ 显存极低 ｜ 无推理延迟 ｜ 表达力强 ｜ 多任务好

Adapter　3~5%参数 ｜ 显存中 ｜ 有推理延迟 ｜ 表达力中强 ｜ 多任务好

Prefix Tuning　0.1~0.5%参数 ｜ 显存低 ｜ 微延迟 ｜ 表达力中 ｜ 多任务好

Prompt Tuning　<0.1%参数 ｜ 显存极低 ｜ 微延迟 ｜ 表达力弱 ｜ 多任务好

选型建议：首选LoRA——绝大多数场景下的最优解。显存低、无推理延迟、训练稳定、生态成熟。显存不够选QLoRA。全量微调只在数据量>10万条、多GPU集群可用时才有必要。

2024~2025年的实践共识：LoRA是LLM微调的默认选择。QLoRA是LoRA的"穷人版"，效果接近但门槛更低。Adapter和Prefix Tuning在LLM场景下使用较少，但在学术研究中有价值。

1.3 蒸馏的核心机制：知识迁移范式

如果说微调的核心问题是"更新哪些参数"，那么蒸馏的核心问题就是"迁移什么知识"。教师模型内部有多种形式的"知识"，不同形式的知识，对应不同的蒸馏策略。

1.3.1 先分清：白盒蒸馏 vs 黑盒蒸馏

黑盒蒸馏：学生模型只能看到教师模型的最终输出（生成的文本），无法访问其内部状态。典型流程：准备输入提示 → 发送给教师获取文本 → 用（提示，教师输出）微调学生。黑盒蒸馏的本质就是用教师模型的输出做数据增强，然后对学生做监督微调。

白盒蒸馏：学生模型可以访问教师模型的内部状态，包括输出层的Logits、中间层的Hidden States、注意力权重。白盒蒸馏能利用的信息远比黑盒丰富，效果通常也更好，但代价是需要加载教师模型——这意味着你需要有足够的显存来同时运行教师和学生。

教师模型要求　黑盒：只需API访问 ｜ 白盒：需要模型权重

可用信息　黑盒：生成的文本 ｜ 白盒：Logits + Hidden States + Attention

显存需求　黑盒：低（只需运行学生） ｜ 白盒：高（需同时运行教师+学生）

本质　黑盒：数据增强+SFT ｜ 白盒：知识迁移

在开源模型上做蒸馏，白盒蒸馏是首选——你有模型权重，没有理由浪费内部信息。黑盒蒸馏主要用于无法获取权重的闭源模型。

1.3.2 响应蒸馏（Response-based Distillation）

一句话概括：让学生模型的输出分布尽量接近教师模型的输出分布。

响应蒸馏是最经典、最广泛使用的蒸馏范式，源自Hinton等人2014年的知识蒸馏框架。核心公式：L_KD = KL(σ(z_T/τ) ‖ σ(z_S/τ))，其中 τ 是温度参数，控制分布的"软度"。

温度参数 τ 的作用：τ=1时分布保持原始形态；τ>1时分布变得更"软"（更均匀），原本概率很低的类别也会获得相对更高的概率——这就是"暗知识"被释放出来的过程；τ→∞时分布趋近均匀分布。典型取值：τ = 2~5。

正向KL vs 反向KL：LLM生成任务推荐反向KL，学生模型会聚焦于教师分布的主要模式，生成质量更高；正向KL倾向于模式覆盖，学生可能过度估计低概率区域，生成不连贯文本。MiniLLM（ICLR 2024）系统性地验证了这一点。

损失函数的完整形式：L_total = α·L_CE + (1-α)·τ²·L_KD。其中 τ² 是补偿因子——因为软标签的梯度比硬标签小 τ 倍，乘以 τ² 使两项损失的梯度量级可比。

为什么需要同时保留CE损失？三个原因：①锚定正确答案——如果教师在某些样本上犯了错，纯蒸馏会让学生也学到错误；②稳定训练——KL散度的优化景观比交叉熵更复杂；③数据有标注时充分利用。

蒸馏显存需求

72B(FP16)→7B(LoRA)　教师~144GB + 学生~16GB = ~160GB

72B(4bit)→7B(LoRA)　教师~36GB + 学生~16GB = ~52GB ← 量化后更实际

14B(FP16)→1.5B(LoRA)　教师~28GB + 学生~4GB = ~32GB

7B(FP16)→0.5B(LoRA)　教师~14GB + 学生~2GB = ~16GB

关键洞察：蒸馏的显存瓶颈不是学生模型的训练，而是教师模型的推理。一个72B的教师模型即使量化到4bit，推理仍需36GB显存。

1.3.3 特征蒸馏（Feature-based Distillation）

一句话概括：让学生模型的中间层特征尽量接近教师模型对应层的特征。

响应蒸馏只利用了输出层的信息，但教师模型的中间层同样包含了大量有价值的知识。特征蒸馏的核心思想是让学生模型的中间层隐藏状态去"模仿"教师模型对应层的隐藏状态。由于教师和学生的模型大小不同，中间层的维度也不同，需要引入一个变换矩阵 W_align 将学生的特征映射到教师的特征空间。

层映射策略：均匀映射（教师32层学生16层，则学生第i层对齐教师第2i层）；最后一层映射（简单但信息量少）；选择性映射（只对齐关键层）；注意力图对齐。

特征蒸馏通常与响应蒸馏结合使用。2025年IJCNN的研究表明，特征蒸馏相比纯响应蒸馏，在分类任务上提升2~5%，在生成任务上提升1~3%。

1.3.4 关系蒸馏（Relation-based Distillation）

一句话概括：不迁移单个样本的特征，而是迁移样本之间的关系。

响应蒸馏和特征蒸馏都是"点对点"的。关系蒸馏换了一个视角：它关注的是不同输入之间的关系结构。如果教师模型认为样本A和样本B"相似"，那么学生模型也应该认为它们相似。在LLM场景中研究较少，了解即可。

1.3.5 渐进式蒸馏（Progressive Distillation）

一句话概括：不一次性从大模型蒸馏到小模型，而是分多步逐步缩小。

直接从72B蒸馏到0.5B，能力跨度太大。渐进式蒸馏的思路是：72B → 32B → 14B → 7B → 1.5B → 0.5B。每一步的蒸馏跨度较小，学生更容易学习。

直接蒸馏　72B→0.5B　~150GB

渐进第1步　72B→7B　~160GB

渐进第2步　7B→1.5B　~18GB ← 显存骤降

渐进第3步　1.5B→0.5B　~5GB ← 消费级即可

渐进式蒸馏还有一个实际的好处：你不需要同时加载72B的教师和0.5B的学生。每一步只需要加载相邻大小的两个模型，显存需求可控。虽然总训练时间更长，但最终效果通常优于直接蒸馏。

1.3.6 四种蒸馏范式对比

响应蒸馏 ★首选　迁移输出概率分布 ｜ 实现简单 ｜ LLM最常用 ｜ 基线

特征蒸馏　迁移中间层特征 ｜ 实现中等 ｜ 效果 +2~5% ｜ 追求精度时叠加

关系蒸馏　迁移样本间关系 ｜ 实现复杂 ｜ LLM场景研究少 ｜ 了解即可

渐进式蒸馏　逐步缩小模型 ｜ 实现中高 ｜ 效果 +3~8% ｜ 大跨度压缩时用

选型建议：首选响应蒸馏（最简单、最成熟）；追求更高精度加特征蒸馏；模型跨度太大用渐进式蒸馏；关系蒸馏在LLM场景中研究较少，暂不推荐。

1.4 关键对比：蒸馏 vs 微调

前三节分别讲了微调和蒸馏各自的内部机制。现在把它们放在一起，从多个维度做一次正面对比。这一节是整本书最重要的认知框架之一。

微调回答的问题是："这个7B模型怎么才能更好地做医疗问答？"

蒸馏回答的问题是："这个0.5B模型怎么才能尽量像72B模型那样聪明？"

七维度全面对比

目标　微调：适配特定任务/领域 ｜ 蒸馏：将大模型能力迁移到小模型

模型大小　微调：不变（7B微调后还是7B） ｜ 蒸馏：变小（72B→7B→0.5B）

数据需求　微调：任务相关的标注数据 ｜ 蒸馏：教师模型生成的软标签+原始数据

训练信号　微调：真实标签（硬标签） ｜ 蒸馏：教师输出（软标签）+ 可选真实标签

硬件瓶颈　微调：模型训练的显存 ｜ 蒸馏：教师模型推理的显存

数据获取成本　微调：高（人工标注） ｜ 蒸馏：低（教师生成）

输出产物　微调：适配后的同尺寸模型 ｜ 蒸馏：能力接近教师的更小模型

什么时候该用哪个？

有7B模型，想让它做特定任务 → 微调　直接适配，成本最低

想在端侧部署，需要小模型 → 蒸馏　只有蒸馏能缩小模型

需要领域专用的小模型 → 先蒸馏再微调　先继承通用能力，再做领域适配

只有API访问，没有模型权重 → 黑盒蒸馏

数据极少（<100条） → LoRA微调　蒸馏也需要一定量的输入数据

训练稳定性的对比

黑盒蒸馏：高　本质就是SFT，稳定性与微调相同

白盒响应蒸馏（正向KL）：中　KL散度优化景观比交叉熵复杂

白盒响应蒸馏（反向KL）：低　反向KL梯度方差大

特征蒸馏：中低　多项损失权重平衡是难点

反常识点：很多人以为蒸馏比微调"高级"，所以应该更难。实际上，蒸馏的硬件门槛往往高于微调——因为你需要同时养活一个"老师"和一个"学生"。

迭代成本：黑盒蒸馏的迭代成本高于微调——因为每次迭代都需要重新生成蒸馏数据。白盒蒸馏的迭代成本与微调相当——只需要重新训练。如果你的项目需要频繁迭代，白盒蒸馏比黑盒蒸馏更高效。

⚠️ 本书中所有评测数据均基于Qwen2.5系列在特定数据配置下的社区实测，实际效果因数据质量、训练超参数和评测方法而异，仅供参考。

1.5 选型决策树

把所有知识整合成一套可操作的决策框架——当面对一个具体的LLM适配需求时，按什么路径选择微调还是蒸馏？

你的需求是什么？

A. 让现有模型在特定任务上更好 → 微调

B. 需要更小的模型（部署/降本） → 蒸馏

C. 既要小模型，又要领域专用 → 先蒸馏再微调

D. 只是想让模型输出更符合预期 → 先试Prompt Engineering

蒸馏路径细化

能获取教师权重？→ 白盒蒸馏

　压缩比2倍以内 → 响应蒸馏

　压缩比2~10倍 → 响应蒸馏 + 特征蒸馏

　压缩比10倍以上 → 渐进式蒸馏

只有API → 黑盒蒸馏

蒸馏后还需适配？→ 先蒸馏再微调

微调路径细化

≥4×A100 80GB + 数据>10万条 → 全量微调

1~2×A100 或 2×RTX 4090 → LoRA（模型≤14B）/ QLoRA（模型>14B）

1×RTX 3090/4090 (24GB) → LoRA（模型≤7B）/ QLoRA（模型>7B）

<24GB → QLoRA 或云GPU

常见误区

"蒸馏比微调更高级"——不是。它们解决不同的问题，是互补关系

"先微调再蒸馏"——错误顺序。微调后模型偏科，蒸馏会继承偏科。正确：先蒸馏再微调

"蒸馏不需要数据"——白盒蒸馏确实不需要人工标注，但仍需输入数据来触发教师推理

"LoRA效果一定不如全量微调"——不一定。适当rank的LoRA在多任务场景中可以媲美甚至超越全量微调

"模型越小，越需要蒸馏"——恰恰相反。模型越小，能"消化"教师知识的能力越弱

本章小结

读完这一章，你应该建立了三个认知锚点：

三者各司其职：预训练建能力，微调适配表达，蒸馏迁移能力。微调不是灌知识，蒸馏不是简单压缩——这两句话值得反复咀嚼。

微调是谱系，蒸馏是范式：从全量微调到LoRA到QLoRA，是参数效率的递进；从黑盒到白盒，从响应到特征，是知识利用深度的递进。LoRA是微调的默认选择，响应蒸馏是蒸馏的通用起点。

选型从需求出发：需要缩小模型→蒸馏；需要适配任务→微调；两者都要→先蒸馏再微调。先试Prompt Engineering，不够再升级。