## 1. 为什么需要模型量化

随着大语言模型参数规模从 7B 一路增长到 70B、405B 甚至更大，显存和推理成本成为落地部署的最大瓶颈。以 FP16 精度为例，一个 7B 模型仅权重就需要约 14GB 显存，70B 模型则超过 140GB，普通消费级显卡根本无法加载。

量化（Quantization）的核心思想是：把模型权重从高精度浮点数（FP32/FP16/BF16）映射到低精度表示（如 4-bit 整数），从而大幅降低显存占用、加快推理速度，同时尽可能保持模型效果不出现明显下降。

当前主流的量化方案大致可以分成两类：

- **训练后量化（PTQ）**：不需要重新训练或微调，直接对已有模型做量化，代表方案有 **GPTQ**、**AWQ**。
- **面向推理框架的格式与混合推理方案**：把量化后的权重封装成特定格式，方便在不同硬件上高效运行，代表方案是 **GGUF**，配合 llama.cpp 可以实现在 CPU 与 GPU 之间灵活分配计算。

本文将围绕 GPTQ、AWQ（4-bit 权重量化）和 GGUF（CPU/GPU 混合推理）展开，介绍它们的原理、适用场景和实践用法。

## 2. 量化的基本概念

在深入三种方案之前，先理解几个关键概念。

### 2.1 对称量化与非对称量化

- **对称量化**：将浮点区间对称地映射到整数区间，零点固定为 0。计算简单，硬件友好。
- **非对称量化**：浮点区间和整数区间都不以 0 为中心，需要额外存储零点（zero point）。表达能力更强，但计算稍复杂。

### 2.2 量化粒度

- **逐张量量化（per-tensor）**：整个权重矩阵共享一个缩放因子，实现简单但精度损失较大。
- **逐通道量化（per-channel）**：每个输出通道单独计算缩放因子，精度更高，是大模型权重量化的主流选择。
- **分组量化（group-wise）**：把通道进一步分组，例如每 128 个元素共享一个缩放因子，精度与灵活性的平衡点。

### 2.3 量化位宽

- **8-bit**：通常损失很小，但节省空间有限。
- **4-bit**：显存开销约为 FP16 的四分之一，是目前“效果/成本”平衡最好的档位，也是 GPTQ、AWQ 最常见的配置。
- **3-bit、2-bit**：进一步节省空间，但模型质量下降明显，需要谨慎评估。

## 3. GPTQ：训练后量化的经典方案

### 3.1 GPTQ 的核心思想

GPTQ 是一种基于近似二阶信息的训练后量化方法。它借鉴了经典的 OBQ（Optimal Brain Quantization）思路：逐层对权重进行量化，并在量化每一列权重后，用 Hessian 矩阵的逆来补偿剩余权重，从而把量化误差分散到尚未处理的权重上。

GPTQ 的主要特点：

- 只需要少量校准数据，通常是 128 条左右的文本样本。
- 量化过程完全在单卡上即可完成，即使量化 70B 模型也不需要多卡训练环境。
- 支持 2/3/4/8-bit 量化，其中 4-bit 是实际使用最多的档位。
- 对于生成类任务，常见的 weight group size 为 128，并配合激活排序（act-order）进一步提升精度。

### 3.2 GPTQ 的优缺点

优点：

- 推理速度快，尤其适合在 NVIDIA GPU 上配合 ExLlama、vLLM、TensorRT-LLM 等推理引擎。
- 生态成熟，Hugging Face 上有大量现成的 GPTQ 量化模型可直接下载。

缺点：

- 量化过程主要针对权重做二阶误差补偿，激活值中的异常通道考虑不足。
- 在小批量、CPU 场景下表现一般，更适合 GPU 部署。
- 与特定 kernel 绑定较紧密，旧版本兼容性问题较多。

### 3.3 使用 AutoGPTQ 量化与推理

下面演示如何用 AutoGPTQ 对模型进行 4-bit 量化并加载推理。

