我先分享一下我了解的情况：
当前paddle对910的支持是基于小算子方式，所以直接跑小模型的推理性能就是如此（大模型有优化过，所以应该还好）。
对于昇腾硬件的小模型推理部署，如果有性能要求，建议走paddle2onnx-om，然后使用昇腾的推理引擎上部署。

我先分享一下我了解的情况： 当前paddle对910的支持是基于小算子方式，所以直接跑小模型的推理性能就是如此（大模型有优化过，所以应该还好）。 对于昇腾硬件的小模型推理部署，如果有性能要求，建议走paddle2onnx-om，然后使用昇腾的推理引擎上部署。

@onecatcn 感谢分享。之前有怀疑过是我的环境没有配置好导致看起来占用了显存但实际计算没走npu，这么看来还是paddle本身适配的问题？不过这几十个字推理十几秒的速度是不是太夸张了点

还有一个疑惑的点是，utc和uie的推理性能为何会差这么多？因为我的服务需要同时加载多个uie和utc模型推理，测试时发现一个现象：任意一个uie模型首次推理后，所有的uie模型往后的几次推理都快很多；而utc切换模型后速度好像反而变慢了

您好，推理性能慢的问题一般有这么几种可能性：
1、部分小算子npu不支持，fall back到cpu上运算，该过程耗时久，排查方法：
先设置日志级别为3，export GLOG_v=3；然后完成一次推理，保存日志，在日志中搜索关键字"fallbacking to CPU"，就可以找到fall back到cpu的算子。
2、算子编译耗时，npu存在一边运行一边编译算子的情况，通常会表现为开始性能慢，当所有算子编译缓存完成后，后期性能变快。可通过设置环境变量export ASCEND_MAX_OP_CACHE_SIZE=5000改变缓存区大小，设置export FLAGS_npu_jit_compile=0关闭jit编译。
3、如果以上两种都不是，可采集profiling来分析性能情况。

您好，推理性能慢的问题一般有这么几种可能性： 1、部分小算子npu不支持，fall back到cpu上运算，该过程耗时久，排查方法： 先设置日志级别为3，export GLOG_v=3；然后完成一次推理，保存日志，在日志中搜索关键字"fallbacking to CPU"，就可以找到fall back到cpu的算子。 2、算子编译耗时，npu存在一边运行一边编译算子的情况，通常会表现为开始性能慢，当所有算子编译缓存完成后，后期性能变快。可通过设置环境变量export ASCEND_MAX_OP_CACHE_SIZE=5000改变缓存区大小，设置export FLAGS_npu_jit_compile=0关闭jit编译。 3、如果以上两种都不是，可采集profiling来分析性能情况。

@a31413510 根据您的答复进行了对应尝试：
1、设置日志级别后进行一次推理，在日志里没有找到fallbacking相关信息，可以排除此问题

2、首先尝试在910B（cann8，paddle版本develop）上export FLAGS_npu_jit_compile=0报错ACL error 50002，只设置ASCEND_MAX_OP_CACHE_SIZE=5000没有问题。
接着在910（cann7，paddle版本2.6.1）上尝试设置两个环境变量都没问题，又测了一次，utc和uie的推理速度都无变化，与之前基本相同。
基于您提到的所有算子编译缓存完成后性能会变快，在首次推理后，尝试输入与先前长度相同、但内容不同的文本进行推理，发现utc的速度确实快了不少。不知我的理解是否到位？

另外uie的速度无变化，单条推理仍然需要1-2s。请问uie是否还有优化空间？
3、如何采集profiling？以及采集后怎样分析性能呢？

1、utc首次推理慢，后面推理速度变快，很有可能就是算子编译导致的。设置ASCEND_MAX_OP_CACHE_SIZE=5000，是增大缓存空间，防止空间满了重新缓存，可以在这个基础上多测试几次uie，看看速度会不会逐渐变快。另外，可否提供一下在910B上编译PaddleCustomDevice的commit，如果不是最新的，建议使用最新的develop。

2、昇腾profiling性能工具详细使用方法可以参考： https://www.hiascend.com/document/detail/zh/canncommercial/80RC2/devaids/auxiliarydevtool/topic_0000001949500228.html
这里简单贴一个paddle采集profiling的示例：

import paddle.profiler as profiler
profiler=profiler.Profiler(targets=[profiler.ProfilerTarget.CUSTOM_DEVICE], custom_device_types=['npu'], record_shapes=True)
profiler.start()
# 执行一次推理操作
profiler.stop()

然后执行命令：

alias msprof='/usr/local/Ascend/ascend-toolkit/latest/tools/profiler/bin/msprof' 
msprof --export=on --output=ascend_profiling

在ascend_profiling目录下，会生成性能统计结果

在op_statistic.csv可以看到各个算子的统计时间，可以分析msprof，详细看性能慢的进程。

1、utc首次推理慢，后面推理速度变快，很有可能就是算子编译导致的。设置ASCEND_MAX_OP_CACHE_SIZE=5000，是增大缓存空间，防止空间满了重新缓存，可以在这个基础上多测试几次uie，看看速度会不会逐渐变快。另外，可否提供一下在910B上编译PaddleCustomDevice的commit，如果不是最新的，建议使用最新的develop。

@a31413510 910B上编译的commit是develop，步骤如下：

麻烦提供一下测试utc性能的代码/脚本，我们这边复现一下。