大模型量化怎么选：看懂 GGUF、AWQ、GPTQ 与 FP8

Q: 同样标称四位，Q4_K_S 与 Q4_K_M 有什么区别？

它们是 llama.cpp 在 Q4K 家族中提供的不同预设。中等预设会为选定的张量分配更高精度，较小预设则采用另一套分配方式。具体选择哪些张量，可能随模型架构变化，因此应检查实际模型文件，不要假定两者大小相同。

Q: GGUF 是一种量化方法吗？

不是。GGUF 是保存张量和元数据的文件容器，可以承载不同的数值精度。Q4KM 或 Q80 才是这个容器生态中的具体选择。

大模型量化不只是把模型文件变小。本文梳理 GGUF、AWQ、GPTQ 与 FP8 的区别，以 Qwen2.5-7B-Instruct 演示权重内存计算，说明 KV 缓存、上下文和并发为何仍需单独预算，并按 llama.cpp、Ollama、vLLM 与托管 API 梳理选择路径，帮助你用实际任务验证速度与质量。

发布于 2026年10月20日

作者 Omid Saffari

Tools

大模型量化能让模型权重显著“瘦身”：以参数规模为 7.61B 的模型为例，理想情况下，权重存储可从 16 位时的 15.22 GB 降到 4 位时的 3.805 GB。具体选什么，先看推理框架：使用 llama.cpp 或 Ollama，可以考虑 GGUF；使用 vLLM，应选择它支持的 AWQ、GPTQ 或 FP8 模型检查点；调用托管 API，则只能在接口提供的精度选项中选择。

在能承载实际工作负载、并通过自身质量检查的前提下，优先选择最高精度。 下载文件变小，只有在模型仍能正确作答、又能为对话留足内存时才有意义。

本文的文档说明与兼容性结论，已于 2026 年 10 月 20 日对照各项目当时的在线页面核实。文中的内存数据根据 Qwen2.5-7B-Instruct 公布的参数量计算得出，并非 GPU 占用实测或性能基准测试结果。

大模型量化是什么？降低数值精度，保留模型结构

量化，就是用更少的位数存储模型学到的数值。 大语言模型（LLM）依靠训练得到的数值参数生成文本，这些参数称为权重。降低精度可以减少权重的存储和数据搬运开销，同时也会引入近似误差。Hugging Face 的量化概览解释了这种内存占用与准确性之间的权衡。

可以把模型想成一份尺寸标得十分精细的建筑图纸。给尺寸数值取近似值，记录会更简洁，但部分数值也会略有偏差，建筑中的房间却还是那些房间。同样，常见的权重量化不会减少大模型的层数，也不会削减训练得到的参数数量；它改变的是权重数值的表示精度。

这个比喻也有边界：量化并不是简单删掉小数位。实际做法可以是将数值分组、设置缩放因子，再映射到规模更小的可表示数值集合。运行时需要计算时，会借助缩放因子还原出近似值。重要的部分还可以保留更高精度。IBM 对量化的说明介绍了这些映射关系及其产生的误差。

下载模型之前，先分清三类数据：

权重： 随模型保存、由训练得到的数值。
激活值： 处理输入时产生的中间数值。
KV 缓存： 保存已处理上下文的注意力相关数据；对话越长，占用的额外内存也越多。

仅权重量化缩减的是第一类数据，并不会自动压缩另外两类。这也解释了为什么模型能够成功加载，却可能在处理长请求时耗尽内存。Ollama 的内存与缓存文档也将上下文容量与缓存精度分开讨论。

训练后量化与量化感知训练，有什么区别？

对下载模型用于开发的人来说，通常应从训练后量化开始了解。 训练后量化（PTQ）将已完成训练的检查点转换为量化版本。部分方法需要校准数据，也就是具有代表性的输入，用来帮助确定如何近似表示权重。量化感知训练（QAT）则在训练或微调过程中就考虑低精度带来的影响。IBM 对这两种方法均有介绍。

使用别人发布的量化检查点，并不需要自己训练模型。但你需要知道它来自哪个原始模型、采用什么量化方案，以及哪个推理框架能够加载它。仅凭文件名，无法可靠地判断这些信息。

GGUF、AWQ、GPTQ、FP8，分别适合什么推理框架？

这些名称对应系统中的不同层次，不能当成同一类选项直接互换。 GGUF 是文件容器，AWQ 和 GPTQ 是量化方法，FP8 是数值格式。检查点则是保存下来的模型文件，其中既有权重，也有加载这些权重所需的信息。

Hugging Face 既是模型托管平台，也是 Transformers 的开发者，其文档介绍了文件格式和加载方法。下表结合这些文档与各推理框架的官方说明，帮助判断选型方向；表中列出某条路径，并不意味着所有模型架构都能使用它。

