1. 课程导入与工程全景

在 GPU 上部署深度学习模型时，很多团队都会遇到同一个矛盾：模型精度已经调好，但推理延迟和显存占用仍然无法满足业务要求。TensorRT 的 INT8 量化正是解决这一矛盾的核心手段之一。它把原本以 FP32 或 FP16 存储和计算的权重、激活值，转换为 8 位整数表示，在保持可接受精度的前提下，把显存带宽需求降到约四分之一，并借助 GPU 的 INT8 张量核心获得数倍于 FP32 的吞吐。理解这条工程链路，是后续所有量化、校准与精度验证工作的起点。

INT8 量化的核心价值

INT8 量化的收益来自三个层面。第一是显存与带宽：一个 FP32 权重占 4 字节，INT8 只占 1 字节，模型体积和每层读写的数据量都显著下降，而推理往往是访存受限的，因此带宽下降会直接转化为延迟下降。第二是计算吞吐：从 Turing 架构开始，NVIDIA GPU 提供 INT8 的 DP4A 指令与张量核心路径，单周期可完成的乘加运算数量远高于 FP32。第三是功耗与成本：同样的吞吐可以用更少的 GPU 或更低的功耗达成，这对边缘设备和多路视频分析场景尤其关键。

但 INT8 不是免费的。把连续的浮点值映射到只有 256 个离散整数上，必然引入量化误差。误差在浅层网络中可能被放大，在检测、分割等对数值敏感的任务中可能表现为小目标漏检、边界框偏移或分割边缘毛刺。因此，量化工程的目标从来不是“把模型变成 INT8”，而是“在满足精度约束的前提下把模型变成 INT8”。

典型部署场景

INT8 量化最常出现在以下几类场景中：

• 多路视频结构化：单机需要同时处理 16～64 路 1080p 视频流，检测模型必须在数毫秒内完成单帧推理，INT8 是达成该吞吐的常规选择。
• 边缘推理盒子：Jetson Orin、Jetson Xavier 等平台功耗与散热受限，INT8 能在相同功耗预算下提升有效算力。
• 云端高并发服务：推荐、搜索、内容审核等在线服务对 P99 延迟敏感，INT8 可降低单次推理耗时并提升单卡并发数。
• 大模型推理加速：在 LLM 场景中，INT8 权重与 KV Cache 量化可显著降低显存占用，使更大模型或更长上下文成为可能。

这些场景的共同点是：精度要求明确、延迟或成本约束刚性、且允许在离线阶段做一次校准。如果业务对精度极其敏感且无法接受任何精度回退，或者模型结构包含大量 INT8 不友好的算子，那么量化前需要更谨慎的评估。

精度验证为什么不可省略

很多量化失败的案例并不是因为量化本身不可行，而是因为缺少系统的精度验证。常见的误区包括：只看校准阶段的“无错误”就认为量化成功；只在一个小样本集上比较输出，忽略了分布尾部；或者只比较最终精度指标，没有定位到具体是哪一层、哪个算子导致了精度下降。

精度验证至少应回答三个问题：量化后模型在代表性数据集上的指标下降了多少；下降是否集中在特定层或特定算子；以及是否可以通过混合精度（对敏感层保留 FP16/FP32）把精度拉回可接受范围。TensorRT 提供的逐层精度对比工具，正是为回答后两个问题而设计的。没有这套验证，量化就变成了碰运气。

从模型到 INT8 引擎的完整工程链路

下面这张图给出了本节最需要建立的整体认知：一条从训练框架模型出发，经过导出、解析、校准、量化、构建，最终得到可序列化 INT8 引擎，并回到精度验证闭环的工程链路。图中同时标出了每个阶段的关键输入、产物与常见风险点。

这张图里有两条路径值得特别注意。第一条是校准数据流：校准集从真实业务数据中采样，经过校准器统计每一层激活值的动态范围，生成量化参数（scale 与 zero-point），再参与引擎构建。校准集的质量直接决定量化误差的大小，用随机噪声或与业务分布不符的数据做校准，几乎必然导致精度崩塌。第二条是验证反馈路径：引擎构建完成后，必须回到 FP32 基准做逐层对比，一旦发现某层误差超限，就要回到校准策略或混合精度配置重新构建，而不是直接上线。

本课程将覆盖的内容

围绕这条链路，课程会依次展开：量化原理与对称/非对称量化的数学表达；TensorRT 中 INT8 的启用方式与精度标志；校准器接口与校准算法选择；ONNX 导出与算子兼容性处理；逐层精度对比工具的使用；敏感层识别与混合精度回退；以及最终引擎的序列化、部署与性能基准测试。每一部分都会给出可执行的代码片段、示例参数和结果判读方法。