Surya OCR 2 packs document parsing into 650M parameters

Every RAG pipeline I've audited eventually hits the same wall: the PDF parser.

Scanned contracts, handwritten intake forms, tables that collapse into word soup. Teams either pay per-page API fees or duct-tape five specialized models together. Datalab's answer in May 2026 was blunt: rebuild Surya as a single 650M vision-language model and ship state-of-the-art numbers at sub-3B scale.

What Surya OCR 2 actually does

Surya 2 is a ground-up rework. One 650M-parameter VLM (Qwen3.5-style architecture) handles:

• Full-page OCR
• Layout analysis (headers, images, tables)
• Reading order
• Table recognition (rows and columns)

Text-line detection stays a separate lightweight EfficientViT model. Layout, OCR, and table tasks share the same VLM weights.

Datalab: Announcing Surya OCR 2

Outputs moved from v1's text_lines to structured blocks with HTML, bounding boxes, and inline LaTeX for math. That's a breaking API change. Budget migration time if you're on Surya 1.x.

The benchmark that matters

On olmOCR-bench, Surya 2 hits 83.3%. Best score under 3B parameters. For context:

You're within ~4 points of models 54x larger. For private document pipelines, that gap often loses to latency and hosting cost.

Multilingual coverage is the other headline: 87.2% average across 91 languages on Datalab's internal eval, with 38 languages at or above 90%.

Speed and where it runs

Datalab reports 5.35 pages/sec on a single RTX 5090 at 128 concurrent requests. Apple Silicon is viable through llama.cpp at roughly 0.1 pages/sec in community reports. Slow for batch OCR farms. Fine for laptop-side prototyping.

Inference backends:

• vLLM + Docker + NVIDIA Container Toolkit on GPU
• llama.cpp on CPU or Apple Silicon

pip install surya-ocr

v2 API sketch:

from surya.inference import SuryaInferenceManager
from surya.recognition import RecognitionPredictor

manager = SuryaInferenceManager()  # auto-spawns vllm or llama-server
rec = RecognitionPredictor(manager)
predictions = rec([image])

datalab-to/surya on GitHub

Licensing (read before production)

• Code: Apache 2.0
• Weights: modified OpenRAIL-M (free for research, personal use, startups under $5M funding/revenue)

Broader commercial weight licensing goes through Datalab's pricing page. Don't assume Apache 2.0 covers the checkpoint.

When I'd pick Surya 2 over a cloud API

Good fits:

• On-prem or VPC-bound documents (health, legal, finance)
• Multilingual intake without per-language model sprawl
• RAG prep where layout and tables must survive chunking
• Cost-sensitive batch jobs where 650M local beats per-page SaaS

Stick with cloud parsers when:

• You need managed SLAs and zero GPU ops
• Documents are mostly clean digital PDFs (cheaper text extraction may suffice)
• Compliance requires a vendor's BAA/DPA today, not next quarter

Integration tips from client work

1. Chunk on block boundaries, not arbitrary token windows. Tables die when you split mid-row.
2. Store HTML + bbox metadata for citation UIs. Users trust answers that highlight source regions.
3. Benchmark on your docs, not leaderboard PDFs. Handwriting and stamp noise vary wildly by industry.
4. Plan v1 → v2 migration if you cached Surya 1 outputs. Schema changes are real.

Try without installing via the Datalab playground.

Bottom line

Surya OCR 2 is the strongest argument I've seen this year for small specialist VLMs beating "throw a 7B generalist at it." If document parsing is on your critical path, run it on a sample of production PDFs before the next invoice from your cloud OCR vendor.

Need help wiring OCR into a private RAG or ops workflow? Book a free call.