7B 模型量化降本全复盘：FP32 到 INT4 的精度-成本博弈
一、算力账单的刺痛：每月 12 万推理成本能否砍半
团队为内部业务线部署了基于 Llama-2-7B 微调的对话模型，使用 4 张 A100-80G 部署。每月 12 万的 GPU 租赁费用让预算线吃紧。业务方对推理延迟的要求是 P99 < 500ms，当前的 FP32 部署延迟约 220ms，存在一定的优化空间。
降本最直接的手段是模型量化——将参数精度从 FP32 降到 INT8 或 INT4，减少显存占用从而降低硬件需求。但量化不是免费的午餐，精度损失和推理延迟的变化需要精确评估。
初始方案设计了两条技术路线：GPTQ 离线量化（对权重做 INT4 压缩）和 AWQ（Activation-aware Weight Quantization）。前者实现成熟、生态完善，后者在激活值保护方面更有优势，但工具链支持尚不完善。综合评估后选择 GPTQ 方案，配套使用 vLLM 作为推理引擎。
二、GPTQ 量化的精度评估：不能只看平均分
量化模型的核心风险是精度退化。简单依赖 MMLU 或 CEval 等综合性 benchmark 的平均分变化往往具有欺骗性——整体下降 1% 可能掩盖特定任务下降 8% 的灾难。
建立了一个分层评估体系：
| 维度 | 评估方法 | FP32 基线 | GPTQ-INT8 | GPTQ-INT4 |
|---|---|---|---|---|
| 通用能力 | MMLU 均分 | 64.3 | 63.8 (-0.5) | 62.1 (-2.2) |
| 推理能力 | GSM8K | 52.7 | 51.9 (-0.8) | 48.3 (-4.4) |
| 代码生成 | HumanEval Pass@1 | 36.8 | 35.6 (-1.2) | 31.2 (-5.6) |
| 多轮对话 | MT-Bench | 7.1 | 6.9 (-0.2) | 6.5 (-0.6) |
| 业务定制 | 内部测试集 | 89.2 | 88.7 (-0.5) | 87.1 (-2.1) |
INT8 量化在各维度表现与 FP32 相当，精度损失控制在可接受范围。但 INT4 在代码生成（-5.6）和数学推理（-4.4）上退化明显，不适合需要精确推理的场景。最终的决策是：线上推理服务采用 INT8，离线批量推理采用 INT4。
三、量化工具链与推理引擎的适配
GPTQ 量化使用 AutoGPTQ 库完成，核心流程如下：
# GPTQ 量化流程 —— 离线完成后模型体积缩减 75% from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig from transformers import AutoTokenizer # 1. 定义量化配置 quant_config = BaseQuantizeConfig( bits=8, # 目标位宽 group_size=128, # 量化组大小：越小精度越保真，但压缩比越低 desc_act=False, # 是否按激活值排序量化（降序可减少尾部误差） damp_percent=0.01, # Hessian 矩阵阻尼系数，防止奇异矩阵 ) # 2. 加载模型并执行量化 model = AutoGPTQForCausalLM.from_pretrained( "meta-llama/Llama-2-7b-hf", quantize_config=quant_config, ) # 使用校准数据集计算量化参数 —— 关键步骤，数据质量直接影响精度 model.quantize( calibration_dataset, # 128 条代表性样本即可，覆盖各类任务分布 batch_size=4, use_triton=True, # Triton 加速推理，需 GPU 环境 ) # 3. 保存量化模型 model.save_quantized("./llama-2-7b-gptq-int8") # 4. vLLM 支持直接加载 GPTQ 模型，无需额外转换 # vllm serve ./llama-2-7b-gptq-int8 --quantization gptq在推理引擎层做了两个额外优化来补偿量化带来的延迟变化：
# vLLM 推理配置 —— 针对量化模型调优的参数 from vllm import LLM, SamplingParams llm = LLM( model="./llama-2-7b-gptq-int8", quantization="gptq", # INT8 模型显存减半，可以放大 batch_size 提升吞吐 max_model_len=4096, max_num_seqs=64, # 并发请求数从 FP32 的 32 提升到 64 gpu_memory_utilization=0.92, # 量化后显存更充裕，可提高利用率 enforce_eager=False, # 使用 CUDA Graph 加速 ) sampling_params = SamplingParams( temperature=0.7, top_p=0.95, max_tokens=512, # 量化模型对采样参数更敏感，temperature 过高会放大精度误差 )四、ROI 量化分析：一毛钱都不能白花
上线后的实际数据：
| 指标 | FP32 部署 | INT8 部署 | INT4（离线） |
|---|---|---|---|
| GPU 需求 | 4 张 A100-80G | 2 张 A100-80G | 1 张 A100-80G |
| 月 GPU 成本 | 12 万 | 6 万 | 3 万 |
| 单卡并发请求 | 32 | 64 | — |
| P50 延迟 | 120ms | 145ms (+21%) | — |
| P99 延迟 | 220ms | 260ms (+18%) | — |
| 业务精度 | 89.2% | 88.7% (-0.5%) | 87.1% (-2.1%) |
INT8 部署的年化 GPU 成本从 144 万降至 72 万，降幅 50%。延迟增加约 18%，仍远在 P99 < 500ms 的业务要求线之下。精度损失 0.5% 在业务可接受范围。INT4 离线任务则用更低成本覆盖了数据标注批量推理等非实时场景。
五、总结
模型量化的降本实践有几个关键判断：
- INT8 是生产环境的安全选项：精度损失普遍在 0.5% 以内，显存需求减半，是 ROI 最佳的选择；
- INT4 需按场景分层使用：在代码生成、数学推理等对精度敏感的任务上退化明显，但在多轮对话和文本摘要上表现可接受。建议分层部署——高精度任务用 INT8，批量离线任务用 INT4；
- 分层评估体系比单一 benchmark 更可靠：MMLU 均分下降 0.5% 不代表所有任务都安全。至少覆盖通用能力、推理能力、业务定制三个维度；
- 推理引擎的参数调优不可跳：量化后 max_num_seqs 翻倍、gpu_memory_utilization 上调、温度参数降低，这些配置调整能有效补偿量化带来的延迟开销。
适用边界：本结论基于 7B 参数的 Llama-2 架构模型。13B 以上的模型 INT4 量化对精度的影响通常更小，可更激进地使用。
