1.1 数值精度#

1.2 量化原理#

量化将浮点权重映射到低精度整数：

$x_{quant} = \text{round}(x / s + z)$

其中 $s$ 是缩放因子（scale），$z$ 是零点（zero point）。

反量化时： $x_{dequant} = s \cdot (x_{quant} - z)$

对称量化（$z = 0$）是最常见的方案：

$x_{quant} = \text{clamp}\left(\text{round}\left(\frac{x}{\max(|x|)}\right) \cdot (2^{b-1} - 1), -2^{b-1}, 2^{b-1}-1\right)$

其中 $b$ 为目标位宽（如 INT4 时 $b=4$）。

1.3 量化误差#

量化引入的误差会影响模型精度：

误差来源：

1. 舍入误差：浮点到整数的映射，每个权重都有 $\pm 0.5 \cdot s$ 的偏差
2. 截断误差：超出量化范围的值被截断到最近端点
3. 异常值放大：少量异常值会拉大量化范围，导致大部分正常值的精度变差

异常值问题是量化精度损失的主要来源。研究发现 Transformer 模型中约 0.1% 的权重通道包含极端异常值（magnitude > 100），这些通道对量化非常敏感。

2.1 核心思想#

GPTQ（Frantar & Alistarh, 2023）是一种**后训练量化（Post-Training Quantization, PTQ）**方法，无需重新训练即可量化模型。

核心思想：逐层优化，找到最小化输出误差的量化参数

GPTQ 的关键优势在于：

• 无需重新训练模型
• 量化速度快（LLaMA-65B 约 4 小时）
• 精度损失极小（INT4 量化 perplexity 增加通常 < 0.5）

2.2 最优大脑量化（OBQ）#

GPTQ 的理论基础来自 OBQ（Optimal Brain Quantization）算法，后者又源自经典的 Optimal Brain Surgeon（OBS）框架。

OBS 框架的核心问题：给定已训练好的模型权重，如果要删除（或量化）某些权重，如何调整剩余权重以最小化对输出的影响？

对于权重矩阵 $\mathbf{W}$，量化后产生的误差为：

$\mathcal{L} = \|\mathbf{W}\mathbf{X} - \hat{\mathbf{W}}\mathbf{X}\|^2 = \text{tr}\left((\mathbf{W} - \hat{\mathbf{W}})^T \mathbf{H}^{-1} (\mathbf{W} - \hat{\mathbf{W}})\right)$

其中 $\mathbf{H} = 2\mathbf{X}\mathbf{X}^T$ 是 Fisher 信息矩阵的近似（即 Hessian 矩阵），$\mathbf{X}$ 是校准数据集上的输入激活。

逐权重贪心量化：OBQ 按照每个权重对输出误差的贡献排序，贪心地选择影响最小的权重优先量化：

$w_q = \text{argmin}_i \frac{(w_i - \text{quant}(w_i))^2}{[\mathbf{H}^{-1}]_{ii}}$

量化一个权重后，需要通过 OBS 公式修正剩余权重：

$\mathbf{w}_{\text{new}} = \mathbf{w} - \frac{w_q - \text{quant}(w_q)}{[\mathbf{H}^{-1}]_{qq}} \cdot \mathbf{H}^{-1}_{\cdot, q}$

2.3 GPTQ 的改进：从 OBQ 到可扩展#

OBQ 的原始算法复杂度为 $O(d^3 \cdot d_{row})$（$d$ 为列数，$d_{row}$ 为行数），对于大模型不可行。GPTQ 做了三个关键改进：

1. 固定列序替代贪心选择

GPTQ 发现贪心选择的排序与自然列序差异不大，因此直接按列顺序量化，将复杂度降低到 $O(d^2 \cdot d_{row})$。

1
def gptq_quantize(W, H_inv, bits=4):
2
    """
3
    GPTQ 核心算法
4
    W: 权重矩阵 [d_row, d_col]
5
    H_inv: Hessian 逆矩阵 [d_col, d_col]
6
    """
7
    Q = np.zeros_like(W)  # 量化后的权重
8
    E = np.zeros_like(W)  # 累积误差
9

10
    for col in range(W.shape[1]):
11
        # 量化当前列
12
        Q[:, col] = quantize(W[:, col], bits)
13

14
        # 计算量化误差
15
        err_col = (W[:, col] - Q[:, col]) / H_inv[col, col]
16

17
        # 用 Hessian 逆矩阵修正后续列的权重
18
        # 这是 GPTQ 的核心：不是逐个独立量化，而是考虑权重间相关性
19
        W[:, col+1:] -= err_col[:, None] * H_inv[col, col+1:][None, :]
