模型量化教程：INT8、INT4、GPTQ、AWQ、GGUF、FP8和质量评估
摘要
模型量化不是把权重文件压小的后处理步骤，而是一次改变数值表达、推理内核、显存结构和业务质量边界的系统改造。INT8、INT4、GPTQ、AWQ、GGUF 和 FP8 的差异，只有放在硬件、推理引擎、校准数据、KV Cache、长上下文、工具调用和上线评测中才有意义。本文把量化视为“资源收益与能力退化”的联合优化问题：显存下降、吞吐提升和成本降低必须与格式稳定性、引用正确率、结构化输出、拒答边界和高风险动作质量一起评估。
关键词
模型量化；INT8；INT4；GPTQ；AWQ；GGUF；FP8；KV Cache；质量评估；推理优化
研究问题与方法
本文讨论三个问题：量化到底改变了权重、激活还是 KV Cache；低比特格式在什么条件下带来真实吞吐收益，而不只是文件变小；生产系统怎样判断量化退化是否可接受。方法上，文章把量化流程拆成候选生成、校准、离线质量回放、性能压测、灰度监控和版本治理，并以同一批业务样本比较标准精度、INT8/FP8 和 INT4 候选，避免靠少量聊天样例做结论。
下图把量化放回上线决策链路。图中的关键点是：量化候选不能直接进入生产，必须同时通过质量门、性能门和风险门。
量化后的部署判断可以抽象为一个门槛函数：
这里 表示相对标准精度模型的业务质量下降， 表示线上高分位延迟， 表示峰值显存， 表示格式错误、工具误调、安全拒答失效等风险。只要其中一项不满足，量化就不能靠“省显存”单独成立。
| 量化路线 | 主要收益 | 主要风险 | 适合的验收重点 |
|---|---|---|---|
| INT8 / FP8 | 显存下降、吞吐改善、质量退化较小 | 硬件和 kernel 支持差异会影响收益 | 与标准精度模型对比 p95 延迟、格式成功率、引用正确率 |
| INT4 / GPTQ / AWQ | 单卡部署能力明显提高，权重常驻显存显著下降 | 专业任务、长上下文和工具参数更容易出现边界退化 | 长文档、JSON、函数调用、拒答边界和业务样本回放 |
| GGUF 本地量化 | 分发简单，适合桌面、边缘和离线助手 | 机器差异大，速度与质量受格式和后端影响 | 本地启动时间、上下文长度、中文问答和用户硬件分层 |
| KV Cache 量化 | 长上下文和高并发显存压力下降 | 注意力缓存误差可能影响长距离引用 | 长上下文定位、引用稳定性、并发下 TTFT 和 p99 |
写作日期：2026-05-22
大模型量化的目标很朴素：用更少显存、更少内存带宽和更低部署成本，保留尽可能多的模型能力。一个七十亿参数模型用 FP16 或 BF16 权重加载时，单是权重就需要十几 GB 显存；三百亿、七百亿甚至更大的模型，会把显卡、内存、磁盘和推理引擎一起推到边界。量化把权重、激活或 KV Cache 从高精度表示压到 INT8、INT4、FP8 等低精度表示，让同一台机器能运行更大的模型，或者让同一个模型在更高并发下服务更多用户。
但量化不是无损压缩，也不是把模型文件变小就结束。它改变了模型里的数值表达方式，可能影响困惑度、指令遵循、中文理解、数学计算、代码生成、函数调用、JSON 格式、长上下文定位、拒答边界和专业术语稳定性。很多量化模型在闲聊里看起来没有问题，一进入业务问答、结构化抽取、工具调用和长文档总结，就会暴露出数字错误、引用漂移、重复输出、格式损坏或边界判断变差。生产级量化必须同时看三件事：省了多少资源，快了多少，损失了什么能力。
这篇教程系统讲清楚模型量化的核心概念、常见精度格式、INT8 和 INT4 的取舍、GPTQ 和 AWQ 的思路、GGUF 在本地推理中的位置、FP8 在现代 GPU 上的价值，以及怎样做质量评估。读者可以把它当作一份落地手册：先理解权重、激活和 KV Cache 的不同，再根据硬件、推理引擎和任务风险选择量化路线，最后用业务样本验证是否真正可用。
引言：量化到底在量化什么
神经网络里的参数和中间结果本质上是数字。训练和推理常见的高精度表示包括 FP32、FP16 和 BF16。FP32 精度高但占用大，训练早期很常见；FP16 和 BF16 每个数约两个字节，是大模型推理和训练中常见的半精度格式。量化就是把这些数映射到更少 bit 的表示里，例如 INT8 每个数约一个字节，INT4 每个数约半个字节，FP8 每个数约一个字节。数值占用变小后，权重文件、显存占用和内存带宽压力都会下降。
最容易理解的是权重量化。模型权重是固定资产，模型加载后长期存在显存或内存里。把权重从 BF16 压到 INT8，理论上权重体积约减半；压到 INT4，理论上约减到四分之一。实际文件大小还要加上 scale、zero point、分组信息、元数据和部分保持高精度的张量，所以不会严格等于理论比例。llama.cpp 的量化工具文档也提醒，量化会缩小模型并可能加速推理，但可能引入准确率损失，常用困惑度和分布差异等指标观察。
第二类是激活量化。激活是推理过程中每一层产生的中间值。只做权重量化时，常见形式是 W8A16 或 W4A16，也就是权重低精度、激活仍用 FP16 或 BF16。这样比较稳，但计算时仍要处理较宽的激活。若进一步做 W8A8 或 FP8 W8A8，权重和激活都低精度，吞吐可能更好，但对硬件、kernel 和量化校准要求更高。SmoothQuant 一类方法就是为权重和激活同时 8bit 化服务，核心是处理激活中的离群值，让 W8A8 更可行。
第三类是 KV Cache 量化。大语言模型自回归生成时，会为历史 token 保存每层注意力的 key 和 value。长上下文和高并发场景下，KV Cache 可能比权重更早成为显存瓶颈。一个模型权重已经 INT4，并不代表长上下文就便宜，因为 KV Cache 可能仍是 FP16 或 BF16。vLLM 等推理引擎提供 FP8 KV Cache 选项，目的就是降低长上下文缓存占用。它和 GPTQ、AWQ 这种权重量化不是一回事。
第四类是训练或微调中的量化。QLoRA、bitsandbytes 4bit、8bit optimizer 等技术常用于低显存微调，它们与纯推理量化有关但不完全相同。微调时还要考虑梯度、优化器状态、可训练适配器和反向传播稳定性。本文重点讨论推理部署中的量化，但读者要记住：能用于推理的量化格式，不一定适合继续训练；能用于低显存微调的量化方案，也不一定是线上推理最快方案。
缩放、分组和离群值：量化误差从哪里来
把高精度浮点数压到低精度整数时，第一步通常是确定一个映射关系。以对称 INT8 为例，可以把一组浮点数除以 scale 后四舍五入到 -127 到 127 的整数区间；推理计算时再用 scale 把结果解释回近似浮点值。非对称量化还会引入 zero point，用来处理数值分布不以零为中心的情况。INT4 也是类似逻辑，只是可用整数级别更少，误差更容易变大。
量化误差来自两个方向。第一，数值级别变少了。原本连续的浮点数被放到有限格子里，格子越稀疏，近似越粗糙。第二，同一组数共享 scale 时，如果这组数里有极端大值，scale 会被大值拉大，普通小值就会被压到很少几个格子里，信息损失明显。大模型里常见激活离群值，这也是为什么激活量化比权重量化更难。
分组量化就是为减少共享 scale 的误差。它不是让整层权重共用一个 scale，而是按通道、按行、按列或按固定 group size 分别计算 scale。group size 越小，局部数值分布越容易被表达，质量通常更好，但 scale 元数据更多，kernel 复杂度也更高。很多 INT4 权重量化会在 group size、速度和质量之间折中，例如 32、64、128 等分组大小在不同框架里都能看到。
是否按通道量化，也会影响质量和速度。per-tensor 量化最简单，但容易被局部异常值拖累；per-channel 或 per-group 更精细，常见于低比特权重量化。KV Cache 量化也有 per-tensor 和 per-head 等策略，vLLM 文档中就区分了不同缩放粒度。粒度越细，质量越容易保住，但实现和运行成本也会上升。
还有一类误差来自反量化和 kernel。低比特权重通常不会直接按普通整数矩阵乘法完成全部计算，而是经过打包、解包、反量化、混合精度计算和融合 kernel。某个格式理论上省显存，不代表在目标硬件上就快。如果 INT4 权重每次计算都要高成本解包，吞吐可能不如 INT8 或 FP16。量化部署必须把格式和推理引擎放在一起看。
因此，量化质量不能只由 bit 数决定。一个经过良好校准、分组合理、kernel 成熟的 INT4 模型，可能比粗糙 INT8 模型更可用；一个在 A100 上跑得很快的格式，换到消费级显卡或 Mac 上可能不再有同样收益。工程判断要看模型结构、任务类型、硬件支持、推理引擎、量化数据和评测结果。
INT8：最常用的稳健压缩入口
INT8 是很多团队第一次尝试量化时的稳健入口。它把每个权重从 FP16/BF16 的 16 bit 降到 8 bit，内存占用约减半，误差相对可控。对分类、摘要、检索增强问答、普通聊天和部分代码任务来说，好的 INT8 量化通常能保留大部分质量。它的好处是硬件和软件支持广，风险比 INT4 小，适合在生产系统里作为第一阶段压缩方案。
INT8 也分很多种。最简单的是权重-only INT8，也就是 W8A16，推理时权重低精度存储，计算中激活保持半精度。这种方案省权重显存，但不一定充分利用 INT8 Tensor Core。更激进的是 W8A8，权重和激活都用 8bit 表示，理论上吞吐更高，但需要处理激活离群值。SmoothQuant 的核心贡献就是把激活里的量化困难部分迁移到权重上，让激活更容易量化，从而服务 W8A8 部署。
对业务系统来说，INT8 的优势不是“压得最小”，而是“容易建立可信基线”。先用标准精度模型跑一套业务评测，再用 INT8 跑同一套样本，观察回答正确率、格式成功率、引用正确率、延迟和显存。如果 INT8 基本无损，就能省掉大量成本。如果 INT8 已经明显影响任务质量，再去尝试 INT4 就要更谨慎。
INT8 常见误区是只看模型能不能加载。模型能加载，不代表 kernel 路径正确，也不代表吞吐提升。某些框架可能用低精度存储，但计算时反量化到半精度，主要收益是显存而不是速度。也有些硬件对 INT8 支持很好，但具体模型结构、batch 形态和序列长度会影响收益。在线服务里还要观察首 token 延迟、输出 token 间隔、吞吐和 p95/p99，而不是只看单次回答速度。
第二个误区是把 INT8 当作所有任务无风险默认值。对闲聊和摘要来说，INT8 常常很稳；对财务数字、数学推理、代码补全、结构化 JSON、函数调用参数、严肃安全拒答来说，仍然需要回放评测。量化误差可能不会让回答整体变差，但会改变边界行为。生产系统关心的经常就是这些边界。
INT4：显存收益大，评估压力也大
INT4 是本地大模型社区和单卡部署里最常见的低比特路线之一。它把权重压到 4 bit，理论上权重体积约为 FP16 的四分之一。很多 7B、8B、14B、32B 模型能否在普通消费级显卡、Mac 或 CPU 内存中流畅运行，往往取决于 INT4 或近似 4bit 格式。llama.cpp 生态中的 Q4_K_M、Q4_K_S、IQ4、Q5、Q6 等格式，本质上都在质量、速度和体积之间做不同折中。
INT4 的吸引力很强，因为它能把“不可能部署”变成“可以试用”。一个标准精度模型需要两张卡，INT4 后可能单卡可跑；一个本地电脑原本只能跑 7B，INT4 后可以跑更大模型；一个在线服务原本只能低并发，权重压缩后可以把更多显存留给 KV Cache。但 INT4 也更容易损伤细节能力，尤其在专业任务、长上下文和结构化输出上。
INT4 常见形式是权重-only，例如 W4A16。这样权重低精度，激活仍用半精度，兼顾显存和稳定性。GPTQ、AWQ、部分 GGUF K-quants 都属于围绕低比特权重压缩的路线。它们不会自动解决 KV Cache 问题，也不等于激活全程 4bit。若有人说“我的模型是 INT4，所以上下文很长也没问题”，要继续追问 KV Cache 用什么精度、最大并发多少、上下文长度多少。
INT4 的质量损失不总是线性的。某些层、某些张量、某些 token embedding 或输出层对量化更敏感。llama.cpp 的量化工具提供保留输出张量、指定 token embedding 类型、使用 importance matrix 等选项，就是承认不同张量敏感度不同。经验上，输出层、注意力关键投影、专家模型路由相关张量、嵌入层和最后几层都可能需要更谨慎处理。
INT4 的评估要更重视业务边界。普通问答十条都对，不代表模型可以上线。要看：是否更容易复读，是否更容易丢失中间证据，是否更容易编造引用，是否更容易输出非法 JSON，是否更容易把工具参数类型弄错，是否在低温设置下仍稳定，是否在中文长句和专业名词里出现明显退化。若系统依赖函数调用和自动化执行，INT4 的格式成功率和参数正确率往往比主观聊天质量更重要。
GPTQ：用近似二阶信息做一次性后训练量化
GPTQ 是大模型低比特量化里影响很大的方法。它的目标是做 post-training quantization，也就是不重新训练完整模型，只用少量校准数据和近似二阶信息，把权重量化到 3bit 或 4bit 等低比特，同时尽量保持输出接近原模型。GPTQ 论文强调它能在较短时间内量化非常大的 GPT 类模型，并在 3/4 bit 权重下保持较小精度损失。
直观理解 GPTQ，可以把它看成“按层处理权重压缩，同时补偿量化误差”。普通 round-to-nearest 只是把权重四舍五入到最近量化格子，GPTQ 会利用校准数据估计权重误差对层输出的影响，并在量化后更新剩余权重的误差补偿。它不需要完整反向训练，但比朴素量化更懂哪些误差会影响输出。
GPTQ 的优势是质量和生态。很多 Hugging Face 模型仓库提供 GPTQ 预量化版本，AutoGPTQ、GPTQModel、Transformers、vLLM、TGI 和其他推理栈都曾围绕它建立支持。对 GPU 推理来说，GPTQ 如果配合成熟 kernel，可以在显存和速度之间取得不错平衡。vLLM 量化文档也把 GPTQ 列为重要路径，并区分不同硬件上的支持状态。
GPTQ 的代价是量化过程相对重，需要校准样本、层级处理和合适配置。校准数据如果和实际业务差别很大，量化后的模型可能在业务任务上退化。比如只用英文 Wiki 校准，却部署中文法律问答；只用短文本校准，却部署长文档总结；只用普通聊天校准，却要求稳定函数调用，这些都可能导致评估结果失真。
GPTQ 还有格式碎片问题。不同发布者的 group size、act-order、desc-act、sym/asym、bits、kernel 适配、模型架构支持可能不同。下载一个“GPTQ 4bit”模型前，要看模型卡里的量化参数和目标推理引擎支持情况。能在某个 WebUI 里跑，不代表能在 vLLM 里以最佳 kernel 跑；能在单卡离线生成，不代表能稳定做高并发服务。
生产上使用 GPTQ 的建议是：优先选择目标引擎明确支持的模型格式；确认 tokenizer、chat template 和原模型一致；不要用未知来源量化模型直接替换生产模型；用标准精度基线和业务评测集对比；特别检查工具调用、结构化输出和长上下文样本。如果质量接近而显存收益明显，GPTQ 是很实用的 4bit 部署路线。
AWQ：关注激活敏感权重的低比特压缩
AWQ 全称 Activation-aware Weight Quantization。它的核心观察是，大模型里并不是所有权重同等重要；少量对激活响应很敏感的权重，对模型输出质量影响更大。AWQ 通过激活分布识别更重要的权重通道，并用缩放等方式保护这些权重，从而在低比特权重量化中保持质量。AWQ 论文和项目都强调它面向 LLM 压缩和加速，并结合硬件友好的权重打包与 kernel。
与 GPTQ 相比，AWQ 常被理解为更关注激活感知和硬件友好。GPTQ 用近似二阶误差补偿来量化权重；AWQ 则强调通过激活统计找出重要权重，并避免直接量化导致这些权重失真。两者都属于后训练量化路线，都常见于 W4A16 低比特权重推理，也都需要校准数据。实际选择时，不要只根据方法名判断优劣，要看目标模型、硬件、推理引擎和业务评测。
AWQ 的优势之一是工程部署广。很多开源模型，特别是 Qwen、Llama、Mistral 等常见模型，有社区或官方 AWQ 版本。Transformers 支持加载 AWQ 模型，vLLM 支持 AWQ 并在硬件兼容表中列出不同平台支持状态。对需要 4bit GPU 推理的团队来说，AWQ 是常见候选项。
AWQ 也不是万能。它通常主要处理权重量化，不自动把激活、KV Cache 和所有中间状态变成 4bit。一个 AWQ 模型在显存上能省权重，但长上下文仍然要算 KV Cache。另一个现实问题是，AWQ 模型在不同 kernel 下速度差异很大。某些引擎会提示 AWQ 支持，但实际吞吐取决于是否走了高效 kernel、batch 形态是否合适、GPU 架构是否匹配。
评估 AWQ 时，重点看两类样本。第一类是语义质量样本：中文问答、专业术语、长文档摘要、推理题、代码任务、事实引用。第二类是操作可靠性样本：JSON schema、函数参数、工具选择、多轮约束、拒答边界。AWQ 在很多主观任务里表现很稳，但生产系统真正担心的是小概率格式崩坏和边界变化。
GPTQ 和 AWQ 之间没有固定答案。若团队已有 vLLM 服务并找到目标模型的高质量 AWQ 版本，可以先测 AWQ；若模型社区 GPTQ 版本更多、kernel 更成熟，也可以先测 GPTQ。判断标准不是名称，而是“同一业务评测集下，哪一个在质量、显存、吞吐、延迟和维护成本上更合适”。
GGUF：本地推理生态里的模型容器和量化载体
GGUF 是 llama.cpp 和 ggml 生态中非常重要的模型文件格式。它不仅保存张量，还保存模型元数据、tokenizer 信息、架构信息和量化类型等内容。对本地用户来说，一个 GGUF 文件经常就是“下载后可以直接跑”的模型包。llama.cpp、Ollama、LM Studio、很多桌面工具和本地推理程序都围绕 GGUF 生态工作。
GGUF 和 GPTQ、AWQ 的位置不同。GPTQ 和 AWQ 更像量化算法或量化路线；GGUF 更像承载模型权重和元数据的文件格式，并支持多种量化类型。一个 GGUF 模型可能是 Q4_K_M、Q5_K_M、Q8_0、IQ4_XS 等格式。用户在模型仓库看到的“GGUF Q4_K_M”，通常说明这个文件可被 llama.cpp 生态加载，并使用某种 llama.cpp 支持的量化类型。
GGUF 的优势是易分发、易本地运行、设备覆盖广。CPU、Metal、CUDA、Vulkan 等后端在不同程度上可用；Mac、Windows、Linux、低成本服务器都能找到对应路径。对个人知识助手、离线工具、隐私敏感小团队、边缘设备和桌面应用来说，GGUF 很实用。它让用户不必搭完整 PyTorch 或 vLLM 服务，也能运行开放权重模型。
GGUF 的量化命名需要理解。Q8_0 通常比 Q4 类质量更稳但体积更大；Q4_K_M 是常见中等 4bit 选择；Q5、Q6 往往在体积增加的同时保留更多质量；IQ 系列追求更低 bit 下的质量折中。具体质量不能只看名称，因为模型架构、量化数据、imatrix、llama.cpp 版本和推理参数都会影响结果。
llama.cpp 的量化工具支持从 F32、BF16 或 FP16 GGUF 转成不同量化类型，并提供 importance matrix 以优化量化质量。importance matrix 可以理解为根据校准数据知道哪些权重更重要，从而在量化时更谨慎。对中文任务而言，若量化模型是别人用英文或通用数据生成的，最好用自己的中文业务样本验证，不能只相信文件名。
GGUF 的局限也明确。它非常适合本地和边缘推理，但如果要做高并发在线服务、复杂多 GPU 调度、统一模型网关、细粒度指标和高吞吐批处理，团队可能更偏向 vLLM、TensorRT-LLM、TGI 或 SGLang 等服务化推理栈。vLLM 也支持 GGUF，但其文档提示 GGUF 支持有特定边界，生产上要验证目标模型和功能。格式选择要服务部署形态，而不是社区流行度。
FP8：不是整数低比特，而是现代 GPU 的低精度浮点路线
FP8 是 8bit 浮点格式，不同于 INT8。NVIDIA Transformer Engine 文档介绍了 H100 支持的 E4M3 和 E5M2 两种 FP8 类型：E4M3 用更多尾数位换取较好精度，动态范围较小；E5M2 用更多指数位换取更大动态范围，精度较低。FP8 保留浮点指数结构，适合在现代 Tensor Core 上做低精度矩阵计算，特别是在 Hopper、Ada、Blackwell 等新硬件上越来越重要。
FP8 的价值不只是模型文件变小。它与硬件算子、缩放策略和混合精度训练/推理紧密相关。Transformer Engine 文档强调，不是所有操作都适合 FP8，需要通过 autocast、recipe 和 scale 管理，让适合低精度的矩阵乘法获得性能收益，同时把敏感操作留在更高精度。也就是说，FP8 更像硬件协同的低精度计算体系，而不是简单把文件转成某种后缀。
在推理服务中，FP8 常见两类用途。第一是 FP8 权重和激活，例如 vLLM 文档中的 FP8 W8A8 支持，用于在合适 GPU 上降低内存并提高吞吐。第二是 FP8 KV Cache，用于降低长上下文缓存显存。后者对长上下文和高并发尤其重要，因为权重压缩后，KV Cache 往往成为新的瓶颈。
FP8 也需要质量评估。E4M3 和 E5M2 动态范围与精度不同，scale 选择影响巨大。NVIDIA 文档提到 FP8 需要为不同张量使用缩放因子，因为单一缩放策略不能覆盖所有激活和梯度分布。推理中虽然不需要训练反向梯度，但激活和缓存仍然会受到 scale 策略影响。打开 FP8 不应视为无风险配置。
硬件兼容是 FP8 最大门槛之一。vLLM 硬件表显示 FP8 路线在不同 GPU 架构上支持不同。Hopper 和更新架构通常更适合 FP8；老卡可能无法获得同等收益，甚至不支持某些 kernel。团队如果使用 A100、3090、4090、H100、H200、L40S、MI300、CPU 或 Mac，量化选择可能完全不同。不能把某篇 H100 benchmark 直接套到消费级显卡上。
FP8 的合理使用方式是：在硬件支持明确、推理引擎支持成熟、业务评测通过时，把它作为吞吐和上下文容量优化手段。它不取代 INT4/GGUF 的本地部署价值，也不取代 GPTQ/AWQ 的低显存单卡价值。FP8 更适合现代 GPU 服务化部署里的性能路线。
量化和推理引擎要一起选
量化格式不能脱离推理引擎。一个模型文件在某个工具里能运行，不代表在另一个服务栈里也高效。vLLM、TensorRT-LLM、Text Generation Inference、SGLang、llama.cpp、Ollama、Transformers、LM Studio 对量化格式、kernel、硬件和模型架构的支持都不同。生产选型时，要先确定运行环境，再选择量化格式，而不是先下载一个最小模型文件。
vLLM 适合高并发在线服务，提供 OpenAI 兼容接口、PagedAttention、连续批处理、前缀缓存、量化和多 GPU 能力。它支持 AWQ、GPTQ、FP8、INT8、GGUF 等多条路线，但每条路线的硬件支持不同。使用 vLLM 时，要看官方量化文档和当前版本支持，不要凭旧经验判断。
llama.cpp 适合本地、桌面、边缘和低成本部署。GGUF 是它的核心生态优势，量化类型丰富，模型分发方便，CPU 和多种加速后端可用。如果目标是 Mac 本地助手、离线知识库、小型服务器或用户自带设备，GGUF 往往比服务化 GPU 栈更容易落地。若目标是多租户高并发 SaaS，llama.cpp 可能不是唯一选择。
TensorRT-LLM 更适合 NVIDIA 硬件栈统一、追求高性能且有工程投入能力的团队。它会把模型构建、kernel、并行、低精度和调度做深度优化，但模型转换、engine 构建和版本管理成本也更高。对于固定模型、固定硬件和高吞吐需求，TensorRT-LLM 很有价值；对于频繁换模型的团队，灵活性要评估。
Transformers 适合研究、原型、模型加载和生态兼容。它支持多种量化配置，也能加载 GPTQ、AWQ、bitsandbytes 等模型，但直接作为高并发在线服务通常还需要配合专门推理服务器。很多团队会用 Transformers 做验证，用 vLLM 或其他引擎做生产。
同一个组织可以保留多条量化路线。比如云上高并发用 vLLM FP8 或 AWQ，本地桌面用 GGUF Q4/Q5，离线批处理用 INT8，敏感场景用私有 GPU 和较高精度模型。关键是上层要有统一评测和模型网关，否则多格式会变成不可比较的模型碎片。
量化评估不能只看困惑度
困惑度是语言模型评估中的经典指标，能反映模型对文本分布的拟合程度。llama.cpp 量化文档也提到量化损失常用困惑度和 KL 差异观察。困惑度很有用，因为它可以快速比较不同量化版本在固定语料上的整体退化。但它不是业务质量的全部。一个量化模型困惑度只变差一点，仍可能在工具调用、代码生成、数学和长上下文任务上明显退化。
评估量化模型要分四层。第一层是通用语言质量，例如困惑度、常见基准、中文阅读理解、问答和摘要。它判断模型有没有整体坏掉。第二层是能力专项，例如数学、代码、逻辑推理、事实问答、多轮对话、长上下文定位。它判断模型核心能力是否保住。第三层是产品协议，例如 JSON schema、函数调用参数、引用格式、禁止项、拒答规则。它判断模型能不能接入真实系统。第四层是业务样本，例如客服、合同、教育、检索、报表、代码仓库、医疗或金融内部任务。它决定能不能上线。
量化评估要有标准精度基线。先用 FP16/BF16 或官方推荐精度跑同一批样本，确认原模型能达到要求。再跑 INT8、INT4、GPTQ、AWQ、GGUF、FP8 等候选版本。没有基线时，无法判断错误来自原模型能力不足，还是量化造成损失。很多团队抱怨“量化不行”，实际是原模型在该任务上本来就不够好。
评估还要固定生成参数。温度、top-p、top-k、重复惩罚、最大输出、停止词、chat template、系统提示词都会影响结果。比较量化版本时，尽量保持这些参数一致。若某个量化版本需要特殊采样才能稳定，也要记录下来，因为这会影响线上行为。
长上下文评估尤其重要。量化误差可能在短问答中不明显，但上下文变长后，模型更容易丢中间信息、忽略细节、引用错误片段或过早总结。若产品是 RAG、长文档问答、合同审查、代码仓库问答或研究助手，一定要用接近真实长度的样本评估。不要用 512 token 短题判断 64K 上下文质量。
结构化输出评估也很关键。很多 AI 产品不是让用户读一段话，而是让模型输出 JSON、表格、SQL 草稿、函数参数、表单字段或工单对象。量化可能只让自然语言差一点，但让格式成功率下降几个百分点。对自动化系统来说，这几个百分点可能意味着大量重试、人工修正和安全风险。
业务质量评估怎么设计
设计业务评测集时，先不要追求大而全。每个候选模型准备一百到三百条高价值样本，比随便跑几千条无关 benchmark 更有用。样本要覆盖真实用户问题、高频任务、困难边界、失败案例和高风险动作。每条样本最好包含输入、可接受答案、必须引用的信息、禁止出现的内容、格式要求和评分维度。
中文任务要特别注意中文语料。很多量化模型的校准和公开评测偏英文，中文质量不能默认等同。中文有长句、成语、省略、专业术语、政策文本、混合英文缩写、表格口径和上下文指代。一个模型在英文 MMLU 或 Wiki 困惑度上保持很好，不代表中文业务问答稳。评估时要加入中文长文、中文代码注释、中文表单、中文合同和中文客服对话。
代码任务要看编译和测试，不只看主观解释。量化模型可能能写出看起来合理的代码，但变量名、边界条件、类型、导入路径和测试断言容易出错。若产品用于代码助手，要用真实仓库片段、单元测试、静态检查和代码审查样本比较。GPTQ 或 AWQ 版本若让测试通过率下降，省下的显存可能不值得。
函数调用任务要看工具选择和参数。样本应包含明确工具、不应调用工具、参数缺失、用户指代模糊、权限不足和需要确认等情况。评分不只是最终回答，还包括是否调用正确工具、是否填对字段、是否在缺少信息时追问、是否拒绝越权动作。量化造成的一点理解偏差，可能让 Agent 走错工具。
RAG 任务要看引用。模型是否引用了正确片段，是否忠于资料，是否在资料缺失时承认找不到，是否把旧资料当新资料，是否把相似客户或相似政策混淆。量化后如果引用正确率下降，用户信任会直接受损。评估时最好把检索结果固定住，先隔离生成模型量化带来的影响；之后再评估量化 embedding 或 reranker 的影响。
安全边界也要评估。提示注入、敏感信息、越权请求、医疗金融建议、危险操作、支付和文件动作，都可能因为量化后边界判断变化而受影响。不要假设拒答能力不受量化影响。对生产系统来说，安全评估样本数量可以不多，但必须覆盖高风险类型。
性能评估：显存、吞吐、延迟和稳定性
量化性能评估不能只看模型文件大小。上线时关心的是显存峰值、常驻显存、KV Cache 使用、首 token 延迟、输出 token 速度、吞吐、并发、p95/p99 延迟、OOM、重试和失败率。一个 INT4 模型文件很小，如果 kernel 慢、反量化开销高或不支持连续批处理，在线吞吐未必好。
显存评估要分权重和 KV Cache。权重量化能减少常驻显存，但高并发长上下文还要看 KV Cache。把 32B 模型压成 4bit 后，权重能放进单卡，并不代表 32K 上下文和多用户并发也能跑。要用目标上下文长度、目标并发和目标输出长度压测，而不是只启动一次模型。
吞吐评估要区分 prefill 和 decode。长输入短输出任务主要压力在 prefill；短输入长输出任务主要压力在 decode；聊天服务两者都有。量化可能提高 decode，也可能只省显存不明显提速。若启用 FP8 KV Cache 或低精度权重，观察不同长度分桶下的 TTFT 和 tokens/s，才能知道收益在哪里。
延迟评估要看长尾。平均延迟好看但 p99 很差，用户仍然觉得系统不稳。量化版本如果在某些输入长度下触发慢 kernel、内存不足或输出重复，会让长尾明显变差。生产灰度时要按模型、量化格式、入口、租户、输入长度、输出长度和任务类型拆指标。
稳定性评估要看连续运行。很多量化问题不是第一条请求暴露，而是在长时间服务中出现：显存碎片、缓存回收异常、特定 prompt 重复输出、某些 batch 形态速度骤降、某个模型层 kernel 不稳定。压测至少覆盖混合请求、取消请求、多轮会话和长时间运行。
成本评估要算有效输出。量化让单次推理便宜，但如果质量下降导致用户重试、人工修正、工具调用失败或格式重试，单位有效任务成本可能上升。真正的成本公式不是“每 token 更便宜”，而是“每个通过质量标准的任务更便宜”。
不同场景怎么选量化路线
个人本地聊天和知识助手，通常优先看 GGUF。8B、14B 模型可以从 Q4_K_M、Q5_K_M、Q6_K、Q8_0 之间选择。若机器内存紧张，先试 Q4；若回答质量不稳，升到 Q5 或 Q6；若仍不稳，换更小但高精度的模型。有时一个更小的 Q8 模型比一个更大的 Q3 模型更可靠。
Mac 或边缘设备部署，要看 llama.cpp、Metal、Ollama 和目标应用支持。GGUF 的优点是交付简单，用户可下载运行。缺点是不同机器速度差异大，长上下文和大模型仍受内存带宽限制。对面向终端用户的产品，应给出推荐配置，而不是只给一个最小可运行模型。
单卡 GPU 部署 14B、32B 或更大模型，可以优先比较 AWQ、GPTQ 和 FP8。若硬件支持 FP8 且引擎成熟，FP8 可能带来更好的吞吐；若显存最紧张，INT4 AWQ/GPTQ 常见；若质量风险高，可以退回 INT8 或 BF16。不要只看“能放下”，还要看业务样本和并发。
高并发在线服务，优先确定推理引擎和模型网关。vLLM、TensorRT-LLM 或 TGI 下的量化支持、batch 调度、KV Cache、前缀缓存和监控都很重要。生产模型可以分层：高风险任务用 BF16/FP16 或 INT8，普通任务用 AWQ/GPTQ/FP8，长上下文任务单独评估 KV Cache 量化。
RAG 和知识库问答要谨慎。生成模型量化只是其中一环，embedding、reranker、检索、引用和上下文压缩也会影响质量。若生成模型量化后更容易忽略引用或编造答案，就算闲聊质量很好也不能直接上线。RAG 场景建议至少保留一个高精度回退模型，用于高风险问题或用户追问。
工具调用和 Agent 场景更要保守。工具调用需要稳定理解意图、选择工具、填参数、识别缺失信息和请求确认。INT4 若让格式成功率下降，可能导致后端重试和错误动作。对能写入业务系统的 Agent，优先使用经过业务评测的 INT8、FP8 或高精度模型；INT4 可以用于草稿、摘要、分类等低风险步骤。
量化上线流程
第一步，确定基线模型和任务边界。不要一开始就下载多个量化版本盲测。先选定标准精度模型，明确它要服务哪些入口、最大上下文、最大输出、并发目标、质量标准和安全边界。若原模型无法满足业务，量化不会解决根本问题。
第二步，准备评测集。评测集包括通用质量、业务样本、结构化输出、长上下文、工具调用、安全边界和压力样本。每条样本要有可判定标准。没有评测集，量化选择会退化成主观感受。
第三步，选择候选量化版本。候选可以包括 INT8、AWQ、GPTQ、GGUF Q4/Q5/Q8、FP8 等，但要和目标引擎匹配。不要把所有社区模型都下载一遍；先筛掉引擎不支持、来源不可信、tokenizer 不一致、许可证不清楚或模型卡信息不足的版本。
第四步，跑离线质量回放。同一批样本、同一套提示词、同一采样参数，比较标准精度和候选量化版本。记录准确率、人工评分、格式成功率、引用正确率、拒答正确率和失败类型。失败样本要分类，不要只给总分。
第五步，跑性能压测。用接近真实的输入长度、输出长度、并发和请求到达分布测试。记录显存、KV Cache、TTFT、输出速度、吞吐、p95/p99、OOM、错误和成本。不同量化格式要在同一硬件和同一引擎版本上比较。
第六步，灰度上线。先给低风险入口和少量流量使用量化模型，保留高精度回退。监控用户反馈、重试率、人工修改率、格式错误、工具调用失败和安全拒绝。不要一次性替换所有入口。
第七步，建立版本治理。记录模型来源、原始模型、量化方法、参数、校准数据、推理引擎版本、启动参数、评测结果和上线时间。量化模型是生产资产，不是随手下载的文件。模型升级、引擎升级和量化参数变化都要重新评估。
常见误区
第一个误区是把量化当成无损压缩。量化会改变数值行为，只是损失有时很小。是否可接受取决于任务，而不是取决于模型文件名。
第二个误区是只看显存，不看质量。省下显存如果换来错误引用、JSON 失败、工具误调和用户重试，整体成本可能更高。
第三个误区是把 INT4 等同于更快。INT4 常常省显存，但速度取决于 kernel、硬件和 batch。没有高效实现时，低 bit 不一定高吞吐。
第四个误区是混淆权重量化和 KV Cache 量化。AWQ、GPTQ 主要解决权重，长上下文显存还要看 KV Cache。权重很小不代表上下文免费。
第五个误区是下载别人量化好的模型就直接上线。预量化模型的校准数据、参数、引擎适配和质量边界未必适合自己的业务。必须用本地评测集验证。
第六个误区是相信通用 benchmark 能覆盖业务。模型在公开榜单上退化很小，不代表你的合同、客服、代码、表格和工具调用也退化很小。
第七个误区是忽视 tokenizer 和 chat template。量化权重没问题，但如果模板、特殊 token 或 stop 条件不一致，输出质量也会变差。
第八个误区是把所有入口都用同一个量化版本。不同任务风险不同，完全可以低风险走低比特，高风险走高精度，长上下文走单独资源池。
实践检查清单
量化前，确认原始模型能完成业务任务，确认许可证允许使用，确认目标推理引擎支持模型架构，确认 tokenizer 和 chat template 正确，确认评测集覆盖真实输入。
选择格式时，确认量化对象是权重、激活还是 KV Cache，确认 bit 数、group size、scale 策略和特殊张量处理，确认硬件支持，确认是否有高效 kernel，确认模型来源可信。
质量评估时，至少比较标准精度、INT8 或 FP8、INT4 候选。观察通用质量、中文质量、长上下文、结构化输出、函数调用、引用、安全边界和业务评分。不要只看一两个聊天样例。
性能评估时，记录权重显存、KV Cache、TTFT、输出速度、吞吐、p95/p99、并发、错误率和重试率。用真实请求分布压测，避免只测单用户短 prompt。
上线时，使用灰度和回退。保留高精度模型或更稳量化版本作为 fallback。监控质量反馈，不只监控服务健康。对高风险任务设置人工确认和质量门槛。
维护时，记录每个模型版本和量化版本。更新模型、更新推理引擎、切换 GPU、调整上下文长度、打开 KV Cache 量化，都要重新跑关键评测。量化不是一次性动作，而是模型生命周期管理的一部分。
结语
模型量化是一门工程折中。INT8 稳健，适合作为生产压缩入口；INT4 显存收益大，适合本地和单卡部署，但质量评估压力更高；GPTQ 用近似二阶信息做低比特后训练量化；AWQ 通过激活感知保护关键权重；GGUF 是本地推理生态的重要文件格式和量化载体；FP8 则是现代 GPU 上低精度计算和 KV Cache 优化的重要路线。
真正成熟的量化实践，不会问“哪个格式最好”，而会问“在哪个硬件、哪个推理引擎、哪个任务、哪个质量门槛下，哪个格式最合适”。只要把权重、激活、KV Cache 分清，把质量、延迟、吞吐、成本一起评估，把业务样本作为上线依据，量化就能从社区经验变成生产能力。
参考资料
- llama.cpp Quantize README: https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
- GGUF file format specification: https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
- vLLM Quantization documentation: https://docs.vllm.ai/en/v0.15.0/features/quantization/
- vLLM Quantized KV Cache documentation: https://docs.vllm.ai/en/v0.15.0/features/quantization/quantized_kvcache/
- NVIDIA Transformer Engine FP8 primer: https://docs.nvidia.com/deeplearning/transformer-engine/user-guide/examples/fp8_primer.html
- GPTQ paper: https://arxiv.org/abs/2210.17323
- AWQ paper: https://arxiv.org/abs/2306.00978
- AWQ project: https://github.com/mit-han-lab/llm-awq
- AutoGPTQ project: https://github.com/AutoGPTQ/AutoGPTQ
- Hugging Face Transformers AWQ documentation: https://huggingface.co/docs/transformers/main/quantization/awq
- Hugging Face Transformers quantization selection guide: https://huggingface.co/docs/transformers/main/quantization/selecting
- SmoothQuant paper: https://arxiv.org/abs/2211.10438