2026 AI PDF OCR 工具排行榜：pdf-inspector、MinerU、Marker 誰最好用？

做 RAG、合約審核或論文知識庫時，團隊常問「MinerU 和 Marker 誰更強」。但真正拖慢流水線的，往往是把自帶文字層的 PDF 也送進 GPU OCR——一次批次處理從秒級變成分鐘級，Agent 還在等文件就緒。Firecrawl 開源的 pdf-inspector 把這件事講透了：先分類、再抽取、只對缺字頁 OCR。

本文面向要把 PDF 餵給向量庫或 Agent 的 iOS / Flutter / 後端開發者，以及正在評估 Cloud Mac 節點 跑本地解析的團隊。最後更新於 2026 年 8 月 5 日；工具版本與許可以各專案 GitHub 為準。

為什麼「OCR 一切」會拖垮文件流水線

企業 PDF 語料裡，大量報告、論文、發票、招股書其實帶有可抽取的文字層，並不需要視覺模型逐頁識別。傳統做法是統一呼叫 MinerU / Marker / 雲 OCR API，帶來三類隱性成本：

1. 延遲稅——純文字 PDF 本可在百毫秒級出 Markdown，卻被迫排隊等 GPU。
2. 結構稅——OCR 可能打亂原有閱讀順序，表格與註腳在後處理裡更難修。
3. 許可稅——Marker 等工具的模型權重對商用有額外條款，全量 OCR 等於放大合規面。

2026 年更合理的框架是：入口分類 → 本地文字抽取 → 按頁 OCR 回退。pdf-inspector 在 opendataloader-bench 200 份 PDF 上，無 OCR 模式下整體得分約 0.875，整庫跑完約 2.8 秒——與動輒數分鐘的 ML 流水線形成鮮明對比。

AI PDF 工具怎麼分類（三類入口）

不要把三款工具當成同一賽道裡的「排行榜名次」，它們解決的是流水線不同層：

類型	代表	核心動作	典型延遲
A. 路由 / 文字層抽取	pdf-inspector	判定 TextBased / Scanned / Mixed，原生文字轉 Markdown	~20ms 分類 + ~150ms 抽取/份
B. 高精度 OCR 流水線	MinerU	版式分析、表格 HTML、公式 LaTeX、84 語 OCR	秒～分鐘/份（視 GPU）
C. 高吞吐 OCR 流水線	Marker	Surya 套件，多格式輸入，可選 LLM 精修	批量下頁/秒級（GPU）

非對稱結論：真正分水嶺不是模型參數量，而是你有沒有在流水線入口做對「文字層 vs 掃描件」分類。缺這一層，再強的 OCR 也是在為不需要 OCR 的文件買單。

核心對比：pdf-inspector vs MinerU vs Marker

下表用統一維度對比三款工具，便於寫入技術選型文件。執行能力指批次處理、流水線嵌入與輸出可控性；上下文指版式、表格、公式與多語言保留程度。

工具	入口	執行能力	上下文	適合人群
pdf-inspector	Node / Python / Rust CLI；可嵌 Agent 前置	無 ML 依賴；pages_needing_ocr 按頁路由；MIT 許可	原生文字 Markdown、雙模式表格、多欄閱讀順序；不做掃描 OCR	要做混合流水線的後端；Firestore / S3 海量 PDF 預處理
MinerU	CLI / Docker / API；CPU 與 VLM 雙後端	OmniDocBench 類場景準確率高；GPU VLM 路徑 ≥8GB 顯存；自訂開源協議	表格、公式、CJK 強項；頁眉頁腳剔除；JSON + MD 多格式	學術論文庫、財報、中文多欄排版、科研 RAG
Marker	CLI / GUI / API；支援 PDF 以外 Office 格式	批量吞吐高；可選 LLM 後處理；GPL 程式碼 + 權重許可限制商用	90+ 語 OCR；圖片提取友好；複雜表格偶發弱項	英文書庫批量轉 MD、多格式歸檔、能接受許可審查的團隊

成本與算力（第二維對比）

工具	硬體	磁碟 / 模型	許可要點
pdf-inspector	CPU 即可；Apple Silicon 友好	無模型下載	MIT，可閉源嵌入
MinerU	準確路徑建議 NVIDIA GPU；CPU pipeline 可降級	首次執行約數十 GB 級依賴	自訂協議，商用需讀條款
Marker	CPU / CUDA / MPS（Mac）	Surya 權重需下載	GPL + RAIL-M，高收入實體需授權

場景怎麼選：決策矩陣

如果你是…	優先看什麼	推薦工具	備註
語料以電子版研報 / 合約為主	延遲與成本	pdf-inspector 為主	僅 Mixed 頁進 OCR
掃描件論文 / 老舊期刊	OCR 與公式	MinerU VLM 路徑	預留 GPU 或遠端 Mac
英文書籍批量數位化	吞吐	Marker 批次處理	先過許可審查
Agent 即時讀使用者上傳 PDF	P95 延遲	pdf-inspector → 條件 OCR	避免冷啟動拉模型
行動端 App 離線解析	包體與能耗	僅 pdf-inspector 層可行	掃描頁走雲端 OCR
合規要求資料不出境	自託管	三者皆可本地；勿預設雲 OCR	參考 說明中心 部署隔離

