Главная Программы Офис и продуктивность Средства конвертации документов marker-pdf: инструкция от гика, как Marker 2 превращает PDF и документы в структурированный текст

marker-pdf: инструкция от гика, как Marker 2 превращает PDF и документы в структурированный текст

marker-pdf — это имя Python-пакета проекта Marker, который разбирает PDF и другие документы в структурированный Markdown, JSON, HTML или плоский формат chunks. В актуальной версии 2.0.0 он совмещает извлечение встроенного текстового слоя, анализ макета, OCR на базе Surya, распознавание формул и таблиц, а при необходимости — дополнительную коррекцию через внешний или локальный LLM. Это не редактор PDF и не программа для нанесения пометок: Marker нужен там, где содержимое документа требуется превратить в машиночитаемую структуру для поиска, RAG, индексации, анализа, миграции данных или дальнейшей обработки скриптами.

Что такое marker-pdf и чем он отличается от одноимённых решений

Официальное пользовательское название проекта — Marker, а marker-pdf — название дистрибутива в PyPI. Репозиторий развивается в организации Datalab; автором пакета в PyPI указан Vik Paruchuri. Такая привязка важна, потому что слово Marker используется множеством несвязанных приложений: от инструментов для аннотаций до редакторов заметок и расширений браузера. В этой статье рассматривается только пакет marker-pdf из репозитория Datalab, предназначенный для программного преобразования документов.

Основная задача Marker — не изменить исходный PDF, а восстановить его смысловую структуру. Конвейер выделяет заголовки, абзацы, списки, таблицы, изображения, формулы, колонтитулы и другие блоки, определяет порядок чтения и затем рендерит результат в выбранный формат. Поэтому Marker ближе к document parser и OCR-конвейеру, чем к привычному PDF-редактору. Для ручной правки страниц, подписей и форм в исходном файле разумнее использовать специализированный редактор; на GeekHow есть отдельный материал про бесплатные программы для редактирования PDF.

На 4 сентября 2026 года marker-pdf доступен в PyPI, а последним релизом остаётся версия 2.0.0 от 20 июля 2026 года. Marker 2 заметно отличается от ветки 1.x: он переписан вокруг Surya OCR 2, облегчённой модели анализа макета и обновлённого pdftext. Одновременно изменились режимы обработки, требования к inference backend и лицензирование кода. Поэтому старые команды, советы о прежних моделях и условия использования нельзя автоматически переносить на текущую версию.

Основные параметры marker-pdf

Параметр	Актуальное состояние
Продукт	Marker; пакет PyPI называется marker-pdf
Разработчик	Datalab; автор пакета — Vik Paruchuri
Актуальная версия	2.0.0, опубликована 20 июля 2026 года
Тип	Локальный Python-конвертер документов, CLI, Streamlit GUI, Python API и простой локальный FastAPI-сервер
Основная задача	Преобразование PDF и документов в структурированный Markdown, JSON, HTML или chunks
Базовые входы	PDF и изображения; дополнительные офисные и книжные форматы подключаются через extra full
Расширенные входы	PPTX, DOCX, XLSX, HTML и EPUB после установки marker-pdf[full]
Выходы	Markdown, JSON, HTML, chunks; отдельно сохраняются метаданные и извлечённые изображения
OCR	Surya VLM; режимы balanced, fast и обработка без OCR
Аппаратные варианты	GPU, CPU и Apple Silicon через MPS; VLM обслуживается локальным inference server
Python	3.10 и новее, но ниже Python 4
Интерфейс	CLI и встроенный Marker Demo на Streamlit; подписи GUI в текущем коде англоязычные
Регистрация	Для локального пакета не требуется
Цена локального кода	Код распространяется по Apache 2.0; у весов моделей отдельные коммерческие условия
Интернет	Понадобится для обычной установки из PyPI, получения отсутствующих локально моделей и внешних LLM-сервисов; основной inference server работает локально

По назначению Marker ориентирован прежде всего на разработчиков, исследователей, команды по обработке документов и тех, кто готов работать с Python-окружением. Наличие GUI снижает порог для разовой проверки, но не превращает проект в обычное настольное приложение с установщиком, меню «Файл» и собственным форматом проектов.

Платформы, установка и системные зависимости

marker-pdf поставляется как Python-пакет и требует Python 3.10+ вместе с PyTorch. Сам wheel 2.0.0 опубликован как py3-none-any, однако практическая совместимость определяется зависимостями и inference backend. Для NVIDIA GPU Marker 2 использует vLLM и требует Docker вместе с NVIDIA Container Toolkit. Для CPU и Apple Silicon применяется llama.cpp; на macOS его можно установить через Homebrew, а для других систем доступен бинарный llama-server.

Это означает, что «поддержка платформы» у marker-pdf устроена не как у обычной программы. Для запуска важна не только операционная система, но и то, способен ли выбранный backend обслужить Surya VLM в конкретном окружении. Apple Silicon прямо учтён через MPS и llama.cpp, NVIDIA — через vLLM. PyPI публикует универсальный Python wheel, но Marker 2 не оформляет совместимость как отдельный список поддерживаемых операционных систем. На Windows итоговая работоспособность зависит от Python, PyTorch и выбранного inference backend; требования ветки 2.x здесь нельзя заменять старыми инструкциями для 1.x.

Базовая установка выполняется пакетом marker-pdf. Для DOCX, PPTX, XLSX, HTML и EPUB нужны дополнительные зависимости marker-pdf[full]. Это полезное разделение: если задача ограничена PDF, окружение можно не перегружать библиотеками офисных форматов. Пользователям Linux, которым нужен общий контекст по установке пакетов и приложений, пригодится отдельное руководство GeekHow о том, как устанавливать приложения в Linux.

Marker 2 не задаёт фиксированное минимальное число гигабайт RAM или VRAM в кратких требованиях. Выбор режима и размер документов напрямую влияют на нагрузку: при ошибках нехватки памяти уменьшают число workers, а очень длинные PDF при необходимости делят на несколько файлов.

Интерфейс Marker Demo

Встроенный графический интерфейс запускается командой marker_gui и построен на Streamlit. В актуальном коде страница называется Marker Demo и работает в широком двухколоночном режиме. Слева показывается выбранная страница исходного документа, справа — результат преобразования. Основные параметры собраны в боковой панели, поэтому интерфейс скорее напоминает интерактивную лабораторию для проверки настроек, чем полноценный редактор документов.

Загрузка и предпросмотр

В боковой панели расположен загрузчик PDF, document, or image file. Он принимает PDF и изображения, а при наличии расширенных зависимостей — PPTX, DOCX, XLSX, HTML и EPUB. После загрузки Marker вычисляет количество страниц. В левой колонке появляется поле Page number out of N и изображение выбранной страницы. Это удобно для проверки конкретного разворота, таблицы или формулы до запуска полной обработки.

