昇腾 910B 推理缓慢+预热效能不符预期

[HighGee]

基于 #1118 提问者的场景，有一些补充。

前提：
按 develop 分支 07.15 左右最新的 commit(bcc47be) 执行编译，并通过了“基础功能检查”

1.预热尝试一
手里有 5500+ 完全不同的query token
预热阶段，每个 length 的 query 只取1个，分别执行query，当作预热
剩下的5000+个query，大部分都能在较短的延时(30ms+)推理出结果，但仍有少部分仍需更长延时

2.预热尝试二，基于尝试一中length无法覆盖用例最大512长度token的生产要求
构建中文汉字1000个+英文字符+中英文标点符号+数字的字符集
每次query从中随机选取指定数量的字符拼凑成整句
整句长度从1一直到512，也就是执行512次query
这样的操作，显存会逐渐增涨，把910B单卡64GB显存撑爆。

3.预热尝试三，基于尝试二，将最大长度由512降至256（用于验证可行性）
预热完成后，显存占用16GB
然后再使用之前5000+query进行query测试（这些query都在256长度范围内）
结论是之前的预热仿佛没有任何作用

4.另外，推理时路径下有生成kernel_meta_xxx数据，但kernel_meta_xxx数据无法复用，这意味着每次都需要走较长时间的预热流程。
第一次启动docker，执行5000+query，生成kernel_meta目录，将该目录中的数据导出至宿主机
第二次启动docker，使用-v挂载路径，再次启动进程，之前已经warm up的请求仍然耗时达30s+

5.然后尝试探究问题进行性能采样，数据如下，但不太明确
PROF_000001_20240720102832085_QKLFOOPJMINELEIC.zip

基于以上，我的问题是：
1.预热操作是否有执行标准？或者更好的建议？
2.问题关键还是推理耗时过久，所以麻烦看看采样数据中是否有值得关注的点，能指出模型/paddle框架需要完善的点？

[HighGee]

ascend_profiling.tar.gz

更新较完善的采样数据