模型量化不是壓縮，是精度換頻寬的工程帳

很多人把量化理解成「把大模型變小」，方向對了一半。對推論成本敏感的團隊更該問的問題是：同樣一批 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 個點，匯出工具鏈要鎖定版本。

結論很樸素：量化前算清楚顯存帳和並行帳，量化後用真實業務評測集說話。省下的顯存換成更高吞吐，才是這筆工程帳的正解。