Docling 对比 MinerU、Marker、PyMuPDF4LLM、MarkItDown 与 Unstructured（2026 实测）

哪个工具适合哪种任务#

Docling

从 PDF、Office、HTML、图片和音频生成结构化输出（标题、表格、阅读顺序、页面来源），内置 OCR。MIT 许可。最适合 RAG 流水线和必须保持宽松许可的项目。

MinerU

流行的 PDF 与图片解析工具，中文支持出色，提供 VLM 后端。Apache-2.0 加附加条件（门槛和署名）。

Marker

高质量的 PDF 转 Markdown，可选 LLM 处理表格、公式和表单。代码 Apache-2.0；当前模型权重在融资/收入低于 500 万美元时免费，超过需商业许可。

PyMuPDF4LLM

从原生数字 PDF 极快地生成 Markdown，表格不错。AGPL-3.0 或 Artifex 商业许可。OCR 依赖 Tesseract。

MarkItDown

快速把多种格式（Office、HTML、EPUB、ZIP、YouTube……）转成近似纯文本的 Markdown。MIT。PDF 没有本地 OCR，也没有表格结构。

Unstructured

把文档切分为带类型元素的分区库，面向数据接入流水线。Apache-2.0。本地 OCR 依赖 Tesseract。

同一份 PDF 上的速度#

同一 PDF、同一 CPU 下的速度每页秒数，预热后运行的中位数。速度不等于质量——请看下方的表格测试。

docling.org 实测，一台 4 vCPU、无 GPU 的云服务器：Docling 2.148.0 测于 2026-11-06，其他工具测于 2026-10-27。越低越好。

查看数据表

同一 PDF、同一 CPU 下的速度
	秒/页
MarkItDown	0.35 秒
Unstructured	0.36 秒
PyMuPDF4LLM	0.69 秒
Docling (关闭 OCR)	1.83 秒
Docling (默认)	6.58 秒
Unstructured (hi_res)	10.01 秒
Marker	90.66 秒

所有工具都在同一台无 GPU 的 4 vCPU 机器上转换同一份 9 页原生数字论文（Docling 技术报告）。Docling 的两条分别是默认流水线和关闭 OCR 的同一流水线——耗时主要花在对论文插图做 OCR 上。Marker 1.10.2 在这里每页 90.7 秒——它的模型是为 GPU 设计的，在 GPU 上数字会大不相同。Unstructured 的默认策略直接读取文本层（每页 0.36 秒）；我们在表格测试中使用的带表格识别的 hi_res 模式每页 10.0 秒。

扫描页面#

扫描版 PDF：还原出的原文词语比例4 页以 150 DPI 栅格化并加入轻微模糊与倾斜。没有 OCR 的工具几乎提取不到内容。

docling.org 于 2026-10-27 实测（Docling 2.143.1）：原生文本中（≥4 个字母的）不重复单词在各输出中出现的比例。

查看数据表

扫描版 PDF：还原出的原文词语比例
	还原比例
Unstructured	99.7%
Marker	97.2%
Docling	94.2%
PyMuPDF4LLM	93.8%
MarkItDown	0.0%

把同一篇论文的四页以 150 DPI 栅格化，并加入轻微模糊和倾斜，因此没有文本层。分数是原文中（四个字母及以上的）不重复单词出现在各工具输出中的比例。PyMuPDF4LLM 和 Unstructured 通过需要另行安装的 Tesseract 做 OCR（没有它时 PyMuPDF4LLM 完全没有输出文字）。Unstructured 的纯文本输出得分最高；Docling 的 Markdown 有意省略页眉、页脚和 arXiv 页边标记，这在按词计数的指标上会少几分。Docling 自身各引擎的对比见 OCR 指南——在 2.148.0 的复测中，以 Tesseract 为引擎时 Docling 达到 96.1%，每页 5.5 秒。本图来自 10 月 27 日用 Docling 2.143.1 的测试，五个工具使用的是同一份扫描件。

同一张表格，五种输出#

论文的表 1 有两级表头，且每个单元格包含两个数值（4 线程和 16 线程）。子行之间没有横线——这是典型的难点。以下是各工具的原样输出（只截取表格部分）：

markdownDocling 2.148.0（关闭 OCR）

| CPU                                         | Thread budget   | native backend - TTS   | native backend - Pages/s   | native backend - Mem   | pypdfium backend - TTS   | pypdfium backend - Pages/s   | pypdfium backend - Mem   |
|---------------------------------------------|-----------------|------------------------|----------------------------|------------------------|--------------------------|------------------------------|--------------------------|
| Apple M3 Max                                | 4 16            | 177 s 167 s            | 1.27 1.34                  | 6.20 GB                | 103 s 92 s               | 2.18 2.45                    | 2.56 GB                  |
| (16 cores) Intel(R) Xeon E5-2690 (16 cores) | 4 16            | 375 s 244 s            | 0.60 0.92                  | 6.16 GB                | 239 s 143 s              | 0.94 1.57                    | 2.42 GB                  |