Диапазон страниц и формат результата

Поле Page range to parse принимает номера через запятую и интервалы вида 0,5-10,20. Нумерация начинается с нуля. Ниже расположен Output format с четырьмя вариантами: markdown, json, html и chunks. Выбор формата влияет не только на оформление вывода, но и на структуру данных: JSON сохраняет дерево блоков, а chunks превращает верхнеуровневые блоки страниц в плоский список, удобный для последующего разбиения материала в RAG-конвейере.

Mode и настройки OCR

Селектор Mode содержит auto, balanced и fast. Auto оставляет выбор устройству: на GPU используется balanced, на CPU и MPS — fast. Отдельные переключатели Force OCR, Disable OCR и Strip existing OCR управляют тем, как Marker обращается с текстовым слоем. Force OCR принудительно распознаёт страницы, Disable OCR исключает вызов VLM и оставляет только извлечение текстового слоя, а Strip existing OCR удаляет существующий OCR-текст и выполняет распознавание заново.

LLM, колонтитулы и Debug

Переключатель Use LLM включает дополнительную коррекцию через выбранный LLM-сервис. Show page headers/footers меняет стандартное поведение: по умолчанию повторяющиеся верхние и нижние колонтитулы удаляются, а эта опция сохраняет их в выводе. Debug включает диагностические артефакты. После обработки интерфейс может показать PDF debug image, Layout debug image и Raw output, что помогает отделить проблему анализа макета от ошибки финального рендеринга.

Зона результата

После Run Marker правая колонка меняется в зависимости от Output format. Markdown отображается как отрендеренный документ с встроенными извлечёнными изображениями, JSON и chunks — как структурированные данные, HTML — через встроенный HTML-рендерер. В текущем коде Marker Demo нет отдельной кнопки экспорта файла, поэтому интерфейс удобнее использовать для проверки результата, а сохранение в заданную папку выполнять CLI-командой marker_single.

Как устроен конвейер распознавания

Marker 2 строится вокруг сочетания текстового слоя PDF, анализа макета и VLM. Сначала pdftext извлекает встроенный текст в порядке чтения. Затем определяется структура страницы: в fast используется облегчённый детектор макета, а balanced сильнее опирается на Surya VLM. После этого система оценивает пригодность встроенного текста и отправляет проблемные участки на OCR. Работа с математикой зависит от режима: balanced распознаёт inline math через VLM, тогда как fast по умолчанию сильнее опирается на текстовый слой; для VLM-обработки inline math в fast предусмотрены force_ocr и ocr_inline_math.

Таблицы восстанавливаются из текстового слоя с помощью CPU-эвристик, а при низкой уверенности возможен переход к VLM. Затем отдельные блоки собираются в документную модель, проходят процессоры и рендерятся в Markdown, HTML, JSON или chunks. Такая архитектура объясняет, почему Marker способен одновременно работать как обычный извлекатель текста на цифровых PDF и как OCR-конвейер на сканах.

Внутренняя модель разделена на Providers, Builders, Processors, Renderers, Schema и Converters. Providers дают доступ к исходным данным, Builders создают блоки документа, Processors исправляют или дополняют отдельные типы блоков, Renderers формируют выход, Schema задаёт типы блоков, а Converters связывают весь путь обработки. Для разработчика это важнее красивого GUI: можно заменить список processors, написать собственный renderer или добавить provider для нового источника.

Режимы balanced, fast и обработка без OCR

Balanced

Balanced предназначен для максимального качества в локальном конвейере и по умолчанию выбирается на GPU. В этом режиме Surya VLM участвует в анализе макета, распознаёт inline math и заново обрабатывает целую страницу, когда встроенный текст признан плохим. Такой подход особенно уместен для сканов, сложной верстки и научных PDF с формулами, но требует более тяжёлого inference backend.

Fast

Fast оптимизирован для CPU и является автоматическим выбором на CPU/MPS. Он использует облегчённый layout detector и pdftext, а VLM вызывает точечно для пустых, испорченных или отсканированных участков и низкоуверенных реконструкций. Математика в fast по умолчанию сильнее зависит от текстового слоя, поэтому для math-heavy документов balanced даёт более полный VLM-путь; при необходимости в fast можно включить force_ocr или ocr_inline_math.

Disable OCR

Disable OCR полностью исключает VLM и оставляет извлечение текстового слоя вместе с анализом структуры. Это самый экономный вариант для born-digital PDF, но у него есть принципиальное ограничение: отсканированные страницы и математические элементы, которым нужен OCR, будут пропущены или потеряют часть содержания. Такой режим нельзя рассматривать как универсальное ускорение — это осознанный отказ от распознавания.

Force OCR и Strip existing OCR

Force OCR нужен, когда цифровой PDF формально содержит текст, но он искажён, имеет неверную кодировку или даёт мусор. Strip existing OCR решает другую задачу: удаляет существующий OCR-слой и формирует новый. Эти режимы не стоит включать автоматически на каждом документе, потому что они увеличивают объём распознавания и могут заменить корректный цифровой текст результатом OCR.

Карта форматов и совместимости

Формат	Роль в Marker	Что сохраняется	Типичные потери или ограничения
PDF	Основной вход	Порядок чтения, заголовки, списки, таблицы, формулы, изображения и часть метаданных	Сложные вложенные таблицы и формы остаются трудными; точность зависит от качества макета и текста
Изображения	Вход для OCR/структурного разбора	Распознанный текст и обнаруженные блоки	Нет исходного текстового слоя; результат зависит от качества изображения
DOCX/PPTX/XLSX	Расширенный вход через marker-pdf[full]	Содержимое преобразуется в общую документную модель и далее в выбранный выход	Требуются дополнительные зависимости; Marker не сохраняет исходный редактируемый формат Office
HTML/EPUB	Расширенный вход через full	Структура и текст преобразуются в модель Marker	Результат ориентирован на содержимое, а не на пиксельное воспроизведение исходного дизайна
Markdown	Выход по умолчанию	Заголовки, списки, таблицы, ссылки, fenced code, формулы LaTeX, ссылки на извлечённые изображения	Не является копией визуальной верстки PDF
HTML	Структурированный выход	Изображения через img, математика через math, код через pre	Ориентирован на смысловую структуру, а не на исходные координаты страницы
JSON	Дерево страниц и блоков	Типы блоков, координаты polygon, иерархия секций, дочерние элементы	Требует программной обработки; сложнее для ручного чтения
Chunks	Плоский JSON-подобный выход	Верхнеуровневые блоки с полным HTML каждого блока	Теряется древовидная форма JSON, зато упрощается подготовка к RAG

