3、TensorRT基础概念：网络定义、引擎构建、序列化与反序列化、执行上下文、绑定张量等核心术语

在深入TensorRT插件开发之前，必须首先建立对TensorRT运行时核心对象模型的清晰认知。插件本质上是一个被TensorRT引擎在推理阶段调用的计算单元，它必须与TensorRT的构建期（Build Time）和运行期（Runtime）架构无缝集成。本章将系统拆解五个核心术语：网络定义（INetworkDefinition）、引擎（ICudaEngine）、序列化与反序列化、执行上下文（IExecutionContext）以及绑定张量（Tensor Binding），并阐明它们之间的数据流与生命周期关系。理解这些概念是编写正确、高效插件的前提，也是排查推理错误（如形状不匹配、内存越界）的理论基础。

上图展示了TensorRT从构建到运行的核心对象流转。构建期负责将高层网络描述转化为高度优化的推理引擎，而运行期则负责加载引擎并高效执行。插件开发者的工作横跨这两个阶段：在构建期提供层实现和验证逻辑，在运行期提供实际的计算内核。下面我们将逐一深入每个概念。

3.1 网络定义（INetworkDefinition）：计算图的蓝图

核心原理

网络定义是TensorRT对深度学习模型计算图的抽象表示。它不关心具体的硬件设备，只描述张量（Tensor）如何流动、层（Layer）如何连接。在插件开发中，您需要将自定义算子封装为一个继承自IPluginV2DynamicExt（或相应版本）的类，并通过addPluginV2接口将该插件实例添加到网络定义中。网络定义中的张量具有数据类型（DataType）、维度（Dims）和格式（Format）属性，这些属性在构建期会被用于优化选择。

操作流程

1. 创建网络定义：通过builder->createNetworkV2(0)创建，建议显式设置显式批处理维度（1U << static_cast<uint32_t>(NetworkDefinitionCreationFlag::kEXPLICIT_BATCH)）。
2. 添加输入张量：使用network->addInput("input", DataType::kFLOAT, Dims4{1, 3, 224, 224})定义输入名称、类型和形状。
3. 添加插件层：创建插件实例后，调用network->addPluginV2(&inputs[0], 1, plugin)将其挂载到网络中。
4. 标记输出：使用network->markOutput(*tensor)指定网络输出张量。

案例拆解：自定义ROI Pooling层的网络集成

假设您要实现一个自定义的ROI Pooling层。在构建期，您需要：

// 创建插件实例
auto roiPool = new ROIPoolingPlugin(roiSize, spatialScale);
// 添加输入：特征图 (1, 256, 100, 100) 和 ROI 坐标 (N, 4)
auto featMap = network->addInput("feat", DataType::kFLOAT, Dims4{1, 256, 100, 100});
auto rois = network->addInput("rois", DataType::kFLOAT, Dims3{1, 4, 1}); // 简化示例
// 将插件添加到网络
auto roiLayer = network->addPluginV2(&featMap, 1, *roiPool);
// 设置输出
network->markOutput(*roiLayer->getOutput(0));

这里的关键是插件必须正确实现getOutputDimensions方法，返回输出张量的形状，否则构建器无法进行后续的内存规划和内核选择。

3.2 引擎构建（ICudaEngine）与序列化/反序列化

核心原理

引擎构建是将网络定义、权重、算法选择、内核调优等打包成可执行对象的过程。构建器（Builder）会尝试多种算法（Tactic），选择在目标GPU上延迟最低的组合。构建出的ICudaEngine是平台相关的，它包含了特定GPU架构（如SM86）的优化内核。序列化是将引擎转换为字节流（通常保存为.engine文件），以便后续加载，避免重复构建的时间开销。反序列化则是将字节流重新还原为引擎对象。

构建与序列化流程

实战场景：跨平台部署的序列化策略

在自动驾驶场景中，模型在Orin上训练并构建引擎，但实际部署在另一台Orin设备上。由于GPU架构相同（均为Ampere架构），序列化后的引擎可以直接加载。但如果部署到Jetson Nano（Maxwell架构），则必须重新构建。因此，序列化文件与GPU架构强绑定，与CUDA版本和TensorRT版本也相关。建议在部署脚本中检查设备计算能力（deviceProp.major和minor），不匹配时触发重新构建。

3.3 执行上下文（IExecutionContext）与绑定张量（Binding）

核心原理

执行上下文是引擎的运行时实例。一个引擎可以被多个上下文共享，每个上下文拥有独立的中间激活内存（Activation Memory）和内核执行状态。绑定张量是引擎输入/输出的抽象标识，通过索引或名称访问。在运行期，您需要为每个绑定张量分配GPU显存，并将设备指针传递给上下文。

操作流程：从引擎到推理

1. 创建上下文：auto context = engine->createExecutionContext();
2. 获取绑定索引：int inputIdx = engine->getBindingIndex("input");
3. 设置输入形状（动态形状时）：context->setBindingDimensions(inputIdx, Dims4{1, 3, 224, 224});
4. 分配显存：cudaMalloc(&inputBuffer, size); 同样为输出分配。
5. 执行推理：context->enqueueV2(&buffers[0], stream, nullptr); 其中buffers数组包含所有输入输出指针。

案例拆解：多上下文并发推理

在视频分析场景中，需要同时处理4路视频流。可以为每路视频流创建一个执行上下文，共享同一个引擎。每个上下文绑定不同的输入输出缓冲区，通过4个CUDA流并行执行。关键点：

// 每路流独立上下文
IExecutionContext* ctx[4];
for (int i = 0; i < 4; i++) {
    ctx[i] = engine->createExecutionContext();
    cudaMalloc(&inBuf[i], inputSize);
    cudaMalloc(&outBuf[i], outputSize);
}
// 每个流执行
for (int i = 0; i < 4; i++) {
    cudaMemcpyAsync(inBuf[i], hostInput[i], inputSize, cudaMemcpyHostToDevice, stream[i]);
    ctx[i]->enqueueV2(&inBuf[i], stream[i], nullptr);
    cudaMemcpyAsync(hostOutput[i], outBuf[i], outputSize, cudaMemcpyDeviceToHost, stream[i]);
}

这里需要注意，绑定张量的顺序必须与引擎创建时的顺序一致。通常输入在前，输出在后，但插件层可能会改变内部顺序，因此建议通过名称获取索引，而不是硬编码顺序。

3.4 核心术语对比与总结

常见误区与复盘

• 误区1：认为引擎可以跨设备通用。实际上，引擎与GPU架构、TensorRT版本、CUDA版本强绑定。解决方案是构建时记录builder->getPlatform()信息，部署时校验。
• 误区2：忽略动态形状的绑定维度设置。如果网络定义使用了-1维度，必须在推理前调用setBindingDimensions，否则默认维度为0，导致内核启动失败。
• 误区3：在插件中直接使用全局CUDA上下文。TensorRT要求插件使用传入的cudaStream_t执行所有CUDA操作，以保证多流并发正确性。
• 误区4：序列化插件时未保存自定义属性。如果插件有配置参数（如ROI大小），必须在serialize方法中写入这些参数，并在deserialize时恢复，否则反序列化后的插件行为不一致。