Indra OCR: a 1M-parameter tiny model that reads 49 pages per second on CPU, over ten times faster than Tesseract
What this project does
Indra OCR is a tiny OCR model from Datalab with only 1 million parameters, yet it reads up to 49 pages per second on pure CPU. It turns PDFs and images into markdown, plain text, or JSON with bounding boxes. Put simply, it does the old job of "turn scans and screenshots into copyable, searchable, database-ready text," but with a suspiciously small model that gets it done on a machine with no GPU. For anyone processing contracts, papers, or invoices in bulk on a server, that means you do not need to provision a graphics card just for OCR.
Why it is trending
OCR looks like a solved, old problem, but "fast, accurate, and cheap" is forever a hard requirement. Indra hits exactly that. It needs no GPU: on a plain 4-core x86 cloud vCPU, per-page latency is about 230 ms, and throughput is 11 to 17 times faster than Tesseract and PaddleOCR on the same machine. The sharper point is accuracy — it scores 41.3 on the OmniParseBench text item, ahead of PaddleOCR's PP-OCR (35.8) and Tesseract (19.3). That "tiny model beats the old heavyweights" reversal took it past 350 stars in three days and pulled in a batch of engineers who want to cut cost.
Technical highlights
It is not mere character recognition but a full pipeline: line detection first boxes each text line, then CTC recognition turns the image into a character sequence, then reading order is sorted, and finally structured markdown is emitted — headings, lists, and paragraphs are reconstructed as faithfully as possible. The model is released in ONNX format, so it is framework-agnostic and runs in most inference setups directly. The output also carries bounding boxes, letting you trace "which part of the original image held this text," which document-extraction people will love. One million parameters means tiny memory footprint — you can even squeeze it onto an edge device without trouble.
Who it is for
I think it fits three crowds best. First, back-end and data engineers who must batch-convert documents on cheap GPU-less machines and save on graphics cards. Second, products doing document intelligence and receipt extraction that need fast, coordinate-bearing structured output. Third, researchers and edge-computing scenarios that want OCR on a small device without depending on the cloud. It is not for extreme handwriting or wildly complex layouts — there you still want a larger specialist model.
Quick start
Install is one line: pip install indra-ocr. Model weights are on Hugging Face (datalab-to/indra-ocr), or you can try it online at the Datalab Playground. Drop a PDF or image in, and you get markdown or boxed JSON; the docs site documentation.datalab.to has the full API reference.
How it compares
Against Tesseract, Indra is both faster and more accurate, and it emits structured markdown instead of plain text. Against PaddleOCR, it is 11-17 times faster on the same machine with higher accuracy, and it avoids Paddle's heavier dependency chain. Against cloud OCR like AWS Textract or Azure, it is fully local, keeps data on premises, and costs zero per page. In short: Tesseract is the old workhorse, PaddleOCR the sturdy horse, and Indra a greyhound that eats little and runs fast — on the CPU track, it maxes out the price-performance ratio.
One more thought
The ONNX choice matters for deployment. It means Indra is not tied to one training framework — you can infer with the same weights in Python, C++, or even a browser, and drop it into an edge box, an intranet service, or an offline device with data never leaving the premises. I particularly like it for "bulk digitization of receipts and contracts": a small GPU-less server finishes thousands of pages overnight, and by morning the markdown and boxed JSON are both ready, at a cost close to just the electricity. One boundary to state clearly: it aims for the practical line of "fast and accurate enough," and on extreme handwriting, cross-page tables, or artistic fonts the accuracy drops, where you still want a larger specialist model or human proofreading. So position it as the "first-pass OCR for everyday documents," not the "finish line for every hard problem," and the price-performance stays highest.
Picking your input
Indra reads both PDF and image, but for scanned PDFs the line-detection stage does most of the heavy lifting, so feeding clean, high-DPI pages pays off more than tweaking the model. If your pipeline already emits images per page, you can skip the PDF parser entirely and just stream images in. For most teams the sweet spot is a nightly batch job: dump a folder of documents in, wake up to markdown and boxed JSON, and let your downstream extraction code trust the coordinates Indra returns rather than re-detecting layout itself.