量化
量化把权重(有时还有激活)从 BF16/FP16 压到更窄的格式,换显存和带宽,换一点精度。vLLM 侧常见是 AWQ、GPTQ、FP8,以及 compressed-tensors 等更新格式。这和 Ollama 里的 GGUF Q4/Q8 不是同一条流水线:不要指望把 .gguf 直接丢给 vllm serve 当默认路径。
算法枚举、内核名(Marlin 等)随版本变。下面讲选型;标志以 vllm serve --help 与 量化文档 为准。
三种格式(高层)
粗算:7B 的 16-bit 大约十多 GB 量级;4-bit 往往能进 8–12GB 级显卡(还要加 KV)。不要用经验公式替代 nvidia-smi。 精度:指令遵循、数学、长上下文最容易伤;上线前用你的评测集对比满精度。
--quantization 还要不要写?
预量化检查点(仓库里已有 quantize_config.json / config.json 的 quantization_config)时,vLLM 常常能自动识别,不必强行加标志。乱写 --quantization 可能和检查点声明冲突而报错。
在线量化(把 BF16/FP16 在加载时转成 FP8 等)才需要明确指定,例如官方仍文档化的:
AWQ / GPTQ 预量化仓(ID 换成你确认存在且许可允许的仓库):
--quantization / -q 的合法取值列表很长(awq、gptq、fp8、marlin 变体、bitsandbytes…)。抄博客里的旧枚举前先 --help。
实践建议
- 先跑通未量化小模型(本课的 Qwen 0.5B / OPT-125M),确认驱动与 API。
- 需要更大模型再找 已经量化好的 Hub 仓,读模型卡:许可、量化工具、group size。
- 有 H100 / L40S 一类新卡,优先评估 FP8(吞吐 vs 精度)。
- 不要把「4-bit 一定更快」当成定理:内核、batch、KV 精度都会影响;以实测 tokens/s 为准。
- KV 缓存还可以有独立精度选项(如
--kv-cache-dtype,名称以当前文档为准),那是另一档显存账。
用 Hugging Face 搜 AWQ / GPTQ 时,避开门控 Llama 作为唯一依赖;Qwen、部分社区 OPT/GPT 量化仓更容易第一次就下下来。
和 Ollama 量化的分工
需要桌面「拉一个 q4 就聊」→ Ollama。需要 OpenAI 兼容网关、连续批处理 → vLLM + 对应检查点。
常见问题
加载报 quantization mismatch? 去掉手写 --quantization,或改成与 quantize_config.json 一致的方法名。
FP8 报架构不支持? 卡太老;改用 AWQ/GPTQ 或满精度小模型。
质量明显崩? 换 bit 数更高的仓,或回到 BF16 并减小 --max-model-len / 并发。
bitsandbytes / GGUF? 支持情况版本差异大,不当本课默认。以当前量化章节为准。