marker-pdf: подробный обзор локального конвертера PDF и документов для Markdown и RAG

marker-pdf — не PDF-просмотрщик и не визуальный редактор, а Python-инструмент Datalab для преобразования документов в структурированные данные. Версия 2.0 извлекает текст и структуру страниц из PDF и других форматов, распознаёт сканы, восстанавливает таблицы и формулы, сохраняет изображения и выдаёт Markdown, HTML, JSON либо chunks для RAG. Его следует оценивать по качеству разбора, управляемости OCR и пригодности результата для автоматизации, а не по удобству чтения страниц.

Скачать marker-pdf

Безопасный способ получить marker-pdf — установить пакет marker-pdf из PyPI или взять исходный код из официального репозитория Datalab. На 15 сентября 2026 года в PyPI последней стабильной публикацией значится 2.0.0. Для неё опубликованы исходный архив и универсальный Python wheel. Отдельного установщика EXE, DMG или классического настольного пакета разработчик не предлагает: marker-pdf рассчитан на Python-среду и запускается как консольная программа либо как библиотека.

Базовая установка выполняется командой pip install marker-pdf. Если нужны не только PDF, но и DOCX, PPTX, XLSX, HTML или EPUB, документация рекомендует вариант pip install marker-pdf[full], который подтягивает дополнительные зависимости. Это важное различие: наличие расширенного списка форматов в описании проекта не означает, что минимальная установка одинаково обслуживает все типы файлов.

Не стоит скачивать архивы marker-pdf с сайтов-каталогов и неофициальных зеркал: пакет быстро меняется, а ветка 2.0 существенно отличается от старых публикаций. В частности, условия лицензирования кода изменились относительно 1.10.2, поэтому старые обзоры и инструкции могут приводить уже неверные сведения. Для проверки установленной версии достаточно сверить её с актуальной версией пакета в PyPI перед развёртыванием в рабочей среде.

Что такое marker-pdf

marker-pdf, или Marker, — проект Datalab для document parsing. Он переводит визуальный документ в логические блоки: текст, заголовки, списки, таблицы, рисунки, формулы и другие элементы, после чего рендерит результат в текстовые и структурные форматы.

Версия 2.0 — переписанное поколение, ориентированное на скорость, CPU-поддержку и гибридный выбор между встроенным текстом PDF и OCR. Marker использует текстовый слой, когда он пригоден, определяет структуру страницы и отправляет в Surya VLM только проблемные или сканированные участки. Это отличает его от подхода с VLM на всю страницу, где визуальная модель обрабатывает каждую страницу целиком.

Не следует смешивать локальный marker-pdf с Datalab Convert API: облачная платформа имеет отдельный аккаунт, тарифы и API, а локальный пакет устанавливается в собственной Python-среде. Проект активен; на 15 сентября 2026 года 2.0.0 остаётся последней стабильной публикацией PyPI.

Основные функции marker-pdf

Структурное извлечение

Marker строит документ как страницы и блоки, а не как простой поток символов. Схема различает заголовки, списки, таблицы, изображения, подписи, формулы, сноски, колонтитулы, формы и другие элементы. На многоколоночной верстке это полезнее прямого копирования текста из просмотрщика.

OCR и режимы

balanced рассчитан на качество и лучше подходит для GPU: Surya VLM участвует в анализе структуры и inline-математики и повторном OCR плохих страниц. fast ориентирован на CPU: шире использует pdftext и лёгкий layout detector, а VLM вызывает точечно. По умолчанию balanced выбирается на GPU, fast — на CPU/MPS.

—disable_ocr полностью отключает VLM и подходит для цифровых PDF с хорошим текстовым слоем; сканы и формулы в таком режиме теряют информацию. —force_ocr принудительно запускает OCR, а —strip_existing_ocr позволяет не полагаться на старый OCR-слой.

Таблицы, формулы и изображения

Цифровые таблицы восстанавливаются из текстового слоя и геометрии, а сканы и низкоуверенные случаи могут передаваться VLM. Отдельный TableConverter извлекает только таблицы и умеет отдавать HTML-блоки или JSON с координатами. Формулы в balanced преобразуются в LaTeX; изображения по умолчанию извлекаются и связываются с выходом.

Форматы вывода

