Marker

Marker 能够快速准确地将 PDF 转换为 Markdown。

• 支持广泛的文档类型（针对书籍和科学论文进行了优化）
• 支持所有语言
• 移除页眉/页脚/其他人工制品
• 格式化表格和代码块
• 提取并保存图像与 Markdown 一起
• 将大多数方程转换为 LaTeX
• 可在 GPU、CPU 或 MPS 上运行

工作原理

Marker 是一个深度学习模型管道：

• 提取文本，必要时进行 OCR（启发式方法、surya、tesseract）
• 检测页面布局并确定阅读顺序（surya）
• 清理和格式化每个文本块（启发式方法、texify）
• 合并文本块并对完整文本进行后处理（启发式方法、pdf_postprocessor）

它仅在必要时使用模型，从而提高速度和准确性。

示例

PDF	类型	Marker	Nougat
Think Python	教科书	查看	查看
Think OS	教科书	查看	查看
Switch Transformers	arXiv 论文	查看	查看
Multi-column CNN	arXiv 论文	查看	查看

性能

上述结果是在 A6000 上配置 marker 和 nougat，使每个任务占用约 4GB VRAM 的情况下获得的。

详细的速度和准确性基准测试以及如何运行自己的基准测试的说明，请参见下文。

商业用途

我希望 marker 能尽可能广泛地使用，同时仍能为我的开发/训练成本提供资金支持。研究和个人用途始终是允许的，但对商业用途有一些限制。

模型权重采用 cc-by-nc-sa-4.0 许可，但对于最近 12 个月内总收入低于 500 万美元且累计风险投资/天使投资融资低于 500 万美元的任何组织，我将豁免该许可。如果你想删除 GPL 许可要求（双重许可）和/或在超出收入限制的情况下商业使用权重，请查看这里的选项。

托管 API

这里提供了 marker 的托管 API：

• 支持 PDF、Word 文档和 PowerPoint
• 价格是领先的基于云的竞争对手的 1/4
• 利用 Modal 实现高可靠性，无延迟峰值

社区

我们在 Discord 上讨论未来的开发。

局限性

PDF 是一种棘手的格式，因此 marker 并不总是能完美工作。以下是一些已知的限制，我们计划在未来解决：

• Marker 不会将 100% 的方程转换为 LaTeX。这是因为它需要先检测再转换。
• 表格并不总是 100% 正确格式化 - 文本可能出现在错误的列中。
• 空白和缩进并不总是被完全保留。
• 并非所有行/跨度都能正确连接。
• 这个工具最适用于不需要大量 OCR 的数字 PDF。它针对速度进行了优化，只使用有限的 OCR 来修复错误。

安装

你需要 Python 3.9+ 和 PyTorch。如果你不使用 Mac 或 GPU 机器，可能需要先安装 CPU 版本的 torch。更多详情请参见此处。

使用以下命令安装：

pip install marker-pdf

可选：OCRMyPDF

仅在你想使用可选的 ocrmypdf 作为 OCR 后端时需要。请注意，ocrmypdf 包含 Ghostscript（一个 AGPL 依赖项），但通过 CLI 调用它，因此不会触发许可条款。

参见此处的说明

使用方法

首先，进行一些配置：

• 检查 marker/settings.py 中的设置。你可以使用环境变量覆盖任何设置。
• 你的 torch 设备将被自动检测，但你可以覆盖它。例如，TORCH_DEVICE=cuda。
  • 如果使用 GPU，将 INFERENCE_RAM 设置为你的 GPU VRAM（每个 GPU）。例如，如果你有 16 GB VRAM，设置 INFERENCE_RAM=16。
  • 根据你的文档类型，marker 的每个任务的平均内存使用量可能略有不同。如果你注意到任务因 GPU 内存不足而失败，可以配置 VRAM_PER_TASK 来调整此项。
• 默认情况下，marker 将使用 surya 进行 OCR。Surya 在 CPU 上较慢，但比 tesseract 更准确。如果你想要更快的 OCR，将 OCR_ENGINE 设置为 ocrmypdf。这还需要外部依赖项（见上文）。如果你完全不想使用 OCR，将 OCR_ENGINE 设置为 None。

转换单个文件

marker_single /path/to/file.pdf /path/to/output/folder --batch_multiplier 2 --max_pages 10 --langs English

• --batch_multiplier 是如果你有额外的 VRAM，要将默认批处理大小乘以多少。数值越高，占用的 VRAM 越多，但处理速度越快。默认设置为 2。默认批处理大小将占用约 3GB VRAM。
• --max_pages 是要处理的最大页数。省略此项以转换整个文档。
• --langs 是文档中语言的逗号分隔列表，用于 OCR

确保 DEFAULT_LANG 设置适合你的文档。OCR 支持的语言列表在这里。如果你需要更多语言，可以将 OCR_ENGINE 设置为 ocrmypdf，使用 Tesseract 支持的任何语言。如果你不需要 OCR，marker 可以处理任何语言。

转换多个文件

marker /path/to/input/folder /path/to/output/folder --workers 10 --max 10 --metadata_file /path/to/metadata.json --min_length 10000

