Datalab lanzó Marker v2, una reescritura completa de su pipeline open source de conversión de documentos. Marker transforma archivos PDF, imágenes, PPTX, DOCX, XLSX, HTML y EPUB en markdown, JSON, HTML o fragmentos — formatos de salida que sirven como entrada directa para sistemas de generación aumentada por recuperación (RAG), preparación de datos para entrenamiento de LLM y pipelines empresariales de conocimiento, donde la fidelidad del parsing determina el rendimiento posterior del modelo. El equipo de Datalab reconstruyó la herramienta en torno a tres componentes lanzados en los últimos meses: Surya OCR 2, un modelo rápido de layout de 20M de parámetros y un motor pdftext reconstruido que es 3× más rápido que la versión anterior.

Los principales resultados de benchmark provienen de olmOCR-bench, un benchmark de terceros creado por Allen AI (Ai2). El modo balanced de Marker v2 alcanza 76.0% general y 83.5% en PDFs nacidos digitales, con un rendimiento sostenido de 2.9 páginas por segundo en una sola GPU B200. Ese throughput representa más de 5× la velocidad del backend de pipeline de MinerU, que obtiene 72.7% a 0.54 páginas por segundo. Docling obtiene 50.3% a 2.1 páginas por segundo en el mismo harness.

Novedades en Marker v2

Marker v2 introduce tres modos de conversión:

• Balanced — Surya VLM gestiona el layout, y se activa un nuevo OCR de página completa cada vez que la calidad del texto incrustado es baja. Es el modo de mayor calidad, optimizado para GPU. Alcanza 76.0% en olmOCR-bench.
• Fast — Un detector de layout ligero rf-detr/onnx combinado con pdftext, usando llamadas VLM mínimas y focalizadas. Obtiene 66.6% con un costo significativamente menor.
• –disable_ocr — Extracción pura de la capa de texto, sin llamadas VLM de ningún tipo. Se ejecuta íntegramente en CPU. Obtiene 43.6% a 23.7 pg/s.

La selección de modo ahora es consciente del dispositivo de forma predeterminada: balanced en GPU, fast en CPU/MPS, con anulación manual mediante –mode. El soporte completo para CPU constituye el segundo cambio estructural: el modo fast con –disable_ocr no requiere GPU ni servidor de inferencia, pero el modelo de layout de 20M de parámetros aún interpreta columnas, tablas y encabezados en CPU.

El tercer cambio arquitectónico impulsa las cifras de throughput. Múltiples workers ligeros de CPU comparten un único servidor de inferencia Surya, mientras el proceso principal administra la concurrencia VLM entre ellos. Como resultado, el throughput escala con la capacidad del servidor en lugar de quedar limitado por la VRAM de cada proceso. Datalab informa que el modo balanced sostiene aproximadamente 2.9 pg/s frente a una tasa de flujo único de ~0.3 pg/s en el mismo hardware.

Antes de actualizar, conviene tener en cuenta varios cambios incompatibles. Ahora se requiere Python 3.10+. El empaquetado pasó de Poetry a uv, con hatchling como backend de compilación, aunque pip install marker-pdf no cambia. Se eliminaron el convertidor de extracción estructurada y los extractores; Datalab dirige a los usuarios a la API alojada o a un flujo de trabajo –use_llm como alternativas.

Metodología del benchmark

El benchmark de puntuación es olmOCR-bench de Ai2, compuesto por 1,403 PDFs con aproximadamente 8,400 pruebas unitarias de aprobado/fallido que cubren renderizado matemático, estructura de tablas, orden de lectura, encabezados y pies de página, y escaneos antiguos. La puntuación general es el macro-promedio de las 8 categorías, calculado con el verificador oficial de olmOCR-bench. Las cifras de throughput representan páginas por segundo concurrentes sostenidas en un solo host B200, no latencia de flujo único.

Sobre la procedencia: aunque olmOCR-bench es un benchmark de terceros de Ai2, todas las puntuaciones y cifras de throughput provienen de ejecuciones de prueba propias de Datalab. Todos los resultados son reproducibles mediante el harness abierto del repositorio de Marker, que incluye runners de competidores para MinerU, Docling y LiteParse junto con los de Marker. Estas cifras reflejan la mezcla documental de un benchmark en una única configuración de hardware, por lo que los resultados en otros corpus pueden diferir. Los equipos que evalúen estas herramientas deberían ejecutar el harness contra sus propios conjuntos de documentos para obtener comparaciones significativas.

Marker v2 frente a MinerU

El backend de pipeline de MinerU es el equivalente arquitectónico más cercano, ya que ambas herramientas leen la capa de texto del PDF y aplican OCR de forma selectiva. En la puntuación general, Marker balanced supera a MinerU por 76.0 frente a 72.7. En documentos nacidos digitales, ambos están prácticamente empatados: 83.5 frente a 83.3.

La separación relevante está en el throughput. Marker balanced sostiene 2.9 pg/s frente a 0.54 pg/s de MinerU — una diferencia de 5.4× con una puntuación de precisión más alta. Marker fast sostiene 7.4 pg/s, aproximadamente 13.7× la tasa del pipeline de MinerU, aunque a cambio obtiene 6.1 puntos menos que MinerU.

MinerU también ofrece un backend VLM, que según Datalab obtiene una puntuación más alta que su backend de pipeline. Ese backend usa un enfoque VLM de página completa y no está incluido en esta tabla comparativa. Los equipos que evalúen MinerU deberían medir esa opción por separado.

