MinerU vs Docling vs Marker：开源文档解析工具深度对比

1. 核心定位与技术路线差异

1.1 产品定位总览

1.1.1 MinerU：高精度中文文档解析专家

MinerU 由上海人工智能实验室（OpenDataLab）主导开发，其核心定位是高精度中文文档解析专家，专门针对复杂版面的学术文献、技术报告、财务报表等场景进行深度优化。该工具诞生于 InternLM 大语言模型的预训练数据清洗需求，因此在中文语料的理解和结构化提取上具有天然优势 。MinerU 的技术路线明确指向"理解PDF布局+识别内容+重建语义"的三步闭环，而非简单的OCR文字提取，其设计哲学强调"结果导向"——用户无需深入理解底层模型架构，即可获得可直接导入 Obsidian、Typora 或 Jupyter 的干净 Markdown 文件 。

从产品形态来看，MinerU 已形成完整的商业化矩阵：Web UI 在线服务（mineru.net）、桌面客户端、命令行工具、API 服务以及多语言 SDK（Python/.NET/JavaScript/TypeScript），覆盖从个人开发者到企业级私有化部署的全谱系需求 。其 GitHub Stars 已突破 62,000，月下载量超过 50,000 次，社区活跃度极高 。MinerU 的自动过滤页眉页脚能力在同类工具中表现突出，这对于中文学术论文中常见的页眉机构名称、页脚页码等干扰信息的清除尤为关键 。然而，这种高度集成的设计也带来了灵活性代价：当用户需要替换特定OCR引擎或调整版面分析策略时，MinerU 的模块化程度不如 Docling 开放 。

1.1.2 Docling：IBM生态驱动的企业级多格式流水线

Docling 由 IBM 苏黎世研究院的 AI for Knowledge 团队开发，现为 Linux Foundation AI & Data Foundation 托管项目，其定位是企业级多格式文档处理平台，核心解决的是多格式文档统一处理与 AI 生态系统深度集成的问题 。与 MinerU 专注 PDF 深度解析不同，Docling 的设计目标是构建一个通用的、可扩展的文档处理流水线，支持 PDF、DOCX、PPTX、XLSX、HTML、Markdown、LaTeX、JATS 学术文章、USPTO 专利、XBRL 财务报告，甚至包括图片、音频、视频等富媒体格式 。这种"一站式"能力使其在企业文档管理系统、多格式转换服务等场景中具有独特价值。

Docling 的企业级特性体现在其与 IBM Cloud、Red Hat OpenShift 的深度集成能力，以及对 Docling Document 这一统一文档中间格式的定义——该格式支持后续的格式互转和语义操作 。其 MIT License 的宽松授权也降低了企业集成的法律门槛 。然而，正如社区反馈所指出的，Docling 的"广"有时伴随着"精"的妥协——在特定高难度任务（如复杂公式识别、扫描件 OCR）上，其表现往往不及专门优化的竞争对手 。Docling 的中文支持被明确标注为"实验性"阶段，IBM 官方承认其多语言功能"尚未经过企业级性能或稳定性的验证" 。

1.1.3 Marker：轻量化快速PDF转Markdown工具

Marker 由个人开发者 Vik Paruchuri 创建，后获得 EndlessAI 商业支持，其定位是轻量、快速的 PDF 转 Markdown 工具，核心优势在于处理速度和部署灵活性 。Marker 的技术架构基于 PyMuPDF 和 Tesseract OCR，支持 GPU 加速（Surya OCR 引擎），整体架构轻量且易于本地部署 。其设计哲学强调"按需调用模型"——在非 LLM 增强模式下仅激活必要的识别模块，从而实现极高的处理吞吐量：在 H100 GPU 批处理模式下可达 25 页/秒，单页处理约 0.6 秒 。

然而，Marker 的多语言支持存在明显短板。早期版本明确声明"不支持具有不同字符集的语言（中文、日语、韩语等）"，仅支持与英语相似的语言（西班牙语、法语、德语、俄语等）。后续版本虽通过 LLM 集成改善了部分多语言处理能力，但其底层 OCR 引擎（Tesseract/Surya）对中文等复杂字符集的原生支持仍弱于 MinerU 和 Docling 。Marker 的许可证模式也值得关注——其采用 GPL 代码 + Open RAIL-M 模型权重，商业使用需要额外授权，这与 Docling 的 MIT License 和 MinerU 的 Apache 2.0 衍生协议形成鲜明对比 。

维度	MinerU	Docling	Marker
主导组织	上海AI Lab (OpenDataLab)	IBM → Linux Foundation	个人开发者 → EndlessAI
核心定位	高精度中文文档深度解析	企业级多格式文档流水线	轻量快速PDF转Markdown
目标用户	学术研究者、金融分析师、RAG开发者	企业IT部门、算法工程师	个人开发者、小型项目快速原型
设计哲学	开箱即用、体验优先、精度至上	模块化可定制、控制优先、生态集成	极简部署、速度优先、成本敏感
GitHub Stars	~62,000	~37,000	~18,000（估算）
开源协议	Apache 2.0衍生（商用友好）	MIT（无限制商用）	GPL + Open RAIL-M（商用受限）

1.2 技术架构哲学对比

1.2.1 MinerU：VLM+专用模型组合的多阶段流水线

MinerU 的技术架构体现了**"分而治之"的工程哲学**，将文档解析任务分解为多个专业化子任务，每个任务由针对性优化的模型负责。其核心组件包括：（1）版面检测：基于 LayoutLMv3-base-chinese 和 YOLOv8 的联合检测，识别页面中的文本块、图像、表格、公式等区域，定位准确率达到 98.7%；（2）OCR引擎：基于 PaddleOCR 中文优化版，支持 109 种语言识别，针对中文笔画复杂性、字体多样性进行了专门设计；（3）公式识别：UniMERNet 专用模型，在复杂印刷公式（CPE）、手写公式（HWE）、屏幕公式（SPE）等场景达到 96.6%-99.2% 的 CDM 准确率；（4）表格识别：StructEqTable（基于 InternVL2-1B，支持 HTML/LaTeX/MarkDown 输出）或 TableMaster 可选，前者精度高，后者速度快 。

MinerU 2.5 版本引入了VLM后端作为可选方案，采用 NaViT-675M 视觉编码器 + Qwen2-0.5B 语言模型的组合，总参数量 1.2B，通过"粗到细"的两阶段策略——先在降采样图像上进行全局布局分析，再在原始分辨率裁剪上进行局部内容识别——实现了精度与效率的平衡 。同时保留的 Pipeline后端 采用经典的模块化设计，集成 7 个以上专用模型组成完整流水线，适合对精度要求极致的场景 。这种双引擎设计允许用户根据精度需求、硬件条件和延迟要求灵活选择：Pipeline 后端精度更高但速度较慢，VLM 后端速度更快但在极端复杂场景可能牺牲部分精度 。

MinerU 的硬件部署策略体现了灵活性：支持纯 CPU 环境运行，同时支持 GPU（CUDA）、NPU（CANN，华为昇腾等 10+ 种国产芯片）和 MPS（Apple Silicon）加速，兼容 Windows、Linux 和 Mac 三大平台 。然而，多模型组合架构的代价是系统复杂度较高，首次部署需要下载超过 5GB 的模型权重，CUDA 环境配置可能遇到版本冲突问题 。

1.2.2 Docling：IBM自研轻量VLM端到端架构

Docling 的技术架构经历了从传统流水线到 VLM 增强的演进。早期版本（2024 年 7 月开源）采用纯模块化设计：布局分析基于 DocLayNet 数据集训练的专用模型（81,000+ 人工标注页面），表格结构识别采用 TableFormer（训练于 100 万+ 科学和金融表格），OCR 则通过插件化方式集成 Tesseract/EasyOCR/RapidOCR 等引擎 。这种设计的核心理念是**“避免传统OCR”**——对于数字原生 PDF，Docling 直接提取文本流而非逐页图像识别，宣称比传统 OCR 快 30 倍 。

2025 年 9 月发布的 Granite-Docling-258M 标志着架构升级。这是一个 258M 参数的端到端 VLM，采用 Apache 2.0 许可证，专为文档理解优化 。该模型在英文语料上训练，但扩展了实验性多语言能力（阿拉伯语、中文、日语）。IBM 的研究表明，这种轻量 VLM 在保持速度优势的同时，显著提升了复杂版式的理解能力 。Docling 的架构哲学强调**“可编程性”**——用户可替换任何组件，如使用自训练 OCR 模型替代默认引擎，或接入自定义布局分析模型 。

Docling 的部署架构同样体现企业级思维：支持本地、云端、混合、气隙四种处理模式；容器镜像从 4.4GB（CPU 版）到 11.4GB（CUDA 版）；通过 OpenShift Operator 实现 Kubernetes 集群的大规模部署 。其 v1 API 于 2026 年 1 月达到稳定状态，承诺向后兼容性。与 MinerU 的"配置即代码"不同，Docling 提供更底层的 Python API，允许细粒度控制每个处理阶段 。

1.2.3 Marker：LLM/VLM端到端生成路线

Marker 的技术架构最为简洁，核心依赖两个组件：PyMuPDF 负责 PDF 渲染和基础文本提取，Tesseract/Surya 负责 OCR 识别。其设计哲学是**“最小可行产品”**——不做复杂的版面分析，而是通过启发式规则（如字体大小变化检测标题、空白行分隔段落）重建 Markdown 结构 。这种架构在简单单栏文档上效率极高，但面对复杂版式时容易失效。

Marker 的"端到端"特性体现在其直接输出 Markdown 的单一目标，不像 MinerU 和 Docling 那样提供丰富的中间表示和多种输出格式。2024 年后，Marker 开始探索 VLM 增强路径，提供 --use_llm 选项调用视觉大模型进行复杂区域识别 。这种"分层决策"机制在效率与精度之间提供了灵活的权衡空间：默认使用传统 CV/NLP 流水线保证速度和确定性，当遇到复杂表格、跨页表格、行内数学公式、手写内容等难点时，启用 LLM 增强处理 。