• --workers 是同时转换的 PDF 数量。默认设置为 1，但你可以增加它以提高吞吐量，代价是更多的 CPU/GPU 使用率。如果你使用 GPU，并行度不会超过 INFERENCE_RAM / VRAM_PER_TASK。
• --max 是要转换的最大 PDF 数量。省略此项以转换文件夹中的所有 PDF。
• --min_length 是从 PDF 中提取的最小字符数，低于此数量的 PDF 将不会被处理。如果你要处理大量 PDF，我建议设置此项以避免对主要是图像的 PDF 进行 OCR（会降低整体速度）。
• --metadata_file 是一个可选的 JSON 文件路径，包含 PDF 的元数据。如果提供，它将用于设置每个 PDF 的语言。如果不提供，将使用 DEFAULT_LANG。格式如下：

{
  "pdf1.pdf": {"languages": ["English"]},
  "pdf2.pdf": {"languages": ["Spanish", "Russian"]},
  ...
}

你可以使用语言名称或代码。具体代码取决于 OCR 引擎。surya 代码的完整列表请参见这里，tesseract 的请参见这里。

在多个 GPU 上转换多个文件

MIN_LENGTH=10000 METADATA_FILE=../pdf_meta.json NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out

• METADATA_FILE 是一个可选的 JSON 文件路径，包含 PDF 的元数据。格式见上文。
• NUM_DEVICES 是要使用的 GPU 数量。应为 2 或更大。
• NUM_WORKERS 是在每个 GPU 上运行的并行进程数。每个 GPU 的并行度不会超过 INFERENCE_RAM / VRAM_PER_TASK。
• MIN_LENGTH 是从 PDF 中提取的最小字符数，低于此数量的 PDF 将不会被处理。如果你要处理大量 PDF，我建议设置此项以避免对主要是图像的 PDF 进行 OCR（会降低整体速度）。 请注意，上述环境变量是特定于此脚本的，不能在 local.env 中设置。

故障排除

如果程序运行结果不符合预期，以下设置可能会有帮助：

• OCR_ALL_PAGES - 设为 true 可强制对所有页面进行 OCR。如果表格布局无法正确识别，或文本出现乱码，这个设置很有用。
• TORCH_DEVICE - 设置此项可强制 marker 使用指定的 torch 设备进行推理。
• OCR_ENGINE - 可设置为 surya 或 ocrmypdf。
• DEBUG - 设为 True 可在转换多个 PDF 时显示 ray 日志。
• 确认已正确设置语言，或已传入元数据文件。
• 如果遇到内存不足错误，请减少工作进程数量（增加 VRAM_PER_TASK 设置）。您也可以尝试将较长的 PDF 拆分成多个文件。

通常，如果输出结果不符合预期，对 PDF 进行 OCR 是一个好的首选步骤。并非所有 PDF 都嵌入了良好的文本/边界框。

有用的设置

这些设置可以改善/更改输出质量：

• OCR_ALL_PAGES 将强制对整个文档进行 OCR。许多 PDF 由于使用了较旧的 OCR 引擎，嵌入了质量较差的文本。
• PAGINATE_OUTPUT 将在页面之间插入水平分隔线。默认值：False。
• EXTRACT_IMAGES 将提取图像并单独保存。默认值：True。
• BAD_SPAN_TYPES 指定要从 markdown 输出中移除的布局块。

基准测试

对 PDF 提取质量进行基准测试是很困难的。我通过寻找同时具有 PDF 版本和 LaTeX 源代码的书籍和科学论文创建了一个测试集。我将 LaTeX 转换为文本，并将参考文本与文本提取方法的输出进行比较。这个方法可能会有噪音，但至少在方向上是正确的。

基准测试表明，marker 比 nougat 快 4 倍，在 arXiv 以外的领域更准确（nougat 是在 arXiv 数据上训练的）。我们还展示了朴素文本提取（无处理直接从 PDF 中提取文本）作为比较。

速度

方法	平均得分	每页用时	每份文档用时
marker	0.613721	0.631991	58.1432
nougat	0.406603	2.59702	238.926

准确性

前 3 个是非 arXiv 书籍，后 3 个是 arXiv 论文。

方法	multicolcnn.pdf	switch_trans.pdf	thinkpython.pdf	thinkos.pdf	thinkdsp.pdf	crowd.pdf
marker	0.536176	0.516833	0.70515	0.710657	0.690042	0.523467
nougat	0.44009	0.588973	0.322706	0.401342	0.160842	0.525663

基准测试期间的峰值 GPU 内存使用为：nougat 为 4.2GB，marker 为 4.1GB。基准测试在 A6000 Ada 上运行。

吞吐量

Marker 平均每个任务使用约 4GB 显存，因此在 A6000 上可以并行转换 12 个文档。

运行您自己的基准测试

您可以在自己的机器上对 marker 的性能进行基准测试。手动安装 marker：

git clone https://github.com/VikParuchuri/marker.git
poetry install

下载基准测试数据此处并解压。然后运行 benchmark.py：

python benchmark.py data/pdfs data/references report.json --nougat

这将对 marker 和其他文本提取方法进行基准测试。它为 nougat 和 marker 设置批处理大小，以使每个方法使用相似数量的 GPU 内存。

省略 --nougat 可将 nougat 排除在基准测试之外。不建议在 CPU 上运行 nougat，因为速度非常慢。

致谢

没有这些优秀的开源模型和数据集，本工作将无法完成，包括（但不限于）：

• Surya
• Texify
• Pypdfium2/pdfium
• 来自 IBM 的 DocLayNet
• 来自 Google 的 ByT5

感谢这些模型和数据集的作者将它们提供给社区！