从一次上线前的性能压测说起。某检测项目里的模型在GPU上用FP32的TensorRT引擎跑得“还行”，单路延迟七八毫秒，看着能用。但业务方提了个需求：一块显卡要同时处理4路视频流，延迟还不能涨太多。压测一跑，显存带宽直接被打满，GPU利用率冲到了90%以上，延迟却压不下来。翻profile数据发现，卷积计算只占了一半出头，剩下的大头全在数据搬运上。与其继续抠算子，不如直接从数据类型下手——这就是我把TensorRT INT8量化排进迭代计划的起因。
INT8量化，简单说就是把网络的权重和激活值从32位浮点压缩到8位整数。换来的是显存占用减半、带宽需求降到原来的四分之一，在多数GPU上实测能拿到1.5倍到4倍的推理加速。这篇我不打算从数学原理讲起，TensorRT官方文档里的量化理论写得足够细。我想聊的是从零搭一个可落地的INT8量化工程链路：校准数据怎么准备、校准器怎么选、CMake工程怎么组织、序列化和动态Shape有哪些坑、验收时精度掉了怎么排查。内容更适合已经跑通过TensorRT FP32部署、正打算上INT8的工程师。
1. 被推理延迟卡住之后：INT8量化的真实价值
1.1 延迟瓶颈到底出在哪
推理延迟从来不是单个算子的问题。当时我对着profiler输出逐段看：GPU内推理占了差不多60%的时间，剩下的时间分布在输入预处理、H2D拷贝、D2H拷贝、后处理几个环节。GPU内的算子耗时，大头在卷积和矩阵乘，但真正头疼的是显存带宽被吃满——FP32下权重和激活的数据量太大，频繁从显存读数据，导致不少算子的计算单元一直在“等数据”，而不是“算数据”。
这种场景下，FP16能解决一半问题。FP16的数据量是FP32的一半，带宽压力缩小一半，算力上也有加成。但继续压流数时发现FP16还是不够。当时用的是一块消费级显卡，计算单元不算弱，短板就卡在显存带宽上。要再往下压数据量，只能走INT8——数据量再砍一半，等于带宽需求压到FP32的四分之一。
1.2 收益不是拍脑袋估出来的
我当时的预期是“延迟减半”，实际上线后的数据是这样的：
| 引擎版本 | 单路延迟(ms) | 显存占用(GB) | 精度(mAP) |
|---|---|---|---|
| FP32 | 12.8 | 1.6 | 0.852 |
| FP16 | 8.2 | 0.9 | 0.853 |
| INT8 | 4.6 | 0.5 | 0.845 |
三个版本里，INT8精度掉了约0.7个点，延迟却只有FP32的36%。对这个检测业务来说，损失在容忍范围内。当然这不是说所有模型都这么温和，ResNet类的分类网络量化后几乎不掉点，但目标检测、尤其是小目标多的模型，量化后精度波动会更大。后面的章节我会专门讲怎么定位和补救。
这里插一句：收益大，不代表每个项目都该上INT8。如果模型本身跑在CPU上，或者显存带宽本来就不紧张，INT8的收益会明显削弱。但反过来，如果你的GPU利用率长期在90%以上、延迟却压不下来，多半就能从量化里吃到红利。
1.3 不是所有层都在“快乐量化”
还要说一个概念：INT8量化对卷积和矩阵乘这类计算密集型算子很友好，因为误差会通过多层卷积的累加和融合被稀释。但对某些结构，比如检测分支最后的回归头、紧挨着BatchNorm的层，量化误差会直接反映到坐标和类别概率上。换句话说，量化收益不是平均分布在各层的，有的层甚至可以跳过不量化，TensorRT支持按层排除来避开高风险带。
把注意力放在敏感层上，往往比全局调精度更有效。这个思路贯穿整个量化工程的验收阶段。
2. 校准阶段的核心准备：数据、方向与粒度
2.1 校准数据集：多样性比数量重要
TensorRT做INT8量化前需要跑一段“校准”流程：把一批有代表性的输入喂进网络，统计每层激活值的分布，然后根据分布确定8位整数该用什么样的缩放因子。这里最关键的工程判断是：什么样的数据算“有代表性”。
从踩坑经验看，校准集数量不需要太大，500到1000张图通常就够，但多样性必须保证。比如做夜间场景检测，校准集里如果全是白天图，夜间模糊区域的激活值就会落在量化范围之外，推理时那些层持续饱和，精度崩得莫名其妙。另一个老生常谈但总有人忽略的点：校准集必须和推理时的预处理流程完全一致，包括缩放算法、归一化参数、通道顺序。否则校准统计的是“另一个网络”的分布，量化出来自然不准。
提示：校准集的预处理差异是精度掉点的第一嫌疑。我见过有人训练时用双线性resize，校准和推理时却用了最近邻，结果INT8精度掉了3个点还多。
数据标注也很重要。校准集最好覆盖所有类别、所有典型场景，每类的样本量尽量均衡。如果某类样本只占1%，它在激活分布里就很难被体现，量化后这类别的检测效果会明显变差。
2.2 校准器选型：EntropyCalibrator2是默认答案
TensorRT的INT8校准分几类：MinMax直接取激活的最小最大值做映射；Entropy（KL散度）通过最小化量化前后信息损失来选阈值；EntropyCalibrator2是改进版；LegacyCalibrator则可以结合自定义分布做人工调参。工程实践里，EntropyCalibrator2基本是默认选择——它对大部分网络的精度保持效果最好，而且不需要人工介入。
MinMax不是不能用，它对激活分布本来就集中在固定区间的网络很合适，比如某些语义分割模型。但如果分布有长尾，MinMax会把整段量化范围拉宽，小数值被压缩得厉害，精度损失明显。LegacyCalibrator需要你额外提供概率分布函数，适合做极端调优，但对多数项目来说投入产出比不高。
2.3 敏感层预分析：先把大风险摘出来
TensorRT默认使用per-tensor量化，也就是整个张量共用一组缩放因子。对某些通道差异大的网络，可以启用per-channel。验证per-channel有没有帮助，最快的方法是先跑一版per-tensor，把掉精度最明显的输出层找出来，在构建时给那些层单独设置量化策略或直接排除。
我当时的做法是：先把回归头相关的层排除量化，精度回来了一截，延迟只多零点几毫秒，完全可接受。排除量化层不是玄学，核心依据是“该层输出对最终结果的绝对误差影响”。卷积层输出还有后续层去平滑，但最后的回归输出直接变成坐标和类别概率，所以它对误差最敏感。类似的敏感点还有Softmax之前的Logits层，以及损失函数中直接参与比较的中间特征。
3. CMake工程化设计：从脚本到可交付构建
3.1 为什么用CMake而不是脚本堆
项目早期，校准和推理靠Python脚本加Shell跑通。Python脚本做模型解析和调试确实方便，但问题在于它成不了“可交付的部署件”。依赖版本五花八门，换台机器就要折腾半天的环境。真到上线时，重建引擎、加载量化缓存、跑推理，这些步骤散落在三个目录里，每次都要小心翼翼按顺序执行。
后来我把整个流程收敛到一个CMake工程里，编译出两个可执行文件：校准工具calib_tool负责用校准集生成量化缓存；推理程序infer_demo负责加载缓存、反序列化引擎、跑推理和统计性能。两个工具的输入输出全部通过命令行参数和配置文件控制，从构建到验收都是可复现的。
这么做还有个隐性好处：校准和推理用的是同一套代码里的runtime封装，日志、CUDA错误检查、引擎管理逻辑统一，不容易出现两边行为不一致。
3.2 目录与模块划分
我的目录结构大致这样：
tensorrt_int8_project/ ├── CMakeLists.txt ├── cmake/ │ ├── FindTensorRT.cmake │ └── FindCUDAToolkit.cmake ├── common/ │ ├── logger.h │ ├── runtime.h │ └── runtime.cpp ├── calib/ │ ├── calib_tool.cpp │ └── int8_calibrator.h ├── infer/ │ ├── infer_demo.cpp │ └── engine_context.h ├── configs/ │ ├── calib_config.yaml │ └── infer_config.yaml └── scripts/ ├── build.sh └── run_benchmark.sh设计上有两条原则：校准和推理共用common里的runtime封装；校准器类只放在calib目录里，因为只有校准程序需要实现TensorRT的校准回调接口。职责清楚，依赖也干净。configs里放YAML的好处是，换一组校准数据或者换推理batch时，不用重新编译。
3.3 CMakeLists核心写法与依赖定位
CMakeLists里最核心的部分是找依赖和生成目标。TensorRT常装在非标准路径，find_package经常找不到，我倾向手写一个FindTensorRT.cmake模块来定位。模块里的核心逻辑是：
# 简化后的FindTensorRT.cmake set(TENSORRT_ROOT "$ENV{TENSORRT_ROOT}" CACHE PATH "TensorRT root") find_path(TENSORRT_INCLUDE_DIR nvinfer.h HINTS ${TENSORRT_ROOT}/include) find_library(TENSORRT_LIBRARY nvinfer HINTS ${TENSORRT_ROOT}/lib) set(TENSORRT_LIBRARIES ${TENSORRT_LIBRARY}) set(TENSORRT_INCLUDE_DIRS ${TENSORRT_INCLUDE_DIR})主CMakeLists里配置好C++标准和编译选项，把CUDA和OpenCV一并链上：
cmake_minimum_required(VERSION 3.18) project(tensorrt_int8_project LANGUAGES CXX CUDA) include(cmake/FindTensorRT.cmake) find_package(CUDAToolkit REQUIRED) find_package(OpenCV QUIET) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(calib_tool calib/calib_tool.cpp calib/int8_calibrator.cpp common/runtime.cpp common/logger.cpp) target_include_directories(calib_tool PRIVATE ${CMAKE_SOURCE_DIR}) target_link_libraries(calib_tool PRIVATE ${TENSORRT_LIBRARIES} CUDA::cudart ${OpenCV_LIBS}) # infer_demo 的配置类似，不再重复这么做有个直接收益：不管在开发机还是部署机，只要把TENSORRT_ROOT指对、编译器版本固定，一拉代码一编译，构建结果一致。原来“跑不起来先怪环境”的争论明显变少了。
3.4 编译细节里的两个坑
这里写两个不算难但很容易踩的点。第一，编译时一定要加-std=c++14或更高标准，新版本TensorRT的头文件用了大量新特性，不设标准会出现模板解析错误。第二，Linux下的链接顺序很讲究，TensorRT的库要放在依赖它的目标之后，否则会报“undefined reference”。调试版本里日志要保留，建议在common里封装一个简单的Logger，配合TensorRT的ILogger回调，把错误级别统一管理。看起来是小问题，但在工程化交付时，这些细节决定了别人能否顺利接手。
4. 从校准到推理：序列化、动态Shape与显存细节
4.1 plan文件的反序列化约束
TensorRT的构建产物叫plan文件，是序列化后的引擎。校准工具执行完会得到两个东西：量化缓存表（工程上建议用独立的缓存文件保存）和可反序列化的engine文件。这里有个经典坑：反序列化plan时仍然需要和构建引擎时相同的TensorRT主版本，而且必须是同一代GPU架构。在A卡上构建的plan不能直接拿到B卡上用，算力不匹配时常见报错是“engine could not be deserialized”。
所以工程里我推荐把构建和反序列化分开：构建阶段在开发机完成，产物（plan加量化缓存）一起打入部署包；部署机上只跑推理程序，启动时加载plan并反序列化。这样把开发机和部署机的环境差异隔离在构建端。反序列化的代码量不大，但要注意设置流和buffer的时机，必须在createExecutionContext之后再去获取绑定的输入输出张量。
4.2 动态Shape与workspace配置
现在多数检测模型的输入不是固定尺寸。TensorRT需要给网络设置动态维度，并在构建时指定三种shape：min、opt、max。opt里填业务实际最常见的尺寸，优化器会围绕这个尺寸做大量算子融合和内存复用调优；min和max划定允许范围，超出范围的shape在推理时会走回退路径，性能可能打折。
一个容易忽视的点：动态shape变化会触发内部context重构。如果业务里输入尺寸频繁跳变，即便都在允许范围内，延迟也会有明显波动。我当时的做法是让预处理把输入统一resize到少数几个固定档位，比如640、960、1280三档，每档单独申请context和buffer，换来的是延迟曲线非常平稳。
workspace size参数同样关键。它决定算子优化时能使用的临时显存上限，设太大可能OOM，设太小某些融合优化直接放弃。建议从默认值开始逐步上调，观察构建成功率和性能变化，取一个拐点值。我在项目里通常从2GB起步往上试，如果显卡显存有限，就适当牺牲部分融合换取稳定性。
4.3 运行时buffer与流的编排
运行时阶段，enqueueV2在新版里已经边缘化，新接口基于流式API，需要自己管理输入输出buffer、事件同步和流。CUDA流这块值得花时间优化。我一般开两条流：一条做H2D拷贝和推理，一条做D2H拷贝，配合事件做流水线。这样CPU和GPU之间的等待时间大幅减少，实测吞吐能再涨15%到20%。
buffer管理上要注意避免显存碎片。如果每次推理都重新分配输出buffer，长时间运行后显存碎片会很严重。推荐的做法是启动时统一分配好固定大小的buffer池，按档位复用。输出buffer如果按最大可能shape分配，内存在小输入时会浪费不少，建议改成按档位分配、分批复用。
4.4 并发路数与吞吐平衡
并发通常有两种选择：多进程或多线程加多stream。多数项目里单进程多stream已经够用。INT8引擎省下来的显存正好可以容纳更多并发流。但别盲目开高并发——当GPU被调度器打满后，继续加并发只会增加上下文切换开销，延迟反而升高。
我上线前会写一个并发扫描脚本，从1路并发测到8路，画出吞吐与延迟的曲线，取两者的平衡点。这个平衡点通常就是业务需要的并发上限。脚本本身不复杂，但有了这条曲线，调参时心里就有底了。
5. 验收与排障：把量化结果吃透
5.1 标准对比实验的设计
量化效果行不行，不能只看几张测试图。我习惯搭一套标准对比流程：同一份测试数据、同一个预处理管线、同一个后处理阈值，分别拿FP32和INT8引擎各跑一遍，统计mAP、Recall、平均延迟、P95延迟、显存占用。跑完写进一个表格，附上校准集信息和校准策略，方便之后回溯。
项目里建议把精度容差写清楚，比如“mAP下降不超过1个点”作为合格线。有了这个标准，量化上线后因为偶发抖动被质疑时，可以直接拿对比数据说话。测试集要留一部分完全不参与校准，否则存在作弊嫌疑。
5.2 精度严重下降时的排查链路
如果真的出现精度崩了，我按这个顺序排查。
- 校准集是否和实际部署分布一致。这个占的比例最大，经常出现白天图校准、夜间图上线的情况。
- 预处理是否被改过。resize算法、归一化参数、BGR/RGB顺序，任何一项变了，量化统计就废了。
- 敏感层是否被量化。用排除层的方式逐层试探，哪个层排除后精度回升，重点标记。
- 校准器类型和参数。尝试换LegacyCalibrator，或者调整数据比例。
- 是否意外混用了FP16。有些INT8引擎配置里打开了FP16开关，某些层走了FP16，一般没事，但偶发问题排查时值得检查。
这套排查链路基本能覆盖95%的掉点问题。最难的是第一项，因为它不在代码里，而在数据管理的流程里。
5.3 性能不达标时的方向清单
性能不达标我一般看几个方向。延迟高但GPU利用率低，先查数据加载和预处理是不是CPU瓶颈，必要时上GPU预处理或并行流水线。多线程并发提升不明显，查锁竞争或单条流的串行依赖。P95延迟抖动大，查动态shape档位是否频繁跳变，或显存碎片严重。显存占用比预期高，查workspace size和输出buffer是否按最大shape分配，改成按档位复用后通常能降下来。
这些排查听起来琐碎，但都属于“把工程做实”的必经环节。INT8量化不是改一行配置就完事，它牵动的细节贯穿数据管线、构建流程和运行时。
最后分享一点个人体会。每次跟团队讲INT8量化，大家最关心的永远是“掉几个点”、“快多少倍”，但真正决定量化能不能落地的，其实是校准数据管线和构建工程的可复现性。匀出一部分精力把CMake工程、缓存文件管理、验收脚本搭好，后面每次换模型、换数据、换显卡，都能少踩一遍重复的坑。如果你正卡在量化精度或工程组织的某一步，希望这篇能提供些参考。先跑通最小闭环，再逐步深化。
