When teams build RAG, contract review, or paper knowledge bases, the debate often starts with "MinerU or Marker?" What actually slows the pipeline is feeding text-layer PDFs into GPU OCR—batch jobs jump from seconds to minutes while Agents wait for documents to become ready. Firecrawl's open-source pdf-inspector makes the fix obvious: classify first, extract native text, OCR only the pages that need it.
This guide is for iOS, Flutter, and backend developers piping PDFs into vector stores or Agents, and for teams evaluating a Cloud Mac node for local parsing. Last updated August 6, 2026; tool versions and licenses follow each project's GitHub repo.
Why "OCR everything" breaks document pipelines
Enterprise PDF corpora include reports, papers, invoices, and prospectuses that already carry an extractable text layer—no vision model required per page. The traditional approach—calling MinerU, Marker, or a cloud OCR API for every file—creates three hidden costs:
- Latency tax — pure-text PDFs could return Markdown in hundreds of milliseconds but queue behind GPU jobs instead.
- Structure tax — OCR can scramble reading order; tables and footnotes become harder to fix in post-processing.
- License tax — Marker and similar tools attach commercial terms to model weights; full OCR amplifies compliance surface.
The 2026 framework is entry classification → local text extraction → per-page OCR fallback. On opendataloader-bench's 200-PDF set, pdf-inspector scores about 0.875 in no-OCR mode and finishes the full library in roughly 2.8 seconds—a different universe from multi-minute ML pipelines.
How to classify AI PDF tools (three entry types)
These three tools are not rivals on a single leaderboard—they sit at different pipeline layers:
| Type | Example | Core action | Typical latency |
|---|---|---|---|
| A. Routing / text-layer extraction | pdf-inspector | Classify TextBased / Scanned / Mixed; native text → Markdown | ~20ms classify + ~150ms/doc extract |
| B. High-accuracy OCR pipeline | MinerU | Layout analysis, table HTML, formula LaTeX, 84-language OCR | Seconds to minutes/doc (GPU-dependent) |
| C. High-throughput OCR pipeline | Marker | Surya stack, multi-format input, optional LLM polish | Pages/sec at scale (GPU) |
Asymmetric takeaway: the real divider is not model parameter count but whether you classify text layer vs scan at the pipeline entry. Without that layer, the strongest OCR engine still pays for documents that never needed it.
Core comparison: pdf-inspector vs MinerU vs Marker
The table below uses consistent dimensions so you can paste it into a tech-selection doc. "Execution" covers batch embedding and output control; "Context" covers layout, tables, formulas, and multilingual fidelity.
| Tool | Entry | Execution | Context | Best fit |
|---|---|---|---|---|
| pdf-inspector | Node / Python / Rust CLI; Agent pre-step | No ML dependency; pages_needing_ocr per-page routing; MIT license |
Native-text Markdown, dual-mode tables, multi-column order; no scan OCR | Backends building hybrid pipelines; Firestore / S3 PDF preprocessing |
| MinerU | CLI / Docker / API; CPU and VLM backends | Strong on OmniDocBench-style docs; VLM path needs ≥8GB VRAM; custom OSS license | Tables, formulas, CJK strength; header/footer stripping; JSON + MD output | Academic libraries, financial reports, Chinese multi-column RAG |
| Marker | CLI / GUI / API; PDF plus Office formats | High batch throughput; optional LLM post-process; GPL code + weight license limits | 90+ language OCR; good image extraction; complex tables occasional weak spot | Bulk English digitization, multi-format archives, teams that can review licenses |
Cost and compute (second comparison)
| Tool | Hardware | Disk / models | License notes |
|---|---|---|---|
| pdf-inspector | CPU only; Apple Silicon friendly | No model download | MIT; embed in closed source |
| MinerU | NVIDIA GPU recommended; CPU pipeline degrades | First run pulls tens of GB of deps | Custom license—read before commercial use |
| Marker | CPU / CUDA / MPS (Mac) | Surya weights required | GPL + RAIL-M; high-revenue entities need review |
How to choose: decision matrix
| If you are… | Prioritize | Pick | Notes |
|---|---|---|---|
| Corpus is digital reports / contracts | Latency and cost | pdf-inspector first | OCR only Mixed pages |
| Scanned papers / legacy journals | OCR and formulas | MinerU VLM path | Budget GPU or remote Mac |
| Bulk English book digitization | Throughput | Marker batch | License review first |
| Agent reads user-uploaded PDFs live | P95 latency | pdf-inspector → conditional OCR | Avoid cold-start model pulls |
| Mobile app offline parsing | Bundle size and power | pdf-inspector layer only | Scan pages → cloud OCR |
| Data must stay on-prem | Self-hosting | All three locally; skip default cloud OCR | See help center for isolation |
Recommended stacks (layered combos)
Stack A — low-cost RAG entry (default)
pdf-inspectorclassification + text-layer Markdownpages_needing_ocr→ MinerU CPU or cloud API- Unified chunk strategy in the vector store (title + page metadata)
- Fit: enterprise knowledge bases, support docs, mixed scan corpora
Stack B — academic / Chinese finance high precision
- Full MinerU (VLM backend) → MD + JSON
- QA: layout visualization on 5% sample
- Compute: trial on local M4 24GB; peak batch on Cloud Mac M4 nodes
Stack C — massive English archive + CI automation
- Marker overnight batch → object storage
- CI gate with pdf-inspector on new uploads ("needs OCR?")
- Orchestration: see OpenClaw cloud automation to separate parse jobs from build nodes
Cloud Mac and Apple Silicon fit
MinerU and Marker both run on macOS via MPS unified memory, but a 24GB M4 node fits a clean split: batch parsing overnight, remote dev by day—parse jobs do not fight Xcode compiles for swap. pdf-inspector is light enough for a CI runner or self-hosted GitHub Actions Mac upload gate: classify before triggering heavy OCR.
Teams without a permanent GPU server often spend less renting Cloud Mac monthly for Marker/MinerU batches than buying dedicated OCR hardware—while keeping the routing layer in app code or a small container.
Common mistakes
- Benchmark totals replace business acceptance — your PDFs may be two-column Chinese tables with footnotes, not English paper collections.
- Ignoring "fake text layers" — GID-encoded or garbled layers get
needsOcrfrom pdf-inspector; route to OCR, don't force extraction. - MinerU vs Marker as a forced binary — mixed corpora often need routing plus dual engines per page.
- Skipping page-level metadata — vector search can't cite "page 12 table," making hallucination harder to correct.
- Licenses reviewed last — Marker GPL and weight terms can block SaaS distribution paths.
Rollout steps (7-step action plan)
- Sample 30–50 real PDFs and run pdf-inspector to measure TextBased / Scanned / Mixed ratios.
- Define acceptance metrics — reading order, table structure, formula LaTeX render rate; each gets a pass line.
- Implement routing — high-confidence TextBased extracts locally; output
pages_needing_ocrlists. - Pick OCR engines per segment — Chinese complex layout → MinerU; English bulk → Marker; log model versions.
- Deploy compute — light routing on CI; GPU batch on Cloud Mac or dedicated hardware; see Mac mini rental.
- Run one week of production traffic — track P95 latency, failed pages, manual fix rate; tune routing thresholds.
- Write the ops runbook — license boundaries, rollback versions, aligned with help center key and retention policies.
FAQ
Is pdf-inspector an OCR tool?
Not traditional OCR. It classifies then extracts native text; only pages marked for OCR should go to MinerU, Marker, or a cloud API.
MinerU vs Marker for tables?
Complex academic tables and Chinese multi-column layouts usually favor MinerU. Marker is smoother for English bulk and image extraction—verify licenses before commercial use.
Can MinerU run without NVIDIA GPU?
Yes via CPU pipeline, but high-accuracy VLM wants ≥8GB VRAM. On Apple Silicon try MPS with Marker, or move batch jobs to a remote Mac.
What should a RAG pipeline start with?
Default to pdf-inspector routing, then OCR scan pages—this cuts average cost and latency materially.
Can the three tools chain together?
Yes—that's the 2026 mainstream pattern: inspector classify → local MD for text layers → MinerU/Marker for gaps → unified schema into the store.
Summary
There is no single winner in "pdf-inspector, MinerU, Marker—which is best?" pdf-inspector wins entry and cost, MinerU wins complex structure and CJK, Marker wins English bulk throughput. Answer how many pages never needed OCR before picking engines—that beats chasing leaderboard scores and saves compute.
One acceptance question before launch: if you turned OCR off, how many documents still produce usable Markdown? Put that ratio on the first page of your architecture review.
Further reading
Run PDF batch jobs and CI gates on Cloud Mac
MinerU / Marker batch parsing and pdf-inspector upload gates fit well on dedicated M4 nodes—no memory contention with your local dev machine, scale compute month by month.
Trial routing + OCR stacks on real corpus for a week before locking node size. View Mac cloud plans · See pricing