【MinerU】Pipeline 与 Auto-Engine 模式

Pipeline 与 Auto-Engine 模式

一、两种模式的区别

Pipeline 模式（传统多模型流水线）

采用多个专用模型串行处理：

复制代码

PDF → 版面检测 → 公式识别 → OCR → 表格识别 → 后处理 → 输出

使用 PPDocLayout（版面）、UniMERNet（公式）、PaddleOCR（文字）、RapidTable（表格）等独立模型
精度 85+（OmniDocBench v1.6）
支持 CPU 推理，最低 4GB 显存即可
无幻觉风险（确定性处理，不涉及 AI 生成）
支持 109 种语言 OCR

Auto-Engine 模式（VLM + OCR 双引擎）

分为 hybrid-auto-engine（默认）和 vlm-auto-engine 两种，核心是引入了 视觉语言模型（VLM）：

复制代码

PDF → 文本类型判断 →
├─ 文本PDF: 原生文本提取 → VLM 理解 → 后处理
└─ 扫描PDF: VLM 分析 → OCR 兜底 → 后处理 → 输出

使用 MinerU2.5-Pro-2604-1.2B VLM 模型进行文档理解
精度 95+（OmniDocBench v1.6）
需要 8GB+ 显存，不支持 CPU
对复杂版面、跨页表格、复杂公式等场景效果显著更好

核心差异对比

维度	Pipeline	Auto-Engine
精度	85+	95+
硬件要求	CPU 或 4GB 显存	8GB+ 显存（必须 GPU）
处理方式	多模型串行流水线	VLM 理解 + OCR 双引擎
幻觉风险	无	低（原生文本提取降低风险）
适用场景	大批量、资源受限环境	高精度、复杂文档
速度	简单文档更快	较慢但更准

为什么 Pipeline 精度"只有" 85+？

Pipeline 依赖多个独立专用模型串行工作，每个模型各自优化，但各环节误差会累积（版面检测的误差传给 OCR，OCR 的误差传给后处理），且缺乏对文档全局语义的理解。而 Auto-Engine 利用 VLM 对文档进行端到端的理解，能更好地处理复杂版面、旋转表格、复杂公式等 Corner Case，因此精度更高。

简言之：追求精度和复杂文档效果选 Auto-Engine，追求速度/兼容性/低成本选 Pipeline。

二、GPU 模式 Auto-Engine 设置指南

1. 硬件前提

GPU: Volta 架构及以上（V100, RTX 20xx/30xx/40xx, A100, H100 等）
显存: 最低 8GB
内存: 最低 16GB，建议 32GB+
CUDA : 12.9.1 或更高版本驱动（用 nvidia-smi 检查）

2. 安装

bash 复制代码

pip install --upgrade pip
pip install uv
uv pip install -U "mineru[all]"

或者只安装特定推理引擎：

bash 复制代码

# Linux 推荐 vllm（速度更快）
uv pip install "mineru[core,vllm]"

# Windows 推荐 lmdeploy
uv pip install "mineru[core,lmdeploy]"

Windows 用户注意：需要先手动安装 GPU 版 PyTorch，到 https://pytorch.org/get-started/locally/ 选择对应 CUDA 版本的安装命令。

3. 下载模型

bash 复制代码

# 交互式选择下载
mineru-models-download

# 或直接下载全部模型
mineru-models-download -m all

# 只下载 VLM 模型
mineru-models-download -m vlm

国内用户可切换 ModelScope 源加速：

bash 复制代码

# Linux/macOS
export MINERU_MODEL_SOURCE=modelscope

# Windows
set MINERU_MODEL_SOURCE=modelscope

4. 运行

bash 复制代码

# 默认就是 hybrid-auto-engine，直接运行即可
mineru -p <输入PDF路径> -o <输出目录>

# 显式指定后端
mineru -p <输入PDF路径> -o <输出目录> -b hybrid-auto-engine

# 或使用纯 VLM 模式（仅中英文）
mineru -p <输入PDF路径> -o <输出目录> -b vlm-auto-engine

5. 显存不足时的调优

