TensorRT INT8量化实战：PTQ与QAT全流程解析

做深度学习推理的人，几乎都逃不过两个词：更慢、更胖。模型越来越大，线上推理成本越来越高，单卡吞吐上不去，响应延迟压不下来。这两年遇到最多的问题就是“模型跑起来了但扛不住流量”，而TensorRT的INT8量化，是我目前觉得性价比最高的优化手段之一。一套PTQ流程跑下来，常见视觉模型基本能拿到1.2到2倍的推理加速，显存占用砍掉一半以上，精度损失还能控制在可接受范围。如果PTQ不够，再切到QAT微调，精度基本能拉回和FP32几乎持平的水平。

这篇内容不搞花活，直接从工程角度讲清楚PTQ和QAT两条路线在TensorRT里怎么落地，包括ONNX导出、校准集准备、Calibrator实现、量化感知训练的细节，以及实际踩过的坑。适合已经把模型部署过一遍、想压榨推理性能的开发者，也适合正在评估量化收益、不确定该选哪条路的团队参考。

1. 动手之前，先把量化的账算明白

1.1 INT8量化到底省在哪、快在哪

量化本质上是把网络里的权重和激活值从FP32表示压缩到INT8表示。FP32用4字节存一个数，INT8用1字节，光权重这一项，模型体积直接缩到四分之一。推理过程中的矩阵乘法，在GPU上从FP32的CUDA Core计算切换到INT8的Tensor Core计算，吞吐量和延迟都有实打实的提升。

TensorRT的INT8推理不是简单地把算子换成低精度实现，它内部会用量化后的权重计算GEMM，然后把中间结果反量化为更高精度再传给下一层。得益于GPU架构里的INT8 Tensor Core，INT8 GEMM的理论算力常常是FP32的好几倍。实测下来，分类模型在常见GPU上的INT8推理延迟通常能降到FP32的60%到80%，显存占用也能大幅减少。

但这笔账有个前提——量化是有损的。FP32到INT8，数值表示精度降了两个数量级，权重分布不合理或者激活值动态范围没校准好，精度就会明显下跌。所以量化部署从来不是“打开开关就完事”，核心是在压缩和精度之间找平衡点。

1.2 精度损失到底从哪来

一个32位的浮点数被强行映射成8位整数，最直接的影响是数值表示的精度和范围都变了。训练好的模型，尤其是BatchNorm层之后的激活分布，往往呈现出很明显的尖峰特征——大部分数值集中在某个小区间内，但偶尔有离群值。INT8只能表示256个离散的整数档位，把一段连续浮点区间映射过去，一定会产生舍入误差。

更隐蔽的问题是层与层之间的误差累积。浅层的一点点量化误差，经过十几层的卷积、池化、激活放大之后，到输出层可能就被放大得非常明显。尤其是检测、分割这类任务，特征图的空间结构很敏感，局部特征的误差可能直接影响最终定位和分类结果。

所以量化部署的关键动作不是“把模型转成INT8”，而是“校准”——搞清楚每层激活值的真实动态范围，用恰到好处的scale和zero point去量化，让误差尽可能平均地分布在有效数值范围内。这也是为什么PTQ需要准备校准数据集、QAT需要真实训练数据的原因。

1.3 PTQ和QAT的本质差异

PTQ（训练后量化）和QAT（量化感知训练）两条路线，本质差别在于“有没有让模型在训练阶段就尝到量化的苦头”。

PTQ是模型训练完之后再做量化，你只需要准备几百张代表性数据跑一遍校准流程，让TensorRT统计每层激活值的分布，然后据此算出量化参数。过程快、成本低，通常几十分钟就能完成，适合绝大多数相对稳定的模型。缺点是如果模型的激活值分布特别糟糕，或者对数值误差敏感度很高，PTQ校准后精度可能会掉到不可接受的程度。

QAT则是在训练阶段就引入伪量化操作——前向传播时把权重和量化输入/激活模拟成INT8精度，反向传播时仍然用保存的高精度权重更新。这样模型会在训练过程中自动学着适应量化误差，把对精度影响大的数值范围调整得更稳健。QAT需要完整的数据集和训练流程，周期以小时甚至天计，但精度恢复效果明显更好，适合PTQ救不回来的模型。

选哪个，一看预期精度指标，二看手里有多少训练资源和时间。先说清楚：不是所有模型都需要QAT，大多数场景PTQ已经够用。但如果PTQ跑完精度掉超过1到2个点、对线上业务影响明显，那QAT就是下一步必须走的路。

