Рейтинг AI PDF OCR 2026: pdf-inspector, MinerU, Marker — что выбрать?

При построении RAG, проверке договоров или базы знаний по статьям команды часто спорят: «MinerU или Marker?» На практике пайплайн тормозит не выбор движка, а отправка PDF с готовым текстовым слоем в GPU-OCR — пакетная обработка растягивается с секунд до минут, пока Agent ждёт готовых документов. Open-source pdf-inspector от Firecrawl задаёт правильную рамку: сначала классификация, затем извлечение нативного текста, OCR только для страниц, которым он действительно нужен.

Материал для разработчиков iOS, Flutter и backend, которые подают PDF в векторные хранилища или Agents, а также для команд, оценивающих узел Cloud Mac для локального парсинга. Последнее обновление — 5 августа 2026; версии инструментов и лицензии — по репозиториям на GitHub.

Почему стратегия «OCR для всего» ломает документный пайплайн

В корпоративных PDF-корпусах значительная доля отчётов, статей, счетов и проспектов уже содержит извлекаемый текстовый слой — визуальная модель на каждой странице не нужна. Классический подход — вызывать MinerU, Marker или облачный OCR API для каждого файла — создаёт три скрытых издержки:

1. Налог на задержку — чисто текстовый PDF мог бы отдать Markdown за сотни миллисекунд, но стоит в очереди за GPU.
2. Налог на структуру — OCR может нарушить порядок чтения; таблицы и сноски сложнее исправить на постобработке.
3. Налог на лицензию — у Marker и аналогов коммерческие условия на веса моделей; полный OCR расширяет зону комплаенса.

Рамка 2026 года: классификация на входе → локальное извлечение текста → постраничный OCR как fallback. На наборе opendataloader-bench из 200 PDF pdf-inspector в режиме без OCR набирает около 0,875 и обрабатывает всю библиотеку примерно за 2,8 секунды — иной порядок величин по сравнению с многоминутными ML-пайплайнами. Смена только OCR-движка без слоя маршрутизации часто оптимизирует не тот рычаг: основная задержка возникает до первого вызова инференса, когда в GPU-пайплайн попадают страницы, которым OCR не нужен.

Перед бенчмарком MinerU против Marker измерьте долю production-PDF с меткой TextBased. Многие команды забывают, что цифровые договоры, экспортированные слайды и нативные PDF-отчёты уже несут текстовую структуру — OCR там чаще ухудшает порядок чтения и контекст таблиц.

Как классифицировать AI PDF-инструменты (три типа входа)

Эти три инструмента — не соперники на одном пьедестале; они занимают разные слои пайплайна:

Тип	Пример	Основное действие	Типичная задержка
A. Маршрутизация / извлечение текстового слоя	pdf-inspector	Классификация TextBased / Scanned / Mixed; нативный текст → Markdown	~20 мс классификация + ~150 мс/док извлечение
B. Высокоточный OCR-пайплайн	MinerU	Анализ вёрстки, таблицы HTML, формулы LaTeX, OCR на 84 языках	Секунды — минуты/док (зависит от GPU)
C. Высокопроизводительный OCR-пайплайн	Marker	Стек Surya, мультиформатный ввод, опциональная LLM-доводка	Страницы/сек при пакетной обработке (GPU)

Асимметричный вывод: настоящий разделитель — не число параметров модели, а классификация «текстовый слой vs скан» на входе пайплайна. Без этого слоя даже сильнейший OCR платит за документы, которым он не требовался.

Сравнение: pdf-inspector vs MinerU vs Marker

Таблица ниже использует единые измерения для технического обоснования выбора. «Исполнение» — пакетная интеграция и контроль вывода; «Контекст» — вёрстка, таблицы, формулы и многоязычная точность. При переносе матрицы в архитектурный документ дополните каждую строку SLA: максимальная P95-задержка на загрузку, ожидаемые страницы/час в пакете, вывод Markdown, JSON или оба в векторную БД.

