🧮 量化方案与精度验收
1. 为什么量化是容量问题，不只是精度问题
显存账 = 权重 + KV Cache + 激活 + CUDA 上下文。27B 模型 BF16 权重 ≈ 54GB，超过单张 24G 卡——量化（或 TP 多卡）不是可选项。量化同时影响两个测试维度：
- 精度：数值近似引入输出质量退化，必须做评测集回归
- 性能：权重变小 → 访存减少 → decode 提速（decode 是访存密集）；但 dequant 有计算开销，小 batch 下可能得不偿失
2. 主流方案对比（2026）
| 方案 | 位宽 | 显存（27B 权重） | 精度保持 | 适用 |
|---|---|---|---|---|
| BF16（基线） | 16bit | ≈54GB | —（基准） | 多卡/大显存，精度敏感场景 |
| GPTQ | 4/8bit | ≈13.5/27GB | 高（校准集 128-512 条） | 离线量化成熟，CPU 可 dequant |
| AWQ | 4bit | ≈13.5GB | 高（激活感知，保护显著通道） | 4bit 首选之一，GPU 推理快 |
| FP8（E4M3/E5M2） | 8bit | ≈27GB | 很高（浮点动态范围好） | H100/B200 原生支持；消费级卡部分支持 |
| NVFP4 | 4bit 浮点 | ≈7GB | 高（block-wise scale） | 新硬件（Blackwell 系）+ 新引擎版本 |
| LLM.int8 / GGUF Q4_K_M | 8/4bit | 视方案 | 中（GGUF 生态偏端侧） | llama.cpp 系部署 |
量化"精度保持"列是社区基准（MMLU/GSM8K 类）上的相对表现，不能替代本服务的领域内回归——通用基准不掉点 ≠ 业务场景不掉点。
3. 精度验证测试设计
- 定基线：BF16（或上一代已验收量化版本）在同一评测集上的得分作为基准。
- 评测集分层（银行环境建议三层）：
- 通用能力：MMLU / C-Eval / GSM8K 各 200 题（能力面是否塌方）
- 领域回归：业务术语理解、数字计算、合规问答，各 ≥100 条（这是验收关键）
- 红队探针：诱导性/对抗性 prompt 50 条（量化对拒答行为的影响）
- 控制变量：同 prompt、temperature=0（或固定 seed）、max_tokens 一致；每个量化版本跑 3 轮取均值，消除采样噪声。
- 定验收线：与 BF16 基线相比，领域回归集掉点 ≤ 2 分（按百分制）、数字计算类掉点 ≤ 1 分；任一红线不过即否决该量化方案。
⚠️ 数字计算是量化最脆弱的场景：算术 token 序列对单 token 概率扰动极敏感，GSM8K 掉 1 分可能意味着"一步算错、整链错"。涉及金额/利率/合规数字生成的场景，建议维持 BF16/FP8 并保留"结果双算校验"兜底。
4. 量化对性能的验证
- 同硬件同并发下，量化版 vs BF16 版：TPOT 预期下降 10-30%（4bit），吞吐上限因显存释放（KV Cache 空间变大）进一步后移拐点。
- 必须测的交互项：量化 + 长上下文（KV Cache 占比更大，量化收益是否保持）、量化 + 高并发（dequant 计算占比上升，小 batch 优势消失的拐点在哪）。
- 回归口径与基线管理见 性能测试实践。