> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Docling vs Marker vs MinerU
- URL: https://www.hubwiz.com/blog/docling-vs-marker-vs-mineru/
- Published: 2026-08-28T16:10:38.000Z
- Updated: 2026-10-13T15:51:32.000Z
- Description: 2026年真正的开源PDF转Markdown基准测试——哪个适合你的RAG流水线
- Author: admin
- Tags: TOOL, PDF, #Import 2026-10-14 14:41

每个RAG系统都有一个肮脏的秘密，它不是向量数据库。它是第一阶段：将一堆杂乱的PDF转换成语言模型可以实际推理的干净结构化文本。如果这个阶段出错，下游的一切——分块、嵌入、检索、生成——都会继承这种损害。一个被扁平化成文字沙拉的表格，一个被横向读取的双栏论文，一个被渲染成乱码的公式：这些都不会被更好的嵌入模型修复。垃圾进，垃圾出。

多年来，对于“如何解析这些文档”的诚实回答是严峻的：将Tesseract、布局启发式、表格库和周末的正则表达式拼凑在一起。2026年情况发生了变化。三个开源项目现在可以完成整个工作——输入PDF，输出结构化的Markdown或JSON——并且它们已经足够好，有趣的问题不再是*是否*使用它们，而是*哪一个*，以及*为什么*。

这三个分别是IBM Research的**Docling**、Datalab的**Marker**和OpenDataLab（上海人工智能实验室）的**MinerU**。三者都是开源的。三者都将文档转换为Markdown和JSON。三者的GitHub星标数都是五位数。然而，它们建立在完全不同的理念上，采用完全不同的许可条款，并针对完全不同的约束进行了优化。

我构建保险和企业处理的文档流水线，其中解析错误的表格不是外观错误——而是错误定价的保单。所以我不会因为某个解析器在Hacker News上流行而选择它。我关注架构、真实的基准数字、硬件成本，以及——直到法律部门打电话来大家都忘记的部分——许可证。

本文就是那个比较。以下是地图：

- **三大竞争者** ——每个背后的理念。
- **架构** ——每个工具内部的流水线和实际模型。
- **基准现实** ——数字说了什么，以及围绕它们的诚实警告。
- **许可证** ——对大多数公司而言，它凌驾于精度之上的隐藏决定因素。
- **速度和硬件** ——CPU vs GPU，以及其成本。
- **决策树和判决** ——谁应该使用哪个。

> **工程说明。**

## 1、三大竞争者

在任何数字之前，了解每个项目*试图成为什么*。这种意图解释了下游的每一个权衡。

### 1.1 Docling ——通用、宽松的摄取层

Docling来自IBM Research Zurich，并于2026年初捐赠给Linux基金会。它的押注是**文档AI的难点不仅仅是OCR精度——而是覆盖范围、结构和使用自由度。** 因此Docling摄取几乎所有内容（PDF、DOCX、PPTX、XLSX、HTML、EPUB、图像，甚至电子邮件和音频），在CPU上愉快运行，采用完全宽松的**MIT许可证**，并且——关键——输出一种名为DoclingDocument的丰富、无损的结构化表示，从设计之初就为RAG摄取而不仅仅是为了人类阅读。

Docling对平台团队的宣传：*一个库，所有格式，不需要GPU，不需要许可证律师。*

### 1.2 Marker ——快速、功能齐全的转换器

Marker来自Datalab和Vik Paruchuri，建立在Datalab自己的**Surya**模型套件之上。它的押注是**大规模的速度和Markdown质量。** 当你有十万个PDF和一个H100，并且你想要尽可能快地从另一端获得干净的Markdown时，Marker就是你使用的工具——并带有可选的LLM流程来清理困难的5%（跨页表格、内联数学、表单字段）。

Marker的宣传：*最快的足够好的PDF到Markdown流水线，当你需要更多时，有一个通向LLM的逃生舱口。*

### 1.3 MinerU ——精度专家