然而，Marker 的架构深度较浅，缺乏 MinerU 式的多模型融合和 Docling 式的模块化替换能力。其精度上限更多依赖 LLM 增强选项，而 LLM 调用又带来额外的成本和延迟 。在中文场景，Marker 的底层 OCR 引擎（Tesseract/Surya）对中文的优化程度有限，且早期版本明确排除中文支持，这使其在技术架构层面就存在中文处理的先天不足 。

架构维度	MinerU	Docling	Marker
核心路线	VLM+专用模型多阶段组合	模块化流水线 + 可选轻量VLM	PyMuPDF+OCR + 可选LLM增强
版面检测	LayoutLMv3 + YOLOv8（98.7% mAP）	DocLayNet / RT-DETR（93.1% mAP）	无专门模块，依赖PyMuPDF
OCR引擎	PaddleOCR中文优化版	Tesseract/EasyOCR/RapidOCR（可替换）	Tesseract / Surya OCR
公式识别	UniMERNet专用模型（CDM 97.29）	基础支持，需第三方集成	无专门优化，LLM增强可选
表格识别	StructEqTable / TableMaster	TableFormer	基础提取，LLM增强可选
核心模型规模	~1.2B参数（VLM后端）	~258M参数（Granite-Docling）	无单一模型，轻量组件
推理模式	Pipeline / VLM / Hybrid 三后端	流水线为主，VLM可选插入	基础模式 + LLM增强模式

2. 中文支持能力（核心维度）

2.1 中文OCR引擎对比

2.1.1 MinerU：PaddleOCR中文优化版，109种语言覆盖

MinerU 的中文 OCR 能力建立在 PaddleOCR 的深度优化版本之上，这是其区别于其他工具的核心技术壁垒。PaddleOCR 由百度飞桨团队开发，针对中文场景进行了大量专项训练：支持简体中文（GB2312/GBK/GB18030）、繁体中文（Big5）、竖排文档以及中英文混排场景；对宋体、黑体、楷体、仿宋等主流印刷字体，以及部分手写体、艺术字体具有良好适应性 。MinerU 在此基础上进一步扩展了多语言支持，官方宣称覆盖 109 种语言，涵盖主流拉丁语系、西里尔语系、阿拉伯语系以及东亚 CJK 文字 。

在 OmniDocBench v1.6 的权威评测中，MinerU2.5-Pro 的中文文本字符识别准确率达到 98.1%（整体）/ 95.2%（难样本），编辑距离仅为 0.019 。这一成绩的具体含义是：在元素级评估（排除版面检测误差干扰）中，平均每 1000 个字符约有 19 个字符级误差；在包含版面误差的 Hard 端到端场景下，字符识别准确率仍维持在 95.2% 。对于中文场景而言，这一指标尤为关键——中文字符的"字"单位识别错误可能带来较大语义偏差，因此高字符准确率是保障后续 NLP 任务质量的基础。

MinerU 的中文 OCR 优势还体现在对复杂字体的处理上。通过大规模预训练和困难样本微调，在 Hard 子集（困难样本）上仍能保持 95.2% 的等效字符准确率，Base→Hard 掉分仅为 -2.04 分，稳定性领先于同类模型 。这种稳定性对于企业级应用至关重要，意味着 MinerU 在面对质量参差不齐的真实文档时，能够保持可预期的性能表现。此外，MinerU 的 OCR 模块支持 GPU 加速（CUDA/NPU）和 CPU 降级运行，可根据硬件条件动态调整精度-速度权衡 。

2.1.2 Docling：内置OCR中文性能有限，需自行集成开源模型

Docling 的中文 OCR 能力呈现**“框架完备、模型待补”**的特点。其内置 OCR 能力主要依赖 Tesseract、EasyOCR、RapidOCR 等多引擎集成，这一设计在通用多语言支持上具有灵活性，但在中文专项优化上存在明显短板 。关键问题在于，Docling 默认下载的 OCR 模型仅包含英文，中文简体模型（zh_sim_g2.pth）需要用户手动下载并配置，这增加了中文用户的初始使用门槛 。

社区已有开发者整理了 Docling 的中文模型包并分享下载链接，但官方尚未将中文模型纳入默认分发 。在实际测试中，Docling 处理中文 PDF 时容易出现字符识别错误、排版错乱等问题，特别是在处理竖排文本、繁体字、手写体等复杂场景时，其表现与 MinerU 存在显著差距 。Docling 的模块化设计允许用户替换 OCR 引擎，这是其应对中文场景的核心策略——通过 PdfPipelineOptions 配置，用户可以将 EasyOCR 替换为 PaddleOCR、RapidOCR 或 Tesseract 等更擅长中文的引擎 。然而，这种替换需要用户具备一定的技术能力，包括模型下载路径配置、语言参数设置（如 easyocr_options.lang = ['ch_sim','en']）、以及可能的版本兼容性调试 。

IBM 在 Granite-Docling-258M 中宣称提供对中文的"实验性支持"，但明确标注"尚未达到企业级稳定水准"，这反映了 IBM 对中文市场重视但技术积累仍需时间的现状 。对于需要开箱即用中文支持的企业用户，Docling 当前的状态可能需要额外的集成投入。

2.1.3 Marker：Tesseract基础支持，中文等亚洲语言效果一般

Marker 的中文 OCR 支持是其最明显的短板。早期版本（2024 年 6 月）明确声明：“只支持与英语相似的语言（西班牙语、法语、德语、俄语等）。不支持具有不同字符集的语言（中文、日语、韩语等）”。这一限制源于其底层 OCR 引擎的选择：基础版本依赖 Tesseract OCR，该引擎虽然支持 100+ 种语言，但中文训练数据较旧，对现代中文字体、复杂排版的识别效果不佳；GPU 加速版本使用 Surya OCR，该引擎在多语言支持方面有所改进，但中文优化程度仍不及 PaddleOCR 。

社区对 Marker 中文支持的反馈证实了这一问题。GitHub Issue #29 中用户直接询问"可以支持中文汉化吗"，反映了中文用户的迫切需求 。尽管后续版本可能通过 LLM 集成间接改善了部分中文处理能力（LLM 本身具备多语言理解能力），但这种"绕路"方案存在明显局限：LLM 对中文文档的解析依赖于 OCR 层首先正确提取字符，如果 OCR 层将中文误识别为乱码或漏检，LLM 也难以凭空恢复 。此外，Marker 的 LLM 增强选项需要调用外部 API（如 OpenAI、Anthropic 等），这不仅带来额外成本，还涉及中文数据出境的合规风险，对国内用户尤为敏感 。综合来看，Marker 在中文 OCR 方面与 MinerU 和 Docling 存在代际差距，不建议作为中文文档解析的首选工具。

中文OCR维度	MinerU	Docling	Marker
核心引擎	PaddleOCR中文优化版	Tesseract/EasyOCR/RapidOCR（可替换）	Tesseract / Surya OCR
简体中文	优秀（98.1%字符准确率）	需自行集成优化	一般（92%估算）
繁体中文	良好（专门语言代码）	依赖集成引擎	有限
竖排文本	支持（阅读顺序恢复）	未明确支持	不支持
中英混排	优秀（专项优化）	一般（集成后改善）	一般（空格处理易出错）
复杂字体	良好（多字体训练覆盖）	依赖集成引擎	较弱
开箱即用程度	高（预装中文模型）	低（需手动配置）	低（中文非原生支持）

2.2 中文复杂场景处理

2.2.1 简体/繁体/竖排识别能力分级

在中文变体支持方面，三款工具呈现明显的梯度差异。MinerU 表现最优，其 PaddleOCR 基础对简体中文的识别准确率高，且针对中文常见场景如横排正文、表格文字、图注等进行了专门优化 。繁体中文支持方面，MinerU 明确将 chinese_cht（繁体中文）列为独立支持语言，但社区反馈显示其繁体竖排支持"有一定检测和处理机制，但支持有限"。具体表现为：MinerU 能自动检测竖排文本块并尝试按"自上而下、从右到左"顺序合并排序，但在多栏竖排场景下常将相邻竖列误判为同一区块，导致文字顺序错乱 。这一问题在古籍数字化场景中尤为突出，用户反馈"竖排的古汉语，识别总是出错"，“MinerU 知道是从右往左的排列，但是常把两列看作一个整体”。

Docling 的繁体支持依赖于所选 OCR 引擎，EasyOCR 的繁体模型质量一般，替换为 PaddleOCR 后可改善。但其架构层面缺乏对竖排文本阅读顺序恢复的专门设计，默认配置下主要优化现代横排文档 。Marker 未声明繁体支持，Tesseract 的繁体训练数据陈旧，对现代印刷体、屏幕截图的识别效果不稳定，竖排文本更是超出其处理能力范围 。

竖排识别是中文文档解析的终极挑战，目前三款工具均未达到生产级水准。MinerU 2.5-Pro 的技术报告 Appendix D 提供了竖排文本的定性对比图，承认这是"已覆盖、但未达到最优"的能力——识别可用，但大规模古籍数字化仍需人工抽检 。这一现状反映了竖排排版在深度学习时代的特殊困难：现代文档 AI 的训练数据以横排为主，竖排样本稀缺；竖排的"从右到左、从上到下"阅读顺序与横排模型假设冲突；古籍的繁体字、异体字、缺笔避讳等进一步增加了识别难度。

2.2.2 中英混排与复杂字体鲁棒性

中英混排是中文技术文档、学术论文、商业报告的典型场景，对 OCR 引擎的字体切换和语言检测能力提出挑战。MinerU 在此场景下展现了卓越的鲁棒性：其多语言 OCR 引擎能够自动检测语言边界，在 OmniDocBench 的中文上下文公式子集上取得 CDM 95.28 分，证明了其在"中文段落中嵌入英文公式"这一典型混排场景下的精准识别能力 。MinerU 的字体支持范围涵盖宋体、黑体、楷体、仿宋、圆体等主流中文字体，以及 Times New Roman、Arial 等西文字体的混排组合，在财务报告中常见的"中文标题+英文数据表格"版式中表现稳定 。

