Datalab 发布了 Marker v2，这是对其开源文档转换管道的全面重写。Marker 可将 PDF、图片、PPTX、DOCX、XLSX、HTML 和 EPUB 文件转换为 markdown、JSON、HTML 或分块格式——这些输出格式可直接作为检索增强生成（RAG）系统、LLM 训练数据准备以及企业知识管道的输入，其中解析保真度直接决定下游模型性能。Datalab 团队围绕近几个月发布的三个组件重构了该工具：Surya OCR 2、一个 2000 万参数的快速布局模型，以及比上一版本快 3 倍的重建版 pdftext 引擎。

基准测试的核心结果来自 olmOCR-bench，这是由 Allen AI（Ai2）创建的第三方基准测试。Marker v2 的均衡模式总体得分 76.0%，在原生数字 PDF 上得分 83.5%，在单块 B200 GPU 上可维持每秒 2.9 页的处理速度。这一吞吐量是 MinerU 管道后端的 5 倍以上——后者以每秒 0.54 页的速度得分 72.7%。Docling 在同一测试框架下以每秒 2.1 页的速度得分 50.3%。

Marker v2 的新特性

Marker v2 引入了三种转换模式：

• 均衡模式（balanced） — 由 Surya VLM 处理布局，当嵌入文本质量较差时触发整页重新 OCR。这是最高质量的模式，针对 GPU 优化。在 olmOCR-bench 上得分 76.0%。
• 快速模式（fast） — 轻量级 rf-detr/onnx 布局检测器结合 pdftext，使用最少且有针对性的 VLM 调用。得分 66.6%，成本大幅降低。
• –disable_ocr — 纯文本层提取，完全不调用 VLM。完全在 CPU 上运行。得分 43.6%，速度 23.7 页/秒。

模式选择现在默认具有设备感知能力：GPU 上使用均衡模式，CPU/MPS 上使用快速模式，可通过 –mode 手动覆盖。完整的 CPU 支持是第二个结构性变化——快速模式加 –disable_ocr 无需 GPU 也无需推理服务器，但 2000 万参数的布局模型仍然可以在 CPU 上解析列、表格和标题。

第三个架构变化是实现高吞吐量的关键。多个轻量级 CPU 工作进程共享一个 Surya 推理服务器，父进程在它们之间管理 VLM 并发。因此，吞吐量随服务器容量扩展，而非受限于单进程的 VRAM。Datalab 报告称，在同一硬件上，均衡模式以约 2.9 页/秒的速度持续运行，而单流速度约为 0.3 页/秒。

升级前需注意几个破坏性变更。现在要求 Python 3.10+。打包方式从 Poetry 迁移到 uv，构建后端使用 hatchling，不过 pip install marker-pdf 保持不变。结构化提取转换器和提取器已被移除；Datalab 指导用户使用托管 API 或 –use_llm 工作流作为替代。

基准测试方法论

评分基准测试使用 Ai2 的 olmOCR-bench，包含 1,403 份 PDF，约有 8,400 个通过/失败单元测试，覆盖数学公式渲染、表格结构、阅读顺序、页眉页脚和旧扫描件。总体得分是 8 个类别的宏观平均值，使用官方 olmOCR-bench 检查器计算。吞吐量数据表示在单台 B200 主机上持续并发的每秒页数，而非单流延迟。

关于数据来源：虽然 olmOCR-bench 是 Ai2 的第三方基准测试，但所有得分和吞吐量数据均来自 Datalab 自己的测试运行。所有结果均可通过 Marker 仓库中的开放测试框架复现，该框架包含 MinerU、Docling 和 LiteParse 的竞争者运行器以及 Marker 自己的运行器。这些数字反映的是单个基准测试的文档混合在单一硬件配置上的表现，因此在不同语料库上的结果可能有所不同。评估团队应针对自己的文档集运行该框架以获得有意义的比较结果。

Marker v2 对比 MinerU

MinerU 的管道后端在架构上最为接近，因为两者都读取 PDF 文本层并选择性应用 OCR。在总分方面，Marker 均衡模式以 76.0 对 72.7 领先。在原生数字文档上，两者基本持平：83.5 对 83.3。

显著的差异在于吞吐量。Marker 均衡模式以 2.9 页/秒持续运行，而 MinerU 为 0.54 页/秒——在更高准确率的条件下差距达 5.4 倍。Marker 快速模式以 7.4 页/秒持续运行，约为 MinerU 管道速率的 13.7 倍，但得分比 MinerU 低 6.1 分。

MinerU 还提供 VLM 后端，Datalab 指出其得分高于管道后端。该后端采用全页 VLM 方法，未包含在此比较表中。评估 MinerU 的团队应单独对该选项进行基准测试。

