简介深度解析 DeepSeek 的蒸馏技术是一份面向大模型研究者与AI工程实践者的技术文档以PDF文档形式提供。内容从蒸馏技术定义出发厘清教师模型与学生模型的知识迁移原理随后重点剖析DeepSeek的双重蒸馏路径一方面借助教师模型生成与优化数据进行数据蒸馏另一方面通过800K推理样本监督微调Qwen/Llama系列学生模型。文档还介绍了层次化特征提取、基于特征蒸馏与特定任务蒸馏等创新策略并给出DeepSeek-R1-Distill-Qwen-7B/32B在AIME 2024、MATH-500等基准上的Pass1成绩方便读者评估性能收益与计算开销的平衡。资源共1个PDF文件体积742KB体量精巧、阅读成本低适合快速获取蒸馏技术要点。已有176人学习对于关注模型压缩、边缘部署或大模型优化的开发者来说是一份兼具原理深度与实证数据的参考材料。1. DeepSeek 的蒸馏技术到底在处理什么问题如果你在 DeepSeek 相关的技术社区泡过几天大概率会撞见这个词蒸馏。它听起来像某种黑匣子魔法实际解决的是最现实的一件事模型太大跑不动、租不起、私有化部署更头疼。DeepSeek 的蒸馏技术本质上就是让一个小模型去模仿一个大模型教师模型的行为把大模型的“判断力”压缩进小模型的参数里。目标不是省训练时间而是省推理成本——同样跑一个问答、写一段代码小模型需要的显存和延迟都低一个量级这让本地部署、企业内网部署变成可能也让 vLLM 这类推理框架跑得更从容。这份文档切入的角度很直接蒸馏不是神秘算法而是一套可复现的数据流动流程。我从头到尾读下来的感觉是它把知识蒸馏从论文术语拉回到了工程参数层面温度怎么设、软标签怎么算、学生模型怎么选、评估怎么不翻车。适合谁读给那些手头有一个 70B 级别的大模型、却想把它塞进 24G 显卡或者一台普通服务器的人。也适合做垂直场景问答、代码助手、企业私有部署的技术团队。如果你只是好奇炼丹它也能让你少走很多弯路。2. 蒸馏流程拆解从教师模型到学生模型的关键环节2.1 先想清楚你要蒸馏什么通用能力还是任务能力很多人拿到蒸馏文档第一反应是找一个教师模型然后开始跑脚本。我建议你先停下来问自己一个问题你要蒸馏的是“全知全能的对话能力”还是“某一个具体任务的处理能力”。这两个方向数据配比、训练时长、评估方式完全不同。DeepSeek 这类开源大模型本身是通用底座蒸馏出一个 7B 甚至 3B 的模型如果目标是通用对话那你需要海量多轮对话数据而且学生模型的容量有限学得越全越浅。如果目标是垂直场景比如“根据公司知识库回答售后问题”“从代码仓库生成 commit message”那你的数据应该集中在这些任务上蒸馏出的模型在垂直指标上往往比通用蒸馏更亮眼。常见做法是先从通用对话蒸馏一遍拿到一个基础小模型再用垂直数据做第二遍蒸馏。我一般会建议团队直接做两段式第一段用通用指令数据把学生模型的“语言习惯”对齐第二段用任务数据把“专业能力”压进去。不要指望一步到位学生模型的学习能力远没有教师模型那么强。2.2 数据准备蒸馏用的不是原始语料是“模型输出”蒸馏和普通微调最本质的区别就在这里。普通微调你给模型喂“问题-标准答案”蒸馏你给模型喂“问题-教师模型的输出分布”。后者信息量更大因为教师模型不仅告诉你答案是哪个还告诉你每个候选答案的置信度以及那些看似离谱但概率不为零的选项。实际操作中你要先准备好一批问题集最好覆盖你目标场景的真实分布。然后用教师模型批量跑出回答保存的字段至少要有输入文本、教师模型的 logits、教师模型生成的文本。如果可能把 logits 保存下来不要只存 softmax 之后的概率因为后面要加温度系数重新计算概率是已经归一化过的重新计算需要原始 logits 精度才够。数据量上没有玄学门槛。我见过两万条指令数据效果就相当不错的情况也见过三万条对话数据训练后效果反而变差的情况——问题往往出在数据单一、重复度过高。宁可要一万条覆盖度高的数据不要十万条同一个模板的翻版。每条数据之间保持多样蒸馏出的模型才不会变成复读机。2.3 一个可运行的最小蒸馏脚本下面这个脚本是标准做法里的极简版用 PyTorch 实现 KL 散度蒸馏。它不追求完整生产而是让你理解核心循环教师模型冻结学生模型学习教师输出。import torch import torch.nn.functional as F from transformers import AutoModelForCausalLM, AutoTokenizer # 加载教师模型并冻结 teacher AutoModelForCausalLM.from_pretrained(deepseek-ai/deepseek-llm-7b) teacher.eval() for param in teacher.parameters(): param.requires_grad False # 加载学生模型这里用更小的模型 student AutoModelForCausalLM.from_pretrained(deepseek-ai/deepseek-llm-1.3b) student.train() tokenizer AutoTokenizer.from_pretrained(deepseek-ai/deepseek-llm-7b) optimizer torch.optim.AdamW(student.parameters(), lr5e-5) def distill_step(batch, temperature4.0, alpha0.5): inputs tokenizer(batch, return_tensorspt, paddingTrue, truncationTrue) inputs {k: v.to(student.device) for k, v in inputs.items()} with torch.no_grad(): teacher_logits teacher(**inputs).logits student_logits student(**inputs).logits # 温度缩放后的KL散度 teacher_soft F.log_softmax(teacher_logits / temperature, dim-1) student_soft F.log_softmax(student_logits / temperature, dim-1) loss_kl F.kl_div(student_soft, teacher_soft, reductionbatchmean, log_targetTrue) loss_kl loss_kl * (temperature ** 2) # 硬标签交叉熵防止学生模型跑偏 loss_ce F.cross_entropy( student_logits.view(-1, student_logits.size(-1)), inputs[labels].view(-1) ) loss alpha * loss_kl (1 - alpha) * loss_ce optimizer.zero_grad() loss.backward() optimizer.step() return loss.item()这段代码里有几个关键点。teacher_logits是教师模型对同一批输入的原始输出必须包在torch.no_grad()里否则显存会直接爆炸。temperature用来软化概率分布值越高分布越平滑学生模型能学到教师模型的“犹豫”值越低越接近硬标签学生模型只会学到“标准答案”。loss_kl后面乘上temperature ** 2是因为 KL 散度经过温度缩放后梯度的量级会变化不乘回去会导致温度升高时 loss 反而降低这是一个非常经典的坑。alpha控制软标签和硬标签的权重。alpha 太高学生模型只学教师的口吻可能丢真知识alpha 太低蒸馏就退化成普通微调教师模型的信息优势全浪费了。我一般先从 alpha0.5 起步看验证集表现再决定往哪边偏。3. 温度、损失权重与模型结构蒸馏效果三个必调参数3.1 温度 T 怎么调从粗暴尝试到规律复盘温度是蒸馏里最让人摸不着头脑的参数很多人直接套默认值 4.0结果学生模型回答变得软绵绵什么都是“可能”“大概”“也许”。我自己的血泪经验是温度需要和你的数据难度匹配。数据里如果答案高度确定比如数学题、代码生成温度可以设到 2.0 左右因为教师模型对这类问题的 logits 分布本来就尖锐温度太高会把确定性稀释掉。如果是开放域对话、创意写作温度提到 5.0 甚至更高才能让学生模型学到教师模型的发散性。判断温度是否合适不要只看 loss。我一般会做一个小实验固定同一批 200 条验证数据用不同温度训完看生成结果。温度太低学生模型模仿的是教师模型的“口气”而非“逻辑”温度太高学生模型输出会出现大量无关词。一个可靠的做法是先观察教师模型对你验证集的 logits 分布如果大多数答案的概率集中在极少数 token 上温度用 2~3如果分布均匀温度用 4~6。3.2 软标签与硬标签的配比alpha 不是拍脑袋alpha 这个参数很多入门教程会告诉你取 0.5 或者 0.7但实际工程里它和数据规模、训练轮数强相关。数据量大时硬标签足够让学生模型学到正确语法和知识alpha 可以降到 0.3数据量小时学生模型容易过拟合硬标签alpha 升到 0.8 反而更稳。另一个容易忽略的维度是训练轮次。如果你做的是一遍蒸馏alpha 定成一个值没问题但如果你做的是两段式第一段建议 alpha 高一些让学生模型充分拟合教师行为第二段把 alpha 降低让真实标注数据占据主导防止学生模型继承教师模型的“失望和偏见”——也就是教师模型在困难样本上的犯错模式。我习惯把 alpha 做成一个随训练进度衰减的量而不是常数。比如前 30% 的步数 alpha0.8中间 40% 用 0.6最后 30% 用 0.4。这样前期学教师风格后期回归任务目标效果比固定 alpha 稳定得多。3.3 学生模型结构选择同架构还是跨架构蒸馏文档里最常见的选择是同架构蒸馏教师是 7B学生是 1.3B两个模型词表一致、层数不同。这样实现最简单连 tokenizer 都不用换logits 对齐方便。跨架构蒸馏比如从 DeepSeek 蒸馏到 Qwen 或 Llama 的小模型也可以做但要先解决词表不一致的问题比如用 teacher 的 tokenizer 生成 logits再映射到 student 的 vocab 上这一步很容易出错。我的建议第一版蒸馏永远选同架构学生模型。先跑通整个流程拿到一个可部署的 checkpoint再考虑跨架构。因为跨架构蒸馏的 tokenizer 映射会让损失函数失真你很难判断效果变差是因为模型结构不匹配还是参数没调好。学生模型的隐藏层维度也要注意不要贪小。从 7B 蒸馏到 0.5B 的参数量差距太大学生模型很可能记不住教师模型的完整知识。一个相对可行的范围是从 7B 蒸馏到 1B~3B再往上压缩需要配合其他压缩手段比如量化和剪枝但这已经超出纯蒸馏的讨论范围了。参数取值范围我常用的影响调试优先级温度 T2.0~6.0决定软标签平滑程度高alpha0.3~0.8可衰减软硬标签配比高学习率3e-5~1e-4学生模型收敛速度中batch size8~32显存占用与噪声中学生模型层数教师模型的 1/3~1/2容量上限低4. 在本地把蒸馏跑起来从加载模型到导出推理4.1 环境准备与模型加载本地蒸馏第一个门槛不是训练而是把模型加载进显存。以 DeepSeek 7B 教师模型为例显存需要 14G 左右fp16学生模型再加 3G再加上优化器和中间激活值一张 24G 显卡勉强能跑。如果你只有 16G 显存可以用 4bit 量化教师模型做推理但要注意量化后的 logits 会有精度损失蒸馏出来的模型质量会略打折扣。安装依赖这一步我直接用 pip 解决不需要额外编译任何自定义算子pip install torch transformers datasets accelerate huggingface_hub加载时教师模型和学生模型分别用各自的 dtype。教师模型用 fp16 省显存学生模型如果要训练最好用 bf16因为蒸馏训练中梯度幅度很小fp16 容易下溢。from transformers import AutoModelForCausalLM, AutoTokenizer teacher AutoModelForCausalLM.from_pretrained( deepseek-ai/deepseek-llm-7b, torch_dtypetorch.float16, device_mapauto ) student AutoModelForCausalLM.from_pretrained( deepseek-ai/deepseek-llm-1.3b, torch_dtypetorch.bfloat16, device_mapauto )device_mapauto会把层自动分配到 GPU 和 CPU 上但训练中这种方式容易产生大量 CPU 与 GPU 之间的张量拷贝拖慢速度。如果显存足够我建议直接把两个模型都.to(cuda)并且把验证集数据一次性加载到显存中减少传递开销。4.2 蒸馏训练与 checkpoint 保存训练循环和普通微调很像唯一要特别注意的教师模型必须处于 eval 模式学生模型必须处于 train 模式。听起来简单但很多人会把教师模型也留在 train 模式BatchNorm 和 Dropout 在生成 logits 时会产生随机性蒸馏出的模型在推理时表现就不稳定。训练过程中每 500 步保存一次 checkpoint不要只等在最后。蒸馏训练经常跑了一半发现温度设置不对劲调整参数之后要能从最近的 checkpoint 继续而不是从头再来。我把保存逻辑写成这样from transformers import TrainerCallback class SaveCheckpointCallback(TrainerCallback): def on_step_end(self, args, state, control, **kwargs): if state.global_step % 500 0: checkpoint_dir fcheckpoints/step_{state.global_step} kwargs[model].save_pretrained(checkpoint_dir) kwargs[tokenizer].save_pretrained(checkpoint_dir)这里的 checkpoint 保存的是学生模型不需要保存教师模型。学生模型权重可以直接用from_pretrained重新加载然后继续蒸馏或者做推理。注意不要把 optimizer 状态混进普通 checkpoint否则文件会非常大而且和后续 vLLM 加载格式不兼容。4.3 把蒸馏结果部署到 vLLM 的注意事项蒸馏完的模型如果想用 vLLM 部署做快速推理需要先把它转成 vLLM 能识别的格式。最简单的方式是直接用 transformers 保存的目录vLLM 支持自动读取python -m vllm.entrypoints.openai.api_server \ --model ./checkpoints/step_5000 \ --tokenizer deepseek-ai/deepseek-llm-1.3b \ --port 8000 \ --gpu-memory-utilization 0.85这里有一个非常隐蔽的坑如果学生模型的 tokenizer 是从教师模型拷贝过来的而学生模型在蒸馏时词表被截断或重排vLLM 启动时不会报错但推理输出会变成乱码。所以加载模型后先跑一个简单的前向推理对比一下输入输出长度是否合理再做并发压测。还有一个常见误区蒸馏后的模型本身就是小模型不需要再用量化压缩。如果你发现显存依然紧张优先减小--max-model-len比如从 8192 降到 4096而不是急着量化。量化会进一步损害小模型本就不充裕的容量很容易让回答质量断崖式下跌。5. 蒸馏避坑五个让我翻车过的常见问题5.1 教师模型输出意外瘫痪logits 分布反常现象训练 loss 在第几个 epoch 突然飙升学生模型生成的内容变成无意义符号。原因教师模型在某些输入上输出了极端 logits比如大量负无穷值导致 KL 散度计算出 NaN。这个情况最容易出现在数据尾部有超长文本、教师模型 context window 被突破时。解决数据预处理里截断输入到模型最大长度的 80%并且在计算 loss 之前用torch.isnan检查 logits 是否含 NaN一旦发现直接跳过这批数据。5.2 温度太高导致学生模型“太软”现象模型所有回答都以“根据目前掌握的信息”开头措辞含糊像在打太极。原因温度 T 设成了 10 甚至更高教师模型的概率分布被过度平滑学生模型学到的是“每个词都有一点可能”的均匀分布。解决把温度降回 2~4 之间并检查教师模型的原始 logits 方差。如果教师模型自身输出方差就很小温度设置再低也没用要考虑换一批难度更高的数据。5.3 评估指标好看但实际对话翻车现象蒸馏后的模型在测试集上的 BLEU、ROUGE 都很高但是人类一聊就发现它避重就轻、答非所问。原因评估数据集和蒸馏数据集分布过于接近学生模型背下了答案模板没有真正学到推理边界。解决单独留出 10% 的硬样本也就是那些教师模型都回答得磕磕绊绊的问题放进验证集而不是训练集。如果硬样本得分低说明学生模型还在“背答案”需要把蒸馏数据的多样性提上来。5.4 显存不足batch_size 调小反而更慢现象24G 显卡训练时报 CUDA out of memory于是把 batch_size 从 16 调到 4结果训练速度反而下降了一半以上。原因batch_size 过小时梯度更新过于频繁而且 GPU 利用率不足每个 step 的时间拉长吞吐量掉得更厉害。解决先用梯度累积来平衡batch_size 保持 8梯度累积步数设为 4等价于每一轮更新用 32 条数据显存占用却只有原来的二分之一。5.5 导出格式与部署端不一致现象本地用 transformers 推理正常导入 vLLM 后输出重复、乱码甚至报 shape mismatch。原因学生模型的 config.json 里vocab_size是 teacher 的原始值而模型权重实际是裁剪后的。解决在保存学生模型前手动修改config.json中的vocab_size和权重真实维度对齐这一步虽然简单但能省掉后面整整一个晚上的排查时间。6. 进阶用“线上表现”反推蒸馏迭代而不是只盯 loss蒸馏跑通只是第一步真正决定这个模型能不能上线要看你敢不敢把线上流量分给它。我个人的经验是loss 和离线指标只用来筛选 checkpoint最终是否留用必须看一组“用户会真的这么问”的样本上的表现。这里有一个具体的技巧把线上日志里的真实用户问题按频率排序取前 2000 条作为评估集而不是自己臆造问题。用户的问题充满了诸如“你上一句话没说清楚”“再解释一遍”之类的话语教师模型对这些问题的回答往往更长、更有层次而学生模型很容易在这些地方显得生硬。我习惯每轮蒸馏后用 API 调用的方式把教师模型和学生模型对同一批问题的回答同时打点人工看 50 条。不对比答案对不对先对比“谁更像一个正常人”。这个环节暴露出的大多不是知识缺失而是“口语感”和“上下文承接力”的差距。发现差距后把这类问题单独收集起来喂回蒸馏数据管道作为下一轮训练的困难样本。训练目标改为每个 batch 都加入 10% 这类困难样本而不是平均采样。另一个容易被忽略的验证方法是长对话稳定性。小模型在单轮问答上往往不输大模型但一旦来回聊上五轮就会开始遗忘前文、重复表述。验证时我会写一个脚本构造 5 轮到 10 轮的多轮对话观察学生模型的指令跟随能力是否衰减。如果衰减明显优先检查训练数据里的多轮对话比例——很多蒸馏数据是单轮问答模型天然没见过长上下文。我在自己的蒸馏迭代里就吃过这个亏第一版模型单轮测试高分拿去和业务方联调时对方说“你这是个金鱼模型吧聊两句就忘”后来把多轮数据占比提升到 30%问题才缓解。蒸馏调参的边界也值得说一下它不是无限迭代的万灵药。如果你连续三轮在相同验证集上都没有明显收益问题往往不在参数而是教师模型本身和学生模型的容量差距太大。这时候与其继续调温度、调 alpha不如换个更大的学生模型比如从 1.3B 换成 4B。我曾经在一个垂直场景里折腾了整整一周换来换去不如直接升级学生模型基座效果一下就通了。最后说一个我的习惯每次蒸馏训练结束我都会跑一遍“冷启动验证”——把模型加载到一台没有任何预热的服务上用 vLLM 部署连续发 50 个问题记录响应时间和首个 token 延迟。因为蒸馏模型在训练时是 batch 输入推理时是单条输入如果训练时没有加 padding mask 处理推理时的计算图会多出一些不必要的运算导致延迟比预期大不少。这个小验证花不了几分钟但能避免你把一个“模型效果不错但延迟超标”的 checkpoint 当成最终的交付版本。希望这条路能帮你少走几步弯路也祝你蒸馏出的模型一次过线。本文还有配套的精品资源点击获取