Markdown сохраняет заголовки, таблицы, код, LaTeX и ссылки на изображения. HTML удобен для CMS. JSON содержит дерево блоков, типы, координаты, иерархию и метаданные. Chunks уплощает верхнеуровневые блоки и добавляет полный HTML каждого блока, что удобно для RAG без рекурсивного обхода дерева.

Пакетная обработка и Python API

Команда marker обрабатывает каталог; доступны workers, —skip_existing, ограничение количества файлов и шардирование по нескольким машинам. В Python используются PdfConverter, ConfigParser и расширяемые providers, builders, processors и renderers.

Опциональный LLM

—use_llm подключает отдельную модель для сложных таблиц, форм, математики и коррекции результата. Поддерживаются Gemini, Vertex, Claude, OpenAI-совместимые endpoints, Azure OpenAI, OpenRouter и локальный Ollama. Без этого флага облачный LLM не нужен.

Интерфейс и удобство использования

Основной интерфейс — командная строка. Для одиночного PDF достаточно передать путь к файлу; режим, формат вывода и OCR задаются флагами. Это удобно для автоматизации, но заметно сложнее настольного приложения с миниатюрами страниц и ручными инструментами.

В репозитории есть необязательное Streamlit-приложение, запускаемое через marker_gui после установки Streamlit и streamlit-ace. Документация называет его простым интерактивным интерфейсом с базовыми настройками, поэтому рабочие повторяемые процессы разумнее фиксировать в CLI, config JSON или Python-коде.

Отдельная русская локализация не заявлена: CLI-опции и конфигурация англоязычные. Это не ограничивает язык документа: Surya многоязычен, а при корректном текстовом слое без OCR Marker может обрабатывать текст независимо от языка интерфейса.

Удобство CLI повышает то, что основные параметры собраны вокруг одной команды: можно ограничить диапазон страниц, выбрать каталог вывода, сохранить разделители страниц, включить отладку и передать config JSON. Команда config —help выводит доступные builders, processors и converters. Это полезно для воспроизводимости: вместо ручного щёлканья параметров в GUI конфигурацию можно хранить рядом с проектом и запускать одинаково на сервере и рабочей станции.

На первом OCR-запуске стоит отдельно контролировать inference server. Surya запускает его автоматически и может использовать уже работающий endpoint через переменную SURYA_INFERENCE_URL. Для производственной среды это позволяет отделить сам парсер от процесса инференса и не поднимать новую модель на каждый отдельный вызов.

Поддерживаемые форматы и совместимость

Версия 2.0 перечисляет входные PDF, изображения, PPTX, DOCX, XLSX, HTML и EPUB. Для PDF достаточно базовой установки, а для остальных форматов требуется marker-pdf[full]. Старые упоминания MOBI из ранних веток не следует переносить на текущую версию: в актуальном перечне 2.0 MOBI не указан.

Экспорт — Markdown, HTML, JSON и chunks. Обратной конвертации в PDF, DOCX или PPTX нет. Если нужен ручной офисный документ, результат придётся передать следующему инструменту; например, для редактирования текста уместен LibreOffice Writer.

JSON хранит страницы, типы блоков, иерархию и координаты; chunks удобны для retrieval-систем. Для обычного чтения PDF Marker избыточен: Okular и другие просмотрщики решают задачу навигации, тогда как Marker превращает документ в данные.

У форматов есть разные уровни обратимости. Markdown удобен человеку и хорошо подходит для LLM-контекста, но часть геометрии страницы нормализуется. HTML сохраняет больше явной разметки: изображения представлены через img, формулы — через math, код — через pre. JSON наиболее информативен для программной обработки: дочерние блоки содержат тип, HTML, polygon, section hierarchy и изображения, а метаданные включают вычисленное оглавление и статистику по страницам.

Chunks нужен не как «ещё один текстовый экспорт», а как интерфейс между парсером и retrieval-системой. Marker уплощает дерево до верхнеуровневых блоков и вкладывает полный HTML блока, чтобы индексатору не приходилось рекурсивно собирать содержимое. Если следующий этап должен показывать источник на странице или анализировать точные координаты, JSON лучше сохранять параллельно.

Производительность и стабильность

Нагрузка зависит от режима и качества исходника. Цифровой PDF с хорошим текстовым слоем в fast в основном использует pdftext и лёгкий layout detector; сканы, повреждённый текст, сложные формулы и таблицы вызывают VLM. Поэтому скорость без указания режима и железа малоинформативна.