2. PTQ实操：TensorRT训练后量化全流程

2.1 ONNX导出：量化之前的最后一道坎

TensorRT走PTQ，第一步肯定是把训练好的PyTorch模型转成ONNX。这一步看起来简单，实际操作里九成问题都出在这里。TensorRT对ONNX算子的支持分三档：原生支持、通过插件支持、完全不支持。模型里如果用了自定义算子或者动态控制流，ONNX导出时要么转不出来，要么导出的图里带一堆小碎算子，TensorRT解析时直接报错。

PyTorch导出ONNX时建议用torch.onnx.export，设置opset_version=13左右，配合dynamic_axes参数把batch维度和关键空间维度定义成动态。举个例子：输入shape是[1, 3, 224, 224]，如果想支持动态batch，写成：

dynamic_axes = { "input": {0: "batch", 2: "height", 3: "width"}, "output": {0: "batch"} } torch.onnx.export( model, dummy_input, "model.onnx", opset_version=13, input_names=["input"], output_names=["output"], dynamic_axes=dynamic_axes )

导出后我会先用onnxruntime快速验证一遍ONNX的输出和PyTorch原始输出的误差，确认图结构和数值没问题，再去碰TensorRT。这一步叫“噪声检查”也好，叫“提前排雷”也好，成本低收益高。

ONNX里如果遇到不支持的算子，常见办法一个是改模型结构绕开，另一个是给TensorRT写plugin。我的建议是优先改模型结构，plugin维护成本高，跨版本升级经常炸。比如某些模型用了F.grid_sample做特征采样，转ONNX出来的子图长且碎，性能还差，不如改成等价的卷积加插值实现。

2.2 校准集准备：几百张图，比想象中讲究

PTQ在TensorRT里叫“calibration”，中文叫校准。核心流程是跑一组有代表性的数据，统计每一层激活值的直方图分布，然后根据分布特征算出每个张量的量化尺度和零点。选择的校准方法不同，统计口径和参数确定策略也不同。

TensorRT主要提供三种校准算法，在8.x版本里分别对应EntropyCalibratorV2、MinMaxCalibrator和LegacyCalibrator。最常用的是熵校准，它用KL散度找到让量化前后信息损失最小的截断阈值，对大多数模型效果最好。MinMax就是简单粗暴地取激活值的最小最大值作为量化范围，实现最简单，但容易被离群值带偏。Legacy是旧版本的熵校准实现，新项目一般不用。

校准集的选取直接影响量化质量，我踩过一次很深的坑：第一次用训练集按batch顺序抽了1000张图做校准，跑出来的INT8模型在测试集上精度掉了将近2个点。后来换了个思路，用验证集按类别均匀采样、并且混入一些亮度分布差异较大的图像，精度恢复到了-0.5%以内。原因很容易理解：校准集要覆盖模型在真实业务里遇到的数据分布，单一来源、单一场景的数据不足以代表全局。

校准集建议准备500到1000张图像，太少统计不充分，太多也没必要，校准过程会额外多跑一次推理，时间成本会随之上升。关键原则概括成一句话：校准集的分布要尽量接近线上真实数据分布。

2.3 Calibrator实现细节与Engine构建

TensorRT的校准器需要继承IInt8Calibrator接口，实现几个核心方法。PyTorch场景下，比较常见的实现方式是把校准数据做成Python生成器，每次回调返回一个batch的输入。

核心代码大概是这个模样：

import tensorrt as trt import numpy as np import torch class PyTorchCalibrator(trt.IInt8Calibrator): def __init__(self, dataloader, cache_file=""): trt.IInt8Calibrator.__init__(self) self.dataloader = dataloader self.buffer = None self.cache_file = cache_file self.index = 0 def get_batch_size(self): return 32 def get_batch(self, names): if self.index >= len(self.dataloader): return None input_tensor = next(iter(self.dataloader))[0] self.buffer = input_tensor.contiguous().numpy() self.index += 1 return [self.buffer] def read_calibration_cache(self): if self.cache_file: with open(self.cache_file, "rb") as f: return f.read() return None def write_calibration_cache(self, cache): if self.cache_file: with open(self.cache_file, "wb") as f: f.write(cache)

值得注意的是read_calibration_cache和write_calibration_cache。第一次跑校准得到的结果会被缓存到文件里，下次直接读缓存，不用重新跑校准。这个机制在调精度的过程中非常有用——模型结构没变、校准集没变的情况下，反复构建engine会快很多。

