PaddleX的Ocr产线使用高性能插件几乎没有提升，某些情况下推理速度不如普通模式？

[1756112901]

环境 centos7.9
docker镜像 paddlepaddle/paddle:3.0.0b2-gpu-cuda11.8-cudnn8.6-trt8.5
显卡cuda 11.8 如下

用的是Ocr产线

测试同样40张图片，高性能模式 推理速度大概在 17秒
（另外这个警告是否有影响：
[WARNING] fastdeploy/runtime/backends/paddle/paddle_backend.cc(178)::BuildOption Currently, Paddle-TensorRT does not support the new IR, and the old IR will be used.）

同样的40张图片，普通模式 大概在18秒

请问这种样情况是正常的吗，还是我有哪个包版本不对？求解

[1756112901]

后续我把所有的模型目录和core文件删掉后，重新运行，出现报错，这是什么问题？
然后没做其他操作，我再重新运行，程序却能正常跑起来？

[TingquanGao]

想问下这个耗时是如何统计的呢？方便提供下代码吗

[1756112901]

代码就是简单的 使用 PaddleX的Ocr产线去批量识别图片，没有涉及复杂的操作，另外补充的第一次运行高性能时报错是否对这会有影响？

[1756112901]

想问下这个耗时是如何统计的呢？方便提供下代码吗
如上

[1756112901]

@TingquanGao 麻烦大佬看一下，问题出在哪？是否有提升的空间？开启搞性能模式是大概能提升多少呢？ 这是我的Ocr配置

[TingquanGao]

由于推理引擎在首次推理时需要初始化，因此通常前几次推理耗时较长，建议多预测几次，比如剔除前5次，从第6次开始统计。

[TingquanGao]

我没看到有报错，截图中的红色框标注的是警告warning，具体是否会对推理速度有影响，我得再确认下。

[1756112901]

@TingquanGao
报错是在最后一张图，不是我红色框标注的部分。麻烦重新看一下。 好，我把次数提升再尝试一下。

后续我把所有的模型目录和core文件删掉后，重新运行，出现报错，这是什么问题？ 然后没做其他操作，我再重新运行，程序却能正常跑起来？

[Bobholamovic]

@1756112901 请设置export FLAGS_enable_pir_api=0后尝试～

[1756112901]

@Bobholamovic 在docker容器里面设置完 ，重试了一下，新的额报错。大佬麻烦看一下

@1756112901 请设置export FLAGS_enable_pir_api=0后尝试～

[Bobholamovic]

建议把模型目录里叫做trt_serialized*的缓存文件以及shape_range_info.pbtxt文件删掉后重试

[1756112901]

我已经把您提及的文件删除了，甚至删除了整个/root/.paddlex目录。重新运行程序，可以看到程序重新下载了新的模型，但是报一样的错。我也尝试清空文件后，用这个直接命令调用的方式也是报一样的错误。（paddlex --pipeline OCR --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png --device gpu:0 --use_hpip --serial_number {序列号}）

[Bobholamovic]

这样的话，看起来在你的环境里可能使用不了Paddle-TensorRT，建议参考高性能推理文档手动修改推理后端～

[1756112901]

我用的docker镜像是官方提供的 paddlepaddle/paddle:3.0.0b2-gpu-cuda11.8-cudnn8.6-trt8.5， 这也用不了吗？ 难受了。好吧，我试试修改一下推理后端

[Bobholamovic]

如果是docker部署的话，感觉环境问题的可能性小一些。请问使用官方默认的图像进行推理，可以成功嘛？

[1756112901]

@Bobholamovic 我之前是拉取的官方的PaddlePaddle镜像然后再安装PaddleX及其他所需的东西，可能环境存在问题。

现在我重新拉取了官方的PaddleX的docker镜像：ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddle:3.0.0b2-gpu-cuda11.8-cudnn8.6-trt8.5
安装了 高性能插件

设置了export FLAGS_enable_pir_api=0

然后执行命令（用的是官方默认的图像），然后出现了新的报错
paddlex --pipeline OCR --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0 --use_hpip --serial_number {序列号}

大佬看看什么问题

[Bobholamovic]

请问你使用的GPU型号是什么呀？

[1756112901]

3090

[1756112901]

[1756112901]

具体参数如下

[1756112901]