Docling 的中英混排处理能力更多依赖其布局分析模块的文本块分割精度。DocLayNet 模型在检测文本区域时能够区分不同语言区块，但 OCR 阶段的语言识别准确性受限于所选引擎的能力。社区反馈显示，Docling 在处理"中文为主、英文为辅"的文档时表现尚可，但在"密集混排"（如每行多次语言切换）和"专业术语混排"（如中文论文中的英文文献引用）场景下错误率上升 。Marker 的中英混排表现与其 OCR 引擎的语言切换机制直接相关，Tesseract 的多语言模式需要明确指定语言列表，且语言间切换的边界检测不够精细，常见错误包括英文单词间空格丢失、中文字符间距不均等 。

复杂字体方面，中文的书法字体、艺术字体、古籍刻本字体对 OCR 构成严峻挑战。MinerU 的 PaddleOCR 通过大量合成数据和真实数据训练，对常见复杂字体有一定覆盖，但极端情况（如狂草、严重磨损的碑刻拓片）仍可能失败。Docling 的字体支持完全取决于所选 OCR 引擎，EasyOCR 的字体覆盖较窄，PaddleOCR 替换后可改善。Marker 的 Tesseract 对复杂中文字体的支持最弱，这是其架构层面的固有局限。

2.2.3 中文论文、教材、财报等垂直场景实测表现

垂直场景实测是检验工具真实能力的最终标准。在中文学术论文场景，MinerU 展现出明显优势。实测对比显示，MinerU 对 Nature、Science 式双栏格式的多栏还原准确率达 98.2%，公式语义保真度 94.7%（输出 LaTeX 可直接编译），表格结构完整性 96.3%（能还原合并单元格、跨页表头），均显著高于 Docling 的 86.5%、89.1% 和 91.8%。Docling 的优势在于模块化可调试，当 MinerU 在某篇论文的特定公式上失败时，可以单独替换 Docling 的公式识别模块进行优化，但这种"组合使用"方案增加了工程复杂度 。Marker 在该场景表现较弱，复杂公式识别精度一般，表格转换易错位 。

在中文教材场景，MinerU 的标题层级识别、列表保留、图文关联能力使其输出可直接用于知识库构建。Docling 的格式互转能力则有助于将已有 Word 版教材快速转为 Markdown。Marker 因缺乏中文支持基本不适用 。

在中文财报场景，MinerU 的表格识别优势突出，其 StructEqTable 模型对复杂表头、合并单元格的保留能力在中文表格基准 TED-Struct 上获得满分 1.000 。Docling 的 TableFormer 在 GPU 上平均每个表格耗时 400ms，但复杂表格可能需要更长时间 。Marker 的表格处理被评价为"易错位"，LLM 优化后有所改善但基础能力仍弱 。

中文垂直场景	MinerU	Docling	Marker
学术论文	优秀（多栏98.2%，公式94.7%）	良好（需调试优化）	较弱（公式精度不足）
教材	优秀（结构完整保留）	可用（Word转Markdown便利）	不适用
财报	优秀（表格结构96.3%）	一般（复杂表头易错）	弱（表格错位）
古籍/竖排	有限支持（需人工抽检）	不支持	不支持

2.3 国内部署与合规

2.3.1 MinerU：国内节点与数据不出域支持

MinerU 作为国内团队（上海人工智能实验室/OpenDataLab）开发的开源工具，在数据主权与合规性方面具有天然优势。其开源版本支持完全私有化部署，所有模型和代码均可下载到本地服务器运行，无需调用任何外部 API，满足金融、政府、医疗等对数据不出域有严格要求的场景 。MinerU 还提供在线 Demo 和 API 内测服务，但用户可自主选择是否使用云服务，核心功能不依赖云端 。

对于需要国内节点的企业用户，MinerU 的国内开发背景意味着更贴近本土合规要求（如网络安全法、数据安全法、个人信息保护法），社区支持和技术文档也以中文为主，降低了国内团队的沟通成本 。MinerU 的 Docker 部署镜像特别集成了 fonts-noto-cjk 字体包以确保中文渲染质量，这一细节体现了其对中文场景的重视程度 。此外，MinerU 提供官方 API 服务（mineru.net），服务器部署于国内，符合数据不出域的合规要求，同时提供 JS/TS SDK（mineru-open-sdk）方便前端应用直接集成 。

2.3.2 Docling：IBM云生态，本地化部署可行

Docling 作为 IBM 开源项目，其默认部署模式偏向国际化，但本地化部署完全可行。所有模型可通过 docling-tools models download 命令预取到本地，支持离线环境运行 。Docling 的 MIT 许可证允许自由商用和修改，无 GPL 的传染性限制，企业可将其集成到自有产品中而无需开源衍生代码 。然而，Docling 的 IBM 背景也意味着其云服务（如 IBM watsonx.ai 集成）主要面向国际市场，国内用户如需云端服务可能需要考虑网络延迟和合规问题 。

对于纯本地化部署场景，Docling 与 MinerU 在数据主权方面处于同等水平，但 Docling 的中文模型配置需要额外注意（如手动下载中文 OCR 模型）。Docling 与 Red Hat AI、OpenShift 的集成提供了企业级部署路径，但主要面向已有 IBM 生态的客户；对于纯内网部署、追求完全自主可控的国内机构，Docling 的"IBM 品牌背书"反而可能成为供应商锁定担忧的来源 。

2.3.3 Marker：纯开源方案，无官方云服务

Marker 的部署模式最为简单直接：纯开源、纯本地、无官方云服务。这既是优势也是劣势：优势在于完全自主可控，无供应商锁定风险，无数据出境合规顾虑；劣势在于缺乏官方托管服务，用户需自行解决硬件、运维、模型更新等问题 。Marker 的 GPL/研究许可证对商用构成限制，商业使用需要联系 DataLab 获取授权，这在国内企业合规审查中可能引发额外流程 。

对于中文用户，Marker 的另一隐性成本是 LLM 增强选项通常需要调用国际 API 服务商（如 OpenAI），这直接触及数据出境合规红线，除非使用国内 LLM 替代，但集成工作量较大 。综合来看，Marker 在中文部署与合规方面与 MinerU 和 Docling 存在明显差距，不适合对数据主权和合规有严格要求的企业场景。

国内部署与合规	MinerU	Docling	Marker
数据不出域	原生支持（完全本地运行）	可行（需自行配置）	原生支持（纯本地）
国内节点/镜像	有（官方镜像+CDN加速）	无（需国际访问或镜像）	无
国产硬件适配	10+种NPU（昇腾、寒武纪等）	通用PyTorch后端	通用PyTorch后端
合规认证	适配国内监管要求	需自行评估	无官方认证
商用许可证	Apache 2.0衍生（宽松）	MIT（最宽松）	GPL+Open RAIL-M（受限）

3. 解析精度硬指标

3.1 权威基准测试表现

3.1.1 OmniDocBench v1.6综合得分对比

OmniDocBench 是当前文档解析领域最具权威性的公开基准之一，其 v1.6 版本涵盖了综合准确率、文字识别、公式识别、表格识别等多个分项，覆盖 9 种 PDF 页面类型（书籍、幻灯片、财报、教材、试卷、杂志、学术论文、笔记、报纸），从文本、公式、表格、阅读顺序四个维度评估 。在该基准的最新评测中，三款工具的表现呈现显著分化：

MinerU2.5-Pro 以 综合得分 95.69 的优异成绩位居开源工具首位，在 15 个专用模型和 6 个通用 VLM 中排名第一 。其分项表现同样亮眼：文本编辑距离（越低越好）仅 0.019，对应字符准确率约 98.1%；公式识别 CDM（Character Detection Metric）达到 97.29，在 9 个基准子集中 5 个排名第一；表格 TEDS（Tree-Edit-Distance-based Similarity）达到 93.42，TEDS-S（结构相似度）95.92；阅读顺序编辑距离仅 0.120，意味着阅读顺序错乱问题基本可忽略 。这些硬指标反映了 MinerU 在学术文献场景的深度优化成果，其多模型融合架构在公式和表格这两个"杀手级"能力上投入了大量研发资源。

Docling 在 OmniDocBench 上的公开得分较少，但从其技术论文和社区评测可以推断其表现处于中上水平。Docling 的架构设计更侧重通用性和可扩展性，而非在特定基准上追求极限分数，这导致其在某些专项上可能不及 MinerU，但整体稳定性较好 。IBM 推出的 docling-eval 评测套件和数据集规划，表明 Docling 团队正在建立标准化评估体系，未来将有更多公开对比数据 。

Marker 在 OmniDocBench 上的官方数据缺失，社区评测反馈其"复杂公式识别精度一般"，“表格转换易错位”。Marker 的自我定位更偏向"快速、通用"而非"高精度、专项"，其基准测试更多关注处理速度（如"比 nougat 快 10 倍"）而非解析准确率 。对于需要量化精度指标的企业选型，Marker 的数据透明度不足。

OmniDocBench v1.6 分项对比	MinerU 2.5-Pro	行业对比
综合总分	95.69	排名第1
文本编辑距离↓	0.019	最优
公式CDM↑	97.29	9子集5个第1
表格TEDS↑	93.42	5公开基准第1
表格TEDS-S↑	95.92	最优
阅读顺序编辑距离↓	0.120	显著最优
中文公式CDM↑	95.28	远超通用VLM

3.1.2 Docling分项得分与差距分析

虽然 Docling 缺乏 OmniDocBench 的直接高分记录，但从实战对比数据可以推断其性能水平。在 5 篇真实学术论文的横向评测中（涵盖计算机、物理、生物、数学领域），Docling v0.4.2 的多栏还原准确率 86.5%、公式语义保真度 89.1%、表格结构完整性 91.8%，均显著低于 MinerU 2.5-1.2B 的对应指标 。这种差距在复杂元素（公式、表格）上尤为明显，反映了 Docling 在专用模型优化方面的不足。

Docling 的劣势部分源于其轻量模型设计。SmolDocling-256（256M 参数）和 Granite-Docling-258M（258M 参数）的参数量仅为 MinerU 1.2B 的五分之一左右 ，这种轻量设计虽然带来了部署灵活性，但也限制了模型的表达能力。在公式识别这种需要精细视觉理解的任务上，Docling 的"基础支持"定位使其难以与 MinerU 的 UniMERNet 专用模型竞争 。

