拓冰建站拓冰建站
首页 / 资讯中心 / 正文

MinerU PDF解析2种后端选型指南

MinerU PDF解析2种后端选型指南【免费下载链接】MinerUA high-quality tool for convert PDF to Markdown and JSON.一站式开源高质量数据提取工具将PDF转换成Markdown和JSON格式。项目地址: https://gitcode.com/OpenDataLab/MinerU先说答案只有一张消费级显卡显存8GB以下MinerU 的pipeline后端模式就够应付绝大多数 PDF 转 Markdown 任务显存8GB以上、追求速度再上vlm-engine端到端路线。下面把两种后端的架构差异、硬件门槛、精度数字和我个人的默认推荐讲清楚用3个场景当主线10分钟你就能定下选型。 结论先行三种用户怎么选我个人建议一句话版默认 pipeline显存≥8GB且求速度切 vlm-engine。维度pipelinevlm-engine最低显存6GB8GBTuring架构及以上纯CPU完整支持有限支持模型形态多个小模型合计约2GB单个VLM约10亿参数多语言OCR37种语言以中英文为主文本识别精度98.2%98.7%公式识别精度92.1%95.3%布局保持度97.8%96.2%批量100页耗时无加速45.2s32.8s一句实话当前版本的默认后端其实是hybrid-engine上面两条路线的混合体你直接装完就跑到的就是它。但选型要讲清楚还是得先搞懂两条纯路线因为 hybrid 的行为本质是它们之间的加权取舍6GB显存批量转500页合同选哪个上个月帮一个朋友数字化500页老合同卡是6GB的 GTX 1060我直接给他定了调别碰 vlm-engine用 pipeline。显存不够8GB还能跑vlm-engine吗能拉起但10亿参数的视觉语言模型加上 KV cache6GB 显存很容易吃到爆长文档跑到一半就 OOM。我的建议是别试8GB1080Ti、3070及以后才是门槛线。pipeline 路线的思路是分工YOLO 布局模型先找位置OCR 读文本表格、公式各由专门模型负责后处理再拼到一起。每一步都轻、可控所以 6GB 显存甚至纯 CPU 都能跑。pipeline批量跑500页怎么调参批大小环境变量MINERU_MIN_BATCH_INFERENCE_SIZE默认384提到512吞吐有明显提升合同基本没有公式--formula false直接关表格也没有就再关--table false中文文档补一个-l chOCR 准确率更稳mineru -p contract_dir/ -o out/ -b pipeline -l ch --formula false export MINERU_FORMULA_ENABLEfalse # 等价写法朋友那500页合同在1060上一路跑完没翻车耗时可接受表格还原够用。这类批量、稳定、资源紧的任务pipeline 目前仍是唯一解。⚡ 论文10万页要跑得飞快上VLM路线换个场景一个 RAG 团队要清洗10万页 arXiv 论文。这个量级下瓶颈不再是精度是吞吐。VLM 路线是端到端整页图像直接丢进视觉语言模型模型自己吐出结构化 Markdown不做布局检测、不做 OCR 拼接链路短、出错环节少。精度上文本98.7%、表格96.8%、公式95.3%也略高于 pipeline 的98.2%、94.5%、92.1%。真正拉开差距的是速度10页纯文本文档vlm-enginetransformers 直跑8.7秒已经快过 pipeline 的12.3秒挂上 vLLM/lmdeploy 加速引擎后同一批文档缩到0.4秒100页从45.2秒到3.2秒快的场景下有30倍量级的提升。VLM怎么接上vLLM/lmdeploy加速mineru-openai-server --port 30000 # 需装 vllm 或 lmdeploy mineru -p papers/ -o out/ -b vlm-http-client -u http://127.0.0.1:30000vLLM 的参数可以原样透传比如--max-new-tokens 4096 --temperature 0.1。vlm-http-client本身是轻量客户端本地不需要装 torch推理机和客户端可以分开部署。 多语言OCR、纯CPU环境为什么pipeline更稳多语言pipeline 的 OCR 组件覆盖37种语言外文合同、发票、阿拉伯文文档都在射程内VLM 路线主要面向中英文调优纯CPUpipeline 完整支持 CPUVLM 在 CPU 上不仅慢依赖还重不建议折腾模块化公式、表格、图片分析可以单独开关只取纯文本时能省掉三成以上耗时如果你的文档语料多语言 无 GPU选型不用纠结pipeline 一个词收尾。精度数字信哪边上面的表是标准测试集的数据。我的读法是VLM 读得更准pipeline 摆得更稳——文本、表格、公式都是 VLM 略胜唯独布局保持度反过来97.8% 对 96.2%。所以下游是 RAG 切片或检索看文本和表格那两行VLM 占优客户在意视觉还原度pipeline 更保险。但不管选哪边都从真实业务文档里抽20页人工抽检纸面数字和自己文档的表现未必一致这条标准比任何评测都靠谱。上生产之前先做这几件事我上生产前的固定动作按重要性排高并发API服务vlm 路线 vLLM16GB以上显卡多实例mineru-api负载均衡多卡用mineru-router --local-gpus auto编排批量文档处理pipeline8GB 显卡就够把批大小调上去VLM预热服务端加--enable-vlm-preload true避免首个请求冷启动超时混合型负载12GB 显卡或文档类型太杂时让 hybrid-engine 来仲裁细节看 官方文档VLM 推理的实现代码在 mineru/backend/vlm/ 里翻一遍比我这篇更清楚。 现在就跑一条命令试试同一份文档分别用mineru -p 你的pdf -o out/ -b pipeline和-b vlm-engine各跑一遍肉眼对比两份 Markdown比任何对比表都直观。两条路线没有绝对的高下只有适不适合你的显卡。【免费下载链接】MinerUA high-quality tool for convert PDF to Markdown and JSON.一站式开源高质量数据提取工具将PDF转换成Markdown和JSON格式。项目地址: https://gitcode.com/OpenDataLab/MinerU创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门