Indra OCR needs a source-mix benchmark
In short: Indra OCR is fast on CPUs, but its auto-mode score mixes text-layer extraction with OCR; benchmark each document class separately.
Datalab released Indra OCR on 13 October 2026 and reported 49.4 pages per second on 32 AMD EPYC CPU cores over 300 OmniParseBench pages. The 1M-parameter model is small enough to make CPU document ingestion interesting.
The useful answer is narrower than the speed headline. Indra OCR’s default auto mode can bypass OCR when a PDF already has a usable text layer, while ocr mode always recognises the rendered page. A production benchmark therefore needs a source mix: native PDFs, clean scans and documents that are likely to fail.
Indra OCR’s auto mode is not one OCR workload
The launch post reports 41.3 text accuracy in auto mode and 33.5 in OCR-only mode. That gap matters because the auto path is allowed to extract an existing PDF text layer instead of applying the model to every page.
| Vendor-reported run | Result | Important boundary |
|---|---|---|
| 32-core OCR throughput | 49.4 pages/s | 300 pages, one worker per page, model loading excluded |
| Short job with loading | 37.7 pages/s | Includes model start-up |
| 4-vCPU single page | 228 ms median | One named vendor setup |
| Auto vs OCR-only text score | 41.3 vs 33.5 | Auto may use a native text layer |
These are Datalab’s results; I did not reproduce the benchmark.
The distinction is not a gotcha. Using the text layer is sensible when it is reliable. The problem begins when a mixed benchmark is read as a uniform recognition result and carried into a RAG capacity plan.
What the 27-second Indra OCR video establishes
I inspected the complete X thread and video. Frames around 8, 16 and 27 seconds show the latency claim, the benchmark comparison and the install/source cards. The video establishes the vendor’s launch argument; it does not show a controlled run across your invoice scans, tables or multilingual PDFs.
The repository and model card also put useful limits beside the launch. The code is Apache-2.0, while the model weights use modified OpenRAIL-M terms with commercial restrictions. Documented weak areas include handwriting, complex tables, several scripts in scanned images and old scanned mathematics.
My RAG pilot would stratify the source mix
This is labelled editorial judgment, not a Trigent or client result. For a hypothetical ingestion pilot, I would freeze a representative set of native PDFs, clean scans and failure-heavy documents. For each class, record accepted pages, text quality, median and tail latency, and the rate that needs a heavier fallback.
That changes the buying question from “is Indra fast?” to “which pages can Indra safely clear from the expensive path?” A small prefilter can be valuable without winning every page. The architecture earns its place when routing keeps failures visible.
Where the Indra OCR claim holds and breaks
The reported throughput is a good reason to test CPU-first ingestion, especially where GPU scheduling would dominate a light document workload. It is not evidence that one 49.4-pages-per-second number applies to a single worker, includes loading or predicts every document class.
I did not install Indra OCR, inspect its weights in execution, reproduce OmniParseBench or verify production licensing for a specific use. Treat the figures as vendor-reported launch evidence and validate the applicable model terms before deployment.
What's in it for you
- Keep native PDFs on the cheap path without letting them inflate the OCR score.
- Measure fallback rate by document class before estimating ingestion cost.
- Separate code licence, model licence and benchmark evidence in the production decision.
Benchmark the document mix you will ingest, not the easiest route hidden inside an average.
