量化

量化把权重(有时还有激活)从 BF16/FP16 压到更窄的格式,换显存和带宽,换一点精度。vLLM 侧常见是 AWQ、GPTQ、FP8,以及 compressed-tensors 等更新格式。这和 Ollama 里的 GGUF Q4/Q8 不是同一条流水线:不要指望把 .gguf 直接丢给 vllm serve 当默认路径。

算法枚举、内核名(Marlin 等)随版本变。下面讲选型;标志以 vllm serve --help量化文档 为准。


三种格式(高层)

方法直觉典型来源适合
AWQ4-bit 权重量化,保护「显著」通道Hub 上 *-AWQ 仓库消费级 / 中端 GPU 跑 7B–70B
GPTQ4-bit,用校准数据压权重AutoGPTQ / Hub GPTQ 仓存量 GPTQ 检查点很多
FP88-bit 浮点;新架构可 W8A8预量化仓,或加载时在线转Hopper / Ada 等(计算能力常见 ≥ 8.9 才有完整 FP8 算力;更老的卡可能走权重量化回退,以当前文档为准

粗算:7B 的 16-bit 大约十多 GB 量级;4-bit 往往能进 8–12GB 级显卡(还要加 KV)。不要用经验公式替代 nvidia-smi 精度:指令遵循、数学、长上下文最容易伤;上线前用你的评测集对比满精度。


--quantization 还要不要写?

预量化检查点(仓库里已有 quantize_config.json / config.jsonquantization_config)时,vLLM 常常能自动识别,不必强行加标志。乱写 --quantization 可能和检查点声明冲突而报错。

在线量化(把 BF16/FP16 在加载时转成 FP8 等)才需要明确指定,例如官方仍文档化的:

vllm serve facebook/opt-125m --quantization fp8
from vllm import LLM

llm = LLM(model="facebook/opt-125m", quantization="fp8")

AWQ / GPTQ 预量化仓(ID 换成你确认存在且许可允许的仓库):

vllm serve <org>/<model>-AWQ
# 若必须声明(以当前文档为准):
# vllm serve <org>/<model>-AWQ --quantization awq

--quantization / -q 的合法取值列表很长(awq、gptq、fp8、marlin 变体、bitsandbytes…)。抄博客里的旧枚举前先 --help


实践建议

  1. 先跑通未量化小模型(本课的 Qwen 0.5B / OPT-125M),确认驱动与 API。
  2. 需要更大模型再找 已经量化好的 Hub 仓,读模型卡:许可、量化工具、group size。
  3. 有 H100 / L40S 一类新卡,优先评估 FP8(吞吐 vs 精度)。
  4. 不要把「4-bit 一定更快」当成定理:内核、batch、KV 精度都会影响;以实测 tokens/s 为准。
  5. KV 缓存还可以有独立精度选项(如 --kv-cache-dtype,名称以当前文档为准),那是另一档显存账。

Hugging FaceAWQ / GPTQ 时,避开门控 Llama 作为唯一依赖;Qwen、部分社区 OPT/GPT 量化仓更容易第一次就下下来。


和 Ollama 量化的分工

OllamavLLM
常见格式GGUF(Q4、Q8…)AWQ / GPTQ / FP8 / 压缩张量
目标单机交互、省心服务端 batch
换量化改 Library 标签换 Hub 仓或 --quantization

需要桌面「拉一个 q4 就聊」→ Ollama。需要 OpenAI 兼容网关、连续批处理 → vLLM + 对应检查点。


常见问题

加载报 quantization mismatch? 去掉手写 --quantization,或改成与 quantize_config.json 一致的方法名。

FP8 报架构不支持? 卡太老;改用 AWQ/GPTQ 或满精度小模型。

质量明显崩? 换 bit 数更高的仓,或回到 BF16 并减小 --max-model-len / 并发。

bitsandbytes / GGUF? 支持情况版本差异大,不当本课默认。以当前量化章节为准。


下一步

评论