TensorRT 用于计算机视觉：Jetson 和桌面 GPU 上推理加速的真实机制

TensorRT 在边缘 AI 部署的讨论中被频繁提到，但描述通常很模糊："更快"、"NVIDIA 的推理引擎"、"压缩模型"。这些说法并不能告诉你实际期望什么，或者加速从哪里来。

这篇文章从部署工程师的角度介绍 TensorRT——它在机制上做了什么，哪些模型架构受益最大，量化在实践中如何工作，以及可能出错的地方。

TensorRT 实际做了什么

TensorRT 是 NVIDIA GPU 的推理优化器和运行时。你提供一个训练好的模型（通过 ONNX 从 PyTorch 导出，或来自 TensorFlow），它生成一个针对你的 GPU 硬件和目标精度专门优化的引擎文件。

核心操作：

算子融合。 数学上相邻的操作——比如卷积后接批归一化再接 ReLU——被合并为一个内核调用。这消除了操作之间往返 GPU 内存的开销。在典型的 ResNet 块上，仅算子融合就能减少 60–70% 的内核启动次数。

内核自动调优。 TensorRT 在你的特定 GPU 上对每个操作的多个 CUDA 内核实现进行基准测试，选择最快的。在 A100 上运行快的卷积不一定在 Jetson AGX Xavier 上最快。引擎是硬件特定的。

精度缩减。 FP32 → FP16 在支持的硬件上将内存带宽减半（所有现代 NVIDIA GPU）。INT8 减少 75%，但需要校准数据以最小化精度损失。

内存规划。 TensorRT 分析整个计算图，找出哪些张量可以共享内存缓冲区（因为它们的生命周期不重叠）。这减少了峰值显存使用，在受限的边缘设备上尤为重要。

加速从哪里来

确切的加速取决于模型架构：

卷积密集型模型（YOLO、ResNet、EfficientDet）： 收益最大。算子融合和 INT8 量化可在同一 GPU 上比原生 PyTorch 实现 3–5 倍的吞吐量提升。在 Jetson AGX Orin 上，YOLOv8m 导出为 TensorRT INT8 通常跑 120–180 FPS，而 PyTorch 只有 35–50 FPS。

基于 Transformer 的视觉模型（ViT、DETR）： 收益较为适中，通常 1.5–2.5 倍。注意力机制更难高效融合，加速取决于序列长度。

动态输出形状的检测头： 需要特殊处理。TensorRT 在引擎构建时需要固定的输入/输出形状，除非使用动态形状配置，这会增加复杂性。

量化的现实情况

FP16（半精度）通常是免费的午餐。每块 Maxwell 架构以后的 NVIDIA GPU 都有 FP16 张量运算的硬件支持。对视觉模型的精度影响极小——检测任务上 mAP 下降通常不超过 0.5%。

INT8 更复杂。你需要一个校准数据集——通常 500–1000 张代表性图像——TensorRT 通过网络运行这些图像来确定每层的最优缩放因子。如果校准集不能代表实际推理分布，INT8 精度会明显下降。

常见失败模式：工程师用训练集校准，但在来自不同相机、光照条件或地理位置的图像上部署。始终用与部署场景匹配的数据进行校准。

我的感受

我见过的最大错误：人们在与部署目标不同 GPU 的开发机上构建引擎。引擎构建成功，加载到错误的硬件上，要么崩溃要么输出垃圾。始终在目标硬件上构建引擎。

第二个错误：把 INT8 当成免费的。它更快，但需要严格的校准。在一个项目中，我们有一个校准不良的 INT8 模型导致 3% 的 mAP 下降，直到生产测试才发现。

当正确工作时，TensorRT 对边缘部署确实具有变革性——同一硬件上模型从 8 FPS 运行到 45 FPS 的差距，就是原型和产品的差距。

在 Jetson AGX Orin（JetPack 6.x）、Jetson AGX Thor（JetPack 6.8）和 RTX 3090（CUDA 12.4，TensorRT 10.x）上测试。不同 TensorRT 主版本的构建和运行时行为可能有所不同。