模型部署与推理优化中的量化技术全景：INT8矩阵乘、校准与QAT实操

1. 模型部署与推理优化中的量化技术全景

模型部署这件事，做过的人都知道，训练只是万里长征第一步，真正把模型塞进生产环境、跑出可接受的延迟和吞吐，才是真正考验工程能力的环节。而在推理优化的工具箱里，量化几乎是绕不开的一把刀。它不像剪枝那样需要重新训练，也不像蒸馏那样依赖教师模型，量化的核心逻辑非常直接：用更低的数值精度来表示权重和激活值，从而减少内存占用、降低带宽压力、加速矩阵乘法。

我最早接触量化是在一个视觉分类模型的部署项目上。当时模型是FP32的，推理延迟在目标硬件上始终压不下去，后来把权重和激活都量化到INT8，延迟直接降了将近一半，精度只掉了不到0.5个百分点。从那以后，量化就成了我部署流程里的标配环节。

这篇文章会围绕INT8矩阵乘的底层原理、校准（Calibration）的具体做法、量化感知训练（QAT）的实操细节，以及LLM量化的特殊挑战展开。适合有一定深度学习基础、正在做模型部署或推理优化的工程师阅读。如果你刚开始接触量化，建议先理解FP32、FP16、BF16、INT8这几种数值格式的区别，再往下看。

提示：量化不是万能药。有些模型对精度极其敏感，量化后精度崩塌的情况并不罕见。动手之前，先评估模型对数值精度的敏感度。

2. 数值格式与INT8矩阵乘的底层逻辑

2.1 FP32、FP16、BF16、INT8到底差在哪

要理解量化，先得搞清楚这几种数值格式的本质区别。浮点数的表示方式是符号位加指数位加尾数位，不同格式的差异主要体现在指数位和尾数位的分配上。

FP16的指数位只有5位，动态范围很窄，训练时容易出现梯度下溢或上溢。BF16的指数位和FP32一样是8位，所以动态范围完全一致，但尾数只有7位，精度比FP16低。这也是为什么BF16在训练场景中越来越受欢迎——它牺牲了精度换取了稳定性。

INT8则是完全不同的思路。它用8位整数来表示数值，没有指数位和尾数位的概念，就是一个纯粹的整数。INT8的表示范围是-128到127，总共256个离散值。这意味着它只能表示256个不同的数，而FP32可以表示大约40亿个不同的数。量化的本质，就是把这40亿个数的映射关系，压缩到这256个数上。

2.2 INT8矩阵乘为什么快

INT8矩阵乘之所以快，核心原因有三个。

第一是内存带宽。INT8的数据宽度是FP32的四分之一，同样大小的模型，INT8版本占用的内存只有FP32的四分之一。在推理过程中，内存带宽往往是瓶颈，尤其是大模型。数据量少了，搬运时间自然就短了。

第二是计算单元。现代GPU和专用加速器（如NPU、TPU）通常都有专门的INT8计算单元。以NVIDIA的Tensor Core为例，INT8的吞吐量是FP16的两倍，是FP32的四倍。这不是软件层面的优化，而是硬件层面的支持。

第三是指令效率。INT8的乘加运算可以用更少的指令周期完成。在CPU上，INT8的SIMD指令（如AVX2的VPMADDUBSW）可以一次处理更多的数据。

不过，INT8矩阵乘并不是简单地把FP32的乘法换成整数乘法。它需要一套完整的量化方案，包括如何把浮点数映射到整数、如何处理零点偏移、如何累加结果并反量化。这些细节决定了量化的精度和速度。

2.3 对称量化与非对称量化的选择

量化方案主要分为对称量化和非对称量化两种。

对称量化的公式很简单：

q = round(x / scale) x_hat = q * scale

其中scale是一个正数，表示量化步长。对称量化的零点固定在0，所以量化后的整数范围是对称的，比如-127到127。它的优点是计算简单，矩阵乘的时候不需要额外处理零点偏移。

