技术知识库 · 工具评测 · · 国科智飞 Gavin

2026 开源 PDF 解析方案横评：LiteParse、MinerU、MarkItDown 怎么选

三款热门开源 PDF 解析工具，路线完全不同：一个拼速度，一个啃复杂版面，一个覆盖格式。选型之前，先看清边界。

PDF 转 Markdown 是所有文档 AI 流水线的第一道工序。RAG 预处理、合同审查、论文结构化，都绕不开它。这道工序有个特点：出了问题，后面所有环节都在为它买单——切片切歪了、表格碎成乱码、扫描件整页丢失，检索和问答再强也救不回来。

2026 年被问得最多的三个开源方案，路线其实完全不同：LiteParse 用 Rust 把速度做到极致，MinerU 用模型啃复杂版面，MarkItDown 用插件覆盖格式。选型之前，先看清它们各自适合什么、不适合什么。

LiteParse：极速还原，结构判断交给下游

run-llama/liteparse 是 LlamaIndex 团队用 Rust 重写的 model-free PDF 解析引擎。model-free 指解析过程不调用任何大模型，这也是它能快的原因。

按 LlamaIndex 公布的基准，v2.1 单页解析 3.16 毫秒，500 页 PDF 约 2 秒；同一基准下，MarkItDown 是 182.5 毫秒/页，pymupdf4llm 是 141.5 毫秒/页，分别慢约 57 倍和 44 倍。LlamaIndex 称它在 ParseBench、OpenDataLoader、olmOCR-bench 三个公开基准上均为 model-free 赛道第一；准确率方面，ParseBench 0.328、OpenDataLoader 0.871，同样高于 pymupdf4llm 与 MarkItDown。

更有意思的是它的设计哲学。传统解析器会把表格尽力转成 Markdown 管道语法，复杂表格直接崩；LiteParse 用空间网格投影算法（基于自定义 PDFium 分支），按原始空间位置重建页面，表格不转格式，只保留缩进和列对齐。它的判断是：解析器的职责是如实还原物理信息，结构化判断留给下游的 LLM。

这条哲学决定了它的适用姿势。如果你期待"解析完就是干净的结构化数据"，LiteParse 会让你失望——它交出的是一份忠实的空间文本，合并单元格、跨页续表演示出来仍是原始形态，需要下游模型再判断一次。但反过来说，如果你本来就要把文本喂给 LLM，这层"不替模型做判断"的设计反而少了一次错误传递。

工程完整度也高：Rust 核心通过 FFI 输出 Rust / Python / Node / WASM 四种形态，统一一个 lit CLI；安装对应四条路径——pip install liteparse、npm i @llamaindex/liteparse、cargo install liteparse，浏览器用 WASM 包。OCR 内置零配置的 Tesseract，也可通过 HTTP 接 PaddleOCR / EasyOCR；还能生成页面截图，给 Agent 当视觉兜底。官方另外提供了一条命令装进 Claude Code / Cursor 的 Agent Skill。

这里有一个容易被忽略的部署细节：Tesseract 是本地跑，数据不出机器；HTTP 接 PaddleOCR / EasyOCR 时，文档图像会离开内网。金融、医疗、政务这类对数据边界敏感的客户，优先用本地 OCR 模式。

License 是 Apache-2.0，闭源商用、私有化部署、SaaS 转售都合法。

边界同样明确，而且写在 README 里：密集表格、多栏布局、图表、手写、扫描件效果有限，官方建议这类复杂文档改用付费云服务 LlamaParse。这既是商业策略，也是真实的能力边界——把它当成扫描件 OCR 方案会踩坑。上线前最稳妥的做法，是拿自己的文档各跑一遍，用结果而不是榜单来做决定。

MinerU 与 mineru-web：重装备，专治复杂文档和私有化

MinerU 是 OpenDataLab 出品的文档解析器，走模型推理路线：vlm / hybrid 双引擎，覆盖 PDF、表格、公式、版面分析，对带公式、表格、多栏的学术、法律、财务文档更有办法，对中文文档的支持也相对友好。上游项目在 GitHub 上有 4 万以上 Star，生态成熟度在国产方案里属于第一梯队。

代价是部署重：需要 GPU，资源开销明显高于 model-free 方案。它换来的不是更快，而是更难啃的文档也能结构化。

如果需要完整产品而不是命令行工具，lpdswing/mineru-web 是上游生态里较受认可的 Web 封装：FastAPI + Vue 3 + Redis 异步队列 + MinIO 存储 + Docker Compose 一键部署，带多用户隔离、批量上传导出、任务进度和 Office / 图片预览。默认端口分工清晰：Web UI 8088、业务后端 8000、MinerU router 8002、MinIO 控制台 9001。多 GPU 场景用内置的 mineru-router 调度；macOS Apple Silicon 上则可以用"业务服务进 Docker、MinerU API 跑宿主"的混合部署绕过 GPU 兼容问题。v2.6.8 起还加入了 NPU 支持，为国产化硬件留了路径。

