TRT与TF-TRT差异及Jetson设备模型部署转换相关问题咨询

问题1 模型体积、显存未达预期是否正常，是否存在配置问题 #

• 这个现象不属于正常情况，大概率是TF-TRT的配置参数不合理导致的：
  • 你观测到的16GB显存占用是TensorFlow默认的全量显存预分配机制导致的，和模型本身大小无关，可以在代码中添加tf.config.experimental.set_memory_growth(physical_devices[0], True)关闭预分配，就能看到真实的显存占用变化。
  • 模型体积变大通常是开启了FP32精度转换、或者仅做了子图拆分没做量化压缩导致的，如果要缩小体积需要开启INT8/FP16量化，同时设置合理的最小分段节点数，避免大量小TRT子图夹带冗余的TF节点。
  • 目前仅FPS提升说明算子优化已经生效，但内存相关的优化项没有开启，属于配置缺失问题。

问题2 FPS大幅跳变的原因和修复方案 #

• 跳变核心原因是TF-TRT的懒加载机制+子图调度开销导致的：
  • 首帧推理时TRT需要完成对应子图的内核编译、显存分配，所以耗时高FPS低，后续帧复用编译好的内核所以FPS突然拉高。
  • 中间的波动是因为部分未被TRT优化的原生TF算子和TRT算子调度时出现的资源抢占，或者输入的视频帧存在分辨率波动、动态尺寸适配的额外开销。
• 修复方案：
  1. 正式推理前先跑10-20次假的预热推理，把所有TRT内核提前编译加载完成，消除首帧延迟。
  2. 固定输入的图像分辨率，提前做resize预处理不要放在推理流程里。
  3. 调大TF-TRT的最小分段节点阈值，把过小的子图留给TF原生执行，减少跨框架调度的开销。

问题3 TRT性能是否优于TF-TRT，二者差异 #

• 该说法属实，原生TensorRT的性能普遍比TF-TRT高15%-50%，具体差异如下：
  • 原生TRT会对整个计算图做端到端的优化，包括算子融合、量化、内核调优、显存复用，没有额外的框架交互开销。
  • TF-TRT仅会把TF计算图中符合TRT支持的算子拆成独立子图用TRT优化，剩下的算子还是用TF原生执行，子图之间的调度、数据格式转换会产生额外开销，优化程度受限于TF算子的TRT适配度。
  • 原生TRT支持更细粒度的量化配置、动态形状调优，TF-TRT的对应功能通常会比原生TRT晚1-2个版本才会支持。

问题4 PyTorch的HourGlass CNN转TRT的实现方式 #

• 标准转换流程如下：
  1. 先把PyTorch训练好的HourGlass模型导出为ONNX格式，导出时固定输入形状，打开opset_version=13以上的配置，避免不支持的算子报错。
  2. 用trtexec工具或者TensorRT的Python API加载ONNX文件，开启对应的精度优化（FP16/INT8），生成TRT序列化引擎文件。
  3. 推理时直接加载序列化后的引擎文件，做输入输出的前后处理即可。
• 可参考的公开资源可以直接在GitHub搜索HourGlass TensorRT转换相关的开源实现，也可以在YouTube搜索PyTorch ONNX TensorRT转换的通用教程，适配HourGlass的算子调整即可。

问题5 TensorFlow转TRT和PyTorch转TRT的难度对比 #

• 目前PyTorch转TRT的实现难度更低：
  • PyTorch生态和TensorRT的适配更成熟，ONNX作为中间格式的兼容性更好，大部分常见CV算子都能完美转换，遇到不支持的算子也有更丰富的自定义实现参考。
  • TensorFlow转TRT不管是用TF-TRT还是先转ONNX再转TRT，都容易遇到TF特有算子（比如tf.control_dependencies、部分tf.math算子）不兼容的问题，排查成本更高，尤其是TF1.x版本的模型适配难度更大。

内容的提问来源于stack exchange，提问作者Shabnam