3.4 量化推理优化

3.4 量化推理优化

本节导读：量化用精度换成本——显存减半、吞吐翻倍、同样GPU能服务的模型翻番。本节梳理vLLM支持的各类量化方案（FP8/AWQ/GPTQ/INT8/KV量化），讲清选型逻辑、上线方法与精度验证流程。

学习目标

• 理解权重量化、KV Cache量化的原理与区别
• 掌握各量化方案的选型决策方法
• 能在vLLM中部署量化模型并验证精度损失
• 学会用llm-compressor自产量化模型

核心概念

量化的两个维度

两者独立、可叠加，但都要过精度验证这一关。

vLLM主要量化方案对比

选型主线：有H100/L40S选FP8；通用卡追求4bit选AWQ；求稳选INT8。

为什么4bit还能用：分位数缩放

直接把权重截断到4bit会毁掉模型。AWQ/GPTQ这类PTQ（训练后量化）方法的核心是识别"关键通道"——对激活分布敏感的权重通道保持高精度或放大缩放因子，其余压到4bit，最终用校准数据集补偿误差。所以同是4bit，量化质量差异很大，优先选官方或社区验证过的量化权重。

分步实战

步骤 1：直接加载社区量化模型

# AWQ 4bit（Qwen官方发布，质量有保障）
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
  --quantization awq \
  --max-model-len 8192

# FP8（H100环境）
vllm serve Qwen/Qwen2.5-7B-Instruct-FP8 --quantization fp8
​

步骤 2：对比量化前后的资源占用

nvidia-smi --query-gpu=memory.used --format=csv
# 7B模型典型对比：
# FP16   ≈ 15GB 权重 + KV
# AWQ 4bit ≈ 5GB  权重 + KV  → 同卡能塞更大模型或更大KV池
​

同时跑压测对比吞吐：4bit权重小、访存少，decode吞吐通常提升30%~80%。

步骤 3：用llm-compressor自产量化模型

业务模型微调后没有现成量化版，自己压一个：

from llmcompressor.transformers import oneshot
from llmcompressor.modifiers.quantization import QuantizationModifier
from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained(
    "my-finetuned-model", torch_dtype="auto")
recipe = QuantizationModifier(
    targets="Linear", scheme="FP8_DYNAMIC", ignore=["lm_head"])
oneshot(model=model, recipe=recipe, output_dir="my-model-fp8")
​

FP8动态方案无需校准数据；若做INT8静态量化，需准备几百条代表性样本作为校准集。

步骤 4：开启KV Cache量化

vllm serve Qwen/Qwen2.5-14B-Instruct \
  --kv-cache-dtype fp8 \
  --max-model-len 32768
​

KV显存减半意味着：同样显存下长上下文并发能力翻倍，与前缀缓存（3.3节）叠加效果更佳。

步骤 5：精度验证（上线前必做）

准备业务评估集（50~500条真实样本），对比量化前后输出：

import json
from evaluate import load

befores = json.load(open("outputs_fp16.json"))
afters  = json.load(open("outputs_awq.json"))

# 1) 任务指标：分类看accuracy/F1，抽取看F1，生成看人工抽检或LLM-as-judge
# 2) 回归检查：困惑度对比
ppl = evaluate.load("perplexity")
print(ppl.compute(predictions=afters, model_id="my-model-fp16")["mean_perplexity"])
​

验收标准建议：任务指标下降<1%、抽样人工盲评无感知差异，方可上线。

完整示例：一张24GB卡跑14B的完整路径

FP16下14B需要约28GB权重，装不下。两条路：

# 路线A：AWQ 4bit ≈ 9GB权重，剩余15GB全给KV Cache
vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
  --quantization awq --max-model-len 16384 --gpu-memory-utilization 0.95

# 路线B：FP8权重(若有)≈14GB + fp8 KV，上下文更长
vllm serve Qwen/Qwen2.5-14B-Instruct-FP8 \
  --quantization fp8 --kv-cache-dtype fp8 --max-model-len 32768
​

量化把"不可能"变成"日常"，这正是它成为推理侧标配的原因。

常见问题 FAQ

Q1：4bit量化后模型"变笨"了怎么办？
分三步：①换量化质量更高的版本（官方AWQ > 不知名repo的GPTQ）；②改用INT8/FP8，8bit通常无可感知损失；③退回FP16并对模型规模降级。量化是手段，任务质量是底线。

Q2：FP8和INT8怎么选？
硬件优先：有H100/L40S（原生FP8支持）直接FP8，性能最好；Ampere及更早的卡（A10/A100/3090）选INT8或直接上4bit方案。

Q3：量化模型还能挂LoRA吗？
可以。vLLM支持AWQ/GPTQ基座+LoRA适配器组合（--enable-lora），但组合的rank与兼容性有限制，先在测试环境验证5.1节所述流程。

Q4：KV量化对短文本任务有意义吗？
收益有限。KV Cache体积与上下文长度成正比，短文本场景KV本来就不大；它真正的战场是32K以上长上下文与前缀缓存密集的负载。

Q5：校准集该怎么挑？
用线上真实分布的样本（几百条足够），覆盖高频场景与极端case。用不相干语料校准（如拿英文新闻校准中文客服模型）会让关键通道判断失准。

最佳实践与避坑

• 避坑一：只看显存数字就上线。任何量化都可能伤任务指标，评估集验证是不可跳过的环节；
• 避坑二：混用量化生态——基座AWQ、LoRA按FP16训练未转换。各组件格式要配套，否则加载即报错或精度异常；
• 实践：量化模型入库时把方案、位宽、校准集、评估结果写进模型卡，避免半年后无人敢动；
• 实践：FP16基线服务保留一份小流量副本，线上量化版指标波动时可快速比对定位。

本节小结

量化的本质是"用可接受的精度损失换取数量级的成本优势"。选型上，H100用FP8、通用卡4bit选AWQ、求稳用INT8；KV量化专治长上下文显存焦虑。所有量化上线都遵循同一纪律：业务评估集先行。第3章至此完结，下一章进入实战部署。

延伸阅读

• 相关章节：3.3 缓存策略优化、5.1 自定义模型与微调、5.4 性能深度调优
• vLLM·量化支持文档
• llm-compressor