构建INT8 engine的关键配置是设置BuilderFlag.INT8，把校准器传进去：

builder = trt.Builder(logger) network = builder.create_network(EXPLICIT_BATCH) parser = trt.OnnxParser(network, logger) parser.parse_from_file("model.onnx") config = builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 << 30) config.set_flag(trt.BuilderFlag.INT8) config.int8_calibrator = calibrator engine = builder.build_serialized_network(network, config)

构建期的一些细节也很关键。TensorRT在INT8模式下会自动对网络里的每层尝试量化，但有些层本身对精度特别敏感，比如一些小的检测头、最后的分类层。这种情况下可以显式把这些层设置为FP32或FP16运行。TensorRT 8.x支持config.set_precision和set_tactic级别的层精度控制，但精度控制粒度越细，调优工作量越大，建议先把粗粒度版本跑通，再逐层排查精度瓶颈。

2.4 PTQ精度掉点与补救方案

PTQ跑完之后，最常见的情况是：延迟降下来了，但精度掉幅超过预期。这时候先不要急着上QAT，有几个简单手段可以救。

第一，检查校准集质量。校准集不够代表性，量化参数就整体跑偏，换一套更贴近真实分布的校准集重跑一次，很多时候问题就解决了。

第二，改用不同校准算法。默认熵校准跑出来不好，可以试试MinMax。激活值分布呈均匀形态的任务，MinMax往往表现不错。

第三，精度敏感的层回退到更高精度。TensorRT里有LayerPrecision可以按层指定精度，可以在精度掉幅严重的关键层强制使用FP16甚至FP32，典型对象是最后的FC层和某些敏感的反卷积层，大多数情况下这种目的性明确的精度混合组合就能把整个模型的量化精度拉回到容忍范围。

第四，检查是否存在不支持的算子导致的图优化失败。TensorRT解析ONNX时会把支持的算子融合成更高效的实现，不支持的算子保留原样运行，这些未融合的子图在INT8模式下可能反而变得更慢或精度更差。用trtexec --dumpProfile或Polygraphy看一下网络结构，能直观看到哪些层跑在低效路径上。

如果这些手段都试过，精度仍然不达标，那基本可以判定这个模型天然不适合PTQ，下一步老老实实走QAT。

3. QAT实操：量化感知训练的正确打开方式

3.1 QAT到底改了模型的什么

QAT的全称是Quantization-Aware Training，核心思想是在训练阶段让模型“预演”量化过程，这样网络能学会保持鲁棒性，从而抵抗量化误差的累积。

PyTorch里QAT的典型流程是：定义模型 → 把普通nn.Conv2d、nn.Linear替换成带FakeQuantize的版本 → 插入Observer统计激活和权重的动态范围 → 用训练数据跑前向反向 → 导出UNNQ蒸馏后的ONNX。

PyTorch的量化工具链在2.0之后统一到了torch.ao.quantization，相比老版本torch.quantizationAPI更清晰。先看模型结构，然后依次做：

import torch.ao.quantization as quant model.qconfig = quant.get_default_qconfig("fbgemm") quant.prepare_qat(model, inplace=True)

prepare_qat会沿着网络图结构把量化节点插入到各个关键位置。前向计算时，权重会被fake量化到INT8精度，反向传播时则依然使用原始浮点权重，这样梯度可以正常流动，不会因为量化而出现梯度为零的情况。训练过程中Observer会记录每层权重和激活的数值范围，训练结束后这些统计出来的scale和zero point会直接作为导出时的量化参数。

这期间的关键是训练策略。QAT不是从头重训模型，而是在已经收敛的高精度模型上做微调。学习率通常要降到原来的十分之一甚至更低，用SGD或AdamW都行，重点是不能训练太久——一般几个epoch就能看到效果，训练太久反而可能让模型因为学习率过高而在新任务上震荡漂移。

训练数据不需要完整训练集的全部数据，但至少要有足够的类别覆盖和数据多样性。因为QAT本质上是重新校准整个网络的数值分布，数据太偏的话，训练出来的量化参数也容易偏。

3.2 PyTorch侧模型改造的完整路径

QAT前需要先确定哪些层参与量化。默认情况下PyTorch会用量化配置处理所有Conv和Linear层，但对某些特殊结构需要手工标记。

常见做法：对模型的feature extractor层开启量化，对head层保持高精度。实现上可以用torch.ao.quantization.quantize_fx的FX图模式，也可以用手动方式替换模块。

