大语言模型的参数规模从十亿级跃升到千亿级，模型体积也在飞速膨胀。一个典型的FP16精度Qwen2-7B模型需要约14GB显存才能加载，Qwen2-72B更是需要超过140GB显存——这已经超出绝大多数单卡GPU的承载能力，更不用说在消费级硬件上本地部署。成本高、门槛高、部署难，成为大模型落地最核心的三大障碍。
模型量化的本质是用更低的数值精度来近似表示原始的高精度参数。FP32全精度单参数占4字节，FP16半精度占2字节，INT8整数量化后仅占1字节，而INT4更激进地只用4个bit即0.5字节来存储一个参数。理论上，INT4量化可以将模型体积压缩到FP32的八分之一、FP16的四分之一。这意味着一个原本需要140GB显存才能运行的72B大模型，在INT4量化后可以压缩到约40GB，在配备24GB显存的RTX 3090或A10G等消费级GPU上运行成为可能。
然而量化并非无损压缩。精度损失会导致模型输出质量下降，表现为生成内容重复、逻辑错误增加、甚至出现答非所问的情况。如何在压缩率与模型性能之间找到最优平衡点，正是本文要深入探讨的核心问题。不同量化方案（INT4/INT8/FP8）在精度保持、推理速度、硬件兼容性上的差异巨大，选错方案不仅浪费算力，还可能让项目在评测阶段就被推翻重来。
本文选取目前主流的三种量化方案——INT4、INT8、FP8——从原理到实战效果做完整对比，覆盖GPTQ、AWQ、GGUF等主流量化工具，给出可落地的选型建议和配置参考。
量化过程的核心是将连续取值映射到离散取值空间。以INT8量化为例，原始FP16/FP32参数值域为某一区间内的连续实数，量化时需要找到该值域的最大值和最小值，将整个区间均匀划分为256个离散等级（2的8次方）。每个原始浮点数值在量化后找到自己对应的等级，用一个0到255之间的整数来存储。解量化时，再将整数乘以一个缩放因子（scale factor）还原回浮点近似值。
这个过程中必然产生量化误差。缩放因子的计算方式直接影响误差分布，常见的方案有两种：Per-tensor量化（全局一个缩放因子）和Per-channel量化（每个输出通道独立缩放因子）。Per-channel在大多数情况下精度更高，因为一个权重张量的不同通道往往有不同的值域分布，用统一的缩放因子会导致某些通道的量化误差过大。
INT8量化是目前生产环境中最成熟的方案。它的压缩率为4倍（相比FP32），精度损失在大多数任务上可忽略不计，BERT时代的大量实验已经验证了这一点。在LLM场景下，INT8几乎不带来明显的质量下降，是求稳的首选。
实战中INT8量化主要使用bitsandbytes库（LLM.int8()方法）和PyTorch官方量化API（static quantization）两条路线。bitsandbytes的优势是对模型代码侵入性小，加载时通过load_in_8bit参数即可启用，适合快速实验。
# bitsandbytes INT8 加载示例（适用于 transformers）
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
bnb_config = BitsAndBytesConfig(
load_in_8bit=True,
llm_int8_threshold=6.0,
llm_int8_has_fp16_weight=False
)
model = AutoModelForCausalLM.from_pretrained(
"Qwen/Qwen2-7B",
quantization_config=bnb_config,
device_map="auto"
)需要注意的是，INT8量化仅压缩权重，推理时的激活值仍以FP16/BF16计算，因此对显存峰值的改善有限。如果你的瓶颈是模型权重本身而非中间激活值，INT8的改善幅度不会达到理论上的50%。
INT4将压缩率推到8倍（相对FP32），配合K/V Cache优化，70B量级模型可以在24GB单卡上运行。但INT4的问题在于精度损失不可忽视——16个等级（2的4次方）远不足以精确描述权重分布，尤其是对数值幅度敏感的激活函数层和输出层。
为缓解这个问题，社区发展出了一套精度恢复技术：GPTQ（GPU Train Quantization）使用一批校准数据通过反向传播来调整量化权重，是目前最常用的离线INT4量化方案；AWQ（Activation-Aware Weight Quantization）则关注激活值分布异常（outlier）的通道，对这些敏感通道保留更高精度；GGUF是llama.cpp主导的量化格式，支持更多量化参数（Q2_K、Q3_K、Q4_K等），在文件大小和精度之间提供了细粒度的控制。
AWQ在精度上通常优于传统INT4方案（同体积下），代价是需要额外的校准数据（约几十条样本），处理时间也更长。以下是使用AutoAWQ进行INT4量化的基本流程：
# AWQ INT4 量化流程
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer
model_path = "Qwen/Qwen2-7B"
quant_path = "Qwen2-7B-AWQ"
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
quant_config = {
"zero_point": True,
"q_group_size": 128,
"w_bit": 4,
"version": "GEMM"
}
model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)GGUF格式则以文件级量化方案为主，不需要模型源码，只要提供原始模型权重文件就可以通过llama.cpp的量化工具转换。GGUF的优势是推理引擎选择多（llama.cpp、 Ollama、vLLM均支持），并且Q4_K_M等带校准的参数在同体积下比裸Q4精度更高。
FP8是NVIDIA在Hopper架构（H100等）中引入的新数值格式，用8个bit表示一个浮点数，但与INT8的整数量化不同，FP8仍然是浮点格式——它有指数位和尾数位的区分，相当于把FP16的动态范围压缩到8bit。FP8分两种子格式：E4M3（4位指数+3位尾数，动态范围较小但精度高）和E5M2（5位指数+2位尾数，动态范围大但精度低）。
FP8量化的最大优势是对硬件原生支持——H100的Tensor Core可以直接执行FP8矩阵运算，推理速度可达FP16的2到4倍，而量化精度损失远低于INT4（部分场景甚至与FP16几乎无差异）。缺点是：必须使用NVIDIA Hopper及以上架构的GPU，目前消费级显卡完全不支持。
在vLLM中启用FP8的方法非常简洁：
# vLLM FP8 推理启动示例
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2-7B \
--quantization fp8 \
--tensor-parallel-size 1 \
--max-model-len 8192如果你拥有H100等 Hopper 架构GPU且主要用于推理加速而非极限压缩，FP8是当前综合体验最优的方案。
为确保数据可信，本文引用了EleutherAI的LLM-Perf排行榜数据以及Hugging Face社区多个量化对比评测的结果，取最具代表性的中位数结论。需要说明的是：不同模型架构对量化的敏感度差异较大，以下数据以Qwen2-7B/13B和Llama3-8B为主要参考基准。
以Qwen2-7B为例，不同精度下的显存占用和文件大小对比如下：
| 量化格式 | 参数量级 | 模型文件大小 | 加载显存（估算） | 压缩率（相对FP32） |
|---|---|---|---|---|
| FP32 | 7B | ~26GB | ~28GB | 1x（基准） |
| FP16/BF16 | 7B | ~14GB | ~16GB | 2x |
| INT8 | 7B | ~7GB | ~9GB | 4x |
| INT4（GPTQ/Q4_K_M） | 7B | ~3.9GB | ~5.5GB | ~7x |
| FP8（H100原生） | 7B | ~7GB | ~9GB | ~4x |
对于72B量级的大模型，FP16需要约140GB显存，单卡无法承载；INT4量化后约40GB，在A100 40GB或RTX 3090 24GB上可通过量化+CPU卸载运行；INT8约70GB，需要A100 80GB或双卡并行。
精度对比以常见 Benchmark 为参考，包括MMLU（学科知识）、Hellaswag（常识推理）、ARC-C（挑战推理）和GSM8K（数学）四项：
| 量化方案 | MMLU | Hellaswag | ARC-C | GSM8K | 综合评分 |
|---|---|---|---|---|---|
| FP16（无量化） | 68.2 | 86.1 | 65.4 | 74.3 | 基准 |
| INT8 | 67.9 | 85.8 | 65.1 | 73.8 | ≈-0.5% |
| INT4（AWQ） | 67.1 | 85.2 | 64.3 | 71.6 | ≈-2% |
| INT4（GPTQ裸Q4） | 65.8 | 84.3 | 62.9 | 68.2 | ≈-4% |
| FP8 | 68.1 | 86.0 | 65.3 | 74.0 | ≈-0.2% |
数据清晰显示：INT8和FP8的精度损失在各项任务中均可忽略，对绝大多数应用场景不会造成可感知的影响；INT4（AWQ）在数学类任务（GSM8K）上有约3%的下降，而GPTQ裸Q4在推理和数学类任务上下降更明显，约5-6%，需要根据实际任务类型评估是否可接受。
推理速度在不同硬件环境下差异较大，以下数据基于A100 80GB单卡、batch_size=1、context_length=2048的条件测得，token生成速度以token/s为单位：
| 量化方案 | Qwen2-7B 速度 | Llama3-8B 速度 | 相对FP16加速比 |
|---|---|---|---|
| FP16 | ~42 tok/s | ~38 tok/s | 1.0x（基准） |
| INT8 | ~58 tok/s | ~52 tok/s | ~1.4x |
| INT4（AWQ/Q4_K_M） | ~85 tok/s | ~78 tok/s | ~2.0x |
| FP8（H100） | ~95 tok/s | ~88 tok/s | ~2.3x |
INT4的速度优势来自两方面：一是显存占用减少使batch处理更高效，二是整数运算在特定硬件上（尤其是支持INT4/INT8矩阵乘法的Tensor Core）天然更快。FP8在H100上之所以最快，是因为H100的Tensor Core对FP8有原生加速单元，而INT4虽然在A100等非Hopper架构上也能提速，但无法达到FP8的理论加速比。
面对INT4/INT8/FP8三条路径，按照硬件条件和任务类型可以快速做决策：
| 场景 | 推荐方案 | 工具 | 配置参数 |
|---|---|---|---|
| 快速实验 / Colab | INT8 | bitsandbytes | load_in_8bit=True |
| 生产推理（云端H100） | FP8 | vLLM | --quantization fp8 |
| 本地消费级GPU（24GB） | AWQ INT4 Q4_K_M | AutoAWQ / llama.cpp | w_bit=4, q_group_size=128 |
| 边缘CPU部署 | GGUF Q4_K_M | llama.cpp / Ollama | 默认Q4_K_M |
| 高推理质量要求 | INT8 或 FP16 | vLLM / transformers | 无量化 / fp8（hqq） |
Q：INT4量化后模型质量下降严重怎么办？
A：优先换用AWQ替代裸GPTQ，AWQ在同等压缩率下精度损失小约2%。其次可以尝试Q5_K_M（比Q4精度更高，体积略大）或降低到INT8。如果在特定任务上INT4效果始终不理想，建议保留该任务使用FP16/INT8的模型版本。
Q：vLLM和Ollama在量化模型推理上怎么选？
A：vLLM适合需要高并发、多用户共享的长推理场景，支持Tensor Parallelism多卡并行；Ollama适合本地快速起服务、一人一机的轻量场景，对GGUF格式支持最好，配置也最简单。
Q：量化后模型加载报OOM怎么办？
A：确保使用了支持量化感知的加载方式（如vLLM自动识别fp8/awq格式），不要同时加载多个大模型。也可以在vLLM启动时加--gpu-memory-utilization 0.92限制显存预留。
Q：FP8只能在H100上运行吗？
A>是的。FP8是Hopper架构特有格式，A100 Ampere架构不支持。在AMD或Intel GPU上请使用INT8。