Surya 2.5: 1.7x faster, best open OCR under 1B

Source: Datalab•

Surya 2.5: 1.7x faster, best open OCR under 1B

Surya 2.5 reads 1.7x as many pages per second as Surya 2 and scores 85.9 on OmniParseBench, the best of any open model under 1B parameters.

We’re releasing Surya 2.5: 1.7 times faster than Surya 2, and the most accurate open OCR model under 1B parameters. It reads 4.5 pages per second on one H100, against 2.7 for Surya 2 (fig. 1), and scores 85.9 on OmniParseBench, the highest of any open model its size (fig. 2). It has 689M parameters, open weights, and almost never loops.

Here’s what’s new:

  • 1.7x faster: 4.5 pages per second on one H100, against 2.7 for Surya 2 with MTP
  • Best open model under 1B: 85.9 on OmniParseBench, up from 83.3 for Surya 2; tables 78.3 vs 74.3
  • olmOCR-bench: 83.7, up from 82.8
  • Looping: 0.1% of requests loop until the output limit, against 3.8% for Surya 2 with MTP
  • Multilingual: level on text across 91 languages, stronger on tables (58.1 vs 54.5); 21 languages score 90% or above, against 15
  • Larger vocabulary: 88,526 tokens, including emoji and math letters Surya 2 could not write; a page takes 2.6 times fewer tokens
  • License: same as Surya 2: code is Apache 2.0, weights are modified OpenRAIL-M (free for research, personal use, and startups under $5M)

Get it:

  • Model weights
  • Playground - try Chandra 2.5, our larger and more accurate model, on your own documents
  • API

Other models’ scores are from the OmniParseBench dataset card, each run with its vendor’s recommended settings (per-model settings); Surya 2.5 was run the same way. Parameters are the total in the released weights. olmOCR-2 and Nanonets-OCR2-3B return no layout, so they have no headline.

Why we built it

Surya 2 is small and accurate, but it had three gaps. Its vocabulary had no tokens for emoji or for bold, italic and other styled math letters, so it could not write them. It wrote each page in many tokens. And on a few percent of pages it looped until it hit the token cap.

Surya 2.5 has a larger vocabulary and a more compact page format. The vocabulary has a token for every emoji in Unicode’s main emoji blocks and every styled math letter, plus about 20,000 common multi-character units, and it can still write every character Surya 2 could. With both, a page takes 2.6 times fewer tokens to write. And Surya 2.5 almost never loops.

Benchmark results

OmniParseBench

OmniParseBench is our open parsing benchmark: 16,288 pass/fail tests on 2,937 pages in 92 languages, scored by code with no model judge. The headline is the mean of the text, tables and layout scores.

All 2,937 pages; both models through surya-ocr 0.23.0 at 192 DPI with full-page regeneration on, so a looping page is retried; one run each. Intervals are 95% bootstrap intervals over pages. Details in the appendix.

Surya 2.5 is ahead in all three families; the largest gain is tables (+4.0).

Against other open models, Surya 2.5 has the highest score of those under 1B parameters (fig. 2), and the best layout score of any open model (95.7).

olmOCR-bench

Mean of three runs per model, same harness and settings for both (olmOCR-bench revision 54a96a6). With LightOn’s PP3 benchmark post-processing, the overall scores are 83.6 and 84.2.

Surya 2.5 is slightly higher overall, with the clearest gain on multi-column pages. Old scans remain the hardest category for both models.

Multilingual

We also evaluate on our internal benchmark of 91 languages, which covers text accuracy, layout, tables, math and reading order in documents from each language.

Overall pass rate: 74.9% for Surya 2.5 against 74.5% for Surya 2, across 91 languages (36,089 tests), on a newer, harder version of the benchmark than the 87.2% in the Surya 2 post. Text accuracy is level; the gain is in tables, +3.6 points (+2.0 to +5.3). 21 languages score 90% or above (Surya 2: 15) and 52 score 80% or above (47).

Top 15 widely spoken languages:

Pass rate is the share of tests that pass. Both models through surya-ocr 0.23.0 at 192 DPI, one run each; the tables interval is from a paired page-level bootstrap. The full 91-language table is in the Surya repository.

What the model can do

Surya 2.5 reads a full page in one pass and returns every block with its type, its position on the page, and its content: text and headings, tables as HTML, equations as LaTeX, captions, and page headers and footers, in reading order. The examples below are public OmniParseBench pages, run with the bf16 GGUF in llama.cpp on a Mac at 192 DPI; each shows the page, a detail, and Surya 2.5’s output for that detail.

Throughput

Surya 2.5 reads 1.7 times as many pages per second as Surya 2 with MTP at 192 DPI, and 2.3 times at 96 DPI; at 300 DPI the gap narrows to 1.15 times. Tail latency falls further: p95 is 11.3 s, against 26.0 s.

One H100, vLLM 0.25.1, same server settings and 300 OmniParseBench pages for every model. Pages per second, latency and tokens per page are at 32 concurrent requests; cap hits are pooled over 1, 8, 32 and 128 concurrent requests. Times are for the model server only (pages rendered in advance), and pages per second counts only pages that finished before the token cap. Latency by DPI and by concurrency is in the appendix.

