1. 大模型蒸馏的现状与OPD的破局点1.1 为什么蒸馏成了大模型落地的必修课大模型的能力越来越强但部署成本也水涨船高。一个70B参数的模型光是推理就需要两张A100级别的显卡延迟和吞吐量在真实业务场景里往往撑不住。于是知识蒸馏成了绕不开的环节——把大模型教师模型的能力迁移到小模型学生模型上让学生模型在特定任务上逼近教师的水平同时把参数量压下来。传统的蒸馏路子大致分两种。一种是白盒蒸馏你能拿到教师模型的完整输出分布包括logits和中间层特征学生模型去拟合这些软标签。另一种是黑盒蒸馏你只能看到教师模型的最终输出文本拿这些文本当训练数据去微调学生模型。白盒效果好但需要教师模型的内部访问权限黑盒更通用但信息量少、效率低。实际做过的都知道黑盒蒸馏的Token消耗是个大头。你得让教师模型对海量无标注数据生成回复每一条都要消耗Token数据量一上来成本直接起飞。而且生成的数据质量参差不齐很多Token其实是浪费在重复、低信息量的内容上。1.2 OPD到底改了什么OPDOn-Policy Distillation的核心思路是不再让教师模型离线生成一大堆数据而是让学生模型在训练过程中实时向教师模型提问教师只对当前学生最需要学习的样本给出反馈。这样一来Token的利用率被大幅拉高。传统离线蒸馏像是老师提前录好一整套课程视频学生从头看到尾不管自己会不会、需不需要。OPD则像是学生做题时遇到卡壳的地方老师当场点拨一句学生立刻调整。后者的信息密度显然更高。蚂蚁和MBZUAI的这项工作把OPD的效率推到了一个很夸张的水平1%的Token量就能达到甚至超过传统蒸馏的效果。这意味着原本需要生成100万条数据的蒸馏任务现在只需要1万条左右的高质量交互就能完成。对于算力预算有限的团队来说这个数字的吸引力是致命的。1.3 适合谁来关注这个方向如果你正在做以下事情OPD的思路值得仔细看手上有大模型API预算限制但又想蒸馏出可用的小模型做垂直领域微调标注数据有限想用教师模型的能力来补研究蒸馏算法本身想了解On-Policy和Off-Policy在LLM场景下的差异部署端侧模型需要把大模型能力压缩到7B甚至更小的规模这个方向不要求你有千卡集群单卡或者少量多卡的环境就能跑通核心流程。关键是理解OPD的采样逻辑和损失设计后面的实操部分我会把这两块拆开讲。2. OPD的核心机制拆解2.1 On-Policy采样的本质要理解OPD先得搞清楚On-Policy和Off-Policy在蒸馏里的区别。Off-Policy蒸馏就是传统的做法用教师模型生成一批数据存下来然后拿这批固定数据去训练学生。数据分布是教师模型的分布和学生模型当前的能力状态无关。学生可能早就会了某些样本但训练时还是反复在这些样本上花时间而学生真正薄弱的环节教师生成的数据里可能覆盖得不够。On-Policy蒸馏则反过来让学生模型自己生成回复然后让教师模型对这些回复进行评分或修正学生根据教师的反馈来更新参数。数据分布是学生模型当前的分布教师只针对学生“正在犯的错”给出指导。这个思路在强化学习里很常见但在LLM蒸馏里落地有几个难点。一是学生生成的质量可能很差教师怎么给有效的反馈二是训练过程中学生分布一直在变教师反馈也得跟着变计算开销怎么控制三是怎么保证训练稳定不会因为学生早期太差导致教师反馈全是“重写”而失去梯度信号。蚂蚁和MBZUAI的工作在这几个点上都有针对性的设计后面会展开。2.2 Token效率为什么能提升两个数量级1% Token这个数字听起来夸张但拆开算一下其实合理。假设传统离线蒸馏需要100万条教师生成数据每条平均200个Token总Token消耗是2亿。这2亿Token里真正对学生有信息增益的可能只有一小部分——大量样本是学生已经掌握的或者教师生成的内容和学生当前能力不匹配。OPD的做法是每轮训练只采样学生当前最不确定的样本让教师对这些样本给出密集反馈。假设每轮采样1000条训练100轮总共10万条交互每条平均200Token总消耗2000万Token。相比2亿正好是1%。关键在于这10万条交互的信息密度远高于那100万条离线数据。因为每一条都是针对学生当前状态的“精准打击”没有浪费在已经学会的内容上。注意1%这个数字是特定任务和模型规模下的实验结果不是所有场景都能复现。实际项目中Token节省比例取决于任务难度、教师学生能力差距、采样策略等因素。2.3 教师反馈的三种形式OPD里教师给学生的反馈可以有不同的粒度粒度越细信息量越大但计算成本也越高。第一种是序列级反馈。教师对学生生成的整条回复给一个分数或者一个偏好判断学生根据这个信号做策略梯度更新。这种方式计算最省但信号最稀疏学生很难知道具体哪一步错了。第二种是Token级反馈。教师对学生的每一个生成Token给出概率分布或者logit学生去拟合这个分布。这其实就是白盒蒸馏的On-Policy版本信息量最大但需要教师模型的完整输出层访问权限而且计算开销高。第三种是混合方式。在关键位置比如推理步骤的转折点、答案的关键词给Token级反馈其他位置给序列级反馈。这样在信息量和成本之间取平衡。蚂蚁和MBZUAI的论文里主要用的是第二种和第三种具体选择取决于教师模型是否开源、推理预算多少。2.4 训练稳定性的保障机制On-Policy蒸馏有个天然的风险学生早期生成的质量很差教师反馈可能全是负面的导致学生梯度方向混乱训练崩掉。常见的保障手段有几个。一是教师修正不直接让学生拟合自己的输出而是让学生拟合教师修正后的输出。比如学生生成了一句有语法错误的回复教师把它改对学生去学这个改对的版本。这样即使学生早期很差教师也能提供正向的学习信号。二是重要性采样在策略梯度里用重要性权重来修正学生分布和采样分布之间的偏差避免梯度估计方差过大。三是KL约束在学生更新时加一个KL散度约束防止学生偏离教师太远。这个约束的系数需要调太大学生学不动太小训练不稳定。四是课程学习先从简单样本开始等学生能力上来再逐步增加难度。这个在OPD里可以通过控制采样策略来实现。3. 实操流程与关键参数3.1 环境准备与依赖安装先说一下基础环境。这套流程对硬件的要求取决于教师模型的规模。如果教师模型是7B级别的单张24G显存的卡就能跑如果是70B级别至少需要两张A100 80G或者四张4090。软件依赖主要是PyTorch、Transformers、DeepSpeed或者FSDP以及一个用于高效推理的框架比如vLLM。下面是基础安装命令pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets accelerate pip install deepspeed pip install vllm如果要用LoRA做参数高效微调再加一个peftpip install peft提示vLLM的版本要和CUDA版本匹配装之前先确认驱动支持的CUDA版本。版本不匹配会导致推理时各种奇怪的报错。3.2 数据准备与采样策略OPD不需要海量的离线数据但需要一批种子问题作为学生生成的起点。这批种子问题的质量直接影响蒸馏效果。种子问题的来源可以是目标任务的实际输入分布比如你要蒸馏一个客服模型就用真实用户问题教师模型生成的一些多样化问题公开数据集中与目标任务相关的部分种子问题的数量不用多几千条就够。关键是覆盖面要广要能触发学生模型在不同能力维度上的表现。采样策略是OPD的核心。每一轮训练时从种子问题池里采样一批问题让学生生成回复然后根据学生的生成结果决定哪些样本送给教师。采样的依据可以是学生生成的置信度置信度低的样本优先送给教师学生生成结果的多样性多样性高的样本说明学生不确定值得教师反馈历史训练中的损失损失高的样本说明学生还没学好实际实现时可以维护一个样本优先级队列每轮训练后更新优先级。3.3 教师反馈的获取与处理教师反馈的获取方式取决于教师模型的部署形式。如果教师模型是本地部署的开源模型可以直接拿到logits。用vLLM的话可以通过设置logprobs参数来获取每个Token的对数概率from vllm import LLM, SamplingParams llm LLM(modelteacher_model_path) sampling_params SamplingParams( temperature0.7, max_tokens512, logprobs5 # 返回top-5 token的logprob ) outputs llm.generate(prompts, sampling_params)如果教师模型只能通过API访问那就只能拿到文本输出需要把文本级的反馈转换成训练信号。一种做法是用教师输出作为目标序列做序列级的交叉熵训练另一种做法是用教师输出和学生的输出做对比训练一个奖励模型或者用DPO类的损失。拿到教师反馈后需要和学生的生成结果对齐。Token级的反馈要求教师和学生的tokenizer一致否则需要做token对齐处理。这个对齐在实操中很容易出错建议先用小批量数据验证对齐逻辑。3.4 损失函数设计与参数配置OPD的损失函数通常由两部分组成蒸馏损失和任务损失。蒸馏损失衡量学生输出和教师反馈之间的差距。如果是Token级反馈用KL散度import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, temperature2.0): student_log_probs F.log_softmax(student_logits / temperature, dim-1) teacher_probs F.softmax(teacher_logits / temperature, dim-1) kl_loss F.kl_div(student_log_probs, teacher_probs, reductionbatchmean) return kl_loss * (temperature ** 2)温度参数temperature控制软标签的平滑程度。温度越高教师分布越平滑学生学到的信息越丰富但太高的温度会让分布接近均匀失去区分度。一般设在1.5到3之间。任务损失就是常规的交叉熵用真实标签或者教师修正后的输出作为目标。总损失是两者的加权和total_loss alpha * distillation_loss (1 - alpha) * task_lossalpha一般设在0.5到0.9之间具体看任务。如果教师反馈质量高alpha可以大一些如果教师反馈噪声大alpha要小一些。学习率方面OPD通常用比常规微调更小的学习率因为On-Policy的训练信号方差更大。建议从1e-5开始试如果训练不稳定就降到5e-6。3.5 训练循环的完整实现把上面的模块串起来一个简化的OPD训练循环长这样for epoch in range(num_epochs): # 1. 采样种子问题 batch_questions sample_questions(question_pool, batch_size) # 2. 学生生成回复 student_outputs student_model.generate(batch_questions) # 3. 计算样本优先级 priorities compute_priorities(student_outputs) # 4. 选择高优先级样本送给教师 selected_indices select_top_k(priorities, kteacher_budget) selected_questions [batch_questions[i] for i in selected_indices] selected_student_outputs [student_outputs[i] for i in selected_indices] # 5. 获取教师反馈 teacher_feedback teacher_model.get_feedback( selected_questions, selected_student_outputs ) # 6. 计算损失并更新学生 for q, s_out, t_fb in zip(selected_questions, selected_student_outputs, teacher_feedback): student_logits student_model(q, s_out) loss compute_loss(student_logits, t_fb) loss.backward() optimizer.step() optimizer.zero_grad() # 7. 更新样本优先级 update_priorities(question_pool, priorities)这个循环里教师只在第5步被调用而且只处理被选中的样本。如果teacher_budget设得小教师调用次数就少Token消耗自然低。注意学生生成和教师反馈这两步的batch size可以不一样。学生生成可以大batch教师反馈因为要控制Token消耗batch要小。实际实现时可以把这两步解耦学生生成用大batch跑然后从里面挑样本给教师。4. 常见问题与排查技巧4.1 训练不收敛或者loss震荡这是OPD最常见的问题。原因通常有几个教师反馈噪声太大。如果教师模型本身在某些样本上表现不好给出的反馈就是错的学生学了反而变差。解决办法是加一个教师置信度过滤只保留教师高置信度的反馈。学习率太大。On-Policy的训练信号方差比Off-Policy大学习率要相应调小。可以先跑一个学习率扫描看哪个学习率下loss下降最平稳。KL约束系数不合适。KL约束太强学生被绑在教师附近学不动太弱学生跑偏。可以动态调整KL系数训练初期小一些后期大一些。样本优先级更新太快。如果每轮都大幅更新优先级采样分布变化太剧烈训练不稳定。可以给优先级更新加一个动量项让分布变化平滑一些。4.2 教师Token消耗还是太高虽然OPD理论上能省Token但实操中如果采样策略没设计好Token消耗还是可能失控。控制教师调用频率。不是每一轮训练都要调用教师。可以每N轮调用一次教师中间几轮用历史教师反馈做Off-Policy训练。这样Token消耗直接除以N。限制教师反馈的长度。教师不需要对学生的整条回复都给出Token级反馈可以只对关键片段给反馈。比如只对答案部分给Token级反馈推理过程给序列级反馈。缓存教师反馈。如果某些样本在多个轮次里被重复采样教师反馈可以缓存复用。用一个哈希表存样本和对应反馈采样时先查缓存。用更小的教师模型。如果70B教师太贵可以先用70B教师蒸馏一个7B的中间教师再用7B教师去蒸馏目标学生。两级蒸馏的Token消耗比一级蒸馏低不少。4.3 学生生成质量太差导致教师反馈无效学生早期生成的东西可能完全没法看教师反馈全是“重写”学生学不到东西。用教师修正代替教师评分。不让学生去拟合自己的差输出而是让学生拟合教师修正后的好输出。这样即使学生早期很差也有正向的学习目标。课程学习。先从简单任务开始等学生能力上来再增加难度。简单任务的判断可以用教师模型的置信度教师置信度高的样本就是简单样本。预热阶段用Off-Policy。训练最开始的一小段用离线数据做预热等学生有基本能力了再切换到On-Policy。预热数据不用多几千条就够。4.4 Tokenizer不一致导致对齐失败如果教师和学生用的tokenizer不一样Token级的反馈没法直接对齐。这个问题在跨模型蒸馏时很常见。统一tokenizer。如果可能的话让学生和教师用同一个tokenizer。比如都基于Llama tokenizer或者都基于GPT tokenizer。做token对齐。如果tokenizer没法统一需要做token级别的对齐。一种做法是把教师和学生的token序列都映射到字符级别然后在字符级别做对齐。这个实现起来比较麻烦但效果还行。退化为序列级反馈。如果对齐成本太高干脆放弃Token级反馈只用序列级反馈。虽然信息量少一些但实现简单不容易出错。4.5 常见问题速查表问题现象可能原因排查方向解决思路loss震荡不下降学习率太大打印每步loss看波动幅度降低学习率到1e-5以下学生输出重复教师反馈单一检查教师反馈的多样性增加采样温度用教师修正Token消耗超预期教师调用太频繁统计每轮教师调用次数降低调用频率加缓存训练后期性能下降过拟合教师噪声对比学生和教师在验证集上的表现加KL约束过滤低置信反馈对齐报错tokenizer不一致检查教师和学生的vocab统一tokenizer或做字符级对齐显存不够batch太大或模型太大看显存占用峰值减小batch用梯度累积教师反馈全是负面学生早期太差看学生生成样本加预热阶段用课程学习提示这张表里的排查方向是按优先级排的遇到问题先从第一列的现象出发按顺序排查大部分问题在前三行就能定位到。5. 效果验证与调优经验5.1 怎么判断蒸馏是否成功蒸馏效果不能只看训练loss要看学生在目标任务上的实际表现。验证集要覆盖目标任务的真实分布不能只用训练时见过的样本类型。评估指标分两类。一类是任务指标比如分类任务的准确率、生成任务的BLEU或ROUGE、推理任务的准确率。另一类是蒸馏指标衡量学生和教师输出分布的距离比如KL散度、Top-k重叠率。实际项目中任务指标是最终标准蒸馏指标用来辅助诊断。如果任务指标上不去但蒸馏指标很好说明学生学到了教师的分布但没学到任务相关的知识可能是蒸馏目标设错了。如果蒸馏指标差但任务指标还行说明学生在任务上找到了自己的解法不一定要完全模仿教师。5.2 教师模型选择的经验教师模型不是越大越好。太大的教师模型推理成本高而且教师和学生能力差距太大时学生的拟合难度反而增加。一个经验法则是教师模型的参数量是学生的5到10倍比较合适。比如要蒸馏一个1B的学生教师选7B到10B要蒸馏7B的学生教师选70B左右。教师模型的任务能力也很重要。如果教师在自己不擅长的任务上给学生反馈反馈质量会很差。选教师时要在目标任务上先评估一下教师的表现确保教师在这个任务上是靠谱的。另外教师模型的输出多样性也值得关注。有些教师模型倾向于生成很保守的回复多样性低学生学到的东西也单一。可以在教师推理时调高温度增加输出的多样性。5.3 采样策略的调优采样策略直接决定Token效率。几个调优方向优先级函数的形状。优先级函数决定了哪些样本被选中。如果优先级函数太陡只有极少数样本被反复采样覆盖面不够太缓的话采样退化成随机采样失去On-Policy的优势。建议用softmax形状的优先级函数温度参数控制陡峭程度。采样池的更新频率。采样池不能一直不变否则学生会过拟合池子里的样本。但更新太快又会导致训练不稳定。建议每轮更新一小部分比如替换掉池子里表现最好的10%样本。探索与利用的平衡。采样时既要利用已知的高优先级样本也要探索新的样本。可以用epsilon-greedy策略以一定概率随机采样保证覆盖面。5.4 我踩过的几个坑第一个坑是教师反馈的格式不统一。教师模型有时候输出JSON有时候输出纯文本解析的时候各种报错。后来加了一个格式规范化层把所有教师输出统一成固定格式再送进训练问题才解决。第二个坑是学生生成的截断。学生生成时设了max_tokens有些回复被截断了教师对截断的回复给反馈学生学到的就是半截的东西。后来在采样时过滤掉被截断的样本训练稳定了很多。第三个坑是验证集泄漏。种子问题池里混进了验证集的样本导致验证指标虚高。后来在构建种子池时严格做了去重和划分确保验证集样本不出现在训练流程的任何环节。第四个坑是显存碎片化。训练跑久了显存占用越来越高最后OOM。原因是PyTorch的显存缓存机制在变长序列场景下容易碎片化。解决办法是定期调用torch.cuda.empty_cache()或者用固定长度的序列做padding。5.5 后续可以扩展的方向OPD这套框架还可以往几个方向延伸。多教师蒸馏。用多个不同专长的教师模型每个教师负责自己擅长的样本类型。采样时根据样本类型路由到对应的教师。这样学生的能力覆盖面更广。在线持续学习。把OPD和在线学习结合起来学生在部署后继续从教师那里获取反馈持续更新。适合那些数据分布会随时间变化的任务。跨模态蒸馏。OPD的思路不限于文本可以扩展到多模态场景。比如用一个大视觉语言模型作为教师蒸馏一个小的视觉模型。自蒸馏。如果没有外部教师可以用学生自己的历史版本作为教师做自蒸馏。虽然效果不如外部教师但完全不需要额外的模型部署。这套东西的核心思想其实很简单把Token花在刀刃上。传统蒸馏是广撒网OPD是精准打击。理解了这一点具体的实现细节都可以根据自己的场景灵活调整。 OPD大模型蒸馏实战：1% Token实现高效知识迁移
1. 大模型蒸馏的现状与OPD的破局点1.1 为什么蒸馏成了大模型落地的必修课大模型的能力越来越强但部署成本也水涨船高。一个70B参数的模型光是推理就需要两张A100级别的显卡延迟和吞吐量在真实业务场景里往往撑不住。于是知识蒸馏成了绕不开的环节——把大模型教师模型的能力迁移到小模型学生模型上让学生模型在特定任务上逼近教师的水平同时把参数量压下来。传统的蒸馏路子大致分两种。一种是白盒蒸馏你能拿到教师模型的完整输出分布包括logits和中间层特征学生模型去拟合这些软标签。另一种是黑盒蒸馏你只能看到教师模型的最终输出文本拿这些文本当训练数据去微调学生模型。白盒效果好但需要教师模型的内部访问权限黑盒更通用但信息量少、效率低。实际做过的都知道黑盒蒸馏的Token消耗是个大头。你得让教师模型对海量无标注数据生成回复每一条都要消耗Token数据量一上来成本直接起飞。而且生成的数据质量参差不齐很多Token其实是浪费在重复、低信息量的内容上。1.2 OPD到底改了什么OPDOn-Policy Distillation的核心思路是不再让教师模型离线生成一大堆数据而是让学生模型在训练过程中实时向教师模型提问教师只对当前学生最需要学习的样本给出反馈。这样一来Token的利用率被大幅拉高。传统离线蒸馏像是老师提前录好一整套课程视频学生从头看到尾不管自己会不会、需不需要。OPD则像是学生做题时遇到卡壳的地方老师当场点拨一句学生立刻调整。后者的信息密度显然更高。蚂蚁和MBZUAI的这项工作把OPD的效率推到了一个很夸张的水平1%的Token量就能达到甚至超过传统蒸馏的效果。这意味着原本需要生成100万条数据的蒸馏任务现在只需要1万条左右的高质量交互就能完成。对于算力预算有限的团队来说这个数字的吸引力是致命的。1.3 适合谁来关注这个方向如果你正在做以下事情OPD的思路值得仔细看手上有大模型API预算限制但又想蒸馏出可用的小模型做垂直领域微调标注数据有限想用教师模型的能力来补研究蒸馏算法本身想了解On-Policy和Off-Policy在LLM场景下的差异部署端侧模型需要把大模型能力压缩到7B甚至更小的规模这个方向不要求你有千卡集群单卡或者少量多卡的环境就能跑通核心流程。关键是理解OPD的采样逻辑和损失设计后面的实操部分我会把这两块拆开讲。2. OPD的核心机制拆解2.1 On-Policy采样的本质要理解OPD先得搞清楚On-Policy和Off-Policy在蒸馏里的区别。Off-Policy蒸馏就是传统的做法用教师模型生成一批数据存下来然后拿这批固定数据去训练学生。数据分布是教师模型的分布和学生模型当前的能力状态无关。学生可能早就会了某些样本但训练时还是反复在这些样本上花时间而学生真正薄弱的环节教师生成的数据里可能覆盖得不够。On-Policy蒸馏则反过来让学生模型自己生成回复然后让教师模型对这些回复进行评分或修正学生根据教师的反馈来更新参数。数据分布是学生模型当前的分布教师只针对学生“正在犯的错”给出指导。这个思路在强化学习里很常见但在LLM蒸馏里落地有几个难点。一是学生生成的质量可能很差教师怎么给有效的反馈二是训练过程中学生分布一直在变教师反馈也得跟着变计算开销怎么控制三是怎么保证训练稳定不会因为学生早期太差导致教师反馈全是“重写”而失去梯度信号。蚂蚁和MBZUAI的工作在这几个点上都有针对性的设计后面会展开。2.2 Token效率为什么能提升两个数量级1% Token这个数字听起来夸张但拆开算一下其实合理。假设传统离线蒸馏需要100万条教师生成数据每条平均200个Token总Token消耗是2亿。这2亿Token里真正对学生有信息增益的可能只有一小部分——大量样本是学生已经掌握的或者教师生成的内容和学生当前能力不匹配。OPD的做法是每轮训练只采样学生当前最不确定的样本让教师对这些样本给出密集反馈。假设每轮采样1000条训练100轮总共10万条交互每条平均200Token总消耗2000万Token。相比2亿正好是1%。关键在于这10万条交互的信息密度远高于那100万条离线数据。因为每一条都是针对学生当前状态的“精准打击”没有浪费在已经学会的内容上。注意1%这个数字是特定任务和模型规模下的实验结果不是所有场景都能复现。实际项目中Token节省比例取决于任务难度、教师学生能力差距、采样策略等因素。2.3 教师反馈的三种形式OPD里教师给学生的反馈可以有不同的粒度粒度越细信息量越大但计算成本也越高。第一种是序列级反馈。教师对学生生成的整条回复给一个分数或者一个偏好判断学生根据这个信号做策略梯度更新。这种方式计算最省但信号最稀疏学生很难知道具体哪一步错了。第二种是Token级反馈。教师对学生的每一个生成Token给出概率分布或者logit学生去拟合这个分布。这其实就是白盒蒸馏的On-Policy版本信息量最大但需要教师模型的完整输出层访问权限而且计算开销高。第三种是混合方式。在关键位置比如推理步骤的转折点、答案的关键词给Token级反馈其他位置给序列级反馈。这样在信息量和成本之间取平衡。蚂蚁和MBZUAI的论文里主要用的是第二种和第三种具体选择取决于教师模型是否开源、推理预算多少。2.4 训练稳定性的保障机制On-Policy蒸馏有个天然的风险学生早期生成的质量很差教师反馈可能全是负面的导致学生梯度方向混乱训练崩掉。常见的保障手段有几个。一是教师修正不直接让学生拟合自己的输出而是让学生拟合教师修正后的输出。比如学生生成了一句有语法错误的回复教师把它改对学生去学这个改对的版本。这样即使学生早期很差教师也能提供正向的学习信号。二是重要性采样在策略梯度里用重要性权重来修正学生分布和采样分布之间的偏差避免梯度估计方差过大。三是KL约束在学生更新时加一个KL散度约束防止学生偏离教师太远。这个约束的系数需要调太大学生学不动太小训练不稳定。四是课程学习先从简单样本开始等学生能力上来再逐步增加难度。这个在OPD里可以通过控制采样策略来实现。3. 实操流程与关键参数3.1 环境准备与依赖安装先说一下基础环境。这套流程对硬件的要求取决于教师模型的规模。如果教师模型是7B级别的单张24G显存的卡就能跑如果是70B级别至少需要两张A100 80G或者四张4090。软件依赖主要是PyTorch、Transformers、DeepSpeed或者FSDP以及一个用于高效推理的框架比如vLLM。下面是基础安装命令pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets accelerate pip install deepspeed pip install vllm如果要用LoRA做参数高效微调再加一个peftpip install peft提示vLLM的版本要和CUDA版本匹配装之前先确认驱动支持的CUDA版本。版本不匹配会导致推理时各种奇怪的报错。3.2 数据准备与采样策略OPD不需要海量的离线数据但需要一批种子问题作为学生生成的起点。这批种子问题的质量直接影响蒸馏效果。种子问题的来源可以是目标任务的实际输入分布比如你要蒸馏一个客服模型就用真实用户问题教师模型生成的一些多样化问题公开数据集中与目标任务相关的部分种子问题的数量不用多几千条就够。关键是覆盖面要广要能触发学生模型在不同能力维度上的表现。采样策略是OPD的核心。每一轮训练时从种子问题池里采样一批问题让学生生成回复然后根据学生的生成结果决定哪些样本送给教师。采样的依据可以是学生生成的置信度置信度低的样本优先送给教师学生生成结果的多样性多样性高的样本说明学生不确定值得教师反馈历史训练中的损失损失高的样本说明学生还没学好实际实现时可以维护一个样本优先级队列每轮训练后更新优先级。3.3 教师反馈的获取与处理教师反馈的获取方式取决于教师模型的部署形式。如果教师模型是本地部署的开源模型可以直接拿到logits。用vLLM的话可以通过设置logprobs参数来获取每个Token的对数概率from vllm import LLM, SamplingParams llm LLM(modelteacher_model_path) sampling_params SamplingParams( temperature0.7, max_tokens512, logprobs5 # 返回top-5 token的logprob ) outputs llm.generate(prompts, sampling_params)如果教师模型只能通过API访问那就只能拿到文本输出需要把文本级的反馈转换成训练信号。一种做法是用教师输出作为目标序列做序列级的交叉熵训练另一种做法是用教师输出和学生的输出做对比训练一个奖励模型或者用DPO类的损失。拿到教师反馈后需要和学生的生成结果对齐。Token级的反馈要求教师和学生的tokenizer一致否则需要做token对齐处理。这个对齐在实操中很容易出错建议先用小批量数据验证对齐逻辑。3.4 损失函数设计与参数配置OPD的损失函数通常由两部分组成蒸馏损失和任务损失。蒸馏损失衡量学生输出和教师反馈之间的差距。如果是Token级反馈用KL散度import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, temperature2.0): student_log_probs F.log_softmax(student_logits / temperature, dim-1) teacher_probs F.softmax(teacher_logits / temperature, dim-1) kl_loss F.kl_div(student_log_probs, teacher_probs, reductionbatchmean) return kl_loss * (temperature ** 2)温度参数temperature控制软标签的平滑程度。温度越高教师分布越平滑学生学到的信息越丰富但太高的温度会让分布接近均匀失去区分度。一般设在1.5到3之间。任务损失就是常规的交叉熵用真实标签或者教师修正后的输出作为目标。总损失是两者的加权和total_loss alpha * distillation_loss (1 - alpha) * task_lossalpha一般设在0.5到0.9之间具体看任务。如果教师反馈质量高alpha可以大一些如果教师反馈噪声大alpha要小一些。学习率方面OPD通常用比常规微调更小的学习率因为On-Policy的训练信号方差更大。建议从1e-5开始试如果训练不稳定就降到5e-6。3.5 训练循环的完整实现把上面的模块串起来一个简化的OPD训练循环长这样for epoch in range(num_epochs): # 1. 采样种子问题 batch_questions sample_questions(question_pool, batch_size) # 2. 学生生成回复 student_outputs student_model.generate(batch_questions) # 3. 计算样本优先级 priorities compute_priorities(student_outputs) # 4. 选择高优先级样本送给教师 selected_indices select_top_k(priorities, kteacher_budget) selected_questions [batch_questions[i] for i in selected_indices] selected_student_outputs [student_outputs[i] for i in selected_indices] # 5. 获取教师反馈 teacher_feedback teacher_model.get_feedback( selected_questions, selected_student_outputs ) # 6. 计算损失并更新学生 for q, s_out, t_fb in zip(selected_questions, selected_student_outputs, teacher_feedback): student_logits student_model(q, s_out) loss compute_loss(student_logits, t_fb) loss.backward() optimizer.step() optimizer.zero_grad() # 7. 更新样本优先级 update_priorities(question_pool, priorities)这个循环里教师只在第5步被调用而且只处理被选中的样本。如果teacher_budget设得小教师调用次数就少Token消耗自然低。注意学生生成和教师反馈这两步的batch size可以不一样。学生生成可以大batch教师反馈因为要控制Token消耗batch要小。实际实现时可以把这两步解耦学生生成用大batch跑然后从里面挑样本给教师。4. 常见问题与排查技巧4.1 训练不收敛或者loss震荡这是OPD最常见的问题。原因通常有几个教师反馈噪声太大。如果教师模型本身在某些样本上表现不好给出的反馈就是错的学生学了反而变差。解决办法是加一个教师置信度过滤只保留教师高置信度的反馈。学习率太大。On-Policy的训练信号方差比Off-Policy大学习率要相应调小。可以先跑一个学习率扫描看哪个学习率下loss下降最平稳。KL约束系数不合适。KL约束太强学生被绑在教师附近学不动太弱学生跑偏。可以动态调整KL系数训练初期小一些后期大一些。样本优先级更新太快。如果每轮都大幅更新优先级采样分布变化太剧烈训练不稳定。可以给优先级更新加一个动量项让分布变化平滑一些。4.2 教师Token消耗还是太高虽然OPD理论上能省Token但实操中如果采样策略没设计好Token消耗还是可能失控。控制教师调用频率。不是每一轮训练都要调用教师。可以每N轮调用一次教师中间几轮用历史教师反馈做Off-Policy训练。这样Token消耗直接除以N。限制教师反馈的长度。教师不需要对学生的整条回复都给出Token级反馈可以只对关键片段给反馈。比如只对答案部分给Token级反馈推理过程给序列级反馈。缓存教师反馈。如果某些样本在多个轮次里被重复采样教师反馈可以缓存复用。用一个哈希表存样本和对应反馈采样时先查缓存。用更小的教师模型。如果70B教师太贵可以先用70B教师蒸馏一个7B的中间教师再用7B教师去蒸馏目标学生。两级蒸馏的Token消耗比一级蒸馏低不少。4.3 学生生成质量太差导致教师反馈无效学生早期生成的东西可能完全没法看教师反馈全是“重写”学生学不到东西。用教师修正代替教师评分。不让学生去拟合自己的差输出而是让学生拟合教师修正后的好输出。这样即使学生早期很差也有正向的学习目标。课程学习。先从简单任务开始等学生能力上来再增加难度。简单任务的判断可以用教师模型的置信度教师置信度高的样本就是简单样本。预热阶段用Off-Policy。训练最开始的一小段用离线数据做预热等学生有基本能力了再切换到On-Policy。预热数据不用多几千条就够。4.4 Tokenizer不一致导致对齐失败如果教师和学生用的tokenizer不一样Token级的反馈没法直接对齐。这个问题在跨模型蒸馏时很常见。统一tokenizer。如果可能的话让学生和教师用同一个tokenizer。比如都基于Llama tokenizer或者都基于GPT tokenizer。做token对齐。如果tokenizer没法统一需要做token级别的对齐。一种做法是把教师和学生的token序列都映射到字符级别然后在字符级别做对齐。这个实现起来比较麻烦但效果还行。退化为序列级反馈。如果对齐成本太高干脆放弃Token级反馈只用序列级反馈。虽然信息量少一些但实现简单不容易出错。4.5 常见问题速查表问题现象可能原因排查方向解决思路loss震荡不下降学习率太大打印每步loss看波动幅度降低学习率到1e-5以下学生输出重复教师反馈单一检查教师反馈的多样性增加采样温度用教师修正Token消耗超预期教师调用太频繁统计每轮教师调用次数降低调用频率加缓存训练后期性能下降过拟合教师噪声对比学生和教师在验证集上的表现加KL约束过滤低置信反馈对齐报错tokenizer不一致检查教师和学生的vocab统一tokenizer或做字符级对齐显存不够batch太大或模型太大看显存占用峰值减小batch用梯度累积教师反馈全是负面学生早期太差看学生生成样本加预热阶段用课程学习提示这张表里的排查方向是按优先级排的遇到问题先从第一列的现象出发按顺序排查大部分问题在前三行就能定位到。5. 效果验证与调优经验5.1 怎么判断蒸馏是否成功蒸馏效果不能只看训练loss要看学生在目标任务上的实际表现。验证集要覆盖目标任务的真实分布不能只用训练时见过的样本类型。评估指标分两类。一类是任务指标比如分类任务的准确率、生成任务的BLEU或ROUGE、推理任务的准确率。另一类是蒸馏指标衡量学生和教师输出分布的距离比如KL散度、Top-k重叠率。实际项目中任务指标是最终标准蒸馏指标用来辅助诊断。如果任务指标上不去但蒸馏指标很好说明学生学到了教师的分布但没学到任务相关的知识可能是蒸馏目标设错了。如果蒸馏指标差但任务指标还行说明学生在任务上找到了自己的解法不一定要完全模仿教师。5.2 教师模型选择的经验教师模型不是越大越好。太大的教师模型推理成本高而且教师和学生能力差距太大时学生的拟合难度反而增加。一个经验法则是教师模型的参数量是学生的5到10倍比较合适。比如要蒸馏一个1B的学生教师选7B到10B要蒸馏7B的学生教师选70B左右。教师模型的任务能力也很重要。如果教师在自己不擅长的任务上给学生反馈反馈质量会很差。选教师时要在目标任务上先评估一下教师的表现确保教师在这个任务上是靠谱的。另外教师模型的输出多样性也值得关注。有些教师模型倾向于生成很保守的回复多样性低学生学到的东西也单一。可以在教师推理时调高温度增加输出的多样性。5.3 采样策略的调优采样策略直接决定Token效率。几个调优方向优先级函数的形状。优先级函数决定了哪些样本被选中。如果优先级函数太陡只有极少数样本被反复采样覆盖面不够太缓的话采样退化成随机采样失去On-Policy的优势。建议用softmax形状的优先级函数温度参数控制陡峭程度。采样池的更新频率。采样池不能一直不变否则学生会过拟合池子里的样本。但更新太快又会导致训练不稳定。建议每轮更新一小部分比如替换掉池子里表现最好的10%样本。探索与利用的平衡。采样时既要利用已知的高优先级样本也要探索新的样本。可以用epsilon-greedy策略以一定概率随机采样保证覆盖面。5.4 我踩过的几个坑第一个坑是教师反馈的格式不统一。教师模型有时候输出JSON有时候输出纯文本解析的时候各种报错。后来加了一个格式规范化层把所有教师输出统一成固定格式再送进训练问题才解决。第二个坑是学生生成的截断。学生生成时设了max_tokens有些回复被截断了教师对截断的回复给反馈学生学到的就是半截的东西。后来在采样时过滤掉被截断的样本训练稳定了很多。第三个坑是验证集泄漏。种子问题池里混进了验证集的样本导致验证指标虚高。后来在构建种子池时严格做了去重和划分确保验证集样本不出现在训练流程的任何环节。第四个坑是显存碎片化。训练跑久了显存占用越来越高最后OOM。原因是PyTorch的显存缓存机制在变长序列场景下容易碎片化。解决办法是定期调用torch.cuda.empty_cache()或者用固定长度的序列做padding。5.5 后续可以扩展的方向OPD这套框架还可以往几个方向延伸。多教师蒸馏。用多个不同专长的教师模型每个教师负责自己擅长的样本类型。采样时根据样本类型路由到对应的教师。这样学生的能力覆盖面更广。在线持续学习。把OPD和在线学习结合起来学生在部署后继续从教师那里获取反馈持续更新。适合那些数据分布会随时间变化的任务。跨模态蒸馏。OPD的思路不限于文本可以扩展到多模态场景。比如用一个大视觉语言模型作为教师蒸馏一个小的视觉模型。自蒸馏。如果没有外部教师可以用学生自己的历史版本作为教师做自蒸馏。虽然效果不如外部教师但完全不需要额外的模型部署。这套东西的核心思想其实很简单把Token花在刀刃上。传统蒸馏是广撒网OPD是精准打击。理解了这一点具体的实现细节都可以根据自己的场景灵活调整。