Инструмент	Вход	Исполнение	Контекст	Кому подходит
pdf-inspector	CLI Node / Python / Rust; предшаг Agent	Без ML-зависимостей; маршрутизация pages_needing_ocr по страницам; лицензия MIT	Markdown из нативного текста, таблицы в двух режимах, порядок многоколоночной вёрстки; без OCR сканов	Backend гибридных пайплайнов; массовая предобработка PDF в Firestore / S3
MinerU	CLI / Docker / API; CPU и VLM бэкенды	Силён на документах типа OmniDocBench; путь VLM требует ≥8 ГБ VRAM; кастомная OSS-лицензия	Таблицы, формулы, сильная сторона CJK; удаление колонтитулов; JSON + MD	Академические библиотеки, финансовая отчётность, китайский многоколоночный RAG
Marker	CLI / GUI / API; PDF и Office-форматы	Высокий пакетный throughput; опциональный LLM постпроцесс; GPL + ограничения на веса	OCR 90+ языков; удобное извлечение изображений; сложные таблицы — периодически слабее	Массовая англоязычная оцифровка, мультиформатные архивы, команды с аудитом лицензий

Стоимость и вычисления (второй уровень сравнения)

Инструмент	Железо	Диск / модели	Лицензия
pdf-inspector	Только CPU; дружелюбен к Apple Silicon	Без загрузки моделей	MIT; можно встраивать в закрытый код
MinerU	Рекомендуется GPU NVIDIA; CPU pipeline с деградацией	Первый запуск — десятки ГБ зависимостей	Кастомная лицензия — читать перед коммерцией
Marker	CPU / CUDA / MPS (Mac)	Требуются веса Surya	GPL + RAIL-M; крупным компаниям — отдельная проверка

Как выбрать: матрица решений

Если вы…	Приоритет	Выбор	Примечание
Корпус из цифровых отчётов / договоров	Задержка и стоимость	Сначала pdf-inspector	OCR только для Mixed-страниц
Сканированные статьи / старые журналы	OCR и формулы	Путь VLM MinerU	Заложите GPU или удалённый Mac
Массовая оцифровка англоязычных книг	Пропускная способность	Пакет Marker	Сначала аудит лицензии
Agent читает загруженные PDF в реальном времени	P95 задержки	pdf-inspector → условный OCR	Избегайте cold-start загрузки моделей
Мобильное приложение с офлайн-парсингом	Размер бандла и энергия	Только слой pdf-inspector	Сканы → облачный OCR
Данные не должны покидать периметр	Самохостинг	Все три локально; без облачного OCR по умолчанию	См. центр помощи по изоляции

Рекомендуемые стеки (комбинируемые)

Стек A — недорогой вход RAG (рекомендуемый по умолчанию)

• pdf-inspector — классификация + Markdown текстового слоя
• pages_needing_ocr → MinerU CPU или облачный API
• Единая стратегия чанков в векторной БД (заголовок + метаданные страницы)
• Подходит для: корпоративных баз знаний, документации поддержки, смешанных корпусов скан/текст

Стек B — академика / китайские финансы с высокой точностью

• Полный MinerU (VLM-бэкенд) → MD + JSON
• QA: визуализация вёрстки на 5% выборки
• Вычисления: пробный прогон на локальном M4 24 ГБ; пиковые пакеты — на узлах Cloud Mac M4

Стек C — массивный англоязычный архив + автоматизация CI

• Ночной пакет Marker → объектное хранилище
• CI-ворота с pdf-inspector для новых загрузок («нужен OCR?»)
• Оркестрация: см. облачную автоматизацию OpenClaw — разделение parse-job и build-узлов

Связь с Cloud Mac и Apple Silicon

MinerU и Marker работают на macOS через MPS и unified memory, но узел M4 с 24 ГБ удобно разделяет роли: ночная пакетная обработка, днём — удалённая разработка — parse-job не конкурирует с компиляцией Xcode за swap. pdf-inspector достаточно лёгок для ворот загрузки на CI Runner или self-hosted Mac в GitHub Actions: классификация до запуска тяжёлого OCR.