Marker не предназначен для обратного восстановления редактируемого PDF или DOCX с исходной геометрией. Если конечная цель — открыть PDF как обычный текстовый документ и затем редактировать его вручную, полезно сравнить подход Marker с классическим способом конвертации PDF в Google Docs: Marker выигрывает в программной структуре и автоматизации, а офисный сценарий — в ручной правке результата.

LLM, OCR, интернет и приватность

Основной Marker 2 использует локальный inference server для Surya VLM. Это отличает его от облачных конвертеров: базовый OCR и анализ макета не требуют отправлять документ в отдельный SaaS только ради распознавания. При этом первоначальная установка, загрузка зависимостей и получение моделей требуют сетевого доступа, если нужные компоненты ещё не находятся в локальном кеше.

Use LLM — отдельный слой. Marker поддерживает Gemini, Google Vertex, Claude, OpenAI-compatible endpoints, Azure OpenAI, OpenRouter и Ollama. Первые варианты предполагают сетевое обращение к внешним сервисам; Ollama позволяет подключить локальную модель. Поэтому для конфиденциальных документов важно различать локальный базовый конвейер и необязательную LLM-коррекцию. Внешний сервис добавляет собственные правила хранения и обработки данных, которые находятся за пределами marker-pdf.

LLM-режим используется для задач, где обычного распознавания недостаточно: объединение таблиц между страницами, дополнительная работа с inline math, улучшение форматирования таблиц и извлечение значений из форм. Также доступен block_correction_prompt, который задаёт дополнительную инструкцию для коррекции блока. Это уже не просто OCR: результат зависит и от поведения выбранной языковой модели.

Регистрация для локального marker-pdf не нужна. Отдельная управляемая платформа Datalab существует как самостоятельный сервис и не является обязательной частью пакета. Такое разделение полезно для выбора инфраструктуры: локальный пакет подходит тем, кто готов управлять моделями и зависимостями самостоятельно, а hosted-подход снимает часть этой нагрузки ценой перехода к внешней платформе.

Пакетная обработка, Python API и локальный сервер

Папки и несколько документов

Команда marker обрабатывает целую входную папку. Параметр workers задаёт число параллельных процессов; по умолчанию оно рассчитывается автоматически. Все workers используют один inference server, а родительский процесс распределяет VLM-concurrency, чтобы не создавать бесконтрольную очередь. Для повторных прогонов есть skip_existing, для ограничения набора — max_files, а disable_multiprocessing отключает многопроцессную обработку.

При обработке на нескольких машинах набор файлов можно разделить через num_chunks и chunk_idx. На много-GPU узле используется переменная VLLM_GPUS. Это делает Marker пригодным не только для одного PDF в терминале, но и для больших корпусов документов, хотя реальная пропускная способность зависит от оборудования, режима, структуры PDF и числа вызовов OCR.

Python API

Базовый программный интерфейс строится вокруг PdfConverter и create_model_dict. Для более тонкой настройки используется ConfigParser, через который выбираются renderer, processor_list и LLM service. Полученный rendered-объект зависит от выбранного формата: Markdown-результат содержит markdown, metadata и images, JSON — children, block_type и metadata. Это даёт разработчику доступ не только к финальному тексту, но и к промежуточной документной структуре.

Специализированные converters

TableConverter извлекает только таблицы и может принудительно считать каждую страницу таблицей через force_layout_block=Table. OCRConverter предназначен для OCR без полного конвейера форматирования; для цифровых PDF у него доступно сохранение отдельных символов и bounding boxes через keep_chars, тогда как VLM-обработанные страницы возвращают блочный HTML без посимвольных координат.

Локальный API server

marker_server запускает простой FastAPI-сервер на локальной машине. Он принимает ограниченный набор параметров: page_range, mode, force_ocr, paginate_output и output_format. LLM-режим и Disable OCR в список параметров этого сервера не входят. marker_server рассчитан на небольшой масштаб, а не является готовым production API с очередями, авторизацией, лимитами и отказоустойчивостью.

Как пользоваться программой — советы гика

Установить Marker 2 и подготовить inference backend

Цель: получить рабочее локальное окружение marker-pdf 2.0.0. Подготовка: нужен Python 3.10+ и PyTorch. Для NVIDIA GPU заранее готовят Docker и NVIDIA Container Toolkit; для CPU или Apple Silicon — llama-server из llama.cpp.

Создайте отдельное Python-окружение, чтобы зависимости Marker не конфликтовали с другими проектами.
Установите пакет командой pip install marker-pdf. Для DOCX, PPTX, XLSX, HTML и EPUB используйте pip install marker-pdf[full].
Для NVIDIA GPU подготовьте vLLM-среду через Docker и NVIDIA Container Toolkit. Для CPU или Apple Silicon установите llama.cpp и убедитесь, что бинарный llama-server доступен системе.
Выполните marker_single —help. Команда должна вывести параметры текущей версии без ошибки импорта.

Проверка результата: справка marker_single открывается, а пакет отображается в текущем Python-окружении. Типичная ошибка: Marker 2 запускается, но сообщает об отсутствии llama-server или inference backend. Безопасный откат: не меняйте глобальный Python; удалите созданное виртуальное окружение и соберите его заново с нужным backend.

Запустить Marker Demo и загрузить документ

Цель: визуально проверить одну или несколько страниц перед массовой обработкой. Подготовка: Marker уже установлен; дополнительно нужны Streamlit и streamlit-ace.

Установите GUI-зависимости командой pip install -U streamlit streamlit-ace.
Запустите marker_gui. Откроется страница Marker Demo.
В боковой панели нажмите загрузчик PDF, document, or image file: и выберите файл.
В левой колонке используйте Page number out of N, чтобы открыть страницу, которую хотите проверить.

Проверка результата: слева отображается изображение выбранной страницы и корректное количество страниц. Типичная ошибка: формат не принимается после базовой установки. Безопасный откат: закройте GUI и установите extra full только в текущем виртуальном окружении, не затрагивая системный Python.

Выбрать диапазон страниц и режим обработки

Цель: обработать только нужную часть документа и заранее выбрать баланс качества и нагрузки. Подготовка: документ открыт в Marker Demo.

В поле Page range to parse, comma separated like 0,5-10,20 укажите страницы с нумерацией от нуля. Для проверки одного листа оставьте диапазон выбранной страницы.
В Mode оставьте auto, если хотите использовать device-aware default.
Выберите balanced для тяжёлой обработки с активным VLM или fast для более лёгкого конвейера с точечным OCR.
Не включайте Force OCR, Strip existing OCR и Disable OCR одновременно без конкретной причины: каждый переключатель меняет стратегию распознавания.

