# 模型量化完全指南：GGUF、GPTQ、AWQ 怎么选

> 同一份权重，为什么发布页上挂着一串 Q4_K_M、Q8_0、AWQ 后缀？4bit 省下的是什么、丢掉的又是什么？前几篇里这些词反复出现，这一篇集中说清：量化的本质（显存为什么能除以二、除以四）、GGUF / GPTQ / AWQ 三套体系各自的适用范围，以及选档位的真实标准——不是"谁压得最狠"，而是"你的显存配哪一档最划算"。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-12801654/73bd200e78be53fdc5e6265c49fe28de.png)


## 一、为什么需要它

**量化的本质只有一句话：把每个参数的存储精度调低，用一点精度换一大截显存。** 模型权重默认用 fp16/bf16 存，每参数 2 字节；量化到 int8 就是 1 字节（显存 ÷2），量化到 int4 就是 0.5 字节（显存 ÷4）。按《AI-05 显存计算与模型选择》的统一标准，7B 模型：**fp16 权重约 14-15 GB → int8 约 7-8 GB → int4 约 4-5 GB**——除以 2、再除以 4，就这么来的。

为什么这是必学内容？因为**显存是本地部署第一瓶颈**：8 GB 的卡想跑 7B，fp16 根本装不下，4bit 才能舒适；24 GB 的卡想上 32B，也只有 Q4（约 20 GB 级）够得着；48 GB 专业卡才轮到 70B int4（约 40 GB+）。"模型量化""4bit 量化""AWQ 是什么"长期是本地部署的高搜索词，本质都是同一个问题：**我的卡，配哪一档量化更划算？**

还要建立预期：量化不是免费的。**位宽越低，丢的信息越多**——Q8 接近无损，Q4 是"大多数人日常问答感觉不出差距"的甜点，Q2/Q3 则会明显掉智商（输出重复、变笨、逻辑断裂）。所以本篇的结论不是"越省越好"，而是**按场景和显存选对档**：个人本地用 GGUF Q4_K_M，高并发服务用 AWQ/GPTQ 4bit，PyTorch 里做实验用 bitsandbytes 动态 4bit。

还要补一个实际跑起来才会注意到的细节：量化省的**不只是权重显存**。生成时模型还维护着 KV Cache（已生成 token 的注意力缓存），它随上下文长度和并发增长；量化模型会把它一起压缩，整体占用更小（量级参考见《AI-05》）。这就是为什么 Q4 的 7B 在 8 GB 卡上开 4K 上下文还能留出并发余量，而 fp16 连加载都做不到——位宽降一档，权重和缓存同时变轻，余量是双重增加的。

## 二、环境要求

| 路线 | 环境要求 | 说明 |
|------|---------|------|
| GGUF（Ollama / llama.cpp / LM Studio） | N 卡可选，纯 CPU 也能跑 | 装 Ollama 或下 llama.cpp 即可（《AI-07》《AI-12》），门槛最低 |
| AWQ / GPTQ（vLLM 服务） | N 卡 + CUDA + Python 3.9-3.12 | `pip install vllm`（《AI-13》），模型需先下好量化版 |
| GPTQ（transformers + AutoGPTQ） | N 卡 + CUDA + PyTorch | PyTorch 装对应 cuXXX 版 wheel（《AI-02》） |
| bitsandbytes（PyTorch 实验） | N 卡 + PyTorch | `pip install bitsandbytes`，4bit 对 N 卡支持好 |

三条路线的模型都来自 HuggingFace（或镜像）：**国内必配 `HF_ENDPOINT=https://hf-mirror.com` 或 ModelScope**，下载细节见《AI-06 模型下载全攻略》。模型一律放非 C 盘，7B 级 Q4 约 4-5 GB、Q8 约 7-8 GB、fp16 约 14-15 GB。

## 三、安装与部署：三大体系各走各的路

### 3.1 GGUF 路线（Ollama / llama.cpp，K-quant 家族）

GGUF 是 llama.cpp 系的统一文件格式：量化权重 + 模型配置打进一个 `.gguf` 单文件，CPU/GPU 混合推理友好，Ollama、LM Studio、llama.cpp 三家通用（结构详解见《AI-12 llama.cpp与GGUF格式》）。它的量化档属于 **K-quant 家族**：`Q2_K / Q3_K_M / Q4_K_M / Q5_K_M / Q6_K / Q8_0`，其中 **Q4_K_M 是"精度-体积"甜点，默认推荐**。