FX图模式是现在推荐的方式，它能自动分析模型的计算图、找到可以量化的模块和边界：

from torch.ao.quantization import ( QConfigMapping, get_default_qconfig_mapping, prepare_qat_fx, convert_fx, ) m = prepare_qat_fx( model, qconfig_mapping, example_inputs )

FX模式下可以指定哪些模块不量化：

qconfig_mapping = QConfigMapping() qconfig_mapping.set_module_name("head", None)

我踩过一个非常有代表性的坑：模型里有一个自定义的RoIAlign算子，PyTorch的量化工具不支持它，FX模式跑prepare时直接报错。最后的解决办法是把该算子包在一个nn.Module里，然后通过set_module_name把它标记为不量化，保住输入输出精度，只量化前端的Backbone。这种混合精度策略在检测模型里非常实用，Backbone承担大部分计算量，感受一下收益就知道为什么值得做。

3.3 QAT模型转ONNX的隐藏细节

QAT训练完成之后，需要把模型转成TensorRT可用的ONNX。这里有一个容易踩的坎：直接把QAT模型转ONNX，导出图里会包含大量的Quantize/Dequantize节点。TensorRT 8.x版本对这类ONNX支持度尚可，但图结构一旦复杂化就容易解析出问题。

我的建议是先做一步模型重组：把QAT后带带fake quant特的模型，通过torch.ao.quantization的convert方法转成推理格式，然后再导出ONNX。convert会把fake quantize节点折叠成真正的量化参数，导出出来的ONNX会更加简洁、更利于TensorRT解析。

model = convert_fx(model) model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "model_qat.onnx", opset_version=13, dynamic_axes=dynamic_axes )

转换成推理模式后的模型，量化参数已经固化在权重里。TensorRT加载此类ONNX时，识别到Q/DQ节点，会对网络执行精确的INT8推理计算。构建engine的阶段配置不需要再传calibrator了，因为量化参数已固化在生产流程中。

3.4 QAT后精度为什么通常更好

QAT与PTQ一个本质区别在于误差抵消。PTQ使用校准集统计每层的动态范围，但统计是静态的，训练中产生的误差分布无法反馈给网络调节。QAT则让网络在训练时就接触了量化的“毛刺”，梯度会引导权重往更鲁棒的数值形态收敛，比如让权重分布更集中、减少极端值。这些无意的调整，恰恰是降低量化误差的根本原因。

另外QAT过程中Observer统计到的动态范围是在完整训练流程中逐渐积累的，比PTQ用几百张图快筛出来的结果更稳定。尤其对于BatchNorm层比较多的模型，PTQ在统计激活范围时会因为BatchNorm参数而产生偏差，而QAT可以把这些偏差在训练期间直接消化掉。

不过QAT也并非万能。训练过程中如果数据增强和训练配置和线上推理环境差异太大，模型学到的分布偏移同样会导致量化掉点。QAT训练结束之后，依然要在线下的测试集上做精度验证，不能因为有QAT加持就放松校验流程。

4. 量化上线前的工程细节：精度、性能与稳定性

4.1 模型精度评测：别只看一个指标

量化效果的评估，不能只看Top-1准确率或者单一指标的变化。工程上我会同时看几个维度，放到测试集上做完整验证，再对比FP32基线的各项数值。

常见做法是准备一套完整的评估脚本，分别跑FP32的ONNX模型和INT8的TensorRT engine，输出一个精度对比表格：

关键是要看相对变化，而不是绝对值。对于不同任务，指标容忍度差别很大：分类任务掉0.5个点左右通常可接受；检测任务的mAP掉0.5到1个点就要引起警惕；分割任务对细节敏感，掉1个点以上基本就通不过。

除度量指标外，还要看分错误分布的最大值。量化后误差最大的那批样本往往集中在分辨率低、光照异常、小目标等极度依赖细节的区域。这种偏态分布虽然不直接拉低平均值，但容易在线上产生意想不到的异常行为。

4.2 性能评测：trtexec和Polygraphy的正确用法

TensorRT自带的trtexec是评测引擎性能最直接的工具。它能做精度对比、dump推理输出、统计吞吐和延迟分布，不需要写额外的C++或Python代码。

典型用法：

trtexec --onnx=model_fp32.onnx \ --saveEngine=model_fp32.engine \ --shapes=input:1x3x224x224 trtexec --loadEngine=model_int8.engine \ --shapes=input:1x3x224x224 \ --warmUp=100 \ --iterations=200

