GitHub Repo
Surya 2.5 updates OCR model, with official tests showing about 1.7× higher single-GPU throughput
Datalab released Surya 2.5 on October 29, using a more compact page output format to reduce generation costs and publishing its test setup. The new package switches to the model by default, but workflows that need table row and column coordinates must continue using Surya 2.

Datalab released Surya 2.5, a 689-million-parameter OCR model, on October 29, and made the new weights the default in surya-ocr 0.23.0. The update affects both inference efficiency and interface behavior: surya_table now outputs table HTML by default, and the new model does not support geometric coordinates for table rows and columns. Existing workflows that rely on this data need to explicitly specify a Surya 2 checkpoint. Release notes
One key efficiency improvement is shorter output. The new version expands the vocabulary with common multi-character units and uses a more compact page format, reducing the amount of decoding required per page. In official tests using a single H100, 192 DPI, and 32 concurrent requests, it processed 4.52 pages per second, compared with 2.72 pages for the previous version with multi-token prediction (MTP)—about a 1.7× increase. The comparison used the same server settings and a 300-page document, but the pages had already been rendered, so the result should not be treated as the speedup for the entire PDF processing pipeline. Testing methodology
For batch document processing, it also matters that a small number of pages do not keep generating output for too long. The release notes report that, in 192 DPI tests, the share of requests that hit the output limit fell from 3.8% for the previous version with MTP to 0.1%. This suggests fewer unusually long pages may tie up inference resources, though actual retry costs still depend on document content and application settings. The release also adds an experimental Apple Silicon MLX backend. Version changes
For accuracy, Datalab reports an overall OmniParseBench score of 85.9, compared with 83.3 for the previous version. This is an average of text, table, and layout scores; it should not be interpreted as character recognition accuracy. The figures were published by the development team and still await independent reproduction. Before upgrading, engineering teams should check output quality on their own Traditional Chinese documents, scans, and complex tables, then measure end-to-end processing time. The licenses also need separate review: the code is under Apache 2.0, while the weights use a modified OpenRAIL-M license. Check the applicable terms before commercial deployment. Official announcement