Как выбрать OCR в 2026-м: тестируем девять моделей на трех движках инференса на рукописном русском

Вам нужен OCR. В техобзорах рекомендуют Tesseract, на Хабре все пишут про VLM, идете на Hugging Face — там PaddleOCR-VL, DeepSeek-OCR, Dots.OCR, Qwen2.5-VL, и каждая называет себя SOTA. Прибавим к этому vLLM, SGLang, TGI, Native HF Transformers, и вот вы зависли между десятками комбинаций. Мы протестировали девять моделей на трех движках инференса на рукописном русском и отразили в таблице, какая модель под какую задачу лучше подходит.

Ваше время ценно для нас. Так что сразу держите краткие выводы

• Native HF Transformers не для продакшена. Тот же Qwen2.5-VL под vLLM/SGLang в два раза быстрее, чем под Native, на той же GPU.

•  Размер модели обманчив. PaddleOCR-VL 1.7B обгоняет Qwen2.5-VL-7B в пять с лишним раз по скорости в стр/мин и в 6,7 раза по токен/сек. Специализация бьет general-purpose.

• Tesseract быстрее всех — миф. На сложных изображениях он возвращает 411 символов против 1193 токенов у PaddleOCR-VL. Быстро возвращать пустоту — не победа.

• В классе general-VLM  наша компактная модель Cotype Light 3 на 9 млрд параметров обгоняет Qwen2.5-VL-7B на 79% по стр/мин с включенным MTP-декодингом (37.7 vs 21.1) при сопоставимом TTFT.

Вот обещанная таблица со сводкой, какие модели в каких сценариях себя лучше показали. 

Цифры получены на NVIDIA A100 80GB (shared), batch=1, 15 образцов русскоязычного рукописного текста. 

Ниже объясню, как мы эту таблицу получили и какие нюансы стоят за каждой строкой.

Ландшафт: традиционный OCR vs VLM в 2025–2026 гг.

До 2024 года выбор OCR был относительно понятным. Tesseract, PaddleOCR, EasyOCR. Пайплайн один: детекция текстовых областей, распознавание символов, постобработка. Обычный текст на выходе, минимальные требования к железу, предсказуемость.

Но тут появились VLM (Vision Language Models). По сути это end-to-end модели: вижн-энкодер превращает картинку в эмбеддинги, LLM-декодер генерирует текст. Никаких отдельных стадий: подал картинку — получил Markdown, JSON, HTML.

Вот сравнительная таблица для традиционного и VLM-подхода к OCR.

А еще появились специализированные OCR-VLM типа PaddleOCR-VL (1,7B), DeepSeek-OCR (3B MoE), Dots.OCR (3B). Это VLM по архитектуре, но дообученные исключительно на OCR-задачах. Они меньше VLM общего назначения  в 4–10 раз, но на распознавании документов работают на уровне или лучше.

В таком многообразии инструментов нам было интересно узнать, где проходит граница между «брать классику» и «брать VLM» и какая конкретная связка модель + движок оптимальна.

Как мы это узнавали? 

Методология

Мы решили разработать честный бенчмарк, в котором все модели бегут в одинаковых условиях. Что мы зафиксировали:

Унифицированные параметры:

·      Precision: bfloat16 (для всех VLM)

·      max_new_tokens: 2048

·      temperature: 0.0 (детерминированный вывод)

·      Image preprocessing: thumbnail 800×800, JPEG q85, base64

·      Warmup: пять прогонов перед замерами (прогрев KV-cache, CUDA-кернелов)

·      Промпт: SYSTEM: «You are an OCR assistant. Extract all text…» + USER: «Extract all text from this document.»

Стек инфраструктуры:

·      NVIDIA A100 80GB PCIe (им пришлось делиться  с другими командами, об ограничениях ниже)

·      vLLM 0.18.1: gpu-memory-utilization=0.4, max-model-len=4096, OpenAI-compatible API

·      SGLang v0.5.10: mem-fraction-static=0.85, OpenAI-совместимый API