20

21
    return Q

2. 批量处理（Block-wise）

将权重列分成大小为 B（通常 B=128）的块，块内精确更新，块间只做近似修正。这使得算法可以高效利用 GPU 矩阵运算。

3. Cholesky 分解

为了避免数值不稳定的 Hessian 逆矩阵求逆运算，GPTQ 使用 Cholesky 分解预先计算所需的对角元素，大幅提升数值稳定性。

2.4 逐层处理流程#

GPTQ 按层独立处理，每一层的量化流程如下：

校准数据：GPTQ 需要少量校准数据（通常 128 条样本）来计算 Hessian 矩阵。这些数据不需要是训练数据，通用语料（如 C4、WikiText）即可。

2.5 实验结果#

3.1 核心思想#

AWQ（Activation-Aware Weight Quantization）由 Lin 等人在 2023 年提出，核心观察是：并非所有权重对量化误差的贡献相同，少量「显著权重」对模型精度至关重要。

与 GPTQ 不同，AWQ 的关键创新在于：通过激活分布来识别显著权重，而非通过 Hessian 矩阵。这意味着 AWQ 不需要昂贵的 Hessian 计算，量化速度更快。

3.2 激活感知的显著性度量#

AWQ 定义权重通道 $i$ 的显著性分数为：

$s_i = \mathbb{E}[|x_i|] \cdot |w_i|$

其中 $x_i$ 是第 $i$ 个输入通道的激活值，$w_i$ 是对应的权重。

直觉理解：如果一个权重通道的输入激活值很大，那么该通道的量化误差会被放大，因此需要更高精度。

为什么不用纯权重幅度？ 研究发现，仅看权重大小不足以判断该通道对输出的影响。有些权重大但输入激活很小，量化后影响不大；有些权重不大但激活很大，量化后影响显著。

3.3 逐通道缩放（Per-Channel Scaling）#

AWQ 不是简单地将显著通道用 INT8、其余用 INT4，而是通过逐通道缩放来保护显著权重。

核心公式：对于权重通道 $i$，寻找最优缩放因子 $s_i$：

$\hat{w}_i = s_i \cdot w_i, \quad \hat{x}_i = x_i / s_i$

量化后再反量化：

$\text{Quant}(s_i \cdot w_i) / s_i$

通过增大显著通道的 $s_i$，等效地增大了该通道的量化精度（因为量化范围内的离散级别更多）。

最优缩放因子通过以下目标搜索：

$s_i^* = \text{argmin}_{s_i} \|\text{Quant}(s_i \cdot w_i) \cdot (x_i / s_i) - w_i \cdot x_i\|$

AWQ 使用快速的网格搜索，在 $[0, 1]$ 范围内以 0.1 为步长搜索最优 $s_i$，整个过程非常高效。

3.4 保护显著权重的量化流程#

AWQ 的实际量化流程中，所有权重统一量化为 INT4，但通过缩放因子隐式地为显著通道分配了更高的有效精度。这种方法的优势：

• 无需混合精度运算：推理时全部用 INT4 计算，硬件友好
• 缩放因子开销极小：仅增加 < 0.1% 的参数量
• 量化速度快：无需 Hessian 计算，比 GPTQ 快 2-3 倍

3.5 量化流程对比#

3.6 AWQ 实验结果#

4.1 GGML 与 GGUF#

GGUF（原名 GGML）是 llama.cpp 团队开发的量化格式：

• GGML：C 语言实现的机器学习张量库
• GGUF：统一量化格式，支持多种量化方法，替代了旧的 GGML 格式

GGUF 相比 GGML 的改进：

• 可扩展的元数据系统（支持键值对）
• 向后兼容性保证
• 支持 mmap 高效加载
• 更丰富的量化类型选择

4.2 量化类型详解与对比#

GGUF 支持多种量化类型，核心区别在于是否使用「k-quantization」（分层混合精度）：

基础量化（均匀量化）

k-quantization（分层混合精度）

bpw = bits per weight，包含缩放因子等元数据的开销。

4.3 Q4_0 vs Q4_K_M vs Q5_K_M 实际对比#

以 LLaMA-7B 为例的具体对比：

选择建议：

• Q4_K_M：性价比最高，推荐作为默认选择
• Q5_K_M：精度敏感场景（如代码生成、数学推理）
• Q4_0：纯速度优先，对质量不敏感的场景

4.4 GGUF 文件结构#

1
// GGUF 文件格式
2
struct GGUFHeader {
3
    char magic[4];      // "GGUF"
4
    uint32_t version;
5
    uint64_t tensor_count;
6
    uint64_t metadata_kv_count;
7
    // ... 元数据键值对
8
    // ... 张量数据
9
};

