量化实践：GPTQ、AWQ、GGUF 如何选择

第一次接触本地大模型时，我被模型文件名吓了一跳：同一个模型有 FP16、GPTQ、AWQ、GGUF，还有不同的 Q4_K_M、Q5_K_S。看起来只是下载一个更小的文件，真正运行时却可能遇到格式不支持、速度没有变快、输出质量突然下降，甚至模型能加载但生成结果完全不对。

后来我才发现，量化不是“把文件压缩一下”。它改变了权重的表示方式，也会影响推理引擎、硬件加速、内存访问和模型质量。选择 GPTQ、AWQ 还是 GGUF，首先要看你准备在哪里运行，其次才是看文件大小。

一、量化到底在损失什么

神经网络权重通常用 FP16 或 BF16 表示，每个参数有较精细的数值。INT8、INT4 等低比特表示只能保留更少的离散值，因此会产生误差。

FP16：数值范围和精度较高，内存占用大
INT8：占用下降，通常较容易保持质量
INT4：占用显著下降，但更依赖量化方法和数据

粗略估算：一个 7B 参数模型使用 FP16，权重约需 14GB；INT4 理论上约需 3.5GB，再加上量化元数据、运行时缓冲区、KV Cache 和系统开销。实际可用显存不能只看模型文件大小。

量化误差也不是平均分布的。某些层、某些通道和某些权重对模型输出更敏感，简单地把所有参数统一压到 4 bit，可能会严重伤害推理和长文本能力。

二、GPTQ：面向权重的后训练量化

GPTQ 通常在模型训练完成后，使用一批校准数据估计量化误差，并逐层调整权重，使量化后的输出尽量接近原模型。它的优势是生态成熟、模型选择多，很多 GPU 推理路径都支持。

但 GPTQ 不是一个统一质量保证。不同工具版本、Group Size、校准数据和保存配置都可能影响结果。下载模型时要确认量化位数、量化工具、推理引擎和模型架构是否匹配。

量化结果质量
≈ 原始权重
  + 量化算法
  + 校准数据
  + 分组参数
  + 推理内核

GPTQ 更适合已经确定 GPU 推理路线，并且希望使用成熟量化模型的场景。它不是“所有设备都通用”的格式。

三、AWQ：优先保护重要权重

AWQ 的核心思路可以用白话理解：不是所有权重都同样重要，先识别对激活值敏感的通道，尽量保护它们，再量化其他权重。

这类激活感知的策略，通常能在较低比特下较好地保持质量，尤其适合配合特定 GPU 推理内核。但它同样依赖模型架构、校准数据和推理实现。一个 AWQ 文件在某个引擎上很快，在另一个引擎上可能回退到不理想的路径。

下载 AWQ 模型时要看清：支持的 Transformers 版本、CUDA 版本、推理引擎、是否支持 KV Cache 和批处理。不要只看别人截图里的 Token/s。

四、GGUF：更像一条本地和跨平台生态路径

GGUF 是一种适合 llama.cpp 等本地推理生态的模型文件格式，常见于 CPU、Apple Silicon、消费级 GPU 和多种桌面工具。它的优势是部署方便、生态广、可以把模型和必要元数据放进一个可管理的文件中。

Q4_K_M、Q5_K_M 等名称表示不同的量化级别和策略。数字越高通常占用更多，但质量可能更好；具体后缀还影响分组和混合精度，不能只按“4 比 5 小”做决定。

GGUF 很适合个人电脑、本地隐私场景和快速验证。它不代表质量一定低，也不代表在所有 GPU 上最快。对于大规模服务，需要结合引擎的批处理、并发和硬件利用率重新评估。

五、先按部署目标选择

可以先用这个粗略决策：

NVIDIA GPU 服务
  ├─ 追求 GPU 吞吐 → 优先看 AWQ / GPTQ 的引擎支持
  └─ 需要特定框架 → 跟随框架推荐格式

CPU / Apple Silicon / 桌面本地
  └─ 优先看 GGUF 与 llama.cpp 生态

端侧设备
  └─ 看 Core ML、TFLite、ExecuTorch 等目标格式，不要直接照搬桌面量化文件

这不是绝对规则。真正选择前要确认模型架构、上下文长度、硬件指令集和推理引擎版本。格式只是入口，实际性能来自整个运行路径。

六、校准数据决定量化后的边界

校准数据不一定要很大，但要像真实输入。客服模型就使用客服问题，代码模型就加入目标语言和仓库风格，中文模型不能只用英文校准。

type CalibrationSet = {
  domain: string
  languages: string[]
  averageLength: number
  longContextRatio: number
  edgeCases: string[]
}

如果校准集只包含简单短句，量化后的模型可能在样例上很好，长文本、专业术语和边界问题却明显退化。校准数据要覆盖真正关心的输入分布，但也必须经过授权和脱敏。

七、评测不要只看模型能不能加载

量化比较至少包含三类结果：

质量：任务准确率、困惑度、结构化输出、RAG 忠实性和高风险样本。
资源：峰值显存、内存、模型加载时间和磁盘占用。
性能：首 Token 延迟、生成速度、并发 P95 和长时间运行稳定性。

原模型 FP16：质量 92，显存 14GB，速度 35 token/s
GPTQ INT4：质量 90，显存 5GB，速度 48 token/s
AWQ INT4：质量 91，显存 5GB，速度 55 token/s
GGUF Q4：质量 89，内存 6GB，速度 22 token/s

这些数字只是示意，真实结果要在你的硬件和数据上测量。GGUF 在本地 CPU 上可能是最合适的选择，AWQ 在 GPU 服务上可能更好，不能用一张跨环境排行榜替代部署测试。

八、KV Cache 和上下文会改变结论

模型权重压下来了，不代表长上下文成本也解决了。对话越长，KV Cache 越大；量化权重节省的显存可能很快被 Cache 和运行时缓冲区吃掉。

要分别测试短输入、长输入和连续多轮对话。记录上下文长度增加时的速度、显存和质量变化。必要时使用 KV Cache 量化、上下文摘要和长度上限，但每个优化都要重新评测。

九、常见错误和排查顺序

模型加载成功但质量异常时，可以按顺序排查：

模型架构和 Tokenizer 是否匹配。
推理引擎是否支持当前量化格式。
RoPE、上下文长度和特殊 Token 配置是否正确。
量化文件是否完整，下载哈希是否一致。
推理参数是否和原模型相同。
量化质量是否在目标数据上确实退化。

不要一看到输出变差就换量化格式。先用同一 Prompt、同一 Tokenizer、同一采样参数做基线，再逐项排除。

总结：量化选择是部署选择

GPTQ、AWQ 和 GGUF 没有一个脱离场景的冠军。GPTQ 适合成熟的后训练量化和 GPU 生态，AWQ 更强调保护重要激活通道并配合高效 GPU 内核，GGUF 则在本地和跨平台推理中非常实用。

我现在选择量化模型，不会先问“哪个文件最小”，而会问：它在哪个引擎里跑，目标硬件是什么，真实任务质量掉了多少，长上下文和并发表现怎样，出了问题能不能回退到 FP16 或另一个版本。

量化的意义不是让模型变小本身，而是用可接受的质量代价换取更低的资源门槛。只要把质量、内存、速度和稳定性放在同一张表里，量化就不再是一场下载文件名的猜谜，而会变成一次有证据的工程决策。