Проверка результата: диапазон соответствует нужным страницам, а Mode показывает выбранное значение. Типичная ошибка: указан номер за пределами документа или перепутана нумерация с единицы. Безопасный откат: верните поле к одной известной странице и Mode к auto.

Получить Markdown с таблицами, формулами и изображениями

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

В Output format выберите markdown.
Оставьте Show page headers/footers выключенным, если повторяющиеся колонтитулы не нужны в тексте.
Нажмите Run Marker.
Сравните правую колонку с исходной страницей: порядок заголовков, абзацев, таблиц и формул должен соответствовать содержанию PDF.

Важные параметры: Markdown хранит формулы в LaTeX, код в fenced blocks, таблицы в структурированном виде и ссылки на извлечённые изображения. Проверка результата: смысловой порядок не нарушен, таблица не потеряла строки, формулы не превратились в случайный текст. Типичная ошибка: цифровой текст выглядит как набор неверных символов. Безопасный откат: не редактируйте исходный PDF; измените только OCR-настройку и повторите вывод в отдельную папку.

Использовать JSON, HTML и chunks

Цель: получить не человекочитаемый Markdown, а структуру для интеграции. Подготовка: сначала убедитесь на одной странице, что Marker правильно определяет порядок чтения.

Для дерева блоков выберите json. В результате будут страницы, block_type, polygon, children и иерархия секций.
Для готовой HTML-структуры выберите html. Изображения попадут в img, математика — в math, код — в pre.
Для плоского списка верхнеуровневых блоков выберите chunks. Этот вариант удобен перед последующим разбиением и индексацией.
Запустите Run Marker и проверьте тип результата в правой колонке.

Проверка результата: JSON содержит координаты и дочерние блоки, HTML сохраняет структуру, chunks не требует обхода глубокой иерархии. Типичная ошибка: chunks принимают за готовый Markdown-файл. Безопасный откат: смените только Output format и выполните обработку повторно; исходник остаётся неизменным.

Исправить плохой текст с Force OCR и Strip existing OCR

Цель: заменить непригодный текстовый слой корректным распознаванием. Подготовка: сначала получите обычный результат и убедитесь, что проблема действительно связана с текстом, а не с неправильным порядком блоков.

При испорченном цифровом тексте включите Force OCR и повторите ту же страницу.
Если PDF уже содержит некачественный OCR-слой, включите Strip existing OCR, чтобы удалить его перед новым распознаванием.
Сохраните остальные параметры без изменений, иначе будет трудно понять, какая настройка исправила проблему.
Сравните результат по короткому фрагменту, числам и специальным символам.

Проверка результата: слова и числа совпадают с изображением страницы, а порядок блоков не ухудшился. Типичная ошибка: Force OCR включают на хорошем born-digital PDF и получают больше ошибок, чем при использовании встроенного текста. Безопасный откат: отключите Force OCR и Strip existing OCR и вернитесь к базовому режиму.

Отключить OCR для чистых born-digital PDF

Цель: исключить VLM, когда документ уже содержит корректный текстовый слой. Подготовка: убедитесь, что PDF не является сканом и не содержит критичных формул, требующих VLM.

В GUI включите Disable OCR или в CLI добавьте —disable_ocr.
Оставьте Mode fast или auto; при Disable OCR inference server не запускается.
Обработайте небольшой диапазон, где есть обычный текст, колонки и таблица.
Проверьте, что важные элементы не исчезли.

Проверка результата: цифровой текст и структура сохранены без OCR. Типичная ошибка: сканированные страницы оказываются пустыми, а формулы теряются. Безопасный откат: выключите Disable OCR и повторите только проблемные страницы.

Подключить LLM-коррекцию

Цель: улучшить сложные таблицы, формы и математические блоки после базового распознавания. Подготовка: выбран и настроен один из поддерживаемых сервисов — Gemini, Vertex, Claude, OpenAI-compatible, Azure OpenAI, OpenRouter или Ollama.

Сначала получите результат без LLM и сохраните его как контрольный вариант.
В GUI включите Use LLM; в CLI используйте —use_llm.
При необходимости задайте —llm_service для выбранного backend. Для Gemini передайте учётные данные через —gemini_api_key; для Ollama задайте —ollama_base_url и —ollama_model.
Для дополнительной коррекции блока используйте —block_correction_prompt; для максимально качественной повторной обработки inline math вместе с LLM доступен —redo_inline_math.
Повторите тот же диапазон страниц и сравните структуру, а не только внешний вид.

Проверка результата: таблицы, формы или inline math исправились без потери фактического содержания. Типичная ошибка: включён Use LLM, но сервис не настроен или недоступен по сети. Безопасный откат: отключите Use LLM и используйте сохранённый базовый вариант; исходный документ Marker не изменяет.

Встроить Marker в Python-код

Цель: получать результат Marker внутри собственного приложения без запуска отдельной CLI-команды. Подготовка: пакет и inference backend уже работают на тестовом документе.

Импортируйте PdfConverter из marker.converters.pdf и create_model_dict из marker.models.
Создайте converter как PdfConverter(artifact_dict=create_model_dict()).
Передайте путь к документу вызовом rendered = converter(«FILEPATH»).
Для Markdown прочитайте поля rendered.markdown, rendered.metadata и rendered.images; для другого renderer ориентируйтесь на его модель результата.
Если нужен управляемый output_format, processors или LLM service, формируйте конфигурацию через ConfigParser и передавайте созданные им параметры в converter.

Проверка результата: приложение получает rendered-объект и может отдельно сохранить текст, метаданные и изображения. Типичная ошибка: код ожидает поле markdown у JSON-результата, хотя набор полей зависит от renderer. Безопасный откат: вернитесь к Markdown renderer по умолчанию и сначала подтвердите базовый PdfConverter на одном файле.

Извлечь только таблицы или только OCR

Цель: не запускать полный PDF-конвейер, когда нужна узкая задача. Подготовка: работайте через CLI или Python API, потому что GUI не даёт отдельного переключателя converter_cls.

Для таблиц используйте —converter_cls marker.converters.table.TableConverter. При необходимости добавьте —force_layout_block Table, чтобы рассматривать каждую страницу как таблицу.
Выберите JSON, если нужны bounding boxes таблиц, или обычный рендеринг для HTML-представления таблиц.
Для OCR без полного форматирования укажите —converter_cls marker.converters.ocr.OCRConverter.
На цифровом PDF включайте keep_chars только тогда, когда нужны отдельные символы и их координаты.

Проверка результата: TableConverter выдаёт таблицы, OCRConverter — OCR-структуру без лишних преобразований. Типичная ошибка: пользователь ожидает от TableConverter полный текст страницы. Безопасный откат: верните стандартный PdfConverter, который используется по умолчанию.

