1. 为什么蒸馏这条路值得走成本账与技术账旗舰模型每天都在变聪明可它们的使用门槛也越来越高。Claude 4.6 Opus 的推理能力确实顶尖但按 token 计费的成本、响应延迟、数据隐私约束让不少团队卡在生产环境的门口。把这份推理能力蒸馏到 Qwen3.5 27B 这样的开源中型模型里听起来很诱人做起来却有不少门道。这篇文章是我自己完整跑过一遍蒸馏流程后的复盘内容包括方案选型、数据准备、训练配置、评测排坑和部署落地适合已经有模型微调经验、正在考虑私有化部署大模型的开发者参考。先说最现实的问题钱。企业应用里如果每天有几十万次请求每次请求携带长上下文按 token 计费的成本会涨到让人心疼。我见过一个内部知识助手项目早期全部走旗舰模型 API一个月账单六位数而且每次回答延迟在 3 到 5 秒。换成本地部署的 27B 模型后单卡 A100 就能撑起并发单次推理延迟压到 1 秒内成本变成一次性的硬件采购和电费。这就是很多人对蒸馏感兴趣的直接原因——不是不认可旗舰模型的能力而是没法不计成本地把它接到生产流量上。再看控制权和数据边界。金融、医疗、政务这类场景里客户往往明确要求数据不出域外部 API 根本不在考虑范围内。即便是不敏感的行业把内部知识库、客户对话记录送到外部模型手里也会让法务和合规部门睡不好觉。这种情况下本地一个可信、可控、能力又够用的模型比什么都重要。Qwen3.5 27B 在开源模型里属于聪明且不娇贵的档位它能跑在常见的企业级显卡上也能轻松做量化和容器化这正是它适合作为蒸馏承接目标的原因。1.1 蒸馏与普通微调的本质区别很多人会把蒸馏误当成用高端模型生成一批数据然后微调小模型这个理解不算错但没有抓到关键。普通的指令微调目标是让小模型学会某种输出格式或某个知识领域的记忆而蒸馏核心目标是让模型学会教师模型的推理方式。打个比方同样一道数学题普通微调给小模型的是题目和答案蒸馏给小模型的是题目、思考步骤和答案。旗舰模型在数学、代码、逻辑规划上的优势很大程度上来自它在给出最终答案之前经历的那段链式思考。如果只是把最终答案丢给学生模型那它记住的是这个题目的答案是什么如果把整个推理轨迹丢给它它才有可能学会遇到这类问题时应该按什么逻辑一步步推进。所以在我后面的实操流程里采集教师的推理过程会比单纯采集答案重要得多。1.2 为什么是 27B 这个规模模型规模选择其实是在能力和部署友好度之间做妥协。7B、14B 模型部署门槛最低但蒸馏能力和上限有限复杂推理经常学不进去70B 级别能力更强可是全参微调要八卡起步量化后也不是每台机器都能塞得下。27B 正好卡在中间显存占用可控4bit 量化后约 20GB 以内推理速度对一个中型级服务绰绰有余而它本身的基础能力池也足够大能真正承接从教师模型迁移过来的一部分推理模式。在实际训练中这个规模做 LoRA 或者全参微调都是可行的后文会展开讲硬件规划。2. 开始之前先把这几个选择想清楚动手训练之前至少有四件事需要提前定下来教师模型输出用什么格式、学生模型选哪个版本、训练框架用哪个、硬件怎么安排。这四件事直接影响后续数据清洗和训练效果属于前置的省心工程建议认真过一遍。2.1 教师模型优先采集推理链而非最终答案蒸馏的第一步是确定教师模型能提供什么样的输出。以 Claude 4.6 Opus 为例它的普通对话输出质量已经很高但如果目标是迁移推理能力更值得采集的是它在给出最终结论之前产生的扩展思考内容。这类内容包含问题分析、步骤拆解、自我校验等过程是学生模型真正需要模仿的对象。采集时我有两个常用的配置组合让教师模型输出带推理过程的结构化回答比如在回复中用特定标记区分思考和结论温度设置在 0.7 到 1.0 之间多次采样同一批问题这样能获得一个问题的多种解法路径避免训练集过于单一。同时要注意不要让教师模型每次都生成固定长度、固定措辞的回复。采样次数太少学生模型会学到过度自信的单一模式采样次数太多噪声也会变多。我一般每个 prompt 采 3 到 5 条之后还会做去重和长度过滤。2.2 学生模型Base 版本还是 Instruct 版本这个问题我踩过坑。Qwen3.5 27B 同时有 Base 和 Instruct 两条产品线蒸馏目标不同选择也不同。用 Instruct 版本做起点收敛速度快模型从一开始就懂得对话格式和基本指令跟随但缺点是它会带着原本的旧习惯某些生成风格很难被彻底洗掉尤其是当教师模型的输出习惯和原模型差异较大时反而会互相打架。用 Base 版本做起点模型没有任何预置聊天习惯蒸馏数据是什么样它就学成什么样适合想完整塑造一套新输出风格的情况。缺点是训练初期会更吃力需要更多数据才能学会像对话模型一样说话。我的建议是如果你蒸馏的目标主要是保留教师模型的推理能力并输出自然回答那么 Instruct 版本 LoRA 是最稳的路线如果希望打造一个严格模仿教师输出格式的专用模型那从 Base 开始训练会走得更彻底。这篇文章后面示例使用 Instruct 版本因为大多数人落地时还是需要它具备通用对话能力。2.3 训练框架选型对比目前开源社区里蒸馏训练通常绕不开这几个框架框架适合场景配置难度显存优化备注LLaMA-Factory快速验证、LoRA/QLoRA 微调低好数据格式简单入门首选Axolotl需要精细控制训练过程中高好配置文件多适合深度定制unsloth单卡有限显存下追求速度低极好训练速度比标准实现快不少如果是第一次做蒸馏我建议直接用 LLaMA-Factory。它把数据格式、LoRA、DPO 这些环节都封装得很友好出问题了排查起来也容易。等你想对损失函数做改动、或者需要自定义数据采样逻辑时再考虑迁移到 Axolotl。不必一上来就追求高自由度先把跑通一轮数据闭环才是重点。2.4 硬件规划先算清楚再动手27B 模型的硬件需求并不神秘关键是看你选择什么训练方式。以 Qwen3.5 27B 为例模型权重在 BF16 精度下大约需要 54GB 显存这还没算梯度和优化器状态。训练方式显存需求经验值推荐配置全参微调BF16需要 150GB 以上显存4 到 8 张 A100 80GLoRA / QLoRA单张 48G 可跑量化后单张 24G 也能尝试1 到 2 张 A100 或 A6000 48G实际项目里大多数人会选 LoRA 或 QLoRA。不是全参微调效果不好而是性价比太低。27B 这个规模用 LoRA 训练如果秩设置得当效果已经能接近全参微调而显存和训练时间成本却大幅降低。我在单卡 A100 80G 上用 QLoRA 训练过类似的 27B 蒸馏任务序列长度控制在 8K 左右过拟合控制和模型收敛都比较理想。3. 实操拆解三阶段完成推理能力迁移整个蒸馏流程我最推荐切成三个阶段数据采集与清洗、SFT 微调、偏好对齐优化。每个阶段的目标不同踩坑点也不同。下面按时间顺序完整过一遍。3.1 数据采集教师模型思维轨迹的获取这一步的产出决定了后面模型效果的天花板。数据质量差后面再怎么调参都没用。采集前先准备一个高质量提问池覆盖数学计算、逻辑推理、代码生成、多步任务规划、复杂指令理解这几类场景。不要只堆难题也要混合一些日常问题因为学生模型在蒸馏后仍然要承担通用对话职责。我习惯按 6:2:2 的比例分配六成高难度推理题两成常规业务题两成通用对话题。调用教师模型时需要把推理过程也保留下来。例如在 prompt 中明确要求模型先分析再作答输出格式类似{ user_query: 如果一个矩形的长是12宽比长少5求它的面积。, teacher_reasoning: 宽等于12减5等于7面积等于长乘宽12乘7等于84。, teacher_answer: 84 }如果教师模型支持显式的思考字段那更好直接摘取思考字段作为teacher_reasoning。需要注意不同来源的输出格式有可能不同统一转成上面的 JSON 结构会方便后续清洗和转换训练集。清洗阶段至少要处理四类问题空回复和纯错题直接删掉最好人工抽检一批确认教师没有系统性犯错的题目批量采样带来的重复内容用文本去重算法筛掉相似度超过 0.85 的只保留一条超出学生模型最大上下文长度的样本做截断而不是直接丢弃保留推理过程和最终答案明显带有不当内容、偏见倾向的输出坚决过滤掉。3.2 SFT 阶段让 Qwen3.5 27B 先学会教师的输出模式SFT 阶段的核心是让学生模型在给定问题上逐渐生成与教师模型一致的推理过程和答案。普通微调用的是标准交叉熵损失也就是拿教师生成的文本作为标准答案去训练学生。工程上最简单的做法就是把它当作指令微调任务来处理数据格式用对话模板拼好即可。下面是我实际用 LLaMA-Factory 跑 SFT 时的一份配置示例model_name_or_path: Qwen/Qwen3.5-27B-Instruct stage: sft dataset: distill_claude_data finetuning_type: lora lora_rank: 128 lora_alpha: 256 learning_rate: 5e-6 num_train_epochs: 3.0 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 max_seq_length: 8192 warmup_ratio: 0.1 save_steps: 500几个学习率的经验值LoRA 下5e-6到1e-5是我试过最稳的区间学习率只要超过2e-5loss 就很容易震荡。训练轮次上3 个 epoch 左右通常就能看到明显的输出风格变化再多则可能导致过拟合。max_seq_length设置要兼顾显存和训练效率27B 模型上 8K 是一个性价比合理的配置。另外还有一个进阶选择不只用标准文本做监督而是用教师的 logits 做软标签对齐也就是让学生的输出概率分布去逼近教师的概率分布。这种做法的理论上限更高但实现复杂度也更高而且对显存和训练框架都有额外要求。我建议第一次做蒸馏先走硬标签 SFT把链路跑通后再考虑是否引入软标签优化。3.3 偏好对齐用 DPO 把好坏标准也搬过来仅仅让学生模型学会生成像教师的输出还不够它还需要学会区分好的推理和差的推理。第二阶段的 DPO直接偏好优化就是干这个的。构造偏好数据的方式很直接同一个问题让教师模型生成 3 到 5 条候选回答然后借助另一个评估模型或者人工标注把回答排序。选一条最好的作为正样本再选一条明显较差的作为负样本形成偏好对。训练时DPO 会让模型以更高概率生成正样本远离负样本。偏好对数据不需要太多几千条高质量的就能明显见效。如果 SFT 阶段已经做得很好DPO 主要是锦上添花但这一步在很多场景里决定了模型是偶尔惊艳还是稳定可靠。训练配置上DPO 的学习率通常比 SFT 更低我常用2e-6到5e-6。4. 评测与调优如何确认模型真的继承了推理能力训练结束后最怕的就是感觉模型变聪明了但又说不出到底哪些能力提升了。没有评测体系就谈不上迭代。这个阶段的重点是建立一个能真实反映推理能力迁移的评测框架。4.1 建立评测集不是所有准确率都值得看评测集应该和训练集严格分割。我的习惯是覆盖四类任务数学推理包括代数、几何、应用题重点看多步推导是否正确逻辑推理如条件推理、谬误识别、排序问题代码生成考察代码逻辑正确性和健壮性复杂指令跟随多步指令、约束条件较多的任务。上面这些任务不能只盯着最终答案是否正确还要看推理步骤是否完整。我见过不少蒸馏模型能给出正确结果但推理过程跳步严重这种模型在真实场景里遇到没见过的同类题目时翻车率会很高。4.2 对比基准三模型同台评测时至少要把三个模型放在同一组测试问题上对比原版 Qwen3.5 27B Instruct、教师模型 Claude 4.6 Opus、蒸馏后的模型。没有教师模型和基座模型的对照你根本分不清效果提升来自蒸馏还是原本就有。每次评测记录下面的信息会非常直观题目类型测试题目数原版 27B 正确率蒸馏后正确率教师模型正确率数学推理200实测记录实测记录实测记录逻辑推理200实测记录实测记录实测记录代码生成150实测记录实测记录实测记录复杂指令150实测记录实测记录实测记录这里千万不能只看数字。一定要下载一批失败样本逐条看推理过程找出蒸馏模型的薄弱点。比如数学正确率上去了但代码生成格式总是错那就说明训练数据里代码类样本的格式一致性不够。4.3 失败样本驱动的二次迭代评测不是终点而是下一轮数据采集的起点。我通常在首轮蒸馏后挑出 10 到 20 个典型的失败样本把它们和教师的回答放在一起对比分析模型是在哪一步开始走偏的。这之后只针对失败方向补充教师采样重新清洗、混合增量数据再做一轮小规模 SFT。这种失败样本驱动的循环比无脑堆数据有效得多。5. 部署落地从训练卡到生产环境模型训练好了最终要跑在业务系统里。低门槛部署是这条路线的重要卖点但落地时需要注意的细节并不少。5.1 量化方案AWQ、GPTQ、GGUF 怎么选Qwen3.5 27B 在 BF16 下大约占用 54GB 显存量产后能显著降低部署成本。三种主流方案各有侧重量化方式显存占用推理速度适用环境AWQ低4bit 约 16GB快服务端 GPU 部署GPTQ低4bit 约 16GB快服务端 GPU 部署GGUF可调从 2bit 到 8bit受 CPU/GPU 带宽影响本地、边缘设备服务端生产环境我优先推荐 AWQ 或 GPTQ 量化的 4bit 版本。AWQ 在推理任务里通常比 GPTQ 更稳尤其是在低比特下对敏感层的保护更好。GGUF 则更适合要夹在 Ollama、Llama.cpp 这类工具里跑的场景。量化后一定要重新评测一遍。因为量化是压缩必然带来一定程度的精度损失。我遇到过 4bit 量化后正确率掉 2 到 3 个百分点的模型也遇到过某些模型几乎不掉点的案例这取决于原来模型的权重分布和量化校准集跟业务分布的匹配程度。5.2 vLLM 服务化一行命令变成 API部署推理我用的是 vLLM它能高效利用显存、支持高并发是为生产环境准备的方案。启动方式类似vllm serve Qwen/Qwen3.5-27B-AWQ \ --quantization awq \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.95启动后它会提供一个 OpenAI 兼容的接口业务代码改动很小就能切换过去。要注意max-model-len不只是显存够不够的问题它还直接影响并发时的吞吐。开太长会导致并发能力下降我的经验是如果业务大多数请求在 2K token 以内服务端开到 8K 就足够留出余量不要贪大。5.3 上线前的容量评估上线前至少要做两层预估单卡能支撑的并发上限以及峰值流量下是否会出现显存溢出。先用工具压测几百个并发请求看 P95 延迟和 token 吞吐是否满足指标。如果单卡不够优先调lerror fate——这里写错了应该用调整 vLLM 的调度参数和 batch 策略不要轻易上多卡因为多卡通信开销在小模型上带来的性能收益有时候并不高。27B 模型单卡 80G 在 4bit 量化下实际上已经很能扛压了。6. 常见问题速查与实用技巧蒸馏过程中许多问题很有共性我把最常见的几种整理成一个速查表方便对照排查。现象可能原因解决办法训练 loss 正常但推理结果奇怪数据格式拼接错误检查训练集是否严格对齐了对话模板格式模型总在输出里带思考中之类的标签训练时推理标记没有做统一处理重做数据清洗统一转换推理标记通用对话能力明显下降SFT 数据太偏灾难性遗忘混入通用 SFT 数据或降低蒸馏数据占比测试时准确率不稳定采样参数不合适推理时温度降到 0.2 到 0.3配合 top_p数学题会做但代码题格式一塌糊涂代码类训练样本不足或格式不一致补充结构化代码推理样本统一代码输出格式DPO 阶段 loss 震荡偏好对质量太低重新筛选偏好对保证正负样本差异明显显存不足序列太长或 batch 太大降低 max_seq_length增加梯度累积步数除了速查表还有三个我在实操中印象特别深的经验。第一个经验是数据格式的统一比想象中更重要。教师模型可能在不同的批次里输出略有差异的思考格式如果直接拼接进训练集学生模型会学着精神分裂。我每次都会写一段脚本把所有样本的思考和答案统一成固定结构顺便检查特殊 token 是否被意外截断。第二个经验是蒸馏模型上线后不能完全撒手不管。它毕竟是从教师模型迁移来的能力遇到训练分布之外的题型表现可能不如原版通用模型。我的做法是保留一个降级策略蒸馏模型拒答或置信度过低时再转调教师模型兜底。这样既控制成本又保证用户体验。第三个经验和经验相关评估模型是否真正继承了推理能力不仅要看准确率还要看解释的可信度。我经常挑出同一个问题让蒸馏模型和教师模型分别解释自己的推理过程让人来做盲评。很多时候准确率差不多但教师的推理步骤更干净、更少冗余这种差距在规模放大后会非常明显。最后再分享一个我印象很深的踩坑经历。第一次做蒸馏时我把训练集全部设为高难度竞赛题结果模型竞赛题确实变强了但日常对话能力全面退化连帮我把会议纪要按照要点整理都开始输出冗长的逻辑推导。后来在第二轮训练中我用 8:2 的比例掺入了大量通用指令数据才把这个问题解决。后来我做任何蒸馏项目都会把这个比例视为不能打破的底线。这套方法整体跑下来最核心的收获是蒸馏不是一次性的复制粘贴而是一套采集、训练、评测、再采集的闭环。每轮迭代不一定都要重新采集全部数据但一定要从评测结果里找到真正的短板。只要有耐心把数据清洗和评测体系做好Qwen3.5 27B 完全可以在推理能力逼近教师模型的同时把部署门槛降到团队能够接受的程度。