2、TensorRT基础回顾：TensorRT推理引擎架构、ONNX模型转换流程、静态shape与动态shape的区别
在正式进入动态shape与batch size配置实战之前，我们必须先夯实TensorRT的基础认知。很多同学在配置动态shape时遇到“明明设置了优化profile却报错”“转换成功但推理速度反而变慢”等问题，根源往往不在于API使用细节，而在于对TensorRT引擎架构、ONNX转换链路以及shape语义的理解存在偏差。本章将系统梳理这三块基石，并重点剖析静态shape与动态shape的本质差异，为后续章节的实战操作建立清晰的心智模型。
2.1 TensorRT推理引擎架构：从模型到CUDA Kernel的编译流水线
TensorRT本质上是一个深度学习推理优化器与运行时，它不直接执行原始框架（如PyTorch、TensorFlow）的计算图，而是将模型转换为高度优化的CUDA Kernel序列。理解其架构需要抓住三个核心组件：模型解析器（Parser）、引擎构建器（Builder）和运行时（Runtime）。
模型解析器负责读取ONNX、UFF或Caffe等格式的模型文件，将其解析为TensorRT内部的网络定义（Network Definition）。这一阶段会进行初步的算子映射，将不支持的算子标记为“无法转换”。引擎构建器是核心优化器，它接收网络定义和配置参数（如精度模式、工作空间大小、动态shape范围），执行层融合（Layer Fusion）、精度校准（INT8/FP16）、kernel自动调优等操作，最终生成一个序列化的引擎文件（.engine或.plan）。运行时则负责反序列化引擎文件，并在GPU上创建执行上下文（ExecutionContext），管理输入输出缓冲区和kernel执行。
从工程视角看，TensorRT的架构可以类比为“编译器”：ONNX模型是“源代码”，引擎构建器是“编译器”，生成的.engine文件是“可执行二进制”，而运行时就是“操作系统加载器”。这种设计带来两个关键优势：构建与部署分离（可以在离线环境完成耗时优化，在目标环境快速加载）和跨平台一致性（引擎文件与CUDA版本、GPU架构强相关，但运行时API保持稳定）。
2.2 ONNX模型转换流程：从PyTorch导出到TensorRT引擎的完整链路
ONNX（Open Neural Network Exchange）作为中间表示格式，是当前TensorRT最主流的模型输入方式。完整的转换流程包含四个阶段，每个阶段都有其特定的验证要点。
- 模型导出（PyTorch/TF → ONNX）：使用
torch.onnx.export或tf2onnx将训练好的模型导出为ONNX格式。此阶段需要固定输入shape（或指定动态轴），并确保所有算子均被ONNX支持。 - ONNX验证与简化：使用
onnx.checker验证模型完整性，使用onnx-simplifier（如onnxsim）消除冗余节点、常量折叠，使计算图更简洁。 - TensorRT解析与构建：通过
trtexec工具或Python API（tensorrt.Builder）加载ONNX文件，设置构建配置（精度、工作空间、动态shape范围），执行构建。 - 引擎验证与部署：加载生成的.engine文件，使用随机输入或真实数据验证输出一致性（与原始模型对比），然后集成到推理服务中。
在实际操作中，最常见的失败点集中在第一阶段和第三阶段。例如，PyTorch中的torch.where、torch.topk等算子可能无法直接映射到TensorRT，需要手动替换或使用插件（Plugin）。此外，ONNX导出时若未正确设置dynamic_axes参数，导出的模型将是静态shape，后续无法在TensorRT中配置动态batch。
| 阶段 | 关键操作 | 常见问题 | 验证方法 |
|---|---|---|---|
| 模型导出 | 设置dynamic_axes、opset版本 | 算子不支持、shape推断错误 | onnx.checker + onnx.shape_inference |
| ONNX简化 | 常量折叠、冗余消除 | 简化后精度变化 | 对比简化前后输出 |
| TensorRT构建 | 设置FP16/INT8、动态Profile | 构建失败、显存不足 | 查看构建日志、使用trtexec |
| 引擎部署 | 反序列化、绑定buffer | shape不匹配、精度下降 | 对比推理输出与原始模型 |
2.3 静态Shape与动态Shape的本质区别：构建期锁定 vs 运行期适配
静态Shape（Static Shape）指在引擎构建时，所有输入和输出张量的维度都是完全确定的。例如，输入固定为[1,3,224,224]，batch size固定为1。动态Shape（Dynamic Shape）则允许在构建时指定一个维度范围，例如batch size在[1, 8, 16]之间变化，或输入分辨率在[224, 512]范围内调整。
这种区别的根源在于TensorRT的kernel选择机制。对于静态Shape，构建器可以为特定维度生成完全特化的CUDA Kernel，例如针对224x224输入优化卷积的循环展开和共享内存分配。而动态Shape要求构建器生成一个“通用”kernel，能够处理范围内的任意维度，或者为每个可能的维度组合预生成多个kernel，在运行时根据实际输入shape进行选择。前者牺牲灵活性换取极致性能，后者以少量性能开销换取部署弹性。
从工程实践角度，静态Shape适合固定分辨率的视频流分析、固定batch的离线批处理等场景；动态Shape则适合多租户在线服务（不同请求的batch size不同）、多分辨率检测任务（如同时处理720P和1080P图像）等场景。值得注意的是，动态Shape并非“免费午餐”——它要求构建时配置优化Profile（Optimization Profile），定义每个动态维度的min、opt、max值。其中opt值的选择对性能影响显著，因为TensorRT会针对opt值进行重点优化。
opt值设置为最常见场景，并控制min和max的跨度在4倍以内。
2.4 实战场景拆解：动态Shape在目标检测服务中的配置决策
假设我们正在部署一个工业质检目标检测模型，输入为工业相机拍摄的零件图像，分辨率固定为1280x720，但每次请求的batch size会随产线节拍变化（通常为1~8张）。初始方案采用静态Shape，将batch固定为4，但实际运行时发现：当请求batch为1时，GPU利用率极低；当batch为8时，又无法处理。这促使我们切换到动态Shape。
具体操作步骤如下：
- ONNX导出时设置动态batch：在
torch.onnx.export中设置dynamic_axes={'images': {0: 'batch'}}，确保ONNX模型的第一维是动态的。 - 配置优化Profile：在TensorRT构建器中设置
profile.set_shape('images', min=(1,3,720,1280), opt=(4,3,720,1280), max=(8,3,720,1280))。这里opt选择4，因为产线平均每批次处理4张图像。 - 运行时动态绑定：在推理时，根据实际请求的batch大小，调用
context.set_input_shape('images', (actual_batch,3,720,1280))，并重新分配输入输出缓冲区。 - 性能验证：分别测试batch=1、4、8时的延迟和吞吐量。结果显示，batch=1时延迟比静态batch=4方案降低约30%（因为无需填充空样本），batch=8时吞吐量达到静态方案的95%以上。
这个案例揭示了动态Shape的核心价值：在不显著牺牲性能的前提下，实现资源利用率的弹性化。但同时也暴露了代价——构建时间从静态的2分钟增加到动态的8分钟，且引擎文件从15MB增加到22MB。因此，在batch size波动不大且硬件资源充足时，静态Shape仍是更优选择。
2.5 常见误区与总结复盘
在基础回顾阶段，有三个高频误区需要特别澄清：
- 误区一：动态Shape一定比静态Shape慢。实际上，如果
opt值设置合理，且实际输入shape接近opt值，性能差距可以控制在5%以内。只有在输入shape频繁偏离opt值且跨度较大时，性能才会明显下降。 - 误区二：ONNX模型是动态的，TensorRT引擎就自动支持动态Shape。ONNX的动态轴只是“允许”维度可变，TensorRT构建时仍需显式配置Profile，否则默认按静态处理。
- 误区三：动态Shape可以无限制地改变维度。实际上，TensorRT要求所有动态维度必须在构建时声明的
min和max范围内，超出范围会导致运行时错误。