1. 推理优化与部署的整体思路拆解1.1 为什么推理优化是模型落地的第一道坎训练一个大模型动辄需要几十上百张加速卡跑上几周但真正决定一个模型能不能用起来的往往是推理阶段的表现。我见过太多团队在实验室里把模型调到满意的精度结果一上线就傻眼单次请求延迟两秒起步并发一上来显存直接爆掉单张卡的吞吐量连业务最低要求都撑不住。推理优化要解决的就是这个落差——让模型在有限的硬件资源下跑得动、跑得快、跑得省。从工程视角看推理优化主要围绕三个维度展开延迟单次请求响应时间、吞吐单位时间能处理的请求数、成本每千次推理的硬件开销。这三个指标往往互相拉扯降低延迟可能牺牲吞吐提升吞吐可能增加显存占用。所以优化的第一步不是急着上技术手段而是先搞清楚业务场景到底更看重哪个指标。在线对话类应用对延迟极其敏感首 token 时间超过一秒用户就会觉得卡而离线批处理任务更在意吞吐延迟高一点无所谓关键是单位时间能跑完多少数据。1.2 量化、蒸馏、选型三者的关系与取舍很多人把量化、蒸馏、模型选型当成三个独立的技术点实际上它们是一条链上的不同环节。模型选型决定了你的起点——选一个多大的模型、什么架构、什么许可证蒸馏决定了你能不能把大模型的能力迁移到小模型上从而在推理阶段获得天然的速度优势量化则是在选定模型之后进一步压缩权重和激活值的精度换取显存和带宽的节省。这三者的优先级怎么排我的经验是先选型再蒸馏最后量化。选型错了后面怎么优化都是事倍功半。比如你选了一个 70B 参数的稠密模型却想部署在单张消费级显卡上那基本是给自己找不痛快。蒸馏适合你有充足算力做教师模型推理、且业务允许一定精度损失的场景。量化则是普适性最强的优化手段几乎任何模型都能从中受益但要注意量化后的精度回退是否在可接受范围内。1.3 部署形态的选择逻辑部署形态没有绝对的好坏只有适不适合。我一般按这几个维度来判断并发量、延迟要求、硬件预算、运维能力。并发量低、延迟要求不苛刻的场景直接用 Ollama 这类工具本地跑就行一条命令拉起省心省力。并发量中等、需要 OpenAI 兼容接口的vLLM 是当前最主流的选择PagedAttention 对显存的利用率确实高。如果追求极致的吞吐和更细粒度的调度TensorRT-LLM 或 SGLang 值得考虑但上手成本也更高。提示不要一上来就追求最复杂的方案。我见过不少团队为了“技术先进性”直接上 TensorRT-LLM结果编译引擎就花了两天最后发现业务并发根本用不上那么高的吞吐。先从简单方案跑通遇到瓶颈再换这才是务实的做法。2. 量化技术的核心细节与实操要点2.1 量化的基本原理从 FP16 到 INT8 再到 INT4量化的本质是用更少的比特数来表示权重和激活值。FP16 每个参数占 2 字节INT8 占 1 字节INT4 只占 0.5 字节。一个 7B 参数的模型FP16 需要约 14GB 显存INT8 降到 7GBINT4 只要 3.5GB 左右。这个压缩比对于显存受限的部署场景来说是救命稻草。但量化不是免费的午餐。把 FP16 的连续值映射到 INT8 的 256 个离散值必然引入误差。量化的核心挑战就是如何在压缩的同时最小化精度损失。常见的做法是逐通道量化per-channel而不是逐张量量化per-tensor因为不同通道的数值分布差异很大统一用一个缩放因子会损失太多信息。更精细的还有逐组量化per-group把通道分成若干组每组独立计算缩放因子和零点。2.2 GPTQ、AWQ、GGUF 三种主流量化方案对比目前社区里最常用的三种量化方案各有侧重我整理了一个对比表方案量化粒度是否需要校准数据推理框架支持典型精度损失适用场景GPTQ逐层/逐组需要vLLM、ExLlama、Transformers较低GPU 部署追求精度AWQ逐通道需要vLLM、TensorRT-LLM低GPU 部署激活感知GGUF多种混合不需要llama.cpp、Ollama中等CPU/混合部署易用性优先GPTQ 的思路是逐层做量化用校准数据来最小化量化误差。它的优势是精度保持得不错而且 vLLM 对 GPTQ 的支持很成熟。AWQ 的核心洞察是不是所有通道都同等重要激活值大的通道应该保留更高精度。实测下来 AWQ 在 INT4 下的精度通常比 GPTQ 略好一点尤其是在小模型上。GGUF 则是 llama.cpp 生态的格式支持从 Q2 到 Q8 多种量化级别最大的好处是不需要校准数据转换方便而且 CPU 推理效率高。2.3 实操用 AutoGPTQ 量化一个模型下面是我实际用过的量化流程以 Qwen 系列模型为例。首先安装依赖pip install auto-gptq transformers optimum然后准备校准数据。校准数据的质量直接影响量化效果我一般从业务相关的语料里抽 128 到 256 条每条长度控制在 512 token 左右。不要随便拿一堆无关的文本凑数校准数据和推理时的输入分布越接近量化后的表现越好。from transformers import AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig model_id Qwen/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_id) quantize_config BaseQuantizeConfig( bits4, group_size128, desc_actFalse, ) model AutoGPTQForCausalLM.from_pretrained(model_id, quantize_config) calibration_texts [...] # 你的校准数据 calibration_dataset [ tokenizer(text, return_tensorspt).input_ids for text in calibration_texts ] model.quantize(calibration_dataset) model.save_quantized(./qwen2.5-7b-gptq-int4) tokenizer.save_pretrained(./qwen2.5-7b-gptq-int4)几个关键参数说明group_size128是精度和压缩率的平衡点设成 32 精度更好但压缩率下降设成 256 压缩率更高但精度损失明显。desc_actFalse表示不做激活值重排序开启后精度略好但推理速度会慢一些。实测下来7B 模型 INT4 量化后显存占用从 14GB 降到 4GB 左右在通用对话任务上的精度损失大概在 1 到 2 个百分点。2.4 量化避坑指南第一个坑校准数据泄露。如果你用测试集的数据做校准量化后的模型在测试集上表现会虚高实际部署就露馅。校准数据必须和评估数据严格分开。第二个坑忽视激活值量化。很多人只量化权重激活值还是 FP16这样显存节省有限。权重和激活都量化到 INT8 才能获得最大的收益但激活值量化对精度的影响更大需要更仔细地调参。第三个坑盲目追求 INT4。INT4 不是万能的。对于 7B 以下的小模型INT4 量化后精度损失可能超过 5 个百分点这时候 INT8 反而是更稳妥的选择。我的经验是13B 以上的模型可以放心上 INT47B 左右的模型建议 INT8 起步再小就考虑蒸馏而不是量化了。注意量化后的模型一定要做完整的评估不能只看 loss。用业务相关的评测集跑一遍对比量化前后的输出差异特别关注那些需要精确推理的任务比如数学计算和代码生成这些任务对量化误差最敏感。3. 知识蒸馏的落地方法与代码实现3.1 蒸馏的核心逻辑软标签为什么比硬标签好知识蒸馏的基本框架是用一个大的教师模型来指导小的学生模型训练。关键不在于让学生模型去拟合真实的硬标签比如分类任务里的 one-hot 标签而是去拟合教师模型输出的软标签概率分布。软标签里包含了类别之间的相对关系信息比如教师模型认为“这张图是猫的概率 0.7是狗的概率 0.2”这个 0.2 的信息就是硬标签给不了的。用生活化的类比硬标签就像只告诉你正确答案是 A软标签则告诉你 A 最对、B 次之、C 再次之。学生模型从软标签里能学到更多关于问题结构的信息泛化能力自然更好。温度参数 T 就是用来控制软标签平滑程度的T 越大概率分布越平滑类别间的相对关系越明显。3.2 蒸馏损失函数的设计与调参蒸馏的损失函数通常是两部分加权求和Loss α * KL(学生软输出 || 教师软输出) (1-α) * CE(学生硬输出, 真实标签)α 控制蒸馏损失和任务损失的权重。我的经验是 α 取 0.7 到 0.9 之间比较合适太低了蒸馏效果不明显太高了学生模型可能学不到任务本身的特征。温度 T 一般取 2 到 5T 太小软标签接近硬标签T 太大分布过于平滑信息反而模糊。还有一个容易被忽视的点教师模型和学生模型的容量差距不能太大。用 70B 的教师去蒸馏 0.5B 的学生学生根本学不过来效果可能还不如直接训练。一般来说教师模型参数量控制在学生模型的 5 到 10 倍比较合理。3.3 实操用 Transformers 实现一个蒸馏训练循环下面是一个可运行的蒸馏训练代码框架以文本分类任务为例import torch import torch.nn as nn import torch.nn.functional as F from transformers import AutoModelForSequenceClassification, AutoTokenizer teacher AutoModelForSequenceClassification.from_pretrained(teacher-model) student AutoModelForSequenceClassification.from_pretrained(student-model) tokenizer AutoTokenizer.from_pretrained(teacher-model) teacher.eval() for param in teacher.parameters(): param.requires_grad False optimizer torch.optim.AdamW(student.parameters(), lr2e-5) alpha 0.8 temperature 3.0 def distillation_loss(student_logits, teacher_logits, labels): soft_student F.log_softmax(student_logits / temperature, dim-1) soft_teacher F.softmax(teacher_logits / temperature, dim-1) kl_loss F.kl_div(soft_student, soft_teacher, reductionbatchmean) kl_loss kl_loss * (temperature ** 2) ce_loss F.cross_entropy(student_logits, labels) return alpha * kl_loss (1 - alpha) * ce_loss for batch in dataloader: inputs tokenizer(batch[text], return_tensorspt, paddingTrue, truncationTrue) labels batch[label] with torch.no_grad(): teacher_logits teacher(**inputs).logits student_logits student(**inputs).logits loss distillation_loss(student_logits, teacher_logits, labels) optimizer.zero_grad() loss.backward() optimizer.step()注意kl_loss乘以了temperature ** 2这是为了补偿温度对梯度尺度的影响让不同温度下的损失量级可比。这个细节很多教程会漏掉但不加的话温度调大后损失会变得很小训练信号被削弱。3.4 蒸馏的常见误区与经验误区一只蒸馏最后一层。实际上中间层的特征也可以蒸馏让学生模型的隐藏状态去逼近教师模型的隐藏状态这叫中间层蒸馏通常能带来额外的精度提升。但实现起来更复杂需要对齐层数和维度。误区二蒸馏数据越多越好。蒸馏的效果更依赖于数据的质量和多样性而不是数量。我试过用 10 万条通用数据蒸馏效果不如用 2 万条业务相关数据。教师模型在业务数据上的软标签更有指导价值。误区三蒸馏完就完事了。蒸馏后的学生模型通常还需要在业务数据上做一轮微调把蒸馏学到的通用能力适配到具体任务上。这一步叫“蒸馏后微调”能再涨一两个点。4. 主流模型选型与部署方案实战4.1 模型选型的决策框架选模型不是选最大的而是选最合适的。我一般按这个顺序来筛许可证→架构→参数量→社区生态。许可证决定了你能不能商用这个必须第一步确认。架构决定了推理效率MoE 架构虽然总参数量大但激活参数量小推理成本反而可能比同级别的稠密模型低。参数量要和你的硬件匹配单卡 24GB 显存的话INT4 量化后 13B 左右的模型是比较舒服的选择。社区生态决定了你遇到问题能不能快速找到解决方案主流模型在 vLLM、Ollama 上的支持都比较好。4.2 本地部署工具选型Ollama vs vLLM vs LM Studio这三个工具我都在不同场景下用过各有各的适用面Ollama适合快速验证和个人使用。安装一条命令拉模型一条命令跑起来一条命令。它底层用的是 llama.cppGGUF 格式的模型直接就能跑。缺点是并发能力弱不适合生产环境的高并发场景。vLLM适合生产部署。PagedAttention 对 KV Cache 的管理非常高效吞吐量比朴素实现高好几倍。支持 OpenAI 兼容接口接入现有系统很方便。缺点是对模型格式有要求需要 HuggingFace 格式或 GPTQ/AWQ 量化格式。LM Studio适合桌面端使用有图形界面对不熟悉命令行的用户很友好。底层也是 llama.cpp性能和 Ollama 差不多但交互体验更好。4.3 实操vLLM 部署量化模型的完整流程以部署一个 AWQ 量化的 Qwen 模型为例pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000几个关键参数--gpu-memory-utilization 0.9表示用 90% 的显存来放模型和 KV Cache留 10% 给系统。这个值设太高容易 OOM设太低浪费显存。--max-model-len控制最大上下文长度设得越大 KV Cache 占用越多需要根据实际业务需求来定。启动后用 OpenAI 兼容接口测试from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct-AWQ, messages[{role: user, content: 用一句话解释什么是量化}], temperature0.7, max_tokens128, ) print(response.choices[0].message.content)4.4 部署后的性能调优与监控部署完不是终点调优才刚开始。我一般关注这几个指标首 token 延迟、每 token 生成时间、并发吞吐量、显存占用。vLLM 自带 Prometheus 指标接口可以接入 Grafana 做可视化监控。如果首 token 延迟高通常是 prefill 阶段计算量大可以考虑开启 chunked prefill把长 prompt 分块处理避免阻塞其他请求。如果每 token 生成时间慢可能是 KV Cache 命中率低检查一下是不是 batch size 设得太小。如果显存占用高可以降低--max-model-len或者开启--enable-prefix-caching来复用系统提示词的 KV Cache。提示生产环境一定要做压测。用 locust 或 wrk 模拟真实并发观察在不同并发数下的延迟和吞吐变化。我见过不少配置在低并发下表现很好一上到 50 并发就雪崩的情况。压测能帮你找到系统的拐点提前做好容量规划。5. 常见问题排查与避坑经验实录5.1 量化模型加载失败或输出乱码这是最常见的问题通常有几个原因。第一量化格式和推理框架不匹配。GPTQ 模型用 vLLM 加载时要加--quantization gptqAWQ 要加--quantization awq忘了加或者加错了就会加载失败或者输出乱码。第二group_size 不匹配。量化时用的 group_size 和推理时框架默认的不一致会导致权重解析错误。第三模型文件不完整。下载过程中断导致部分文件损坏重新下载即可。排查步骤先确认模型目录下的 config.json 里 quantization_config 字段是否正确再确认推理框架的版本是否支持该量化格式最后用sha256sum校验模型文件完整性。5.2 蒸馏训练不收敛或效果差蒸馏训练比普通训练更难调常见问题有损失震荡通常是学习率太大降到 1e-5 试试学生模型输出退化可能是 α 设得太高学生只顾着模仿教师忘了任务本身把 α 降到 0.5 左右教师模型输出过于自信温度 T 设大一点让软标签更平滑。还有一个隐蔽的问题教师模型和学生模型的 tokenizer 不一致。如果教师用的是 SentencePiece学生用的是 BPEtoken 的切分方式不同软标签的对齐就会出问题。蒸馏前务必确认两个模型的 tokenizer 是同一个。5.3 部署后并发上不去并发上不去通常卡在几个地方。KV Cache 不够vLLM 的--gpu-memory-utilization设低了或者--max-model-len设太大了导致能同时处理的请求数受限。batch size 太小vLLM 默认是连续批处理但如果请求间隔太长batch 一直凑不满GPU 利用率就上不去。CPU 预处理瓶颈tokenization 和 prompt 拼接在 CPU 上做如果 CPU 性能不够GPU 会等 CPU 喂数据。我的调优顺序是先看 GPU 利用率如果低于 70% 说明 GPU 没吃饱检查 batch size 和 KV Cache 配置如果 GPU 利用率高但吞吐还是低看是不是模型本身计算量太大考虑换更小的模型或者更激进的量化。5.4 常见问题速查表问题现象可能原因排查方法解决方案模型加载 OOM显存不足nvidia-smi 看显存占用降低 max-model-len 或用量化模型输出乱码量化格式不匹配检查 config.json加正确的 quantization 参数首 token 延迟高prefill 计算量大看 prefill 耗时指标开启 chunked prefill吞吐上不去batch 太小看 GPU 利用率增大并发或调整调度参数蒸馏不收敛学习率或 α 不当看 loss 曲线降学习率、调 α 和 T量化后精度暴跌校准数据不匹配对比量化前后评测换业务相关校准数据5.5 几个我踩过的坑坑一用错了量化版本。有一次我拿了一个 Q4_K_M 的 GGUF 模型想用 vLLM 加载折腾了半天才发现 vLLM 根本不支持 GGUF 格式。GGUF 是 llama.cpp 生态的vLLM 要用 GPTQ 或 AWQ。选量化方案前先确认推理框架支持哪些格式能省很多时间。坑二忽视了 tokenizer 的 max_length。部署时没设 max-model-len默认值可能很小长 prompt 直接被截断模型回答得莫名其妙。上线前一定要确认 max-model-len 覆盖了业务的最长输入。坑三蒸馏时教师模型没冻结。第一次写蒸馏代码时忘了加param.requires_grad False结果教师模型也被更新了训练完全跑偏。这个错误很隐蔽因为 loss 看起来在下降但教师模型已经面目全非了。坑四量化校准数据用了训练集。量化后在验证集上表现很好上线后效果差一截。后来发现校准数据里混了验证集的样本导致量化参数过拟合到验证集分布。校准数据必须从训练集里抽和验证集严格隔离。推理优化这件事说到底是在精度、速度、成本之间找平衡点。没有银弹只有针对具体场景的最优解。我个人的习惯是先把基线跑通量化、蒸馏、换模型这些手段一个个加上去每加一个就测一次看收益和代价是否划算。有时候最简单的方案——选一个合适大小的模型加 INT8 量化——反而比一堆花哨技术叠加起来效果更好。
大模型推理优化实战：量化、蒸馏与部署选型指南
1. 推理优化与部署的整体思路拆解1.1 为什么推理优化是模型落地的第一道坎训练一个大模型动辄需要几十上百张加速卡跑上几周但真正决定一个模型能不能用起来的往往是推理阶段的表现。我见过太多团队在实验室里把模型调到满意的精度结果一上线就傻眼单次请求延迟两秒起步并发一上来显存直接爆掉单张卡的吞吐量连业务最低要求都撑不住。推理优化要解决的就是这个落差——让模型在有限的硬件资源下跑得动、跑得快、跑得省。从工程视角看推理优化主要围绕三个维度展开延迟单次请求响应时间、吞吐单位时间能处理的请求数、成本每千次推理的硬件开销。这三个指标往往互相拉扯降低延迟可能牺牲吞吐提升吞吐可能增加显存占用。所以优化的第一步不是急着上技术手段而是先搞清楚业务场景到底更看重哪个指标。在线对话类应用对延迟极其敏感首 token 时间超过一秒用户就会觉得卡而离线批处理任务更在意吞吐延迟高一点无所谓关键是单位时间能跑完多少数据。1.2 量化、蒸馏、选型三者的关系与取舍很多人把量化、蒸馏、模型选型当成三个独立的技术点实际上它们是一条链上的不同环节。模型选型决定了你的起点——选一个多大的模型、什么架构、什么许可证蒸馏决定了你能不能把大模型的能力迁移到小模型上从而在推理阶段获得天然的速度优势量化则是在选定模型之后进一步压缩权重和激活值的精度换取显存和带宽的节省。这三者的优先级怎么排我的经验是先选型再蒸馏最后量化。选型错了后面怎么优化都是事倍功半。比如你选了一个 70B 参数的稠密模型却想部署在单张消费级显卡上那基本是给自己找不痛快。蒸馏适合你有充足算力做教师模型推理、且业务允许一定精度损失的场景。量化则是普适性最强的优化手段几乎任何模型都能从中受益但要注意量化后的精度回退是否在可接受范围内。1.3 部署形态的选择逻辑部署形态没有绝对的好坏只有适不适合。我一般按这几个维度来判断并发量、延迟要求、硬件预算、运维能力。并发量低、延迟要求不苛刻的场景直接用 Ollama 这类工具本地跑就行一条命令拉起省心省力。并发量中等、需要 OpenAI 兼容接口的vLLM 是当前最主流的选择PagedAttention 对显存的利用率确实高。如果追求极致的吞吐和更细粒度的调度TensorRT-LLM 或 SGLang 值得考虑但上手成本也更高。提示不要一上来就追求最复杂的方案。我见过不少团队为了“技术先进性”直接上 TensorRT-LLM结果编译引擎就花了两天最后发现业务并发根本用不上那么高的吞吐。先从简单方案跑通遇到瓶颈再换这才是务实的做法。2. 量化技术的核心细节与实操要点2.1 量化的基本原理从 FP16 到 INT8 再到 INT4量化的本质是用更少的比特数来表示权重和激活值。FP16 每个参数占 2 字节INT8 占 1 字节INT4 只占 0.5 字节。一个 7B 参数的模型FP16 需要约 14GB 显存INT8 降到 7GBINT4 只要 3.5GB 左右。这个压缩比对于显存受限的部署场景来说是救命稻草。但量化不是免费的午餐。把 FP16 的连续值映射到 INT8 的 256 个离散值必然引入误差。量化的核心挑战就是如何在压缩的同时最小化精度损失。常见的做法是逐通道量化per-channel而不是逐张量量化per-tensor因为不同通道的数值分布差异很大统一用一个缩放因子会损失太多信息。更精细的还有逐组量化per-group把通道分成若干组每组独立计算缩放因子和零点。2.2 GPTQ、AWQ、GGUF 三种主流量化方案对比目前社区里最常用的三种量化方案各有侧重我整理了一个对比表方案量化粒度是否需要校准数据推理框架支持典型精度损失适用场景GPTQ逐层/逐组需要vLLM、ExLlama、Transformers较低GPU 部署追求精度AWQ逐通道需要vLLM、TensorRT-LLM低GPU 部署激活感知GGUF多种混合不需要llama.cpp、Ollama中等CPU/混合部署易用性优先GPTQ 的思路是逐层做量化用校准数据来最小化量化误差。它的优势是精度保持得不错而且 vLLM 对 GPTQ 的支持很成熟。AWQ 的核心洞察是不是所有通道都同等重要激活值大的通道应该保留更高精度。实测下来 AWQ 在 INT4 下的精度通常比 GPTQ 略好一点尤其是在小模型上。GGUF 则是 llama.cpp 生态的格式支持从 Q2 到 Q8 多种量化级别最大的好处是不需要校准数据转换方便而且 CPU 推理效率高。2.3 实操用 AutoGPTQ 量化一个模型下面是我实际用过的量化流程以 Qwen 系列模型为例。首先安装依赖pip install auto-gptq transformers optimum然后准备校准数据。校准数据的质量直接影响量化效果我一般从业务相关的语料里抽 128 到 256 条每条长度控制在 512 token 左右。不要随便拿一堆无关的文本凑数校准数据和推理时的输入分布越接近量化后的表现越好。from transformers import AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig model_id Qwen/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_id) quantize_config BaseQuantizeConfig( bits4, group_size128, desc_actFalse, ) model AutoGPTQForCausalLM.from_pretrained(model_id, quantize_config) calibration_texts [...] # 你的校准数据 calibration_dataset [ tokenizer(text, return_tensorspt).input_ids for text in calibration_texts ] model.quantize(calibration_dataset) model.save_quantized(./qwen2.5-7b-gptq-int4) tokenizer.save_pretrained(./qwen2.5-7b-gptq-int4)几个关键参数说明group_size128是精度和压缩率的平衡点设成 32 精度更好但压缩率下降设成 256 压缩率更高但精度损失明显。desc_actFalse表示不做激活值重排序开启后精度略好但推理速度会慢一些。实测下来7B 模型 INT4 量化后显存占用从 14GB 降到 4GB 左右在通用对话任务上的精度损失大概在 1 到 2 个百分点。2.4 量化避坑指南第一个坑校准数据泄露。如果你用测试集的数据做校准量化后的模型在测试集上表现会虚高实际部署就露馅。校准数据必须和评估数据严格分开。第二个坑忽视激活值量化。很多人只量化权重激活值还是 FP16这样显存节省有限。权重和激活都量化到 INT8 才能获得最大的收益但激活值量化对精度的影响更大需要更仔细地调参。第三个坑盲目追求 INT4。INT4 不是万能的。对于 7B 以下的小模型INT4 量化后精度损失可能超过 5 个百分点这时候 INT8 反而是更稳妥的选择。我的经验是13B 以上的模型可以放心上 INT47B 左右的模型建议 INT8 起步再小就考虑蒸馏而不是量化了。注意量化后的模型一定要做完整的评估不能只看 loss。用业务相关的评测集跑一遍对比量化前后的输出差异特别关注那些需要精确推理的任务比如数学计算和代码生成这些任务对量化误差最敏感。3. 知识蒸馏的落地方法与代码实现3.1 蒸馏的核心逻辑软标签为什么比硬标签好知识蒸馏的基本框架是用一个大的教师模型来指导小的学生模型训练。关键不在于让学生模型去拟合真实的硬标签比如分类任务里的 one-hot 标签而是去拟合教师模型输出的软标签概率分布。软标签里包含了类别之间的相对关系信息比如教师模型认为“这张图是猫的概率 0.7是狗的概率 0.2”这个 0.2 的信息就是硬标签给不了的。用生活化的类比硬标签就像只告诉你正确答案是 A软标签则告诉你 A 最对、B 次之、C 再次之。学生模型从软标签里能学到更多关于问题结构的信息泛化能力自然更好。温度参数 T 就是用来控制软标签平滑程度的T 越大概率分布越平滑类别间的相对关系越明显。3.2 蒸馏损失函数的设计与调参蒸馏的损失函数通常是两部分加权求和Loss α * KL(学生软输出 || 教师软输出) (1-α) * CE(学生硬输出, 真实标签)α 控制蒸馏损失和任务损失的权重。我的经验是 α 取 0.7 到 0.9 之间比较合适太低了蒸馏效果不明显太高了学生模型可能学不到任务本身的特征。温度 T 一般取 2 到 5T 太小软标签接近硬标签T 太大分布过于平滑信息反而模糊。还有一个容易被忽视的点教师模型和学生模型的容量差距不能太大。用 70B 的教师去蒸馏 0.5B 的学生学生根本学不过来效果可能还不如直接训练。一般来说教师模型参数量控制在学生模型的 5 到 10 倍比较合理。3.3 实操用 Transformers 实现一个蒸馏训练循环下面是一个可运行的蒸馏训练代码框架以文本分类任务为例import torch import torch.nn as nn import torch.nn.functional as F from transformers import AutoModelForSequenceClassification, AutoTokenizer teacher AutoModelForSequenceClassification.from_pretrained(teacher-model) student AutoModelForSequenceClassification.from_pretrained(student-model) tokenizer AutoTokenizer.from_pretrained(teacher-model) teacher.eval() for param in teacher.parameters(): param.requires_grad False optimizer torch.optim.AdamW(student.parameters(), lr2e-5) alpha 0.8 temperature 3.0 def distillation_loss(student_logits, teacher_logits, labels): soft_student F.log_softmax(student_logits / temperature, dim-1) soft_teacher F.softmax(teacher_logits / temperature, dim-1) kl_loss F.kl_div(soft_student, soft_teacher, reductionbatchmean) kl_loss kl_loss * (temperature ** 2) ce_loss F.cross_entropy(student_logits, labels) return alpha * kl_loss (1 - alpha) * ce_loss for batch in dataloader: inputs tokenizer(batch[text], return_tensorspt, paddingTrue, truncationTrue) labels batch[label] with torch.no_grad(): teacher_logits teacher(**inputs).logits student_logits student(**inputs).logits loss distillation_loss(student_logits, teacher_logits, labels) optimizer.zero_grad() loss.backward() optimizer.step()注意kl_loss乘以了temperature ** 2这是为了补偿温度对梯度尺度的影响让不同温度下的损失量级可比。这个细节很多教程会漏掉但不加的话温度调大后损失会变得很小训练信号被削弱。3.4 蒸馏的常见误区与经验误区一只蒸馏最后一层。实际上中间层的特征也可以蒸馏让学生模型的隐藏状态去逼近教师模型的隐藏状态这叫中间层蒸馏通常能带来额外的精度提升。但实现起来更复杂需要对齐层数和维度。误区二蒸馏数据越多越好。蒸馏的效果更依赖于数据的质量和多样性而不是数量。我试过用 10 万条通用数据蒸馏效果不如用 2 万条业务相关数据。教师模型在业务数据上的软标签更有指导价值。误区三蒸馏完就完事了。蒸馏后的学生模型通常还需要在业务数据上做一轮微调把蒸馏学到的通用能力适配到具体任务上。这一步叫“蒸馏后微调”能再涨一两个点。4. 主流模型选型与部署方案实战4.1 模型选型的决策框架选模型不是选最大的而是选最合适的。我一般按这个顺序来筛许可证→架构→参数量→社区生态。许可证决定了你能不能商用这个必须第一步确认。架构决定了推理效率MoE 架构虽然总参数量大但激活参数量小推理成本反而可能比同级别的稠密模型低。参数量要和你的硬件匹配单卡 24GB 显存的话INT4 量化后 13B 左右的模型是比较舒服的选择。社区生态决定了你遇到问题能不能快速找到解决方案主流模型在 vLLM、Ollama 上的支持都比较好。4.2 本地部署工具选型Ollama vs vLLM vs LM Studio这三个工具我都在不同场景下用过各有各的适用面Ollama适合快速验证和个人使用。安装一条命令拉模型一条命令跑起来一条命令。它底层用的是 llama.cppGGUF 格式的模型直接就能跑。缺点是并发能力弱不适合生产环境的高并发场景。vLLM适合生产部署。PagedAttention 对 KV Cache 的管理非常高效吞吐量比朴素实现高好几倍。支持 OpenAI 兼容接口接入现有系统很方便。缺点是对模型格式有要求需要 HuggingFace 格式或 GPTQ/AWQ 量化格式。LM Studio适合桌面端使用有图形界面对不熟悉命令行的用户很友好。底层也是 llama.cpp性能和 Ollama 差不多但交互体验更好。4.3 实操vLLM 部署量化模型的完整流程以部署一个 AWQ 量化的 Qwen 模型为例pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000几个关键参数--gpu-memory-utilization 0.9表示用 90% 的显存来放模型和 KV Cache留 10% 给系统。这个值设太高容易 OOM设太低浪费显存。--max-model-len控制最大上下文长度设得越大 KV Cache 占用越多需要根据实际业务需求来定。启动后用 OpenAI 兼容接口测试from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct-AWQ, messages[{role: user, content: 用一句话解释什么是量化}], temperature0.7, max_tokens128, ) print(response.choices[0].message.content)4.4 部署后的性能调优与监控部署完不是终点调优才刚开始。我一般关注这几个指标首 token 延迟、每 token 生成时间、并发吞吐量、显存占用。vLLM 自带 Prometheus 指标接口可以接入 Grafana 做可视化监控。如果首 token 延迟高通常是 prefill 阶段计算量大可以考虑开启 chunked prefill把长 prompt 分块处理避免阻塞其他请求。如果每 token 生成时间慢可能是 KV Cache 命中率低检查一下是不是 batch size 设得太小。如果显存占用高可以降低--max-model-len或者开启--enable-prefix-caching来复用系统提示词的 KV Cache。提示生产环境一定要做压测。用 locust 或 wrk 模拟真实并发观察在不同并发数下的延迟和吞吐变化。我见过不少配置在低并发下表现很好一上到 50 并发就雪崩的情况。压测能帮你找到系统的拐点提前做好容量规划。5. 常见问题排查与避坑经验实录5.1 量化模型加载失败或输出乱码这是最常见的问题通常有几个原因。第一量化格式和推理框架不匹配。GPTQ 模型用 vLLM 加载时要加--quantization gptqAWQ 要加--quantization awq忘了加或者加错了就会加载失败或者输出乱码。第二group_size 不匹配。量化时用的 group_size 和推理时框架默认的不一致会导致权重解析错误。第三模型文件不完整。下载过程中断导致部分文件损坏重新下载即可。排查步骤先确认模型目录下的 config.json 里 quantization_config 字段是否正确再确认推理框架的版本是否支持该量化格式最后用sha256sum校验模型文件完整性。5.2 蒸馏训练不收敛或效果差蒸馏训练比普通训练更难调常见问题有损失震荡通常是学习率太大降到 1e-5 试试学生模型输出退化可能是 α 设得太高学生只顾着模仿教师忘了任务本身把 α 降到 0.5 左右教师模型输出过于自信温度 T 设大一点让软标签更平滑。还有一个隐蔽的问题教师模型和学生模型的 tokenizer 不一致。如果教师用的是 SentencePiece学生用的是 BPEtoken 的切分方式不同软标签的对齐就会出问题。蒸馏前务必确认两个模型的 tokenizer 是同一个。5.3 部署后并发上不去并发上不去通常卡在几个地方。KV Cache 不够vLLM 的--gpu-memory-utilization设低了或者--max-model-len设太大了导致能同时处理的请求数受限。batch size 太小vLLM 默认是连续批处理但如果请求间隔太长batch 一直凑不满GPU 利用率就上不去。CPU 预处理瓶颈tokenization 和 prompt 拼接在 CPU 上做如果 CPU 性能不够GPU 会等 CPU 喂数据。我的调优顺序是先看 GPU 利用率如果低于 70% 说明 GPU 没吃饱检查 batch size 和 KV Cache 配置如果 GPU 利用率高但吞吐还是低看是不是模型本身计算量太大考虑换更小的模型或者更激进的量化。5.4 常见问题速查表问题现象可能原因排查方法解决方案模型加载 OOM显存不足nvidia-smi 看显存占用降低 max-model-len 或用量化模型输出乱码量化格式不匹配检查 config.json加正确的 quantization 参数首 token 延迟高prefill 计算量大看 prefill 耗时指标开启 chunked prefill吞吐上不去batch 太小看 GPU 利用率增大并发或调整调度参数蒸馏不收敛学习率或 α 不当看 loss 曲线降学习率、调 α 和 T量化后精度暴跌校准数据不匹配对比量化前后评测换业务相关校准数据5.5 几个我踩过的坑坑一用错了量化版本。有一次我拿了一个 Q4_K_M 的 GGUF 模型想用 vLLM 加载折腾了半天才发现 vLLM 根本不支持 GGUF 格式。GGUF 是 llama.cpp 生态的vLLM 要用 GPTQ 或 AWQ。选量化方案前先确认推理框架支持哪些格式能省很多时间。坑二忽视了 tokenizer 的 max_length。部署时没设 max-model-len默认值可能很小长 prompt 直接被截断模型回答得莫名其妙。上线前一定要确认 max-model-len 覆盖了业务的最长输入。坑三蒸馏时教师模型没冻结。第一次写蒸馏代码时忘了加param.requires_grad False结果教师模型也被更新了训练完全跑偏。这个错误很隐蔽因为 loss 看起来在下降但教师模型已经面目全非了。坑四量化校准数据用了训练集。量化后在验证集上表现很好上线后效果差一截。后来发现校准数据里混了验证集的样本导致量化参数过拟合到验证集分布。校准数据必须从训练集里抽和验证集严格隔离。推理优化这件事说到底是在精度、速度、成本之间找平衡点。没有银弹只有针对具体场景的最优解。我个人的习惯是先把基线跑通量化、蒸馏、换模型这些手段一个个加上去每加一个就测一次看收益和代价是否划算。有时候最简单的方案——选一个合适大小的模型加 INT8 量化——反而比一堆花哨技术叠加起来效果更好。