54% of PDFs Don't Need OCR: How firecrawl/pdf-inspector Cuts GPU Costs 36x

Forum topic · ✨步子哥 · 2026-08-06

Summary

Most RAG pipelines treat every PDF page as a scanned document, sending all pages through GPU-based OCR. Firecrawl found that roughly 54% of PDF pages are actually text-based and have extractable text layers, making OCR redundant and wasteful. Their open-source Rust tool, pdf-inspector, classifies each page in 10-50 ms into four categories—TextBased, Scanned, ImageBased, or Mixed—by inspecting font encoding, text operators, and image coverage. Only pages lacking a real text layer are forwarded to OCR. In benchmarks on a 200-page PDF, the traditional OCR path took 17.117 s while pdf-inspector combined with native text extraction finished in 0.470 s, a 36x speedup driven entirely by skipping OCR rather than running faster OCR. The classifier uses no ML model, depends only on lopdf, and ships with Python, Node.js, and WebAssembly bindings. The article situates the approach alongside selective filtering patterns such as mantis-shrimp phonon shields and sparse MoE activation, argues that rule-based routers can efficiently steer AI workloads, and notes the limits: pdf-inspector classifies but does not extract, struggles with complex multi-column layouts, and can misclassify edge cases.

Key points

The "one-size-fits-all" PDF trap: Typical RAG pipelines route every page of an incoming PDF through GPU OCR, even though ~54% of pages (per Firecrawl's production traffic) are text-based PDFs with a real text layer that can be extracted directly.
What pdf-inspector does: A Rust classifier from firecrawl/pdf-inspector inspects each page's font encoding, text drawing operators, and image coverage in 10-50 ms and labels it as TextBased, Scanned, ImageBased, or Mixed.
Smart routing, not faster OCR: Text-based pages are extracted natively (millisecond latency, zero GPU). Only the remaining ~46% are sent to OCR. The speedup comes from skipping OCR, not from optimizing it.
Benchmark on a 200-page PDF: pymupdf4llm + full OCR = 17.117 s; pdf-inspector + native extract = 0.470 s — about a 36x speedup and a proportional cut in GPU cost.
Why Rust: zero-cost classification with no GC pauses, a single dependency on lopdf, no ML model files, and bindings for Python, Node.js, and WebAssembly.
Position in the Fire-PDF pipeline: pdf-inspector is the open-source classification stage; the GPU-heavy neural layout + OCR stage stays commercial. This mirrors the "rule systems do rules, AI does AI" division of labor.
Cross-domain principle: The piece frames selective filtering — mantis-shrimp phonon shields, sparse Mixture-of-Experts activation, PDF routing — as a recurring pattern where filtering is cheaper than processing.
Limits: pdf-inspector only classifies; extraction still needs another tool. Complex layouts (multi-column, tables, formulas) require downstream layout models, and edge cases where text-layer pages contain scans can be misclassified.

Findings

Headline statistic: ~54% of PDF pages in Firecrawl's traffic are text-based and do not need OCR.
Latency budget: classification 10-50 ms per page; native text extraction on the order of milliseconds; OCR reserved for the remaining pages.
End-to-end speedup: 36x on the 200-page benchmark (17.117 s → 0.470 s).
Dependency footprint: one Rust crate (lopdf); no model artifacts, no GPU required at the classification stage.
Integration paths: bindings available for Python, Node.js, and WebAssembly, so the classifier can be embedded in browser, server, or worker contexts.
Recommended users: RAG builders handling large PDF volumes, document-processing services looking to drop GPU spend, and anyone running a routing layer in front of OCR.

54% of PDFs Don't Need OCR: How firecrawl/pdf-inspector Cuts GPU Costs 36x

Summary

Key points

Findings

Links

Tags