1. 课程导入与低延迟目标定义

在视觉模型真正落地到摄像头、机器人、工业质检或自动驾驶等场景时，模型精度只是入场券，能否在严格的时间预算内稳定输出结果，才是决定系统可用性的关键。TensorRT 正是为解决这一矛盾而生的推理优化与运行时框架：它把训练框架导出的模型（ONNX、PyTorch 等）转换为高度优化的推理引擎，通过层融合、精度校准、内核自动调优与显存复用等手段，把同一张网络在 NVIDIA GPU 上的执行效率推到接近硬件极限。理解 TensorRT 的定位，本质上就是理解"从模型文件到可交付延迟"这条链路上，哪些环节可以被压缩、哪些代价必须被接受。

延迟、吞吐与精度：三个互相拉扯的目标

在讨论优化之前，必须先明确三个核心指标的定义，否则后续所有调优都会失去参照。

• 延迟（Latency）：从一帧图像进入系统，到对应推理结果可被下游消费所经历的时间，通常以毫秒计。端到端延迟包含预处理、Host 到 Device 传输、推理、后处理与结果回传，TensorRT 只负责其中的推理段。
• 吞吐（Throughput）：单位时间内系统能完成的推理次数，常用 FPS（帧每秒）或 QPS 表示。吞吐可以通过批处理（batch）和并发流（stream）显著提升。
• 精度（Accuracy）：模型输出与真值的吻合程度，常用 mAP、Top-1、IoU 等衡量。降低数值精度（如 FP32→FP16→INT8）通常能换来速度，但会引入精度损失。

这三者并非独立：增大 batch 能提高吞吐，却往往抬高单帧延迟；使用 INT8 能降低延迟并提升吞吐，但需要校准集来抑制精度下降。因此"低延迟优化"从来不是单目标最大化，而是在给定精度约束下，寻找延迟与吞吐的可行工作点。

建立端到端优化视角

很多团队在优化时只盯着推理内核，结果发现端到端延迟几乎没有改善。原因在于推理往往只占整条链路的一部分。以一个 1080p、30 FPS 的检测任务为例，典型的时间分布可能是：图像解码与缩放 3 ms、归一化与 HWC→CHW 转换 2 ms、Host→Device 拷贝 1.5 ms、TensorRT 推理 8 ms、NMS 后处理 2 ms、结果回传与绘制 1.5 ms，合计约 18 ms。此时即便把推理压到 4 ms，端到端也只降到 14 ms，收益被非推理段稀释。

因此正确的做法是先测量、再定位、后优化。用 CUDA Event 或 Nsight Systems 在每一段打点，得到真实的分段耗时，再判断瓶颈究竟在数据搬运、预处理、推理还是后处理。TensorRT 能优化的是推理段以及部分可通过插件下沉到 GPU 的算子，其余部分需要靠零拷贝、GPU 预处理、异步流水线等手段解决。

精度选择与工作点确定

TensorRT 支持 FP32、FP16、INT8 以及部分场景下的 FP8。精度越低，通常计算吞吐越高、显存占用越小，但数值误差也越大。工程上常见的做法是：先用 FP16 作为默认基线，因为现代 GPU 对 FP16 有原生加速且精度损失通常可忽略；只有在延迟仍不达标时，才引入 INT8，并用校准集（约 500～1000 张有代表性的图像）生成激活值分布，通过 KL 散度或熵最小化确定量化尺度。

判断精度是否可接受，不能只看单一指标。建议在验证集上同时对比 FP32 基线与量化后的 mAP、分类混淆矩阵以及小目标召回率。如果整体 mAP 只降 0.3%，但小目标召回率下降 5%，对检测任务而言仍可能不可接受。此时可以尝试混合精度：对敏感层保留 FP16，其余层使用 INT8，TensorRT 允许通过层精度覆盖来实现。

从目标到可执行的第一步

在进入后续章节的具体优化手段之前，建议先完成三件事：第一，用 Nsight Systems 或 CUDA Event 对现有链路做一次完整打点，得到各段真实耗时；第二，写下明确的精度容差、延迟分位数与吞吐下限；第三，确认硬件型号、驱动与 TensorRT 版本，因为不同架构（如 Ampere、Hopper、Ada）对 FP16、INT8、稀疏化的支持程度不同，优化空间也不同。完成这三步后，你才拥有一个可度量、可比较、可回退的优化起点，而不是凭感觉调参。

TensorRT 的价值不在于它能让模型"跑起来"，而在于它把推理段的时间压缩到接近硬件极限，从而为整条链路留出预算。理解这一点，就理解了本课程后续所有优化手段的共同目标：在精度约束下，把端到端延迟压到可交付的水平。