非对称量化则多了一个零点参数：

q = round(x / scale) + zero_point x_hat = (q - zero_point) * scale

zero_point是一个整数，表示浮点数0对应的量化值。非对称量化的优点是能够更好地利用INT8的表示范围，尤其是当数据分布不对称时（比如ReLU之后的激活值全是非负的）。

在实际部署中，权重的分布通常是对称的，所以权重一般用对称量化。激活值的分布往往不对称，所以激活值一般用非对称量化。但这也不是绝对的，具体要看硬件支持哪种模式。有些加速器只支持对称量化，那就只能统一用对称方案。

注意：对称量化和非对称量化的选择不是拍脑袋决定的，要看目标硬件的指令集支持。选错了方案，可能根本跑不起来。

3. 校准：让量化误差可控的关键步骤

3.1 校准到底在做什么

校准（Calibration）是训练后量化（PTQ）的核心环节。它的目的是确定量化参数，也就是scale和zero_point。为什么需要校准？因为量化参数不是随便定的，它取决于数据的实际分布。

举个例子，假设某一层的激活值范围是-3.2到5.8。如果直接用这个范围来量化，scale就是(5.8 - (-3.2)) / 255 ≈ 0.035。但如果实际推理时，激活值的范围可能更大或更小，量化参数就不准了。校准就是用一批代表性数据跑一遍模型，统计每一层激活值的实际分布，然后根据这个分布来确定量化参数。

校准数据的选取非常关键。它不需要标注，但必须能代表真实推理时的数据分布。通常从训练集或验证集中随机抽取几百到几千个样本就够了。如果校准数据分布和实际推理数据分布差异太大，量化后的精度会明显下降。

3.2 常见的校准方法对比

校准方法主要有以下几种：

Min-Max校准是最简单的方法，直接取激活值的最大值和最小值来确定量化范围。它的优点是计算快，缺点是对异常值非常敏感。如果某个样本的激活值特别大，整个量化范围就会被拉大，导致大部分值的量化精度下降。

Moving Average Min-Max是对Min-Max的改进，它不直接用当前batch的最大最小值，而是用滑动平均来平滑。这样可以减少异常值的影响，但滑动平均的系数需要调。

KL散度校准（也叫熵校准）是TensorRT默认使用的方法。它的思路是找到一个量化范围，使得量化后的分布和原始分布的KL散度最小。具体做法是：先统计激活值的直方图，然后尝试不同的截断阈值，计算截断后量化分布和原始分布的KL散度，取KL散度最小时的阈值作为量化范围。这种方法比Min-Max更鲁棒，但计算量更大。

百分位校准是取激活值的某个百分位（比如99.9%）作为最大值，忽略掉极端值。这种方法在实践中最常用，因为它简单且效果稳定。

3.3 校准实操：以ONNX模型为例

假设你有一个ONNX格式的模型，想用ONNX Runtime做INT8量化。基本流程是这样的：

首先准备校准数据。校准数据需要是一个DataLoader或者numpy数组，形状要和模型输入匹配。通常取100到500个样本就够了。

import numpy as np from onnxruntime.quantization import quantize_static, CalibrationDataReader class MyCalibrationReader(CalibrationDataReader): def __init__(self, calibration_data): self.data = calibration_data self.index = 0 def get_next(self): if self.index >= len(self.data): return None batch = self.data[self.index] self.index += 1 return {"input": batch} calibration_data = np.random.randn(200, 3, 224, 224).astype(np.float32) reader = MyCalibrationReader(calibration_data) quantize_static( model_input="model.onnx", model_output="model_int8.onnx", calibration_data_reader=reader, quant_format=QuantFormat.QDQ, per_channel=True, activation_type=QuantType.QUInt8, weight_type=QuantType.QInt8 )

这里有几个关键参数需要解释。quant_format选QDQ表示在模型中插入QuantizeLinear和DequantizeLinear节点，这是ONNX量化的标准格式。per_channel=True表示权重按通道量化，而不是按张量量化。按通道量化精度更高，但计算量稍大。activation_type和weight_type分别指定激活和权重的量化类型。