常见名称	它指的是什么	可以考虑的推理框架	主要限制
GGUF：Q4_K_M、Q5_K_M、Q6_K、Q8_0	保存张量、元数据及所选量化方案的文件容器	llama.cpp；Ollama 的 GGUF 导入功能	模型架构与张量类型必须与推理框架兼容。GGUF 文档、llama.cpp
AWQ，通常为 4 位	激活感知权重量化，利用激活信息指导权重的近似表示	vLLM；兼容的 Hugging Face Transformers 加载器	检查点的数据布局必须与硬件计算内核匹配。Hugging Face AWQ、vLLM AWQ
GPTQ，常见为 4 位或 8 位	通过最小化重建误差来量化权重的训练后量化方法	vLLM；搭配 GPTQModel 的 Transformers	检查导出格式与计算内核的兼容性。vLLM GPTQModel、Hugging Face GPTQ
FP8	八位浮点存储或计算格式	支持相应检查点与后端的 vLLM	原生 FP8 计算与仅权重采用 FP8，是不同的执行路径。vLLM FP8
INT8 / LLM.int8()；4 位 NF4 或 FP4	bitsandbytes 库提供的量化方案	搭配 bitsandbytes 的 Hugging Face Transformers	存储精度、计算类型与设备支持，需要分别选择。bitsandbytes 文档
FP16 / BF16	两种不同的 16 位浮点格式，可作为较高精度的对照基准	兼容的模型加载器，包括受支持的 GGUF 导出版本	权重体积更大；数据类型仍须适配硬件。Hugging Face 概览

Hugging Face 的 GGUF 文档，展示文件容器与张量元数据。 — Hugging Face：检查文件容器及其中的张量

仅凭 .safetensors 扩展名，同样无法判断精度。 它只说明张量采用哪种存储格式。要确定张量如何表示、应该使用哪个加载器，需要阅读检查点的量化配置和模型卡。Hugging Face 的 GGUF 文档区分了容器元数据与张量数据，AWQ 指南则展示了相关的 quantization_config 字段。

Q4_K_M 到底是什么意思？

Q4_K_M 应理解为一种混合精度预设，而不是“每个参数恰好占四位”的保证。 Q4 表示标称四位量化家族，K 表示 K-quant 分块方案，M 表示中等预设。根据模型架构和量化工具的规则，部分张量可能采用更高精度。llama.cpp 的量化实现明确规定了这些选择。

即使是普通的 Q4_K 数据块，也需要额外的记录信息：项目的张量编码表指出，计入缩放因子与最小值信息后，每个权重占 4.5 位。这是数据块层面的数值，并非每个 Q4_K_M 模型的平均位宽。

对于资源有限的本地设备，Q4_K_M 是值得测试的起点。如果更高精度的版本也能容纳目标上下文，不妨一起比较。不要仅仅因为有更小的文件，就牺牲回答质量。

大模型内存怎么算？以 Qwen2.5-7B-Instruct 为例

先按总参数量计算权重，再加上运行模型所需的内存。 这里以 Qwen 的指令微调模型 Qwen2.5-7B-Instruct 为例，它的参数总量为 7.61B。模型卡另列了 6.53B 的非嵌入参数；如果用这个较小的数值计算，就会漏掉一部分需要存储的模型参数。参见 Qwen 模型卡。

理想情况下，计算公式为：

权重字节数 ≈ 参数量 × 每个参数的位数 ÷ 8

采用 16 位精度时，计算为 7,610,000,000 × 16 ÷ 8 = 15,220,000,000 bytes。其他精度同理：

假设的存储精度	计算过程	十进制 GB	二进制 GiB
16 位	7.61B × 2 字节	15.22 GB	14.17 GiB
8 位	7.61B × 1 字节	7.61 GB	7.09 GiB
4 位	7.61B × 0.5 字节	3.805 GB	3.54 GiB

这些数据是我们根据模型卡中经过舍入的参数量自行计算的结果，假设每个参数都采用表中所列位宽。十进制 GB 等于字节数除以 1,000,000,000；GiB 则等于字节数除以 1,073,741,824。单位不同只会改变显示的数字，不会改变实际内存容量。

表中没有计入量化缩放因子、高精度张量、文件元数据、缓存、激活值、临时工作缓冲区，以及运行时预留的内存。因此，实际下载的 Q4_K_M 文件不会恰好等于理想的四位结果；表中的四位数据，也不能证明模型可以在一张假设的 4 GB 显存 GPU 上运行。

