Text-Extract-API项目OCR处理性能问题深度分析

问题现象

在Text-Extract-API项目中，用户反馈OCR处理出现严重性能问题。从日志可见，系统在处理362页文档的第52页时，单页处理耗时超过124,000秒（约34小时），且进度停滞在30%。日志显示系统正在处理大量"chunk"（如3488388-3488844等编号），但处理速度异常缓慢。

技术背景

该项目基于以下技术栈：

1. OCR引擎：采用GPU加速的现代OCR技术
2. 后端架构：FastAPI + Celery任务队列
3. 模型服务：Ollama提供的LLM视觉模型服务
4. 部署方式：Docker容器化部署

根本原因分析

1. GPU利用率不足

虽然nvidia-smi显示GPU正在使用，但存在以下可能性：

• 仅单个GPU被调用，未充分利用多GPU资源
• GPU显存或计算单元未饱和使用
• 存在CPU-GPU数据传输瓶颈

2. 模型选择问题

日志中出现"mllama doesn't support parallel requests yet"警告，表明：

• 当前使用的mllama模型不支持并行请求
• 模型版本可能不是最优选择（如未使用推荐的marker策略）

3. 任务分片异常

观察到"chunk no"数值异常庞大（达到百万级），可能原因：

• 文档分片策略存在缺陷
• 图像预处理阶段产生过多微小片段
• 分片大小设置不合理导致处理效率低下

4. 系统资源竞争

日志显示频繁的HTTP请求（/ocr/result端点），表明：

• 结果查询可能影响处理性能
• 未实现有效的请求限流机制
• 可能存在资源锁竞争

解决方案建议

1. 模型策略优化

• 明确指定使用marker策略（通过CLI参数或URL参数）
• 验证模型是否支持当前硬件配置
• 考虑使用轻量级模型进行初步测试

2. 性能调优

• 实现处理过程的可观测性监控
• 优化分片大小和并行度
• 增加GPU利用率监控指标

3. 架构改进

• 实现请求队列管理
• 优化结果缓存机制
• 考虑引入工作节点自动扩展

最佳实践

对于大型文档处理，建议：

1. 先进行小规模测试（单页或少量页面）
2. 监控GPU利用率和显存使用情况
3. 选择适当的模型策略（如marker）
4. 合理设置超时和重试机制

该案例提醒我们，在部署AI文档处理系统时，需要综合考虑模型选择、硬件利用和系统架构的协调配合，才能达到最优性能。