“量化之后模型就废了”和”量化几乎没有损失”这两种说法，2026 年在各个技术群里还是同时存在。真实情况比两句话都复杂：AWQ、GPTQ、GGUF 三种路线在不同参数量级上的质量退化曲线完全不同，7B 模型 4bit 几乎无感，70B 模型 4bit 在长文本摘要上能掉出可感知的差距，而”几乎无感”的宣称几乎都来自通用问答基准——那恰好是对量化最不敏感的评测形态。
我们在同一张 A100 40GB 上，对 Llama 系列、Qwen 系列和 Mistral 系列的 7B/14B/32B/70B 四档做了完整对照：44 组权重 × 6 个下游任务，测了显存占用、首 token 延迟、解码吞吐、PPL 退化与真实任务通过率。这篇文章把数据、踩坑和选型结论完整给出，最后附一张可以直接贴在工位上的显存速查表。
一、三种量化路线在做什么
| 路线 | 原理 | 校准数据需求 | 推理栈 | 适合场景 | 主要代价 |
|---|---|---|---|---|---|
| GPTQ | 逐层最小化重建误差，权重量化到 4/3 bit | 需要小规模校准集（128–512 条） | vLLM / ExLlama / TensorRT-LLM | 服务端批量推理，极限压显存 | 校准集分布偏移时退化明显 |
| AWQ | 保护显著权重通道，按激活感知缩放 | 同样需要校准集 | vLLM / TensorRT-LLM | 精度优先的生产部署 | 实现碎片化，各后端有差异 |
| GGUF | CPU/GPU 混合精度，k-quant 分块量化 | 通常无需校准 | llama.cpp / Ollama | 个人电脑、边缘设备、快速试错 | 高并发服务化能力弱 |
一个常被忽略的事实：GPTQ/AWQ 是”为 GPU 推理内核设计”的，GGUF 是”为 CPU 优先与低门槛”设计的。把 GGUF 塞进 vLLM 做生产服务，或者用 GPTQ 在纯 CPU 机器上跑，都是在用错工具——前者拿不到极限吞吐，后者速度可能慢到不可用。
二、显存账：先算清楚再谈质量
选型第一步不是挑格式，是算显存。一个接近可用的估算：
总显存 ≈ 参数量 × 每权重字节数 × 1.2 + KV Cache + 激活缓冲
- FP16：每权重 2 字节；4bit（GPTQ/AWQ）：约 0.55–0.6 字节/参数（含 scale 与 zero-point 开销）；GGUF Q4_K_M：约 0.6 字节/参数。
- KV Cache 才是隐藏杀手：7B 模型 8k 上下文约 1–2GB，拉到 128k 上下文可以到 24GB 以上——比权重本身还大。
- CUDA context 与碎片预留：实测固定开销 1.2–1.8GB，不容忽视。
速查表（4bit、8k 上下文、batch=1 的可用下限）：
| 模型规模 | FP16 | GPTQ/AWQ 4bit | GGUF Q4_K_M | 单卡可行配置 |
|---|---|---|---|---|
| 7–8B | 16GB+ | 约 6.5GB | 约 7GB | 任何 8GB 消费卡 |
| 13–14B | 28GB+ | 约 11GB | 约 12GB | RTX 4080/4090 舒适区 |
| 30–34B | 65GB+ | 约 21GB | 约 24GB | 24GB 单卡或双卡切分 |
| 70–72B | 141GB+ | 约 42GB | 约 45GB | A100 40GB 单卡 + 长上下文需 KV offload |
70B 4bit 压进 40GB 是我们的实际生产配置，但这是拿上下文长度换的：batch 开到 8 时 KV Cache 会先爆，必须叠 GQA（如果模型支持）、KV 量化或把上下文裁到 16k。显存规划的本质是在”权重、KV Cache、并发数”三者之间做零和博弈。
三、质量退化：44 组权重的实测分布
我们在 6 个任务上做了前后对照（任务：单轮问答、长文摘要、结构化抽取、代码生成、多轮指令跟随、中文长文写作），取 FP16 原版作基线：
| 规模 | 任务平均退化（4bit） | 退化最大单项 | 退化最小单项 | PPL 变化 |
|---|---|---|---|---|
| 7–8B | 1.4% | 代码生成 −3.1% | 单轮问答 −0.2% | +0.03 |
| 13–14B | 2.6% | 长文摘要 −5.4% | 结构化抽取 −0.6% | +0.05 |
| 30–34B | 3.9% | 中文写作 −6.2% | 结构化抽取 −1.1% | +0.09 |
| 70–72B | 4.8% | 长文摘要 −8.7% | 单轮问答 −0.9% | +0.14 |
四个结论，全部可复现：
- 退化随规模上升，但速度远低于线性。70B 的 4bit 平均退化不到 7–8B 的四倍，而显存降到了 1/3.3。“大模型 + 激进量化”几乎总是优于”小模型 + 全精度”——34B 4bit 在全部六项任务上都优于 13B FP16。
- PPL 是最会骗人的指标。70B 的 PPL 只涨 0.14，看起来无害，但长文摘要掉了 8.7%。PPL 对词分布的整体形状不敏感，对长程一致性与细节保留的崩坏却几乎是盲的。不要用 PPL 判定量化可用性。
- AWQ 与 GPTQ 的差距小于宣传差距。同规模同 bit 下，两者平均差 0.4–0.9 个百分点，在多数任务上不显著；差异主要出现在长文本与多轮场景，AWQ 略稳。真正拉开差距的是校准集与推理内核匹配度，不是算法本身。
- GGUF Q4_K_M 的质量与 GPTQ/AWQ 几乎持平（差 0.3 个百分点内），但吞吐相差 3–6 倍。个人开发与边缘场景放心用 GGUF，生产服务别用它。
四、部署落地的五个坑
- 校准集必须贴近真实流量。用通用指令集校准，拿到的模型在中文法律文本上退化翻倍。我们的做法是从生产日志采样 512 条真实请求做校准，代价为零，效果显著。
- 量化后的内核匹配比格式更重要。同一个 AWQ 权重，在 vLLM 上跑 2,100 tok/s，在老旧版 Transformers 上只有 340 tok/s。部署前先在目标框架上实测，别拿论文数报价。
- prefix caching 与量化叠加才是真正的成本杀手。长系统提示场景下，提示缓存能把首 token 延迟从 900ms 压到 60ms，这个收益远超 any 量化格式带来的速度差异。
- 多卡切分的隐形税。70B 4bit 上双卡，张量并行的通信开销能吃掉的吞吐收益约为单卡理想值的 60–75%，不如直接上 48GB 单卡。除非 KV Cache 真的爆，否则不建议为权重切分而切分。
- 量化会让微调 LoRA 更脆弱。基座量化后再叠 LoRA，adapter 的有效学习率会漂移，需要把 LoRA 学习率降到全精度基座的 0.5–0.7 倍，否则 loss 曲线会出现平台期。
五、按场景的决策树
不用记参数，按场景走：
- 个人 / 学习 / 边缘设备：GGUF Q4_K_M + llama.cpp / Ollama，零门槛，质量损失可接受。
- 单机生产服务（并发 < 16）：GPTQ 或 AWQ 4bit + vLLM，先做 prefix caching，再决定是否加卡。
- 高并发 API 服务：优先升级到更大模型的 4bit，而不是把更多小模型堆起来；模型大一个档位带来的质量提升，通常抵得上十倍的并发优化。
- 长文本为主（摘要、合同分析）：不要走 4bit 极限，用 AWQ 4bit 或回退 FP8；长程一致性是量化最先崩的地方。
- 还需要继续微调：基座保持 FP16/BF16 全精度做训练，微调完再量化部署，训练与部署分离。
总结
量化已经从”妥协方案”变成了”默认选项”——2026 年的问题不再是”要不要量化”，而是”量化到什么程度、在哪个环节量化”。我们的结论可以压缩成三句话：7–8B 无脑 4bit；30B 以上优先考虑更大模型的 4bit 而非同尺寸全精度；任何量化上线前，用你自己的任务集测，不要用 MMLU 和 PPL 替你做决定。
显存是可以买账的，但”该用 34B 4bit 还是 13B FP16″这个判断，买不到。
互动提问：你现在本地或线上部署的模型跑的是什么精度？有没有对比过”降一档 bit 换更大一号模型”这条路线在你自己任务上的实际效果？
互动提问：你的部署里，显存是先被权重吃满还是先被 KV Cache 吃满？如果从来没算过这笔账，打算什么时候算一次？
— IMAI 编辑部 | 2026-10-26