📚 课程目录第3章 TensorRT基础概念

3. TensorRT基础概念：引擎、上下文、绑定、优化策略等核心术语解析

3.1 核心概念总览：从模型文件到可执行推理

TensorRT 的推理体系建立在几个关键抽象之上。理解这些术语之间的关系，是掌握 TensorRT 部署的第一步。简单来说，整个流程可以概括为：将训练好的模型（如 ONNX）通过 Builder（构建器）编译为 Engine（引擎），再由 Execution Context（执行上下文）在 GPU 上驱动推理，并通过 Binding（绑定）来管理输入输出数据。

下图展示了 TensorRT 的核心组件关系与数据流，它清晰地说明了从磁盘上的模型文件到 GPU 显存中张量数据的完整路径：

上图展示了 TensorRT 的核心架构。其中 Builder 负责将模型编译成针对特定 GPU 优化的 Engine，Engine 可以被序列化保存为 .engine 文件以便后续直接加载。每次推理时，需要基于 Engine 创建一个 Execution Context，它持有推理所需的中间激活显存和内核执行状态。而 Bindings 则是连接外部数据与引擎内部张量的桥梁。

3.2 核心术语逐一解析

3.2.1 Engine（引擎）与序列化

Engine 是 TensorRT 对计算图的优化表示，它包含了层融合后的网络结构、每个算子的内核选择、权重常量以及内存分配计划。Engine 是设备相关的，针对 RTX 4090 构建的 Engine 无法在 A100 上运行。Engine 可以序列化为二进制文件，部署时直接反序列化加载，省去重新构建的时间。

// 构建 Engine 并序列化（C++ 伪代码）
IBuilder* builder = createInferBuilder(logger);
INetworkDefinition* network = builder->createNetwork();
// ... 解析 ONNX 模型填充 network ...

builder->setMaxBatchSize(1);  // 旧版 API，新版本使用优化配置
builder->setFp16Mode(true);   // 启用 FP16

IHostMemory* serializedModel = builder->buildSerializedNetwork(*network, config);
// 将 serializedModel->data() 写入 .engine 文件

3.2.2 Execution Context（执行上下文）

Engine 是只读的、可共享的元数据，而 Execution Context 是可变的、每次推理独立的状态。每个 Context 拥有独立的中间张量显存、CUDA 流状态和动态形状绑定信息。多线程推理时，每个线程应持有独立的 Context，但可以共享同一个 Engine。

关键区别：Engine 好比是“编译好的程序文件”，Context 则是“运行中的进程”。多个进程（Context）可以同时运行同一个程序（Engine），互不干扰。

3.2.3 Binding（绑定）与张量寻址

Binding 是 Engine 输入/输出张量的抽象索引。每个 Binding 对应一个张量名称（如 "input"、"output"）。在推理前，需要通过 getBindingIndex(name) 获取索引，然后使用 setTensorAddress() 将 GPU 显存指针绑定到该索引上。TensorRT 不负责数据拷贝，输入数据必须已存在于 GPU 显存中。

// 绑定示例（C++）
int inputIdx = engine->getBindingIndex("input");
int outputIdx = engine->getBindingIndex("output");

void* inputMem;  // 已通过 cudaMalloc 分配
void* outputMem; // 已通过 cudaMalloc 分配

context->setTensorAddress(inputIdx, inputMem);
context->setTensorAddress(outputIdx, outputMem);

// 执行异步推理
context->enqueueV3(stream);

3.2.4 优化策略（Optimization Strategies）

TensorRT 的优化是自动进行的，但理解其机制有助于配置构建选项。下表总结了主要优化策略及其效果：

优化策略	原理说明	典型收益	配置方式
层融合（Layer Fusion）	将 Conv+BN+ReLU 等垂直或水平合并为单一内核，减少内核启动开销和中间显存读写	延迟降低 20%~50%	默认开启
精度校准（Precision Calibration）	FP16 直接降低精度；INT8 需要校准数据集统计激活值分布，计算缩放因子	FP16 加速 ~2x；INT8 加速 ~3-4x	`setFp16Mode(true)` / `setInt8Mode(true)`
内核自动调优（Kernel Auto-Tuning）	对每个算子尝试多种 CUDA 实现（不同 tile 大小、向量化宽度等），benchmark 后选择最优	单算子性能提升 10%~30%	构建时间增加，可通过 `setEngineCapability` 限制
张量内存复用（Memory Reuse）	分析张量生命周期，将不重叠的中间张量分配到同一块显存	显存占用降低 30%~60%	默认开启
动态形状（Dynamic Shapes）	通过优化配置文件指定 min/opt/max 维度，避免为每个形状重新构建	灵活性与性能的平衡	`setOptimizationProfile()`

3.3 典型工作流程：从 ONNX 到高性能推理

下面以一个 ResNet-50 图像分类模型为例，展示完整的 TensorRT 部署流程：

导出 ONNX：从 PyTorch 导出 resnet50.onnx，固定 batch=1，输入尺寸 3×224×224。
构建 Engine：使用 trtexec 工具或 C++/Python API 构建 FP16 Engine。
序列化保存：将 Engine 保存为 resnet50_fp16.engine（约 100MB）。
加载与推理：在服务中反序列化 Engine，创建 Context，绑定输入输出显存，执行 enqueueV3()。

# 使用 trtexec 快速构建（命令行）
trtexec --onnx=resnet50.onnx \
        --saveEngine=resnet50_fp16.engine \
        --fp16 \
        --minShapes=input:1x3x224x224 \
        --optShapes=input:8x3x224x224 \
        --maxShapes=input:16x3x224x224

  性能对比参考（RTX 3090, batch=1）：PyTorch 原始推理延迟约 4.2ms；TensorRT FP16 引擎延迟约 1.1ms，加速比约 3.8x。若使用 INT8 量化，延迟可进一步降至约 0.6ms，但需要准备 500~1000 张校准图片。

3.4 常见误区与复盘

误区一：Engine 可以跨设备通用。实际上，Engine 与 GPU 架构（如 Ampere、Ada、Hopper）、CUDA 版本、TensorRT 版本强绑定。换卡或升级驱动后必须重新构建。

误区二：Context 可以多线程共享。Context 内部状态（如中间激活指针）不是线程安全的。多线程并发推理时，每个线程必须创建自己的 Context，但可以共享同一个 Engine。Engine 的构建成本高，而 Context 的创建成本相对较低。

误区三：忽略动态形状配置。如果模型需要处理不同 batch 或不同分辨率的输入，必须在构建时通过 OptimizationProfile 指定 min/opt/max 三个档位。否则，TensorRT 只优化固定形状，遇到新形状时会报错或回退到低效路径。

复盘总结：在实际项目中，建议将 Engine 构建与推理服务分离——构建过程在离线环境完成并保存 .engine 文件，服务启动时直接加载。同时，务必在目标 GPU 型号和驱动版本上进行最终验证。对于动态形状场景，合理设置 opt 档位（通常是实际部署中最常见的形状）能获得接近固定形状的性能。理解 Engine、Context、Binding 三者的关系，是避免并发问题、显存泄漏和性能劣化的基础。