PyMuPDF4LLM・pdfplumber・Marker を実際のPDFで比較

PyMuPDF4LLM・pdfplumber・Marker：結論

すべてのテストで勝ったライブラリはありません。この記事の残りでは各行の裏にある数字を示すので、手元にあるPDFに合わせて pymupdf4llm・pdfplumber・marker を比べられます。

テストの方法：ハードウェア、バージョン、文書

比較を公平にするため、どのライブラリにも同じマシンで同じファイルを渡しました。すべてCPUだけでのPDF解析です：Intel(R) Xeon(R) Processor、8 vCPU、RAM 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）。トークンは tiktoken 0.14.0 とエンコーディング o200k_base で数えました。テストは2026年10月19日に行いました。

• 文書： 見出し13個と表1個のある5ページの英語のガイド、見出し29個と表4個のある11ページの中国語のレポート、すべてのページに繰り返しのヘッダーとページ番号がある4ページの英語のレポート。
• 表のサンプル： 正しい表をセル単位で把握している1ページのPDF 11個。うち2個は表をまったく含みません。
• 設定： 各ライブラリの初期設定。pdfplumber にはMarkdown出力がないため、テキスト行と find_tables() の結果を読む順に並べる約20行のコードを書きました。marker は初期設定（CPUでの標準である高速モード）と --disable_ocr の2通りで実行しました。
• 時間の計測： 3回の実行の中央値。marker のモデルは事前に1回読み込み（4.79秒）、ウォームアップの1回は除外しました。

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 を動かすには、README によると別途インストールが必要な llama.cpp の llama-server バイナリも要り、初回の起動時に私たちのマシンでは約1.8 GBのモデルファイルをダウンロードしました。最初の2回の試行は失敗しました。1回目は torch と torchvision のバージョンの不一致、2回目は llama-server がなかったためです。どちらもライブラリの不具合ではなくセットアップの問題ですが、その時間は見込んでおいてください。

速度とトークン数

pymupdf4llm・pdfplumber・marker の差が最も大きいのは速度です。pdfplumber は短いレポートで最速（0.023秒）でしたが、中国語のレポートでは軽量なツールの中で最も遅くなりました。pymupdf4llm は一貫して1ページあたり約0.1〜0.14秒でした。marker はモデルを読み込み済みでも、英語のガイドで pymupdf4llm の5倍遅く、--disable_ocr を付けると差は縮まりました。

軽量な2つのライブラリのトークン数は近い値でした。marker は中国語のレポートで約12%多くのトークンを出力し、その一部は <sup> タグと余分なスペースによるものでした。短いレポートでは、繰り返しのヘッダーを省いたため少なくなりました。

見出しとページの余計な要素

見出しは2つ目の大きな違いです。pymupdf4llm はすべての見出しを正しいレベルで見つけました。ガイドの太字のFAQの質問も見出しとして扱いましたが（6行）、これは役に立つこともあります。pdfplumber には見出しの概念がないので、平坦なテキストになります。marker はほとんどの見出しを見つけましたが、レベルが違うことがよくありました。

4ページのレポートでは、pymupdf4llm と pdfplumber は繰り返しヘッダー4個とページ番号4個をすべて残し、marker はどちらも取り除きました。pymupdf4llm と marker の違いが最もはっきり出た例です。marker のレイアウトモデルはヘッダーとは何かを知っていますが、軽量なライブラリは知りません。pdfplumber は行末でハイフン区切りされた単語もそのまま残しました。

表：罫線あり、罫線なし、結合セル

表の順位は、PDFが線を描いているかどうかで決まります。PDFが罫線を描いていれば、find_tables() が線をたどるので、pdfplumber の表は結合セルを含めて完全に一致します。線がなければ何も見つかりませんでした。pymupdf4llm は罫線のある表のほとんどで完全一致でしたが、セルに | を含むオフィスソフトの表では、それをエスケープせずに表を崩しました。marker はシンプルな罫線なしの例を2つとも見つけてセルの83〜90%を再現し、pymupdf4llm は1つを40%で、pdfplumber は0個でした。ただし結合セルの例では、marker は列をまとめてしまいました。

オフィスソフトから書き出した罫線なしの表は、どのライブラリも認識できませんでした。表が目的なら、PDFの表のガイドで、罫線なしのレイアウトがどのツールにも難しい理由を説明しています。

中国語テキスト：網羅率、スペース、句読点

中国語のテキストでは、順位がまた入れ替わります。元のPDFには文中にスペースがありません。pymupdf4llm はすべての文字と全角の読点を残しましたが、文中に159個のスペースを入れました。pdfplumber も文字は残しましたが、文の途中に140個の改行が残りました。marker は文字の1.4%を失い、その中にはいくつかのセクション見出しも含まれていました。また全角の読点をすべてASCIIのカンマに変え、<sup> タグを152個追加しました。私たちのテストでは、中国語の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」とあります。簡単に言えば、これを使ったプログラムを配布したり、変更版をネットワーク越しにユーザーに提供したりする場合、Artifex から商用ライセンスを買わない限り、AGPLはそのプログラムのソースコードを同じライセンスで公開することを求めます。
• marker： コードは Apache-2.0 ですが、モデルの重みは独自に変更された AI Pubs Open RAIL-M ライセンスです。MODEL_LICENSE によると、重みは研究、個人利用、総収入または資金調達額が500万ドル未満の組織には無料で、それを超える場合は Datalab のライセンスが必要です。

ライセンスが決め手なら、多くの商用チームにとって、軽量な2つのライブラリの間の本当の選択は AGPL か MIT かであり、marker にはさらに収益の基準があります。これは要約であって法的助言ではありません。何かを公開する前に、ライセンスファイルを読んでください。