Docling vs Marker vs MinerU

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

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

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

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

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

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

工程说明。 所有三个工具都发展迅速。截至2026年中期：Docling版本为v2.111，Marker版本为v1.10.2，MinerU版本为v3.4.3，MinerU的精度模型是MinerU2.5。版本对基准数字影响巨大——我每次都会标注。

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。

工程说明。 注意，这三者都不是“OCR模型”。它们是文档转换系统——布局检测、表格结构识别、公式识别、OCR和阅读顺序逻辑的编排。整个流水线的质量比其中任何单个模型都重要。这正是为什么它们值得作为系统进行比较。

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

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

2.1 Docling

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

关于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优化阶段。

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

2.3 MinerU

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

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

工程说明。 架构的主线：Docling和MinerU流水线是可检查的多阶段系统，你可以在CPU上运行；MinerU2.5和Marker的Surya路径依赖VLM，需要GPU才能获得全速和精度。 这个单一的区别——经典流水线 vs VLM——驱动了下面的大部分成本和硬件权衡。

3、基准现实

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

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

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

MinerU2.5按类别（v1.5，来自其论文）：文本编辑0.047，公式CDM88.46，表格TEDS88.22，TEDS-S92.38，阅读顺序编辑0.044——在每个轴上领先其同类。

工程说明——在引用95.69之前请阅读此部分。 OmniDocBench v1.5和v1.6是不同的套件，它们的分数不能直接比较。 OpenDataLab自己解释从90.67到95.69的跳跃是“不是通过扩展参数而是通过数据工程”以及基准版本更改。将低90分视为MinerU诚实的、跨一致的地位，将中90分视为更新基准、供应商报告的数字。并且此表中的每个数字都是自报的——后面测试套件的重点是你在自己的文档上验证。

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

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

工程说明。 Marker的两个olmOCR-Bench数字（76.1 vs 83.2）是不同版本在不同基准修订版上——不是矛盾，只是不可比较。这是开源OCR基准测试的反复主题：工具发展比排行榜快，所以任何单个数字都是快照，不是判决。

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

…但这个每页数字忽略了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流水线。

所有这些的诚实结论： MinerU拥有最强的已发布精度，Marker拥有最强的批处理吞吐量，Docling拥有最强的覆盖范围和许可证——但它们从未在相同语料库上进行过干净的头对头测量。因此，决定性的基准测试是你在自己的文档上运行的那个。测试套件在最后。

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

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

复杂表格。 这是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是默认选择，并且差距是真实的，而不是边缘的。

工程说明。 实际结论：用你最难的文档类型构建你的评估语料库，而不是随机样本。 如果你20%的文档是中文扫描金融表格，那么这20%应该占你测试集的60%，因为这是工具分离的地方，也是错误选择让你付出代价的地方。简单和困难文档的混合平均值会告诉你它们都“大约90%”，并且什么也教不了你。

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

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

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

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

最佳实践。 在精度之前决定许可证，而不是之后。基准测试三个工具两周，选择最精确的一个，然后在代码审查中被法律否决，这是令人心碎的。首先按许可证过滤；只对存活下来的进行基准测试。

6、速度、硬件和成本

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

工程解读：

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

工程说明。 不要孤立地过度关注每页延迟。一个工具单线程每页0.86秒但批量处理每秒122页（Marker），一旦你以真实量级处理，将碾压一个每页0.21秒但批量处理不好的工具。在你的批处理大小和并发度下测量你的吞吐量——单个文档计时是营销，不是容量规划。

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

提示。 对于RAG流水线，不要只是导出Markdown并盲目分块。Docling的export_to_dict()和MinerU的JSON保留了文档层次结构（标题、表格、阅读顺序）——在那个结构上分块（按章节，保持表格完整），而不是在固定的令牌窗口上。你选择的解析器远不如你是否立即丢弃其结构重要。

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

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

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

# 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质量：

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

最佳实践。 一起评估解析和检索，而不是分开。一个分数低两个TEDS点但产生更清晰章节边界的解析器，可以在端到端RAG答案质量上击败“更准确”的解析器。重要的数字不是解析器的基准——而是你的系统是否正确回答问题。

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。并排放置的输出使差异很快变得明显；你通常会在十个文档内看出哪个工具适合你的语料库。

提示。 固定所有三个的版本（docling==、marker-pdf==、mineru==）并将bench.json与git SHA一起提交。这些工具每月都在变化；你想要一个可复现的工件，而不是“MinerU那次更好”的记忆。

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测试它们，在它们之间回退，并在下个月排行榜变化时交换“最佳”一个——这将会发生。

工程说明。 单一最高杠杆的生产决策是回退链。在保险处理中，我默认运行快速、便宜的解析器，只将低置信度或失败的文档升级到繁重的VLM路径。大多数文档很容易；将GPU预算花在困难的文档上，而不是CPU流水线处理得很好的80%上。

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的额外条件。

工程说明。 看到模式了吗：每个工具的最大优点是另一个的最大缺点。Docling的覆盖范围和许可证 vs MinerU的精度 vs Marker的速度。没有免费午餐——只有你最愿意放松哪个约束。

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

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

计算成本。 对于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介于两者之间。将你诚实的工程师天数估计乘以加载的工程师费率，这通常完全使计算行相形见绌。

工程说明。 大规模上最便宜的工具很少是采用最便宜的工具。一个团队选择最精确的GPU流水线，然后花三周时间与CUDA版本和许可证审查作斗争，花费比一个团队在下午在CPU上发布Docling并继续更多。优化总拥有成本，而不是每页数字。

13、谁应该使用哪个

简单说明：

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

最佳实践。 构建一个薄的parse(document) -> StructuredDoc接口，将所有三者放在其后，并设置黄金集回归测试。解析器每月都在改进，“最佳”一个将会改变；你希望交换是一个配置标志，而不是重写。

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…

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