·      Native HF Transformers: AutoModel.generate() напрямую, без оптимизаций

Движки запускались в Docker (vllm/vllm-openai:latest, lmsysorg/sglang:latest).

Датасет:

15 примеров русскоязычных текстов из Russian Handwriting OCR: пять чистых сканов, пять «темных» (низкий контраст), пять «светлых» (засветка), выборка через random_state=42. Мы специально для теста взяли рукописи, так как это максимально сложная задача для любого OCR: нестандартные символы, вариативность почерка, шум. Если модель справится здесь, то на печатных документах и подавно.

Метрики:

·      pages/min: пропускная способность на уровне документов

·      TTFT (Time To First Token, мс): задержка до первого токена

·      TPOT (Time Per Output Token, мс): среднее время на токен

·      tok/s: токенов в секунду

·      tok/page: токенов на страницу (для VLM)

·      peak GPU memory (ГБ), GPU utilization (%)

Замеры пишутся в JSON, графики строятся отдельно.

Результат 1. Общий рейтинг стр/мин и ловушка Tesseract

Первое, что хочется знать про OCR, сколько страниц в минуту. Вот общий рейтинг всех 14 комбинаций модель + движок, упорядочено по убыванию:

В лидерах Tesseract (193) и RapidOCR (143) на CPU. На GPU быстрее всего PaddleOCR-VL под SGLang (111) и под vLLM (99). EasyOCR (105) дает неплохой CPU-результат. Аутсайдеры: Qwen2.5-VL-7B (21 на vLLM/SGLang, 11 на Native) и PaddleOCR v5 (15 стр/мин на CPU).

Кажется очевидным, что традиционный OCR на CPU быстрее VLM на GPU, берите Tesseract. Но это ловушка.

Посмотрите на полноту вывода — сколько символов или токенов модель выдает на одну страницу:

·      Tesseract: 411 символов/стр

·      RapidOCR: 549

·      PaddleOCR v5: 766

·      EasyOCR: 795

·      PaddleOCR-VL: 1193 токенов/стр

Tesseract быстрый именно потому, что возвращает меньше. На сложных изображениях (рукопись, низкий контраст, наклон) он пропускает участки, где не уверен, и возвращает пустую строку. Быстро отвечать «не знаю» — так себе победа.

EasyOCR лидирует по полноте среди традиционных OCR-моделей (795 символов) при разумных 105 стр/мин, это честный CPU-бейзлайн. RapidOCR при 549 символах — компромисс между скоростью и полнотой.

VLM выдают на порядок больше токенов, потому что распознают разметку: заголовки, списки, таблицы в Markdown. 30–40% объема у PaddleOCR-VL — это не сами символы, а структура документа.

Вывод: количество распознанных страниц в минуту без контекста полноты — бесполезная метрика. На простых печатных документах Tesseract будет лидером по причине минимальной вычислительной сложности. На сложных — по причине пропусков.

Результат 2. vLLM vs SGLang vs Native, 2-кратный разрыв на одной модели

После выбора VLM нужно определиться с движком инференса.

Есть три кандидата:

·  vLLM: PagedAttention, де-факто стандарт для прода. Широкая поддержка моделей, OpenAI-совместимый API.

·  SGLang: RadixAttention, агрессивная оптимизация KV-cache. Лучше пропускная способность на специализированных моделях, экономнее по памяти.

·  Native HF Transformers: прямой AutoModel.generate(). Минимум зависимостей, максимум совместимости. Используется для прототипирования.

Чтобы изолировать эффект движка, мы прогнали одну модель, Qwen2.5-VL-7B, под всеми тремя:

Qwen2.5-VL под Native vs vLLM vs SGLang

Вывод 1: Native HF не для прода. Двукратное отставание в скорости распознавания — это не просто «немного хуже», а вдвое хуже. Утилизация GPU — 64% против 97–99%, Native HF просто не умеет грузить карту. С ростом партий запросов (batch > 1) разрыв станет еще заметнее.