如果显存不够 8GB，可以调小 batch ratio：

bash 复制代码

# 6GB 显存
# Linux/macOS
export MINERU_HYBRID_BATCH_RATIO=8
# Windows
set MINERU_HYBRID_BATCH_RATIO=8

# 4GB 显存
set MINERU_HYBRID_BATCH_RATIO=4

6. 指定 GPU 设备

bash 复制代码

# 使用第 0 块 GPU
# Linux/macOS
CUDA_VISIBLE_DEVICES=0 mineru -p <输入> -o <输出>

# Windows
set CUDA_VISIBLE_DEVICES=0
mineru -p <输入> -o <输出>

7. 推理引擎自动选择

系统会根据平台自动选择最优推理引擎，无需手动配置：

平台	优先引擎	备选
Linux	vllm	lmdeploy → transformers
Windows	lmdeploy	transformers
macOS	mlx	transformers

8. 可用的后端总结

后端	说明
`hybrid-auto-engine`	默认，VLM+OCR 混合，精度最高，多语言
`vlm-auto-engine`	纯 VLM，仅中英文
`pipeline`	传统流水线，CPU 可用，精度 85+

总结

安装后默认就是 hybrid-auto-engine 模式 ，只要你有 8GB+ 显存的 GPU 并正确安装了 CUDA 和 GPU 版 PyTorch，直接运行 mineru -p xxx -o xxx 即可。

三、详细技术原理对比

3.1 Pipeline 模式使用的模型清单

Pipeline 模式加载 6 类专用模型，每个模型各司其职：

模型类型	模型名称	路径	作用
版面检测	PPDocLayoutV2	`models/Layout/PP-DocLayoutV2`	检测文档中的文本、标题、表格、图片、公式等区域
公式识别	UniMERNet (默认)	`models/MFR/unimernet_hf_small_2503`	将数学公式转为 LaTeX
公式识别	PP-FormulaNet Plus M (可选)	`models/MFR/pp_formulanet_plus_m`	中文公式优化，需设置 `MINERU_FORMULA_CH_SUPPORT=1`
OCR 文字识别	PytorchPaddleOCR	`models/OCR/paddleocr_torch`	109 种语言的文字检测与识别
表格结构识别	SlanetPlus (无线表)	`models/TabRec/SlanetPlus/slanet-plus.onnx`	无边框表格的结构识别，输出 HTML
表格结构识别	Unet (有线表)	`models/TabRec/UnetStructure/unet.onnx`	有边框表格的结构识别，输出 HTML
表格分类	PaddleTableCls	`models/TabCls/paddle_table_cls/PP-LCNet_x1_0_table_cls.onnx`	判断表格是有线表还是无线表
方向分类	PaddleOrientationCls	`models/OriCls/paddle_orientation_classification/PP-LCNet_x1_0_doc_ori.onnx`	检测并纠正表格旋转

3.2 Auto-Engine 模式使用的模型清单

Auto-Engine 以 VLM 为核心，辅以传统模型：

模型类型	模型名称	作用	使用场景
VLM	MinerU2.5-Pro-2604-1.2B	端到端文档理解，提取文本、表格、公式、图片	核心模型，处理所有页面
版面检测	PPDocLayoutV2	仅用于行内公式检测框	hybrid 模式启用行内公式时
公式识别	UniMERNet	行内公式识别	hybrid 模式启用行内公式时
OCR	PytorchPaddleOCR	文本 PDF 原生文本提取的补充	hybrid 模式部分场景

3.3 MinerU2.5-Pro-2604-1.2B 是什么？

这是 MinerU 自研的文档理解视觉语言模型（VLM），基于 Qwen2VL 架构：

参数量：1.2B（小模型，大能力）
架构：解耦的视觉-语言架构，高效高分辨率文档解析
性能：超越 Gemini 2.5 Pro、GPT-4o、Qwen2.5-VL-72B
推理方式：两步提取（初始分析 + 详细提取）
最低显存：8GB

3.4 Pipeline 处理流程详解

复制代码

PDF 输入
    ↓
PDF 分类（文本型 vs 扫描型）
    ↓