В официальном olmOCR-bench на 1403 PDF Marker 2.0 показывает 76,0% общего результата в balanced, 66,6% в fast и 43,6% без OCR; для поднабора цифровых PDF balanced — 83,5%. На тестовой машине с B200 опубликована устойчивая пропускная способность 2,9 страницы/с для balanced, 7,4 для fast и 23,7 для fast без OCR. Последний путь сам GPU не использует и CPU-bound.

Для каталогов workers используют общий inference server, а суммарная VLM-конкурентность бюджетируется автоматически. Возможны несколько GPU и шардирование по нескольким машинам. Известные ограничения — очень сложные макеты с вложенными таблицами и формы; LLM-режим и force OCR способны помочь, но не дают гарантии безошибочности.

Режимы различаются не только скоростью OCR. В balanced VLM используется для layout и inline math и может переобработать целую страницу, если встроенный текст признан плохим. В fast цифровой документ без уравнений способен пройти без запуска VLM server вообще; для сканированных страниц и низкоуверенных блоков VLM включается точечно. Это делает профиль нагрузки зависимым от состава корпуса: два PDF одинакового размера могут требовать разного времени.

Для таблиц действует похожая логика. Цифровая таблица сначала реконструируется из текстового слоя на CPU, а результат с низкой уверенностью может быть передан VLM. Поэтому включение balanced не означает, что каждая таблица обязательно распознаётся визуально. Такой каскад экономит ресурсы, но требует проверки на документах, где порядок чтения и границы ячеек критичны.

Опубликованные benchmark-цифры следует использовать как контроль архитектурного выбора, а не как SLA. Собственный архив может сильнее отличаться по разрешению сканов, шрифтам, языкам, доле формул и вложенности таблиц. В репозитории есть воспроизводимый benchmark harness, поэтому команда может измерить throughput на своей инфраструктуре вместо переноса показателей B200 на другой сервер.

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

В 2.0 код и модельные веса лицензируются отдельно. Код обозначен как Apache 2.0 и допускает коммерческое использование при соблюдении лицензии. Веса распространяются по modified AI Pubs Open Rail-M и имеют дополнительные ограничения.

В актуальном MODEL_LICENSE порог указан как более 5 млн долларов валовой выручки за предыдущий год или более 5 млн долларов привлечённого equity/debt funding; личное использование и исследования оговорены отдельно. Также ограничено коммерческое использование весов в продукте или сервисе, конкурирующем с предложениями лицензиара. Для случаев за пределами этих условий Datalab предлагает коммерческую лицензию.

Версии важно не смешивать: marker-pdf 1.10.2 от 31 января 2026 года в PyPI был помечен GPLv3+, а 2.0.0 — Apache-2.0. У локального пакета нет платной Pro-редакции, счётчика страниц или пробного срока; облачная платформа Datalab имеет отдельные тарифы и не обязательна для marker-pdf.

Для локальной установки не требуется подписка, активация или пробный период. Ограничений по числу страниц, встроенных в CLI, документация не заявляет; практический предел задают вычислительные ресурсы и лицензия весов. Это отличает пакет от управляемого API Datalab, где тарификация и бесплатный лимит относятся к облачному сервису, а не к локальному marker-pdf.

При корпоративном внедрении полезно фиксировать три объекта раздельно: версию Python-пакета, версию/источник модельных весов и условия их лицензии. Апгрейд кода не должен автоматически означать, что юридические условия весов не изменились. Для дистрибуции собственного продукта поверх Marker особенно важно проверять не только Apache NOTICE/атрибуцию кода, но и ограничения MODEL_LICENSE.

Системные требования

Базовая среда

Marker 2.0 требует Python 3.10 или новее, но ниже 4, и PyTorch. Универсальный wheel не означает одинаковую готовность всех ОС: inference backend имеет собственные зависимости. Официальный README не публикует единые минимумы RAM, VRAM и диска, поэтому придумывать такие числа нельзя.

NVIDIA GPU

Для Surya на NVIDIA документация указывает vLLM через Docker, а также Docker и NVIDIA Container Toolkit. Balanced рассчитан прежде всего на GPU. Конкретный минимальный объём VRAM в README Marker 2.0 не установлен.

CPU и Apple Silicon

Для CPU и Apple Silicon используется llama.cpp и llama-server; для macOS приведена установка через Homebrew. На CPU/MPS default — fast. При —disable_ocr inference server не запускается. Windows не имеет отдельной официальной desktop-инструкции, поэтому совместимость нужно проверять на уровне Python, PyTorch и выбранного backend.