MinerU来自上海人工智能实验室的OpenDataLab，是三者中GitHub吸引力最大的。它的押注是**精度，尤其是在困难的东西上——表格、公式和中文/CJK文档。** MinerU提供两个后端：一个在CPU上运行的经典流水线，以及**MinerU2.5**，一个紧凑的12亿参数视觉语言模型，在OmniDocBench排行榜上获得最高分数，同时其尺寸只是它所击败的模型的一小部分。

MinerU的宣传：*来自微小模型的最先进解析精度——如果你能给它一个GPU。*

> **工程说明。** *文档转换系统*

## 2、架构：内部实际是什么

这是三者分歧最大的地方。让我们逐一打开。

### 2.1 Docling

Docling运行一个经典的、可检查的多阶段流水线，旁边还有一个可选的单模型VLM路径。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-hrWWH8xbNgoATnZTb7DLzQ.png)

关于Docling要记住的两点：首先，**OCR是可选和可插拔的**——对于原生数字PDF，它根本不会运行OCR，它读取文本层，这既更快又更准确。其次，输出是一个`DoclingDocument`**，一个无损保留文档层次结构的结构化对象，这就是为什么Docling如此干净地融入RAG框架。表格结构由IBM自己的**TableFormer\*\*处理，它在金融表格上确实很强。

Docling还提供了一个VLM路径——**Granite-Docling-258M**（Apache-2.0，2026年1月发布，实验性SmolDocling预览的后续版本）——当你想要一个单独的小型模型输出结构化的“DocTags”标记而不是运行完整流水线时。

### 2.2 Marker

Marker最好理解为**Surya模型套件上的编排器。** Surya提供各个模型；Marker将它们连接到文档流水线中，并添加一个可选的LLM优化阶段。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-AbNz_cIoZJnN7Kl2cd6gYg.png)

关键的架构事实：**Marker的质量就是Surya的质量。** Surya OCR 2（2026）将大量识别整合到一个约6.5亿参数的视觉语言模型中，通过提示输出布局JSON或整页HTML。而——use\_llm标志是Marker的秘密武器：对于真正困难的案例——一个跨越三页的表格、一个密集的方程式、一个带复选框的表单——它可以调用外部LLM来清理结果，以延迟和API成本换取精度。

### 2.3 MinerU

MinerU提供**两个可选的后端**和一个结合它们的混合模式——这种灵活性就是重点。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-P476DnLwYwkGawBgRJ8zjA.png)

MinerU2.5是有趣的一个。它是一个**解耦的、从粗到细的VLM**：阶段1在廉价的降采样缩略图上进行布局分析，阶段2在仅重要区域的原始分辨率裁剪上进行内容识别。这个两阶段技巧是1.2B模型如何击败比它大很多倍的系统——它从不浪费计算在全分辨率上读取整个页面。与此同时，流水线后端为你提供了一个纯CPU选项，当你没有GPU并且可以接受较低精度时。

> **工程说明。Docling和MinerU流水线是可检查的多阶段系统，你可以在CPU上运行；MinerU2.5和Marker的Surya路径依赖VLM，需要GPU才能获得全速和精度。**

## 3、基准现实

这是对这三者进行基准测试的诚实状态，你需要在看到任何数字之前听到：**没有一个公开排行榜能清晰地对这三者进行排名。** MinerU在每个榜单上。Marker出现在一些榜单上。**Docling基本上不在标准化的公开排行榜上**——其发布的故事是自己论文中的时序基准加上第三方博客测试。任何向你展示整洁的“Docling 87 vs Marker 84 vs MinerU 91”表格的人，都是将不同套件、不同版本和不同语料库的数字拼凑在一起。所以我不会这样做。

我*能*给你的是每个工具在其实际出现的榜单上的真实、引用的地位——并大声强调警告。

**OmniDocBench（文档解析复合指标：文本编辑距离、表格TEDS、公式、阅读顺序）。**

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-PD9FzoxgtUDBJxO-W6t_zw.png)

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-evmpD0Jqs3bO5k1hEljihA.png)

MinerU2.5按类别（v1.5，来自其论文）：文本编辑**0.047**，公式CDM**88.46**，表格TEDS**88.22**，TEDS-S**92.38**，阅读顺序编辑**0.044**——在每个轴上领先其同类。