Ollama 拉取（默认档通常就是 Q4_K_M，带后缀可指定档，具体可用档以 ollama.com/library 页面为准）：

```
ollama pull qwen2.5:7b
ollama pull qwen2.5:14b-instruct-q4_K_M
```

想自己量化（从已有权重生成目标档 `.gguf`），用 llama.cpp 仓库自带的 `llama-quantize`，`Q4_K_M` 为默认推荐档，按显存余量再选更高/更低档。

### 3.2 AWQ 路线（vLLM 服务首选）

AWQ（Activation-aware Weight Quantization，激活感知）常见 **4bit**：量化时参考激活分布，**保住对激活重要的权重**，同样的 4bit 掉得更少，推理快、服务吞吐高——这是它成为 vLLM 服务场景主流 4bit 选择的原因。做法：从 HF（或镜像）下载目标模型的 AWQ 版本，用 vLLM 起服务（命令见《AI-13 vLLM高吞吐推理引擎》）：

```
vllm serve D:\models\qwen2.5-7b-awq --port 8000 --max-model-len 8192 --quantization awq
```

4bit 权重体积与 Q4 同档（7B 约 4-5 GB），显存预算照《AI-13》第六节口径算。

### 3.3 GPTQ 路线（transformers + AutoGPTQ）

GPTQ 常见 **4bit / 8bit**，属于 HF/PyTorch 生态：用 AutoGPTQ 量化的权重可直接被 transformers 加载，**vLLM 也支持 GPTQ 量化模型**（加载时的量化参数名以 `vllm serve --help` / 官方文档为准）。8bit 档权重体积 ≈ int8（7-8 GB），4bit 档 ≈ int4（4-5 GB）。如果你的服务栈已经围绕 transformers 搭建、或需要 GPTQ 现成的量化权重，走这条路；**纯追求服务吞吐时，AWQ + vLLM 通常是更省心的组合**。

### 3.4 bitsandbytes 路线（PyTorch 里动态量化）

bitsandbytes 是 PyTorch 生态的**动态 4bit/8bit** 方案：不用提前量化权重文件，加载时一个参数就压下去，很适合"想在 PyTorch 代码里快速跑起来试试"的实验场景：

```
pip install bitsandbytes -i https://pypi.tuna.tsinghua.edu.cn/simple
```

```python
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct")
model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-7B-Instruct",
    load_in_4bit=True,   # bitsandbytes 动态 4bit
)
```

8bit 同理换一个参数（参数名以官方文档为准）。注意：bitsandbytes 4bit 对 N 卡支持较好，且它解决的是"实验时显存装不下"，不是服务吞吐——要对外提供服务还是回到 3.1/3.2/3.3。
## 四、验证：三步确认量化生效、质量没掉

1. **显存对账（关键）**：`nvidia-smi` 看模型显存占用。7B 级：Q4 档权重约 4-5 GB、Q8 档约 7-8 GB、fp16 约 14-15 GB（均为权重量级，KV Cache 另计）。量化的账一眼就能对上：如果选了 4bit 却看到 14 GB 级的权重占用，说明量化根本没生效，大概率还是 fp16 在跑。
2. **档位确认**：Ollama 用 `ollama list` 看模型名后缀（如 `:7b-q5_K_M`，可用后缀以 ollama.com/library 页面为准）；vLLM 看启动日志里识别到的量化方式（应显示你传入的 `--quantization` 对应的格式）；bitsandbytes 用 `model.is_loaded_in_4bit` 之类的属性查看（具体属性以官方文档当前版本为准）。
3. **质量对比**：准备 5-10 个固定问题（中文常识、简单推理、代码各几个），量化版与未量化（或 Q8）版各跑一遍人工对比。**通顺、要点齐全、无重复循环 = 通过**；出现第五节说的三类信号就降档处理。

一个实测心得：Ollama 默认拉的多是 Q4_K_M，很多人第一次跑本地模型就是这档；而 vLLM 直接加载 HF 原始仓库时默认是 fp16，不显式换量化权重，24 GB 卡跑 7B 会白白浪费一半以上显存给权重——量化不是"锦上添花"，是"决定装不装得下"的第一道开关。

