[NPU]paddle适配昇腾910B推理没有cpu快

[wietisson]

paddle相关库版本如下：

npu-smi信息如下：

如题，相同的代码，使用npu启动，推理延时很高，比cpu启动的时候还要高。并且输入新的文本信息进行推理时，就如同第一次推理一样，需要30-50s。

下面是我用npu启动，推理的一些延时截图

下图是cpu启动的推理延时截图

下面是我使用paddle.inference.Config设置npu的截图

求懂paddle-npu的大佬帮忙看看是哪里不对劲吧！！！

[qili93]

请问您是用的推理模型和PaddleCustomDevice的版本是什么？可以跑下 python -c "import paddle_custom_device; paddle_custom_device.npu.version()" 看下输出的commit id。

NPU推理比CPU慢的原因可能有以下几种可能

1. NPU使用的aclop，是JIT的算子库，所以第一次运行的时候会有OP compile和cache的时间，会导致第一次推理运行很慢，可以检查下运行推理的目录下是否有kernel_meta_xxx的临时目录生成，这个就是用来缓存 op cache的临时文件。
2. NPU可能部分算子不支持，会自动fallbacking to CPU算子运行，这种情况下会存在反复内存从CPU->NPU之间的拷贝，性能可能比单独运行CPU还要慢。可以打开 export GLOG_v=6 之后运行一次并存储debug日志，查看是否有 fallbacking 的关键字。

对于(1)的修复办法有2个

• NPU的推理程序需要先 warmup 5-10次，再执行10次推理，然后取10次推理的均值，这样统计的推理耗时排除了cache的时间，会比较接近NPU真实计算的耗时；
• 把 PaddleCustomDevice 的版本升级到最新develop分支的代码，最新的代码已经逐步将大部分JIT的aclop修改为了AOT的aclnn算子库，不再需要OP compile和cache的步骤，前几次推理的时间就会快很多 (具体看模型，可能您的模型里面也有部分算子还停留在aclop没有升级到aclnn，这样也会导致如果没有warmup的话，前几次推理耗时会很长)

对于(2)的情况，暂时没有其他修复办法需要补齐缺失算子在NPU上的kernel适配代码，您可以把定位出来fallbacking to CPU的算子list发出来，我们需要评估下适配的可能性和工作量 (会存在NPU算子库中没有此类算子的情况，这样就没有办法适配)。

如果以上2个方法都不适用，那您这里也可以开启NPU Profiling的功能，通过昇腾CANN的profiling工具看下性能瓶颈，再针对性的优化。昇腾CANN的profiling工具可以参考这个回答中的例子，#785 ，并参考昇腾的官网文档进行数据采集之后的解析 https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/80RC1alpha003/devaids/auxiliarydevtool/atlasprofiling_16_0010.html

[wietisson]

非常感谢您的回答！

推理模型的版本是paddlepaddle v2.2.1
commit id如下图，为9e64916ce0610a8e73344d6db6ddc1d46477e4b3

目前我们采用了warmup的方式，发现在长度为x的输入warmup了以后，后面取5-10个长度为x的不同输入来推理，平均延时控制在几十毫秒。

取了最小长度1和最大长度512进行试验后，平均延时在35ms左右。

但是换成别的长度的输入，也还是会如同第一次访问等待30s。

所以晚点会尝试PaddleCustomDevice升级最新版本的方式，有结论了就再来comment。

[qili93]

但是换成别的长度的输入，也还是会如同第一次访问等待30s。

---

您好，这个属于正常现象，因为昇腾NPU的算子op cache就是会针对不同的输入输出shape进行JIT的op compile 和 cache，所以当输入输出变化的时候，就会需要重新进行 op compile 和 cache，因此耗时又会变得很长。

我们自己实际在进行推理耗时测试的时候，通常会针对所有可能的input shape都进行一次warm up，尽量让本地的kernel_meta_xxx 目录能把所有算子的输入输出shape的组合都预先cache到本地，之后在进行推理测试的时候会快很多了。

另外看了下这个commit id 9e64916 是 Tue Jan 23 09:44:54 2024 的，这个时间有点早了可能很多aclnn的算子都还没有接入，可以尝试更新到最新的PaddleCustomDevice develop分支的代码，大部分算子可能都已经升级为aclnn算子了，可以减少很多op compile和cache的消耗。

[HeChangHaoGary]

您好， 我也遇到了相同的问题，可以请求帮助分析一下吗？ 我的型号是910B1， 最新的commit id: 4091df3, 当我运行msprof --application="python tests/test_LeNet_MNIST.py" --output=ascend_log时输出的日志和readme中差不多， 但是msprof采集到的指标如下，Iteration Number和Top Time Iteration这两项都没有获得信息， 我观察到调用过程中npu-smi info的AI Core是没有变化的， 只有功率在变化

[qili93]

您好， 我也遇到了相同的问题，可以请求帮助分析一下吗？ 我的型号是910B1， 最新的commit id: 4091df3, 当我运行msprof --application="python tests/test_LeNet_MNIST.py" --output=ascend_log时输出的日志和readme中差不多， 但是msprof采集到的指标如下，Iteration Number和Top Time Iteration这两项都没有获得信息， 我观察到调用过程中npu-smi info的AI Core是没有变化的， 只有功率在变化

您好，关于msprof采集信息缺失的问题，可能需要到华为昇腾的社区咨询一下，建议可以到 https://gitee.com/ascend/modelzoo/issues 这里open相关issue咨询华为昇腾的工程师，个人猜测可能是profiling的某个metric缺失导致的信息采集不全。咨询华为昇腾工程师之后，可以通过 FLAGS_npu_profiling_dtypes 和 FLAGS_npu_profiling_metrics 这两个的环境变量把相关的metric给添加上，或者也可以直接修改 https://github.com/PaddlePaddle/PaddleCustomDevice/blob/develop/backends/npu/runtime/runtime.cc#L31 这里的源码文件来添加相关的metrics信息。

[HeChangHaoGary]

好的， 非常感谢您

[qili93]

您好，请问这个issue是否有解决您的问题，如果没有更多问题，请帮忙关闭此ISSUE，感谢 ：）

[danyXu]

• NPU的推理程序需要先 warmup 5-10次

请问这个具体怎么操作？是程序处理10次图片么