Surya backend допускает явный выбор через SURYA_INFERENCE_BACKEND, настройку параллельности через SURYA_INFERENCE_PARALLEL, сохранение сервера между вызовами через SURYA_INFERENCE_KEEP_ALIVE и выбор GPU через VLLM_GPUS. Эти параметры относятся уже к эксплуатации, а не к минимальной установке, но именно они определяют предсказуемость batch-нагрузки.

Для CPU-only архива цифровых PDF можно вообще уйти от VLM с —disable_ocr. Это снижает требования к inference-инфраструктуре, но цена такого упрощения — отсутствие OCR для сканов и отсутствие VLM-распознавания уравнений. Поэтому «CPU поддерживается» не следует понимать как идентичное качество во всех режимах.

Преимущества и недостатки marker-pdf

Плюсы и минусы

Сравнение с аналогами

С Sumatra PDF прямое соревнование некорректно: Sumatra читает и показывает документ, Marker превращает его в данные. Если нужно пролистать руководство, Marker лишний; если нужен Markdown, таблицы, JSON или chunks для поиска — просмотрщик этой задачи не решает.

Docling близок по классу и поддерживает ещё более широкий набор форматов и единое DoclingDocument. MinerU также парсит PDF и офисные файлы, а его документация публикует более формализованные аппаратные профили. Выбирать между ними лучше на репрезентативном корпусе и по схеме следующего этапа.

ABBYY FineReader удобнее там, где нужен GUI и ручная вычитка OCR. Для просмотра и визуального редактирования уместнее продукты класса PDF-XChange Editor; Marker предназначен для автоматизированного конвейера.

Есть и принципиальная разница в характере ошибок. У просмотрщика ключевой риск — неправильное отображение страницы; у Marker важнее семантическая ошибка: перепутанный порядок колонок, потерянный заголовок, неверно собранная таблица или формула. Поэтому проверять его нужно не визуальной плавностью интерфейса, а набором эталонных документов и автоматическими/ручными проверками структуры.

Если приоритет — классическая работа с PDF в GUI, имеет смысл сначала посмотреть на Foxit Reader или другой просмотрщик. Если же документ является входом для поиска, аналитики или LLM, Marker, Docling и MinerU относятся к более релевантному классу инструментов.

Карта критических зависимостей

«Локальный» здесь означает, что сам pipeline можно держать в своей инфраструктуре, но установочный контур и backend надо подготовить. Подключение Gemini, Claude, OpenAI, Azure, Vertex или OpenRouter меняет границу приватности; локальный Ollama оставляет LLM-этап внутри своей сети, если и модель размещена локально.

Хронология развития и поддержки

31 января 2026 года: в PyPI опубликован marker-pdf 1.10.2. Эта версия была размечена как GPLv3+ и относится к предыдущему поколению пакета. Использовать её лицензионные сведения для 2.0 нельзя.

20 июля 2026 года: вышел Marker 2.0.0. Разработчик описывает его как переписанную версию, сосредоточенный на скорости, полноценной CPU-поддержке и точности. В релиз вошли режимы balanced и fast, новая схема обработки структуры/OCR, единый локальный Surya inference server и обновлённые benchmark-результаты. Метаданные PyPI 2.0.0 и pyproject фиксируют Apache-2.0 для кода.

15 сентября 2026 года: 2.0.0 остаётся последней стабильной публикацией в PyPI. Проект и официальный README актуальны для новой архитектуры. Для внедрения это означает, что миграцию с 1.x нужно рассматривать не как косметическое обновление, а как переход между поколениями: повторно проверить командные параметры, backend, лицензию и результаты на своём эталонном наборе документов.

Практический смысл этой смены поколений — необходимость закреплять версии в рабочем контуре. Команда и конфигурация, проверенные на 1.x, не должны обновляться до 2.0 «в фоне» без регрессионного набора. Даже если основной вызов остался знакомым, архитектура OCR и анализа структуры и условия кода изменились достаточно существенно, чтобы результат и инфраструктурные зависимости перепроверить.

Паспорт обратимости операций

Marker следует считать преобразователем, а не архивом. Markdown и chunks специально нормализуют PDF, поэтому для аудита сохраняйте оригинал, версию marker-pdf, флаги запуска и по возможности JSON как наиболее структурный результат.

Инструкция по установке

