Indra OCR: Datalab's 1M-Parameter Model Reads 49 Pages per Second on CPU

Most modern OCR advances come from bigger vision-language models that need GPUs. Indra OCR goes the other way. Released on October 13, 2026 by Datalab, the company behind Marker and Surya, it is an OCR package built around a 1M-parameter recognition model that runs on ordinary CPUs and, per Datalab, reads 49 pages per second on 32 cores. The launch post states the speed is 11 to 17 times faster than Tesseract and PaddleOCR's PP-OCR text models, and that it also beats both on Datalab's OmniParseBench text score.

This post goes through the numbers, what the speed claim measures, the limits Datalab openly lists, and how to try it. Where we quote a figure, it comes from Datalab's own benchmarks on a benchmark Datalab created, so treat it as a strong starting point, not as independent proof.

Indra OCR at a glance

What you get besides text

Indra OCR returns structure, not just strings. Every line gets a bounding box. Every layout block gets a box, a label (text, section header, list, table, caption, footnote, form, table of contents, page header or page footer) and its place in the reading order. Pages that are upside down or sideways are rotated upright first. Markdown output uses headings, paragraphs, lists and HTML tables, and leaves out page headers and footers by default (--keep-furniture keeps them). JSON adds confidence per line, the source of each page's text (PDF text layer, OCR or both) and per-page timings.

That structure is what makes the tool useful for pipelines: classify a document, split it into sections, chunk it for retrieval, or feed pages to a heavier model only when needed. It fits the same document-processing space as the tools in our posts on LightOnOCR 3 and ParseBench, Interfaze 1 Lite, Cohere Parse 5 and DocJev with LlamaIndex.

The benchmark table

Datalab scored each engine on OmniParseBench, its new benchmark of 16,288 pass/fail tests on 2,937 pages. Every engine ran on x86 with 4 vCPUs, one page at a time, with default settings.

Datalab's reading: against plain OCR engines, Indra wins on both speed and text score. Against PaddleOCR's full PP-StructureV3 pipeline, Indra wins the headline, tables and layout at about 1/180 of the time per page, but PP-StructureV3 reads text better in default mode (55.6 vs 41.3). With --math enabled, Indra passes it on text too (57.5 vs 55.6). One PP-StructureV3 shard stalled on its first page, so its row omits 19 pages.

How to read the speed claim

The 49 pages per second figure comes from a throughput run on an AMD EPYC machine with no GPU, using 300 OmniParseBench pages with one single-threaded worker per core. Scaling by cores, Datalab reports 7.3 pages per second on 4 cores, 14.2 on 8, 27.2 on 16 and 49.4 on 32. At 32 cores that is 11.5 times PaddleOCR's text models and 16.9 times Tesseract. Three things to keep in mind:

• Model loading is excluded. A short 300-page job including model loading ran at 37.7 pages per second.
• Digital PDFs are faster. When a PDF has a usable text layer, Indra reads the layer instead of running OCR: median 130 ms per page versus 304 ms for pages that needed OCR.
• Your pages decide. Clean print benchmarks well; degraded scans, handwriting or complex tables will not.

Datalab also notes that faster settings exist for competitors: Tesseract with the English model and one thread takes 3.4 seconds a page, and PP-StructureV3 with optional modules off and mobile OCR models takes 10.5 seconds. Indra is still 15 to 45 times faster per page than those faster settings, by Datalab's measurement.

The caveat on who made the benchmark

OmniParseBench is Datalab's own benchmark, and the engine in this comparison is also from the benchmark's author. A sensible approach is to reproduce the Indra rows (the repo includes bench/opb_indra.py) and run the tool on a sample of your own documents before committing.

Limits Datalab lists

Datalab is direct about what Indra is not:

1. Complex tables. Simple tables come out clean, but multi-level headers, merged cells or tables without ruling lines often lose structure. The table score is 56.4.
2. Handwriting. Not read yet; OmniParseBench handwriting tests score about 8%.
3. Scripts on scans. OCR covers Latin, Cyrillic, Greek, Devanagari, Bengali and Chinese only. Arabic, Hebrew, Thai, Japanese kana, Korean Hangul and others are read only from a digital PDF's text layer. Vertical text is unsupported.
4. Math. Plain text unless --math is on, and old scanned math is hard. The math mode adds about 360 ms per page on one x86 test and cuts throughput by 30 to 35%, and it slightly lowers the table score because some numbers in cells are read as math.

"If your pages are mostly clean print in the scripts above, it should do very well," the post says. "If they're handwritten, badly degraded or full of complex tables, it isn't the right tool."

Quickstart

pip install indra-ocr
indra-ocr paper.pdf                    # markdown to stdout
indra-ocr *.pdf --out results/         # one .md per file, all cores
indra-ocr scan.png --format json       # lines, boxes, layout blocks

From Python:

import indra_ocr

conv = indra_ocr.load()
for i, page in conv.convert("paper.pdf"):
    print(page.markdown)

The first run downloads models from Hugging Face. A local viewer, indra-ocr-viewer, draws boxes and reading order over each page. For batches, the CLI and indra_ocr.convert_many run one single-threaded worker per core, one page per task, so even a single long PDF uses every core. The code is at github.com/datalab-to/indra and the model at huggingface.co/datalab-to/indra-ocr. Check the license and any commercial terms on the repo and model card before using it in a product.

Where it fits in a pipeline

A practical design is a two-stage pipeline: run Indra on everything, flag low-confidence pages or tables, and send only those to a heavier vision-language model. That keeps GPU spend proportional to difficulty. The same logic underlies agent pipelines where cheap models do triage, as in our write-up of Tencent's Youtu-Parsing Omni.

Why a tiny OCR model matters

Document pipelines often process millions of pages, and the bill is dominated by compute. A back-of-envelope example using Datalab's own throughput figure: at 49 pages per second, one 32-core machine could read roughly 4.2 million pages a day if it ran flat out (49 times 86,400 seconds), before queueing, I/O and model-loading overheads, which will reduce the real number. Tesseract at 2.9 pages per second on the same 32 cores would manage about a quarter of a million. These are our calculations from the vendor's numbers, not measured results, but they show why a 15x speedup changes which workloads are feasible on CPU-only infrastructure.

Small models also change deployment. A 1M-parameter recognizer can run inside a data-processing job, a serverless function or an edge box without GPU provisioning, and it can sit in front of a more expensive model as a gate. Datalab's reasoning in the post is that for many digital and scanned documents "speed is more important than accuracy": good-enough text enables classification and segmentation, and many teams can only run on CPU. That is the same trade-off behind the broader move to small, specialized models for narrow jobs, such as the fine-tuned Qwen3.5 9B that beat frontier models on Coinbase's fraud task.

What to test before adopting

1. Run 200 to 500 of your own pages through Indra, Tesseract and your current engine, and compare text, tables and reading order by hand on a sample.
2. Measure end-to-end throughput including model loading, PDF rendering and your storage, not only the benchmark loop.
3. Check which of your documents have text layers; those take the faster path.
4. Decide a confidence threshold for escalating pages to a larger model.
5. Review the repository license and the model card for commercial restrictions.

Bottom line

Indra OCR is a credible answer to a boring but widespread problem: getting decent text and layout from lots of documents without paying for GPUs. The speed gap over Tesseract and PaddleOCR text models is large enough that even a generous discount for vendor benchmarking leaves a real advantage. Its limits are stated plainly, so test it on your own pages, check the license, and keep a stronger model in reserve for the hard cases.

Figures come from Datalab's October 13, 2026 launch post and may change as the project is updated.

Related reading

• LightOnOCR 3 and ParseBench
• Interfaze 1 Lite open-weight OCR model
• Cohere Parse 5 document parsing
• DocJev document classification with LlamaIndex
• Tencent Youtu-Parsing Omni
• OCR It Chrome extension with offline Tesseract