> **工程说明——在引用95.69之前请阅读此部分。v1.5和v1.6是不同的套件不能直接比较。** *以及* **自报的**

**olmOCR-Bench（AllenAI——超过7,000个检查的通过/失败单元测试）。**

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-ruYIkXsSXoNqdhzXIRDgUA.png)

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-OZaEu_GIZ8LJKFTSaCu4Rg.png)

Marker自己的弱点也在这里显现：在**旧的、退化的扫描件**上，它得分仅为**51.9**——历史/损坏的文档是Marker最挣扎的地方，即使它在干净的多栏和长小文本页面上表现出色。

> **工程说明。不同版本在不同基准修订版上**

**速度（来自Docling自己的论文，NVIDIA L4 GPU，旧版工具版本——方向性）。**

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-hRSOQwCLUTm_Pq9MdcspSQ.png)

![None](https://www.hubwiz.com/blog/content/images/2026/08/1--nNn7xUzPMgkJILUPK0qig.png)

…但这个每页数字忽略了Marker真正的优势：**批处理吞吐量。** Marker的README预测在H100上批量模式可达**约122页/秒**（有效约0.18秒/页），启发式质量分数在90年代中期。MinerU2.5的VLM后端在A100–80G上运行速度为**约2.1页/秒**（在H200上可达约4.5页/秒），并报告比可比的VLM解析器如MonkeyOCR-Pro和dots.ocr快数倍。诚实的总结：**对于原始大批量处理，Marker在大GPU上难以击败；对于每美元精度，MinerU2.5；对于纯CPU或混合格式摄取，Docling或MinerU流水线。**

> **所有这些的诚实结论：** *已发布精度批处理吞吐量覆盖范围和许可证*

## 4、每个如何处理困难案例

平均值隐藏了所有重要的东西。一个整体准确率为90%的解析器，如果你的语料库80%是表格，而该工具的表格处理正是缺失的10%所在，那么它对*你的*语料库仍然无用。以下是三者在实际破坏流水线的五个文档特征上的表现。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-ILDYaz_8ZLr-QdYB9pH8bg.png)

**复杂表格。** 这是MinerU的主场。其表格TEDS分数领先OmniDocBench同类，并且它比其他两者更可靠地处理合并单元格、跨行和嵌套标题。Docling是一个接近且有时更好的第二名*特别是在金融表格上*，这要归功于TableFormer的ACCURATE模式——IBM在金融数据上构建了该模型，这显而易见。Marker的基础表格处理是三者中最弱的，但这正是use\_llm的用途：优化流程合并跨页表格并修复结构，以每个文档一次LLM调用的代价缩小了很大差距。

**数学和公式。** MinerU再次领先，为密集内联和显示数学输出干净的LaTeX——其公式CDM分数是三者中最好的，对于科学和学术PDF是安全的选择。Docling处理公式但在真正复杂的表达式（嵌套积分、大矩阵）上退化，第三方测试将其置于远低于MinerU。Marker的公式质量，像其表格一样，随着LLM流程显著提升，没有它则平庸。

**扫描和退化文档。** 这里排名混乱。Marker最大的已发布弱点是旧扫描件——在olmOCR-Bench的旧扫描类别中得分仅为50年代低分，这意味着历史、传真或严重退化的文档是最坏情况。MinerU和Docling在扫描件上都表现更好；Docling的可插拔OCR后端（你可以将Tesseract替换为RapidOCR或EasyOCR）为你提供了一个旋钮，在默认失败时调整。如果你的语料库主要由糟糕的扫描件组成，请专门对该类别进行基准测试——这是工具分歧最大的地方。

**多栏和阅读顺序。** 三者都有专用的阅读顺序逻辑，并且三者在标准双栏学术布局上都很胜任。Marker实际上在这里很强（在olmOCR-Bench的多栏和长小文本类别中得分很高）。MinerU的显式布局阶段和Docling的RT-DETR布局模型都能很好地处理阅读顺序。需要 across all three 警惕的失败模式是异国布局——杂志跨页、报纸、非明显流程的表单——你应该用眼睛检查输出而不是信任它。