然而，Docling 在特定场景也有相对优势。其 CPU 模式可用性优于 MinerU——MinerU CPU 版内存占用高，大 PDF 易 OOM，而 Docling 各模块可独立降级，在资源受限环境下更为流畅 。这种权衡体现了"精度优先"与"效率优先"架构哲学的本质差异。

3.1.3 Marker基准测试数据缺失与社区反馈

Marker 在权威基准测试中的参与度明显低于 MinerU 和 Docling。其官方 GitHub 仓库提供了与 Llamaparse、Mathpix 等云服务的对比数据，声称"benchmarks favorably"，但未提供与 MinerU、Docling 的直接对比 。社区实测反馈填补了部分空白：在 500 页大文档处理中，Marker 完成 2% 耗时近 2 小时（1.6-30 秒/页），用户质疑其性能优化空间 ；在公式识别方面，社区用户明确反馈"Marker 的 LaTeX 解析没有那么好，太复杂的会无法解析"。

Marker 的基准测试缺失与其产品定位密切相关——作为轻量化工具，其开发资源集中于功能迭代而非学术评测，用户群体更多是"快速转换"需求者而非"精度最大化"追求者。然而，这种"评测缺席"也导致了技术选型的信息不对称：企业用户在评估 Marker 时缺乏客观数据支撑，更多依赖社区口碑和自行测试。Marker 提供的 --use_llm 模式虽可通过 Gemini 等 LLM 提升复杂场景精度，但这引入了外部依赖和额外成本，其基准测试中的"混合模式"数据（Marker+LLM vs 单独 Marker vs 单独 Gemini）显示表格识别有显著提升，但公式识别的改进幅度未明确量化 。

3.2 复杂版式还原能力

3.2.1 多栏排版准确率：MinerU 98.2% vs Docling 86.5%

多栏排版是学术期刊、技术手册、报纸的典型特征，对解析工具的版面分析能力构成核心考验。根据 5 篇真实论文的横向评测（涵盖计算机、物理、生物、数学领域），MinerU 的多栏还原准确率达到 98.2%，显著高于 Docling 的 86.5%。MinerU 的优势在于对栏间逻辑关系的深度建模：其布局检测模型不仅识别"有几栏"，还理解"栏与栏之间的内容关联"，如左侧栏的引言与右侧栏的方法论不应简单拼接，而应保持相对独立的段落结构。Docling 的 86.5% 准确率意味着在约 13.5% 的情况下会出现栏间内容误判，典型错误是将右栏首段误判为"补充说明"或"侧边栏注释"，导致阅读顺序错乱 。

Marker 在多栏排版方面的表现缺乏量化数据，但其基于 PyMuPDF 的解析层对复杂 PDF 结构的支持有限，社区反馈其"缺乏复杂布局解析能力"。对于中文双栏论文，Marker 可能需要依赖 LLM 增强选项来修正栏间顺序，但这增加了处理时间和成本 。

3.2.2 图文混排与阅读顺序恢复

图文混排是评估文档解析工具"理解能力"的关键场景。MinerU 在该场景的表现得益于其 VLM 后端的视觉理解能力：模型能够判断"图注应紧跟图片而非分散到正文"，“多图并排时的对应关系”，“文中引用与图表的关联”。其重构后的图、表与描述性文本匹配逻辑，将描述性文本的丢失率降至接近 0 。Docling 的图文关联处理相对规则化，依赖布局检测的坐标信息判断邻近关系，在复杂场景（如图文穿插、文字环绕图片）可能出现关联错误。Marker 的图像处理被评价为"保留高质量原图"，但图文关联的语义理解较弱 。

阅读顺序恢复方面，三款工具都强调"人类可读顺序"的输出，但实现机制不同。MinerU 使用 layoutreader 进行阅读顺序排序，确保在各种排版下实现极高准确率 。Docling 通过版面分析和语义重建恢复阅读顺序，但模块间的信息传递可能引入误差。Marker 依赖 PyMuPDF 的基础排序和后期编辑模型的修正，对复杂版式的适应性最弱。

3.2.3 页眉页脚/脚注智能过滤机制差异

页眉页脚、脚注的过滤是文档解析中"看似简单、实则复杂"的环节。MinerU 在该方面投入了大量优化，其段落拼接模块在跨栏、跨页、跨图、跨表情况下均能实现良好的段落拼接效果，同时智能移除页眉、移除脚注，保持核心内容连贯 。这种"智能过滤"不是简单的坐标排除，而是结合字体大小、位置规律、内容重复度等多特征判断，甚至能识别"奇偶页不同页眉"等复杂情况。

Docling 的页眉页脚处理依赖布局检测的类别判断，将顶部/底部固定区域标记为页眉/页脚后排除，但对"首页不同"或"章节变化页眉"等动态场景适应性一般。Marker 的过滤机制相对简单，主要依赖规则匹配，对复杂文档的干扰元素去除不够彻底 。

复杂版式还原能力	MinerU	Docling	Marker
多栏还原准确率	98.2%	86.5%	未公开，预期较低
图文混排-图片定位	100%	92.4%（偶有错乱）	保留原图，关联弱
阅读顺序恢复	编辑距离0.120（最优）	良好	基础，复杂场景弱
页眉页脚过滤	智能多特征融合	规则化，动态场景一般	简单规则，不彻底

3.3 扫描件与长文档稳定性

3.3.1 低质量扫描、倾斜、噪声、手写体OCR鲁棒性

扫描件处理是 OCR 能力的试金石。MinerU 在该场景的表现呈现"部分优化、部分待完善"的特点。其 PaddleOCR 基础对模糊、水印等复杂场景有一定鲁棒性，团队明确标注"倾斜和模糊场景未作为专项优化目标"，极端情况下的识别质量不能保证 。这意味着对于手持扫描、手机拍照产生的倾斜页面或低分辨率模糊图像，MinerU 可能表现不佳，用户需有预期。MinerU 2.5-Pro 的 VLM 后端在竖排场景下保持了"可用的识别准确率"，但同样未达到最优 。

Docling 的扫描件处理能力完全取决于所选 OCR 引擎。EasyOCR 对低质量扫描的鲁棒性一般，替换为 PaddleOCR 或 RapidOCR 后可显著改善。Docling 的模块化优势在此体现：用户可以为扫描件场景专门配置更强的 OCR 模块，而无需改动其他部分 。

Marker 的扫描件支持基于 Surya OCR，该引擎对数字 PDF 效果最佳，“针对速度进行了优化，并且使用有限的 OCR 来纠正错误”。这意味着 Marker 并非为扫描件场景设计，其 OCR 能力更多是"锦上添花"而非核心能力。

3.3.2 100页+大文件内存占用与内容完整性

长文档稳定性是生产环境的关键指标。MinerU 在 GPU 环境下表现优异，但 CPU 版本"内存占用高，大 PDF 易 OOM（Out of Memory）"。其 VLM 后端虽然单次推理显存需求降低（8-10GB），但长文档的逐页处理仍可能累积内存占用，需要适当的批处理策略。MinerU 的技术报告提到跨页表格合并能力，暗示其对长文档的连贯性处理有专门设计 。

Docling 的内存管理相对优秀，其模块化架构允许各组件独立降级，CPU 模式下"流畅"处理大文档 。IBM 的技术论文显示，Docling 在 x86 CPU 上处理一页平均 3.1 秒，M3 Max SoC 上 1.26 秒，内存占用可控 。Docling 的流式处理设计（逐页解析、即时输出）有助于降低长文档的峰值内存。

Marker 的长文档处理能力缺乏公开数据，其轻量架构理论上内存占用较低，但 LLM 增强选项的上下文长度限制可能成为瓶颈。

3.3.3 批量处理稳定性实测对比

批量处理稳定性涉及并发控制、错误恢复、资源管理等多个工程维度。MinerU 支持多进程并行，但表格处理速度较慢是其已知短板 。其 VLM 后端通过 vLLM/LMDeploy 加速，单页处理时间可进一步降低，但具体数值依赖于 GPU 型号和批处理大小 。Docling 的批量处理强调"模块化定制"：通过 Python API 的 PipelineOptions 精细控制处理流程，支持分页处理、批量大小调整等参数优化 。其 IBM Cloud Code Engine 的 Serverless Fleet 配置定义了 worker profile 和扩缩容限制，实现了"scale to zero when idle, scale up on demand"的成本优化 。Marker 的批量处理依赖本地多进程配置，每个工作进程占用显存约 3.5GB，用户可根据显卡容量调整并行度 ，但缺乏官方的云原生调度方案，大规模批量处理需自行集成 Celery、RQ 等任务队列，增加了工程复杂度。

扫描件与长文档稳定性	MinerU	Docling	Marker
低质量扫描鲁棒性	中等（未专项优化倾斜/模糊）	依赖集成OCR引擎	有限（Surya优化数字PDF）
手写体支持	良好（清晰手写印刷体）	依赖集成引擎	弱
100页+内存占用	GPU优，CPU易OOM	优秀（模块化降级）	轻量，但缺乏数据
批量处理稳定性	支持，表格速度瓶颈	优秀（企业级调度）	需自行搭建队列

4. 表格与公式杀手级能力

4.1 表格结构识别

4.1.1 有框/无线框/嵌套/跨页表格支持度

表格识别是文档解析的"硬骨头"，三款工具的支持度差异显著。MinerU 提供两种表格识别方案，覆盖最全面：StructEqTable 基于 InternVL2-1B 模型，支持 HTML/LaTeX/MarkDown 输出，对无线框表格、嵌套表格的识别能力强；PaddleOCR+TableMaster 方案则在有框表格上速度更快 。MinerU 2.5-Pro 特别优化了跨页表格合并，通过检测候选分割对和判断拼接方式，将分页切断的表格自动恢复为完整结构 。在中文表格基准 TED-Struct 上，MinerU 获得满分 1.000，证明其在亚洲语言表格识别上的领先地位 。

