使用vLLM后端，在omnidocbench 1.5的评测集上测试推理速度时效果不及预期

[ShayDuane]

数据集：omnidocbench 1.5 1355张图片

后端：使用vLLM部署到当前机器的GPU上

调用方式：https://github.com/opendatalab/MinerU/blob/master/demo/demo.py
输入的是一个图片list

测速方式：统计所有图片解析完成并且默认保存的总时间

t0 = time.time()
try:
     path_list = [Path(p) for p in batch_files]
     parse_doc_fn(
                    path_list,
                    str(output_base_dir),
                    backend="vlm-http-client",
                    server_url=mineru_url,
                )
      elapsed = time.time() - t0
      batch_times.append(elapsed)
      successful_pages += batch_pages
      pbar.set_postfix(ok=successful_pages, fail=failed_pages, last=f"{elapsed:.1f}s")
except Exception as e:
      failed_pages += batch_pages
      pbar.set_postfix(ok=successful_pages, fail=failed_pages)
      logger.error(f"  ✗ Batch {batch_idx + 1} 失败: {e}")
      logger.exception("")

最后结果显示平均解析一张图片要5.5秒左右，这个效果应该是远不及预期的，可以帮忙排查下原因吗

[dosubot[bot]]

Hi @ShayDuane! I'm Dosu and I’m helping the MinerU team.

你遇到的推理速度慢（5.5秒/张）主要有以下常见原因和优化建议：

1. flash-attn未正确安装/启用：在A100/H100等高端GPU上，flash-attn必须正确安装并被vLLM调用，否则会回退到xformers，推理速度会极慢（8-15秒/页甚至更慢）。请检查vLLM日志，确认没有xformers相关的fallback警告，并确保容器/环境内已pip install flash-attn，重启服务后再测速度。参考

2. vLLM服务端参数未调优：建议启动vLLM服务时设置--gpu-memory-utilization 0.7~0.85，--max-concurrency 10~100（根据显存和负载调整），batch size可适当调大（如8或16，视显存而定），这样能提升吞吐和利用率。参考

3. CPU预处理瓶颈：图片转PDF、PDF转图片等预处理是纯CPU密集型，默认只开4进程。你可以在load_images_from_pdf相关代码处把threads参数设为你的CPU核心数（如32），充分利用多核加速预处理。参考

4. 不必要的功能未关闭：如不需要表格/公式识别，建议设置环境变量MINERU_TABLE_ENABLE=false、MINERU_FORMULA_ENABLE=false，能显著降低CPU负载。参考

5. OCR批量参数过小：可设置MINERU_MIN_BATCH_INFERENCE_SIZE=384（或更大，视显存），提升单批处理吞吐，减少CPU等待GPU的时间。参考

6. 并发设置过高或过低：vLLM后端建议max_concurrency设置在10以内，过高会导致资源争用，过低则利用率不高。参考

7. Docker资源限制：如用容器部署，需确保--shm-size足够大（如32g）、--ipc=host，否则共享内存瓶颈会拖慢推理速度。参考

8. 环境依赖/驱动不兼容：请确保CUDA、驱动、PyTorch、vLLM、flash-attn等版本完全兼容，推荐V100用CUDA 11.8/12.8，PyTorch 2.7/2.8/2.9，vLLM 0.11.x。参考

9. 复杂图片/文本多：推理速度与图片复杂度、文本量成正比，复杂页面本身就会慢。参考

10. MinerU自身批量处理机制：当前vlm-http-client模式下，MinerU是逐图片串行推送到vLLM服务端，吞吐受限于单张图片的处理速度。可以考虑用多进程/多worker并发调用，或切换到pipeline后端（复杂文档、表格多时更快更稳）。参考

排查建议：

• 先用一小批图片，打开详细日志，观察每步耗时，确认瓶颈是在预处理、推理还是后处理。
• 检查vLLM服务端日志，确认flash-attn已启用、无xformers fallback。
• 用nvidia-smi/htop监控GPU/CPU利用率，判断是否有资源未吃满。
• 优化上述参数后再测试，通常A100/H100可做到2-5秒/页，V100略慢，复杂图片会更慢。

如还有问题，可补充你的GPU型号、vLLM/flash-attn/MinerU版本、日志片段等，便于进一步定位。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[myhloli]

您需要通过多个client并发请求server以获得更高的吞吐量。

[ShayDuane]

也就是按照demo.py的调用方式，sdk内部并没有实现异步并发么
那调用的时候传入的图片或者文件列表也是一张一张调用处理的？

[myhloli]

单个client处理单个文档内是并行处理的，处理多个文档是顺序执行的，因为你输入的都是1page的单页文档，所以单client速度必然会慢

[ShayDuane]

我明白了 多谢