Базовая установка для PDF

1. Подготовьте Python от 3.10 до версии ниже 4 и отдельное virtual environment.
2. Установите подходящую сборку PyTorch.
3. Выполните pip install marker-pdf.
4. Для OCR подготовьте backend: NVIDIA — Docker и NVIDIA Container Toolkit; CPU/Apple Silicon — llama-server из llama.cpp.
5. Запустите marker_single /путь/к/файлу.pdf на небольшом образце.
6. Проверьте порядок заголовков, таблицы, формулы и извлечённые изображения, а не только наличие итогового файла.

Расширенные форматы

Для DOCX, PPTX, XLSX, HTML и EPUB установите pip install marker-pdf[full]. Если сервер принимает только PDF, extra full не обязателен. Перед массовой обработкой нового формата полезно держать небольшой эталонный набор для регрессионной проверки после обновлений.

Streamlit-интерфейс

Для визуального старта дополнительно устанавливаются Streamlit и streamlit-ace, затем запускается marker_gui. Найденную рабочую конфигурацию лучше перенести в CLI или config JSON.

Экспресс-аудит за четверть часа

1. Возьмите один цифровой PDF и один скан без чувствительных данных.
2. Цифровой файл обработайте по умолчанию и отдельно с —disable_ocr; скан — с OCR.
3. Для одного образца получите Markdown и JSON.
4. Сверьте заголовки, порядок колонок, одну таблицу, формулу и изображения.
5. Если ошибки сосредоточены на сканах или математике, сравните fast и balanced; LLM подключайте только для тех типов ошибок, которым он действительно нужен.

Безопасное удаление

В отдельном virtual environment достаточно сохранить результаты и удалить окружение. В общем окружении используйте стандартное pip uninstall marker-pdf, но не удаляйте вслепую общие модельные кэши и Docker-образы: ими могут пользоваться другие приложения.

После установки полезно сразу зафиксировать версию пакета в lock-файле или requirements проекта. Для рабочего пайплайна также стоит сохранить конкретные флаги режима, OCR и формат вывода. Это делает повторную обработку объяснимой: при различии результатов можно установить, изменился документ, пакет, модельный backend или конфигурация.

Если обработка идёт на отдельном inference server, сначала проверьте его доступность и только затем запускайте большой каталог. Иначе ошибка backend может повториться на каждом файле и создать длинный список неуспешных задач. В режиме без OCR такой сервер не нужен, поэтому для чистых цифровых архивов это ещё и способ упростить развёртывание.

Практические кейсы

Научная статья с формулами

Цель: Markdown для поиска и заметок. Подготовка: PDF с текстовым слоем и формулами. Шаги: на GPU начните с balanced; на CPU — с fast, при необходимости включив OCR для inline math; изображения оставьте включёнными. Проверка: разделы, LaTeX, таблицы и связи с рисунками. Ограничение: Markdown не сохраняет исходную геометрию страницы.

Сканированный договор

Цель: поисковый текст из скана. Подготовка: читаемые страницы. Шаги: включите OCR; при плохом старом OCR-слое сравните обычный запуск с —strip_existing_ocr или —force_ocr. Проверка: имена, даты, номера и суммы на выборке страниц. Ограничение: юридически значимые поля требуют ручной верификации.

Корпус для RAG

Цель: готовые блоки для индекса. Подготовка: решите, нужна ли полная иерархия. Шаги: экспортируйте chunks, а JSON храните для аудита. Проверка: несколько chunks должны быть самостоятельными и сохранять смысл заголовка с текстом. Ограничение: качество retrieval зависит ещё и от стратегии chunking и embedding, а не только от OCR.

Извлечение таблиц

Цель: отдельные структурные таблицы. Подготовка: образцы цифровых и сканированных таблиц. Шаги: используйте TableConverter; JSON выбирайте для координат, HTML — для готовой разметки. Проверка: колонки, объединённые ячейки и числа. Ограничение: вложенные таблицы и формы относятся к известным сложным случаям.

Пакетная миграция каталога

Цель: обработать архив с возможностью продолжения. Подготовка: разнесите входной каталог и каталог вывода. Шаги: используйте marker, автоматический пул workers и —skip_existing; для нескольких узлов — num_chunks/chunk_idx. Проверка: сверяйте число входов, выходов и список ошибок. Ограничение: смешанный архив сканов и цифровых PDF лучше делить по классам.

Контроль перед сохранением и передачей