Обработать папку документов и безопасно возобновить прогон

Цель: конвертировать большой набор файлов без ручного запуска marker_single для каждого документа. Подготовка: сначала успешно обработайте один типичный файл с теми же параметрами.

Запустите marker /path/to/input/folder —output_dir out.
Оставьте автоматический workers, пока не убедитесь в стабильности памяти. Увеличивать его имеет смысл только после контроля нагрузки.
Для повторного запуска добавьте —skip_existing, чтобы уже созданные результаты не обрабатывались заново.
Для ограниченного теста используйте —max_files N.
Если многопроцессная схема мешает диагностике, добавьте —disable_multiprocessing.

Проверка результата: в output_dir появляются каталоги документов и соответствующие md, html или json-файлы вместе с сопутствующим файлом метаданных с суффиксом _meta.json и извлечёнными изображениями. Типичная ошибка: рост потребления памяти при слишком большом числе workers. Безопасный откат: остановите прогон, уменьшите workers и возобновите его с skip_existing.

Сквозной сценарий: PDF → Markdown → сохранённый набор файлов

Цель: получить воспроизводимый результат от исходного PDF до сохранённого Markdown. Подготовка: рабочее окружение Marker 2 уже настроено, а исходный файл хранится отдельно.

Откройте одну характерную страницу в Marker Demo и проверьте её в Mode auto с Output format markdown.
Если текст читается корректно, не включайте Force OCR. Если цифровой слой повреждён, повторите страницу с Force OCR и выберите лучший вариант.
Закройте тестовый цикл в GUI и выполните marker_single /path/to/file.pdf —output_format markdown —output_dir /path/to/out.
Откройте созданный файл с расширением md и сопутствующий файл с суффиксом _meta.json. Сверьте заголовки, одну таблицу, формулу и ссылку на извлечённое изображение.
Не удаляйте исходный PDF после успешной конвертации: Markdown является производным представлением и не хранит всю визуальную геометрию исходника.

Проверка результата: итоговая папка содержит Markdown, метаданные и извлечённые изображения, а контрольные элементы совпадают с PDF. Типичная ошибка: считать результат полной заменой исходного документа. Безопасный откат: храните исходный PDF как эталон и создавайте новые результаты в отдельном output_dir.

Задача → инструмент → результат → что проверить

Задача	Инструмент Marker	Результат	Что проверить
Подготовить PDF для RAG	PdfConverter + chunks или JSON	Структурированные блоки документа	Порядок секций, границы таблиц, наличие подписей и изображений
Получить читаемый текст	Markdown renderer	MD с таблицами, LaTeX и ссылками на изображения	Заголовки, списки, формулы и отсутствие повторяющихся колонтитулов
Разобрать скан	Balanced или Force OCR	OCR-текст со структурой страницы	Числа, имена, формулы, мелкий текст и порядок колонок
Ускорить born-digital PDF	Fast либо Disable OCR	Текст из встроенного слоя с анализом структуры	Не исчезли ли сканированные вставки и математика
Извлечь таблицы	TableConverter	HTML-таблицы или JSON-блоки с координатами	Количество строк, столбцов, объединённые ячейки и перенос между страницами
Получить OCR-структуру	OCRConverter	Распознанные блоки без полного документного рендеринга	Границы блоков и качество текста
Обработать коллекцию	marker для папки	Набор выходных каталогов	workers, пропуски, стабильность памяти и наличие файла с суффиксом _meta.json
Улучшить сложные формы	Use LLM + выбранный сервис	Скорректированная структура	Фактическая точность и отсутствие нежелательных изменений текста

Эта карта подчёркивает главную особенность Marker: один и тот же PDF можно обрабатывать разными путями. Нельзя оценивать качество пакета одной настройкой. Для цифровой книги, скана счета и математической статьи оптимальный режим будет различаться, потому что источники ошибок у них разные.

Что перестанет работать первым при сбое зависимостей

Inference backend. В Marker 2 Surya VLM обслуживается отдельным локальным сервером. Если vLLM или llama-server не установлен либо не запускается, balanced и OCR-зависимые операции ломаются раньше, чем обычное чтение цифрового текста. Это особенно заметно после перехода с 1.x, где окружение могло работать без нового внешнего llama-server.

Загрузка моделей. При пустом локальном кеше первая обработка зависит от доступности источника моделей. Уже установленный Python-пакет сам по себе не гарантирует, что все веса присутствуют на машине. Сетевые ограничения и корпоративный proxy могут проявиться именно в момент первой инициализации.

Внешний LLM. Базовая конвертация продолжает работать без Use LLM, но дополнительная коррекция остановится при проблемах с учётными данными, endpoint или сетью. Для локального Ollama эта зависимость смещается с интернета на собственный сервер модели.

GUI. marker_single может оставаться работоспособным, даже если Streamlit-часть не запускается. Marker Demo требует отдельных пакетов streamlit и streamlit-ace, поэтому проблема GUI не означает поломку самого конвертера.

Расширенные входы. PDF работает в базовой установке, тогда как офисные и книжные документы требуют extra full. Отсутствующая зависимость проявится только при попытке открыть соответствующий формат.

Многопроцессная обработка. При нехватке памяти первым ухудшается масштабирование: слишком большой workers приводит к OOM, хотя одиночный marker_single на том же документе может работать нормально. Поэтому проблемы большого batch не следует автоматически трактовать как несовместимость файла.

Жизненный цикл marker-pdf: переход от 1.x к Marker 2

До Marker 2 последней заметной веткой была 1.10.2, опубликованная 31 января 2026 года. В PyPI она всё ещё помечена как GPL-3.0-or-later. Версия 2.0.0, вышедшая 20 июля 2026 года, стала крупной переработкой: проект перешёл на Surya OCR 2, новый быстрый layout model, обновлённый pdftext и device-aware режимы balanced/fast.

Второе важное изменение — лицензирование. Код Marker 2 опубликован по Apache 2.0, тогда как веса моделей отделены и регулируются modified AI Pubs OpenRAIL-M. Это не косметическая правка текста лицензии: пользователям, которые переносили корпоративную интеграцию с ветки 1.x, нужно перепроверить как техническую совместимость, так и условия применения весов.

Третье изменение — inference backend. Marker 2 автоматически поднимает сервер Surya и требует vLLM на NVIDIA GPU либо llama.cpp на CPU/Apple Silicon. Поэтому обновление через обычный pip может завершиться успешно, а первый реальный запуск — остановиться на отсутствующем backend. Это подтверждённое отличие 2.0.0, а не универсальная проблема всех версий Marker.