Без постоянного GPU-сервера аренда Cloud Mac на месяц для пакетов Marker/MinerU часто дешевле отдельного OCR-железа — слой маршрутизации остаётся в коде приложения или лёгком контейнере. На Apple Silicon Marker использует MPS; MinerU сильнее раскрывается на VRAM NVIDIA, поэтому тяжёлый пайплайн имеет смысл вынести на удалённый Mac, а pdf-inspector оставить локальным предохранителем. Рабочая станция остаётся свободной для Xcode, сборок Flutter или отладки Agent, пока ночные job обрабатывают большие корпуса.

Частые ошибки

1. Замена бизнес-приёмки баллом бенчмарка — ваши PDF могут быть двухколоночными китайскими таблицами со сносками, а не англоязычными сборниками статей.
2. Игнорирование «ложного текстового слоя» — GID-кодировка или битый текст: pdf-inspector ставит needsOcr; направляйте в OCR, не форсируйте извлечение.
3. MinerU vs Marker как бинарный выбор — смешанные корпуса часто требуют маршрутизацию + два движка по страницам.
4. Отсутствие метаданных на уровне страницы — векторный поиск не сможет сослаться на «таблицу на стр. 12»; галлюцинации сложнее исправить.
5. Лицензии в конце — GPL Marker и условия на веса могут заблокировать путь SaaS-распространения.

План внедрения (7 шагов)

1. Выборка 30–50 реальных PDF и замер долей TextBased / Scanned / Mixed через pdf-inspector.
2. Метрики приёмки — порядок чтения, структура таблиц, доля корректно рендерящихся формул LaTeX; у каждой — порог прохождения.
3. Реализация маршрутизации — TextBased с высокой уверенностью извлекается локально; на выходе — списки pages_needing_ocr.
4. Выбор OCR-движка по сегментам — сложная китайская вёрстка → MinerU; массовый английский → Marker; фиксируйте версии моделей.
5. Развёртывание вычислений — лёгкая маршрутизация на CI; GPU-пакеты на Cloud Mac или выделенной машине; см. аренду Mac mini.
6. Неделя production-трафика — отслеживайте P95, неудачные страницы, долю ручных правок; настройте пороги маршрутизации.
7. Операционный runbook — границы лицензий, версии отката, согласование с центром помощи по ключам и хранению данных.

FAQ

Является ли pdf-inspector OCR-инструментом?

Не в классическом смысле. Сначала классификация, затем извлечение нативного текста; только страницы, помеченные для OCR, должны идти в MinerU, Marker или облачный API.

MinerU или Marker для таблиц?

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

MinerU без GPU NVIDIA?

Да, через CPU pipeline, но VLM высокой точности рекомендует ≥8 ГБ VRAM. На Apple Silicon попробуйте MPS с Marker или перенесите пакеты на удалённый Mac.

С чего начать RAG-пайплайн?

По умолчанию — маршрутизация pdf-inspector, затем OCR сканированных страниц; это заметно снижает среднюю стоимость и задержку.

Можно ли связать все три инструмента?

Да — доминирующий паттерн 2026: классификация inspector → локальный MD для текстового слоя → MinerU/Marker для пробелов → единая схема в хранилище.

Итог

У вопроса «pdf-inspector, MinerU, Marker — что лучше?» нет единого чемпиона: pdf-inspector выигрывает на входе и по стоимости, MinerU — на сложной структуре и CJK, Marker — на массовом английском throughput. Сначала ответьте, сколько страниц на самом деле не нуждались в OCR, — это выгоднее погони за рейтингами бенчмарков и экономит вычисления.

Один вопрос приёмки перед запуском: если отключить OCR, сколько документов всё ещё дадут пригодный Markdown? Эту долю стоит вынести на первую страницу архитектурного обзора.

Дополнительно

• Gemini 4 vs GPT-5.6: выбор модели для разработчиков →
• OpenClaw и Cloud Mac: цепочка автоматизации →