Docling 的表格识别依赖 TableFormer 模型，提供 fast 和 accurate 两种风味。在 L4 GPU 上，TableFormer（fast）平均每个表格耗时 400ms，x86 CPU 上 1.74 秒，M3 Max SoC 上 704ms 。Docling 的表格输出保留结构信息，但社区评测显示其"常把表头识别为独立段落"，复杂表头的层级关系恢复不如 MinerU 。跨页表格支持方面，Docling 缺乏公开的技术细节。

Marker 的表格处理被评价为"默认会以文字表格方式解析，优点是文字可复制，但排版有时候会跑掉"。LLM 优化后表格准确率可从 81.6% 提升至 90.7%，但这需要额外调用 LLM API，增加了成本和延迟 。Marker 对无线框表格、嵌套表格的支持较弱，更多依赖 LLM 的"猜测"而非精确的模型识别。

表格类型支持度	MinerU	Docling	Marker
有框表格	优秀（双方案可选）	良好（TableFormer）	一般（易错位）
无线框表格	优秀（StructEqTable）	一般（推断能力有限）	弱
嵌套表格	优秀（递归检测）	有限（子表识别困难）	不支持
跨页表格	优秀（自动合并94.1%）	未明确	不支持
复杂表头	优秀（层级保留）	一般（易误判为段落）	弱

4.1.2 复杂表头与合并单元格保留能力

复杂表头（如斜线表头、多层嵌套表头、跨列/跨行表头）是表格识别的进阶挑战。MinerU 的 StructEqTable 模型通过 HTML 输出天然支持合并单元格的表示（<td colspan="2">等），在实测中"能还原合并单元格、跨页表头"。其 InternVL2-1B 基础模型的视觉理解能力，使其能够判断"左上角的斜线区域是表头而非数据"，这种语义级识别超越了纯几何分析。

Docling 的 TableFormer 输出结构信息，但合并单元格的保留能力取决于模型的训练数据覆盖。社区反馈显示 Docling 在"复杂表头与合并单元格"场景下表现不如 MinerU，可能需要后处理修正 。

Marker 的合并单元格支持较弱，其基础输出为 Markdown 表格，该格式本身不支持合并单元格，复杂表格可能丢失结构信息或转为纯文本排列 。

4.1.3 表格结构完整性：MinerU 96.3% vs Docling 91.8%

基于 5 篇真实论文的横向评测，MinerU 的表格结构完整性得分 96.3%，Docling 为 91.8%。这一差距在财务、统计、科研等表格密集型场景中具有实际影响：MinerU 的输出可直接用于数据分析流水线，而 Docling 的输出通常需要人工校验或规则修复。MinerU 的 HTML 嵌套表格输出能够精确表达合并单元格的 rowspan/colspan 属性，以及多层表头的嵌套关系，这种"机器优先"的设计理念与 MinerU 的 LLM-ready 定位相一致 。

4.2 公式识别与转换

4.2.1 原生LaTeX转换支持对比

公式转 LaTeX 是学术文献解析的核心需求。MinerU 在该方面表现最为突出，其 UniMERNet 模型"支持手写公式和复杂长公式"，输出"LaTeX-friendly"格式，可直接编译 。实测显示 MinerU 输出的 LaTeX 代码"可直接编译"，而 Docling"部分嵌套公式需手动补括号"。MinerU 的公式检测使用 YOLOv8 模型，能够区分行内公式和独立公式，确保输出格式的正确性（$...$ vs $$...$$）。

Docling 的公式识别依赖第三方模块集成，如 LaTeX-OCR 或 GitOCR，以及 IBM 自研的代码公式模型 。其 2024 年 11 月的版本更新显示"即将支持提取文档中的公式和代码"，表明该能力仍在完善中 。当前版本的公式支持被评价为"不支持将公式转为 Markdown 格式"，这与 MinerU 的原生 LaTeX 输出形成差距。不过，Docling 的公式理解功能（do_formula_enrichment = True）可将公式提取为 LaTeX 表示，其实际效果可能因版本而异 。

Marker 的公式转换能力有限，早期版本明确"转换为 LaTeX 的方程式数量会少于 nougat"，且"空白和缩进不总是得到尊重"。LLM 增强选项可改善部分复杂公式，但基础能力仍弱于 MinerU。

4.2.2 行内/独立/多行对齐/矩阵/化学式覆盖度

在公式类型的覆盖度上，MinerU 的 UniMERNet 模型设计目标包括"复杂的长公式、手写公式和嘈杂的截图公式"，暗示其对多行对齐公式、矩阵等高级 LaTeX 结构有较好支持 。化学式识别方面，MinerU 未明确声明支持，但基于其 VLM 的视觉理解能力，可能对简单化学结构式有一定识别能力。

Docling 的公式类型覆盖取决于所选识别模块，LaTeX-OCR 对标准数学公式支持较好，但对化学式、物理单位等特殊符号可能需要定制 。

Marker 的公式覆盖度最窄，其基础版本主要处理简单行内公式，复杂结构依赖 LLM 的通用知识"猜测"，可靠性较低 。

4.2.3 公式语义保真度：MinerU 94.7% vs Docling 89.1%

公式语义保真度衡量识别结果在数学意义上的正确性。MinerU 的 94.7% 意味着其输出的 LaTeX 代码能够准确还原原公式的数学结构，包括上下标、分式、根号、积分限等复杂元素的层次关系 。Docling 的 89.1% 反映出其在嵌套结构（如多重分数、矩阵嵌套）处理上的不足，需要人工后处理修复 。这一差距在物理、数学等领域的复杂推导中尤为关键，因为单个括号的缺失可能导致整个公式语义改变。

公式识别能力	MinerU	Docling	Marker
LaTeX原生输出	优秀（直接编译）	基础（需补括号）	有限（数量少于Nougat）
行内公式	>97%	~80%	基础
独立编号公式	>95%	~65%（常转图片）	弱
多行对齐/矩阵	>92%	有限	不支持
化学式	有限支持	不支持	不支持
语义保真度	94.7%	89.1%	未公开

4.3 代码块与技术文档

4.3.1 代码格式保留与语法高亮支持

技术文档中的代码块保留是开发者场景的关键需求。Docling 在该方面走在前列，其明确提供"代码理解"功能（do_code_enrichment = True），对文档中找到的代码块使用高级解析 。IBM 的 Granite-Docling-258M 训练数据包含 SynthCodeNet（50 多种编程语言的合成代码片段），专门优化了代码结构保留 。Docling 的代码输出保留缩进、换行等格式信息，但语法高亮需要下游工具处理。

MinerU 的代码块处理更多依赖通用文档结构识别，未见到专门的代码解析模块。其 VLM 后端可能通过视觉理解判断"这是代码块"并保留等宽字体格式，但精细的语法分析非其重点 。

Marker 的代码块保留能力一般，社区反馈"格式化代码块和表格"是其功能之一，但实际效果可能因文档质量而异 。早期版本限制中明确提到"空白和缩进不总是得到尊重"，这直接影响代码的可读性 。

4.3.2 技术文档场景专项优化

技术文档场景要求工具理解"代码+解释+图表"的混排结构。Docling 的代码理解功能（do_code_enrichment = True）和 IBM 官方教程展示的与 Granite 代码模型结合构建技术文档 RAG 系统的完整流程，体现了其在该领域的投入 。MinerU 的技术文档优化体现在对"截断段落合并"的处理——代码注释跨行断开时的智能合并 。Marker 的技术文档支持更多依赖通用能力，缺乏专项优化，但其 --use_llm 模式可调用 LLM 生成图像描述，辅助技术图表的理解 。

技术文档能力	MinerU	Docling	Marker
代码块检测	基础（等宽字体识别）	优秀（专用代码理解模块）	一般
语法高亮标记	不支持自动检测	不支持（保留格式）	不支持
代码缩进保留	良好	优秀	一般（易丢失）
技术图表理解	基础	良好（Granite集成）	LLM增强可选

5. 输出格式与RAG友好度

5.1 默认输出格式矩阵

5.1.1 Markdown/JSON/HTML/自定义格式覆盖

三款工具的输出格式支持形成差异化矩阵。MinerU 的核心输出为 Markdown 和 JSON，其中 Markdown 用于人类可读场景，JSON（包括 middle.json 和 content_list.json）用于机器处理场景 。MinerU 2.5 系列对 JSON 结构进行了调整，以支持 VLM 后端新增的 layout type，这种演进反映了其输出格式与模型能力的深度绑定 。表格输出方面，MinerU 支持 HTML 嵌入（保留复杂样式）和 Markdown 表格（简单场景），公式输出为 LaTeX，图片输出为独立文件加引用链接 。

Docling 的输出格式最为丰富，支持 Markdown、HTML 和 JSON 三种格式，且强调"统一文档表示"（DoclingDocument 格式）作为中间抽象，再导出为目标格式 。这种设计允许同一解析结果灵活转换为不同输出，适应不同下游需求。Docling 的 HTML 输出保留更多样式信息，JSON 输出包含完整的层级结构和元数据。

Marker 的输出包括 Markdown、JSON 和 HTML，支持"按照自定义 JSON schema 进行结构化抽取（测试版）"。其 Markdown 输出质量较高，保留了标题层级、列表、链接等结构，但复杂表格可能降级为纯文本 。

输出格式覆盖	MinerU	Docling	Marker
Markdown	✅ 默认	✅ 支持	✅ 主要输出
JSON	✅ 含版面元数据	✅ DoclingDocument	✅ 含bbox元数据
HTML	⚠️ 表格嵌入	✅ 完整样式	✅ 支持
LaTeX	✅ 公式输出	❌	❌
DOCX	✅ 支持	❌	❌
自定义格式	⚠️ 需扩展	✅ 插件架构	⚠️ 测试版

5.1.2 Docling特色：Word/PPT/Excel↔Markdown双向转换

Docling 最独特的功能是多格式双向转换，这是 MinerU 和 Marker 均不具备的能力。Docling 不仅能将 Word、PPT、Excel 转换为 Markdown/JSON，还能处理反向流程（虽然公开信息主要强调"导出为"而非"导入自"）。这种能力在企业场景极具价值：例如将历史积累的 Word 版规章制度批量转为知识库可用的 Markdown，或将 PPT 培训材料转为结构化学习资源。Docling 对 DOCX、PPTX、XLSX 的原生支持（无需依赖 LibreOffice 等外部工具）也简化了部署，而 MinerU 的 magic-doc 模块处理 Word/PPT 需要安装 LibreOffice，增加了环境依赖 。