## 五、进阶技巧

### 5.1 量化输出的退化识别（三大信号）

模型加载成功不等于量化档位合适——量化过低的典型症状是**输出质量退化**，而不是报错。三个识别信号：

1. **重复循环**：同一句话反复输出、不推进、停不下来——这是位宽过低的典型信号；
2. **乱码 / 中英混杂**：输出无意义字符、中英文乱搅、格式全乱——除了位宽过低，还要重点怀疑**权重与 tokenizer 不同源**（两个来自不同 repo 的组件混用）；
3. **逻辑断裂 / 答非所问**：短问题还能答，长推理中途跑偏、前后矛盾——Q4 边缘或上下文过长时常见。

我的实测经验：Q2_K 档的 7B 模型回答"介绍一下量子计算"会连续复读同一段话；换成 Q4_K_M 后立刻正常，显存也只多 1 GB 出头。这种"同题 A/B 对比"比看任何 benchmark 数字都直接，也是定位"位宽问题"还是"组件混用问题"的直接办法：重复循环先升位宽，乱码先查 repo 配套。

### 5.2 场景选型对照（与配图一致）

| 场景 | 推荐格式 | 推荐档位 | 说明 |
|------|---------|---------|------|
| 本地 Ollama 日常问答 | GGUF | Q4_K_M（默认甜点） | 显存富裕升 Q5_K_M / Q6_K（《AI-07》《AI-12》） |
| 质量优先、显存 ≥ 16 GB | GGUF | Q8_0 | 近无损，体积约为 Q4 两倍 |
| vLLM 多用户服务 | AWQ（首选）/ GPTQ | 4bit | 推理快、vLLM 原生支持（《AI-13》） |
| PyTorch 实验 / 调试 | GPTQ 8bit 或 bitsandbytes | 8bit / 动态 4bit | 加载即量化，不用手动转换文件 |

选型原则：**先算显存、再选格式、最后调档位**。显存不够时优先降位宽（fp16→Q8→Q4），其次才动上下文长度——上下文是体验，位宽是底线；而 **Q4_K_M 是日常问答的下限**，再往下（Q3 及以下）只适合"24 GB 卡极限塞 70B"这类尝鲜场景，日常用会明显掉智商。

### 5.3 一句话带过 K-quant：Q4_K_M 为什么是甜点

GGUF 用的 K-quant 家族（Q2_K 到 Q8_0）是 llama.cpp 生态当前的主流量化方案：把权重拆成小块、分块量化，量化误差比整层一刀切的旧方式更小，同样 4bit 下日常问答基本可用——这就是"K"档被 Ollama 选作默认档的原因。选型时不用记复杂规则：**日常用 Q4_K_M；显存富余想更稳升 Q5_K_M / Q6_K；质量优先用 Q8_0；Q4 以下（Q2_K/Q3_K_M）只建议"极限塞大模型"尝鲜**，日常用会明显掉智商（量化过程与参数细节见《AI-12》）。

## 六、故障排查（按层定位）

| # | 症状（报错原文） | 层 | 原因 | 解决 |
|---|------------------|----|------|------|
| 1 | 模型加载成功但**输出乱码/重复** | 量化 | 量化位宽过低（Q2/Q3）或 tokenizer 不匹配 | 升量化位宽（Q4_K_M 起）；确认权重与 tokenizer 来自同一 repo |
| 2 | `CUDA error: out of memory` / `torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate ...` | 显存 | 模型/上下文/批太大，量化档没选对 | 降量化位宽（fp16→Q8→Q4）；降上下文长度；`nvidia-smi` 查占用后清进程 |
| 3 | HuggingFace 下载卡住 / ConnectionError / 超时 | 网络 | 国内访问 huggingface.co 受限 | `set HF_ENDPOINT=https://hf-mirror.com`（Win）/ `export HF_ENDPOINT=https://hf-mirror.com`（Linux）；或改 ModelScope（见《AI-06》） |
| 4 | `CUDA driver version is insufficient for CUDA runtime version` | 驱动 | 驱动低于框架所需 CUDA | 升级 NVIDIA 驱动（只升 Toolkit 没用），见《AI-01》 |
| 5 | `ModuleNotFoundError: No module named 'torch'` | 环境 | 激活了错误环境 / 全局 vs venv | `which python` / `where python` 确认解释器；重新 `source .venv/bin/activate` 再跑 |
| 6 | `ImportError: DLL load failed while importing ...`（Windows） | 依赖 | VC 运行库缺失 / 位数不匹配（32/64） | 装 VC++ 2015-2022 Redistributable x64；确保 64 位 Python（bitsandbytes 等 C 扩展库敏感） |
| 7 | Ollama 拉模型中途断（网络抖动） | 网络 | 大文件传输中断 | 重新 `ollama pull`（支持断点续传，继续拉即可，见《AI-07》） |
| 8 | `CUDA error: no kernel image is available for execution on the device` | 框架/CUDA | PyTorch 编译的 CUDA 版本与显卡架构不匹配 | 换与显卡架构匹配的 PyTorch wheel（pytorch.org 选择器），见《AI-02》 |