按窗口分批处理（默认 64 页一批）
    ↓
对每批执行以下步骤：

    ① 版面检测 (PPDocLayoutV2)
       输入：页面 PIL 图片
       输出：各元素边界框 + 类别标签
       类别：text, title, table, image, equation,
             abstract, doc_title, paragraph_title,
             vertical_text, seal, header, footer 等

    ② 公式识别 (UniMERNet)
       输入：检测到的公式区域图片
       输出：LaTeX 字符串
       支持：行间公式 + 行内公式

    ③ 表格识别（多步骤）
       ③a 方向分类 → 检测并纠正表格旋转
       ③b 表格分类 → 判断有线表/无线表
       ③c 表格 OCR → 提取单元格文字
       ③d 结构识别 → 输出 HTML 表格

    ④ 文字 OCR (PaddleOCR)
       ④a 检测 → 按语言和分辨率分组批处理
       ④b 识别 → 按语言分组识别文字内容
       ④c 过滤 → 置信度过滤低质量结果
       ④d 行内公式屏蔽 → 避免 OCR 误识别公式区域

    ⑤ 印章识别
       专用 OCR 模型处理印章区域

    ↓
流式写入中间结果 (middle_json)
    ↓
后处理：阅读顺序、页眉页脚去除、结果合并
    ↓
输出结构化 Markdown / JSON

Pipeline 的核心特点：每个模型独立工作，前一步的输出是后一步的输入。版面检测不准确会直接导致 OCR 和公式识别的区域错误，误差会逐级放大。

3.5 Hybrid-Auto-Engine 处理流程详解

复制代码

PDF 输入
    ↓
PDF 分类（文本型 vs 扫描型）
    ↓
判断是否启用 VLM-OCR
    条件：中文/英文 + 启用行内公式 + 扫描型 PDF
    ↓
按窗口分批处理（默认 64 页一批）
    ↓
对每批执行以下步骤：

    ┌─────────────────────────────────────────┐
    │  VLM 两步提取 (MinerU2.5-Pro-2604-1.2B)  │
    │                                         │
    │  第一步：初始分析                         │
    │    输入：页面图片                         │
    │    输出：检测所有元素 + 边界框 + 类型       │
    │    VLM 理解文档全局结构                    │
    │                                         │
    │  第二步：详细提取                         │
    │    根据文档类型走不同路径：                 │
    │                                         │
    │    路径 A（VLM-OCR 启用，中英文扫描PDF）：  │
    │      VLM 直接执行 OCR 提取全部内容         │
    │      → 文本、表格结构、公式 LaTeX          │
    │                                         │
    │    路径 B（VLM-OCR 未启用）：              │
    │      VLM 提取结构（图片、表格、行间公式）    │
    │      → 屏蔽 VLM 已识别区域                 │
    │      → 版面模型检测行内公式框               │
    │      → OCR 模型处理剩余文本区域            │
    │      → 公式模型识别行内公式                 │
    └─────────────────────────────────────────┘
    ↓
结果合并：VLM 结果 + OCR/公式结果融合
    ↓
流式写入中间结果 (middle_json)
    ↓
后处理：归一化边界框、置信度过滤
    ↓
输出结构化 Markdown / JSON

Hybrid 的核心特点：VLM 作为"大脑"统领全局，传统模型作为"工具"辅助。VLM 先理解整页内容，再决定哪些区域需要调用传统模型补充。

3.6 VLM-Auto-Engine 处理流程详解

复制代码

PDF 输入
    ↓
按窗口分批处理
    ↓
对每批执行：

    VLM 两步提取（纯 VLM，无传统模型辅助）
    - 不调用 OCR、版面检测等模型
    - VLM 独立完成所有提取任务

    ↓
输出结构化 Markdown / JSON

VLM 模式最简单，完全依赖视觉语言模型，不使用任何传统专用模型。但仅对中文和英文效果好。

3.7 三种模式在各个处理阶段的对比