5.2 语义结构保留

5.2.1 标题层级、段落关系、列表还原精度

语义结构保留直接影响 RAG 系统的检索质量。MinerU 在标题层级识别方面表现优异，“自动检测标题级别，输出清晰的 Markdown 结构”，其重构的列表和目录识别功能"极大提升列表块和目录块识别的准确率及对应文本段落的解析效果"。MinerU 的段落拼接模块在跨栏、跨页、跨图、跨表情况下均能实现良好的段落拼接效果，确保语义连贯性 。

Docling 的语义保留依赖其"统一文档表示"（DoclingDocument），该格式"表达文档中的文本、表格、图片等内容，及文档的层次结构"。Docling 的优势在于保留"出处信息"（provenance information），如页码、内容的几何位置，这对需要溯源的场景（如法律文档、审计报告）至关重要 。但社区评测显示 Docling 在"段落关系、列表还原"方面偶尔出现层级误判，不如 MinerU 稳定 。

Marker 的语义保留能力处于中等水平，保留了"章节、段落、列表、脚注"等结构，但"并非所有行/跨度都会被正确连接"。其后期编辑模型（T5ForTokenClassification）对文本进行精细化修正，包括换行符和空格的插入，这有助于改善段落边界的识别 。

5.2.2 图文关联与脚注引用处理

图文关联是评估文档"理解深度"的指标。MinerU 的"智能匹配图注和脚注与图表"能力，将"描述性文本的丢失率降至接近 0"。这种匹配不是简单的邻近判断，而是结合字体特征（图注通常较小）、位置规律（图在文中、图注在图下）、内容模式（“图1”、"Figure 1"等编号）的多特征融合。

Docling 的图文关联依赖布局检测的坐标和类别信息，将 PictureItem 与邻近的 CaptionItem 关联 。IBM 的 Granite-Docling-258M 通过 DocTags 格式"精确描述页面元素的类型、坐标、阅读顺序与跨元素关联，例如图与其说明的对应关系"，这种显式关联表示比隐式坐标推断更可靠 。

Marker 的图注检测和引用链接输出能力存在，但"检测图注和引用，输出参考链接"的精度不如 MinerU 。

5.3 RAG场景适配

5.3.1 Chunk分块自然度与边界控制

Chunk 分块是 RAG 系统的核心环节，文档解析的输出质量直接影响分块效果。Docling 在 RAG 适配方面投入最多，其"Hybrid Chunker"与 LangChain、LlamaIndex 等框架集成，“为每个检测到的文档元素创建一个 chunk”，这种基于文档结构的语义分块比固定长度分块更自然 。DoclingDocument 的层级结构允许按标题、段落、表格等自然边界分块，避免"一句话被切成两半"的问题。

MinerU 的 Markdown 输出保留了清晰的标题层级和段落结构，下游 RAG 系统可以基于 Markdown 的 #、## 等标记进行启发式分块。MinerU 的 JSON 输出包含更细粒度的结构信息，但需要额外的解析逻辑才能用于分块 。

Marker 的 Markdown 输出同样支持基于标题的分块，但其结构精度较低可能导致分块边界错误，如将表格标题与表格内容分离 。

5.3.2 坐标/版面元数据输出支持

坐标和版面元数据对于需要"溯源"或"高亮显示"的 RAG 应用至关重要。Docling 明确保留"页码、内容的几何位置"等 provenance 信息，其 JSON 输出包含元素的坐标框（bounding box），支持"在原文中高亮显示检索结果"等高级功能 。Granite-Docling 的 DocTags 格式更是将坐标信息作为核心要素，“精确描述页面元素的…空间位置”。

MinerU 的 JSON 输出（middle.json、content_list.json）包含版面元数据，但具体坐标信息的完整度不如 Docling。MinerU 2.5 系列对 JSON 结构的调整可能增强了元数据支持，但详细规格需要查阅最新文档 。

Marker 的元数据输出相对简单，主要关注文本内容而非版面细节 。

5.3.3 向量数据库注入便利性对比

三款工具与向量数据库的集成路径差异显著。Docling 凭借与 LangChain、LlamaIndex 的官方集成，提供了最便捷的向量数据库注入路径。用户可以直接将 DoclingDocument 输入到这些框架的 Document Loader 中，自动完成解析、分块、嵌入、存储的全流程 。Docling 还支持 MCP Server 协议，可与 Claude Desktop、Cursor 等 AI IDE 直接对接，进一步降低了集成门槛 。

MinerU 的集成路径相对手动，需要用户自行编写代码将 Markdown/JSON 输出导入向量数据库。虽然 MinerU 提供了 Python API 和 CLI 工具，但缺乏 RAG 框架的官方适配，集成工作量较大。不过，MinerU 的国内开发背景意味着可能有更多中文社区的集成方案在涌现 。

Marker 的集成灵活性较高，支持 CLI、GUI、API 多种调用方式，但同样缺乏 RAG 框架的官方集成，需要自定义开发 。

RAG适配维度	MinerU	Docling	Marker
Chunk分块自然度	良好（标题驱动）	优秀（元素级分块）	一般（精度受限）
坐标/版面元数据	中等（JSON含部分信息）	优秀（完整provenance）	弱
框架官方集成	需自定义	LangChain/LlamaIndex官方	需自定义
MCP协议支持	无	有（Claude/Cursor直连）	无
向量注入便利性	中等	最便捷	中等

6. 性能与部署架构

6.1 推理速度与硬件要求

6.1.1 单页处理时间：GPU/CPU/NPU对比

根据 IBM Research 的技术论文和第三方基准测试，三款工具在不同硬件配置下的单页处理时间形成鲜明对比 ：

工具	x86 CPU	M3 Max SoC	NVIDIA L4 GPU	备注
Docling	3.1 sec/page	1.27 sec/page	0.49 sec/page	含OCR和表格结构识别（fast table）
MinerU	3.3 sec/page	未 finish	0.21 sec/page	GPU加速后领先，Mac支持待完善
Marker	>16 sec/page	4.2 sec/page	0.86 sec/page	CPU场景最慢，GPU改善明显
Unstructured	4.2 sec/page	2.7 sec/page	无GPU加速	参考对比

数据来源：Docling技术论文、第三方基准测试

关键发现：MinerU 在 GPU 环境下表现最优（0.21 秒/页），但 CPU 环境下与 Docling 接近（3.3 vs 3.1 秒），且在 MacBook Pro M3 Max 上未能完成任何测试运行，显示其跨平台兼容性仍有待改善 。Docling 的优势在于跨平台稳定性，在 x86 CPU、Apple Silicon 和 NVIDIA GPU 上均有可预测的性能表现，且 CPU 场景下与 MinerU 差距微小。Marker 的 CPU 性能最差（>16 秒/页），GPU 加速后改善至 0.86 秒/页，但仍慢于 MinerU 和 Docling。

在中文场景的实际体验中，MinerU 的 VLM 后端（2.5 系列）通过 vLLM/LMDeploy 加速，单页处理时间可进一步降低，但具体数值依赖于 GPU 型号和批处理大小 。Marker 宣称"平均处理速度可达 2.84 秒/页，相较 Llamaparse 提升 8.2 倍，较 Mathpix 提升 2.2 倍"，在 H100 GPU 环境下吞吐量高达 122 页/秒 ，但这些数据可能来自特定优化配置，与通用基准测试条件不同。

6.1.2 参数规模差异：MinerU 1.2B vs Docling 258M vs Marker轻量

模型参数规模直接影响硬件要求和部署灵活性。MinerU 的 VLM 后端（MinerU2.5-2509-1.2B）采用 1.2B 参数规模，属于"小模型"范畴但已接近边缘设备上限 。其 Pipeline 后端的多模型组合总参数量更大（DocLayout-YOLO + YOLOv8 + UniMERNet + PaddleOCR + StructEqTable/TableMaster），但各模型可独立加载卸载，峰值显存需求通过优化降至 8-10GB。

Docling 的 AI 模型参数量最为精简：布局模型（轻量 CNN/Transformer，50M）、表格模型（TableFormer，100M）、VLM 后端（Granite-Docling-258M，258M），总计可控制在 500M 以内。这种设计使其在 CPU 上即可流畅运行，且内存占用可控，是资源受限场景的首选。

Marker 的参数规模高度可变：基础模式（PyMuPDF+Tesseract）几乎无深度学习模型，LLM 增强模式下参数从 7B 到 72B 不等 。这种灵活性使其能够适配从树莓派到服务器集群的广泛硬件，但也意味着性能表现高度依赖后端选择。

硬件配置	MinerU	Docling	Marker
最低配置	8GB显存GPU / 16GB内存CPU	4GB内存CPU即可	无GPU要求，CPU即可
推荐配置	NVIDIA A100/L4，16GB+显存	NVIDIA T4或同等，8GB显存	NVIDIA H100用于批量，或CPU单页
纯CPU可行性	可行，慢3倍，易OOM	优秀，设计目标	基础模式可行，LLM模式不可行
Apple Silicon	MPS支持待完善	原生支持，性能优异	MPS原生支持
国产NPU	10+种（昇腾、寒武纪等）	通用后端，需适配	通用后端，需适配

6.1.3 端侧可跑性评估

端侧部署能力对于边缘计算和隐私敏感场景至关重要。Docling 的轻量模型（258M VLM + 模块化流水线）使其成为端侧部署的首选：可在树莓派、边缘网关等资源受限设备上运行，且推理延迟可预测 。Marker 的基础模式（无 LLM）同样适合端侧，但功能精度受限；LLM 增强模式则需要边缘服务器级硬件。MinerU 的端侧部署最具挑战：1.2B VLM 后端需要至少 8GB 显存，虽可通过 INT8 量化或模型蒸馏压缩，但官方未提供专门的端侧优化版本 。

6.2 部署方式矩阵