最有辨识度的是 bbox 溯源——解析出的每块 Markdown 都能点回 PDF 原文坐标，表格可以左右对照。需要人工复核的场景里，这个交互比任何精度数字都有说服力。

工程上还有一点值得注意：从 v3.2.3 起，业务后端不再依赖 MinerU 内部 Python 接口，改为调用官方 HTTP API。上游升级时只需改 API 版本号和镜像 tag，业务代码不动——对有长期维护诉求的团队，这比多两个功能更重要。可选的后处理（Popo）也是同样的思路：失败不阻塞主流程，上游 LLM 不稳定时业务不至于断掉。

风险也要讲清楚。mineru-web 是 AGPL-3.0：内部自部署使用不受影响，但修改后对外提供 SaaS 服务，就必须开源修改部分。它还是单人维护项目，bus factor 为 1，长期依赖需要准备 fork 和内部分支策略。部署时三个默认配置必须改：MinIO 默认口令、默认放开的 router 公网调用，以及"首个注册用户即可用"的弱鉴权——公网部署前务必加访问控制。上游 MinerU 同为 AGPL-3.0。

MarkItDown：格式覆盖最广的入口工具

微软的 MarkItDown 是另一种思路：不做最强的 PDF 解析，而是把 15+ 种格式统一转成 LLM 友好的 Markdown——PDF、Word、PPT、Excel、图片、音频、HTML、YouTube、CSV / JSON / XML、ZIP、EPUB、Outlook 邮件。项目在 GitHub 上有 13 万以上 Star，是这一赛道里用户基数最大的工具。

它的目标是语义保真而不是视觉保真：标题变 #，表格变管道语法，图片配描述文本。和 Pandoc 这类追求排版还原的工具不同，它假设读者是 LLM 而不是人。加上插件系统（含扫描件 OCR 插件）、Azure 集成、CLI 和 Python 双入口，上手成本很低，适合做知识库 RAG 的第一道入口。

但 PDF 只是它支持的格式之一，不是专精方向。在 LlamaIndex 同一基准里，它的 PDF 速度是 182.5 毫秒/页，ParseBench 与 OpenDataLoader 准确率也明显低于 LiteParse。拿它做大批量 PDF 高精度解析，属于用错工具。License 是 MIT，商用最宽松。

横向对比

维度 LiteParse MinerU（+ mineru-web） MarkItDown
定位 model-free 极速解析引擎 模型驱动解析 + Web 产品壳 多格式转换入口
强项 速度、离线、多端、许可宽松 复杂版面、公式表格、bbox 溯源 格式覆盖、上手快、MIT
边界 密集表格 / 手写 / 扫描件较弱 需 GPU、部署重、AGPL、单人维护 PDF 非专精、准确率一般
运行成本 CPU 即可、近乎零成本 需要 GPU 与运维投入 CPU 即可
数据边界 本地，HTTP OCR 时除外 自部署时全本地 本地，Azure 插件除外
License Apache-2.0 AGPL-3.0 MIT

选型建议

干净电子版 PDF 的大批量流水线，比如把历年报告切片进 RAG，优先选 LiteParse：快、离线、许可干净，成本可控。

复杂文档，比如学术论文、招股书、审计报告、扫描件，上 MinerU：用模型换版面理解，需要人工复核时配合 mineru-web 的 bbox 溯源。前提是接受 GPU 成本、AGPL 约束和单人维护风险。

混合格式资料库，比如 Word、PPT、邮件、音频、网页混在一起，用 MarkItDown 做统一入口：先把所有文件变成 Markdown，再谈结构化。

组合使用往往更顺：MarkItDown 当入口分流，普通 PDF 走 LiteParse 快路径，疑难 PDF 走 MinerU 慢路径，MinerU 可选 Popo 后处理让 Markdown 更干净，最后交给 LLM 做结构化。把"快"和"准"拆成两条链路，成本和质量的账才算得清。

落地时还有一个工程原则值得坚持：让三者的输出都收敛到同一个中间格式（Markdown），解析器就成了可替换的零件。今天因为成本选 A，明天因为效果换 B，都不会牵动下游代码。反过来，如果业务代码直接依赖某个解析器的内部结构，换工具就等于重写流水线。

三个提醒

第一，本文引用的速度和准确率数字，来自 LlamaIndex 公布的基准与微信公众号「机器折线」的转述，属于项目方自报，并非独立第三方复测。上线前建议用自己的真实文档跑一组对比——这也是本文不给"谁最好"结论的原因。

第二，先给文档分类，再选工具。"干净 PDF"和"扫描件 / 复杂版面"是两类完全不同的问题，指望一个工具包打天下，通常两头不讨好。顺带提醒：同赛道常见的 pymupdf4llm 是 AGPL-3.0，商用前务必评估。

第三，许可证要提前看，不要等到商业化那天。Apache-2.0 与 MIT 基本没有后顾之忧，AGPL-3.0 则要先回答一个问题：你是内部使用，还是对外提供服务？答案不同，风险完全不同。

参考来源