昇腾910B arm架构npu推理速度太慢

[fallbernana123456]

描述问题

使用OCR 产线推荐代码： `import cv2 from paddlex import OCRPipeline from paddlex import PaddleInferenceOption from paddlex.pipelines.OCR.utils import draw_ocr_box_txt

实例化 PaddleInferenceOption 设置推理配置

kernel_option = PaddleInferenceOption() kernel_option.set_device("gpu:0")

pipeline = OCRPipeline( 'PP-OCRv4_mobile_det', 'PP-OCRv4_mobile_rec', text_det_kernel_option=kernel_option, text_rec_kernel_option=kernel_option,) result = pipeline.predict( {"input_path": "https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png"}, )

draw_img = draw_ocr_box_txt(result['original_image'],result['dt_polys'], result["rec_text"]) cv2.imwrite("ocr_result.jpg", draw_img[:, :, ::-1]) ` 使用同一张图片用时第一次很慢，后面的会变快，但是我的需求是识别输入的每张图片，result = pipeline.predict() 识别不同图片是很慢很慢。这个问题之前的版本出现过，现在看来还是没有修复。跟 Warning: tiling offset out of range, index: 32 这个有关吗？

在当前目录会生成kernel_meta/目录。

复现

通过docker环境安装昇腾npu版本。https://github.com/PaddlePaddle/PaddleX/blob/release/3.0-beta/docs/tutorials/INSTALL_OTHER_DEVICES.md

环境

cpu : Kunpeng-920 GPU : 昇腾910B 32G aarch64 ARM 架构 内存： 100G python ： 3.9

[TingquanGao]

想问下两次预测用的是同一个pipeline对象吗？怀疑是第一次预测时存在模型加载等耗时，这样的话，在第一次后，之后预测任意图片都是比较快的。

[fallbernana123456]

想问下两次预测用的是同一个pipeline对象吗？怀疑是第一次预测时存在模型加载等耗时，这样的话，在第一次后，之后预测任意图片都是比较快的。

是一个pipeline对象 `
import cv2 from paddlex import OCRPipeline from paddlex import PaddleInferenceOption from paddlex.pipelines.OCR.utils import draw_ocr_box_txt import time

kernel_option = PaddleInferenceOption()
kernel_option.set_device("npu:0")

pipeline = OCRPipeline(
    'PP-OCRv4_mobile_det',
    'PP-OCRv4_mobile_rec',
        text_det_kernel_option=kernel_option,
            text_rec_kernel_option=kernel_option,)

for i in range(3):
    time1=time.time()
    if i==1:
        result = pipeline.predict(
                        {"input_path": "test1.png"},
                                            )
    else:
        result = pipeline.predict(
                {"input_path": "general_ocr_002.png"},
                )

    draw_img = draw_ocr_box_txt(result['original_image'],result['dt_polys'], result["rec_text"])
    time2=time.time()
    print("use time: ",time2-time1)

`

我觉得不是预测时模型加载的耗时。

[fallbernana123456]

想问下两次预测用的是同一个pipeline对象吗？怀疑是第一次预测时存在模型加载等耗时，这样的话，在第一次后，之后预测任意图片都是比较快的。

查看代码发现几个问题：

1. OCRPipeline如果不设置output，默认会修改识别的原始文件为标了box后的图片
2. 识别慢主要是每一个box的 text_rec都需要3秒左右，既然text_det_kernel_option 和 text_rec_kernel_option 可以设置device,可以通过并行 多个text_rec来提高效率，充分利用多NPU的效率
3. PP-OCRv4_server_rec 和 PP-OCRv4_mobile_rec 有什么区别？
4. 尽管通过text_det_kernel_option 和 text_rec_kernel_option 设置了 device ，但是其实还是都放在第一个NPU上，这个参数没有作用。 查看代码 paddle_inference_predictor.py 里
   config.enable_custom_device('npu') os.environ["FLAGS_npu_jit_compile"] = "0" os.environ["FLAGS_use_stride_kernel"] = "0" os.environ["FLAGS_allocator_strategy"] = "auto_growth" os.environ[ "CUSTOM_DEVICE_BLACK_LIST"] = "pad3d,pad3d_grad,set_value,set_value_with_tensor" 是因为对于npu做了特殊操作，不能指定npu是吗？

[TingquanGao]

感谢反馈！

1. OCRPipeline预测结果保存目录的问题，我们再看下如何调整比较合理；
2. 关于提高预测效率的问题，我们会评估下该需求；
3. PP-OCRv4_server_rec 模型精度更高但推理速度相对较慢，PP-OCRv4_mobile_rec则相反，推荐在移动端等算力有限的平台使用；
4. npu应该也可以指定卡号，我这边找机器验证一下，可以的话我改下paddlex代码。

[fallbernana123456]

感谢反馈！

1. OCRPipeline预测结果保存目录的问题，我们再看下如何调整比较合理；
2. 关于提高预测效率的问题，我们会评估下该需求；
3. PP-OCRv4_server_rec 模型精度更高但推理速度相对较慢，PP-OCRv4_mobile_rec则相反，推荐在移动端等算力有限的平台使用；
4. npu应该也可以指定卡号，我这边找机器验证一下，可以的话我改下paddlex代码。

最最主要的是速度太慢，在GPU上是毫秒级别的，为啥在NPU上都是几十秒，像我们是做视频字幕识别，这样是迁移不到NPU上的。期望能尽早解决这个问题。

[wangna11BD]

第一次运行触发了jit编译，导致推理很慢，第二次换图像后由于图像变化导致算子运行的shape或者数值范围产生较大变化，还是有算子触发了jit编译，Warning: tiling offset out of range, index: 32就是jit编译时的生成的。可以试试 1.把jit编译关了 export FLAGS_npu_jit_compile=0 2.多跑一些数据，一段时间后应该就不会再编译了，推理时间会稳定下来。

[TingquanGao]

也同步一下PaddleX的近期更新：

1. 关于Pipeline保存目录的问题，目前对整个PaddleX Inference模块进行了升级，可以解决该问题，预计本月底完成全部代码更新，到时候我再同步；
2. 关于开启并行提速，新升级的PaddleX Inference速度相较目前会有一定速度提升，但尚未支持并行，我们会考虑再后期陆续支持；
3. 新升级的PaddleX Inference会支持不同模型设置不同device id。

[fallbernana123456]

第一次运行触发了jit编译，导致推理很慢，第二次换图像后由于图像变化导致算子运行的shape或者数值范围产生较大变化，还是有算子触发了jit编译，Warning: tiling offset out of range, index: 32就是jit编译时的生成的。可以试试 1.把jit编译关了 export FLAGS_npu_jit_compile=0 2.多跑一些数据，一段时间后应该就不会再编译了，推理时间会稳定下来。

export FLAGS_npu_jit_compile=0 这个方法可行，基本控制在一秒左右了。