1. 推理优化与部署的整体思路拆解1.1 为什么推理优化是模型落地的第一道门槛训练一个大模型动辄几十上百张卡跑几周但真正决定一个模型能不能用起来、用得起、用得稳的其实是推理阶段。我见过太多团队模型训得漂漂亮亮指标刷得飞起结果一上线就傻眼单次请求延迟两秒起步并发一上来显存直接爆一张A100跑一个7B模型只能扛住个位数的QPS。这不是模型不行是推理优化没做。推理优化要解决的核心矛盾就三个字快、省、稳。快是指延迟低、吞吐高省是指显存占用小、单位算力成本低稳是指长跑不崩、并发不抖。这三个目标彼此拉扯你量化到INT4确实省显存了但精度可能掉你上蒸馏确实快了但学生模型可能学不到老师的全部本事。所以推理优化从来不是单一技术的堆叠而是一套组合拳得根据你的业务场景、硬件条件、精度容忍度来动态权衡。这篇文章我想把量化、蒸馏这两条主流路线讲透再聊聊模型选型和部署落地的实操细节。适合谁看如果你正在做模型上线、做端侧部署、做私有化交付或者单纯想搞清楚为什么别人的模型跑得比你快那这篇内容应该能帮你省下不少试错时间。1.2 量化、蒸馏、模型选型三者的关系很多人把量化、蒸馏、模型选型当成三个独立的话题其实它们是一条链上的三个环节。模型选型决定你用什么底座是选Qwen还是选DeepSeek是选7B还是选72B这一步决定了你的上限和成本基线。蒸馏决定你能不能把大模型的能力迁移到小模型上让你在保持可接受精度的前提下把推理成本降一个数量级。量化决定你最终部署时用什么数值精度FP16、INT8还是INT4这一步直接影响显存占用和推理速度。我通常的建议是先选型定方向再蒸馏压规模最后量化抠细节。顺序反了会很难受比如你先量化了一个72B模型到INT4发现还是跑不动再想蒸馏就得多走一遍流程。反过来你先蒸馏出一个3B的学生模型再对它做INT8量化部署起来就轻松很多。注意蒸馏和量化不是互斥的可以叠加使用。一个蒸馏后的3B模型再做INT8量化显存占用可以压到2GB以内消费级显卡就能跑。1.3 不同场景下的优化策略选择场景不同优化策略完全不一样。我大致分三类来说。云端高并发服务这种场景下吞吐量是核心指标延迟可以稍微放宽。优先考虑量化到INT8配合vLLM这类支持PagedAttention的推理框架把batch size拉大把GPU利用率吃满。蒸馏在这里不是必须的因为云端通常有足够的算力用大模型直接量化部署反而精度更有保障。端侧或边缘设备部署比如RK3588、Jetson这类板子显存和算力都极其有限。这种场景下蒸馏是刚需你得先把模型压到1B到3B这个量级然后再做INT8甚至INT4量化。部署框架也得换ONNX Runtime或者TensorRT是更常见的选择vLLM在这种场景下反而太重了。私有化交付客户给你一台服务器可能是4090也可能是A100你得在有限硬件上跑出可接受的性能。这种场景最考验综合能力量化、蒸馏、框架选型都得考虑还得留出余量应对客户的并发波动。我的经验是私有化交付优先选7B左右的模型蒸馏到3B做备选量化到INT8做默认配置INT4做极限配置。2. 量化技术深度解析与实操要点2.1 量化的基本原理从FP16到INT8到底发生了什么量化的本质是把模型权重和激活值从高精度浮点数映射到低精度整数。FP16每个参数占2字节INT8占1字节INT4占0.5字节。一个7B模型FP16需要14GB显存INT8需要7GBINT4只需要3.5GB。这就是为什么量化能让大模型跑在消费级显卡上的根本原因。但量化不是简单的截断。浮点数的动态范围很大INT8只有256个离散值直接映射会丢失大量信息。所以量化通常分两步先统计权重的分布范围确定一个缩放因子scale和零点zero point然后把浮点数线性映射到整数区间。推理时再把整数反量化回浮点数参与计算。这里有个关键概念叫校准Calibration。因为激活值的分布是随输入变化的你没法提前知道每一层的激活范围。所以需要拿一批代表性数据跑一遍模型统计每层激活的最大值最小值确定量化参数。校准数据的质量和数量直接影响量化后的精度我一般建议至少准备500到1000条覆盖真实场景的样本。2.2 PTQ与QAT两种量化路线的取舍量化分两大流派训练后量化PTQ和量化感知训练QAT。PTQ就是拿训练好的模型直接量化不需要重新训练。优点是快几十分钟就能搞定缺点是精度损失可能比较大尤其是量化到INT4的时候。PTQ适合对精度要求不那么极致的场景比如对话生成、文本摘要这类任务掉一两个点用户基本感知不到。QAT是在训练过程中模拟量化误差让模型提前适应低精度计算。优点是精度保持得好INT4量化后精度损失可以控制在1个点以内缺点是需要重新训练成本高而且需要原始训练数据和训练流程。QAT适合对精度敏感的场景比如分类、检索、金融风控这类任务。我的建议是先试PTQ如果精度达标就用PTQ不达标再考虑QAT。大部分场景下PTQ的INT8量化精度损失都在可接受范围内只有INT4才需要认真考虑QAT。对比维度PTQQAT是否需要训练否是耗时分钟到小时级天级INT8精度损失通常小于1%小于0.5%INT4精度损失可能3%到5%通常小于1%适用场景通用对话、摘要分类、检索、风控数据需求少量校准数据完整训练数据2.3 实操用GPTQ和AWQ量化一个7B模型目前主流的PTQ量化方案有GPTQ、AWQ、GGUF几种。GPTQ出现最早生态最成熟AWQ在精度上通常略好于GPTQ尤其是INT4GGUF是llama.cpp用的格式适合CPU推理。我以AWQ为例走一遍量化流程。假设你有一个Qwen2.5-7B的模型想量化到INT4。第一步安装依赖pip install autoawq transformers datasets第二步准备校准数据。我一般从训练集里抽512条覆盖不同长度和不同任务类型from datasets import load_dataset dataset load_dataset(your_dataset, splittrain) calib_data dataset.select(range(512))第三步执行量化from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path Qwen/Qwen2.5-7B quant_path Qwen2.5-7B-AWQ model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM } model.quantize(tokenizer, quant_configquant_config, calib_datacalib_data) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)这里有几个参数值得说明。q_group_size是分组量化的组大小128是常用值越小精度越高但量化参数越多。w_bit是权重量化位数4就是INT4。version选GEMM适合GPU推理选GEMV适合CPU推理。量化完成后你可以用lm-eval-harness跑一遍评测对比量化前后的精度差异。我实测下来Qwen2.5-7B量化到INT4后在MMLU上掉大约2个点在C-Eval上掉大约1.5个点对话场景基本感知不到差异。注意量化后的模型必须用支持对应量化格式的推理框架加载。AWQ模型需要vLLM或AutoAWQ来加载直接用transformers加载会报错。2.4 量化避坑指南精度掉了怎么排查量化后精度掉得厉害是最常见的问题。我总结了几条排查思路。第一检查校准数据。校准数据如果和真实场景分布差异太大量化参数就会偏。比如你用英文数据校准一个中文模型激活分布完全对不上精度肯定崩。校准数据一定要覆盖真实场景的输入分布。第二检查量化配置。q_group_size设太大比如256或512精度会明显下降。我一般建议128起步如果精度还不够就降到64。w_bit从4降到8精度会大幅提升但显存占用翻倍得权衡。第三检查敏感层。有些层对量化特别敏感比如第一层和最后一层还有attention的某些投影层。AWQ和GPTQ都支持保留部分层为FP16你可以通过配置把敏感层排除在量化之外。代价是显存占用会增加但精度能救回来不少。第四对比激活量化。权重量化和激活量化是两回事。AWQ主要做权重量化激活还是FP16。如果你用的是SmoothQuant这类同时量化激活的方案精度损失会更大需要更仔细地调参。3. 蒸馏技术深度解析与实操要点3.1 蒸馏的核心思想学生怎么学到老师的本事蒸馏的概念不复杂一个大模型叫老师一个小模型叫学生让学生去模仿老师的输出分布。关键在于学生学的不是硬标签比如分类任务里的0和1而是老师的软标签比如老师输出的概率分布。软标签里包含了类间相似性信息比如老师告诉你这张图是猫的概率0.7、是狗的概率0.2、是兔子0.1学生就能学到猫和狗比较像、和兔子不太像这种知识。对大语言模型来说蒸馏通常分两种黑盒蒸馏和白盒蒸馏。黑盒蒸馏只能拿到老师的输出文本学生去模仿老师的生成结果白盒蒸馏能拿到老师的logits学生去拟合老师的概率分布。白盒蒸馏效果更好但需要能访问老师的内部状态。还有一种叫特征蒸馏让学生去拟合老师中间层的特征表示。这种在视觉模型里用得多大语言模型里也有用但实现起来更复杂。3.2 黑盒蒸馏与白盒蒸馏的实操差异黑盒蒸馏实现简单你只需要拿老师模型生成一批数据然后用这批数据去微调学生模型。比如你想蒸馏一个DeepSeek-R1到Qwen2.5-3B可以这样做第一步用老师模型生成训练数据from transformers import AutoModelForCausalLM, AutoTokenizer teacher_path deepseek-ai/DeepSeek-R1 teacher AutoModelForCausalLM.from_pretrained(teacher_path, device_mapauto) tokenizer AutoTokenizer.from_pretrained(teacher_path) prompts load_your_prompts() outputs [] for prompt in prompts: inputs tokenizer(prompt, return_tensorspt).to(teacher.device) with torch.no_grad(): generated teacher.generate(**inputs, max_new_tokens512) outputs.append(tokenizer.decode(generated[0], skip_special_tokensTrue)) save_to_json(outputs, distill_data.json)第二步用生成的数据微调学生模型python finetune.py \ --model_name Qwen/Qwen2.5-3B \ --dataset distill_data.json \ --epochs 3 \ --lr 2e-5 \ --batch_size 4黑盒蒸馏的优点是简单不需要老师的logits甚至可以用API调用的方式获取老师输出。缺点是学生只能学到老师的最终输出学不到老师的推理过程。对于推理类任务这个损失比较大。白盒蒸馏需要拿到老师的logits实现上复杂一些。核心是定义一个KL散度损失让学生输出的概率分布逼近老师import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, temperature2.0): student_probs F.log_softmax(student_logits / temperature, dim-1) teacher_probs F.softmax(teacher_logits / temperature, dim-1) return F.kl_div(student_probs, teacher_probs, reductionbatchmean) * (temperature ** 2)温度参数temperature控制软标签的平滑程度。温度越高概率分布越平滑学生能学到的类间关系越多。但温度太高也会引入噪声一般2到5之间比较合适。3.3 蒸馏实操从72B到7B的完整流程我拿一个实际项目举例把Qwen2.5-72B蒸馏到Qwen2.5-7B目标是保留72B在代码生成任务上80%的能力。第一步数据准备。我从代码数据集里抽了5万条指令-响应对覆盖Python、JavaScript、Go、SQL等语言。然后用72B模型对每条指令重新生成响应作为蒸馏数据。第二步数据过滤。72B生成的响应不一定都对我用单元测试和语法检查过滤掉明显错误的样本最终保留约4.2万条高质量数据。第三步训练配置。学生模型用Qwen2.5-7B学习率2e-5batch size 32训练3个epoch。损失函数用标准的交叉熵因为这是黑盒蒸馏拿不到老师的logits。第四步评测。在HumanEval上72B的pass1是85%蒸馏后的7B是68%保留了80%的能力。在MBPP上72B是78%7B是62%保留率约79%。这个结果基本达到预期。注意蒸馏数据里如果混入了老师的错误输出学生也会学到错误。所以数据过滤这一步不能省宁可少一点也要保证质量。3.4 蒸馏的常见误区与效果评估蒸馏有几个常见的坑我一个个说。误区一蒸馏就是让小模型变大模型。不是的。蒸馏的本质是知识迁移学生模型的能力上限受限于自身容量。你把72B蒸馏到0.5B再怎么蒸馏也达不到7B的水平。学生模型和老师模型的参数量差距最好控制在10倍以内超过这个比例蒸馏效果会急剧下降。误区二蒸馏数据越多越好。数据质量比数量重要。1万条高质量数据效果可能好过10万条低质量数据。我一般建议蒸馏数据在1万到5万条之间具体看任务复杂度。误区三蒸馏一次就完事。蒸馏是个迭代过程。第一轮蒸馏后评测学生模型的弱项针对弱项补充数据再蒸馏一轮。我通常至少做两轮效果比一轮有明显提升。误区四只看最终指标。蒸馏后的模型可能在整体指标上不错但在某些细分场景上崩了。比如代码生成整体pass1还行但特定语言的生成质量很差。所以评测要分场景、分维度做不能只看一个总分。常见误区正确做法学生老师参数量差距过大控制在10倍以内盲目堆数据量优先保证数据质量只蒸馏一轮至少两轮迭代只看整体指标分场景分维度评测忽略数据过滤严格过滤错误样本4. 主流模型选型与部署落地指南4.1 模型选型的核心维度不是越大越好选模型不是选最大的是选最合适的。我一般从五个维度来评估任务匹配度、参数量、推理成本、生态成熟度、许可协议。任务匹配度是第一位。你做代码生成就选代码能力强的模型你做中文对话就选中文语料充足的模型你做数学推理就选推理链能力强的模型。别拿一个通用模型硬套所有任务效果往往不如专用模型。参数量决定推理成本。7B模型在A100上FP16推理单卡能跑延迟可接受72B模型至少需要4卡成本高一个数量级。如果你的场景对精度要求不是极致7B到14B通常是性价比最高的区间。生态成熟度很重要。模型有没有官方量化版本、有没有vLLM支持、有没有社区微调版本这些直接影响你的落地效率。有些模型虽然指标好看但生态不完善你得自己写推理代码、自己做量化时间成本很高。许可协议容易被忽略。商用场景一定要看清楚模型许可有些模型禁止商用有些要求署名有些对用户量有限制。这个坑踩一次就够了。4.2 不同硬件条件下的模型部署方案硬件条件直接决定你能选什么模型、用什么部署方案。我分几种常见情况来说。单卡409024GB显存这是最常见的私有化部署配置。FP16下能跑7B模型INT8下能跑14BINT4下能跑32B。我的建议是7B模型做INT8量化留出显存给KV Cache和并发。部署框架选vLLM开启PagedAttentionbatch size设到16到32QPS能到20以上。单卡A10080GB显存FP16下能跑32BINT8下能跑72BINT4下能跑100B以上。这种配置下我建议直接上32B模型做INT8精度和速度都能兼顾。如果并发要求高可以降到14B把batch size拉大。多卡A100集群这种配置下可以考虑72B甚至更大的模型。用vLLM的张量并行4卡跑72B的INT8吞吐量很可观。但要注意卡间通信开销张量并行度不是越高越好一般4到8卡比较合适。边缘设备RK3588、Jetson Orin这种场景下模型必须压到1B到3B量化到INT8或INT4。部署框架用ONNX Runtime或TensorRTvLLM太重了跑不动。RK3588上跑YOLOv8做视觉任务比较常见大语言模型的话Qwen2.5-1.5B量化后能跑但延迟在秒级。硬件配置推荐模型规模量化精度部署框架预期QPS4090 24GB7BINT8vLLM20-30A100 80GB32BINT8vLLM15-254xA100 80GB72BINT8vLLM张量并行30-50RK35881.5BINT4ONNX Runtime1-3Jetson Orin3BINT8TensorRT3-84.3 部署框架选型vLLM、TensorRT、ONNX Runtime怎么选部署框架的选择核心看你的场景和硬件。vLLM是目前GPU上部署大语言模型最主流的框架。它的核心优势是PagedAttention把KV Cache分页管理显存利用率比朴素实现高好几倍。连续批处理Continuous Batching让吞吐量大幅提升。vLLM支持AWQ、GPTQ、FP8等多种量化格式生态很完善。缺点是只支持GPUCPU场景用不了。TensorRT是NVIDIA的推理优化框架能把模型编译成高度优化的引擎。在固定输入形状的场景下TensorRT的性能通常是最好的。但它对动态形状支持一般编译过程也比较耗时。适合输入长度相对固定的场景比如分类、检索。ONNX Runtime是跨平台的推理框架CPU、GPU、边缘设备都能跑。性能不如vLLM和TensorRT但胜在通用性好。边缘设备部署基本都用ONNX Runtime配合INT8量化能在有限算力下跑出可接受的性能。我的选型逻辑很简单GPU上跑大语言模型首选vLLM固定形状的视觉模型选TensorRT边缘设备或CPU场景选ONNX Runtime。4.4 部署实操vLLM加载量化模型的完整配置我以vLLM加载AWQ量化模型为例走一遍部署流程。第一步安装vLLMpip install vllm第二步启动服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-AWQ \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32 \ --port 8000几个关键参数说明。--quantization awq指定量化格式vLLM会自动识别AWQ模型。--max-model-len是最大上下文长度设太大显存占用高设太小长文本会截断。--gpu-memory-utilization控制显存利用率0.9表示用90%的显存留10%给系统。--max-num-seqs是最大并发序列数直接影响吞吐量。第三步压测。用locust或wrk做并发测试观察QPS和延迟wrk -t4 -c32 -d60s http://localhost:8000/v1/completions我实测下来Qwen2.5-7B-AWQ在4090上max-num-seqs设32时QPS能到25左右P99延迟在800ms以内。如果把max-num-seqs降到16QPS降到18但P99延迟降到500ms以内。这个权衡看你的业务需求是吞吐优先还是延迟优先。注意vLLM启动时会预分配显存如果显存不够会直接报错。启动前先用nvidia-smi确认显存余量gpu-memory-utilization不要设得太激进。4.5 部署后的监控与调优让服务稳定跑下去部署上线只是开始后续的监控和调优才是长期工作。我一般关注几个核心指标QPS、P99延迟、显存占用、GPU利用率、错误率。QPS和P99延迟反映服务性能显存占用和GPU利用率反映资源使用效率错误率反映服务稳定性。这几个指标要持续监控设置告警阈值。调优的方向无非几个如果GPU利用率低但QPS上不去说明batch size没吃满可以调大max-num-seqs如果P99延迟高但GPU利用率不高说明有排队可以加实例或调小batch size如果显存占用高但QPS低说明KV Cache占太多可以调小max-model-len或降低并发。我踩过的一个坑是max-model-len设了32768结果显存被KV Cache吃满并发上不去QPS只有个位数。后来降到8192QPS直接翻了3倍。所以参数不是越大越好得根据实际场景调。5. 常见问题与排查技巧实录5.1 量化后精度下降的排查清单量化后精度下降是最常见的问题我整理了一个排查清单按优先级排序。排查项检查方法解决方向校准数据分布对比校准数据和真实数据换用真实场景数据校准量化组大小检查q_group_size配置从128降到64量化位数检查w_bit配置从4升到8敏感层逐层对比量化前后输出保留敏感层为FP16激活量化检查是否量化了激活关闭激活量化推理框架确认框架支持该量化格式换用匹配的框架我遇到过一次精度崩得厉害的情况排查了半天发现是校准数据用了英文而实际场景是中文。换中文数据重新校准后精度就回来了。所以校准数据这一步千万别偷懒。5.2 蒸馏效果不达预期的调整思路蒸馏效果不好通常有几个原因。学生模型容量不够学不到老师的能力蒸馏数据质量差学生学了错误的东西训练不充分学生还没收敛损失函数设计不合理学生学偏了。我的调整顺序是先检查数据质量再检查训练配置最后考虑换学生模型。数据质量是第一位我一般会人工抽检100条蒸馏数据看看老师的输出是不是合理。如果老师输出本身就有问题学生肯定学不好。训练配置方面学习率是关键。学习率太大学生学不稳学习率太小学生学得慢。我一般从2e-5起步如果loss震荡就降到1e-5如果loss下降太慢就升到5e-5。batch size也要注意太小梯度噪声大太大显存不够32到64比较合适。5.3 部署过程中的显存与并发问题显存不够和并发上不去是部署阶段的两大难题。显存不够先看模型本身占多少。7B模型FP16占14GBINT8占7GBINT4占3.5GB。然后看KV Cache占多少KV Cache的大小和max-model-len、max-num-seqs、模型层数、注意力头数都有关。如果显存不够优先降max-model-len再降max-num-seqs最后考虑换更小的模型或更低的量化精度。并发上不去先看GPU利用率。如果GPU利用率已经90%以上说明算力吃满了只能加卡或换更小的模型。如果GPU利用率不高但QPS上不去说明有瓶颈在别处可能是CPU预处理慢、网络带宽不够、或者框架的调度有问题。我遇到过一次并发上不去的情况排查发现是tokenizer成了瓶颈。tokenizer是Python实现的单线程处理并发一高就排队。后来换成了Rust实现的tokenizerQPS直接翻倍。所以部署时别只盯着GPUCPU侧的瓶颈也要关注。5.4 模型选型的常见纠结与决策建议选模型时最常见的纠结是选大的还是选小的选通用的还是选专用的选新的还是选稳的。我的建议是先跑通再优化。别一上来就纠结选哪个模型先拿一个7B的通用模型跑通全流程量化、部署、压测都走一遍心里有数了再根据实际瓶颈来调整。如果7B够用就不折腾如果不够用再考虑蒸馏或换更大的模型。选新的还是选稳的我倾向于选稳的。新模型可能指标好看但生态不完善踩坑成本高。稳的模型社区资源多遇到问题好查。除非新模型有不可替代的优势否则我一般选发布半年以上、社区活跃的模型。最后说一句模型选型没有标准答案只有适合你场景的答案。别人的推荐只能参考最终还得自己跑评测、做对比。我一般会选2到3个候选模型用真实数据跑一遍评测看哪个最合适。6. 推理优化与部署的实操心得6.1 从项目实战中总结的几条经验做了这么多推理优化和部署的项目我总结了几条经验都是踩坑踩出来的。第一条量化不是万能的。量化能省显存、提速度但精度损失是实实在在的。INT8通常没问题INT4就要小心了。如果业务对精度敏感宁可多花点显存跑INT8也别为了省显存跑INT4。第二条蒸馏要趁早。如果你确定最终要部署小模型那在项目初期就应该规划蒸馏流程而不是等大模型训完了再想蒸馏。蒸馏数据的准备、学生模型的选型、训练流程的设计这些都需要时间。第三条部署框架要匹配量化格式。AWQ模型用vLLM加载GPTQ模型用vLLM或ExLlama加载GGUF模型用llama.cpp加载。格式不匹配要么加载不了要么性能很差。第四条压测要模拟真实场景。别用固定长度的输入压测真实场景的输入长度是变化的。用真实数据压测才能发现真正的问题。第五条留足余量。显存留20%余量GPU利用率别超90%并发别顶到上限。生产环境最怕的就是突发流量留足余量才能扛住。6.2 后续可以继续深挖的方向推理优化这个领域还在快速演进有几个方向值得继续关注。FP8量化H100和4090都支持FP8精度比INT8好速度比FP16快。vLLM已经支持FP8后续可能会成为主流。投机采样用一个小模型做草稿大模型做验证能在保持精度的前提下提升推理速度。vLLM也支持这个特性值得试试。MoE架构混合专家模型在推理时只激活部分参数能在保持大模型容量的同时降低推理成本。DeepSeek系列就是MoE架构部署时要注意专家并行的配置。端侧推理随着RK3588、Jetson这些设备性能提升端侧跑大模型越来越可行。ONNX Runtime和TensorRT的端侧优化也在持续进步。这些方向我后续会继续跟进有新的实践心得再分享。推理优化没有终点只有不断迭代。