Datalab выпустила Marker v2 — полностью переписанную версию своего open-source конвейера преобразования документов. Marker преобразует PDF, изображения, PPTX, DOCX, XLSX, HTML и EPUB в markdown, JSON, HTML или фрагменты — выходные форматы, которые служат прямым входом для систем retrieval-augmented generation (RAG), подготовки данных для обучения LLM и корпоративных конвейеров знаний, где точность парсинга определяет последующую производительность модели. Команда Datalab перестроила инструмент вокруг трех компонентов, выпущенных за последние месяцы: Surya OCR 2, быстрой модели разметки на 20M параметров и переработанного движка pdftext, который в 3× быстрее предыдущей версии.

Основные результаты бенчмарков взяты из olmOCR-bench, стороннего бенчмарка, созданного Allen AI (Ai2). Режим balanced в Marker v2 достигает 76.0% в целом и 83.5% на born-digital PDF, поддерживая 2.9 страницы в секунду на одном GPU B200. Такая пропускная способность более чем в 5× превышает скорость pipeline-бэкенда MinerU, который набирает 72.7% при 0.54 страницы в секунду. Docling набирает 50.3% при 2.1 страницы в секунду на той же тестовой обвязке.

Что нового в Marker v2

Marker v2 вводит три режима преобразования:

• Balanced — Surya VLM обрабатывает разметку, а повторный OCR всей страницы запускается всякий раз, когда качество встроенного текста низкое. Это режим с наивысшим качеством, оптимизированный для GPU. Достигает 76.0% на olmOCR-bench.
• Fast — легковесный детектор разметки rf-detr/onnx в сочетании с pdftext, с минимальными и точечными вызовами VLM. Набирает 66.6% при существенно более низкой стоимости.
• –disable_ocr — чистое извлечение из текстового слоя без каких-либо вызовов VLM. Полностью работает на CPU. Набирает 43.6% при 23.7 pg/s.

Выбор режима теперь по умолчанию учитывает устройство: balanced на GPU, fast на CPU/MPS, с ручным переопределением через –mode. Полная поддержка CPU стала вторым структурным изменением — режим fast с –disable_ocr не требует GPU и inference-сервера, но модель разметки на 20M параметров все равно разбирает колонки, таблицы и заголовки на CPU.

Третье архитектурное изменение обеспечивает показатели пропускной способности. Несколько легковесных CPU-воркеров используют один общий inference-сервер Surya, а родительский процесс управляет параллелизмом VLM между ними. В результате пропускная способность масштабируется вместе с мощностью сервера, а не ограничивается VRAM каждого отдельного процесса. Datalab сообщает, что режим balanced поддерживает примерно 2.9 pg/s по сравнению с ~0.3 pg/s в однопоточном сценарии на том же оборудовании.

Перед обновлением стоит учитывать несколько несовместимых изменений. Теперь требуется Python 3.10+. Упаковка перенесена с Poetry на uv, а hatchling используется как build backend, хотя pip install marker-pdf остается без изменений. Конвертер структурированного извлечения и экстракторы удалены; в качестве альтернатив Datalab направляет пользователей к hosted API или workflow с –use_llm.

Методология бенчмарка

Оценочный бенчмарк — olmOCR-bench от Ai2, включающий 1,403 PDF и примерно 8,400 pass/fail unit tests, которые покрывают отображение математики, структуру таблиц, порядок чтения, колонтитулы и старые сканы. Общий балл представляет собой макро-среднее по 8 категориям, рассчитанное официальным проверяющим инструментом olmOCR-bench. Показатели пропускной способности означают устойчивое параллельное число страниц в секунду на одном хосте B200, а не задержку в однопоточном режиме.

Относительно происхождения данных: хотя olmOCR-bench является сторонним бенчмарком от Ai2, все показатели точности и пропускной способности получены из собственных тестовых прогонов Datalab. Все результаты воспроизводимы через открытую тестовую обвязку в репозитории Marker, которая включает runner’ы конкурентов для MinerU, Docling и LiteParse наряду с собственным runner’ом Marker. Эти числа отражают набор документов одного бенчмарка на одной аппаратной конфигурации, поэтому результаты на других корпусах могут отличаться. Командам, проводящим оценку, следует запускать обвязку на собственных наборах документов для содержательных сравнений.

Marker v2 против MinerU

Pipeline-бэкенд MinerU является ближайшим архитектурным аналогом, поскольку оба инструмента читают текстовый слой PDF и выборочно применяют OCR. По общему баллу Marker balanced лидирует 76.0 против 72.7. На born-digital документах два инструмента фактически находятся на одном уровне: 83.5 против 83.3.

Существенное различие проявляется в пропускной способности. Marker balanced поддерживает 2.9 pg/s по сравнению с 0.54 pg/s у MinerU — разрыв 5.4× при более высоком показателе точности. Marker fast поддерживает 7.4 pg/s, примерно 13.7× от скорости pipeline MinerU, хотя в обмен уступает MinerU 6.1 пункта.

MinerU также предлагает VLM-бэкенд, который, как отмечает Datalab, показывает более высокий результат, чем его pipeline-бэкенд. Этот бэкенд использует подход full-page VLM и не включен в данную сравнительную таблицу. Командам, оценивающим MinerU, следует отдельно протестировать этот вариант.

