Open HighGee opened 2 months ago
基于 https://github.com/PaddlePaddle/PaddleCustomDevice/issues/1118 提问者的场景，有一些补充。
前提： 按 develop 分支 07.15 左右最新的 commit(bcc47be2979e36b4d1a726fbdb9253a1530b7ff4) 执行编译，并通过了“基础功能检查”
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框架需要完善的点？
ascend_profiling.tar.gz
更新较完善的采样数据
HighGee
commented
2 months ago HighGee
commented
2 months ago
基于 https://github.com/PaddlePaddle/PaddleCustomDevice/issues/1118 提问者的场景，有一些补充。
前提： 按 develop 分支 07.15 左右最新的 commit(bcc47be2979e36b4d1a726fbdb9253a1530b7ff4) 执行编译，并通过了“基础功能检查”
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框架需要完善的点？