性能优化问题定界
在通过分析 profiling 文件找出性能瓶颈后，接下来将介绍相关的优化方法。算子时长主要由计算时间和调度时间两部分构成，下面将分别对计算时间长和调度时间长这两种情况进行探讨。
计算时间长的情况分析与优化
计算时间长可能由以下三种情况导致：
算子运行于 AI_CPU
- 若底层未对 AI_CORE 提供支持，就必须开发新的算子；
- 若已有相关支持，计算时间长大概率是由 64 位数据类型所致。此时，可通过在适配层添加 cast 操作来转换数据类型，使算子能在 AI_CORE 上运行。
算子使用 aclop
大部分 aclop 算子的计算速度慢于 aclnn。在此情况下，可使用 aclnn_scale 和 aclnn_split 环境变量切换至 aclnn 算子。在大模型场景设置False性能更好，小模型场景设置True性能更好。
# 大模型场景
export FLAGS_npu_scale_aclnn=False
export FLAGS_npu_split_aclnn=False
# 小模型场景
export FLAGS_npu_scale_aclnn=True
export FLAGS_npu_split_aclnn=True
以 Power 算子为例，在未开启 aclnn_scale 和 aclnn_split 环境变量时，该算子运行于 aclop 上，整体 Task Wait Time (us) 较长；开启环境变量后，算子运行于 aclnn 上，整体等待时间明显减少。
使用 aclnn 算子
若已使用 aclnn 算子，可考虑提升底层算子的性能以优化计算时间。
调度时间长的情况分析与优化
调度时间长的问题相对更容易在适配层解决，可能由以下三种情况导致：
算子运行于 CPU
- 若算子未进行适配，需先完成适配工作；
- 当 Paddle API 所需能力超出 NPU 算子的能力范围，部分功能只能由 CPU 实现时，就需要开发新的 NPU 算子来提供支持。
算子重复编译
这是调度时间长最常见的情况，一般可通过切换至 aclnn 算子来解决。通讯时间长
需检查在算子适配过程中是否添加了过多不必要的 copy 操作。
适配层性能优化手段
以下将简要阐述在适配层可实施的性能优化策略。
算子 CPU 计算耗时优化
未注册算子
对于未注册而运行在 CPU 上的算子（部分算子因 NPU 不支持或未适配，会回退到 CPU 进行运算），可借助 glog 进行排查，方法如下：
# 设置日志级别
export GLOG_v=3
# 查找回退算子：完成推理后保存日志，在日志中搜索关键字 “fallbacking to CPU”，即可找到运行在 CPU 的算子。
已注册算子
在适配层中，存在极少数原生注册为在 CPU 上运行的算子。这种情况通常是由于在适配这些算子时，NPU 不支持算子的部分模式，或者随机算子存在精度问题，致使部分模式只能转换为 CPU 计算。
可依据该算子前后的算子名称以及网络模型结构，定位出这些纯 CPU 运行的算子。
解决此类问题的常规方法，是在适配层将其替换为 NPU 算子。但如果涉及到重要模型缺失算子的部分运行模式，那么就需要算子开发团队先开发出对应的算子，再进行适配。
算子重复编译耗时优化
aclnn 算子不存在重复编译问题，但部分算子仅有 aclop 实现；部分 NPU 算子在启动时进行图编译属于正常现象，但存在个别算子因属性变化而持续重复编译的情况。
切换算子类型
优先将重复编译的 aclop 算子切换为 aclnn 算子。
环境变量优化
若对应的 aclnn 算子存在问题，只能采用 aclop ，可通过以下环境变量进行优化（来不及进行算子开发，开启以下两个环境变量可做为临时缓解措施）：
# 关闭在线编译，使用二进制算子复用
export FLAGS_npu_jit_compile=0
# 增加缓存区容量，提高缓存命中率，此处 5000 的单位为 MB
export ASCEND_MAX_OP_CACHE_SIZE=5000
算子适配优化与替换
适配本质上是一种映射，适配层 API 对于底层算子的选择并非固定不变，很多 API 可通过多种算子组合来实现；若某些算子性能欠佳，可考虑替换为等价算子或更改数据类型；大模型相关的算子适配中，引入融合算子可显著提升性能。
更换底层算子
针对存在性能瓶颈的部分算子，可尝试在适配层更换为其它等价的底层算子。
调整数据类型
对于运行速度较慢的数据类型（如 64 位数据类型会运行在 AI_CPU 上），若实际运算无高精度需求，可通过 CAST 操作转换成 32 位数据类型以提高运行速度。
采用融合算子
部分算子可合并为融合算子，从而大幅提升性能。