markdownPyMuPDF4LLM 2.0

|CPU|Thread<br>budet|n<br>|ative back<br>|end<br>|pypi<br>|dfium bac<br>|i kend<br>|
|---|---|---|---|---|---|---|---|
||g|TTS|Pages/s|Mem|TTS|Pages/s|Mem|
|Apple M3 Max<br>(16 cores)|4<br>16|177 s<br>167 s|1.27<br>1.34|6.20 GB|103 s<br>92 s|2.18<br>2.45|2.56 GB|
|Intel(R) Xeon<br>E5-2690<br>(16 cores)|4<br>16|375 s<br>244 s|0.60<br>0.92|6.16 GB|239 s<br>143 s|0.94<br>1.57|2.42 GB|

MarkItDown 0.1.9

Thread nativebackend pypdfiumbackend
CPU
budget
TTS Pages/s Mem TTS Pages/s Mem
AppleM3Max 4 177s 1.27 103s 2.18
6.20GB 2.56GB
(16cores) 16 167s 1.34 92s 2.45

markdownMarker 1.10.2

| CPU                                    | Thread  |                | native backend |         | pypdfium backend |              |         |
|----------------------------------------|---------|----------------|----------------|---------|------------------|--------------|---------|
|                                        | budget  | TTS            | Pages/s        | Mem     | TTS              | Pages/s      | Mem     |
| Apple M3 Max<br>(16 cores)             | 4<br>16 | 177 s<br>167 s | 1.27<br>1.34   | 6.20 GB | 103 s<br>92 s    | 2.18<br>2.45 | 2.56 GB |
| Intel(R) Xeon<br>E5-2690<br>(16 cores) | 4<br>16 | 375 s<br>244 s | 0.60<br>0.92   | 6.16 GB | 239 s<br>143 s   | 0.94<br>1.57 | 2.42 GB |

htmlUnstructured 0.27.35 (hi_res, infer_table_structure)

<table><thead><tr><th rowspan="2">CPU</th><th rowspan="2">Thread budget</th><th colspan="3">native backend</th><th colspan="3">pypdfium backend</th></tr>
<tr><th>TTS</th><th>Pages/s</th><th>Mem</th><th>TTS</th><th>Pages/s</th><th>Mem</th></tr></thead>
<tbody><tr><td>Intel(R) Xeon</td><td>4</td><td>375s</td><td>0.60</td><td></td><td>239s</td><td>0.94</td><td></td></tr>
<tr><td>E5-2690</td><td>16 =.</td><td>244s</td><td>0.92,</td><td>FOGB</td><td>jy35</td><td>p57</td><td>742 GB</td></tr></tbody></table>

工具	表头	24 个数字是否齐全	行结构
Docling	两级都保留，合并为 “native backend - TTS”	是	4 线程和 16 线程的值合并到同一单元格；“(16 cores)” 被移到错误的行
PyMuPDF4LLM	损坏（“budet”、“ative back”）	是	用 `<br>` 保留了子行；“(16 cores)” 在正确的行
MarkItDown	没有表格	是，但为松散文本	丢失；单词粘连（“AppleM3Max”）
Marker	两级都保留为两行表头（分组名在各自单元格中）	是	用 `<br>` 保留子行；“(16 cores)” 在正确的行——最完整的结果：每一行、每个数字都在正确位置
Unstructured（hi_res）	完美：真正的 `rowspan`/`colspan` 两级表头	否——缺少 Apple M3 Max 整行	剩下的一行部分被 OCR 识别错（“FOGB”、“jy35”）

许可证：决定大多数项目的那一行#

工具（核对版本）	代码许可证	模型 / 权重	注意事项
Docling 2.148.0	MIT	版面模型（Heron）：Apache-2.0 · TableFormer：CDLA-Permissive-2.0 / Apache-2.0（Hugging Face 模型卡）	可选 VLM 预设各有自己的许可证
MinerU 4.0.12	MinerU 开源许可协议（Apache-2.0 加附加条件）	—	月活超过 1 亿或月收入超过 2,000 万美元需另行授权；在线服务须注明使用了 MinerU
Marker 2.0.0	Apache-2.0	修改版 AI Pubs Open RAIL-M：研究、个人使用以及融资/收入低于 500 万美元的初创公司免费	超过门槛需为权重购买商业许可；我们测试的 1.10.2 版为 GPL-3.0
PyMuPDF / PyMuPDF4LLM 2.0	AGPL-3.0 或 Artifex 商业许可	—	网络服务和分发软件需履行 AGPL 义务
MarkItDown 0.1.9	MIT	—	可选云服务（Azure Document Intelligence、LLM 图片描述）有各自条款
Unstructured 0.27.35	Apache-2.0	hi_res 使用第三方版面模型	仅支持 Python 3.11–3.13（据其包元数据）

读取自 2026 年 10 月 27 日各包的 PyPI 元数据和许可证文件。不构成法律意见。

功能一览#

	Docling	MinerU	Marker	PyMuPDF4LLM	MarkItDown	Unstructured