实操心得：校准数据的batch size不要太大，否则内存吃不消。我一般用batch size 1，跑200到500个样本。另外，校准数据一定要做和推理时一样的预处理，否则量化参数会偏。

3.4 校准中的常见坑

校准过程中最容易踩的坑是数据预处理不一致。比如训练时输入是归一化到[-1, 1]的，校准的时候忘了归一化，直接用原始像素值，那量化参数就完全错了。这种错误很隐蔽，因为模型还是能跑，只是精度会莫名其妙地下降。

另一个坑是校准数据量不足。有些人为了省时间，只跑几十个样本。如果模型层数多、分布复杂，几十个样本根本覆盖不了真实分布。我的经验是至少200个样本，复杂模型建议500到1000个。

还有一个坑是忽略了某些层的特殊性。比如第一层和最后一层，通常对精度更敏感。有些量化工具允许跳过特定层，这时候可以把这些层排除在量化之外。

4. QAT：量化感知训练的实操细节

4.1 QAT和PTQ的本质区别

PTQ是在模型训练完成后直接量化，不需要重新训练。QAT则是在训练过程中模拟量化误差，让模型学会适应量化后的数值精度。

为什么需要QAT？因为PTQ有一个根本性的问题：量化误差是事后引入的，模型在训练时并不知道自己会被量化。有些层对量化误差很敏感，PTQ之后精度会明显下降。QAT通过在训练时插入伪量化节点，让模型在训练过程中就感受到量化误差，从而调整权重来补偿。

QAT的代价是需要重新训练，训练时间可能和原始训练差不多。但它的精度通常比PTQ高，尤其是在低比特量化（比如4比特）时优势更明显。

4.2 QAT的训练流程

QAT的训练流程和普通训练有几个关键区别。

第一步是插入伪量化节点。伪量化节点在前向传播时模拟量化误差，在反向传播时使用直通估计器（Straight-Through Estimator, STE）来传递梯度。STE的核心思想是：量化函数的梯度几乎处处为零，无法直接反向传播，所以干脆让梯度直接穿过量化节点，不做任何变换。

第二步是冻结量化参数。在QAT的后期，通常需要冻结scale和zero_point，只训练权重。这是因为量化参数如果一直变化，模型很难收敛。

第三步是微调学习率。QAT的学习率通常比原始训练小一到两个数量级。因为模型已经训练好了，QAT只是微调，不需要大的学习率。

import torch import torch.quantization model = MyModel() model.load_state_dict(torch.load("pretrained.pth")) model.qconfig = torch.quantization.get_default_qat_qconfig("fbgemm") model_fused = torch.quantization.fuse_modules(model, [["conv", "bn", "relu"]]) model_prepared = torch.quantization.prepare_qat(model_fused) optimizer = torch.optim.SGD(model_prepared.parameters(), lr=1e-5, momentum=0.9) for epoch in range(10): for data, target in train_loader: optimizer.zero_grad() output = model_prepared(data) loss = criterion(output, target) loss.backward() optimizer.step() model_prepared.eval() model_int8 = torch.quantization.convert(model_prepared)

这段代码展示了PyTorch中QAT的基本流程。fuse_modules把Conv、BN、ReLU融合成一个模块，这是量化的标准预处理步骤。融合之后，BN的参数会被吸收到Conv的权重里，减少计算量。

4.3 QAT中的关键技巧

QAT有几个技巧值得单独说。

BN层的处理是QAT中最容易出问题的地方。BN层在训练时统计均值和方差，在推理时使用固定的统计量。QAT时，BN的统计量会随着训练更新，这会影响量化参数。通常的做法是在QAT的最后几个epoch冻结BN的统计量，让量化参数稳定下来。