Marker v2 frente a Docling

Docling muestra el margen de rendimiento más amplio entre los pipelines GPU. Marker balanced lidera por 76.0 frente a 50.3 en general y por 83.5 frente a 64.0 en documentos nacidos digitales, además de ejecutarse más rápido: 2.9 pg/s frente a 2.1 pg/s. Datalab señala que Docling fue evaluado con su pipeline predeterminado, que aprovecha la capa de texto para páginas nacidas digitales y OCR para regiones de imagen.

Las fortalezas de Docling están en la gobernanza y la amplitud de formatos, más que en la precisión bruta. El código tiene licencia MIT, se originó en IBM Research y está alojado como proyecto dentro de la LF AI & Data Foundation. Sus formatos de entrada compatibles van más allá de documentos e incluyen audio y correo electrónico.

Marker v2 frente a LiteParse

LiteParse, desarrollado por el equipo de LlamaIndex, es un parser de documentos basado en Rust que opera en un eje fundamentalmente distinto. En CPU obtiene 22.4 en general y 20.4 con OCR desactivado, frente al 43.6 de Marker en modo solo CPU. Sin embargo, LiteParse con OCR desactivado reporta 1721 pg/s — aproximadamente 73× el throughput del modo CPU de Marker, lo que representa una compensación clara entre velocidad y estructura.

El modo fast de Marker con –disable_ocr ejecuta un modelo de layout de 20M de parámetros en CPU y aun así recupera estructura documental, lo que explica por qué más que duplica la puntuación de un volcado de texto plano. LiteParse carece de un modelo de layout y tiene dificultades con diseños de documentos no lineales.

Marker v2 frente al nivel de VLM de página completa

El equipo de Datalab enfatiza que Marker está diseñado como un pipeline y no como un VLM, señalando que son categorías distintas de herramientas. La diferencia tiene peso práctico: los VLM de página completa procesan cada imagen de documento de extremo a extremo mediante un modelo grande, lo que logra mayor precisión pero implica costos de cómputo o API por página que se acumulan a escala. Pipelines como Marker descomponen la tarea en etapas especializadas más económicas, intercambiando precisión máxima por throughput y control de costos. En esta evaluación, Chandra 2 alojado por Datalab obtiene 85.8, mientras que Gemini Flash 3.5 vía API obtiene 76.4. El repositorio Chandra de Datalab también ubica a olmOCR 2 de Ai2 en 82.4 y a dots.ocr 1.5 en 83.9 en una tabla separada. Para escaneos, páginas con mucha matemática y máxima precisión, el nivel VLM sigue siendo superior a todos los pipelines listados.

En particular, el modo balanced de Marker reduce la brecha a solo 0.4 puntos por debajo de Gemini Flash 3.5 en general y lo supera en documentos nacidos digitales por un margen de 83.5 frente a 79.1 — sin requerir una llamada API por página.

Comportamiento por categoría

El modo elegido afecta el perfil de fallas, no solo la puntuación general. El renderizado matemático es el diferenciador más marcado: el modo fast lee ecuaciones desde la capa de texto del PDF en lugar de aplicar VLM-OCR, lo que hace que las puntuaciones de matemática en arXiv caigan de 83.9 a 23.4, y –disable_ocr obtiene 0.0 en esta categoría por diseño. Fuera de las dos categorías de matemática, los escaneos antiguos son el segmento más débil en todos los modos, con un máximo de 43.2.

Licenciamiento

Los términos de licencia divergen de forma significativa entre los cuatro sistemas, lo que tiene implicaciones directas para equipos comerciales, especialmente porque el parsing de documentos suele alimentar flujos regulados donde la procedencia y el cumplimiento de licencias son requisitos auditables:

• Marker: El código es Apache 2.0. Los pesos del modelo usan una licencia AI Pubs OpenRAIL-M modificada — gratuita para investigación, uso personal y startups con menos de $5M en financiamiento o ingresos. Por encima de ese umbral, el uso comercial de los pesos requiere una licencia paga.
• MinerU: Ahora se rige por la MinerU Open Source License, basada en Apache 2.0 con condiciones adicionales. Se requiere una licencia comercial separada por encima de 100M MAU o $20M de ingresos mensuales, y los servicios en línea construidos sobre ella deben revelar ese hecho.
• Docling: Licencia MIT, con licencias de modelos rastreadas por separado en sus paquetes originales.
• LiteParse: Open source, de run-llama, con LlamaParse posicionado como la opción cloud paga para procesar documentos difíciles.

Consideraciones de caso de uso

Las puntuaciones de benchmark por sí solas no determinan la herramienta adecuada. El tipo de corpus, el hardware disponible, el nivel de licencia y el formato de salida requerido son factores de decisión. Los equipos que procesan PDFs nacidos digitales a escala pueden encontrar diferencias mínimas de precisión entre los principales pipelines, mientras que quienes manejan documentos escaneados, papers académicos con matemática densa o corpus de formatos mixtos observarán mayor variación. Los equipos deberían evaluar cada parser contra sus propios conjuntos de documentos y restricciones operativas.

Todas las cifras de benchmark y throughput están acompañadas por un harness reproducible benchmarks/ en el repositorio de Marker.

Referencias clave

• Lanzamiento de Marker v2 en GitHub
• Publicación del blog de Datalab sobre Marker v2
• Anuncio en X
• Repositorio de olmOCR-bench (Ai2)

Fuente: MarkTechPost