• Проверьте порядок заголовков и колонок на нескольких страницах.
• У таблиц сверьте значения и объединённые ячейки, у формул — несколько строчных и блочных выражений.
• Если использовался внешний LLM, зафиксируйте провайдера и модель.
• Если следующий этап зависит от структуры, храните JSON рядом с Markdown или chunks.
• Не удаляйте оригинальный PDF: результат Marker не является его архивной заменой.

Часто задаваемые вопросы

marker-pdf — это PDF-просмотрщик?

Нет. Он читает PDF как источник данных, но не заменяет просмотрщик. Для чтения и печати проще Sumatra PDF; Marker нужен для структурирования.

Нужна ли регистрация?

Для локального пакета — нет. Аккаунт нужен для отдельной платформы Datalab, а API-ключи сторонних LLM — только при использовании соответствующего —use_llm.

Можно ли работать офлайн?

После предварительной установки зависимостей, backend и весов локальный рабочий процесс не обязан обращаться к облаку. Для изолированного контура не подключайте облачные LLM.

Что выбрать: balanced или fast?

На GPU default — balanced, на CPU/MPS — fast. Для чистых цифровых PDF fast экономичнее; для сканов и математики balanced обычно оправданнее. Решение лучше подтверждать на эталонном наборе.

Можно ли отключить OCR?

Да, —disable_ocr отключает VLM. Это ускоряет цифровые PDF с хорошим текстовым слоем, но сканы и формулы, которым нужен OCR, потеряют соответствующую информацию.

Экспортирует ли Marker в PDF или Word?

Нет. Выходы — Markdown, HTML, JSON и chunks. Для финального DOCX или PDF нужен следующий инструмент; для визуального редактирования можно использовать Adobe Acrobat Pro.

Можно ли использовать коммерчески?

Код 2.0 — Apache 2.0, но веса имеют отдельную modified Open RAIL-M с порогами по выручке/финансированию и ограничением для конкурирующих сервисов. Организации за пределами условий нужна отдельная правовая оценка и, возможно, коммерческая лицензия.

Почему старые материалы говорят о GPL?

Потому что 1.10.2 в PyPI действительно был GPLv3+, тогда как 2.0.0 обозначен Apache-2.0. Версию всегда надо проверять явно.

Подходит ли Marker для конфиденциальных документов?

Локальная конфигурация позволяет держать данные внутри своей инфраструктуры. Подключение Gemini, Claude, OpenAI, Azure, Vertex или OpenRouter добавляет внешнего обработчика и должно оцениваться отдельно.

Какие языки поддерживаются?

В текущем описании Marker заявлена работа с документами на всех языках, а Surya OCR описан как многоязычный. При отключённом OCR язык определяется самим текстовым слоем PDF. Отдельной настройки «русский интерфейс» для CLI нет и она не связана с распознаванием.

Можно ли обработать только часть PDF?

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

Можно ли извлечь только OCR или только таблицы?

Да. Помимо PdfConverter предусмотрены OCRConverter и TableConverter. Это уменьшает лишнюю обработку, когда следующему этапу нужен конкретный тип данных, а не полный Markdown документа.

Что сохраняется вместе с текстом?

В зависимости от renderer доступны извлечённые изображения, metadata, вычисленное оглавление, статистика по страницам, типы блоков и координаты. Набор полей отличается между Markdown, HTML, JSON и chunks, поэтому формат следует выбирать по задаче следующего этапа, а не только по удобству чтения.

Вывод

marker-pdf 2.0 подходит разработчикам, исследовательским и data-командам, которым нужно локально превращать PDF и другие документы в Markdown, HTML, JSON или chunks, распознавать сканы, извлекать таблицы и формулы и запускать пакетную обработку. Его сильная сторона — управляемый pipeline, а не визуальный интерфейс.

Он менее удобен тем, кому нужен настольный PDF-комбайн с ручным редактированием и аннотациями. Также требуется учитывать инфраструктуру inference backend и отдельную лицензию модельных весов. Для чтения PDF проще Sumatra PDF, для ручной OCR-верификации — GUI-продукты уровня FineReader, для альтернативных стеков парсинга документов стоит сравнить Docling и MinerU.

Marker особенно уместен в RAG, ETL, научных текстах и массовом извлечении структуры: там ценен не внешний вид страницы, а воспроизводимый структурированный результат, который можно передать следующему этапу обработки.