Для долгоживущих проектов полезно фиксировать версию marker-pdf в окружении и хранить рабочий набор параметров рядом с кодом интеграции. Поскольку схема блоков, default mode и модели меняются, повторная обработка одного архива разными поколениями пакета способна дать структурно отличающиеся результаты даже при одинаковом исходном PDF.

Производительность и опубликованные benchmark-данные

Marker 2 публикует воспроизводимый набор результатов на стороннем olmOCR-bench, содержащем 1403 PDF и примерно 8400 проверок по математике, таблицам, порядку чтения, колонтитулам и старым сканам. На указанном проектом B200-host режим balanced получает 76,0% overall при 2,9 страницы/с, fast — 66,6% при 7,4 страницы/с, а fast с отключённым OCR на CPU — 43,6% при 23,7 страницы/с. Эти числа относятся к конкретному benchmark и не являются обещанием скорости на обычном ноутбуке.

Практический вывод из этих данных не в том, что один режим «всегда быстрее». Balanced тратит больше ресурсов ради OCR и качества сложных страниц. Fast сильнее использует встроенный текст и лёгкие детекторы. Disable OCR переносит акцент на чистый цифровой текст и ради скорости сознательно отказывается от сканов и части математического содержания. Сравнивать режимы имеет смысл только на документе того типа, с которым будет работать реальный конвейер.

Для пакетной обработки производительность зависит от workers и общей VLM-concurrency. Marker 2 автоматически распределяет обращения к inference server между workers и не рекомендует бездумно увеличивать параллелизм. При OOM базовая рекомендация проекта — уменьшить число workers или разбить длинные PDF.

Ограничения и границы применимости

PDF остаётся сложным форматом, и Marker прямо сохраняет ограничения для очень сложных макетов. Вложенные таблицы, формы, нестандартные колонки и страницы с большим количеством пересекающихся объектов могут разбираться неправильно. Use LLM и Force OCR способны улучшить часть таких случаев, но не превращают конвертацию в гарантированно безошибочное восстановление исходной структуры.

Формы — отдельная слабая зона: даже при корректном распознавании текста итоговый Markdown не обязан сохранять визуальную логику полей. Для задач, где юридически или бухгалтерски значима точная связь «подпись поля → значение», нужен контроль результата по исходной странице. Marker умеет извлекать значения с LLM-коррекцией, но это требует дополнительной проверки, а не отменяет её.

Не стоит ждать от Marker pixel-perfect HTML. Выход ориентирован на содержимое и структуру. Координаты блоков доступны в JSON, однако Markdown и HTML предназначены для дальнейшего использования текста, а не для верстки точной копии PDF. Если цель — сохранить исходный дизайн один в один, нужен другой класс инструментов.

GUI тоже имеет ограничения: Marker Demo не содержит полноценного менеджера проектов, истории версий, встроенного редактора Markdown и кнопки пакетного экспорта. Это тестовая оболочка над теми же конвертерами, а серьёзная автоматизация строится через CLI, Python API или собственный сервис.

Цена, лицензирование и коммерческое использование

Код Marker 2 лицензирован по Apache 2.0 и может использоваться коммерчески. Веса моделей лицензируются отдельно по modified AI Pubs OpenRAIL-M. В MODEL_LICENSE коммерческие ограничения срабатывают, если организация превысила 5 млн долларов выручки за предыдущий год, привлекла более 5 млн долларов совокупного финансирования или предлагает продукт либо сервис, конкурирующий с продуктами Datalab и её аффилированных компаний. Для использования весов за пределами этих условий Datalab предлагает отдельное коммерческое лицензирование.

MODEL_LICENSE содержит и другие условия использования, распространения, атрибуции и share-alike, поэтому Apache 2.0 нельзя переносить с исходного кода на веса или их производные. Для корпоративного внедрения нужно оценивать именно текущий MODEL_LICENSE вместе с лицензией кода, а не только строку License на странице пакета.

Таким образом, у marker-pdf нет классических тарифов Free, Pro и Trial. Локальный код устанавливается без подписки и регистрации, но стоимость владения складывается из оборудования, инфраструктуры inference server и, при включённом Use LLM, расходов выбранного внешнего сервиса. У Ollama можно оставить LLM локальным, но тогда вычислительная нагрузка переносится на собственную машину.

Managed platform Datalab — отдельный коммерческий продукт и не должна смешиваться с marker-pdf. В пакете нет обязательной подписки на hosted API; пользователь может полностью строить конвейер локально. Для бизнеса это принципиально: цена локальной эксплуатации определяется инфраструктурой и условиями лицензии весов, а не фиксированной помесячной ценой marker-pdf.

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

Плюсы

Одним конвейером обрабатываются обычный текстовый слой, OCR, макет, таблицы, формулы, изображения и колонтитулы.
Есть четыре выхода с разной задачей: Markdown для текста, HTML для веб-структуры, JSON для дерева блоков и chunks для RAG.
Marker 2 автоматически подбирает balanced на GPU и fast на CPU/MPS, но оставляет ручной контроль режима.
Пакет работает через CLI, Python API и batch-команду, поэтому хорошо встраивается в автоматизированные процессы.
Встроенный Marker Demo позволяет визуально сравнивать исходную страницу и результат без написания собственного интерфейса.
TableConverter и OCRConverter позволяют запускать специализированный конвейер вместо полного PDF-разбора.
Основной Surya inference server локальный; внешний LLM остаётся необязательным.
Код Marker 2 перешёл на Apache 2.0, что упрощает использование самого кода по сравнению с прежней GPL-веткой.

Минусы

Установка Marker 2 включает отдельные требования к vLLM или llama.cpp; обычного pip install недостаточно для всех режимов.
Веса моделей имеют отдельные ограничения по выручке, финансированию и конкурентному использованию, поэтому Apache 2.0 на код не описывает целиком условия бизнеса.
Сложные вложенные таблицы и формы остаются подтверждённым ограничением.
GUI рассчитан на интерактивную проверку и не заменяет полноценное настольное приложение.
Disable OCR ускоряет цифровые документы ценой потери сканов и части математического содержимого.
LLM-коррекция повышает зависимость от отдельного сервиса и требует дополнительного контроля фактической точности.
Markdown и HTML не восстанавливают исходную страницу пиксель в пиксель.

Кому подойдёт

Разработчикам RAG и поиска по документам. JSON и chunks дают блоки, координаты и структуру, которые проще индексировать, чем сырой PDF.
Командам, превращающим PDF-архивы в Markdown. Пакетная команда, skip_existing и sharding позволяют построить повторяемый pipeline.
Исследователям и техническим редакциям. Формулы, таблицы, научная верстка и OCR собраны в одном инструменте.
Пользователям с конфиденциальными документами. Базовый конвейер работает через локальный inference server, а LLM можно не включать или подключить локально через Ollama.
Разработчикам собственных document parsers. Providers, Processors, Renderers и Converters можно расширять, не переписывая весь проект.