**中文、CJK和多语言。** MinerU是中文和CJK的明确领导者——它由中国实验室构建，支持109种语言，并且在中文文档上的精度是一个真正的差异化因素。Marker通过Surya覆盖90多种语言，并且在主要文字上很稳固。Docling的覆盖范围取决于你插入哪个OCR后端。如果你的文档主要是中文、日文、韩文或阿拉伯文，MinerU是默认选择，并且差距是真实的，而不是边缘的。

> **工程说明。用你最难的文档*类型*构建你的评估语料库，而不是随机样本。**

## 5、许可证——隐藏的决定者

这是将比任何精度数字改变更多现实决策的部分，也是没有人放在比较表中的部分。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-JG3nsdoxaLvUSJltwjbqaw.png)

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Q1YdLv77rlb2BI691HIcww.png)

阅读Marker那一行两次。**Marker的模型权重带有收入阈值的RAIL-M许可证。** 如果你的公司融资或收入超过大约200万美元，并且你在商业产品中使用Marker，你就在免费层之外——而代码本身是**GPL-3.0**，对于任何链接它的内容都有自己的copyleft含义。对于独立开发者、研究人员或早期初创公司，这些都不重要，Marker是一份礼物。对于中型或企业公司，这个单一事实可以在精度进入对话之前将Marker从候选名单中剔除。

相比之下，Docling是**从头到尾的MIT**——最宽松的许可证——这就是为什么IBM和Red Hat推动它用于企业RAG的重要部分。MinerU介于两者之间：大致宽松，但有值得法律审查的额外条件。

> **最佳实践。** *之前*

## 6、速度、硬件和成本

架构部分的经典流水线 vs VLM 分割实际上是硬件和成本的分割。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Q6dMVieDLrEeYcoslsAhCA.png)

工程解读：

- **没有GPU？** Docling或MinerU的流水线后端。Docling在格式覆盖和许可证上获胜；MinerU流水线在表格/公式精度上获胜。
- **一个消费级GPU，需要最佳精度？** MinerU2.5——一个1.2B模型，舒适地适配并且击败更大的系统。
- **一队大GPU和数百万页？** Marker批量处理，许可证允许。

> **工程说明。** *你的你的*

## 7、运行每一个

三者都是pip安装和几行代码。以下是每个的形状。

```
# ---- Docling: broadest coverage, MIT, CPU-friendly ----
# pip install docling
from docling.document_converter import DocumentConverter

conv = DocumentConverter()
result = conv.convert("report.pdf")          # PDF, DOCX, PPTX, HTML, image, ...
print(result.document.export_to_markdown())  # or export_to_dict() for lossless JSON

# ---- Marker: fast Markdown, optional LLM refinement ----
# pip install marker-pdf
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(artifact_dict=create_model_dict())
rendered = converter("report.pdf")           # add use_llm=True config for the refinement pass
markdown, _, images = text_from_rendered(rendered)

# ---- MinerU: pick your backend ----
# pip install "mineru[core]"
mineru -p report.pdf -o ./out -b pipeline    # CPU-capable, fast
mineru -p report.pdf -o ./out -b vlm-vllm     # MinerU2.5 VLM, GPU, highest accuracy

```

```
# ---- Docling: broadest coverage, MIT, CPU-friendly ----
# pip install docling
from docling.document_converter import DocumentConverter

conv = DocumentConverter()
result = conv.convert("report.pdf")          # PDF, DOCX, PPTX, HTML, image, ...
print(result.document.export_to_markdown())  # or export_to_dict() for lossless JSON

# ---- Marker: fast Markdown, optional LLM refinement ----
# pip install marker-pdf
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(artifact_dict=create_model_dict())
rendered = converter("report.pdf")           # add use_llm=True config for the refinement pass
markdown, _, images = text_from_rendered(rendered)

# ---- MinerU: pick your backend ----
# pip install "mineru[core]"
mineru -p report.pdf -o ./out -b pipeline    # CPU-capable, fast
mineru -p report.pdf -o ./out -b vlm-vllm     # MinerU2.5 VLM, GPU, highest accuracy

```

> **提示。** *那个结构上*

