Surya OCR 2.5 - OCR-модель от datalab-to на 689M параметров, заточенная под документы. Она распознаёт текст, размечает layout (таблицы, изображения, заголовки и другие элементы) вместе с порядком чтения и отдаёт таблицы в HTML, где объединённые ячейки передаются через colspan и rowspan. Заявленные цифры: 85.9 балла на OmniParseBench, 83.7% на olmOCR-bench, 4.5 страницы в секунду на одной H100 при 192 DPI (в 1.7 раза быстрее Surya 2 с MTP) и 74.9% на внутреннем бенчмарке из 91 языка. Все эти показатели приводит datalab-to в анонсе модели, независимых замеров на 30 октября 2026 года нет.
Границы видны сразу. Это документный движок: фото, вывески и естественные сцены разработчик называет вне цели. Геометрия строк и колонок таблиц в новой версии не выдаётся, для неё нужен чекпоинт Surya 2. Layout, OCR и table_rec работают только при запущенном бэкенде инференса, vllm или llama.cpp.
Материал пригодится тем, кто собирает пайплайн обработки сканов, PDF, счетов и табличных отчётов и выбирает OCR-движок под свои документы, железо и лицензионные рамки.
Что такое Surya OCR 2.5 и кому она адресована
Модель закрывает три задачи документного разбора: распознавание текста, структурный анализ страницы и перевод таблиц в HTML. Layout-анализ определяет, где на странице таблица, картинка или заголовок, и в каком порядке читать блоки. Таблицы уходят в HTML с сохранением объединённых ячеек. Мультиязычная часть заявлена на 91 языке.
Адресаты: разработчики, которые строят извлечение данных из PDF и сканов; команды, собирающие RAG-индекс по внутренним документам и желающие сохранить структуру таблиц; сервисы, которым нужен предсказуемый HTML вместо плоского текста. Для распознавания фотографий и сцен модель не предназначена, там понадобится другой инструмент.
Ключевые характеристики в одном экране
| Параметр | Значение |
|---|---|
| Разработчик | datalab-to |
| Размер | 689M параметров |
| OmniParseBench | 85.9 балла |
| olmOCR-bench | 83.7% |
| Скорость | 4.5 страницы/с на одной H100 при 192 DPI |
| Прирост к Surya 2 | 1.7x (Surya 2 с MTP) |
| Языки | 91 язык, 74.9% на внутреннем бенчмарке |
| Layout | таблицы, изображения, заголовки, порядок чтения |
| Таблицы | HTML с colspan и rowspan, без геометрии строк и колонок |
| Бэкенд инференса | vllm или llama.cpp для layout, OCR и table_rec |
| Код | Apache 2.0 |
| Веса | модифицированная AI Pubs Open Rail-M |
Все значения в таблице - заявленные разработчиком. Они полезны как ориентир для короткого списка кандидатов, но не заменяют прогон на своих документах.
Чем Surya 2.5 отличается от Surya 2
Единственное измеримое отличие, которое datalab-to приводит в анонсе, - скорость: 4.5 страницы/с против Surya 2 с MTP, то есть в 1.7 раза быстрее. Других различий в тексте нет, поэтому ждать от версии 2.5 иных улучшений качества без собственной проверки не стоит.
При этом Surya 2 остаётся в пайплайне. Её чекпоинт нужен, когда требуются координаты строк и колонок таблиц: SURYA_MODEL_CHECKPOINT=datalab-to/surya-ocr-2. Практический вывод: миграция на 2.5 имеет смысл ради скорости и HTML-таблиц. Если в задаче есть зависимость от геометрии ячеек, версии придётся держать обе.
Бенчмарки Surya OCR 2.5: что стоят 85.9 и 83.7%
Три метрики из анонса отвечают на разные вопросы, и смешивать их нельзя.
OmniParseBench и olmOCR-bench: в чём разница
OmniParseBench - комплексный бенчмарк разбора документов. 85.9 балла datalab-to называет лучшим результатом среди открытых моделей до 1B параметров, которые оценивала сама компания. Формулировка важна: это не лидерборд всех открытых моделей, а выборка разработчика. Модели крупнее 1B в такое сравнение не попадают по определению.
olmOCR-bench даёт 83.7%. Это отдельный набор задач, ориентированный на OCR, поэтому 85.9 и 83.7% нельзя складывать, усреднять или сравнивать между собой напрямую: разные наборы, разные метрики. Сопоставлять числа имеет смысл только с результатами других моделей на том же бенчмарке и в тех же условиях.
Третье число, 74.9%, получено на внутреннем наборе datalab-to из 91 языка. Слово «внутренний» здесь ключевое: это не публичный лидерборд, состав языков, объём и жанры документов известны только разработчику.
Скорость 4.5 страницы/с: что она значит на практике
4.5 страницы/с - потолок на одной H100 при 192 DPI. Арифметика простая: 10 000 страниц займут около 37 минут, 100 000 страниц - примерно 6 часов машинного времени на одной карте. Для оценки своего объёма разделите число страниц на 4.5 и добавьте запас на предобработку изображений и постобработку HTML.
Две оговорки. Первая: 192 DPI влияет и на скорость, и на качество, поэтому разрешение стоит зафиксировать в конфиге, чтобы результаты были воспроизводимы. Вторая: замеров на RTX, Apple Silicon или CPU в анонсе нет, и переносить 4.5 страницы/с на потребительскую карту нельзя. Если узкое место - скорость декодирования VLM на документах, пригодится разбор HPD-Parsing с 4752 токен/с на OmniDocBench, где ту же проблему решают через параллельное декодирование.
Layout, порядок чтения и таблицы в HTML: что реально умеет модель
Структурные возможности Surya 2.5 - главная причина, по которой её рассматривают вместо классических OCR-движков.
Порядок чтения: зачем он нужен для многоколоночных документов
Классическая проблема OCR на двухколоночных PDF: строки из левой и правой колонки склеиваются в одну, и текст теряет смысл. Layout-анализ с порядком чтения должен восстановить логическую последовательность блоков, чтобы на выходе получился связный поток, пригодный для индексации или перевода.
Точность порядка чтения datalab-to не публиковала, в анонсе есть только сам факт функции. Поэтому на документах с врезками, сносками и плавающими таблицами результат стоит проверять вручную: это самая частая точка отказа в подобных пайплайнах.
Таблицы как HTML с colspan и rowspan
Таблица выходит как HTML, объединённые ячейки передаются через colspan и rowspan. Для парсинга это удобнее плоского текста: шапка с объединёнными заголовками и сгруппированные строки сохраняют иерархию. Пример: прайс-лист, где категория занимает одну ячейку над тремя колонками с моделями. В HTML такая ячейка станет colspan="3", и дальше её можно разобрать штатным парсером или сразу вставить в веб-страницу.
Чего нет: координат строк и колонок. Если пайплайну нужны bounding box ячеек, HTML-вывод эту задачу не закрывает. Ещё деталь: таблицы читаются как HTML в full-page OCR, block mode и surya_table, то есть формат одинаковый во всех трёх режимах.
Ограничения Surya OCR 2.5, о которых нужно знать заранее
Список короткий, но каждый пункт способен остановить проект, если узнать о нём на этапе приёмки.
Геометрия таблиц: почему нужен чекпоинт Surya 2
Surya 2.5 не выдаёт геометрию строк и колонок. Попытка получить её через surya_table --mode simple заканчивается ошибкой: режим рассчитан на данные, которых новая модель не производит.
Обходной путь один: чекпоинт Surya 2 через переменную окружения SURYA_MODEL_CHECKPOINT=datalab-to/surya-ocr-2. На практике это означает либо два прохода (2.5 для текста и HTML, 2 для геометрии), либо отказ от координат в пользу HTML-структуры. Второй вариант дешевле и чаще достаточен, если конечная цель - извлечение данных, а не точная вёрстка. Требования к чекпоинту и бэкенду зафиксированы в описании модели.
Зависимость от vllm или llama.cpp
Layout, OCR и table_rec требуют запущенного бэкенда инференса: vllm или llama.cpp. Детекция работает чисто на torch и без бэкенда.
Следствие для развёртывания: установка Python-пакета не делает систему готовой. Нужен поднятый сервер инференса и ресурсы под него, отдельно от процесса, который вызывает детекцию и собирает результат. Планируйте и память GPU, и время на настройку бэкенда. Конкретных требований к VRAM и версиям в анонсе нет, их придётся выяснять на своём железе.
Фото и естественные сцены: не сюда
Формулировка разработчика однозначная: модель специализирована на документном OCR, качество на фото и естественных сценах не было целью. Практический вывод: вывески, уличные снимки, чеки, снятые на телефон в сложном освещении, - не её сценарий, для них нужен другой инструмент. Сканы, PDF и документы с ровной геометрией - её территория.
Четвёртое ограничение лежит не в технике, а в юридической плоскости: лицензия весов ограничивает бесплатное коммерческое использование порогом в $5 млн. Ниже об этом отдельный раздел.
Лицензия: Apache 2.0 для кода, AI Pubs Open Rail-M для весов
Лицензируются два разных объекта, и путать их дорого.
Порог $5 млн: как считать и что он значит
Веса идут по модифицированной AI Pubs Open Rail-M. Бесплатно: исследования, личное использование и стартапы с оборотом или финансированием до $5 млн. Для более широкого коммерческого использования datalab-to предлагает коммерческую лицензию через страницу с ценами. Именно так условия сформулированы в анонсе.
В формулировке два разных показателя: выручка и привлечённое финансирование. Смотреть нужно на свой случай, а точные определения и правила расчёта читать в тексте лицензии, а не в пересказе статьи. Перед коммерческим запуском условия стоит показать юристу: описание в блоге не заменяет лицензионный текст. Конкретных сумм сверх порога datalab-to не называет, поэтому бюджет на лицензию придётся выяснять в переписке с правообладателем.
Что покрывает Apache 2.0, а что нет
Код Surya распространяется под Apache 2.0: его можно использовать, менять и распространять по правилам этой лицензии. Веса - отдельный объект и отдельные условия. Свободный код не означает свободные веса для любого коммерческого продукта; проверять нужно именно условия использования весов.
Практический вывод по ролям: небольшой стартап на ранней стадии обычно проходит по порогу и платить не должен, крупной компании нужно закладывать лицензионные расходы в стоимость проекта. Игнорировать этот пункт рискованно: юридические претензии по весам приходят уже после того, как продукт запущен.
Как запустить Surya OCR 2.5: практический сценарий
Логика запуска простая: сначала инфраструктура, потом режим, потом проверка ограничений.
- Поднять бэкенд инференса: vllm или llama.cpp. Без него layout, OCR и table_rec не работают, доступна только детекция на torch.
- Выбрать режим под задачу.
- Решить, нужна ли геометрия строк и колонок. Если да - добавить проход на чекпоинте Surya 2 через
SURYA_MODEL_CHECKPOINT=datalab-to/surya-ocr-2. - Зафиксировать DPI. В замерах разработчика использовался 192 DPI; то же значение стоит закрепить в конфиге, чтобы сравнивать результаты между запусками.
- Прогнать пачку своих документов и сравнить с текущим OCR. Бенчмарки разработчика этого не заменяют.
Какой режим выбрать: full-page OCR, block mode или surya_table
Full-page OCR обрабатывает страницу целиком вместе с layout и порядком чтения. Подходит, когда на входе обычный скан или PDF и нужен структурированный текст.
Block mode пригодится, когда нарезка на блоки уже есть (например, из этапа детекции) и распознавать нужно конкретные фрагменты. На больших пакетах такой подход экономит время.
surya_table включают, когда в фокусе таблицы и нужен HTML с colspan и rowspan.
Во всех трёх режимах таблицы читаются как HTML, геометрии нет ни в одном. Отдельное предупреждение: surya_table --mode simple возвращает ошибку, так как этот режим рассчитан на геометрию, которую Surya 2.5 не выдаёт.
Чек-лист перед запуском
- Бэкенд vllm или llama.cpp поднят и отвечает на запросы.
- Понятно, нужны ли координаты ячеек; если да - есть план на чекпоинт Surya 2.
- Компания проходит по порогу $5 млн либо получена коммерческая лицензия весов.
- На входе сканы и PDF, а не фотографии сцен.
- DPI зафиксирован, значение 192 DPI взято как отправная точка.
- Пропускная способность посчитана под объём: число страниц делённое на 4.5 даёт ориентир для одной H100.
Кому подходит Surya OCR 2.5, а кому нет
Свести критерии к решению проще по двум спискам.
Типичные сценарии, где модель уместна
- Пакетная обработка счетов, договоров и актов со сканов: текст, layout и HTML-таблицы в одном проходе.
- Извлечение таблиц из отчётов и прайс-листов в HTML для дальнейшего парсинга: colspan и rowspan сохраняют иерархию шапки и групп строк.
- Многоколоночные PDF и документы с врезками, где критичен порядок чтения, а не координаты блоков.
- Мультиязычные документы: 91 язык по заявлению разработчика, качество на своих языках нужно проверять отдельно.
- Локальное или серверное развёртывание с vllm или llama.cpp, когда документы нельзя отдавать в облако. Если речь про распознавание на телефоне без сервера, логика другая: on-device OCR для первички строится вокруг других моделей и ограничений по памяти.
Когда лучше посмотреть на другие инструменты
Фото и естественные сцены: модель для них не предназначена. Обязательная геометрия ячеек: либо отдельный проход на Surya 2, либо другой инструмент. Нет возможности держать бэкенд инференса: останется только детекция, остальное не заработает. Крупный коммерческий продукт: сначала коммерческая лицензия весов у datalab-to.
Если сравниваете Surya 2.5 с другими движками по таблицам, формулам и мультиязычности, пригодится обзор открытых OCR-моделей 2026 с методикой расчёта стоимости инференса на vLLM. Если распознавание нужно прямо в браузере, смотрите отдельное сравнение TrOCR и PaddleOCR на Transformers.js: там другие ограничения по памяти и скорости.
Итог: Surya 2.5 закрывает документный OCR-пайплайн целиком, от текста до HTML-таблиц, но требует поднятого бэкенда инференса и честной проверки на своих документах. 85.9 и 83.7% - ориентир от разработчика, а не гарантия на ваших счетах и отчётах. Возьмите 50-100 типичных страниц, прогоните через модель, сравните с текущим движком по числу ошибок в числах и таблицах, и только потом решайте про миграцию.