元数据中存储的关键信息：

• general.architecture：模型架构名称
• llama.context_length：最大上下文长度
• llama.embedding_length：嵌入维度
• llama.block_count：Transformer 层数

5.1 核心特性#

llama.cpp 提供了高效的 CPU/GPU 推理：

• C/C++ 实现：无需 Python 环境，零依赖
• Metal 加速：Apple Silicon 原生支持（M1/M2/M3/M4）
• CUDA kernel：NVIDIA GPU 优化
• Vulkan 后端：支持 AMD GPU 和其他 Vulkan 兼容设备
• 批量推理：支持多并发请求
• 多模态扩展：支持 LLaVA 等视觉语言模型

5.2 使用示例#

1
# 量化模型
2
./quantize ./models/LLaMA-7B/ggml-model-f16.gguf ./models/LLaMA-7B/ggml-model-q4_k_m.gguf Q4_K_M
3

4
# 推理
5
./main -m ./models/LLaMA-7B/ggml-model-q4_k_m.gguf \
6
       -n 512 \
7
       -p "The theory of relativity states that"
8

9
# 启动 OpenAI 兼容 API 服务
10
./server -m ./models/LLaMA-7B/ggml-model-q4_k_m.gguf \
11
         --host 0.0.0.0 --port 8080

5.3 性能对比#

6.1 量化位宽与 Perplexity 退化#

量化误差最直观的衡量指标是 Perplexity（困惑度） 的退化程度。以下是基于 LLaMA 系列模型的典型退化数据：

关键发现：

1. INT8 量化几乎无损：perplexity 退化 < 1%，推荐所有部署场景使用
2. INT4 是性价比甜蜜点：使用 GPTQ/AWQ 后退化约 7%，内存节省 75%
3. INT3 及以下退化严重：仅在极端资源受限场景考虑
4. 量化方法的选择很重要：RTN（直接取整）在 INT4 下比 GPTQ/AWQ 差很多

6.2 量化对不同任务的影响#

量化对不同类型任务的敏感度不同：

实践建议：对于代码生成和数学推理任务，建议至少使用 INT4 的 k-quantization（如 Q4_K_M）或 INT5/INT8。

7.1 为什么需要 KV Cache 量化#

推理过程中，Transformer 需要缓存每一步的 Key 和 Value 向量（KV Cache），以避免重复计算。对于长上下文推理，KV Cache 的内存占用非常可观：

$\text{KV Cache Size} = 2 \times n_{\text{layers}} \times n_{\text{heads}} \times d_{\text{head}} \times \text{seq\_len} \times \text{dtype\_size}$

以 LLaMA-70B、128K 上下文为例：

• FP16 KV Cache：$2 \times 80 \times 64 \times 128 \times 131072 \times 2 \approx$ 40 GB
• 这意味着即使模型权重量化到了 35GB，KV Cache 仍然占 40GB！

7.2 KV Cache 量化方法#

7.3 KV Cache 量化对长上下文的影响#

KV Cache 量化对长上下文场景影响尤为显著：

实践建议：

• 上下文 < 4K：权重量化优先，KV Cache 用 FP16 或 KV8 即可
• 上下文 4K-32K：KV8 几乎无损，推荐使用
• 上下文 128K+：考虑 K4V8 混合策略，节省内存同时保持精度

7.4 主框架的 KV Cache 量化支持#

8.1 量化方法全景对比#

以 LLaMA-70B 为基准的综合对比：

速度以 FP16 为基准（1×），实际速度取决于硬件和 batch size。

8.2 场景选择决策树#

9.1 量化方法选择#

9.2 量化脚本#

1
from transformers import AutoModelForCausalLM
2
from auto_gptq import AutoGPTQForCausalLM
3
from awq import AutoAWQForCausalLM
4

5
# === GPTQ 量化 ===
6
model = AutoGPTQForCausalLM.from_quantized(
7
    "TheBloke/LLaMA-7B-GPTQ",
8
    model_basename="model",
9
    use_safetensors=True,
10
    device="cuda:0"
11
)
12

13
# === AWQ 量化 ===
14
model = AutoAWQForCausalLM.from_pretrained("meta-llama/LLaMA-7B")
15
tokenizer = AutoTokenizer.from_pretrained("meta-llama/LLaMA-7B")
16

17
quant_config = {
18
    "zero_point": True,
19
    "q_group_size": 128,
20
    "w_bit": 4,
21
}
22
model.quantize(tokenizer, quant_config=quant_config)

9.3 llama.cpp 量化命令参考#

