模型量化不是压缩包：INT4 省下的显存，要用精度补回来

一、先算清这笔账：INT4 到底省了什么
量化的账面收益非常直观。权重显存约等于参数量乘以位宽再除以 8：一个 70B 模型，FP16 需要 140GB，INT8 降到 70GB，INT4 只需 35GB；7B 模型则从 14GB 依次降到 7GB 和 3.5GB。一张 24GB 的卡从"跑不动 7B"变成"能塞下 7B 加一段上下文"，这就是量化被追捧的原因。

但这笔账只算了一半。推理时的显存占用是权重、KV Cache 和激活值三部分之和，而权重量化几乎不影响后两项。以 Llama-3-70B 为例，80 层、8 个 KV 头、每头 128 维，每个 token 的 KV Cache 约 320KB；上下文拉到 32K，仅 KV Cache 就要 10GB 左右。也就是说，把权重压到 INT4 省下 105GB，长上下文场景里 KV Cache 依然是不可忽视的大头。只盯着权重位宽做规划，很容易在压测时发现并发上不去。

二、掉点不在平均分，而在长尾任务
量化模型最危险的信号，是评测报告上"困惑度只涨了 0.2"这一行。平均值掩盖了分布尾部：数学推理、代码补全、小语种和长文档检索，往往是最先崩掉的地方。原因并不神秘——Transformer 的激活值里存在少数幅值极大的离群通道，INT4 的 16 个量化档位覆盖不了这种动态范围，权重被压平后，这些通道的信息首先失真。

工程上的对策已经比较成熟。GPTQ、AWQ 这类 weight-only 方案只量化权重，激活保持 FP16，对生成质量更友好；如果要做 W8A8 甚至 W4A8，就需要 SmoothQuant 之类的方法把激活离群值按通道迁移到权重侧，用"两边都不极端"换取整体可量化。换句话说，量化不是把数字截断，而是一次重新分配误差的工程。

三、校准集是最容易被糊弄的一环
多数量化工具默认取 128 到 512 条校准样本，样本从哪来，直接决定量化后的模型认不认你的业务。全部用英文维基语料校准，再拿去跑中文客服和代码生成，掉点几乎是必然的；用通用对话校准，再拿去处理带大量数字的财务报表，同样会出问题。校准集应当覆盖真实流量的长度分布、语言分布和符号密度，而不是随手抓一个公开数据集交差。

另一个常被忽略的参数是 group size。128 的分组比 per-channel 更省显存，但组内一旦混入离群值，整组都会被拉偏；敏感层（如 embedding、lm_head 和首尾若干层）保留高精度，通常比全局统一压低一档更划算。

四、KV Cache 量化是另一笔独立的账
权重压到 4bit 之后，很多人会把目光转向 KV Cache，希望再省一半。实践中 FP8 的 KV Cache 基本可以放心用，精度损失在常规对话里难以察觉；但 INT4 的 KV Cache 在长上下文检索任务上掉点明显，"大海捞针"类测试的命中率会肉眼可见地下滑。相比之下，分页管理、前缀复用、减少重复 prefill，这些手段不牺牲精度，收益反而更确定。

五、上线前的检查清单
判断一个量化模型能不能用，建议按顺序过四关：第一，任务级评测，用业务真实 Prompt 跑准确率，而不是只看困惑度；第二，长上下文专项，测 8K、32K 下的检索与摘要；第三，并发压测，确认显存余量与吞吐的真实曲线——INT4 的解码加速通常来自访存带宽下降，2 到 3 倍是常见区间，指望 4 倍线性收益会失望；第四，灰度对比，让新旧版本在同一批流量上并行跑一段时间。

量化确实是把大模型拉进低成本部署的关键一步，但它压缩的是显存，不是风险。省下来的每一 GB，都要用更细致的评测和更谨慎的层间策略去兑现。把量化当成一次需要验收的模型变更，而不是一次打包压缩，才是它真正可用的前提。

标签：大模型、模型量化、推理优化、INT4、KV Cache