Кому не подойдёт

Тем, кому нужен обычный PDF-редактор. Marker не меняет страницы, не добавляет подписи и не редактирует исходный PDF.
Пользователям без готовности работать с Python и зависимостями. Даже наличие GUI не отменяет настройки окружения и inference backend.
Задачам с требованием pixel-perfect копии. Выход сохраняет смысловую структуру, а не визуальный макет один в один.
Сценариям, где любой OCR-ошибке нельзя доверять без проверки. Marker помогает извлечь структуру, но не заменяет контроль критичных чисел, имён и форм.
Командам, которым нужен готовый production SaaS из коробки. Встроенный marker_server прямо предназначен для небольшого масштаба и не предоставляет полноценную платформенную инфраструктуру.

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

Критерий	Marker / marker-pdf	Docling	MinerU	MarkItDown
Основная задача	Структурный разбор PDF и документов с OCR/VLM	Унифицированная модель документа и экспорт в множество форматов	Высокоточный parsing документов с VLM/OCR	Лёгкое преобразование множества файлов в Markdown для анализа
Платформа	Python; GPU, CPU, MPS; backend зависит от окружения	Python; macOS, Linux, Windows, x86_64 и arm64	Windows, Linux, macOS; CPU, CUDA, NPU и MPS	Python 3.10+; CLI и библиотека, без собственного GUI в основном проекте
Порог освоения	Средний/высокий из-за Surya inference server и режимов	Средний: богатая модель документа и много параметров	Высокий при локальной VLM-инфраструктуре, ниже через WebUI	Ниже для простой конвертации в Markdown
Входные форматы	PDF, изображения; через full — DOCX, PPTX, XLSX, HTML и EPUB	PDF, Office, OpenDocument, EPUB, Pages, Markdown, AsciiDoc, LaTeX и др.	PDF, изображения, DOCX, PPTX, XLSX	PDF, Office, изображения, audio, HTML, CSV/JSON/XML, ZIP, EPUB и др.
Выходы	Markdown, HTML, JSON, chunks	Markdown, JSON, HTML, text, DocLang, chunks, LaTeX и другие	Markdown, JSON и промежуточные структурированные представления	Прежде всего Markdown
OCR и сложный layout	Surya VLM, balanced/fast, Force OCR	Несколько OCR/VLM-пайплайнов и собственная document model	VLM+OCR dual engine, автоматическое распознавание сканов	Базовые конвертеры проще; OCR расширяется плагином или Azure-интеграцией
Автоматизация	CLI, batch, Python API, простой FastAPI server	CLI, Python API, docling-serve и chunking	CLI, FastAPI, Gradio WebUI, интеграции	CLI, Python API, плагины; веб-интерфейс не входит в scope проекта
Модель оплаты	Код Apache 2.0; отдельные условия весов	Код MIT; обязательной подписки на локальный пакет нет	MinerU Open Source License на базе Apache 2.0 с дополнительными условиями	Код MIT; обязательной подписки на локальный пакет нет, облачные интеграции остаются отдельными сервисами
Основное ограничение	Сложная установка 2.x и отдельная лицензия весов	Более широкий стек и модель данных могут быть избыточны для простого PDF→MD	Тяжёлый стек для локальной высокоточной обработки	Не ориентирован на максимально точное восстановление сложной PDF-верстки
Лучший сценарий	PDF/сканы, где нужны Markdown/JSON и управляемый OCR	Многоформатная document intelligence и богатый унифицированный объект	Сложные документы, много языков и развитый VLM/OCR pipeline	Быстрая подготовка разных файлов к текстовому анализу

Marker выигрывает, когда основная проблема — именно качество PDF-разбора с контролируемым OCR и удобным JSON/chunks. Docling сильнее выглядит как универсальная экосистема документной модели и экспорта. MinerU ближе всего по тяжёлому VLM/OCR-сценарию и предлагает более широкий набор готовых интерфейсов. MarkItDown проще, когда важнее быстро получить Markdown из разных файлов, чем восстанавливать сложную структуру страницы.

Типичные проблемы и диагностика

Marker 2 установлен, но при первом запуске не найден llama-server

Симптом: pip install завершился, а marker_single падает при запуске Surya. Возможная подтверждённая причина: в Marker 2 CPU и Apple Silicon требуют внешнего llama-server, который не ставится самим marker-pdf. Диагностика: проверьте доступность бинарного файла в PATH и выбранный Surya backend. Исправление: установите llama.cpp либо явно укажите путь к бинарному файлу в окружении. Проверка: повторный marker_single доходит до инициализации модели и начинает обработку.

На NVIDIA GPU не поднимается VLM

Симптом: balanced не стартует, хотя PyTorch видит CUDA. Возможная подтверждённая причина: Marker 2 использует vLLM server и требует Docker вместе с NVIDIA Container Toolkit. Диагностика: отдельно проверьте работоспособность Docker и доступ контейнера к GPU. Исправление: восстановите backend, не меняя сам PDF и параметры конвертации. Проверка: Surya server запускается, а balanced обрабатывает одну тестовую страницу.

Цифровой PDF выдаёт искажённые символы

Симптом: слова выглядят как мусор, хотя визуально PDF читается нормально. Возможная подтверждённая причина: встроенный текстовый слой повреждён или неправильно закодирован. Диагностика: сравните обычный результат и распознавание одной страницы с Force OCR. Исправление: используйте Force OCR; при плохом существующем OCR-слое добавьте Strip existing OCR. Проверка: контрольные слова, числа и спецсимволы совпадают с изображением страницы.

Сканированная страница пустая при Disable OCR

Симптом: часть страниц исчезает из результата. Возможная подтверждённая причина: Disable OCR запрещает вызов VLM, а у скана нет пригодного цифрового текста. Диагностика: откройте страницу в Marker Demo и убедитесь, что это изображение без выделяемого текста. Исправление: отключите Disable OCR для этого документа или диапазона. Проверка: после повторной обработки текст появляется.

Формулы пропали в ускоренном режиме без OCR

Симптом: обычный текст сохранился, а математические элементы отсутствуют или упрощены. Возможная подтверждённая причина: pdftext не представляет математическую структуру, а VLM был отключён. Диагностика: сравните страницу с Disable OCR и обычным fast/balanced. Исправление: верните OCR; для максимального качества inline math используйте balanced, а при необходимости LLM-коррекцию. Проверка: формула снова присутствует в LaTeX-представлении.

Таблица имеет неправильные строки или столбцы