建筑剖面示意图，将存储的权重、不断扩大的 KV 缓存、工作空间与剩余空闲空间分开展示。 — 权重量化释放的是一部分内存预算，更长的上下文则可能占用另一部分。此图为示意，未按比例绘制。

因此，测试本地编程助手时，仅聊几句不足以判断容量是否够用。有效的测试需要包含实际会用到的源代码文件、指令和回答长度。如果部署服务，还要加入并发请求。Ollama 的文档明确说明了并行请求与上下文分配对内存的影响。

上下文内存需要单独计算，具体可阅读 KV 缓存指南。权重量化和缓存量化是两项独立设置；vLLM 也将 KV 缓存量化作为单独的功能介绍。

先选推理框架，再选量化格式

先确定模型怎么运行，再看精度标签。 兼容性是前提。在满足兼容性的基础上，再根据可用内存、回答质量，以及实际工作负载下测得的延迟做选择。

llama.cpp：先找到兼容的 GGUF

如果希望直接控制模型文件与设备分配，本地推理引擎 llama.cpp 是使用 GGUF 的直接路径。 项目文档列出了 CPU 运行、Apple silicon 支持，以及 CPU/GPU 混合运行能力。当独立显卡装不下全部模型权重时，这些能力很有用。参见 llama.cpp 项目文档。

它的限制在于：能成功加载，不等于速度足够实用。将模型分配到 CPU 和 GPU，会改变运行条件；你仍需用实际提示词和回答进行测量。选择顺序应是先定模型架构，再找兼容的 GGUF，最后选量化预设。

llama.cpp 项目关于受支持设备与本地推理的官方文档。 — llama.cpp：选择量化版本前，先核对模型与后端

可以先用本站的本地大模型推荐指南缩小基础模型的选择范围。如果某个模型在较高精度下就不擅长你的任务，量化也不会让它突然胜任。

Ollama：先准备好量化文件，再导入

本地模型运行工具 Ollama 可以导入已经准备好的 GGUF，但导入本身不会执行量化。 其当前导入指南要求先准备好量化文件。如果你以为导入命令会自动把较高精度的模型转换成 Q4_K_M，这一点尤其需要注意。参见 Ollama 导入文档。

安装 Ollama，并将兼容且已量化的文件以 model.gguf 为名保存到当前目录后，按文档流程执行：

Bash

printf 'FROM ./model.gguf\n' > Modelfile
ollama create quant-check
ollama run quant-check

在另一个终端运行 ollama ps，可以查看已加载模型在 CPU/GPU 上的分配情况。这只能确认模型如何加载，不能代替质量测试。参见 Ollama 常见问题。

Ollama 官方文档，介绍如何通过 Modelfile 导入已准备好的 GGUF 模型。 — Ollama：导入 GGUF 会保留文件已有的量化方案

Ollama 仍然受实际工作负载的内存需求约束。模型命令再方便，也无法省去上下文与并发所需的容量预算。Ollama 与 llama.cpp 对比会帮助你判断，需要对模型文件和运行过程掌握多大程度的控制权。

vLLM：检查点、计算内核与 GPU 必须匹配

推理与模型服务引擎 vLLM 需要量化检查点与受支持的执行路径匹配。 先从模型发布方支持的 AWQ、GPTQ 或 FP8 文件入手，再对照 vLLM 硬件兼容性表检查 GPU。这里的计算内核，指的是让某种格式能够在相应硬件上高效运行的底层计算实现。

如果现在要制作新的 AWQ 量化模型，当前文档推荐使用 LLM Compressor。AutoAWQ 已弃用，但 AWQ 这套方法及其检查点并没有因此消失。在 Transformers 中使用 GPTQ，目前持续维护的后端是 GPTQModel；具体兼容性还可能取决于检查点的设置。参见 vLLM AWQ 指南与 Hugging Face GPTQ 指南。

FP8 还需要进一步区分：W8A8 表示权重和激活值都采用八位，W8A16 则表示权重为八位、激活值为十六位。vLLM 文档列明，NVIDIA Ada、Hopper 和 Blackwell 支持原生 FP8 W8A8；Turing 和 Ampere 则可以通过 Marlin 使用仅量化权重的 W8A16 路径。因此，看到“支持 FP8”，还不能确定实际会采用哪种计算路径。参见 vLLM FP8 文档。

vLLM 官方量化文档与硬件兼容性表。 — vLLM：是否支持，取决于具体的量化实现与硬件

不要因为 GGUF 在本地能用，就把它作为 vLLM 部署的默认格式。 当前文档要求通过 vllm-gguf-plugin 使用 GGUF，仍将其标为实验性、优化不足，并提示可能存在功能兼容问题。这是迁移时需要考虑的限制，不能据此认定 GGUF 本身更差。参见 vLLM GGUF 文档。