```python
from transformers import AutoTokenizer
from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig

model_name = "Qwen/Qwen2.5-7B-Instruct"

# 量化配置
quantize_config = BaseQuantizeConfig(
    bits=4,              # 4-bit 量化
    group_size=128,      # 分组大小
    desc_act=True,       # 激活排序
)

# 加载原模型
model = AutoGPTQForCausalLM.from_pretrained(
    model_name,
    quantize_config=quantize_config,
    device_map="auto",
)

# 校准数据：通常准备一些代表性文本
tokenizer = AutoTokenizer.from_pretrained(model_name)
calibration_texts = [
    "量化是降低模型显存占用的重要手段。",
    "GPTQ 使用近似二阶信息补偿量化误差。",
]
calibration_dataset = [tokenizer(t) for t in calibration_texts]

# 执行量化
model.quantize(calibration_dataset)

# 保存量化后的模型
model.save_quantized("./qwen2.5-7b-gptq-4bit")
tokenizer.save_pretrained("./qwen2.5-7b-gptq-4bit")
```

加载已量化的 GPTQ 模型进行推理：

```python
from transformers import AutoTokenizer, pipeline
from auto_gptq import AutoGPTQForCausalLM

model = AutoGPTQForCausalLM.from_quantized(
    "./qwen2.5-7b-gptq-4bit",
    device="cuda:0",
)
tokenizer = AutoTokenizer.from_pretrained("./qwen2.5-7b-gptq-4bit")

pipe = pipeline("text-generation", model=model, tokenizer=tokenizer)
print(pipe("量化技术的优势是什么？", max_new_tokens=128)[0]["generated_text"])
```

## 4. AWQ：激活感知的 4-bit 权重量化

### 4.1 AWQ 的出发点

AWQ（Activation-aware Weight Quantization）观察到：LLM 的权重并不是同等重要的，大约 1% 的显著权重通道（salient channels）对模型输出影响远大于其余 99%。直接对所有权重做均匀量化，会导致这些重要通道的信息被抹掉，模型效果明显下降。

AWQ 的解决方案不是保留这些权重为高精度（因为混合精度会破坏硬件并行度），而是采用**逐通道缩放**：在量化前，对重要通道的权重乘以一个大于 1 的缩放系数，激活值相应除以该系数；量化后再把缩放合并回权重。这样既保护了重要通道，又保持全 4-bit 的统一精度，推理效率不受影响。

缩放系数通过一个简单高效的目标函数自动搜索得到，不需要反向传播或重训练。

### 4.2 AWQ 为什么快

- 量化后的权重统一为 4-bit，可以充分利用 GPU 上的 INT4 算子，没有 FP16 与 INT4 混合计算带来的额外开销。
- 相比 GPTQ，AWQ 不依赖复杂的逐层重建过程，量化速度更快。
- 在某些基准上，AWQ 的 4-bit 模型效果好于 GPTQ 4-bit，尤其在小模型上优势更明显。

### 4.3 使用 AutoAWQ 量化与推理

```python
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "Qwen/Qwen2.5-7B-Instruct"
quant_path = "./qwen2.5-7b-awq-4bit"

quant_config = {
    "zero_point": True,
    "q_group_size": 128,
    "w_bit": 4,
    "version": "GEMM",
}

# 加载并量化
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)

model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)
```

加载 AWQ 量化模型推理：

```python
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer, TextStreamer

model = AutoAWQForCausalLM.from_quantized(
    "./qwen2.5-7b-awq-4bit",
    fuse_layers=True,
)
tokenizer = AutoTokenizer.from_pretrained("./qwen2.5-7b-awq-4bit")

prompt = "请解释 AWQ 量化的核心思想。"
inputs = tokenizer(prompt, return_tensors="pt")
streamer = TextStreamer(tokenizer, skip_prompt=True)

_ = model.generate(
    **inputs,
    max_new_tokens=256,
    streamer=streamer,
)
```

## 5. GGUF：面向 CPU/GPU 混合推理的格式

### 5.1 GGUF 是什么

