PyMuPDF4LLM vs pdfplumber vs Marker：用真实 PDF 实测

PyMuPDF4LLM vs pdfplumber vs Marker：结论

没有哪个库在所有测试里都赢。下面给出每一行背后的数据，你可以拿手头真正要处理的 PDF，在 pymupdf4llm vs pdfplumber vs marker 之间做决定。

测试方法：硬件、版本、文档

为了公平，三个库在同一台机器上处理同一批文件，全部只在 CPU 上解析 PDF：Intel(R) Xeon(R) Processor，8 个 vCPU，16 GB 内存，没有 GPU，Linux 6.12.94+ x86_64，Python 3.13.5。版本：pymupdf4llm 1.28.2（PyMuPDF 1.28.2），pdfplumber 0.11.9（pdfminer.six 20251230），marker-pdf 2.0.0（surya-ocr 0.22.1，torch 2.14.1+cpu）。token 用 tiktoken 0.14.0 的 o200k_base 编码统计。测试日期是 2026 年 10 月 19 日。

• 文档：一份 5 页的英文指南，13 个标题、1 个表格；一份 11 页的中文报告，29 个标题、4 个表格；一份 4 页的英文报告，每页都有同样的页眉和页码。
• 表格示例：11 个单页 PDF，每个单元格的正确内容我们都知道，其中两个根本没有表格。
• 设置：都用各库的默认值。pdfplumber 没有 Markdown 输出，所以我们写了二十来行代码，把它的文本行和 find_tables() 的结果按阅读顺序拼起来。marker 用默认设置（CPU 上默认的快速模式）跑一次，再加 --disable_ocr 跑一次。
• 计时：取三次运行的中位数。marker 的模型预先加载过一次（4.79 秒），并丢掉了一次预热运行。

import pymupdf4llm
md = pymupdf4llm.to_markdown("report.pdf")

import pdfplumber
with pdfplumber.open("report.pdf") as pdf:
    for page in pdf.pages:
        lines = page.extract_text_lines()
        tables = page.find_tables()

from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered
converter = PdfConverter(artifact_dict=create_model_dict())
md, _, _ = text_from_rendered(converter("report.pdf"))

在 CPU 上，marker 2.0 还需要 llama.cpp 的 llama-server 程序，要按它的 README 另外安装；第一次启动时，它在我们机器上下载了大约 1.8 GB 的模型文件。我们前两次都失败了：一次是 torch 和 torchvision 版本不匹配，一次是缺了 llama-server。这些是安装问题，不是库的 bug，但最好预留时间。

速度和 token 数

pymupdf4llm vs pdfplumber vs marker 差别最大的是速度。pdfplumber 在短报告上最快（0.023 秒），但在中文报告上是两个轻量工具里最慢的。pymupdf4llm 很稳定，每页 0.1 到 0.14 秒。即使模型已经加载好，marker 处理英文指南也比 pymupdf4llm 慢 5 倍；加上 --disable_ocr 后差距缩小了。

两个轻量库的 token 数差不多。marker 在中文报告上多出约 12% 的 token，部分来自 <sup> 标签和多余空格；在短报告上反而更少，因为它删掉了重复的页眉。

标题和页面上的多余内容

第二大差别是标题。pymupdf4llm 找到了所有标题，层级都对。它还把指南里加粗的 FAQ 问题也标成了标题（6 行），有时这反而有用。pdfplumber 不认识标题，只给你平铺的文本。marker 找到了大部分标题，但层级经常不对。

在 4 页报告里，pymupdf4llm 和 pdfplumber 保留了全部 4 处重复页眉和 4 个页码，marker 把两者都删了。这是 pymupdf4llm vs marker 最明显的区别：marker 的版面模型知道什么是页眉，轻量库不知道。pdfplumber 还在一行末尾留下了一个断开的单词。

表格：有边框、无边框、合并单元格

表格的排名取决于 PDF 里有没有画线。pdfplumber 的 find_tables() 沿着线条找表格，所以只要 PDF 画了网格线，连合并单元格都能完全正确；没有线就什么也找不到。pymupdf4llm 在大多数有边框表格上完全正确，但有一个 Office 表格的单元格里有未转义的 |，被它拆坏了。marker 找到了两个简单的无边框示例，单元格正确率 83% 到 90%；pymupdf4llm 只找到一个，正确率 40%，pdfplumber 一个都没找到。不过在合并单元格示例里，marker 把几列合到了一起。

Office 导出的无边框表格，三个库都没识别出来。如果你最看重表格，我们的 PDF 表格转换指南 解释了为什么无边框版式对任何工具都难。

中文文本：字符保留、空格、标点

到了中文，排名又变了。原 PDF 的句子里没有任何空格。pymupdf4llm 保留了每个字和每个全角逗号，但在句子里插了 159 个空格。pdfplumber 也保住了字符，但在句子中间留下了 140 处换行。marker 丢了 1.4% 的字符，包括几个小节标题，把所有全角逗号换成了英文逗号，还加了 152 个 <sup> 标签。在我们的测试里，中文 PDF 用 marker 转出来后要改的地方最多。

许可证：AGPL、MIT、Apache，以及模型条款

• pdfplumber：根据它的 LICENSE 文件，采用 MIT 许可证。只要保留许可声明，就能用在闭源和商业代码里。
• pymupdf4llm 和 PyMuPDF：仓库附带 GNU AGPL 3.0，包的元数据写着 "Dual Licensed - GNU AFFERO GPL 3.0 or Artifex Commercial License"。简单说：如果你分发依赖它的程序，或者通过网络向用户提供修改过的版本，AGPL 要求你以同样的许可证公开这个程序的源代码，除非你向 Artifex 购买商业许可。
• marker：代码是 Apache-2.0，但模型权重用的是修改版 AI Pubs Open RAIL-M 许可证。根据 MODEL_LICENSE，研究、个人使用以及总收入或融资低于 500 万美元的组织可以免费使用权重；超过这个规模需要向 Datalab 购买许可。

如果许可证是决定因素，对大多数商业团队来说，两个轻量库之间真正的选择就是 AGPL 还是 MIT，而 marker 还多了一道收入门槛。以上只是摘要，不构成法律意见，发布前请自己读一遍许可证文件。