@Bobholamovic 另外如果一开始没有设置export FLAGS_enable_pir_api=0的话，执行paddlex --pipeline OCR --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0 --use_hpip --serial_number {序列号}
则报的错是这样的情况

@Bobholamovic 我之前是拉取的官方的PaddlePaddle镜像然后再安装PaddleX及其他所需的东西，可能环境存在问题。

现在我重新拉取了官方的PaddleX的docker镜像：ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddle:3.0.0b2-gpu-cuda11.8-cudnn8.6-trt8.5 安装了 高性能插件

设置了export FLAGS_enable_pir_api=0

然后执行命令（用的是官方默认的图像），然后出现了新的报错 paddlex --pipeline OCR --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0 --use_hpip --serial_number {序列号}

大佬看看什么问题

[Bobholamovic]

考虑到使用的模型和输入数据都是官方的，这个问题确实非常奇怪，我暂时也无法判断原因。想问下其他的产线也会有类似的问题不？

[1756112901]

暂时只用到Ocr的，另外再补充多一点。在干净的环境，（没有额外设置export FLAGS_enable_pir_api=0）第一次执行paddlex --pipeline OCR --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0 --use_hpip --serial_number {序列号}
就报错上面shape的问题， 然后再第二次一样的命令，就能运行出得到结果。但情况应该就是我最开始提及的，虽然开启了高性能但实际和普通模式基本一样

[1756112901]

是按照这样去用其他推理后端么

这样的话，看起来在你的环境里可能使用不了Paddle-TensorRT，建议参考高性能推理文档手动修改推理后端～

[Bobholamovic]

是按照这样去用其他推理后端么

这样的话，看起来在你的环境里可能使用不了Paddle-TensorRT，建议参考高性能推理文档手动修改推理后端～

是的

[Bobholamovic]

export FLAGS_enable_pir_api=0

目前有一个待修复的bug，就是不指定这个环境变量的话，即使在默认推理配置中启用了trt，实际也不会使用，这样的话切换后端引擎带来的加速就很有限了，甚至在某些情况下可能掉速度。我们将在下个版本修复这个bug。

关于第一次跑报错，第二次没有错误，确实很奇怪，之前我们在测试过程中没有遇到过这样的问题。如果方便的话，可以试试其他产线，看看是否有类似的问题，以及试试CPU推理有没有类似的问题～

[1756112901]

好吧。期待下一个版本修复。 另外关于第一次跑错，第二次没有错误，是不是因为第一次构建失败了，第二次再运行没有进行相关校验或者检查导致的呢？因为这个问题是可以复现的，只要自动下载新的模型，第一次第二次运行 paddleX命令就复现。 有空我再尝试一下其他产线

[Bobholamovic]

如果没有设置export FLAGS_enable_pir_api=0，正常来说是不会缓存构建结果的，所以第二次运行和第一次运行观察到的现象不一样，是有些让人费解的

[1756112901]

重新尝试了下，还是一样干净的环境，先执行一遍普通模式，可正常运行，自动下载官方的模型
paddlex --pipeline duck.yaml --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0

使用的是官方的 Ocr server模型（duck.yaml）

然后更改了一下Rec的配置文件inference.yml的参数trt_dynamic_shapes

没有设置export FLAGS_enable_pir_api=0
然后启用高性能模式，就没之前提及的报错，可以正常运行
paddlex --pipeline duck.yaml --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0 --use_hpip --serial_number {序列号}

但是在这样方式下的 高性能 对比 普通模式 推理速度上并没有提升

还有只要设置了export FLAGS_enable_pir_api=0，再去执行一样的命令，还是会报这个错

分割线 下面是之前提及的两个报错情况

@Bobholamovic 另外如果一开始没有设置export FLAGS_enable_pir_api=0的话，执行paddlex --pipeline OCR --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0 --use_hpip --serial_number {序列号} 则报的错是这样的情况

@Bobholamovic 我之前是拉取的官方的PaddlePaddle镜像然后再安装PaddleX及其他所需的东西，可能环境存在问题。
现在我重新拉取了官方的PaddleX的docker镜像：ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddle:3.0.0b2-gpu-cuda11.8-cudnn8.6-trt8.5 安装了 高性能插件
设置了export FLAGS_enable_pir_api=0
然后执行命令（用的是官方默认的图像），然后出现了新的报错 paddlex --pipeline OCR --input https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_001.png --device gpu:0 --use_hpip --serial_number {序列号}


大佬看看什么问题