6.2.1 Docker/pip安装/云API/私有化路径

部署方式	MinerU	Docling	Marker
pip安装	✅ pip install magic-pdf（复杂，需CUDA配置）	✅ pip install docling（简单）	✅ pip install marker-pdf（简单）
Docker	✅ 官方镜像，预配置，预装模型	✅ 4.4GB(CPU)/11.4GB(CUDA)	✅ 社区镜像
云API	✅ mineru.net（国内节点）	❌ 无官方云服务（IBM Cloud可选）	❌ 无官方云服务
桌面客户端	✅ 全功能	❌	✅ Streamlit GUI
私有化	✅ 完整方案，数据不出域	✅ 本地执行，气隙环境	✅ 完全本地
国产芯片	✅ CUDA/NPU/MPS三后端	⚠️ 通用PyTorch	⚠️ 通用PyTorch

6.2.2 MinerU：CUDA/NPU依赖与纯CPU降级方案

MinerU 的硬件依赖最为复杂，需要 CUDA 11.8 + cuDNN 环境，模型权重超过 5GB 。为降低部署门槛，MinerU 提供多种优化方案：FP16 半精度推理减少显存占用、表格识别模块动态按需加载、CPU 模式纯推理（速度较慢但稳定）。对于 NPU（神经网络处理器）场景，MinerU 提供专门的 CANN（昇腾）、MLU（寒武纪）等后端支持，是国内唯一实现 10+ 种国产 AI 芯片适配的文档解析工具 。Hybrid 后端允许用户灵活组合本地模型和远程 VLM API，平衡精度与成本 。

6.2.3 Docling：OpenShift企业级集成

Docling 的企业级部署主要依托 IBM OpenShift 生态，支持容器化部署和 Kubernetes 编排 。其模块化架构使得在 OpenShift 环境中可以灵活配置资源配额，根据业务负载动态调整解析模块的实例数量。对于非 IBM 生态用户，Docling 的标准 Docker 部署同样可行，但缺乏官方的企业级运维工具 。

6.2.4 Marker：本地GPU/CPU/Apple MPS灵活部署

Marker 的部署灵活性在三款工具中最佳，支持 GPU（CUDA）、CPU 和 Apple MPS 三种计算后端 。其轻量架构使得在笔记本电脑上即可流畅运行，无需专用 GPU 卡。Marker 提供内置 API 服务器和 Streamlit GUI，方便非技术用户快速上手 。对于开发者，Marker 的 Python API 和命令行工具支持深度定制和批量处理 。

6.3 并发与批量处理

6.3.1 异步队列与多进程支持

批量处理稳定性涉及并发控制、错误恢复、资源管理等多个工程维度。MinerU 支持多进程并行，但表格处理速度较慢是其已知短板 。其 VLM 后端通过 vLLM/LMDeploy 加速，单页处理时间可进一步降低，但具体数值依赖于 GPU 型号和批处理大小 。Docling 的批量处理强调"模块化定制"：通过 Python API 的 PipelineOptions 精细控制处理流程，支持分页处理、批量大小调整等参数优化 。其 IBM Cloud Code Engine 的 Serverless Fleet 配置定义了 worker profile 和扩缩容限制，实现了"scale to zero when idle, scale up on demand"的成本优化 。Marker 的批处理模式在 H100 上可达 25 页/秒，适合大规模文档转换任务，但复杂表格和公式场景建议降低并发以保证精度 。

6.3.2 大批量文档稳定性实测

在大批量文档处理场景，稳定性比峰值速度更重要。MinerU 的实测数据显示，连续 100 次请求无 OOM、无崩溃、无超时中断，内存波动小于 ±80MB 。Docling 的稳定性得益于其模块化降级机制，在极端情况下可以关闭非核心功能保证任务完成 。Marker 的批量处理需要用户根据表格大小调整批处理参数，避免内存溢出，对于 200 行以上的大型表格建议分块处理 。

批量处理特性	MinerU	Docling	Marker
异步队列	支持（需外部框架）	内置支持	需自行实现
多进程并行	支持	支持	支持
断点续传	支持	支持	不支持
错误隔离	失败文档跳过	模块降级继续	单失败可能中断
进度监控	日志输出	进度条+统计报告	日志输出
千级文档稳定性	>99%	>99%	未验证

7. 开发者体验与生态

7.1 文档与SDK完备性

7.1.1 API文档完整度与多语言SDK覆盖

MinerU 在开发者工具链方面投入最大，提供完整的开发者生态：官方文档中心（opendatalab.github.io/MinerU）、JS/TS SDK（mineru-open-sdk）、Python CLI/SDK、MCP Server（支持 Cursor/Claude Desktop）、以及 Agent Skills（OpenClaw/NanoClaw/Nanobot）。其 JS/TS SDK 支持两种解析模式（Flash Extract 和 Precision Extract），提供从安装到保存的完整代码示例，API 文档详细说明各参数含义和限制条件 。Docling 提供 Python API 和 CLI 工具，文档结构清晰，但多语言 SDK 覆盖不足 。Marker 主要提供 Python API 和命令行工具，缺乏官方多语言 SDK，非 Python 开发者集成成本较高 。

7.1.2 示例代码与快速入门体验

MinerU 的快速入门体验因部署复杂度而受损，但一旦配置完成，其 Web UI 和桌面客户端提供了零代码使用路径 。Docling 的安装和基础使用最为顺畅，pip install 后即可运行，示例代码覆盖常见场景 。Marker 的命令行工具设计直观，marker_single input.pdf --use_llm 等命令易于记忆，适合技术背景用户快速上手 。

开发者体验维度	MinerU	Docling	Marker
官方文档语言	中文+英文	英文为主	英文为主
SDK语言覆盖	Python, JS/TS, .NET	Python	Python
MCP协议支持	无	有（AI IDE直连）	无
快速入门时间	30分钟（含环境配置）	10分钟	5分钟
示例代码丰富度	丰富（含Jupyter Notebook）	丰富	基础

7.2 RAG框架集成生态

7.2.1 LangChain/LlamaIndex/Haystack官方适配

Docling 在 RAG 框架集成方面最为完善，提供 LangChain、LlamaIndex、Crew AI、Haystack 的官方集成，并支持 MCP 协议实现 AI 代理直接调用 。MinerU 需要二次开发接入 LangChain/LlamaIndex，但社区已有多个非官方集成方案 。Marker 缺乏官方 RAG 框架适配，主要依赖社区贡献的集成代码 。

7.2.2 社区贡献的第三方集成方案

MinerU 的社区生态最为活跃，除官方 SDK 外，还有 Dify 插件、RAGFlow 集成、以及多个第三方封装的 API 服务 。Docling 作为 Linux Foundation 项目，其生态建设更偏向企业级合作，与 IBM Watsonx 等产品的深度集成是其独特优势 。Marker 的社区规模较小，但因其轻量特性，常被用作教学示例和个人项目的组件 。

7.3 社区活跃度与治理

7.3.1 GitHub Stars与增长曲线

指标	MinerU	Docling	Marker
Stars	~62,000	~37,000	~18,000（估算）
Forks	~5,200	~2,500（估算）	~800（估算）
Contributors	73	45（估算）	12（估算）
Releases	159	100+	50+
最近更新	2026-04-28	活跃	活跃

MinerU 的 GitHub 数据（62K Stars，5.2K Forks，73 贡献者，159 次 Release）显示出企业级开源项目的治理水平和社区吸引力 。Docling 作为较新项目，Stars 数量增长迅速，IBM 和 Linux Foundation 的背书加速了其生态建设 。Marker 的社区规模相对较小，但保持了稳定的迭代频率。

7.3.2 Issue响应速度与迭代频率

MinerU 的迭代频率极高，2025 年 9 月至 2026 年 4 月间持续发布多个版本，包括 2.2.0（表格精度提升）、2.2.1-2.2.2（bug 修复）、以及 2.5 系列重大更新 。其 Issue 响应速度在社区反馈中表现良好，GitHub Issues 数量控制在较低水平（10 open），显示出高效的问题管理 。Docling 的迭代由 IBM 企业流程驱动，版本发布更为规律但频率较低，重大功能更新通常与 IBM 产品路线图同步 。Marker 的迭代依赖个人开发者时间投入，功能更新较为灵活但稳定性验证周期较短 。

7.3.3 背后组织：上海AI Lab/IBM/Linux Foundation/个人开发者

项目的背后组织决定其长期发展方向与资源保障。MinerU 依托上海人工智能实验室的科研实力，技术前沿性有保障，2026 年 4 月将开源协议从 AGPLv3 迁移至基于 Apache 2.0 的 MinerU Open Source License，显著降低了商业部署门槛 。Docling 的 IBM → Linux Foundation 转移体现了开源治理的规范化，Linux Foundation 的托管为其长期中立性与社区参与提供了制度保障 。Marker 的个人开发者模式灵活性最高，但持续投入与项目延续性存在不确定性，EndlessAI 的商业支持程度有限 。

7.4 调试与可视化工具

7.4.1 中间结果可视化支持

MinerU 提供多种可视化结果，包括布局可视化、span 可视化等，支持高效确认输出效果和质量检验 。其多阶段流水线架构为中间结果输出提供了天然节点，便于调试和错误定位。Docling 的模块化设计同样支持中间结果导出，但官方可视化工具的支持程度未明确。Marker 提供 debug 模式保存每页的布局检测图像和边界框 JSON 文件，帮助用户诊断问题 。

7.4.2 错误诊断与日志系统

MinerU 的日志系统满足开发调试需求，生产环境的集中化日志管理需自行集成 。Docling 的企业级背景使其在日志规范、错误码定义、异常处理等方面更为成熟 。Marker 的日志功能基础，复杂故障排查可能需要深入源码 。

调试工具维度	MinerU	Docling	Marker
布局可视化	✅ 官方支持	⚠️ 需自行开发	✅ debug模式
中间结果导出	✅ JSON格式	✅ 模块化输出	✅ JSON格式
错误定位便利性	良好（多阶段可追溯）	优秀（模块化隔离）	一般（端到端黑箱）
日志系统成熟度	中等	优秀	基础

8. 成本与商业模式