## 8、馈送RAG流水线：真正重要的部分

大多数归咎于检索器或嵌入模型的RAG质量问题实际上是伪装的解析问题。这是在十个初稿流水线中九个发生的失败：你将文档导出为Markdown，通过固定的512令牌分割器运行，然后嵌入块。该分割器不知道它刚刚将表格切成两半，将标题从其章节中孤立，或将一个主题的最后一段拼接到下一个主题的第一段。然后你的检索器返回一半表格，模型幻觉另一半。

修复方法是**在结构上分块，而不是在令牌计数上**——这正是为什么这些解析器的*结构化*输出比Markdown更重要。Docling的DoclingDocument和MinerU的JSON都保留了文档的层次结构：哪些文本是标题，哪些块是表格，阅读顺序是什么。在*那个*上分块。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-yMilPydXQt4R9__U2b_A0w.png)

```
# Structure-aware chunking with Docling — keep tables whole, split on sections
from docling.document_converter import DocumentConverter
from docling.chunking import HybridChunker

doc = DocumentConverter().convert("policy.pdf").document
chunker = HybridChunker(max_tokens=512)          # respects tables, headings, reading order

chunks = []
for ch in chunker.chunk(doc):
    # each chunk carries its section path + never splits a table mid-way
    chunks.append({"text": ch.text, "meta": ch.meta.export_json_dict()})

```

```
# Structure-aware chunking with Docling — keep tables whole, split on sections
from docling.document_converter import DocumentConverter
from docling.chunking import HybridChunker

doc = DocumentConverter().convert("policy.pdf").document
chunker = HybridChunker(max_tokens=512)          # respects tables, headings, reading order

chunks = []
for ch in chunker.chunk(doc):
    # each chunk carries its section path + never splits a table mid-way
    chunks.append({"text": ch.text, "meta": ch.meta.export_json_dict()})

```

两条规则将比任何嵌入模型升级更能提高RAG质量：

1. **永远不要分割表格。** 表格是意义的原子单位。将其完整保留在一个块中（将其转换为Markdown或线性化的“行：列=值”形式），并前置章节标题，以便检索器有上下文。
2. **将层次结构带入元数据。** 将每个块的标题路径（“第3节 > 覆盖范围 > 排除事项”）存储为元数据。它改进检索并让你精确引用来源——这在保险和法律中是可选的。

> **最佳实践。**

## 9、可复现的测试套件

空谈无益；在你自己的文档上运行所有三者。这是一个测试套件，它使用每个工具转换一个PDF文件夹，计时它们，并将输出并排写入，以便你可以根据基本事实对它们进行评分。

```
"""
parse_bench.py — Docling vs Marker vs MinerU on YOUR documents.
Runs each tool over a folder, records wall-clock time, saves Markdown for scoring.
"""
import time, pathlib, subprocess, json

CORPUS = pathlib.Path("corpus")        # your PDFs
OUT = pathlib.Path("out"); OUT.mkdir(exist_ok=True)

# ---- Docling ----
from docling.document_converter import DocumentConverter
_docling = DocumentConverter()
def run_docling(pdf):
    t0 = time.perf_counter()
    md = _docling.convert(str(pdf)).document.export_to_markdown()
    return md, time.perf_counter() - t0

# ---- Marker ----
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered
_marker = PdfConverter(artifact_dict=create_model_dict())
def run_marker(pdf):
    t0 = time.perf_counter()
    md, _, _ = text_from_rendered(_marker(str(pdf)))
    return md, time.perf_counter() - t0

# ---- MinerU (CLI) ----
def run_mineru(pdf, backend="pipeline"):
    t0 = time.perf_counter()
    subprocess.run(["mineru", "-p", str(pdf), "-o", str(OUT / "mineru"),
                    "-b", backend], check=True)
    md = (OUT / "mineru" / pdf.stem / "auto" / f"{pdf.stem}.md").read_text(encoding="utf-8")
    return md, time.perf_counter() - t0

def main():
    rows = []
    for pdf in sorted(CORPUS.glob("*.pdf")):
        for name, fn in [("docling", run_docling), ("marker", run_marker), ("mineru", run_mineru)]:
            try:
                md, secs = fn(pdf)
                (OUT / f"{pdf.stem}__{name}.md").write_text(md, encoding="utf-8")
                rows.append({"doc": pdf.name, "tool": name, "sec": round(secs, 2), "chars": len(md)})
                print(f"{pdf.name:30s} {name:8s} {secs:6.2f}s")
            except Exception as e:
                print(f"{pdf.name:30s} {name:8s} FAILED: {e}")
    pathlib.Path("bench.json").write_text(json.dumps(rows, indent=2))

if __name__ == "__main__":
    main()

```