GGUF 是 llama.cpp 项目推出的模型文件格式，用于替代早期的 GGML 格式。它最大的特点是把模型权重、元数据、分词器等信息打包进单一文件，并且从设计上就考虑了跨平台、跨硬件的高效推理。

GGUF 支持多种量化档位，常见的包括：

- `Q4_K_M`：4-bit，质量与速度的平衡之选，也是社区使用最多的档位。
- `Q4_K_S`：4-bit 小模型版本，体积更小，效果略低于 Q4_K_M。
- `Q5_K_M`：质量高于 4-bit 档位，模型体积更大。
- `Q8_0`：接近原始质量的 8-bit 量化。

### 5.2 CPU/GPU 混合推理

GGUF 配合 llama.cpp 的最大优势在于**分层卸载（layer offloading）**：

- 可以把一部分层放在 GPU 上计算，剩余层放在 CPU 上计算。
- 通过 `-ngl`（n-gpu-layers）参数控制卸载到 GPU 的层数。
- 即使显存不足以容纳整个模型，也能利用 GPU 加速一部分计算，同时用 CPU 内存补齐剩余部分。

这种混合推理方式特别适合以下场景：

- 消费级显卡显存不足，无法完整加载 FP16 模型。
- 希望在没有独显的笔记本、Mac（Apple Silicon）上运行大模型。
- 需要将同一个模型文件方便地分发到不同硬件环境。

### 5.3 模型格式转换

将 Hugging Face 模型转换为 GGUF 格式，官方推荐使用 `convert_hf_to_gguf.py` 脚本：

```bash
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

pip install -r requirements.txt

# 转换模型，具体脚本位置以官方仓库为准
python convert_hf_to_gguf.py \
    /path/to/hf_model \
    --outfile model-f16.gguf \
    --outtype f16
```

转换后会得到 FP16 的 GGUF 文件，再对其进行量化：

```bash
# 使用 llama-quantize 进行 Q4_K_M 量化
./llama-quantize model-f16.gguf model-Q4_K_M.gguf Q4_K_M
```

### 5.4 使用 llama.cpp 混合推理

在 CPU + GPU 的混合模式下运行模型：

```bash
# -ngl 40 表示把 40 层卸载到 GPU，其余层在 CPU 计算
./llama-cli \
    -m model-Q4_K_M.gguf \
    -p "用一句话解释 GGUF 格式" \
    -ngl 40 \
    -n 256
```

也可以通过 llama-cpp-python 在代码中灵活控制：

```python
from llama_cpp import Llama

llm = Llama(
    model_path="./model-Q4_K_M.gguf",
    n_gpu_layers=40,   # GPU 层数，-1 表示尽可能全部卸载到 GPU
    n_ctx=4096,
    verbose=False,
)

output = llm.create_chat_completion(
    messages=[
        {"role": "user", "content": "解释 GGUF 的 CPU/GPU 混合推理优势"}
    ],
    max_tokens=256,
)
print(output["choices"][0]["message"]["content"])
```

## 6. 三种方案对比与选型建议

| 维度 | GPTQ | AWQ | GGUF |
| --- | --- | --- | --- |
| 量化对象 | 权重 | 权重（激活感知） | 权重（多档位） |
| 校准数据 | 需要少量数据 | 需要少量数据 | 不需要 |
| 主要运行环境 | NVIDIA GPU | NVIDIA GPU | CPU/GPU/Apple Silicon |
| 量化速度 | 较慢 | 较快 | 转换+量化，速度中等 |
| 4-bit 效果 | 好 | 通常略优于 GPTQ | 取决于档位，Q4_K_M 接近 |
| 生态与兼容性 | Hugging Face、ExLlama、vLLM、TensorRT-LLM | Hugging Face、vLLM、TensorRT-LLM | llama.cpp、Ollama、LM Studio 等 |
| 典型文件大小（7B） | ~4GB | ~4GB | ~4GB |

选型建议：