输入	37 种格式，含 PDF、Office、HTML、图片、音频、XML	PDF、OFD、EPUB、HTML、图片、CSV、RTF、OOXML、OpenDocument	PDF、图片；装 `marker-pdf[full]` 后支持 Office、HTML、EPUB	PDF 及 PyMuPDF 支持的其他格式	PDF、Office、HTML、EPUB、CSV、图片、音频、ZIP、YouTube……	PDF、Office、HTML、邮件、EPUB、图片等
扫描件本地 OCR	内置（默认 RapidOCR；7 个引擎）	内置	内置（Surya）	通过 Tesseract	无（仅云服务选项）	通过 Tesseract（hi_res / ocr_only）
表格结构模型	TableFormer	有	有	基于文本层的规则	无	有（hi_res）
输出	12 种，含 Markdown、JSON、HTML、DocTags、分块	Markdown、JSON	Markdown、JSON、HTML、分块	Markdown、JSON、文本	Markdown	元素 JSON
内置 RAG 分块	HybridChunker、HierarchicalChunker	—	—	按页分块	—	按标题 / 基础
服务 / API	docling-serve、MCP 服务器	有	托管 API（Datalab）	—	MCP 服务器	托管平台

格式列表来自上述版本中各包自己的说明或源码目录；“—”表示我们没有在包中找到，并不代表无法实现。

我们没能测试的部分#

MinerU 4.0.12 安装成功，但它自带的 llama.cpp 程序在我们的机器上转换第一页之前就崩溃了（free(): invalid pointer）。因此只列出其许可证和支持格式。中文用户如果正在评估 MinerU，建议在自己的硬件上与 Docling 直接对比。
Marker 2.0.0 通过本地推理服务器运行模型（NVIDIA GPU 上用 vLLM，其他情况用 llama.cpp）。我们无法在沙箱中启动该服务器，因此测试的是 Marker 1.10.2——采用旧架构的最后一个版本。Marker 2 的速度和质量可能有很大不同。
GPU。本页所有数字都只用 CPU。模型较重的工具（开启 OCR 的 Docling、Marker、MinerU）从 GPU 获益最多；基于文本层的工具获益很少。

测试方法#

每个工具装在独立的 Python 3.13 虚拟环境中，使用默认设置，先预热转换一次，再在同一进程中计时（取三次运行的中位数；Marker 每页可达数分钟，原生数字 PDF 为预热后计时一次，扫描件为模型加载后单次运行）。
硬件：4 vCPU x86_64，15 GB 内存，无 GPU。文档：Docling 技术报告（arXiv 2408.09869，9 页）及其前四页的栅格化副本。
如需原始输出，请发邮件至 hello@docling.org。工具维护者如果认为某项设置不公平，请告诉我们，我们会重新测试。

常见问题

Docling 和 MinerU 哪个好？

两者都擅长 PDF 且可本地运行。MinerU 4 支持多种输入格式，在中文文档上尤其受欢迎；其许可证为 Apache 2.0 加附加条件（月活超过 1 亿或月收入超过 2,000 万美元需另行取得商业许可，提供在线服务须注明使用了 MinerU）。Docling 为 MIT 许可，支持 37 种输入格式，并与 LangChain、LlamaIndex 和 Haystack 集成。我们未能在测试机上对 MinerU 4 做基准测试（见下文）。

Docling 比 Marker 好吗？

取决于文档和你需要的许可证。在我们的 CPU 测试中，Docling 默认流水线每页 6.6 秒（关闭 OCR 每页 1.8 秒），Marker 1.10.2 每页 90.7 秒。Docling 全部为 MIT 许可，而当前 Marker（2.0）的模型权重只在融资或收入低于 500 万美元时免费。Marker 可以加一道 LLM 处理（--use_llm）来改善复杂表格和行内公式。

Docling 和 MarkItDown 有什么区别？

MarkItDown（MIT，微软）是轻量转换器：很快、支持格式多，但它处理 PDF 时只提取纯文本，没有 OCR 和表格结构。在我们的测试中它每页 0.35 秒，扫描页什么也没提取到。原生数字文件快速导出文本可以用它；需要版面、表格或扫描件时用 Docling。

Docling 和 PyMuPDF4LLM 怎么选？

PyMuPDF4LLM 很快（我们测试中每页 0.69 秒），测试表格的数字也全部保留，但 PyMuPDF 采用 AGPL-3.0 或 Artifex 商业许可，这对闭源和 SaaS 产品很重要。它的 OCR 需要安装 Tesseract。

Docling 可以免费商用吗？

可以。Docling 采用 MIT 许可，默认的版面和表格模型也采用宽松许可证发布。添加可选的 VLM 预设时请查看对应模型卡，因为各模型许可证不同。

资料来源

内容准确吗？当 Docling 新版本改变行为时，我们会重新验证页面。如果某条命令对你无效，请把 Docling 版本号和报错发到 hello@docling.org，更正通常一天内上线。