一篇读懂模型量化：INT8/INT4 压完之后，能力到底损失多少

量化的数学：用更少的比特表示权重

模型权重默认以 FP16（或 BF16）存储——每个参数 2 字节。量化的目标：用更少的比特（INT8 = 1 字节、INT4 = 半字节级）表示同样的信息。基本公式是线性映射：给一组权重找缩放因子 scale 与零点 zero-point，把浮点值域映射到整数范围——量化值 = round(权重 / scale) + zero_point，反量化时 权重 ≈ (量化值 − zero_point) × scale。INT8 的整数有 256 个档位，INT4 只有 16 个档位——位宽决定表示精度，精度决定损失。

量化的核心洞察：大模型的权重分布对量化出奇地友好——绝大多数权重值都很小（集中在零附近），只有极少数离群值（outlier）很大。均匀的整数量化（等宽档位）对这种分布是灾难（离群值撑大 scale，小权重全被压到同一档）；分组量化是解药：把权重切成小组（如每 128 个权重一组），每组独立计算 scale——离群值只影响自己那一组的精度，其他组保持细腻。

两条路线：PTQ 与 QAT

PTQ（Post-Training Quantization，训练后量化）：拿训练好的模型直接量化，不重新训练——部署侧的标准做法，成本低到「一条命令」。naive 的 PTQ（如简单的 RTN，round-to-nearest）在 INT8 基本无损、INT4 开始掉点。现代 PTQ 方法的核心是用校准数据补偿量化误差：GPTQ 用逐层的最小化重构误差（数学上求解「量化后的权重层输出尽量接近原输出」）、AWQ 强调「保护激活值大的重要权重」（不是所有权重同等重要，重要权重量化得更精细）。QAT（Quantization-Aware Training）：训练过程中就模拟量化（前向用量化值、反向用直通估计器 STE），让模型在训练中「适应」量化噪声——效果最好（INT4 下优势明显）但成本高（要完整训练管线），适合对质量极限压榨的场景（端侧设备）。

选择逻辑一句话：有训练管线、追求极限 → QAT；拿到模型就要用 → PTQ（GPTQ/AWQ）——99% 的场景是后者。

粒度与格式的工程细节

量化的工程细节决定同一算法的实测差异。粒度：per-tensor（整层一个 scale，最粗最差）→ per-channel（每列/每行一个 scale，主流）→ per-group（每 64/128 个权重一组，INT4 的标配）。权重与激活要分开谈：权重量化是离线的（部署前做好），激活量化是在线的（推理时激活值动态产生，离群值问题更严重）——W8A8（权重激活都 INT8）需要激活的校准与平滑（SmoothQuant 类方法把激活的离群「搬运」到权重侧）；W4A16（权重 INT4、激活保持 FP16）绕开了激活量化的难题，是消费级部署的主流形态。格式生态：GGUF（llama.cpp 生态的格式，K-quants 系列 Q4_K_M 等变体在「比特数与质量」间做了精细权衡）、GPTQ/AWQ（GPU 推理框架的格式）、FP8（新一代 GPU 的原生 FP8 计算——不是整数量化而是低精度浮点，损失更小）——格式要选你的推理引擎支持的。

KV Cache 也可以量化（本库 KV Cache 篇的延伸）：长上下文场景 KV 的显存占比超过权重，KV 量化到 FP8/INT8 是长上下文部署的常见组合拳。

决策表：什么场景选什么位宽

两个使用注意：小模型对量化更敏感（7B 量化掉点比例大于 70B——容量小的模型没有冗余吸收量化噪声，小模型慎用量化或用 QAT）；量化后必须回归评测（你的任务集跑一遍——通用基准掉 1 个点不代表你的场景掉 1 个点，反之亦然）。

量化的极限与前沿：更低位宽的探索与「量化感知」的未来

INT4 是当前主流的极限位宽，但量化的研究前沿已经推进到更低与更智能的形态。极低位宽（2-bit 与三值）：2-bit 量化的理论诱惑巨大（再省一半显存），但 16 个档位到 4 个档位的信息损失陡增——前沿的解法是改变数字的形态而非单纯压位宽：三值量化（权重只有 -1/0/+1 三态）配合特殊的加法计算硬件，用「极度离散」换取「乘法变加法」的计算优势——这类路线（bitnet 类）目前仍是研究形态，推理生态的支持有限，但它代表「把量化做到极致」的激进分支。混合位宽：对模型的不同层用不同位宽——对量化敏感的层（通常是最前与最后的层、以及注意力 logits 相关的部分）保持高精度，中间的「皮实层」用低位宽——按层搜索最优位宽组合（HAWQ 类方法）把「一刀切的位宽」升级为「按层定制的位宽配方」。量化与推理引擎的协同：量化的收益最终要靠推理内核兑现——INT4 权重的矩阵乘法要有专门的内核才快（不然反量化回 FP16 计算就白压了），格式（GGUF/GPTQ/AWQ）与引擎（llama.cpp/vLLM）的适配矩阵是部署时最容易踩的坑——「量化了」与「量化加速了」是两件事，内核支持是中间的那一步。未来的判断：量化会从「部署侧的补救」逐渐变成「训练侧的协同」——原生低精度训练（FP8 训练已是旗舰标配，INT 训练在研究中）让模型「生来就适合低位宽」——量化的终点不是压得更多，是训练时就想清楚部署时的样子。

