关于使用TensorRT-API搭建与onnx-tensorrt parser的性能差距问题

[Oldpan]

很感谢你们的分享~干货很多，有个小疑问想请教下：

• 这一句中“除此之外我们发现网络结构中存在大量的Transpose+Reshape结构，这些结构是可以通过TensorRT API在设计网络的时候被合并的” ，基于API的搭建方式我理解的是你们去掉了一些多余的reshape操作（等价实现reshape但是用了更少的trt-layer），不过基于parse的方式搭建完network之后（network中包含Transpose->Reshape），会被内部trt优化成Transpose+Reshape结构，就和你使用nsight sys展示的一样，这其实已经合并多余的reshape/transpose吧，这个和直接使用API的方式合并，性能有差别吗？
• 我理解的基于API和基于Parse的本质区别就是可以避免一些onnx的胶水、碎片算子，通过trt-plugin的方式修改onnx模型（将碎片算子合并为一个，比如layernorm）然后通过parse+plugin的方式转模型，应该和直接API+plugin的性能是一样的吧？

希望可以和大佬交流下！

[DataXujing]

这里所说的合并是 把Transpose + Reshape结构在API中直接去掉,举个简单的例子有些OP被ONNX解析出来是连续做了3次 Transpose+Reshape, 这时候可能用1次 Transpose+Reshape替代就解决了，这样相当于去掉了2次。 再比如有时候因为pytorch在设计网络上的需要会先做Transpose+Reshape再加一个OP（比如矩阵乘）再接一个Transpoe+Reshape, 像这样的组合其实是可以直接用一个矩阵乘的OP替代或直接用一个矩阵乘+Transpose+Reshape替代的。在TensorRT API自己去设计的时候其实没必要完全遵循之前网络结构的冗余设计去进行简化，只要结果保持一致性就可以。

[DataXujing]

两种方式底层调用都是TensorRT API的实现,你说的最后一条其实性能是一样的（本项目其实在描述优化过程，Plugin部分的性能提高其实不是API带来的）。我自己觉得TensorRT API比ONNX Parser好一点的优势就是你可以控制一部分算子的合并，重新基于网络设计高效的inference实现。当然ONNX Parser通过一些方式也可以切断算子合并。其实随着ONNX Parser的不断强大，TensorRT API的这些优势也可能会消失。

我个人觉得生产环境下，还是优先考虑ONNX Parser +Plugin的这种方式，其实已经足够了。没必要耗费大量的时间去用API再重新实现一遍 :bug:

[Oldpan]

嗯嗯，感谢回复哈，确实是这样的，如果时间允许的话，直接Tensorrt-API是最好的方法