起因
之前用 LoRA 微调了 Qwen3-VL-8B，做工地场景的图像理解与安全风险分析。微调完了要部署，目标是 vLLM 的 OpenAI 兼容 API server。把主流方案都过了一遍，最后落在 GPTQ W4A16 + LLM Compressor 上。中间踩了几个不算明显的坑，写下来给后面要做同样事情的人省点时间。
几个主流量化方案
先把目前能用在 Qwen3-VL 上的方案大致捋一遍。
GPTQ:基于二阶 Hessian 信息逐层校准量化，对 Qwen 系列适配很好。vLLM 原生支持，配合 Marlin INT4 kernel 推理速度非常快。需要校准数据但量不大，几百条够用。8-bit 几乎无损，4-bit 在领域微调场景下能压住 1–3 个点的精度损失。
AWQ:Activation-aware Weight Quantization。低比特下比 GPTQ 略稳，尤其是 3-bit。vLLM 同样支持。我没选它主要是因为 Qwen3-VL 的 AWQ 工具链成熟度暂时不如 GPTQ，社区 issue 反馈也多一些。
FP8（W8A8）:LLM Compressor 已经支持 Qwen3-VL 的 FP8，而且有 data-free 路径——不需要校准集，几分钟就能压完，精度几乎无损。但前提是 GPU 得有 FP8 Tensor Core，意味着 Ada Lovelace 或 Hopper 架构（H100、H20、L40S、4090、6000 Ada、5880 Ada 这些）。
bitsandbytes（NF4 / INT8）:最简单的方案，load_in_4bit=True 一行搞定。开发阶段用没问题，但 vLLM 对它的支持有限，性能远不如 GPTQ/AWQ。生产部署直接 pass。
GGUF:llama.cpp 的格式，Ollama / LM Studio 用的就是这个。不是 vLLM 的菜，而且 Qwen3-VL 的视觉部分在 llama.cpp 里支持情况要看具体版本。
SmoothQuant:是个量化前的预处理技术，把激活的离群点"摊"到权重上，让后续的 W8A8 更稳。一般不单独用，是 GPTQ/AWQ 的辅助手段。
简单对比：
| 方案 | 压缩比 | 精度损失 | vLLM 支持 | 需要校准 | 适用硬件 |
|---|---|---|---|---|---|
| GPTQ W4A16 | ~4x | 1–3 点 | 原生 | 是 | 通用 |
| AWQ W4A16 | ~4x | 1–2 点 | 原生 | 是 | 通用 |
| FP8 W8A8 | ~2x | <1 点 | 原生 | 否 | Ada / Hopper |
| BnB NF4 | ~4x | 2–4 点 | 弱 | 否 | 通用 |
完整流程
整个 pipeline 就四步：
- LoRA adapter 合并回 base model
- 准备图文校准数据
- LLM Compressor 跑 GPTQ oneshot
- vLLM 加载部署
环境版本：
llmcompressor>=0.8.0
transformers>=4.57
peft>=0.13
qwen-vl-utils>=0.0.10
vllm>=0.10
第一步：合并 LoRA
量化前必须先把 LoRA 合并进 base。否则量化器只动 base weights，LoRA 那部分还是 bf16，既不能完全压缩，部署时还得额外加载 adapter，没意义。
from transformers import Qwen3VLForConditionalGeneration, AutoProcessor
from peft import PeftModel
import torch
model = Qwen3VLForC转载自CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2301_78703432/article/details/161147757
