量化方案全景对比：INT8、FP8 与混合精度在生产推理环境中的实测数据

量化方案全景对比：INT8、FP8 与混合精度在生产推理环境中的实测数据

一、精度与速度的拉锯战：大模型量化不是"一刀切"的简单决策

大模型推理的成本压力使得量化成为必选项而非可选项。一个 70B 参数的模型在 FP16 下需要 140GB 显存，两张 A100 才勉强装下；而 INT8 量化后仅需 70GB，单张 A100 即可部署，吞吐量提升约 2x。但量化带来的精度损失并非均匀分布——某些任务（对话生成）几乎无感，另一些任务（数学推理）退化显著。

核心痛点在于：不同量化方案在不同任务上的精度-速度 Trade-off 差异巨大，盲目选择 INT8 或 FP8 可能导致关键业务指标退化超预期。本次复盘将基于实测数据，对主流量化方案进行全景对比，给出场景化的选型建议。

二、量化机制深度剖析：从浮点到整数的映射与信息损失

量化的本质是将高精度浮点数映射到低精度整数空间，映射过程中的信息损失是精度退化的根源。

INT8 对称量化的信息损失集中在小权重区域——当权重分布集中于 [-0.1, 0.1] 区间时，映射到 [-127, 127] 的整数空间后，相邻整数的间距约为 0.0008，这个分辨率对于微小权重差异可能不够。FP8 量化保留了浮点结构，E4M3 格式有 4 位指数和 3 位尾数，在数值密集区比 INT8 保留更多信息，但动态范围上限仅 ±448，对于某些大权重值可能溢出。

三、量化实现：GPTQ、AWQ 与 FP8 的代码级对比

3.1 GPTQ 逐层量化实现原理

# GPTQ 量化核心逻辑（简化示意） # 目的：逐层量化，利用 Hessian 信息最小化量化误差 import torch def gptq_quantize_layer(weight, hessian_inv, block_size=128, bits=8): """ GPTQ 逐层量化算法： 1. 将权重按 block_size 分块 2. 对每个块内权重，按 Hessian 逆矩阵的对角线元素排序 3. 优先量化对输出影响最小的权重列 4. 量化一列后，立即用 Hessian 信息修正剩余列，补偿误差 """ quantized = torch.zeros_like(weight, dtype=torch.int8) scale = torch.zeros(weight.shape[0]) errors = torch.zeros_like(weight) # Hessian 逆矩阵的对角线，反映每列权重对输出的敏感度 # 对角线值越小 → 该列对输出影响越小 → 优先量化 diag_hessian = torch.diag(hessian_inv) for i in range(0, weight.shape[1], block_size): block_end = min(i + block_size, weight.shape[1]) block = weight[:, i:block_end] # 按敏感度排序：影响最小的列优先量化 sensitivity = diag_hessian[i:block_end] order = torch.argsort(sensitivity) for col_idx in order: col = weight[:, i + col_idx] # 计算当前列的量化 scale max_val = torch.max(torch.abs(col)) col_scale = max_val / ((2 ** (bits - 1)) - 1) scale[i + col_idx] = col_scale # 量化并计算量化误差 q_col = torch.round(col / col_scale).clamp(-127, 127) quantized[:, i + col_idx] = q_col.to(torch.int8) err = (col - q_col * col_scale) / diag_hessian[i + col_idx] # 关键步骤：用 Hessian 信息将误差分配到剩余未量化列 # 这是 GPTQ 精度优于 RTN（Round-To-Nearest）的核心原因 remaining_cols = block[:, col_idx+1:] correction = err.unsqueeze(1) * hessian_inv[i + col_idx, i+col_idx+1:block_end] weight[:, i+col_idx+1:block_end] -= correction return quantized, scale

3.2 FP8 推理配置

# FP8 推理配置（基于 TransformerEngine） # 目的：利用 FP8 格式在 NVIDIA H100 上实现高吞吐推理 import transformer_engine as te import transformer_engine.pytorch as te_pytorch def setup_fp8_inference(model): """ FP8 推理配置： 1. 前向传播中权重从 FP16 转换为 FP8 (E4M3) 2. 梯度计算中使用 FP8 (E5M2) 格式（更大动态范围） 3. 激活值同样使用 FP8 存储 """ # FP8 格式选择策略： # E4M3：4位指数+3位尾数，精度更高但范围小，用于权重和前向激活 # E5M2：5位指数+2位尾数，范围更大但精度低，用于反向传播梯度 fp8_format = te.recipe.Format.E4M3 # 推理场景仅使用 E4M3 # 替换模型中的 Linear 层为 FP8 兼容版本 for name, module in model.named_modules(): if isinstance(module, torch.nn.Linear): # 保留 FP16 权重，推理时动态转换为 FP8 # 为什么不直接存储 FP8 权重： # FP8 动态范围有限，存储阶段需要更高精度缓冲 fp8_linear = te_pytorch.Linear( in_features=module.in_features, out_features=module.out_features, bias=module.bias is not None, fp8_input=True, # 输入激活使用 FP8 fp8_weight=True, # 权重推理时转 FP8 ) # 复制原始权重到 FP8 层 fp8_linear.weight.data.copy_(module.weight.data) return model

四、实测数据：不同量化方案在不同任务上的精度-速度全景对比

在 LLaMA-2-70B 模型上，使用 A100 (80GB) 进行实测：

关键发现：

1. GPTQ vs AWQ：AWQ 在所有任务上优于 GPTQ，因为 AWQ 基于激活值感知量化，保留了对输出影响最大的权重通道的精度。但 AWQ 的量化过程本身更耗时（需要校准数据集前向传播）。

2. FP8 的悖论：在 H100 上 FP8 吞吐最高（95 token/s），但精度损失在数学推理任务上比 INT8 GPTQ 更大。这是因为 E4M3 的动态范围限制在 ±448，某些权重值溢出后被截断。

3. 混合精度最优但代价高：精度损失最小（<0.3%），但显存仍需 85GB，吞吐仅提升 50%，性价比不如 INT8 AWQ。

适用边界：对话生成类业务（精度容忍度高）推荐 INT8 AWQ 或 FP8；数学推理/代码生成类业务（精度敏感）推荐混合精度或 INT8 GPTQ + 敏感层保护；资源极度受限场景（单卡 T4）推荐 INT4 AWQ（本文未展开）。

五、总结

量化方案选型不是简单的精度-速度二元选择，而是需要根据具体任务特征做场景化决策：

1. 任务类型决定量化策略：对话生成对精度容忍度高，INT8/FP8 即可；数学推理和代码生成精度敏感，需要混合精度或激活感知量化。

2. AWQ 是当前综合最优的 INT8 方案：基于激活值感知的通道级量化，在精度和吞吐之间取得了最佳平衡。GPTQ 适合需要逐层精细控制的场景。

3. FP8 需要硬件支持才能发挥优势：H100 的 FP8 Tensor Core 提供了吞吐量优势，但精度损失不可忽视。在非 H100 硬件上，FP8 的性能优势不成立。

落地建议：第一步确认业务任务的精度容忍度阈值；第二步根据阈值选择量化方案——阈值 > 1% 选 INT8 AWQ，阈值 < 0.5% 选混合精度；第三步用校准数据集实测目标任务的精度退化；第四步根据实测结果微调敏感层保护策略。量化选型必须以实测数据为依据，而非理论推算。