学习率调度也很关键。我一般用余弦退火，初始学习率设为原始训练的十分之一，然后逐渐降到零。这样模型能在初期快速适应量化误差，后期稳定收敛。

逐层敏感度分析可以帮助你决定哪些层需要QAT，哪些层可以直接PTQ。做法是逐层量化，观察精度变化。对精度影响大的层用QAT，影响小的层用PTQ。这样可以节省训练时间。

注意：QAT不是万能的。如果模型本身对数值精度极其敏感，QAT也救不回来。这种情况下需要考虑混合精度量化，或者干脆放弃量化。

5. LLM量化：大模型时代的特殊挑战

5.1 LLM量化的难点在哪

LLM量化和小模型量化有本质区别。小模型参数量少，量化误差容易被模型容量吸收。LLM参数量巨大，量化误差会累积，导致输出质量明显下降。

LLM量化的第一个难点是激活值的异常值。研究发现，LLM的激活值中存在极少数非常大的值，这些异常值会主导量化范围，导致大部分值的量化精度下降。这个问题在Transformer的某些层尤其严重。

第二个难点是权重的分布不均匀。LLM的权重在不同通道之间的分布差异很大，有些通道的权重量级很大，有些很小。如果统一量化，小量级的通道会损失很多精度。

第三个难点是KV Cache的量化。LLM推理时，KV Cache占用大量内存。量化KV Cache可以显著减少内存占用，但KV Cache的分布和权重、激活都不同，需要单独处理。

5.2 LLM量化的主流方案

目前LLM量化主要有几种方案。

GPTQ是一种训练后量化方法，它逐层量化权重，用Hessian矩阵来指导量化误差的最小化。GPTQ可以把LLM量化到4比特甚至3比特，精度损失可控。它的缺点是量化过程需要跑一遍校准数据，时间较长。

AWQ（Activation-aware Weight Quantization）的核心思想是：不是所有权重都同等重要，应该根据激活值的分布来保护重要的权重通道。AWQ通过缩放重要通道的权重，让它们在量化后保留更多信息。

SmoothQuant的思路是把激活值的量化难度转移到权重上。具体做法是对激活值除以一个缩放因子，同时把权重乘以这个缩放因子。这样激活值的异常值被平滑了，权重的量化难度增加了，但总体量化误差更小。

GGUF格式是llama.cpp使用的量化格式，它支持多种量化级别，从2比特到8比特都有。GGUF的优点是推理效率高，适合在CPU上跑。

5.3 LLM量化的实操建议

如果你要量化一个LLM，我的建议是从8比特开始，逐步降到4比特。8比特量化通常精度损失很小，可以直接用。4比特量化需要仔细评估，不同模型的敏感度差异很大。

校准数据的选择对LLM量化特别重要。我一般用模型训练数据的一个子集，或者用领域相关的文本。校准数据的长度要和推理时的输入长度匹配，否则量化参数会偏。

KV Cache的量化需要单独配置。有些框架支持KV Cache的INT8量化，但需要额外的校准步骤。如果内存不是瓶颈，可以先不量化KV Cache，只量化权重。

实操心得：LLM量化后一定要做端到端的评估，不能只看困惑度（Perplexity）。困惑度下降不多不代表生成质量没问题。我遇到过困惑度只涨了0.1，但生成结果明显变差的情况。建议用实际任务做评估，比如问答、摘要、翻译。

6. 常见问题与排查技巧实录

6.1 量化后精度下降太多怎么办

精度下降是量化最常见的问题。排查思路是这样的：

首先确认校准数据是否正确。检查预处理是否和推理时一致，检查数据量是否足够。这是最容易出问题的地方，也是最先要排查的。

如果校准数据没问题，那就逐层分析。用工具（如ONNX Runtime的debug模式）输出每一层的量化误差，找到误差最大的层。对这些层尝试跳过量化，或者用更高的比特数。

如果逐层分析也解决不了，那就考虑QAT。QAT通常能挽回大部分精度损失，但需要重新训练。

