Почему стандартные VLM-парсеры тормозят, и как HPD-Parsing это исправляет
VLM-парсеры документов упираются в фундаментальное ограничение авторегрессионной генерации. Каждый токен ждёт, пока сгенерируется предыдущий. На странице с таблицей на 500 ячеек это превращается в очередь из тысяч последовательных шагов. Процессор простаивает, время обработки растёт линейно.
HPD-Parsing решает эту проблему архитектурно. Модель на 1 миллиард параметров выдаёт пиковую пропускную способность 4752 токен/с, что в 2,62 раза быстрее существующих end-to-end парсеров. Цифры получены на бенчмарке OmniDocBench v1.6 при точности 94,91% - это новый SOTA среди унифицированных парсеров документов.
Ключевые инновации: иерархическое параллельное декодирование (HPD) и прогрессивное предсказание нескольких токенов (P-MTP). Первое ломает последовательную природу генерации на уровне структуры документа. Второе сжимает количество шагов внутри каждой параллельной ветки. Результат - скорость без деградации качества.
Если вы проектируете пайплайны обработки документов, где критична задержка, или обрабатываете тысячи страниц в час, эта архитектура заслуживает внимания. Мы уже разбирали, как парсинг влияет на галлюцинации в RAG-системах, и HPD-Parsing закрывает один из самых узких этапов этого пайплайна.
Архитектура HPD-Parsing: как работает иерархическое параллельное декодирование
Архитектура ломает монолитную авторегрессию на два уровня. Верхний уровень координирует глобальную структуру страницы. Нижний генерирует содержимое регионов параллельно. Это не эвристика постобработки, а нативный механизм декодирования внутри модели.
Главная ветка и параллельные ветки: динамическое распределение задач
Главная ветка анализирует макет страницы и выделяет структурные регионы: абзацы, таблицы, списки, подписи к изображениям. Каждый регион становится задачей для параллельной ветки. Ветки запускаются одновременно и генерируют содержимое независимо друг от друга.
Динамическое распределение задач предотвращает дисбаланс. Если одна ветка получает сложную таблицу на 200 ячеек, а другая - короткую подпись из пяти слов, координатор перераспределяет ресурсы. Простаивающие вычислительные блоки не ждут завершения самой медленной ветки, а подхватывают новые задачи из очереди.
Этот подход радикально отличается от схемы «один документ - один последовательный проход». Вместо N шагов для страницы с M регионами модель делает O(log M) координационных шагов плюс параллельную обработку содержимого. На практике это даёт рост пропускной способности в 2,62 раза относительно аналогов.
P-MTP: предсказание нескольких токенов за один шаг
Каждая параллельная ветка внутри себя тоже оптимизирована. Вместо генерации одного токена за шаг, P-MTP предсказывает сразу несколько следующих токенов параллельно. Модель делает один проход через декодер и выдаёт пакет из K токенов, а не один.
Обычная авторегрессия: шаг 1 - токен 1, шаг 2 - токен 2, шаг 3 - токен 3. P-MTP: шаг 1 - токены 1,2,3. Количество шагов декодирования сокращается пропорционально размеру пакета. Для типичного контента документа, где предсказуемость высока (форматирование, структура таблиц, повторяющиеся паттерны), процент принятых предсказаний достигает значений, сопоставимых с лучшими результатами MTP в задачах генерации структурированного контента.
Комбинация HPD и P-MTP даёт мультипликативный эффект. HPD распараллеливает обработку регионов страницы, P-MTP ускоряет генерацию внутри каждого региона. Итог - 4752 токен/с на пике.
Точность без компромиссов: 94.91% на OmniDocBench и новый SOTA
Главный страх при переходе на параллельное декодирование - потеря точности. Когда модель генерирует несколько токенов одновременно, ошибки могут накапливаться быстрее. HPD-Parsing обходит эту проблему через методологию обучения.
Результат на OmniDocBench v1.6 - 94.91% точности. Это выше, чем у предыдущих SOTA-моделей среди end-to-end унифицированных парсеров. Бенчмарк покрывает сложные сценарии: документы со смешанным содержимым, таблицы с объединёнными ячейками, многостраничные отчёты, формы с нестандартной вёрсткой.
Сравнение с другими OCR-моделями, которые мы разбирали в обзоре открытых решений 2026 года, показывает, что HPD-Parsing выигрывает не только в скорости, но и в качестве распознавания сложных структур. Модели вроде Nanonets-OCR2-3B и DeepSeek-OCR показывают сопоставимую точность на простых документах, но проседают на таблицах с нерегулярной структурой.
Постадийная адаптация и автоматическая курация данных по сложности
Параллельное декодирование чувствительно к качеству обучающих данных. Если сразу подавать сложные примеры, модель не успевает выучить стабильные паттерны координации между ветками. Разработчики HPD-Parsing применили постадийную адаптацию с автоматической курацией данных.
Система автоматически оценивает сложность каждого примера в датасете: количество регионов на странице, глубина вложенности структур, вариативность форматирования. Обучение разбивается на стадии. Первая стадия - только простые одноколоночные документы с минимальным форматированием. Модель учится базовой координации между главной веткой и параллельными ветками. Вторая стадия - документы средней сложности с таблицами и списками. Третья - полноценные многостраничные отчёты со смешанным содержимым.
Такой подход предотвращает нестабильность обучения, характерную для параллельных архитектур. Модель не «забывает» простые паттерны при переходе к сложным, а наращивает компетенции аддитивно. Результат - точность 94.91% без компромиссов по скорости.
Как начать использовать HPD-Parsing: быстрый старт и интеграция
Модель доступна для инференса на стандартных GPU с поддержкой трансформерных архитектур. Минимальные требования - GPU с 24 ГБ видеопамяти для загрузки 1B-параметрической версии в FP16. Для продакшен-нагрузок рекомендуется использовать vLLM или аналог с поддержкой continuous batching.
Концептуальный пример инференса:
from hpd_parsing import HPDDocumentParser
parser = HPDDocumentParser.from_pretrained("hpd-parsing-1b")
# Загрузка изображения страницы
image = load_image("document_page.png")
# Параллельный парсинг
result = parser.parse(
image,
max_parallel_branches=8, # максимум параллельных веток
mtp_depth=3 # глубина P-MTP предсказаний
)
# Результат содержит структурированный документ
print(result.markdown) # Markdown с таблицами и форматированием
print(result.regions) # bounding boxes для каждого региона
Интеграция в существующие пайплайны обработки документов идёт через два сценария. Первый - замена медленного VLM-парсера в цепочке «изображение → текст → индексация». HPD-Parsing подставляется на этапе извлечения текста и структуры, сокращая общую задержку пайплайна. Второй сценарий - потоковая обработка тысяч документов, где прирост в 2,62 раза по скорости напрямую конвертируется в снижение затрат на GPU-часы.
Для RAG-систем это означает, что этап парсинга перестаёт быть узким горлышком. Мы уже показывали, как качество парсинга влияет на галлюцинации в RAG, а HPD-Parsing добавляет к качеству ещё и скорость.
Ограничения и когда HPD-Parsing может не подойти
Модель обучалась на документах определённых форматов. Точные данные о распределении обучающей выборки не раскрыты, но типичное смещение для подобных систем - офисные документы, научные статьи, отчёты. Рукописный текст, исторические документы с нестандартной вёрсткой, чертежи и схемы могут давать более низкое качество распознавания структуры.
Параллельное декодирование требует больше видеопамяти, чем последовательное. Каждая параллельная ветка держит свой контекст, и при 8 активных ветках потребление памяти растёт пропорционально. На GPU с 24 ГБ это укладывается в лимиты, но для развёртывания на меньших картах потребуется ограничивать количество параллельных веток, снижая прирост скорости.
Очень сложные макеты с глубокой вложенностью структур (таблица внутри таблицы, многоуровневые списки с нерегулярными отступами) могут создавать конфликты при координации веток. Главная ветка может неправильно определить границы регионов, и тогда параллельные ветки генерируют дублирующееся или обрезанное содержимое. Частота таких ошибок на OmniDocBench v1.6 не превышает 5%, но на специфических доменных документах может быть выше.
Информация о модели основана на предоставленных данных и может быть неполной. Перед внедрением в продакшен рекомендуется провести валидацию на собственной выборке документов. Сравните точность и скорость с текущим парсером на реальных данных, а не только на бенчмарках.