昇腾NPU上运行text_detector速度慢

[wenxinmomo]

🔎 Search before asking

• I have searched the PaddleOCR Docs and found no similar bug report.
• I have searched the PaddleOCR Issues and found no similar bug report.
• I have searched the PaddleOCR Discussions and found no similar bug report.

🐛 Bug (问题描述)

在ARM架构，910B的环境下。
执行PaddleOCR.text_detector()，速度比CPU还慢。
CPU一张图片大概0.5s
NPU一张图片，2s-1s左右

已经使用环境变量： export FLAGS_npu_jit_compile=0

请问这种情况下，text_detector如何进行加速。

注：text_recognizer很快。

🏃‍♂️ Environment (运行环境)

CPU：ARM
NPU：910B
CANN：8.0.RC2

🌰 Minimal Reproducible Example (最小可复现问题的Demo)

使用PaddleOCR中的text_detector函数

[GreatV]

根据提供的问题描述和参考的相关文档，以下是关于在昇腾NPU上运行text_detector速度慢的问题的分析和解决建议：

---

问题分析

1. NPU性能未完全发挥：

   • 您提到在昇腾 910B 上运行 text_detector 的推理速度比 CPU 还慢（NPU: 1-2秒，CPU: 0.5秒）。这通常意味着模型在 NPU 上没有得到针对性的优化，可能是由于模型与硬件的适配问题。
   • 环境变量 FLAGS_npu_jit_compile=0 表明启用了直接执行模式（关闭了 JIT 编译），这可能对性能有一定影响。

2. PaddleOCR 的模型和算子支持问题：

   • 部分算子可能在昇腾 NPU 上未得到充分优化，或者模型的计算图未针对 NPU 进行裁剪和调整。
   • 昇腾 NPU 对 PaddlePaddle 的支持可能存在一定的局限性，尤其是在特定版本的 CANN（8.0.RC2）环境下。

3. 推理引擎配置问题：

   • 如果未正确启用 NPU 推理优化选项（如 FP16、混合精度等），可能会导致性能下降。
   • PaddleOCR 的 text_detector 和 text_recognizer 模型架构不同，text_detector 通常计算量更大，因此速度差异显著。

4. 模型 batch size 和数据预处理：

   • 如果推理时未充分利用批处理（batch size），可能导致硬件资源未被充分利用。
   • 数据预处理（如 resize 和 normalize）可能在 CPU 上执行，从而拖慢整体推理速度。

---

解决方案

1. 优化推理配置

• 确保启用了 NPU 的混合精度模式（FP16），这可以显著提升 NPU 推理速度：

  export FLAGS_npu_storage_format=1
  export FLAGS_npu_precision_mode=allow_fp32_to_fp16

• 尝试调整环境变量以启用 JIT 编译：

  export FLAGS_npu_jit_compile=1

  JIT 编译可能会在初次运行时略慢，但能够在后续推理中提高性能。

2. 检查 CANN 和 PaddlePaddle 版本兼容性

• 当前使用的 CANN 版本是 8.0.RC2。建议检查 PaddlePaddle 和 CANN 官方文档，确保使用的 PaddlePaddle 版本与 CANN 版本完全兼容。
• 如果可能，尝试升级 CANN 至最新稳定版本（如 8.0.3），以获得更多算子和性能优化支持。

3. 调整模型和算子优化

• 使用 PaddleOCR 提供的 NPU 专用模型（如果有）以获得更好的适配性能。
• 检查是否启用了 PaddleSlim 或其他模型量化工具，对 text_detector 进行量化（INT8/FP16 模式），这可以显著减少推理时间。

4. 启用批处理和优化预处理

• 如果一次只推理一张图片，NPU 的利用率会非常低。建议启用批处理（batch size > 1），以提升硬件资源的利用率：

  text_detector(batch_size=8)

• 检查数据预处理是否使用了 GPU/NPU，而不是默认的 CPU。如果预处理耗时较长，可以尝试将预处理操作转移到 NPU。

5. 测试其他检测模型

• 如果 text_detector 是基于 DB 算法，您可以尝试其他检测算法（如 EAST 或 SAST），这些算法可能对 NPU 更友好。

6. 参考相关讨论

• Issue: 用FastDeploy部署比用Flask框架封装PaddleOcr推理要慢: 此 Issue 讨论了不同部署方式（FastDeploy vs Flask）在 GPU 推理中的性能差异，部分优化思路对 NPU 也可能适用。
• Issue: c++推理速度比python慢好几倍，请教下怎么解决: 此 Issue 提到了推理速度的差异，深入分析了底层 API 的调用效率，可能为您提供启发。

---

总结

根据上述分析，以下是优化步骤的优先级建议：

1. 升级 CANN 和 PaddlePaddle，确保版本兼容。
2. 启用 FP16 模式和 JIT 编译，尝试优化推理配置。
3. 调整 batch size 和数据预处理，充分利用硬件资源。
4. 量化模型并测试其他检测算法，选择最适合 NPU 的模型架构。

---

Response generated by 🤖 feifei-bot | chatgpt-4o-latest