还有一种可能是模型本身就不适合量化。有些模型（比如某些注意力机制特殊的模型）对数值精度极其敏感，量化后精度必然下降。这种情况下，要么接受精度损失，要么放弃量化。

6.2 量化后推理速度没提升

速度没提升的原因通常有几个。

第一是硬件不支持INT8加速。有些老旧的GPU或CPU没有INT8计算单元，量化后反而要额外做反量化，速度更慢。确认硬件是否支持INT8指令集。

第二是量化粒度太细。如果per-channel量化，每个通道都要单独计算scale，开销可能抵消了INT8的计算优势。可以尝试per-tensor量化。

第三是内存带宽不是瓶颈。如果模型很小，计算量不大，量化带来的带宽优势不明显。这种情况下，量化可能不会带来明显的速度提升。

第四是框架实现问题。有些框架的INT8推理实现不够优化，实际速度可能不如预期。可以尝试不同的推理框架，比如TensorRT、OpenVINO、ONNX Runtime，看哪个效果最好。

6.3 量化参数怎么调

量化参数主要有scale、zero_point、量化范围。

scale和zero_point通常由校准自动确定，不需要手动调。但如果自动校准效果不好，可以手动指定。比如某些层的激活值范围已知，可以直接设置scale。

量化范围的选择需要权衡。范围太大，量化精度低；范围太小，异常值会被截断。通常用百分位校准来确定范围，比如取99.9%分位数。

per-channel还是per-tensor也需要选择。per-channel精度更高，但计算量更大。如果硬件支持per-channel，优先用per-channel。如果不支持，只能用per-tensor。

6.4 常见问题速查表

7. 量化工具链选型与实战建议

7.1 主流量化工具对比

量化工具的选择取决于你的部署目标。如果是GPU部署，TensorRT是首选，它的INT8推理优化最成熟。如果是CPU部署，OpenVINO和ONNX Runtime都不错。如果是移动端，TFLite和NCNN更合适。

PyTorch原生支持QAT和PTQ，适合在训练框架内完成量化。TensorFlow也有类似的工具。ONNX作为中间格式，支持多种量化工具，灵活性最高。

7.2 我的量化工作流

我自己的量化工作流是这样的：

第一步，用FP32模型跑一遍基准测试，记录精度和延迟。这是后续对比的基准。

第二步，用PTQ做初步量化，评估精度损失。如果精度损失在可接受范围内（比如1%以内），直接用PTQ。

第三步，如果PTQ精度不够，尝试不同的校准方法。Min-Max不行就换KL散度，KL散度不行就换百分位。

第四步，如果校准方法都试过了还是不行，上QAT。QAT通常能挽回大部分精度损失。

第五步，量化后做端到端测试，确认精度和速度都达标。

第六步，部署到目标硬件，做实际性能测试。有时候开发机上的结果和部署环境差异很大。

实操心得：量化不是一次性的工作。模型更新、数据分布变化、硬件升级，都可能需要重新量化。建议把量化流程脚本化，方便重复执行。

7.3 量化后的模型验证

量化后的模型验证不能只看精度指标。我一般会做以下几项检查：

精度对比：量化模型和原始模型在验证集上的精度差异。通常要求差异小于1%。

速度对比：量化模型和原始模型的推理延迟和吞吐量。确认量化确实带来了速度提升。

内存对比：量化模型和原始模型的内存占用。确认内存确实减少了。

输出一致性：随机抽取一些样本，对比量化模型和原始模型的输出。如果输出差异很大，说明量化可能有问题。

边界测试：用极端输入测试量化模型，看是否会出现溢出或异常。INT8的表示范围有限，极端输入可能导致溢出。

量化是推理优化的核心手段之一，但它不是银弹。理解量化的原理，掌握校准和QAT的实操细节，根据模型和硬件选择合适的方案，才能真正发挥量化的价值。我在实际项目中的体会是，量化带来的收益往往超出预期，但前提是你要愿意花时间调校和验证。