Marker v2 对比 Docling

Docling 在 GPU 管道中表现出最大的性能差距。Marker 均衡模式在总分上以 76.0 对 50.3 领先，在原生数字文档上以 83.5 对 64.0 领先，同时运行速度更快：2.9 页/秒对 2.1 页/秒。Datalab 指出，Docling 使用其默认管道进行评估，该管道在原生数字页面上使用文本层，在图像区域使用 OCR。

Docling 的优势在于治理和格式广度，而非原始准确率。其代码库采用 MIT 许可证，起源于 IBM Research，并作为 LF AI & Data Foundation 的项目托管。其支持的输入格式不仅限于文档，还扩展到音频和电子邮件。

Marker v2 对比 LiteParse

LiteParse 由 LlamaIndex 团队开发，是一个基于 Rust 的文档解析器，其运作方式与 Marker 在根本不同的维度上。在 CPU 上，它总分得分 22.4，关闭 OCR 时得分 20.4，而 Marker 仅 CPU 模式得分为 43.6。然而，LiteParse 关闭 OCR 时报告 1721 页/秒——约为 Marker CPU 模式吞吐量的 73 倍，这代表了一种以速度换取结构化的明确取舍。

Marker 的快速模式加 –disable_ocr 在 CPU 上运行 2000 万参数的布局模型，仍然能够恢复文档结构，这解释了为什么它的得分超过纯文本导出的两倍以上。LiteParse 缺乏布局模型，在非线性文档布局上表现不佳。

Marker v2 对比全页 VLM 级别

Datalab 团队强调，Marker 设计为管道而非 VLM，指出这是两类截然不同的工具。这种区别具有实际意义：全页 VLM 通过大型模型端到端处理每个文档图像，实现更高的准确率，但每页的计算或 API 成本会随着规模累积。像 Marker 这样的管道将任务分解为成本更低的专用阶段，以牺牲峰值准确率换取吞吐量和成本控制。在本次评估中，Datalab 的托管版 Chandra 2 得分 85.8，而通过 API 调用的 Gemini Flash 3.5 得分 76.4。Datalab 的 Chandra 仓库还在一个单独的表格中列出 Ai2 的 olmOCR 2 为 82.4，dots.ocr 1.5 为 83.9。对于扫描件、数学密集型页面以及追求最高准确率的场景，VLM 级别仍然优于所有列出的管道。

值得注意的是，Marker 的均衡模式将差距缩小到仅落后 Gemini Flash 3.5 总分 0.4 个百分点，并且在原生数字文档上以 83.5 对 79.1 的优势超越了它——而无需按页调用 API。

分类别表现

所选模式影响的是失败特征，而不仅仅是总分。数学公式渲染是最显著的差异点：快速模式从 PDF 文本层读取公式而非使用 VLM-OCR，导致 arXiv 数学得分从 83.9 降至 23.4，而 –disable_ocr 在该类别中按设计得分为 0.0。除两个数学类别外，旧扫描件是每种模式中最弱的类别，最高仅为 43.2。

许可证

四个系统的许可证条款差异显著，这对商业团队有直接影响——特别是在文档解析经常用于受监管工作流的场景中，来源和许可证合规性是可审计的要求：

• Marker：代码采用 Apache 2.0 许可证。模型权重使用修改版 AI Pubs OpenRAIL-M 许可证——对研究、个人使用以及资金/收入低于 500 万美元的初创公司免费。超过该门槛，权重的商业使用需获得付费许可。
• MinerU：现受 MinerU Open Source License 管辖，基于 Apache 2.0 并附加了额外条件。月活用户超过 1 亿或月收入超过 2000 万美元时需单独的商业许可证，且基于其构建的在线服务必须披露这一事实。
• Docling：MIT 许可证，模型许可证在其原始包中单独跟踪。
• LiteParse：开源，来自 run-llama，LlamaParse 定位为处理困难文档的付费云选项。

使用场景考量

仅凭基准测试得分无法决定正确的工具选择。语料库类型、可用硬件、许可层级和所需输出格式都是决策因素。大规模处理原生数字 PDF 的团队可能会发现顶级管道之间的准确率差异很小，而处理扫描文档、数学密集型学术论文或混合格式语料库的团队将看到更大的差异。团队应根据自己的文档集和运营约束评估每个解析器。

所有基准测试和吞吐量数据均附带 Marker 仓库中可复现的 benchmarks/ 测试框架。

关键参考链接

• Marker v2 GitHub 发布页面
• Datalab Marker v2 博客文章
• X 上的发布公告
• olmOCR-bench 仓库（Ai2）

来源：MarkTechPost