3. TensorRT基础：架构、核心组件与推理流程
TensorRT 是 NVIDIA 推出的高性能深度学习推理优化器，其核心目标是在 GPU 上以最低延迟和最高吞吐量运行训练好的神经网络模型。理解 TensorRT 的架构和核心组件，是掌握算子融合与 CUDA 内核解析的前提。本章将拆解 TensorRT 的三大核心对象——Builder（构建器）、Engine（引擎）和Context（执行上下文），并梳理从模型输入到推理输出的完整流程。
3.1 核心架构：从模型到引擎的三层抽象
TensorRT 的设计遵循“构建时优化，运行时高效”的原则。它将复杂的 GPU 底层细节封装为三个层次分明的组件，每个组件承担不同职责，且生命周期各不相同。
- Builder（构建器）：负责加载模型、配置优化参数、执行层融合与精度校准，最终生成一个序列化的引擎文件。Builder 是离线阶段的核心，运行在 CPU 上，消耗较多内存和计算资源。
- Engine（引擎）：Builder 的产物，是一个经过深度优化的、不可变的推理执行计划。它包含了融合后的算子内核、权重张量、内存分配策略等信息。Engine 可以序列化为二进制文件（.plan），供后续直接加载使用。
- Context（执行上下文）：Engine 的运行时实例。一个 Engine 可以被多个 Context 共享，每个 Context 拥有独立的中间张量存储空间和 CUDA 流，用于执行实际的推理计算。
关键理解：Builder 是“编译器”，Engine 是“可执行文件”，Context 是“进程”。编译一次，可执行多次，每次执行拥有独立的内存空间。
3.2 核心组件详解
3.2.1 Builder：优化策略的决策者
Builder 是 TensorRT 优化能力的集中体现。它通过 INetworkDefinition 接收模型图，然后应用一系列优化策略。其中与算子融合最相关的是层融合（Layer Fusion）和内核自动调优（Kernel Auto-tuning）。Builder 会尝试将 Conv、BN、ReLU 等相邻层合并为一个 CUDA 内核，减少内核启动开销和全局内存读写。
// Builder 典型配置示例（C++ API）
IBuilder* builder = createInferBuilder(gLogger);
uint32_t flags = 1U << static_cast<uint32_t>(NetworkDefinitionCreationFlag::kEXPLICIT_BATCH);
INetworkDefinition* network = builder->createNetworkV2(flags);
builder->setMaxBatchSize(1); // 最大批大小
builder->setFp16Mode(true); // 启用 FP16 精度
builder->setInt8Mode(true); // 启用 INT8 量化（需校准数据）
builder->setMaxWorkspaceSize(1 << 30); // 设置 1GB 工作空间
ICudaEngine* engine = builder->buildCudaEngine(*network);3.2.2 Engine：不可变的执行计划
Engine 保存了优化后的网络执行顺序、每个算子的内核函数指针、权重数据以及内存池的布局。它不包含任何可变状态，因此可以被多个线程安全地共享。Engine 支持序列化与反序列化，使得模型部署时无需重新执行耗时的构建过程。
实践建议：在服务端部署时，建议将构建好的 Engine 序列化为 .plan 文件，部署时直接反序列化加载。这可以将启动时间从分钟级缩短到秒级，且避免目标机器上重复进行算子调优。
3.2.3 Context：推理的执行者
Context 是实际执行推理的组件。它持有中间激活张量的内存缓冲区，并通过 enqueueV2() 或 executeV2() 方法将输入数据送入 GPU 流水线。每个 Context 绑定一个 CUDA 流，因此多个 Context 可以在不同流上并行执行，实现多路并发推理。
// 推理执行示例
IExecutionContext* context = engine->createExecutionContext();
float* inputBuffer; // 已分配 GPU 显存
float* outputBuffer; // 已分配 GPU 显存
// 绑定输入输出缓冲区索引
context->setTensorAddress("input", inputBuffer);
context->setTensorAddress("output", outputBuffer);
// 异步执行推理
bool success = context->enqueueV2(stream); // stream 为 CUDA 流3.3 完整推理流程：从模型文件到推理结果
一个典型的 TensorRT 推理流程包含以下六个步骤，每一步都有明确的输入输出和错误检查点。
- 模型解析：使用
ONNXParser或UFFParser将外部模型转换为 TensorRT 的INetworkDefinition图结构。 - 构建配置：设置精度模式、工作空间大小、动态形状范围等参数。
- 引擎构建：调用
buildCudaEngine()，触发层融合、精度校准、内核选择等优化过程。 - 引擎序列化（可选）：将 Engine 写入磁盘，便于后续快速加载。
- 上下文创建：从 Engine 创建
IExecutionContext，分配输入输出 GPU 显存。 - 循环推理：将输入数据拷贝到 GPU，调用
enqueueV2()执行，再将结果拷回 CPU。
| 步骤 | 核心 API | 关键参数/配置 | 常见错误 |
|---|---|---|---|
| 模型解析 | createNetworkV2 | 显式批处理标志 | 不支持的算子 |
| 构建配置 | setFp16Mode / setInt8Mode | 校准数据集 | 精度不匹配 |
| 引擎构建 | buildCudaEngine | maxWorkspaceSize | 显存不足 |
| 上下文创建 | createExecutionContext | 绑定张量名称 | 名称拼写错误 |
| 推理执行 | enqueueV2 | CUDA 流句柄 | 流未同步 |
3.4 案例：ResNet-50 的 TensorRT 部署流程
以 ResNet-50 图像分类模型为例，展示从 ONNX 到 TensorRT 推理的完整代码骨架。该模型包含 53 个卷积层和大量 BatchNorm + ReLU 组合，是观察算子融合效果的典型对象。
// 1. 创建 Builder 和 Network
IBuilder* builder = createInferBuilder(gLogger);
const auto explicitBatch = 1U << static_cast<uint32_t>(NetworkDefinitionCreationFlag::kEXPLICIT_BATCH);
INetworkDefinition* network = builder->createNetworkV2(explicitBatch);
// 2. 解析 ONNX 模型
nvinfer1::IParser* parser = nvonnxparser::createParser(*network, gLogger);
parser->parseFromFile("resnet50.onnx", 1);
// 3. 配置构建选项
builder->setMaxBatchSize(1);
builder->setFp16Mode(true);
builder->setMaxWorkspaceSize(1 << 30);
// 4. 构建引擎
ICudaEngine* engine = builder->buildCudaEngine(*network);
// 5. 序列化保存
std::ofstream planFile("resnet50.plan", std::ios::binary);
planFile.write(engine->serialize()->data(), engine->serialize()->size());
// 6. 创建上下文并推理
IExecutionContext* ctx = engine->createExecutionContext();
// ... 分配显存、拷贝输入、enqueueV2、拷贝输出 ...融合效果观察：在 ResNet-50 中，TensorRT 会将 Conv+BN+ReLU 融合为单个内核，将残差分支的 Add 操作融合到前一层的输出计算中。经过融合后，原始 176 个网络层通常被压缩到 60~70 个内核，推理延迟可降低 30%~50%。
3.5 常见误区与复盘
误区一：认为 Engine 可以跨 GPU 架构复用。Engine 是针对特定 GPU 架构（如 Turing、Ampere、Ada）编译的。在 A100 上构建的 Engine 无法在 T4 上运行，必须针对目标硬件重新构建。
误区二：忽略动态形状（Dynamic Shape）配置。如果模型需要处理不同尺寸的输入，必须在构建时设置优化轮廓（Optimization Profile），指定最小、最优、最大维度。否则推理时输入尺寸变化会导致引擎报错。
误区三：多个 Context 共享输入输出缓冲区。每个 Context 拥有独立的中间张量内存，但输入输出缓冲区由用户管理。如果多个 Context 并发执行且共享同一缓冲区，会导致数据竞争。正确做法是为每个 Context 分配独立的输入输出显存。
复盘总结：TensorRT 的架构设计体现了“一次构建，多次执行”的高效理念。Builder 承担了所有重计算优化工作，Engine 作为不可变资产被安全共享，Context 则提供轻量级的并发执行能力。在实际项目中，应优先将构建阶段离线完成，运行时只加载 Engine 并创建 Context，从而最大化推理吞吐量。理解这三者的职责边界，是后续深入分析算子融合策略和 CUDA 内核实现的基础。