排错顺序照分层定位法走：先 `nvidia-smi` 确认驱动层，再 `torch.cuda.is_available()` 确认框架层，然后 `nvidia-smi` 看显存占用对不对账（量化显存对不上就按第四节第 1 步查"量化没生效"），最后才看输出质量。

## 七、本篇自检清单

- [ ] 能说出量化本质：每参数字节数降低，显存 ÷2（int8）÷4（int4），7B 权重 fp16 约 14-15 GB → Q8 约 7-8 GB → Q4 约 4-5 GB
- [ ] 能区分三大体系：GGUF（llama.cpp 生态、K-quant、Q4_K_M 甜点）、GPTQ（AutoGPTQ、4/8bit）、AWQ（激活感知 4bit、vLLM 推理快），以及 bitsandbytes 动态量化的适用场景
- [ ] 能背出选型结论：本地 Ollama → GGUF Q4_K_M；vLLM 服务 → AWQ/GPTQ 4bit；PyTorch 实验 → bitsandbytes
- [ ] 会用 `ollama pull`（带档位后缀）、`vllm serve --quantization awq`、`load_in_4bit=True` 三条路线分别把量化模型跑起来
- [ ] 会用 `nvidia-smi` 显存对账，判断"量化是否生效"
- [ ] 能识别量化退化的三大信号（重复循环 / 乱码混杂 / 逻辑断裂）并给出对应解法
- [ ] 遇到 `CUDA out of memory` 知道先降位宽、再降上下文、最后清进程

同一份权重，为什么发布页上挂着一串 Q4_K_M、Q8_0、AWQ 后缀？4bit 省下的是什么、丢掉的又是什么？前几篇里这些词反复出现，这一篇集中说清：量化的本质（显存为什么能除以二、除以四）、GGUF  GPTQ  AWQ 三套体系各自的适用范围，以及选档位的真实标准——不是"谁压得最狠"，而是"你的显存配哪一档最划算"。

模型量化完全指南：GGUF、GPTQ、AWQ 怎么选

人工智能

算法

开发工具

模型量化通过降低权重存储精度，实现显存减半或减四分之一，是本地部署核心。7B模型fp16需14-15GB，Q4仅4-5GB。GGUF适合本地CPU/N卡（Q4_K_M为甜点），AWQ/GPTQ适用于vLLM高并发服务，bitsandbytes便于PyTorch实验。选型依据显存与场景，Q4_K_M是日常问答性价比之选，Q8近无损但体积翻倍。量化省显存同时降低KVCache占用，需通过nvidia-smi验证生效，并识别重复、乱码等退化信号。

量子计算

文件传输

代码解释

解释器

Windows

Python

Linux

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

模型量化通过降低权重存储精度，实现显存减半或减四分之一，是本地部署核心。7B模型fp16需14-15GB，Q4仅4-5GB。GGUF适合本地CPU/N卡（Q4_K_M为甜点），AWQ/GPTQ适用于vLLM高并发服务，bitsandbytes便于PyTorch实验。选型依据显存与场景，Q4_K_M是日常问答性价比之选，...

模型量化完全指南：GGUF、GPTQ、AWQ 怎么选-腾讯云开发者社区-腾讯云

模型量化完全指南：GGUF、GPTQ、AWQ 怎么选

模型量化完全指南：GGUF、GPTQ、AWQ 怎么选

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