Marker v2 против Docling

Docling показывает самый широкий разрыв в производительности среди GPU-конвейеров. Marker balanced лидирует 76.0 против 50.3 в целом и 83.5 против 64.0 на born-digital документах, одновременно работая быстрее: 2.9 pg/s против 2.1 pg/s. Datalab отмечает, что Docling оценивался с использованием своего стандартного конвейера, который задействует текстовый слой для born-digital страниц и OCR для областей изображений.

Сильные стороны Docling связаны с управлением проектом и широтой форматов, а не с чистой точностью. Кодовая база лицензирована по MIT, проект возник в IBM Research и размещается как проект в LF AI & Data Foundation. Поддерживаемые входные форматы также выходят за рамки документов и включают аудио и электронную почту.

Marker v2 против LiteParse

LiteParse, разработанный командой LlamaIndex, — это парсер документов на Rust, который работает в принципиально иной плоскости. На CPU он набирает 22.4 в целом и 20.4 при отключенном OCR, по сравнению с 43.6 у CPU-only режима Marker. Однако LiteParse с отключенным OCR сообщает 1721 pg/s — примерно 73× пропускной способности CPU-режима Marker, что отражает явный компромисс между скоростью и сохранением структуры.

Режим fast в Marker с –disable_ocr запускает модель разметки на 20M параметров на CPU и все равно восстанавливает структуру документа, что объясняет, почему его результат более чем вдвое превышает оценку простого текстового дампа. У LiteParse нет модели разметки, и он испытывает трудности с нелинейными макетами документов.

Marker v2 против уровня full-page VLM

Команда Datalab подчеркивает, что Marker разработан как конвейер, а не как VLM, отмечая, что это разные категории инструментов. Различие имеет практическое значение: full-page VLM обрабатывают каждое изображение документа целиком через большую модель, достигая более высокой точности, но создавая вычислительные или API-издержки на страницу, которые накапливаются при масштабировании. Конвейеры вроде Marker разбивают задачу на более дешевые специализированные этапы, обменивая пиковую точность на пропускную способность и контроль затрат. В этой оценке hosted Chandra 2 от Datalab набирает 85.8, тогда как Gemini Flash 3.5 через API набирает 76.4. Репозиторий Chandra от Datalab также размещает Ai2’s olmOCR 2 на уровне 82.4 и dots.ocr 1.5 на уровне 83.9 в отдельной таблице. Для сканов, страниц с большим количеством математики и достижения максимальной точности уровень VLM остается лучше всех перечисленных конвейеров.

Примечательно, что режим balanced в Marker сокращает разрыв до всего 0.4 пункта позади Gemini Flash 3.5 в целом и превосходит его на born-digital документах с результатом 83.5 против 79.1 — без необходимости API-вызова на каждую страницу.

Поведение по категориям

Выбранный режим влияет не только на общий балл, но и на профиль ошибок. Отображение математики — наиболее выраженный дифференциатор: режим fast читает уравнения из текстового слоя PDF, а не через VLM-OCR, из-за чего показатели arXiv math падают с 83.9 до 23.4, а –disable_ocr получает 0.0 в этой категории по замыслу. За пределами двух математических категорий старые сканы являются самым слабым разрезом во всех режимах, достигая максимум 43.2.

Лицензирование

Условия лицензирования существенно различаются у четырех систем, что имеет прямые последствия для коммерческих команд — особенно потому, что парсинг документов часто используется в регулируемых workflow, где происхождение данных и соблюдение лицензий являются проверяемыми требованиями:

• Marker: код распространяется по Apache 2.0. Веса моделей используют модифицированную лицензию AI Pubs OpenRAIL-M — бесплатно для исследований, личного использования и стартапов с финансированием или выручкой ниже $5M. Выше этого порога коммерческое использование весов требует платной лицензии.
• MinerU: теперь регулируется MinerU Open Source License, основанной на Apache 2.0 с дополнительными условиями. Отдельная коммерческая лицензия требуется при превышении 100M MAU или $20M месячной выручки, а онлайн-сервисы, построенные на ней, должны раскрывать этот факт.
• Docling: лицензия MIT; лицензии моделей отслеживаются отдельно в их исходных пакетах.
• LiteParse: open source от run-llama, при этом LlamaParse позиционируется как платный облачный вариант для обработки сложных документов.

Соображения по сценариям использования

Одни только баллы бенчмарка не определяют правильный инструмент. Тип корпуса, доступное оборудование, лицензионный уровень и требуемый выходной формат — все это влияет на выбор. Команды, обрабатывающие born-digital PDF в масштабе, могут обнаружить минимальные различия в точности между ведущими конвейерами, тогда как при работе со сканированными документами, академическими статьями с плотной математикой или смешанными форматами разброс будет шире. Командам следует оценивать каждый парсер на собственных наборах документов и с учетом операционных ограничений.

Все показатели бенчмарков и пропускной способности сопровождаются воспроизводимой обвязкой benchmarks/ в репозитории Marker.

Ключевые ссылки

• GitHub-релиз Marker v2
• Блог-пост Datalab о Marker v2
• Анонс в X
• Репозиторий olmOCR-bench (Ai2)

Источник: MarkTechPost