- **有 NVIDIA GPU，且追求 GPU 推理速度**：优先选择 GPTQ 或 AWQ，配合 vLLM 或 TensorRT-LLM 可以获得很高吞吐。
- **主要使用消费级显卡，希望兼顾质量与部署简洁性**：AWQ 通常是更好的默认选择，量化快、效果稳。
- **没有独显、显存不足、需要在 Mac 或 CPU 上运行**：选择 GGUF + llama.cpp，利用分层卸载实现混合推理。
- **需要多平台分发、一个文件到处跑**：GGUF 的单文件特性最方便，也最受 Ollama、LM Studio 等工具支持。

## 7. 常见问题与优化实践

### 7.1 量化后模型“变笨”怎么办

- 优先检查量化位宽：4-bit 通常是安全线，低于 4-bit 建议先做任务评测。
- 调整 group size：128 是主流选择；从 128 改为 64 会提升精度，但体积和计算开销也会增加。
- 使用更贴合业务场景的校准数据，避免用单一领域文本校准通用模型。
- 对关键生成任务，可以在量化后做少量 LoRA 微调来修复质量损失。

### 7.2 显存仍然不够用

- 使用 GGUF 的 `-ngl` 参数逐步降低 GPU 卸载层数。
- 开启 flash attention 减少上下文缓存占用。
- 减小上下文长度 `n_ctx`、批量大小和 KV cache 精度。

### 7.3 量化模型与 vLLM 结合

GPTQ 和 AWQ 量化模型可以直接用 vLLM 部署，示例：

```bash
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
    --quantization awq \
    --max-model-len 4096
```

服务启动后即可通过 OpenAI 兼容接口调用，适合生产环境的在线推理。

## 8. 总结

- **GPTQ** 是成熟稳定的训练后量化方案，基于二阶信息逐层补偿误差，适合 NVIDIA GPU 场景，生态完善。
- **AWQ** 通过激活感知找出重要权重通道并做缩放保护，量化速度快、4-bit 效果通常更好，是 GPU 场景下的高性价比选择。
- **GGUF** 是跨平台单文件格式，配合 llama.cpp 实现 CPU/GPU 分层混合推理，特别适合显存有限、需要多端运行的场景。

在实际选型时，建议结合自己的硬件环境、部署框架和对推理吞吐的要求来决策：GPU 生产部署优先 AWQ/GPTQ + vLLM，消费级或多端适配优先 GGUF + llama.cpp。必要时可以对同一基座模型分别量化，在目标任务上做横向评测，用数据决定最终方案。

随着大语言模型参数规模从 7B 一路增长到 70B、405B 甚至更大，显存和推理成本成为落地部署的最大瓶颈。以 FP16 精度为例，一个 7B 模型仅权重就需要约 14GB 显存，70B 模型则超过 140GB，普通消费级显卡根本无法加载。

LLM 量化技术详解：GPTQ、AWQ 与 GGUF 的选型与实践

人工智能

编程语言

架构设计

大模型量化技术通过将权重压缩至4-bit，有效解决显存瓶颈与推理成本问题。本文深入解析GPTQ、AWQ和GGUF三种主流方案：GPTQ基于二阶信息补偿误差，适合GPU部署；AWQ通过激活感知保护重要权重通道，量化速度更快、效果更优；GGUF支持CPU/GPU混合推理，适配多端场景。提供AutoGPTQ、AutoAWQ及llama.cpp实践代码，并给出硬件选型建议与优化策略。

代码解释

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

大模型量化技术通过将权重压缩至4-bit，有效解决显存瓶颈与推理成本问题。本文深入解析GPTQ、AWQ和GGUF三种主流方案：GPTQ基于二阶信息补偿误差，适合GPU部署；AWQ通过激活感知保护重要权重通道，量化速度更快、效果更优；GGUF支持CPU/GPU混合推理，适配多端场景。提供AutoGPTQ、AutoAWQ及...

LLM 量化技术详解：GPTQ、AWQ 与 GGUF 的选型与实践-腾讯云开发者社区-腾讯云

LLM 量化技术详解：GPTQ、AWQ 与 GGUF 的选型与实践

LLM 量化技术详解：GPTQ、AWQ 与 GGUF 的选型与实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