3、TensorRT核心概念：引擎、网络定义、优化器、精度校准、序列化与反序列化

在边缘部署场景中，TensorRT的价值不在于“能跑模型”，而在于“在有限的功耗、显存和延迟预算内把模型跑到极致”。要达成这一目标，必须理解TensorRT的六个核心概念：网络定义（Network Definition）、优化器（Builder/Optimizer）、引擎（Engine）、精度校准（Calibration）、序列化（Serialize）与反序列化（Deserialize）。这六个概念构成了TensorRT从“框架模型”到“可部署推理程序”的完整链路。本章将逐一拆解其原理、操作流程与实战陷阱，帮助你建立对TensorRT工作流的系统性认知。

上图展示了TensorRT的核心工作流：框架模型首先被解析为网络定义，随后由优化器进行图优化和精度选择（可借助精度校准实现INT8量化），最终生成引擎。引擎可以序列化为磁盘文件，在部署时通过反序列化加载并执行推理。下面逐一深入。

3.1 网络定义：模型的结构化中间表示

核心原理

网络定义（INetworkDefinition）是TensorRT对模型结构的内部表示，它不包含具体权重数值的优化布局，而是描述张量（Tensor）如何在层（Layer）之间流动。每一层都明确了输入输出张量的名称、维度、数据类型以及层类型（卷积、池化、全连接、激活等）。网络定义是后续所有优化的“原材料”，其质量直接决定优化器的发挥空间。

在边缘部署中，网络定义阶段最容易忽略的是输入张量的显式批大小（explicit batch）。TensorRT 8.0之后推荐使用显式批大小，即在构建网络时明确指定批大小维度，这允许优化器针对固定形状做更激进的内核选择。如果使用隐式批大小，优化器会保留动态维度，导致部分层无法融合。

操作流程

1. 创建Builder：builder = trt.Builder(logger)
2. 创建网络定义：network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))
3. 解析模型：通过ONNX解析器或手动添加层，将框架模型映射到网络定义。
4. 校验网络：检查输入输出张量名称、维度是否与预期一致。

3.2 优化器：图优化与内核自动调优

核心原理

优化器（Builder）是TensorRT的“编译引擎”，它接收网络定义，执行一系列图优化和内核选择操作。主要优化手段包括：层融合（将卷积+BN+ReLU融合为单个CBR内核）、精度选择（FP16/INT8）、内核自动调优（针对目标GPU选择最优的CUDA kernel）、内存复用（减少中间张量的显存占用）。

优化器的核心参数是构建配置（BuilderConfig），它控制着优化器的行为。例如，set_memory_pool_limit控制显存上限，set_flag控制是否启用FP16或INT8精度。在边缘设备上，显存和功耗是硬约束，优化器必须在这些约束下寻找最优解。

判断方法

如何判断优化器是否“尽力”了？观察生成的引擎文件大小和层融合日志。TensorRT在构建时会输出每层的信息，如果看到大量“Tactic”选择记录，说明优化器在尝试不同内核。如果日志中频繁出现“Unsupported layer”或“Fallback to default”，说明网络定义中存在优化器无法处理的层，需要回到网络定义阶段进行修正。

3.3 精度校准：INT8量化的关键步骤

核心原理

精度校准（Calibration）是启用INT8推理时的必要环节。其原理是：通过一小部分代表性数据（校准数据集）统计每层激活值的动态范围，然后选择合适的量化尺度（Scale）将FP32映射到INT8。TensorRT支持三种校准算法：MinMax（简单但易受离群点影响）、Entropy（KL散度，默认推荐）、Legacy（旧版熵校准）。

校准的核心矛盾是：动态范围过大导致精度损失，动态范围过小导致饱和截断。Entropy校准通过最小化量化前后信息熵的KL散度来寻找最优阈值，在大多数场景下表现最佳。

操作流程

1. 准备校准数据集：从训练集或验证集中随机抽取500-1000张代表性图片。
2. 创建校准器：实现IInt8Calibrator接口，提供get_batch_size和get_batch方法。
3. 设置构建配置：config.set_flag(trt.BuilderFlag.INT8)，并关联校准器。
4. 构建引擎：优化器在校准过程中会前向传播校准数据，统计激活分布。

案例拆解：Jetson Nano上的INT8量化

某安防项目需要在Jetson Nano上部署一个ResNet18分类模型，目标延迟小于15ms。FP16推理延迟为22ms，不满足要求。团队决定尝试INT8量化。

初始现象：使用训练集随机抽取的500张图片校准后，INT8模型在验证集上准确率从92.1%降至88.7%，降幅达3.4%。

分析过程：检查校准数据后发现，训练集图片多为白天场景，而部署现场有大量夜间红外图像。红外图像的像素分布与可见光差异较大，导致激活值动态范围估计不准。

实际操作：团队从现场采集了300张夜间图像，与训练集混合后重新校准。同时将校准算法从Entropy改为MinMax（因为红外图像动态范围较稳定）。重新构建后，准确率恢复至91.2%，延迟降至11ms。

复盘经验：校准数据的选择比校准算法更重要。在边缘部署中，务必采集目标场景的真实数据，哪怕数量少（200-300张）也比使用不匹配的通用数据效果好。

3.4 引擎、序列化与反序列化

核心原理

引擎（ICudaEngine）是优化器产出的最终可执行对象，它包含了所有层的融合内核、权重张量的优化布局、内存池分配方案。引擎是设备相关的，绑定特定的GPU架构和TensorRT版本。

序列化是将引擎转换为字节流（.engine文件）的过程，便于存储和分发。反序列化是运行时将字节流加载回内存并创建可执行上下文（IExecutionContext）的过程。反序列化后的引擎可以直接绑定输入输出缓冲区执行推理。

操作流程

// 序列化
std::ofstream file("model.engine", std::ios::binary);
file.write(engine->serialize()->data(), engine->serialize()->size());

// 反序列化
std::ifstream file("model.engine", std::ios::binary);
std::vector<char> data(std::istreambuf_iterator<char>(file), {});
trt::IRuntime* runtime = trt::createInferRuntime(logger);
ICudaEngine* engine = runtime->deserializeCudaEngine(data.data(), data.size());

常见误区

• 跨设备移植引擎：在Jetson Xavier上构建的引擎不能直接用于Jetson Nano，即使都是ARM架构。必须针对目标设备重新构建。
• 跨TensorRT版本使用引擎：TensorRT 8.x的引擎文件无法在TensorRT 9.x中加载。升级TensorRT后必须重新构建引擎。
• 忽略序列化文件大小：边缘设备的存储空间有限，一个包含大量权重的大模型引擎文件可能达到数百MB。建议在构建时使用set_weights_size或模型剪枝控制引擎大小。