对比FP32和INT8引擎的平均延迟、P99延迟，同时记录GPU显存占用，结合精度对比表一起看，量化收益就一目了然了。

Polygraphy是另一个非常有价值的工具，它可以做模型间的逐层输出对比，帮我们定位INT8推理时哪些层的输出和FP32偏差最大。分析方向明确后，针对性地把偏差大的层回退到FP16或FP32，效率比盲调高很多。

polygraphy run model_fp32.onnx model_int8.engine \ --trt --onnxrt \ --trt-min-shape=input:1x3x224x224 \ --trt-opt-shape=input:8x3x224x224 \ --trt-max-shape=input:16x3x224x224

4.3 上线后需要盯什么

量化模型不是上线就万事大吉。线上数据和校准数据分布如果发生漂移，量化的scale和zero point会逐渐不匹配，精度会随之劣化。建议在推理服务里加上基本的质量监控逻辑：统计模型置信度分布、输出类别的熵值、以及关键业务指标的实时变化，发现异常时及时回滚到FP32版本。

另外，TensorRT版本升级也是影响量化模型上线稳定性的常见原因。不同小版本间的INT8 kernel选择可能不同，同样一个engine文件在新版本上可能跑出不同的延迟和精度。生产环境的TensorRT版本一旦确定不要轻易升级，升级前要在离线环境跑完整回归。

5. 踩坑实录：量化部署里最常见的几个坑

5.1 calibrator buffer命名不匹配

TensorRT的calibrator返回的是一个命名buffer列表，这些名字需要和网络输入名完全一致。很多时候报错信息不明显，只是说“calibration failed”，排查了半天发现只是输入名拼错了。建议实现get_batch时打印一下传入的names参数，确保返回顺序正确。

5.2 动态shape对校准的影响

如果用动态shape，校准阶段的shape要和后续推理常见shape保持一致。比如校准用1x3x224x224，但线上实际跑8x3x224x224，部分层的激活分布统计会出现偏差。建议校准时就按线上主用shape跑，并且多试几个shape的校准结果，观察精度波动。

5.3 INT8精度掉太多的第一排查顺序

分享一点个人心得，按优先级排：

1. 校准集是否贴近真实分布。
2. 校准算法是否适合该模型。
3. 是否有层在Transformer或检测头部位被强切到INT8。
4. ONNX导出是否保留了不必要的精度损耗结构。
5. 最后才考虑上QAT。

前四步大多数时候能解决80%以上的精度问题，真要走到第五步时，已经说明模型本身对量化极其敏感了。

5.4 TensorRT memory pool设置

构建engine时如果WORKSPACE设置太小，TensorRT会放弃一些更优的kernel实现，换成内存占用更低的低效方案，INT8推理速度可能反而比FP32还差。我一般先设1GB，如果显存紧张再逐步往下调。测试时用trtexec --showEngineInfo看一下engine实际用的workspace大小。

5.5 QAT训练不收敛的原因

如果QAT微调后精度反而更差，基本是学习率过大导致模型漂移。建议前几个epoch用FP32模型权重做warmup，然后切换到QAT流程；或者直接把学习率降到正常微调值的五分之一到十分之一。观察到训练loss持续下降但验证精度不升，说明量化噪声对模型的影响已经超过了拟合能力，此时可以适当增加训练数据增强或延长训练时间。

最后补充一些个人经验

量化部署这件事，做得越早越接近真正的“降本增效”。我经手的项目里，多数情况下PTQ的收益就已经非常可观——推理延迟直接下降20%到35%，显存减半不止，而精度损失控制在0.5%以内，业务方根本感知不到差异。真正需要QAT的场景，通常存在于小模型极度敏感或检测边界要求极高的情况，这类需求相对少数，但一旦遇到就值得投入时间把流程走完。

我个人在实际操作中体会最深的一点：量化的成败，常常由一些不起眼的细节决定——校准集的分布偏了多少、ONNX的opset版本对不对、输入name拼错没有、动态shape是否一致。把PTQ到QAT的全流程提前在内部跑通一次，团队在面临“模型上线延迟太高”时就不会陷入无头苍蝇式的调参。

最后再分享一个小方法：量化之后别急着删掉FP32模型。保存一份FP32的engine或ONNX当作“参考答案”，线上测试阶段同时跑两版模型，对比输出分布，出现异常时能第一时间定位是量化引入的问题还是模型自身的问题。这套流程用下来，稳定性和收益都能看得到。