Вывод 2: разница между vLLM vs SGLang в пределах погрешности. По пропускной способности (throughput) на Qwen они идут почти одинаково (21.1 vs 21.3), однако  vLLM лучше TTFT (78 мс vs 122) и выигрывает в плане совместимости с моделями. SGLang экономнее по памяти (57 ГБ vs 69 ГБ у vLLM) и в прогонах на специализированных моделях давал +5–14% к пропускной способности.

Рекомендация: по умолчанию для продакшена берем vLLM. К SGLang идем, когда нужна максимальная пропускная способность или когда уперлись в память видеокарты. Native — только для исследований в Jupyter.

Результат 3. PaddleOCR-VL 1.7B обгоняет Qwen2.5-VL 7B в пять с лишним раз по скорости

И это главный неожиданный результат бенчмарка. 

Все восемь VLM-прогонов в одной таблице:

У PaddleOCR-VL всего 1,7 млрд параметров, у Qwen2.5-VL-7B — 7 млрд. Но первая в 5,2 раза опережает вторую по страницам в минуту (110.8 против 21.1–21.3) и в 6,7 раза — по токенам в секунду (604.2 против 90.5–90.6). По страницам в минуту разрыв меньше, потому что PaddleOCR-VL генерирует больше токенов на страницу (1193 против 341–442) — за счет markdown-разметки в выводе.

Почему так получается?

PaddleOCR-VL, DeepSeek-OCR и Dots.OCR — это специализированные OCR-VLM. Они дообучены на распознавании документов и выдают результат в виде Markdown с разметкой: заголовки, таблицы, списки. Это видно по показателю токен/стр: 1193–1314 у специализированных против 341–442 у Qwen. 30–40% объема у специализированных моделей — это не текст, а структура.

Qwen2.5-VL — модель общего назначения (VLM): умеет отвечать на вопросы по изображению, описывать его, разбираться в структуре документов и многое другое. За универсальность платим скоростью. Плюс Queen’s по природе консервативны: на нечитаемых участках они молчат, а не угадывают. Для рукописи это видится как «низкая полнота», но на читаемых документах это плюс, так как меньше галлюцинаций.

Вывод. Специализация бьет scaling. На задаче с узким сценарием (распознавание документов) маленькая специализированная модель обходит все умеющую большую. И не на 10%, а в разы.

Результат 4. Cotype Light 3 в классе VLM общего назначения

Если VLM-ки общего назначения все равно медленнее спец-OCR, есть ли смысл сравнивать модели внутри этого класса? 

Короткий ответ — есть. Часто нам приходится иметь дело со сценариями, в которых распознавание сканов — лишь часть более широкой задачи: диалог по документу, вопросы по картинке, инструкции с картинкой и прочее. В таких случаях выбираем не между PaddleOCR-VL и Qwen, а между различными general-VLM. 

Недавно мы релизнули Cotype Light 3_9B, и решили заодно прогнать нашу мини-модельку в двух режимах: бейзлайн и с включенным MTP (—speculative-config). MTP это Multi-Token Prediction: в чекпоинт Cotype встроена дополнительная голова model-mtp-injected.safetensors, предсказывающая три токена вперед. Основная модель проверяет их за один forward-pass; при попадании получаем несколько токенов за проход вместо одного. Математически идентично обычной генерации, качество вывода не меняется. Это родной режим модели, а не post-hoc оптимизация под наш бенч. Для сравнения взяли Qwen2.5-VL-7B, как стандартную VLM под OCR-задачи. 

Результаты в таблице:

Baseline дает +25% к Qwen2.5-VL-7B (26.5 против 21.1). MTP-режим — +79% (37.7 vs 21.1). TTFT остается в интерактивном диапазоне 86–93 мс, отклик пользователя не страдает. Расход VRAM сопоставим: 71–72 vs 69 ГБ на A100 80.

Колонку по пропускной способности (токен/сек) мы намеренно не приводим, так как наш streaming-счетчик инкрементирует токен на каждый SSE-чанк, а vLLM в spec-режиме упаковывает в чанк несколько принятых токенов. Wall-clock метрики (стр/мин, сек/стр) считаются от time.perf_counter() и достоверны.