托管 API：接口提供什么，才能选择什么

如果托管 API 没有开放精度设置，你就没有可自行选择的本地量化选项。 先读接口说明。如果它提供明确标注精度的版本，就评估所选版本；如果没有，就直接评估服务输出和延迟，不要猜测其内部数值表示。

不同服务商即使用着同一个模型名称，也不能据此认定它们采用相同的量化方案、推理框架，或会给出相同结果。只有应用确实需要时，才要求对方提供明确的检查点说明或精度保证。如果选择自行上传并托管权重，那是另一种部署方式，需要重新考虑推理框架与硬件兼容性。

建筑风格的决策路径图：本地使用指向 GGUF，服务端在检查 GPU 后选择 AWQ、GPTQ 或 FP8，托管服务则按 API 提供的选项选择。 — 先定推理框架，再查硬件，最后选量化方案。

量化省了什么，又需要付出什么？内存、速度与质量的权衡

表示数值所需的空间变小，确实能节省内存；速度和质量则需要单独验证。 内存中保存的数据减少，可以降低权重搬运的开销。但运行时也可能需要先解包或转换这些数值，再进行计算。Hugging Face 的 GPTQ 文档介绍了融合计算内核如何还原低位宽权重用于计算，而不必在 GPU 全局内存中展开整个模型。

这既解释了量化的优势，也说明了它的边界。合适的计算内核能发挥紧凑权重的价值，不合适的执行路径则可能抵消收益。应在目标并发量下测量首 token 延迟、生成速度和吞吐量，不要把文件大小当作速度测试结果。

质量也取决于具体任务。编程助手要看提出的修改能否通过相关测试；文档抽取要检查必需字段，以及结构化输出是否有效；多语言助手则应覆盖实际服务的语言。回答读起来流畅，不足以证明量化保留了任务所需的表现。

有意义的比较，应针对同一个原始检查点，使用相同的提示词、聊天模板和生成设置，对比其较高精度版本与候选量化版本。如果同时换了不相关的模型，就无法单独判断量化究竟带来了什么变化。

哪些情况下不必量化？常见说法有哪些误区？

如果较高精度已经能装得下，而量化版本又没有带来可测量的运行收益，就保留较高精度。 多做一份压缩版本，就多一份需要管理的模型文件，也多一种需要验证的行为。压缩应该解决实际存在的问题。

如果低精度版本无法通过重要任务检查、推理框架对其执行路径支持不佳，或者长上下文工作负载仍然超出内存，就不要采用它。对于最后一种情况，应先检查上下文和并发配置，而不是反复压缩权重。

也不要把面向推理的量化文件当成通用训练检查点。Bitsandbytes 文档说明，低位宽训练支持的是新增参数，例如适配器权重。这对应特定的微调流程，并不意味着下载的任何量化模型都能进行常规的全参数训练。参见 Hugging Face bitsandbytes 文档。

下面这些说法都夸大或简化了量化的效果：

“四位量化意味着整个应用只用四分之一的内存。” 这只是四位相对于十六位的理想权重位宽比例，运行时内存还包含其他部分。
“八位就是一种格式。” FP8、INT8 和 Q8_0 对应不同的数值表示和执行路径。
“位数越低，速度一定越快。” 节省内存能否转化为延迟或吞吐量改善，要看检查点、计算内核、硬件与工作负载。
“量化后的大模型一定胜过高精度的小模型。” 单凭参数量和位宽，无法判断任务质量。如果两个候选都装得下，就都测一遍。

寻找编程用途的候选模型时，可以先看适合本地编程的 AI 模型指南，再用实际要完成的工作，对比所选检查点的不同量化版本。

大模型量化怎么落地？从一个可复现的评估开始

先选一个受支持的模型文件，再做小规模、可重复的评估。 在弄清精度的影响之前，保持原始模型不变。

记录部署条件
写下推理框架、模型架构、可用内存、目标上下文长度与同时处理的请求量。下载不同版本之前，先根据推理框架文档确定兼容格式。
建立对照基准
条件允许时，使用原始的较高精度检查点作为对照，即使只是临时借助另一台合适的设备运行。如果做不到，就记录这一限制，并根据已知正确的任务结果评估候选版本，不要宣称两者表现等同。
用真实需要的工作负载比较
保持设置一致，运行有代表性的编程、信息抽取或助手请求，覆盖长输入和目标并发量。分别记录正确性、峰值内存与延迟。
在满足目标的前提下，尽量少压缩
如果较高精度能装得下，性能也可接受，就保留它。如果量化版本通过了检查，又解决了内存限制，就将检查点的确切修订版本、量化方案和运行配置随部署一并保存。