```
"""
parse_bench.py — Docling vs Marker vs MinerU on YOUR documents.
Runs each tool over a folder, records wall-clock time, saves Markdown for scoring.
"""
import time, pathlib, subprocess, json

CORPUS = pathlib.Path("corpus")        # your PDFs
OUT = pathlib.Path("out"); OUT.mkdir(exist_ok=True)

# ---- Docling ----
from docling.document_converter import DocumentConverter
_docling = DocumentConverter()
def run_docling(pdf):
    t0 = time.perf_counter()
    md = _docling.convert(str(pdf)).document.export_to_markdown()
    return md, time.perf_counter() - t0

# ---- Marker ----
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered
_marker = PdfConverter(artifact_dict=create_model_dict())
def run_marker(pdf):
    t0 = time.perf_counter()
    md, _, _ = text_from_rendered(_marker(str(pdf)))
    return md, time.perf_counter() - t0

# ---- MinerU (CLI) ----
def run_mineru(pdf, backend="pipeline"):
    t0 = time.perf_counter()
    subprocess.run(["mineru", "-p", str(pdf), "-o", str(OUT / "mineru"),
                    "-b", backend], check=True)
    md = (OUT / "mineru" / pdf.stem / "auto" / f"{pdf.stem}.md").read_text(encoding="utf-8")
    return md, time.perf_counter() - t0

def main():
    rows = []
    for pdf in sorted(CORPUS.glob("*.pdf")):
        for name, fn in [("docling", run_docling), ("marker", run_marker), ("mineru", run_mineru)]:
            try:
                md, secs = fn(pdf)
                (OUT / f"{pdf.stem}__{name}.md").write_text(md, encoding="utf-8")
                rows.append({"doc": pdf.name, "tool": name, "sec": round(secs, 2), "chars": len(md)})
                print(f"{pdf.name:30s} {name:8s} {secs:6.2f}s")
            except Exception as e:
                print(f"{pdf.name:30s} {name:8s} FAILED: {e}")
    pathlib.Path("bench.json").write_text(json.dumps(rows, indent=2))

if __name__ == "__main__":
    main()

```

然后根据你的手写基本事实，使用适合你文档的指标对out/\*.md文件进行评分——文本使用标准化编辑距离，表格使用TEDS，结构化提取使用字段F1。并排放置的输出使差异很快变得明显；你通常会在十个文档内看出哪个工具适合你的语料库。

> **提示。**

## 10、生产部署说明

在一个PDF上获得好结果是演示。大规模运行是工程。

- **将GPU工具隔离在队列后面。** MinerU2.5的VLM后端和Marker都需要一个热GPU工作池，前面有一个作业队列，而不是每个请求冷启动。每个工作加载一次模型；永远不要每个文档加载。
- **设置硬超时和回退链。** 一个病态PDF（900页扫描、损坏文件）可能会卡住一个工作。限制每个文档的时间，失败时回退到更便宜的路径——例如Docling的流水线或原始文本层提取——而不是默默丢弃文档。
- **关注内存，而不仅仅是延迟。** Marker的每个工作约3-5 GB和MinerU2.5的≥8 GB VRAM设定了你的并发上限。根据VRAM调整工作数量，并在真实批处理大小下监控峰值内存，因为那是凌晨2点OOM杀死工作的原因。
- **按内容哈希缓存。** 在真实系统中，文档不断被重新处理（重新摄取、重试、流水线重新运行）。哈希文件字节并缓存解析结果；解析足够昂贵，这立即收回成本。
- **保持与提供商无关的接口。** 将所有三者包装在一个parse(path) -> StructuredDoc函数后面，以便你可以A/B测试它们，在它们之间回退，并在下个月排行榜变化时交换“最佳”一个——这将会发生。