8.1 开源协议商用友好度

8.1.1 MinerU：Apache 2.0衍生协议，商用需关注附加条款

MinerU 2026 年 4 月将开源协议从 AGPLv3 迁移至基于 Apache 2.0 的 MinerU Open Source License，这一变更显著降低了商业部署的门槛 。新协议明确"对于绝大多数开发者、创业团队和中小企业来说，只要在合规前提下，可直接用于商业用途，无需取得我们授权"。仅在"月活跃用户超过 1 亿、或月总收入超过 2000 万美元的大型商业主体"等超大规模场景下保留进一步授权要求 。这种"宽松为主、例外管控"的策略既推动了广泛采用，又为未来商业化保留了空间。

8.1.2 Docling：MIT License，无限制商用

Docling 采用 MIT License，这是最为宽松的开源协议之一——允许自由使用、修改、分发，包括商业用途，仅需保留版权声明 。IBM 将项目捐赠给 Linux Foundation 进一步强化了其中立性与长期可用性，企业无需担心供应商锁定或协议变更风险。对于追求法律确定性的企业客户，Docling 的许可证选择是最安全的选项。

8.1.3 Marker：GPL代码+Open RAIL-M模型权重，商用受限

Marker 的许可证结构最为复杂——代码部分采用 GPL，要求衍生作品同样开源；模型权重采用 Open RAIL-M，对模型的使用场景（如禁止用于监控、歧视等）施加伦理约束，且"免费用于研究、个人使用、和融资/收入低于 200 万美元的初创公司"，超出此范围需购买商业授权 。这种双重许可结构对商用构成显著限制：GPL 的传染性可能要求整个产品开源，Open RAIL-M 的场景限制需合规审查。商业用户需谨慎评估许可证风险，或寻求作者的商用授权。

许可证维度	MinerU	Docling	Marker
代码协议	Apache 2.0衍生	MIT	GPL
模型权重协议	需审查（受原始模型约束）	MIT（统一）	Open RAIL-M
商用自由度	高（中小企业无限制）	最高（完全无限制）	低（双重限制）
法律确定性	高（国内机构背书）	最高（Linux Foundation托管）	中（个人项目）
协议变更风险	低（已稳定）	极低（基金会托管）	中（依赖个人决策）

8.2 云API与托管服务

8.2.1 官方云服务可用性与定价模式

MinerU 提供官方云服务（mineru.net），包括在线 Demo、API 内测服务以及企业级私有化部署方案，形成了从个人开发者到大型机构的完整服务矩阵 。其云 API 采用国内节点，符合数据不出域要求，定价模式包括按量计费和订阅制，具体价格需联系商务团队。Docling 无官方独立云服务，主要通过 IBM Cloud 和 OpenShift 提供托管能力，定价遵循 IBM 企业级服务的标准模式 。Marker 无官方云服务，所有部署均需本地完成 。

8.2.2 第三方基于开源方案的托管服务生态

MinerU 的国内生态催生了多个第三方托管服务，包括阿里云市场镜像、腾讯云 Serverless 封装等，降低了中小企业的接入门槛 。Docling 的第三方托管服务主要依托 IBM 合作伙伴生态，国内选择相对有限。Marker 因无官方云服务，第三方托管服务几乎空白，用户需自行搭建基础设施 。

8.3 总拥有成本分析

8.3.1 私有化部署算力成本：GPU集群 vs CPU集群

部署场景	MinerU	Docling	Marker
GPU集群（推荐）	NVIDIA A100/L4，显存16GB+	NVIDIA T4即可，显存8GB+	H100用于LLM模式，或CPU
CPU集群（降级）	可行，吞吐量下降3倍	设计目标，吞吐量可接受	基础模式可行
单页处理成本	~0.005美元（GPU摊销）	~0.003美元（GPU）/ ~0.01美元（CPU）	~0.001美元（CPU基础）/ ~0.05美元（LLM API）
百万页年成本	~5,000美元	~3,000美元（GPU）/ ~10,000美元（CPU）	~1,000美元（基础）/ ~50,000美元（LLM）

注：成本估算基于公开基准测试数据和云服务定价模型，实际成本因具体配置和使用模式而异。

8.3.2 维护成本：模型更新、Bug修复、社区支持依赖度

MinerU 的维护成本中等——模型更新频率高（2026 年 4 月前 6 个月发布 10+ 版本），但国内社区支持活跃，中文文档完善，降低了故障排查成本 。Docling 的企业级背景保障了稳定的维护节奏，但重大更新可能与 IBM 产品周期绑定，社区支持的响应速度不如 MinerU 敏捷 。Marker 的维护成本高度依赖个人开发者投入，长期维护存在不确定性，企业用户需评估技术债务风险 。

8.3.3 人力集成成本：中文场景定制开发投入

集成场景	MinerU	Docling	Marker
标准中文PDF解析	低（开箱即用）	中（需配置中文OCR）	高（需预处理+后处理）
复杂公式/表格	低（原生支持）	高（需第三方模块集成）	高（LLM增强不稳定）
多格式双向转换	不支持	低（原生支持）	不支持
RAG系统集成	中（需自定义适配）	低（官方集成）	高（完全自定义）
国产硬件适配	低（官方支持）	高（需自行适配）	高（需自行适配）

9. 选型决策矩阵

9.1 场景化推荐

9.1.1 中文学术文献/教材高精度解析：MinerU

对于需要处理中文学术论文、教材、古籍、财务报表等复杂文档的场景，MinerU 是唯一能够满足生产级精度要求的开源选择。其核心优势在于：中文 OCR 的专项优化（PaddleOCR 深度定制）、复杂公式的原生 LaTeX 转换（UniMERNet，CDM 97.29）、表格结构的完整保留（StructEqTable，TEDS 93.42）、以及国内部署的合规保障（数据不出域、国产 NPU 适配）。虽然硬件要求较高（推荐 GPU 加速）且部署复杂度大于 Docling，但这些投入在精度敏感场景下具有明确的 ROI。特别适合：高校图书馆数字化项目、金融风控文档审核、出版社学术期刊结构化、以及构建高质量中文知识库的 RAG 应用。

9.1.2 企业级多格式快速转换与IBM生态：Docling

对于已采用 IBM 技术栈（OpenShift、watsonx） 或需要 Word/PPT/Excel 与 Markdown 双向转换 的企业，Docling 是最优选择。其核心优势在于：MIT License 的完全商用自由、轻量模型的高效推理（CPU 可运行）、企业级容器化部署支持、以及与 LangChain/LlamaIndex 的官方 RAG 集成。中文场景需要额外投入集成 PaddleOCR 等优化引擎，但对于以英文为主、中文为辅的跨国企业，这一成本在可接受范围内。特别适合：企业文档管理系统、多格式知识库迁移、合规审计文档处理、以及需要与现有 IBM 基础设施深度集成的场景。

9.1.3 轻量快速PDF转Markdown个人项目：Marker

对于个人开发者、小型原型项目、或对成本极度敏感的场景，Marker 提供了最低门槛的入门路径。其核心优势在于：极简的部署体验（pip install 即用）、灵活的硬件适配（CPU/GPU/Apple MPS）、以及快速的单页处理速度（基础模式）。但需清醒认识其能力边界：中文支持薄弱、复杂版式精度不足、商用许可证受限。建议的使用方式：英文技术文档的快速预览转换、个人知识管理的辅助工具、以及作为更大系统的预处理组件（配合后续校正流程）。不建议用于：生产级中文文档处理、高精度学术文献数字化、以及有合规要求的商业应用。

9.2 关键权衡因素

9.2.1 精度优先 vs 速度优先 vs 成本优先

优先级	首选工具	关键考量
精度优先	MinerU	中文场景下精度差距具有决定性，公式/表格错误可能导致系统性风险
速度优先	Docling（CPU）/ Marker（基础模式）	需接受精度折损，评估错误率是否在业务容忍范围内
成本优先	Marker（CPU基础模式）	人力校正成本可能超过工具节省，需综合核算总拥有成本
生态优先	Docling（IBM用户）/ MinerU（国内生态）	与现有基础设施的集成成本可能超过工具本身成本

9.2.2 中文场景必选能力清单

评估文档解析工具的中文适用性，建议核验以下能力：

• 简体中文识别准确率 > 95%（元素级）
• 繁体中文支持（至少可配置）
• 竖排文本检测（古籍/传统出版物必需）
• 中英混排处理（学术/技术文档必需）
• 复杂字体鲁棒性（楷体、仿宋、黑体变体）
• 公式LaTeX转换（学术场景必需）
• 表格结构保留（财务/数据场景必需）
• 国内部署可行性（数据合规必需）
• 国产硬件适配（昇腾/寒武纪等，信创场景必需）

MinerU 满足全部 9 项，Docling 满足 5-6 项（需定制），Marker 满足 2-3 项。

9.2.3 未来技术路线演进风险评估

风险维度	MinerU	Docling	Marker
技术路线可持续性	中（依赖上海AI Lab持续投入）	高（Linux Foundation托管）	低（个人项目依赖）
中文优化深度	持续领先（国内团队驱动）	中等（IBM全球优先级）	低（非核心目标）
VLM替代专用模型风险	中（已采用混合架构）	中（轻量VLM持续优化）	高（完全依赖VLM演进）
许可证变更风险	低（已稳定为Apache衍生）	极低（基金会治理）	中（Open RAIL-M可能收紧）
社区生态壮大	高（国内RAG需求驱动）	高（企业集成需求驱动）	中（个人用户为主）

关键洞察：文档解析领域正处于"专用模型"与"通用VLM"的技术路线博弈期。MinerU 的"混合架构"（专用模型+VLM增强）在当前阶段展现了最佳的风险-收益平衡：既保留了专用模型的精度确定性，又通过VLM扩展了复杂场景的理解能力。Docling 的"轻量VLM"路线若能在模型效率上持续突破，可能在中等复杂度场景形成差异化优势。Marker 的"完全VLM依赖"路线则面临最大的不确定性——其核心竞争力与VLM技术的演进速度强绑定，若通用VLM在文档理解上的进步不及预期，Marker 的精度瓶颈将难以突破。