PaddleOCR在晟腾910B环境下的多模型并行推理问题分析
项目地址: https://gitcode.com/paddlepaddle/PaddleOCR 问题背景
在使用PaddleOCR进行文档分析时，开发者发现了一个在晟腾910B（Ascend NPU）环境下特有的问题：当同时使用LayoutDetection（版面分析）和PaddleOCR（文字识别）两个模型时，版面分析的结果会出现严重混乱，而单独使用任一模型则表现正常。
现象描述
开发者提供了一个典型的文档图片作为测试用例，期望能够正确识别文档中的出发地、到达地和路线里程等关键信息区域。测试分为两种情况：
- 单独使用LayoutDetection模型：版面分析结果准确，能够正确识别文档中的各个功能区域。
- 同时使用LayoutDetection和PaddleOCR模型：版面分析结果出现严重偏差，识别出的区域与文档实际内容不符。
环境配置
问题出现在以下硬件和软件环境中：
- 处理器：华为鲲鹏920（aarch64架构）
- 加速卡：晟腾910B2（单卡）
- 软件栈：PaddlePaddle NPU专用版本、CANN 800等昇腾相关组件
问题分析
经过技术团队深入调查，发现问题的根源在于晟腾NPU环境下多个模型并行初始化时的权重管理机制。具体表现为：
- 权重干扰现象：在同一张NPU卡上初始化多个模型时，后续模型的权重会干扰前面已加载模型的权重。
- 环境特异性：该问题仅在NPU环境下出现，在GPU或CPU环境下测试均表现正常。
- 模型交互影响：LayoutDetection和PaddleOCR模型虽然功能独立，但在NPU环境下存在底层资源冲突。
临时解决方案
针对这一问题，技术团队提出了几种临时解决方案：
-
设备隔离方案：将不同模型分配到不同的计算设备上执行
- 将PaddleOCR设置为CPU模式运行
- 如果有多个NPU卡，可将模型分配到不同卡上
-
进程隔离方案：将不同模型放在独立的Python进程中运行，通过进程间通信进行协调
-
服务化架构：将不同模型封装为独立服务，通过API调用方式实现功能整合
技术展望
该问题的根本解决需要昇腾CANN软件栈的底层支持，技术团队已将此问题反馈给昇腾研发团队。未来可能的解决方案包括：
- 权重隔离机制：在NPU驱动层面实现模型权重的完全隔离
- 资源管理优化：改进NPU的资源分配和管理策略
- 框架层适配：在PaddlePaddle框架层增加对NPU多模型并行的特殊处理
最佳实践建议
对于需要在NPU环境下使用PaddleOCR进行复杂文档分析的开发者，建议：
- 优先考虑使用进程隔离或服务化架构
- 密切关注PaddlePaddle和昇腾CANN的版本更新
- 在模型部署前进行充分的集成测试
- 考虑使用混合计算模式（部分模型用NPU，部分用CPU）
该问题的出现提醒我们，在异构计算环境中进行模型部署时，需要特别注意不同硬件平台的特有行为，做好充分的兼容性测试和备选方案设计。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
