模型量化不是压缩，是精度换带宽的工程账

很多人把量化理解成"把大模型变小"，方向对了一半。对推理成本敏感的团队更该问的问题是：同样一批 GPU，量化之后每小时能多跑多少请求。

先算账，再选方案

一张 A100 80G 跑 FP16 的 70B 模型，光权重就占约 140GB，双卡起步。同样的模型量化到 INT8 大约 70GB，双卡带宽压力减半；量化到 INT4 约 35GB，单张 48G 卡就能装下。内存占用下降带来三个直接收益：

1. 单卡能装更大的模型，或同卡装更多副本；

2. 权重从显存搬到计算单元的数据量变小，batch 小时延迟更低；

3. 更多显存留给 KV cache，能并发处理更长的上下文。

第三条最容易被忽略。实际生产中，瓶颈经常不是"算不动"，而是"缓存放不下"。

INT8 通常用 per-channel 或 per-tensor 的 scale 因子，几乎不掉点，多数场景可以放心用。INT4 常用 GPTQ、AWQ 这类方法，按权重分布选保留哪些敏感通道。经验规律：

- 通用对话、分类、抽取任务：INT4 基本无感；

- 数学推理、代码生成：INT4 掉点更明显，敏感任务建议至少保 INT8 关键层（attention 投影、最后一层）；

- 微调场景：先在量化格式上做 LoRA（QLoRA），训练完再决定是否合并回 FP16 部署。

一个实用测试方法：拿 200 条覆盖你核心业务的高质量评测集，分别跑 FP16、INT8、INT4，对比任务指标和首 token 延迟。别只看 MMLU 这种通用榜单，业务分布和榜单分布经常不一致。

- 量化后首次推理有 kernel 编译开销，压测要预热；

- 不同推理框架（vLLM、TGI、TensorRT-LLM）对 INT4 格式支持不一致，换框架前确认 GGUF、GPTQ、AWQ、FP8 各自的兼容性；

- FP8 需要 Hopper 以上硬件（H100/H200），A100 上用不了，别盲目跟进；

- 量化模型换 quantization 工具重导一次，指标可能差 1-2 个点，导出工具链要锁定版本。

结论很朴素：量化前算清楚显存账和并发账，量化后用真实业务评测集说话。省下的显存换成更高吞吐，才是这笔工程账的正解。