Apple Silicon

On an M4 Max with llama.cpp (Metal), Surya 2.5 reads 3.1 times as many pages per second as Surya 2 at about the same tokens per second, because it writes far fewer tokens per page. Every Surya 2.5 page finished; Surya 2 hit the token cap on 4 of 32.

Apple M4 Max with 36 GB, on AC power; llama.cpp bbeb89d, llama-server --parallel 8; full-page OCR at 96 DPI; 16 public OmniParseBench pages, two rounds; pages per second counts completed pages. Peak memory is the server process.

Run Surya 2.5

The interface is the same as Surya 2: the manager starts a server on first use and stops it when the command exits (--keep_server leaves it up). surya-ocr 0.23.0 and later use Surya 2.5 by default. On NVIDIA GPUs the manager runs vLLM in Docker; if you install vllm yourself, keep it in a separate environment, since the package pins an OpenCV version that vLLM does not allow.

For the highest accuracy without running infrastructure, the Datalab API runs Chandra 2.5.

Limitations

  • No table coordinates. Surya 2.5 returns tables as HTML only. The table structure task that returns row and column boxes is not supported; use Surya 2 for it.
  • Hard pages stay hard. Old scans score 44.3 on olmOCR-bench, and Arabic 45.4% on our multilingual benchmark, level with Surya 2.

Appendix: reproducibility details

Throughput

Setup. One NVIDIA H100 80GB HBM3 per run (driver 580.126.09). vLLM 0.25.1 for every line, the GPU is not shared with anything else, bf16 unless stated. Every series gets the same server settings (flags below); Surya 2 with MTP differs only in its speculative-decoding configuration. Prefix caching and the multimodal processor cache are off, so no page benefits from a previous request.

Workload. 300 public OmniParseBench pages, rendered from PDF at each target DPI and fitted to the model’s 3072×2048 pixel cap. Full-page OCR with the same prompt for both models, greedy decoding, a 12,288 token output cap.

Measurement. A fixed number of concurrent requests (1, 8, 32 and 128) with a new request issued as each finishes. We measure over a 120 second window after a 30 second ramp, and report the requests that started in the window, including slow and failed ones. Latency is end to end as seen by the client. A page counts as complete only if it finished before the token cap. Cells are run in shuffled order, and we repeat anchor cells three times to estimate run-to-run noise.

Full vLLM flags: --dtype bfloat16 --max-model-len 24576 --max-num-seqs 256 --max-num-batched-tokens 8192 --enable-chunked-prefill --kv-cache-dtype auto --gpu-memory-utilization 0.85 --no-enable-prefix-caching --mm-processor-cache-gb 0 --limit-mm-per-prompt '{"image": 1}' --mm-processor-kwargs '{"min_pixels": 3136, "max_pixels": 6291456}'. Surya 2.5 is datalab-to/surya-ocr-2.5 at the revision released with the weights, Surya 2 is datalab-to/surya-ocr-2 at 3b3d4cdf. No stop string is set for either model.

Latency by DPI and concurrency.

Median latency per page (s), 32 concurrent requests

p95 latency per page (s), 32 concurrent requests

Pages per second by concurrency, 192 DPI

p95 latency per page (s) by concurrency, 192 DPI

Benchmarks

OmniParseBench and the multilingual set. One run per model, no stop string, one B200 per run, public scorer v1.0.0. Dataset revision 56a3c4f7.

  • Both models: run through a pre-release build of surya-ocr 0.23.0 with the package’s own prompt and decoding, on a vLLM 0.25.1 server set up with the package launcher’s settings for this GPU, at 192 DPI, with full-page regeneration on (the package default is off): a looping or unparseable page is asked again at a rising temperature up to six times, then read block by block. Surya 2 is datalab-to/surya-ocr-2 at 3b3d4cdf.
  • DPI sweep (fig. 3): Surya 2.5 through a plain vLLM 0.20.1 server, asked once per page with no regeneration, at 96, 150, 192 and 300 DPI (prompt: “OCR this image to HTML. Each block is a div with data-label and data-bbox (x0 y0 x1 y1, normalized 0-1000).”; temperature 0, 32,768 token cap); Surya 2 through surya-ocr 0.22.1 at the same resolutions, where several points needed resumed runs and the 300 DPI point combines a run with MTP and one without. These points show the shape of the trade-off; the comparison tables above use one setup for both models.

olmOCR-bench. The datalab harness (surya25 bundle), olmOCR-bench revision 54a96a6f (1,403 pages), vLLM 0.25.1 on our own server with MTP off, one B200, 12,384 token cap, 24 concurrent requests, figures as data, temperature 0 and top-p 0.1, no stop string, three passes per model on one server. Plain model output is the headline; PP3 post-processing is reported next to it. Paired per-test intervals on the first run (95%): overall +0.89 (+0.03 to +1.76), multi-column +1.92 (+0.46 to +3.56), tables +3.42 (−0.60 to +7.69); the other categories are within noise.

If you have feedback or want to integrate Surya 2.5 into your workflow, email [email protected] or find Vik on Twitter.

What this article says