最近“张一鸣为什么反对蒸馏”这个话题在技术圈传得很广各种截图和二手解读满天飞。但先把结论放在前面翻遍公开采访、演讲和字节系公开技术分享目前并没有一段明确记录能证明张一鸣本人对“模型蒸馏”发表过完整、系统的反对意见。这个话题大概率是技术圈情绪的一种投射——大家真正想问的是另一件事为什么大模型圈越来越警惕蒸馏为什么有人把蒸馏和“作弊”“偷技术”画等号蒸馏模型到底是什么意思原理是什么它到底动了谁的蛋糕这篇文章不打算继续把“一句话观点”放大成新闻。我们把视角拉回到工程本身用一篇能落地的技术拆解讲清楚模型蒸馏的定义、原理、训练方法、争议来源以及一套你可以在本地显卡上跑通的蒸馏实验流程。不管你是做大模型应用、垂直模型微调还是只想知道“DeepSeek 被质疑蒸馏是怎么回事”这篇文章都能给你一个比热搜更完整的答案。1. 核心能力速览能力项说明技术类型模型压缩 / 知识迁移技术核心思路用大模型Teacher的预测结果指导小模型Student训练典型收益更小参数量、更低推理成本、更低延迟、可部署到端侧常见用途任务特化、垂直领域模型、端侧部署、模型压缩、API 蒸馏主流实现KL 散度损失、软标签、温度参数、特征对齐硬件需求训练端需要 GPU消费级显卡可跑小规模蒸馏是否支持 CPU 训练可以但速度极慢仅适合最小示例验证是否支持批量任务支持训练和推理都可以脚本化批量执行是否支持 API 部署蒸馏产物可导出为标准模型用 FastAPI / vLLM 等提供服务主要风险数据授权、服务条款合规、评估失真、片面蒸馏导致能力退化适合读者算法工程师、大模型应用开发者、模型压缩方向学生这里要特别说明一点模型蒸馏本身是 2015 年前后深度学习时代就成熟的技术它不是某一家的“黑科技”。真正让它在 2025 年变成热词的是大模型商业竞争中被频繁提及的“API 蒸馏”和“违规数据使用”问题。2. 适用场景与使用边界2.1 蒸馏适合解决什么问题蒸馏并不是万能药它的核心价值是“把一个昂贵能力压缩成廉价能力”。具体来说有三个典型场景。第一个是任务特化。基座大模型什么都会一点但部署成本高响应慢。你可以用一个 70B 的大模型当一个“老师”把它的数学能力、代码能力或特定格式能力蒸馏到一个 7B 甚至 1.5B 的小模型里。最终的小模型只擅长这一件事但这件事做得又快又省。第二个是端侧部署。手机、嵌入式设备、浏览器插件跑不动几十 B 的大模型但可以跑几百 M 或几个 G 的小模型。通过蒸馏可以把大模型的“经验”压缩进小模型让它在本地方完成分类、摘要、结构化抽取等任务。第三个是降低推理成本。API 调用按 token 计费内部业务如果每天有上亿次请求把一部分高频简单请求切到蒸馏后的小模型上成本下降是数量级的。2.2 蒸馏不适用什么场景如果你需要的是“通才”能力蒸馏帮不了你。小模型的天花板由结构决定你不可能让 1B 模型真正达到 70B 模型的综合推理水平。蒸馏只是逼近不是超越。另外如果原始大模型本身能力不够强蒸馏的收益也有限。劣质老师的错误会原样传给徒弟甚至被放大。2.3 版权、隐私与合规边界这是当前关于蒸馏的最大争议点。从知识产权角度看如果你蒸馏的是开源权重模型且遵循其 License那么这是合法的技术路径。如果你使用的是闭源 API 的输出来蒸馏——特别是绕过服务条款、批量抓取响应、用于训练竞品模型——这就可能构成违约甚至不正当竞争。从数据隐私角度看蒸馏过程中如果使用含个人信息、医疗数据、金融数据的样本输出结果可能被小模型记住。发布前要评估记忆泄露风险。从商业道德角度看任何蒸馏实验都应该保留完整的训练数据来源记录、授权证明和评估报告。不要因为“技术无国界”就忽视“数据有边界”。3. 模型蒸馏原理拆解3.1 蒸馏模型是什么意思“蒸馏模型”不是一个具体模型的名字而是一种训练范式的产物。它指把一个大而强的模型Teacher老师模型的知识转移到一个更小更快的模型Student学生模型中去。最直观的理解是老师教学生但教的不是标准答案而是答题思路。标准答案是真实标签label答题思路是老师对每个候选答案的偏好程度。后者信息量更大。3.2 核心原理软标签与温度参数传统分类训练中我们用交叉熵让模型输出逼近 one-hot 标签。例如图片分类真实标签是“猫”那模型的输出越接近[0, 1, 0, 0]越好。但在蒸馏中老师模型的前向输出不是 one-hot而是一个概率分布。例如输入一张猫图老师模型可能输出{ 猫: 0.75, 狗: 0.18, 狐狸: 0.05, 其他: 0.02 }这个分布包含了一个重要信息猫和狗在视觉特征上是接近的猫和“其他”差别大。这种“软标签”比 one-hot 标签的信息量高得多。为了让老师模型输出的分布更“软化”蒸馏引入了温度参数 T。原始 softmax 是P_i exp(z_i / T) / sum_j exp(z_j / T)当 T 1 时就是普通 softmax。T 越大分布越平缓类别间的关系越清晰。T 太小分布就会退化成 one-hot丢失知识。学生模型的训练损失由两部分组成Loss alpha * KL(Teacher_logits_T, Student_logits_T) (1 - alpha) * CrossEntropy(Student_logits, Hard_Label)第一个 KL 散度项让学生模型的概率分布逼近老师模型的概率分布这是知识迁移的核心。第二个交叉熵项保证学生模型不会偏离真实标签。3.3 蒸馏与量化、剪枝的区别很多文章把模型压缩技术混在一起讲这里做一个区分。量化是把模型权重从 FP16 压到 INT8 或 INT4本质上是数值精度的压缩模型结构和参数数量不变。剪枝是把模型中不重要的权重或神经元删掉属于结构化稀疏化。蒸馏则是重新训练一个新的小模型来模仿大模型。三者不冲突实际工程中经常组合使用——先蒸馏出一个小模型再进行量化和剪枝进一步压缩。3.4 黑盒蒸馏与白盒蒸馏按老师模型的可访问程度蒸馏分为两种。黑盒蒸馏指只能拿到模型的 API 输出拿不到中间层特征和梯度。你只能通过大量请求输入收集输出结果再把这些输出当成训练数据来训练小模型。这种方式的优点是简单任何 API 都能做缺点是风险高容易违反服务条款而且拿不到中间层信息蒸馏效率低。行业中争论最激烈的“API 蒸馏”就是这种。白盒蒸馏指使用开源大模型权重直接复现模型前向过程可以提取中间层特征做特征对齐也能直接计算教师对学生的梯度传递。质量更高但要获得开源权重并受开源许可证约束。4. 围绕“蒸馏争议”的真实背景4.1 成本差距引发的技术路线之争蒸馏之所以成为行业焦点本质上是大模型训练成本不对等导致的。头部闭源模型的训练成本极高动辄数千万美元。而蒸馏一个下游专用模型成本可能只有前者的千分之一。如果大家遵守规则那么小团队通过 API 调用大模型、过滤高质量输出、训练自己的小模型用低成本博取高能力这在商业竞争上确实构成一种“搭便车”。问题在于这种行为如果不经过授权就相当于用别人的研发投入为自己的模型做训练数据。这也是许多关于大模型公司“用 API 输出训练竞品”的质疑的根源所在。4.2 开源模型与闭源模型的异步竞争另一个被反复讨论的案例是 DeepSeek 被质疑使用 OpenAI 的输出进行蒸馏训练。公开报道中OpenAI 曾表示发现 DeepSeek 使用了其 API 输出来训练自家模型这可能违反服务条款。DeepSeek 方面是否有正式回应目前没有一致的公开信息所以这里不展开站队。但从技术角度理解这种质疑存在可行性基础只要训练数据包含 API 输出且这些输出被当作文本语料训练模型就能学到类似的行为模式。并不需要“复制权重”只需要大规模调用 API 并清洗响应。注意这是对行业事件的客观描述不构成对任何公司的法律或技术定论。对普通开发者更有意义的启示是如果你在产品中也计划使用蒸馏一定要检查老师模型的条款并用可记录的方式保留数据授权证据。4.3 评估失真蒸馏模型的“虚高分”问题蒸馏还有一个经常被忽略的工程陷阱评估结果失真。假设你用一个 70B 的老师蒸馏了一个 7B 的学生然后拿它去跑基准测试。如果测试集的题目就是蒸馏时用过的题目学生模型的分数会被高估。更隐蔽的情况是老师模型在判断时会遵循某种偏好学生模型把这个偏好也学过去了。最终造成小模型在公开测试集上表现很好但面对真实业务数据泛化能力明显不足。所以任何蒸馏实验都必须设计一个“老师没见过、学生也没见过”的独立测试集。5. 本地蒸馏实战环境准备与最小训练示例这部分我们不用理论空谈直接跑一个最小可运行的蒸馏训练流程。以下示例基于 HuggingFace Transformers PyTorch适合在消费级显卡上验证。5.1 环境准备建议使用 Python 3.10 或 3.11虚拟环境隔离依赖。python -m venv distil_env source distil_env/bin/activate # Windows 下用 distil_env\Scripts\activate pip install torch transformers datasets accelerate nvidia-ml-py模型选择上老师可以选一个小规模开源模型如Qwen2.5-1.5B-Instruct学生选更小的Qwen2.5-0.5B-Instruct。这样即便只有 8GB 显存也能跑通。5.2 蒸馏训练脚本下面的脚本展示了一个典型的白盒蒸馏流程。核心操作用老师的 logits 来监督学生的训练同时保留硬标签损失。import torch import torch.nn.functional as F from transformers import AutoModelForCausalLM, AutoTokenizer device cuda if torch.cuda.is_available() else cpu teacher_name Qwen/Qwen2.5-1.5B-Instruct student_name Qwen/Qwen2.5-0.5B-Instruct teacher AutoModelForCausalLM.from_pretrained( teacher_name, torch_dtypetorch.float16 ).to(device).eval() student AutoModelForCausalLM.from_pretrained( student_name, torch_dtypetorch.float16 ).to(device).train() tokenizer AutoTokenizer.from_pretrained(student_name) # 示例训练数据实际使用时应换成领域数据 train_texts [ 请用一句话概括今日天气今天晴气温26度。, 编写一个Python函数返回列表中的偶数。, ] # 温度参数控制软标签平滑程度 temperature 4.0 alpha 0.7 optimizer torch.optim.AdamW(student.parameters(), lr5e-5) for step, text in enumerate(train_texts): inputs tokenizer(text, return_tensorspt, truncationTrue, max_length128).to(device) with torch.no_grad(): teacher_outputs teacher(**inputs) teacher_logits teacher_outputs.logits / temperature student_outputs student(**inputs) student_logits student_outputs.logits / temperature # KL散度让学生逼近老师的软标签分布 kl_loss F.kl_div( F.log_softmax(student_logits, dim-1), F.log_softmax(teacher_logits, dim-1).exp(), reductionbatchmean, ) # 硬标签交叉熵损失 ce_loss F.cross_entropy( student_outputs.logits.view(-1, student_outputs.logits.size(-1)), inputs[input_ids].view(-1), ignore_indextokenizer.pad_token_id, ) loss alpha * kl_loss (1 - alpha) * ce_loss loss.backward() optimizer.step() optimizer.zero_grad() print(fstep {step}, loss {loss.item():.4f})这个脚本是关键的可执行骨架。真实项目中你需要在数据集上跑多个 epoch加入验证集并用gradient_accumulation_steps控制显存。5.3 推理验证训练完成后直接对比老师与学生模型在相同输入下的输出质量。student.eval() with torch.no_grad(): inputs tokenizer(给一个健康的午餐建议, return_tensorspt).to(device) outputs student.generate( **inputs, max_new_tokens64, do_sampleFalse, ) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))判断标准不是“生成文本是否完美”而是三项输出格式是否正确语义是否符合逻辑字符是否出现重复或崩溃。6. 蒸馏效果验证与评估方法蒸馏训练完只是第一步效果评估才是决定能否上线的关键。建议按下面四个维度来验证。6.1 基础指标指标作用Loss 下降曲线观察训练是否收敛KL 散度学生分布和老师分布的差距回答准确率 / BLEU / ROUGE下游任务指标响应延迟衡量部署收益Loss 曲线如果剧烈震荡说明学习率过高或数据噪声大。如果 KL 散度降不下去说明学生容量不足需要换更大的学生结构。6.2 对抗性评测把老师没见过的 100~500 条真实业务问题作为测试集分别让老师和学生回答再由人工或评判模型打分。重点是看学生的回答是否“继承”了老师的能力而不是死记硬背训练样本。6.3 一致性检查同一 prompt 连续生成 5 次观察学生模型是否稳定。蒸馏模型常见问题之一是输出不稳定温度较高时内容跳变。一次好、一次差的结果不能算有效。6.4 批量评估脚本当测试数据有几千条时可以写一个批处理脚本输出每条样本的响应并落盘。import json from tqdm import tqdm test_samples [ {id: 1, prompt: 解释什么是分布式锁}, {id: 2, prompt: 写一段Python爬虫框架代码}, ] results [] for sample in tqdm(test_samples): inputs tokenizer(sample[prompt], return_tensorspt).to(device) with torch.no_grad(): out student.generate( **inputs, max_new_tokens128, do_sampleTrue, top_p0.9, ) text tokenizer.decode(out[0], skip_special_tokensTrue) results.append({id: sample[id], prompt: sample[prompt], output: text}) with open(eval_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)提示词、采样参数、最大长度要固定否则对比不公平。7. 蒸馏后模型的接口 API 与批量任务部署蒸馏模型的目标通常是低成本上线。这一节给出一个轻量 API 服务示例以及一个批量推理示例。两者可以组合成一个完整的服务系统。7.1 FastAPI 部署蒸馏模型用 FastAPI 把蒸馏后的学生模型包装成 HTTP 接口。如果有并发需求建议把模型加载放到全局变量中并配置--workers。pip install fastapi uvicornfrom fastapi import FastAPI, Request from transformers import AutoModelForCausalLM, AutoTokenizer import torch app FastAPI() device cuda if torch.cuda.is_available() else cpu student_name ./student_model_final model AutoModelForCausalLM.from_pretrained(student_name, torch_dtypetorch.float16).to(device).eval() tokenizer AutoTokenizer.from_pretrained(student_name) app.post(/generate) async def generate(req: Request): body await req.json() prompt body[prompt] max_new_tokens body.get(max_new_tokens, 128) temperature body.get(temperature, 0.7) inputs tokenizer(prompt, return_tensorspt).to(device) with torch.no_grad(): outputs model.generate( **inputs, max_new_tokensmax_new_tokens, temperaturetemperature, do_sampleTrue, ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) return {output: result}启动命令uvicorn app:app --host 0.0.0.0 --port 8000服务启动后使用 curl 测试curl -X POST http://127.0.0.1:8000/generate \ -H Content-Type: application/json \ -d {prompt: 解释什么是MVP, max_new_tokens: 64}7.2 批量推理任务设计在真实业务中批量任务通常以文件或消息队列作为输入。简单场景下按目录读取 JSON 文件并批量推理即可。# 输入目录结构 ./batch_input/ task_001.json task_002.json task_003.jsonimport glob import json import os from tqdm import tqdm os.makedirs(./batch_output, exist_okTrue) for file_path in tqdm(glob.glob(./batch_input/*.json)): with open(file_path, r, encodingutf-8) as f: task json.load(f) prompt task[prompt] inputs tokenizer(prompt, return_tensorspt).to(device) with torch.no_grad(): out model.generate( **inputs, max_new_tokenstask.get(max_new_tokens, 128), do_sampleFalse, ) result_text tokenizer.decode(out[0], skip_special_tokensTrue) task[output] result_text task[status] success out_path os.path.join(./batch_output, os.path.basename(file_path)) with open(out_path, w, encodingutf-8) as f: json.dump(task, f, ensure_asciiFalse, indent2)批量任务要加两个能力失败重试和断点续跑。如果某个文件推理失败不要中断整个任务把错误记录到failed.log程序结束后统一处理。如果任务数量大建议一次跑 50~100 条落盘后再继续避免进程崩溃丢失全部结果。8. 资源占用与性能观察8.1 显存占用如何观察蒸馏训练时老师模型不需要梯度但会占显存。最直观的观察方式是用nvidia-smi监控。watch -n 1 nvidia-smi如果老师模型是 7B 且加载为 FP16显存占用大约在 14GB 以上。学生模型如果是 0.5B 或 1.5B训练的额外显存占用约为 2~6GB。这只是一个通用估算实际占用与框架、batch size、序列长度强相关请以本机测试为准。8.2 降低显存占用的方法第一个方法是把老师模型冻结为 eval 模式并用torch.no_grad()包裹前向计算。第二个方法是使用gradient_checkpointing但会增加前向计算时间。第三个方法是老师模型用 FP16 或 INT8 加载学生模型用全精度训练这样训练稳定性更好。第四个方法是减少 batch size用梯度累积来弥补。8.3 性能观察要点训练阶段重点看“每分钟处理多少样本”推理阶段重点看“每秒生成多少 token”。蒸馏后的模型如果比老师模型推理速度快 3~5 倍说明压缩有效。如果速度提升不明显需要检查模型结构是否过度冗余或是否引入了额外操作。9. 蒸馏训练常见问题与排查方法问题现象可能原因排查方式解决方案训练 loss 不下降学习率过大或数据质量差打印 loss 曲线抽样检查训练数据降低学习率清洗数据增加有效样本显存不足OOMteacher 和 student 同时加载查看 nvidia-smi确认显存占用减小 batch sizeteacher 用 FP16 或半精度加载必要时冻结 teacher蒸馏后模型回答模板化alpha 过大软标签权重过高对比硬标签损失和 KL 损失比重降低 alpha增加硬标签损失权重或调整温度参数评测分数高但真实场景差测试集与训练集重叠或数据分布单一检查评测集是否与蒸馏数据重叠重新构建独立测试集增加多样性和对抗样本推理输出不稳定采样温度过高或模型容量不足固定温度多次生成对比降低 temperature关闭 do_sample或使用更大的学生模型加载模型时报 device mismatch模型权重复存在 CPU/GPU 上检查model.device和inputs.device统一使用.to(device)传输输入和模型到同一设备API 部署后并发性能差未配置模型缓存或线程池过小查看 GPU 利用率与延迟使用模型预加载开启多 worker或接入 vLLM 等推理框架10. 最佳实践与合规建议10.1 工程实践建议第一次做蒸馏项目先从 1000 条样本的小实验开始。目的是跑通环境、验证流程、记录显存占用和时间消耗而不是一上来追求效果。第二步再扩展数据量加入验证集建立评估闭环。训练过程要保留完整实验记录teacher 模型版本、student 模型版本、数据版本、温度参数、alpha 参数、训练步数、loss 曲线。这些信息在复盘时极其重要。模型文件、训练脚本、测试集、评测结果分成独立目录管理project/ data/ train/ eval/ models/ teacher/ student/ scripts/ train.py eval.py deploy.py results/ logs/ predictions/10.2 合规与安全边界在当前大模型环境下蒸馏最核心的风险不是技术难度而是授权边界。使用任何开源模型做 teacher必须确认其 License 是否允许微调、蒸馏和商业化。使用商业 API 输出训练模型要对照服务条款确认是否存在明确禁止行为。涉及人脸、声音、版权文本、个人信息的数据即使只是用于蒸馏训练也必须先完成授权评估。蒸馏模型可能保留训练数据中的某些记忆上线前要做敏感信息探测。发布蒸馏模型时建议在模型卡中声明基座模型来源、训练数据构成、授权状态、已知局限性。这不仅是合规要求也能提升模型的可信度。10.3 技术伦理真正值得讨论的“反对蒸馏”不是反对技术本身而是反对“未经授权的能力复制”。蒸馏本身是一套公开、可解释、有长期学术积累的机器学习方法把它妖魔化没有意义。关键是使用场景是否合法、数据是否授权、评估是否真实。如果你的产品打算长期使用蒸馏模型不要只把它当作一次性任务。建议建立持续的监控系统定期用新的真实业务数据评估模型表现当数据分布漂移时重新蒸馏。11. 总结与下一步回到开头的问题“张一鸣为什么反对蒸馏”这个说法目前找不到可靠的直接出处更合理的解读是行业对“低成本复制能力”的警惕。比起追问某个人怎么想搞懂蒸馏模型是什么意思、原理是什么、怎么合法高效地使用蒸馏对普通开发者更有实际价值。如果你想继续深入建议按这个顺序推进先跑通本文的最小训练脚本记录显存和耗时再用 5000 条左右领域数据做一次完整蒸馏实验最后用独立测试集对比 teacher 和 student 的效果并部署成 API 服务。核心观察三个点学生模型的能力保留比例、推理速度提升倍数、评估集上的稳定性。蒸馏并不是大模型的发明但它在大模型时代重新变得重要。它让“昂贵能力”有了“廉价平替”也让“能力复制”的边界问题变得紧迫。技术本身值得研究边界问题值得警惕这两件事不矛盾。