Симптом: текст таблицы распознан, но структура ячеек нарушена. Возможная подтверждённая причина: сложные или вложенные таблицы остаются известным ограничением Marker; low-confidence реконструкция не всегда восстанавливает исходную сетку. Диагностика: включите Debug и сравните Layout debug image с исходником; отдельно протестируйте TableConverter. Исправление: для сложного случая включите Use LLM и при необходимости Force OCR. Проверка: число строк, столбцов и значения контрольных ячеек совпадают с PDF.

Большая пакетная обработка завершается OOM

Симптом: одиночный PDF работает, а обработка папки падает по памяти. Возможная подтверждённая причина: слишком много параллельных workers или слишком длинные документы. Диагностика: повторите один файл с меньшим workers и сравните стабильность. Исправление: уменьшите workers; при необходимости разделите длинные PDF. Проверка: batch проходит без OOM, а уже готовые результаты можно пропустить через skip_existing.

GUI не запускается, но CLI установлен

Симптом: marker_single работает, а marker_gui завершается ошибкой импорта. Возможная подтверждённая причина: Streamlit и streamlit-ace устанавливаются отдельно. Диагностика: проверьте наличие этих пакетов в том же виртуальном окружении, где установлен marker-pdf. Исправление: добавьте GUI-зависимости без переустановки всего окружения. Проверка: Marker Demo открывается и показывает загрузчик файла.

DOCX, PPTX или XLSX не открывается

Симптом: PDF работает, а офисный файл вызывает ошибку зависимости. Возможная подтверждённая причина: базовый пакет не включает полный набор библиотек для не-PDF документов. Диагностика: проверьте, установлен ли extra full. Исправление: установите marker-pdf[full] в текущем виртуальном окружении. Проверка: тот же файл появляется в GUI и проходит converter.

LLM-режим включён, но качество не меняется или обработка падает

Симптом: Use LLM не даёт результата либо сервис возвращает ошибку. Возможная подтверждённая причина: не настроен выбранный llm_service, отсутствуют учётные данные или endpoint недоступен. Диагностика: сначала подтвердите, что обычный Marker работает без LLM, затем проверьте конфигурацию конкретного сервиса. Исправление: восстановите соединение и параметры сервиса либо переключитесь на локальный Ollama. Проверка: повторный запуск проходит, а изменения видны на заранее выбранной сложной таблице или форме.

Локальный marker_server не принимает нужный параметр

Симптом: через HTTP нельзя включить Use LLM или Disable OCR. Возможная подтверждённая причина: встроенный сервер намеренно принимает только page_range, mode, force_ocr, paginate_output и output_format. Диагностика: сравните параметр со списком API server. Исправление: используйте CLI или Python API для функций, которых нет в простом сервере. Проверка: выбранная функция успешно выполняется вне marker_server.

FAQ

marker-pdf — это то же самое, что Marker?

Да. Marker — название проекта, а marker-pdf — имя пакета в PyPI. В разговоре и документации чаще встречается Marker, в командах установки — marker-pdf.

Можно ли использовать Marker как PDF-редактор?

Нет. Он извлекает и структурирует содержимое, но не редактирует страницы исходного PDF. Для изменения текста, форм, подписей или графики нужен PDF-редактор.

Сохраняет ли Marker исходную верстку?

Он старается сохранить смысловую структуру и порядок чтения, а JSON дополнительно содержит координаты polygon. Markdown и HTML не являются пиксельной копией исходной страницы.

Нужна ли видеокарта?

Нет. Marker 2 поддерживает CPU и MPS. На CPU по умолчанию выбирается fast, а для Surya используется llama.cpp. NVIDIA GPU даёт доступ к balanced через vLLM и лучше подходит для тяжёлой VLM-обработки.

Работает ли Marker без OCR?

Да. Disable OCR полностью исключает VLM и оставляет цифровой текстовый слой. Такой режим подходит только для документов, где критичное содержимое уже присутствует в корректном текстовом слое.

Можно ли распознавать документы не на английском?

Да. Surya VLM является мультиязычным, а при отсутствии необходимости в OCR Marker способен работать с любым языком цифрового текста. Язык интерфейса при этом остаётся отдельным вопросом: Marker Demo в текущем коде использует английские подписи.

Где хранятся результаты CLI?

Для каждого входного файла Marker создаёт каталог внутри output_dir с именем документа. Там сохраняется основной md, html или json-файл, сопутствующий файл метаданных с суффиксом _meta.json и извлечённые изображения, когда они присутствуют.

Чем JSON отличается от chunks?

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

Можно ли превратить результат обратно в исходный PDF?

Marker не создаёт обратимый проект исходной страницы. Markdown, HTML и JSON являются производными представлениями. Если нужно снова получить PDF после ручной работы с текстом, это уже отдельная операция; для офисного сценария можно ориентироваться на материал GeekHow о конвертации Google Docs в PDF.

Есть ли у Marker облачная версия?

Datalab предлагает отдельную managed platform, но marker-pdf как пакет работает локально и не требует подписки на облачный сервис. Подключение внешнего LLM тоже остаётся необязательным.

Подходит ли Marker для тысяч PDF?

Да, пакет имеет batch-команду, workers, skip_existing, max_files и sharding через num_chunks/chunk_idx. При этом встроенный marker_server не позиционируется как production API; крупный конвейер лучше строить вокруг CLI/Python API или отдельной инфраструктуры.

Вывод

marker-pdf оправдан там, где PDF нужно не просто «вытащить в текст», а превратить в структурированные блоки, пригодные для индексации, RAG, анализа и повторной машинной обработки. Для обычных цифровых PDF достаточно fast, а при сканах, формулах и сложном layout имеет смысл balanced или Force OCR. LLM-режим стоит включать точечно для тех элементов, которые базовый конвейер восстанавливает хуже, сохраняя вариант без LLM для сравнения.

Для разовой ручной конвертации Marker потребует больше подготовки, чем веб-сервис или офисный редактор. Для регулярной обработки коллекций его сильные стороны раскрываются через batch, Python API, JSON/chunks и специализированные converters. Основные компромиссы Marker 2 — более сложная инфраструктура inference backend, отдельные условия лицензирования весов и необходимость проверять сложные формы и таблицы по исходнику.

Если задача ограничена быстрым Markdown из разнообразных файлов, проще начать с MarkItDown. Если нужен широкий унифицированный document model и множество форматов экспорта, рациональнее сравнить Docling. Для тяжёлого VLM/OCR-парсинга с развитым WebUI и многоязычной обработкой прямым конкурентом становится MinerU. Marker занимает промежуточную позицию: он остаётся инженерным инструментом, сфокусированным на высококачественном разборе PDF и управляемом выборе между текстовым слоем, OCR и LLM-коррекцией.