Со спец-OCR типа PaddleOCR-VL, Dots.OCR и DeepSeek-OCR сравнивать Cotype Light 3 напрямую бессмысленно, они созданы под другой класс задач. А внутри своего Cotype Light 3 сейчас впереди Qwen2.5-VL-7B — и это радует.

Результат 5. Цена скорости, GPU память и утилизация

Скорость VLM не бесплатна. Главный ресурс это VRAM.

Из таблицы выше видны три закономерности:

1.      vLLM ест больше памяти (~70 ГБ), чем SGLang (~56 ГБ). Это плата за PagedAttention и более агрессивную преаллокацию KV-cache. Для одной модели на 80GB-карте это нормально, но если хочется крутить две модели рядом или нужен запас под батч, SGLang выгоднее.

2.     Загрузка GPU у vLLM и SGLang на уровне 90–98%, впритык к потолку железа. Это значит, что дальнейший рост возможен только от батчинга или более быстрой карты.

3.     Native HF Transformers просто не умеет загружать GPU — всего 64%. Использует меньше памяти, чем движки (~50 ГБ), но скорость в два раза ниже не из-за памяти, а потому что между токенами карта простаивает.

Практический вывод

Если вы вынуждены делиться A100, как мы (нам было реально доступно ~48 ГБ из 80), у вас два варианта:

·  SGLang + специализированная модель (56 ГБ, впритык). Работает с оговорками.

·  vLLM + любая VLM (69+ ГБ). Не помещается, нужна выделенная карта или меньшая модель.

На выделенной A100 80GB обе связки работают комфортно.

Осторожно с этими цифрами

Будем честны, некоторые наши выводы по этому бенчу стоит читать, беря во внимание следующие оговорки:

• Для тестов мы брали A100 80GB, но из-за параллельной нагрузки других команд реально было доступно ~48 ГБ. На выделенной карте абсолютные числа будут выше, но относительные разрывы (Native vs движки, PaddleOCR-VL vs Qwen) сохранятся, это нагрузочное свойство, не зависящее от свободной памяти.

• Batch = 1. Все замеры проводились по одному запросу за раз. В реальной нагрузке с батчингом разрыв vLLM/SGLang над Native будет еще больше, движки именно ради batched inference и сделаны.

• Тестировали на 15 семплах: пять нормальных сканов + пять затемненных + пять засвеченных, выбранных через random_state=42. Статистическая мощность ограничена, но при разрывах в 2–6 раз это уже не шум.

• Брали только русскоязычную рукопись (ад для OCR). На печатных документах абсолютные цифры у всех будут выше, особенно у Tesseract, он отстает именно на рукописи.

• CER/WER не считали. Это бенчмарк скорости, не качества. Эталонная разметка для качественных метрик уже готовится: 15 страниц размечены вручную, о результатах в следующий раз расскажем.

• Native HF Transformers получилось запустить только для Qwen2.5-VL, остальные модели несовместимы с generic pipeline. Для них Native-сравнение отсутствует.

• SGLang у нас не запустился на DeepSeek-OCR (image processor: image.size трактуется как метод). Поэтому цифра есть только для vLLM.

Главный технический инсайт

Размер модели — слабый предиктор производительности. Специализация под задачу и выбор движка инференса важнее количества параметров.

Что хотим сделать дальше

• Добавим больше семплов (печатные документы и таблицы).

• Измерим CER/WER на размеченных страницах. Эталонная разметка 15 страниц готова, скоро опубликуем CER/WER по тем же моделям, чтобы скорость не была единственной осью сравнения.

• Проведем замеры с разной нагрузкой (10, 50, 100 параллельных запросов), чтобы понять, как ведут себя движки под реальным трафиком, а не на синтетическом batch=1.

Пишите в комментариях, какой OCR у вас в проде и почему взяли именно его. Интересно собрать живые сценарии, на которых наши цифры не сходятся с практикой.