处理阶段	Pipeline	Hybrid-Auto-Engine	VLM-Auto-Engine
版面检测	PPDocLayoutV2 模型	VLM + PPDocLayoutV2（仅行内公式）	仅 VLM
公式识别	UniMERNet 模型	VLM + UniMERNet（行内公式）	仅 VLM
文字识别	PaddleOCR（109 种语言）	VLM 直接提取 + PaddleOCR 兜底	仅 VLM（仅中英文）
表格识别	SlanetPlus + Unet 模型	VLM 识别 + OCR 补充	仅 VLM
文本 PDF	OCR 提取文字	原生文本提取（直接读 PDF 内嵌文字）	VLM 提取
扫描 PDF	全量 OCR 流水线	VLM 分析 + OCR 兜底	VLM 提取
误差传播	有（级联放大）	极小（VLM 统领全局）	极小

3.8 Hybrid 模式的文本 PDF 处理优势

Hybrid 模式对文本型 PDF 有独特优势------原生文本提取：

复制代码

文本型 PDF
    ↓
    不走 OCR，直接读取 PDF 内嵌的文字内容
    ↓
    VLM 理解文档结构（标题、段落、表格等）
    ↓
    合并原生文字 + VLM 结构理解
    ↓
    输出

这意味着：

零 OCR 误差：文字直接从 PDF 提取，不存在识别错误
零幻觉风险：不需要 AI 生成文字，只是理解结构
速度快：跳过了 OCR 检测和识别两个耗时步骤
文字保真度高：保留原始文字内容和格式

3.9 显存与批处理策略

Hybrid 模式会根据 GPU 显存自动调整批处理大小：

显存	batch_ratio	说明
>= 32GB	16	最大批处理
>= 16GB	8	高性能
>= 12GB	4	中等
>= 8GB	2	最低要求
< 8GB	1	可能 OOM

也可通过环境变量手动覆盖：

bash 复制代码

export MINERU_HYBRID_BATCH_RATIO=4  # 手动设置

四、不同文档场景的精度对比

4.1 各类文档处理效果

文档类型	Pipeline	Hybrid	VLM	说明
简单文本文档	优秀	优秀	优秀	单栏、格式规整的论文/报告
多栏排版	良好	优秀	优秀	报纸、杂志、双栏论文
复杂嵌套布局	一般	优秀	优秀	混排图文、嵌套表格
数学公式	良好	优秀	优秀	大量行内/行间公式
跨页表格	支持	优秀	优秀	表格跨多页自动合并
旋转/倾斜内容	一般	优秀	优秀	扫描件歪斜、旋转表格
多语言文档	优秀（109种）	良好	有限（中英）	Pipeline 语言支持最广
手写内容	一般	良好	良好	手写笔记、批注
印章	支持	支持	有限	印章文字识别
图片内文字	一般	良好	良好	图表中的标注文字

4.2 精度差异的根本原因

Pipeline 精度上限受限于三个因素：

误差累积：版面检测不准 → OCR 区域错误 → 文字错误 → 表格结构错误
缺乏全局语义：每个模型只看局部特征，不理解"这是一篇论文"或"这是财务报表"
规则化后处理：阅读顺序、段落合并等依赖规则，遇到非标排版容易出错

Auto-Engine 精度更高的三个原因：

端到端理解：VLM 同时看到整页内容，理解文档全局结构和语义
原生文本提取：文本 PDF 直接提取内嵌文字，消除 OCR 误差
智能后处理：VLM 理解上下文后做出的结构判断比规则更准确

五、选型建议

什么时候选 Pipeline？

服务器只有 CPU，没有 GPU
GPU 显存不足 8GB
需要处理大量简单文档，追求吞吐量
文档涉及中文以外的多语言（日/韩/阿拉伯/俄语等）
对确定性输出有严格要求（不能有任何幻觉）
资源受限的嵌入式/边缘环境

什么时候选 Hybrid-Auto-Engine（默认推荐）？

有 8GB+ 显存的 GPU
对解析精度有较高要求
文档包含复杂版面、跨页表格、复杂公式
中英文文档为主
生产环境，追求最佳效果

什么时候选 VLM-Auto-Engine？

纯中英文文档
需要最高精度
不需要多语言支持
研究/评估用途