> **工程说明。**

## 11、优点和缺点

**Docling。** \*优点：\*三者中输入覆盖最广（Office、HTML、EPUB、电子邮件，甚至音频）；完全宽松的MIT许可证；强大的纯CPU故事；专为RAG构建的无损DoclingDocument模型；IBM / Red Hat / Linux Foundation支持和OpenShift操作符；TableFormer在金融表格上确实很强。\*缺点：\*在复杂数学和密集数学上弱于MinerU；不在标准化公开排行榜上，因此其精度更难客观引用；Granite-Docling VLM路径仍在成熟中。

**Marker。** \*优点：\*在大GPU上批量处理最快；干净的通用Markdown；在标题、多栏和长/小文本上很强；use\_llm逃生舱口显著提升表格、数学和表单；通过Surya支持90多种语言。\*缺点：\* **许可证**（GPL-3.0代码 + 带收入阈值的RAIL-M权重）是真正的商业阻碍；在旧/退化扫描件上弱（olmOCR-Bench旧扫描约52）；不在OmniDocBench顶级。

**MinerU。** *优点：最高的已发布*精度（MinerU2.5在同类中位居OmniDocBench榜首）；在表格、公式和CJK/多语言方面最佳；非常高效的1.2B VLM击败更大的模型；双后端设计让你可以权衡精度与纯CPU运行；三者中GitHub吸引力最大。\*缺点：\*高精度VLM路径**需要GPU**（≥8 GB）；约20 GB占用空间和更重的设置；许可证带有超出干净Apache-2.0的额外条件。

> **工程说明。**

## 12、真实成本（超出GPU账单）

由于三者都是开源的，模型本身是免费的——这愚弄了团队，让他们认为*系统*同样便宜。它们不是。真实成本有三层，只有第一层出现在云发票上。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-_dBcSDK1iD5kYzt5IJUMjQ.png)

**计算成本。** 对于CPU路径（Docling、MinerU流水线），每页的边际成本本质上是电力——可以忽略不计。对于GPU路径，做算术：租用的A100大约每小时1.50美元，以每秒约2页的速度运行MinerU2.5，每小时处理约7,200页，在良好利用率下每页约**0.0002美元**。Marker在H100上批量处理每秒约120页，每页甚至更便宜——*如果*你让GPU饱和。在稳定高量以下，GPU闲置，每个有用页的成本膨胀；这是每个自托管模型都面临的相同利用率陷阱。

**许可证成本。** 这是没有人预算的一层。Marker的RAIL-M权重在收入阈值之上意味着商业许可证谈判——一个未知的美元数字和法律审查，可能比整个集成花费更长时间。Docling的MIT许可证使该成本恰好为零，永远。当你给三者定价时，**也要给律师时间定价**；对于企业，Docling的宽松性可能比任何每页计算节省都更有价值。

**工程和维护成本。** 最重的工具是占用空间最大、活动部件最多的那个。MinerU的约20 GB安装和双后端为你购买精度，但设置和维护成本很高。Docling的单个CPU友好库是最便宜的操作。Marker介于两者之间。将你诚实的工程师天数估计乘以加载的工程师费率，这通常完全使计算行相形见绌。

> **工程说明。** *采用*

## 13、谁应该使用哪个

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-rCcImRGurovyPax75Pm0iw.png)

简单说明：

- **使用Docling，如果**你需要最广的格式覆盖、宽松的MIT许可证、仅CPU部署或用于RAG流水线的干净结构化输出。对于大多数企业来说，这是最安全的默认选择，仅许可证就为它赢得了很多房间。
- **使用MinerU，如果**你有GPU，并且在表格、公式或中文/CJK文档上的精度是你的首要任务。其1.2B VLM是最准确的开源选项，流水线后端是可靠的CPU回退。
- **使用Marker，如果**你是个人、研究人员或早期初创公司，处理高量并且你想要最快的干净Markdown——并且你已确认许可证适合你的情况。