推薦組合（可疊加 Stack）

組合 A — 低成本 RAG 入口（推薦預設）

• pdf-inspector 分類 + 文字層 Markdown
• pages_needing_ocr → MinerU CPU 或雲 API
• 向量庫統一 chunk 策略（按標題 + 頁碼元資料）
• 適合：企業知識庫、客服文件、混合掃描語料

組合 B — 學術 / 中文金融高精度

• 全量 MinerU（VLM 後端）出 MD + JSON
• 質檢：layout 視覺化抽檢 5% 樣本
• 算力：本地 M4 24GB 試跑；峰值批次處理放 Cloud Mac M4 節點

組合 C — 海量英文歸檔 + CI 自動化

• Marker 夜間批次處理 → 物件儲存
• CI 裡用 pdf-inspector 對新上傳做「是否需 OCR」門禁
• 編排可參考 OpenClaw 雲端自動化 把解析 job 與建置節點分離

與 Cloud Mac / Apple Silicon 的關聯

MinerU 與 Marker 都可在 macOS 上透過 MPS 使用統一記憶體，但24GB 記憶體的 M4 節點更適合「夜間批次處理 + 白天遠端開發」分工：解析 job 獨占節點，避免與 Xcode 編譯搶 swap。pdf-inspector 極輕，可跑在 CI Runner 或 GitHub Actions 自託管 Mac 上做上傳門禁——先判定再決定是否觸發重型 OCR。

若團隊沒有常駐 GPU 伺服器，按月租用 Cloud Mac 跑 Marker/MinerU 批次任務，往往比為 OCR 單獨買卡更省維運；路由層仍建議留在應用側或輕量容器裡。

常見誤區

1. 用 benchmark 總分代替業務驗收——你的 PDF 可能是雙欄中文表注，和英文論文集分布不同。
2. 忽略「假文字層」——GID 編碼或亂碼層會被 pdf-inspector 標為 needsOcr，應走 OCR 而非強行抽取。
3. Marker / MinerU 二選一死磕——混合語料常需要「路由 + 雙引擎按頁分流」。
4. 不做頁級元資料——向量檢索無法引用「第幾頁表格」，幻覺更難糾。
5. 許可最後才看——Marker GPL 與權重條款可能阻斷 SaaS 分發路徑。

落地步驟（7 步 Action Plan）

1. 抽樣 30–50 份真實 PDF，用 pdf-inspector 統計 TextBased / Scanned / Mixed 占比。
2. 定義驗收指標——閱讀順序、表格結構、公式 LaTeX 可渲染率，各設及格線。
3. 實作路由層——高置信 TextBased 本地抽取；輸出 pages_needing_ocr 清單。
4. 為 OCR 段選引擎——中文複雜版式偏 MinerU；英文批量偏 Marker；記錄模型版本。
5. 部署算力——輕量路由放 CI；GPU 批次處理放 Cloud Mac 或專用機，見 Mac mini 租用。
6. 跑一週生產流量——記錄 P95 延遲、失敗頁、人工修稿比例，調路由閾值。
7. 寫入維運手冊——許可邊界、回滾版本、與 說明中心 對齊金鑰與資料留存策略。

FAQ

pdf-inspector 算不算 OCR 工具？

不算傳統 OCR。它先分類再抽取原生文字；只有標記為需 OCR 的頁才應交給 MinerU、Marker 或雲 API。

MinerU 和 Marker 哪個表格更準？

複雜學術表與中文多欄通常 MinerU 更穩；Marker 在英文批量與圖片提取上更順手，商用前請核對許可。

沒有 NVIDIA GPU 能跑 MinerU 嗎？

可以走 CPU pipeline，但高精度 VLM 建議 ≥8GB 顯存；Apple Silicon 可試 MPS 跑 Marker，或把批次處理遷到遠端 Mac。

RAG 應該先選哪個？

預設 pdf-inspector 做入口路由，再對掃描頁 OCR，可顯著降低平均成本與延遲。

三款工具能否串聯？

可以，也是 2026 年主流做法：inspector 分類 → 文字層本地 MD → 缺頁 MinerU/Marker → 統一 schema 入庫。

總結

「pdf-inspector、MinerU、Marker 誰最好用」沒有單一冠軍：pdf-inspector 贏入口與成本，MinerU 贏複雜結構與 CJK，Marker 贏英文批量吞吐。先回答「你的 PDF 有多少頁其實不需要 OCR」，再選引擎，比追逐榜單分數更省算力也更穩。

上線前用一個問題自檢：如果把 OCR 關掉，還有多少文件能直接出可用的 Markdown？ 這個比例應寫進你的架構評審第一頁。

延伸閱讀

• Gemini 4 vs GPT-5.6：2026 開發者選擇指南 →
• OpenClaw 與雲端 Mac：自動化鏈路 →