第3章 vLLM中的量化支持

3、vLLM中的量化支持：量化方法概览与架构设计

聊到vLLM的量化支持，我得先坦白一件事——量化这个词，我刚入行时觉得特别高大上。说白了，就是把模型里的高精度数字（比如FP16）换成低精度的（比如INT4），换来更快的推理速度和更少的内存占用。但代价呢？精度会掉一点。

vLLM在这块做得挺实在的。它没有自己发明一套量化算法，而是把业界主流的几种量化方法都集成进来了。你想想看，这就像一个大工具箱，不同场景你拿不同的工具。

目前vLLM主要支持四种量化方法：AWQ、GPTQ、FP8和SqueezeLLM。我一个个说。

AWQ是2023年MIT和NVIDIA合作搞出来的。它的核心思路很巧妙——不是所有权重都同等重要。有些权重对模型输出影响大，有些则无所谓。AWQ会先分析激活值的分布，找出那些“重要”的权重通道，然后给它们分配更高的精度。

我个人习惯：在部署大模型（比如LLaMA-70B）到单卡A100上时，AWQ是我的首选。因为它对精度损失控制得特别好，4bit量化后，模型输出质量几乎感觉不到下降。

GPTQ是2022年由IST Austria提出的。它基于一个观察：权重量化误差可以通过“补偿”来修正。具体做法是，量化一个权重后，调整后续未量化的权重，来抵消前面产生的误差。

我在项目中遇到过一个问题：GPTQ在量化时需要一小部分校准数据（calibration dataset），大概128-256条就够了。但如果你选的校准数据跟实际推理数据分布差异太大，量化后的模型效果会打折扣。嗯，这里要注意。

FP8是NVIDIA在H100 GPU上主推的格式。它不像INT8那样需要复杂的量化校准过程，而是直接使用浮点数的8位版本。FP8有两种变体：E4M3（4位指数，3位尾数）和E5M2（5位指数，2位尾数）。

为什么会这样？因为不同层对数值范围的需求不一样。E4M3精度高但范围窄，适合权重和激活值；E5M2范围宽但精度低，适合梯度。

避坑指南：我曾经在H100上跑FP8推理，发现如果模型某些层的激活值特别大（比如超过448），E4M3会直接溢出。解决办法是手动对这些层做一次简单的缩放，或者改用E5M2。

SqueezeLLM是2023年UC Berkeley的工作。它跟前面几种方法不太一样——它不光做量化，还做非均匀量化和稀疏化。说白了，它把权重值聚成几个簇，每个簇用不同的量化参数。

我试过一次，在LLaMA-7B上，SqueezeLLM能做到3bit量化，而且困惑度（perplexity）只涨了不到0.5。但代价是推理时多了个查表操作，速度会慢一点。

光知道方法不行，你得知道什么时候用哪个。我整理了一张表，你直接看：

注意：以上建议基于vLLM 0.4.0及以后版本。早期版本对FP8和SqueezeLLM的支持不完整，升级前记得看release notes。

聊完方法，咱们看看vLLM内部是怎么组织这些量化逻辑的。我画了一张图，帮你理解整体架构：

这张图展示了vLLM量化模块的完整流程。从用户接口传入量化参数（比如--quantization awq），然后QuantConfig解析配置，接着QuantMethodSelector根据配置选择具体的量化方法。最后，三个核心组件协同工作：

WeightLoader：负责从磁盘加载量化后的权重文件。不同量化方法有不同格式，比如AWQ用.pt文件，GPTQ用.safetensors。
QuantKernel：这是性能关键。它实现了量化矩阵乘法（比如INT4的矩阵乘），用CUDA或ROCm编写。我调试过AWQ的kernel，发现它对共享内存的使用特别讲究，稍微调错一点就掉性能。
Dequantizer：有些算子不支持低精度计算，需要先反量化回FP16再算。Dequantizer负责这个转换，但尽量少用，因为反量化本身也有开销。

一个小技巧：如果你自己写量化kernel，记得利用vLLM的QuantOp枚举类。它定义了所有支持的量化操作类型，比如QuantOp.WEIGHT、QuantOp.ACTIVATION。这样你的代码就能跟vLLM的调度器无缝对接。

最后说一句，vLLM的量化模块设计得挺灵活的。它用了一个策略模式——每种量化方法都实现同一个接口（比如QuantMethod），这样新增一种量化方法时，不需要改推理引擎的代码。我去年给vLLM贡献过一个实验性的量化方法，就是照着这个接口写的，确实省了不少事。