大模型量化实战（上）：从显存焦虑到算法本质
大模型量化实战（上）：从显存焦虑到算法本质
想在本地跑个 70B 的大模型？FP16 精度下光权重就得吃掉 140G 显存，连加载都报错。这时候你肯定盯上了量化：换成 INT4，35G 显存搞定，一张 RTX 4090 就能起飞。
但真用起来，坑就来了：
- 明明体积缩小了 4 倍，生成速度怎么没快 4 倍？
- 评测分数看着没掉，怎么让它写个复杂代码就开始胡言乱语了？
- 网上满天飞的 GPTQ、AWQ、W8A8，到底该下哪个包？
很多人以为量化就是“把文件压缩一下”，其实根本不是。它更像是在给大桥换便宜的钢材 ——有些钢缆是主承重墙，换差了桥就塌了；有些只是栏杆，随便换。
而且别被 PPL（困惑度）这种评测指标骗了。很多时候分数没变，但模型的长尾知识召回下降、多步推理链断裂、格式化输出不稳定 ——这些才是量化最常见的“隐形退化”。这就是为什么不能闭着眼睛无脑转 INT4。
为了搞懂这些，我把大模型里需要量化的东西分成了三块，它们的脾气完全不一样：
| 要量化的东西 | 通常压到多少 | 难在哪 | 实际影响 |
|---|---|---|---|
| 权重 (Weights) | INT4/INT8 | 存在少量 outlier 通道（通常占 <1%，但绝对数量随模型增大可达几十至上百个） | 省显存的绝对主力，离线弄好就行 |
| 激活值 (Activations) | INT8/FP8 | 经常冒出极大值（Outlier），动态变化 | 决定推理能不能真正提速，必须在线处理 |
| KV Cache | INT4/INT8/FP8 | 聊得越久占得越多 | 长文本场景下的救命稻草 |
这篇文章不打算给你背公式。我们直接从这几个实际问题出发，用大白话盘一盘主流算法到底是怎么解决这些“刺头”的，最后给你一张直接能用的选型决策表。
💡 提前交个底
这篇主要讲“原理直觉”和“工程选型”。如果你跟我一样，不仅想知道“怎么用”，还想深究背后的数学推导、Hessian 矩阵到底怎么算，或者想拿评估脚本自己跑一遍测试，这部分硬核内容我会整理到下篇《量化实战（下）：评估与调优手册》里，咱们分步吃透。
算法本质：一场关于“误差甩锅”的游戏
搞懂了量化不是无损压缩，接下来就要面对一个灵魂拷问：既然压缩必然带来误差，那这些误差该让谁来扛？
最朴素的做法（RTN）是“平均主义”：所有权重一视同仁地四舍五入（现代实现虽会配合 per-channel 缩放，但仍未考虑权重敏感度差异）。结果就是，那些对输出至关重要的“承重墙”权重被压坏了，模型直接变傻。
主流量化算法的本质，其实都是一场精心设计的“误差甩锅游戏” ——它们都在想办法把量化带来的破坏，转移到模型最能承受的地方去。只是甩锅的姿势和对象不同：
SmoothQuant：激活值太难搞？重新平衡分布！
前面表格里说过，激活值里经常冒出极端大值（Outlier），硬量化会崩。SmoothQuant 不是随便给个常数做缩放，而是逐通道（per-channel）计算缩放因子 $s$，这个 $s$ 是根据激活值和权重的统计分布联合算出来的。
它的核心作用是平滑激活值的分布（把 Outlier 的幅值压下来），让激活值能用更小的量化步长；同时权重因缩放后分布更集中，量化损失也可控。这才是“误差转移”的真正含义——不是简单甩锅，而是通过重新平衡两者的分布，让双方都变得“好量化”。这也是 W8A8 能跑起来的关键。
AWQ：找出“承重墙”，重点保护
AWQ 换了个思路：不甩锅，而是识别出谁不能碰。它发现模型里只有不到 1% 的权重（通常是注意力头和 FFN 的特定通道）对输出影响极大，称为“显著权重”（Salient Weights）。
AWQ 的做法是：只对这些显著权重保持高精度（或单独缩放保护），其余权重放心大胆地压到 INT4。这就像装修时，承重墙用钢筋混凝土，隔断墙用轻质砖——把钱花在刀刃上。这也是为什么 AWQ 在代码生成、数学推理等复杂任务上常常反超 GPTQ：它保住了模型的“知识承重墙”。
GPTQ：用数学精确计算“谁该多扛一点”
GPTQ 是最“精打细算”的。它不像 AWQ 那样粗暴保护，也不像 SmoothQuant 那样整体平滑，而是逐列量化权重，并用已量化列的误差去动态修正未量化列。
背后靠的是二阶信息（Hessian 矩阵）：它能精确算出每个权重被扰动后，对最终输出的影响有多大。影响大的，就多补偿一点；影响小的，就少管一点。这是一种全局最优的误差分配，所以 GPTQ 在通用 PPL 上通常是 W4A16 的精度标杆。量化耗时可通过 OBS 优化或缩减校准集（128 条）压缩到 30 分钟内（A100），并非不可接受。
💡 一句话总结三者的区别
- SmoothQuant：重新平衡激活值与权重的分布（解决 W8A8 难题）
- AWQ：保护关键权重不被压坏（复杂推理任务更稳）
- GPTQ：用数学精确分配每个人的锅（通用 PPL 精度标杆）
它们没有绝对优劣，只有适合的场景。下一节我们就把这些理解转化为一张可直接用的选型决策表。
别忘了 KV Cache：长文本的救命稻草
前面聊的都是权重和激活值，但如果你要跑长上下文（比如读一本书、分析长代码），还有一个隐形显存杀手：KV Cache。
它是自回归推理时缓存的历史 Key/Value 张量，序列越长占得越多。70B 模型在 4K 上下文下，KV Cache 可能比权重还吃显存；到 32K 时直接翻倍。
KV Cache 量化（INT4/INT8/FP8）就是为这个场景而生的。当前主流方案已支持 INT4（如 KIVI、KVQuant），在长上下文下比 INT8 再省一半显存，且精度损失可接受。它和权重量化有两个关键区别：
- 在线进行：每生成一个 token 都要更新，不能离线预处理；
- 对精度更敏感：Cache 里的微小误差会在后续注意力计算中被反复放大。
好消息是，KV Cache 的分布相对平稳，INT8/INT4 量化几乎无损。如果你的应用场景涉及 >8K 的上下文，KV Cache 量化不是可选项，而是必选项。主流框架（vLLM、TensorRT-LLM）都已原生支持，开箱即用。
别背参数了，直接查这张表
理解了原理，最后落到实操：你到底该选哪个？ 别再对着论文纠结了，直接按场景对号入座：
| 你的场景 | 推荐方案 | 为什么选它 | 要注意的坑 |
|---|---|---|---|
| 消费级显卡跑 70B+ | AWQ-W4A16 优先；若使用 HuggingFace 原生 pipeline 且不愿换框架，选 GPTQ | AWQ 在 vLLM/TensorRT-LLM 中推理更快；GPTQ 胜在 Transformers 原生支持、零迁移成本 | AWQ 量化需校准集；GPTQ 量化耗时可通过优化压缩到 30 分钟内 |
| 服务端高吞吐部署 | SmoothQuant-W8A8 / FP8 | 激活值也量化了，真正利用 INT8 Tensor Core，吞吐翻倍 | 对小模型（<13B）收益不明显：因其激活值 Outlier 不严重，W8A8 加速抵不过精度下降 |
| 长文本 / RAG 应用 | 任意权重量化 + KV Cache INT4/INT8 | 解决长上下文显存瓶颈，INT4 比 INT8 再省一半显存 | KV Cache 量化需框架支持，老版本可能不兼容 |
| 代码 / 数学等敏感任务 | AWQ-W4A16 优先 | 保护显著权重，复杂推理任务常反超 GPTQ | 若 AWQ 不可用，退而求其次选 GPTQ |
| 只是试玩 / 不在意精度 | GGUF-Q4_K_M (llama.cpp) | CPU/Apple Silicon 友好，生态最全 | 速度不如 GPU 方案，不适合生产 |
⚠️ 两个通用避坑提醒
- 校准集质量 > 数量：128~512 条是常见范围，但关键是覆盖你的目标分布。多语言、多轮对话等多样场景可能需要更多样本来捕捉分布特征，盲目堆数量不如提升样本多样性。
- 别信单一指标：PPL 低 ≠ 好用。上线前务必用真实业务 case 跑一轮，重点测长尾知识召回和多步推理稳定性。
结语与下篇预告
量化不是银弹，而是一个需要根据场景精心调参的系统工程。理解了“误差甩锅”的本质，你就不会再被各种缩写迷惑，也能看懂为什么没有万能方案。
💡 下篇预告
这篇讲了“怎么选”，下篇《量化实战（下）：评估与调优手册》会讲“怎么验”：包括 Hessian 矩阵的直觉推导、评估脚本实操、以及如何定位量化导致的神经元级损伤。想从“会用”进阶到“真懂”，咱们下篇见。