> **最佳实践。**

## 14、常见问题

**哪个最适合纯CPU部署？** Docling或MinerU的流水线后端。Docling在格式覆盖和MIT许可证上获胜；MinerU流水线在表格和公式精度上获胜。Marker技术上在CPU（和Apple MPS）上运行，但它在那里很慢，许可证是更大的约束。

**哪个最适合中文或CJK文档？** MinerU，并且它不接近。它由中国实验室构建，支持109种语言，并在CJK精度上领先。Marker（通过Surya支持90多种语言）是合理的第二名。

**我有数百万页和GPU集群。哪个最快？** Marker在批量模式下——在H100上可达约120页/秒——前提是其GPL-3.0 + RAIL-M许可证适合你公司的规模和产品。如果不行，MinerU2.5的VLM后端是高精度下最快的许可证清洁选项。

**我可以在商业产品中使用Marker吗？** 只有当你符合其许可证时：免费用于研究、个人使用和融资/收入低于约200万美元的初创公司。超过此限制，你需要商业许可证，并且代码是GPL-3.0。在构建之前咨询法律——这是将Marker从企业候选名单中剔除的首要原因。

**哪个为RAG产生最佳输出？** Docling，通过设计——其DoclingDocument结构和原生分块器专为RAG摄取而构建。MinerU的JSON也结构丰富。关键是在该结构上分块，而不是盲目地按令牌计数分割Markdown。

**我甚至需要专用解析器吗，还是通用视觉语言模型可以做到？** 对于干净的、原生数字PDF，强大的VLM可以走得很远。对于高量、成本敏感或精度关键的流水线——尤其是表格和公式——专用解析器更快、更便宜、更可靠。（这种权衡值得单独一篇文章，它是本系列的下一篇。）

**本文中的基准数字可信吗？** 它们是真实的并且被引用，但它们大多是*供应商自报*的，在*不同的基准套件和版本*上，并且Docling*完全不在主要榜单上*。将它们视为方向性。决定你部署的唯一数字是你在自己文档上运行上述测试套件得到的数字。

**如果我只想要一个，我应该默认使用哪个？** 对于大多数发布真实系统的团队：**Docling**——MIT许可证、所有格式、CPU友好、RAG就绪输出。当困难文档的精度是优先级且你有GPU时，使用**MinerU**；当你规模小、快速移动并处理高量时，使用**Marker**。

## 15、最终判断

如果你强迫我只用一行：**MinerU是最准确的，Marker是最快的，Docling是你实际上可以在任何地方使用而无需请求许可的——对于大多数团队来说，最后一个属性获胜。**

MinerU2.5是三者中最令人印象深刻的*工程*结果：一个12亿参数模型，通过巧妙处理分辨率而不是向问题抛出参数，在排行榜上击败比它大很多倍的系统。如果困难文档的精度是你的工作并且你有GPU，它是我的默认选择。

Marker是最令人印象深刻的*吞吐量*结果：在大GPU上批量处理，它将远远超过其他两者，并且LLM优化逃生舱口是一个真正的好设计。但其许可证悄悄地取消了大量商业用户的资格，这必须是你首先检查的事情，而不是最后。

Docling是最令人印象深刻的*产品*决策：MIT许可证、所有格式、CPU友好、专为RAG构建的结构化输出，以及企业支持意味着它不会消失。它不在任何精度排行榜的顶部——部分原因是它*不在*主要排行榜上——但“在任何地方运行、摄取任何内容、法律说可以”对于大多数发布真实系统的团队来说比三个TEDS点更有价值。

---

原文链接: [Docling vs Marker vs MinerU: The Ultimate Open-Source PDF Parser Benchmark (2026) — Which Is Best…](https://freedium-mirror.cfd/https://adityamangal98.medium.com/docling-vs-marker-vs-mineru-the-ultimate-open-source-pdf-parser-benchmark-2026-which-is-best-a36ecbb6c6b1?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「RAG / 数据 / 文档智能」专题的一部分。**完整地图见：[RAG / 数据 / 文档智能完全指南](https://www.hubwiz.com/blog/rag-data-stack/)