量化的评估方法：怎么量化「量化的损失」

「量化损失多少」需要一个度量方法，评测的坑（本库评测篇）在量化场景全部适用。通用基准的测法：MMLU 类知识、GSM8K 类数学、HumanEval 类代码——量化前后各跑一遍，看掉点分布（知识类通常最抗量化、数学与代码更敏感——推理链对数值精度更挑剔）。生成质量的测法：困惑度回归（量化前后在同一文本集上的 PPL 对比——PPL 变化比任务分数更灵敏，微小的质量损伤先在 PPL 上显形）、以及人工盲评（同 prompt 双模型的输出并排盲选——最终裁决）。长尾与边界 case：量化损伤在「分布尾部」更明显——生僻知识、多语言小语种、长上下文的远端召回——通用基准测不到这些角落，用自己的领域任务集测才算数。一个重要的实验观察：量化损伤不是均匀的——某些任务几乎无损、某些任务（精确算术、长链推理）明显受损；「你的应用依赖的能力是否在敏感清单上」是量化决策的核心问题。评测的成本控制：全量基准跑一遍也就几小时，但「每次换量化档位都重跑」的纪律比基准本身更重要——量化档位的调整如果没有评测闭环，就是闭眼开枪。

量化的常见问题排查：量化后的模型「变笨」了怎么办

量化后模型表现异常的排查清单，按症状定位。症状一：输出全面变差（胡言乱语）——量化的格式或元数据出问题：GGUF 文件损坏（重新下载/转换）、引擎与量化格式不匹配（用错内核）、或分词器没随权重一起加载——先排除「文件与格式」层再谈质量。症状二：特定任务掉点明显——该任务对数值精度敏感（数学、代码），INT4 的损失集中爆发——升档到 Q5/Q6 或换 AWQ（对重要权重保护更好）。症状三：长文本能力大幅退化——KV Cache 没量化但上下文设置被压缩（部署脚本默认了小上下文），或长文本对权重误差累积敏感——检查上下文配置，升档或换混合位宽（重要层用更高精度）。症状四：速度没提升——量化的内核没被启用（引擎没支持该格式的加速内核，回退到反量化计算——「量化了但不快」的经典原因），换支持的引擎或格式。四类症状的排查都在「先查部署链路、再查质量损失」的顺序——量化问题的半数以上是部署链路问题，不是量化本身的问题。

量化决策的最后一步：回归测试的最小集

量化的最后一个动作是回归测试，最小测试集的构造建议：十道题覆盖四种能力——常识问答两道（知识层）、简单算术两道（数值敏感）、一段代码补全（代码能力）、一段指令跟随（格式遵循）、一个中文长句改写（语言细度）、一个多轮上下文的指代消解（长程依赖）、一道「冷门事实」（长尾知识）。量化前后各跑一遍，答案并排对比——肉眼十分钟内即可判断「损失可否接受」。这份迷你回归的价值不在统计严格性（十道题没有统计意义），在「每次换量化档位都强制执行」的仪式感——它把「量化后必须验证」从建议变成流程，而流程是质量保障的全部秘密。再补一条进阶建议：把这十道题的答案存档对比（量化档位 × 输出记录），积累下来就是一份「位宽-质量」的私人对照表——比任何公开 benchmark 都更贴合你的使用画像。

小结

量化用更少比特表示权重，核心数学是「scale 映射 + 分组处理离群值」，大模型权重分布对量化的友好性是它可行的物理基础。PTQ（GPTQ/AWQ，一条命令）是部署侧默认，QAT 是极限压缩的代价选项；粒度（per-group）与格式（GGUF/GPTQ/AWQ/FP8）决定同算法的实测差异，W4A16 是消费级主流。决策表按场景对号：生产保质量用 FP16/FP8、省显存用 W4A16、手机端 QAT、零容忍不量化；小模型量化敏感、量化后必须用自己的任务集回归。量化的尽头是「用可忽略的质量损失换数倍的部署半径」——下一篇看这个半径的另一端：llama.cpp 与本地推理生态，怎么在自己的电脑上把量化模型跑起来。