1
# 将 HuggingFace 模型转换为 GGUF
2
python convert_hf_to_gguf.py ./models/LLaMA-7B/ --outtype f16
3

4
# 量化为不同等级
5
./quantize ./models/LLaMA-7B/ggml-model-f16.gguf ./models/LLaMA-7B-Q4_K_M.gguf Q4_K_M
6
./quantize ./models/LLaMA-7B/ggml-model-f16.gguf ./models/LLaMA-7B-Q5_K_M.gguf Q5_K_M
7

8
# 启动 API 服务器（支持 OpenAI 格式）
9
./server -m ./models/LLaMA-7B-Q4_K_M.gguf \
10
         --host 0.0.0.0 --port 8080 \
11
         -c 4096 -ngl 99

10.1 Q1： GPTQ 和 AWQ 该选哪个？#

大多数场景选 AWQ。AWQ 量化速度快（无需 Hessian 计算），精度与 GPTQ 相当甚至略好，且推理时无需特殊 kernel。但如果你的部署框架（如 vLLM）对 GPTQ 有更好的优化支持，GPTQ 也是很好的选择。

10.2 Q2： INT4 量化会明显影响模型能力吗？#

取决于任务类型。对于一般文本生成和对话，INT4 的影响很小（perplexity 增加约 5-7%）。但对于数学推理和代码生成等精度敏感任务，建议使用 Q5_K_M 或更高位宽。

10.3 Q3： 量化后模型能在 CPU 上运行吗？#

可以。llama.cpp 专为 CPU 推理优化，Apple Silicon（M1/M2/M3/M4）的 Metal 加速效果尤其好。LLaMA-7B Q4_K_M 在 M2 MacBook 上可以达到 ~20 tok/s。

10.4 Q4： 校准数据集对量化效果有多大影响？#

影响不大但存在。GPTQ 和 AWQ 通常使用 128 条通用语料（如 C4、WikiText）作为校准数据。研究表明，校准数据的领域分布对量化精度有轻微影响，但总体差异 < 0.1 perplexity。

10.5 Q5： KV Cache 量化值得做吗？#

长上下文场景非常值得。当上下文超过 32K token 时，KV Cache 的内存可能超过模型权重本身。KV8 量化几乎无损，但能节省 50% 的 KV Cache 内存。

10.6 Q6： 量化能和 LoRA 微调一起用吗？#

可以，这就是 QLoRA。QLoRA 先将模型量化为 NF4（NormalFloat4），然后在量化模型上训练低秩适配器。这是一种非常高效的微调方案，在消费级 GPU 上即可微调大模型。

10.7 Q7： 不同量化方法可以互相转换吗？#

不能直接转换。GPTQ、AWQ、GGUF 各有独特的量化参数和存储格式，需要从原始 FP16 模型重新量化。HuggingFace 上的社区模型通常提供多种量化格式。

10.8 Q8： 2-bit 量化有实用价值吗？#

目前没有。INT2 量化会导致 perplexity 翻倍以上，模型能力严重退化。它主要用于研究和实验。不过，随着量化算法的进步（如 AQLM、QuIP#），2-bit 量化的可行性正在改善。

10.1 4-bit 量化会显著降低模型质量吗？#

取决于方法。GPTQ 4-bit 在 MMLU 上仅下降 1-2%，AWQ 4-bit 下降更少。但 3-bit 及以下通常会有明显退化。对于大多数部署场景，4-bit 是质量和大小的最佳平衡点。

10.2 GPTQ 和 AWQ 应该选哪个？#

AWQ 更快（无需逐层 Hessian 计算），量化过程更简单，且支持激活感知保护。GPTQ 在某些模型上精度略高。实际部署中推荐优先使用 AWQ 或 GGUF（llama.cpp 生态更完善）。

10.3 GGUF 和 GPTQ/AWQ 的区别是什么？#

GPTQ/AWQ 是 GPU 加速的量化格式（需要 CUDA），GGUF 是 llama.cpp 的通用格式（支持 CPU/Metal/CUDA/ROCm）。GGUF 更适合本地部署和边缘设备，GPTQ/AWQ 更适合服务器 GPU 部署。

10.4 量化后的模型能用 LoRA 微调吗？#

可以，这就是 QLoRA 的思路：先 4-bit 量化基础模型，再训练 LoRA 适配器。QLoRA 在保持 4-bit 内存优势的同时，微调效果接近全参数 BF16 微调。

10.5 KV Cache 也需要量化吗？#

是的。长上下文场景下 KV Cache 占用大量显存（32K 上下文 × 70B 模型约需 8GB）。KV8（8-bit KV Cache）可节省 50%，KV4 可节省 75%，对推理延迟影响很小。