Datalab's Marker 2 vs MinerU, Docling and LiteParse: 76.0 on olmOCR-bench at 5x MinerU's Throughput. Datalab has released Marker 2, a full rewrite of its open source document conversion pipeline. Marker converts PDF, image, PPTX, DOCX, XLSX, HTML, and EPUB files into markdown, JSON, HTML, or chunks. The Datalab team rebuilt it around three components shipped over the preceding months: Surya OCR 2, a 20M-param fast layout model, and a rebuilt pdftext that is 3x faster than the previous one. The main result comes from olmOCR-bench, a third-party benchmark from Allen AI. Marker 2's balanced mode scores 76.0% overall and 83.5% on born-digital PDFs. It sustains 2.9 pages per second on a single B200 GPU. That is over 5x the throughput of MinerU's pipeline backend, which scores 72.7% at 0.54 pages per second. Docling scores 50.3% at 2.1 pages per second on the same harness. What's new in Marker 2. Marker 2 exposes three conversion paths instead of one: * balanced - the Surya VLM handles layout, and the whole page is re-OCR'd whenever embedded text is bad. Highest quality, best on GPU. 76.0% olmOCR-bench. * fast - a lightweight rf-detr/onnx layout detector plus pdftext, with minimal, surgical VLM use. 66.6%, and far cheaper. * -disable_ocr - pure text-layer extraction, no VLM calls at all. Runs entirely on CPU. 43.6%, 23.7 pg/s. Mode is now device-aware by default: balanced on GPU, fast on CPU/MPS, overridable with -mode. Full CPU support is the second structural change. fast -disable_ocr needs no GPU and no inference server, and the 20M layout model still reads columns, tables and headers on CPU. The third change is architectural, and it is the one that produces the throughput numbers. Many thin CPU workers share a single Surya inference server. The parent process budgets VLM concurrency across them, so throughput scales with server capacity rather than per-process VRAM. Datalab reports that balanced mode sustains ~2.9 pg/s against a ~0.3 pg/s single-stream rate on the same hardware. Breaking changes are worth flagging before an upgrade. Python 3.10+ is now required. Packaging moved from Poetry to uv, with hatchling as the build backend, though pip install marker-pdf is unchanged. The structured-extraction converter and extractors were removed; Datalab points users to the hosted API or a -use_llm workflow instead. Comparison. The scoring benchmark is olmOCR-bench from Ai2: 1,403 PDFs with roughly 8,400 pass/fail unit tests covering math rendering, table structure, reading order, headers and footers, and old scans. The overall score is the macro-average across the 8 categories, computed with the official olmOCR-bench checker. Throughput is sustained concurrent pg/s on one B200 host, not single-stream latency. A note on provenance. olmOCR-bench is a third-party benchmark from Ai2, but every score and throughput figure below comes from Datalab's own runs. All of them are reproducible through the open harness in the Marker repository, which ships competitor runners for MinerU, Docling and LiteParse alongside Marker's own. These numbers also reflect one benchmark's document mix measured on a single hardware setup, so results on your own documents may differ. Teams evaluating these systems should run the harness against their own corpus, which is the only way to know how the four rank on the documents they actually process. Marker 2 vs MinerU. MinerU's pipeline backend is the closest architectural match. Both read the PDF text layer and OCR selectively. On overall score, Marker balanced leads 76.0 to 72.7. On born-digital documents the two are effectively tied: 83.5 against 83.3. The separation is throughput. Marker balanced sustains 2.9 pg/s against MinerU's 0.54 pg/s, a 5.4x gap at a higher score. Marker fast sustains 7.4 pg/s, roughly 13.7x MinerU's pipeline rate, but scores 6.1 points below MinerU to do it. MinerU also ships a VLM backend, which Datalab states scores higher than its pipeline backend. That backend is a full-page-VLM approach and is not in this table. AI teams evaluating MinerU should benchmark that path separately. Marker 2 vs Docling. Docling is the widest margin among the GPU pipelines. Marker balanced leads 76.0 to 50.3 overall and 83.5 to 64.0 on born-digital, while also running faster: 2.9 pg/s against 2.1 pg/s. Datalab notes Docling was run on its default pipeline, which uses the text layer for born-digital pages and OCR for image regions. Docling's counterweight is governance and format breadth, not accuracy. The codebase is MIT-licensed, it originated at IBM Research, and it is hosted as a project in the LF AI & Data Foundation. Its input list also extends past documents into audio and email formats. Marker 2 vs LiteParse. LiteParse, from the LlamaIndex team, is a Rust document parser. It does not compete on the same axis. On CPU it scores 22.4 overall and 20.4 with OCR off, against Marker's CPU-only 43.6. But LiteParse with OCR disabled reports 1721 pg/s - roughly 73x Marker's CPU mode, which is the tradeoff. Marker's fast -disable_ocr runs a 20M layout model on CPU and still recovers structure, which is why it more than doubles a plain text dump's score. LiteParse has no layout model and collapses on anything non-linear. Marker 2 vs the full-page VLM tier. The Datalab team emphasizes that Marker is designed as a pipeline rather than a VLM, clarifying that these are distinct tools. In this evaluation, their hosted Chandra 2 scores 85.8, while Gemini Flash 3.5 via API scores 76.4. Datalab's Chandra repository also positions Ai2's olmOCR 2 at 82.4 and dots.ocr 1.5 at 83.9 within a separate table. For scans, math-heavy pages, and achieving top accuracy, the VLM tier remains superior to all listed pipelines. Marker's balanced mode narrows the performance gap to just 0.4 points behind Gemini Flash 3.5 overall, and it even outperforms it on born-digital documents by a margin of 83.5 to 79.1 - without requiring a per-page API call. The mode you pick changes the failure profile, not just the score. Each row is one olmOCR-bench category, scored across all three modes. Math is the sharp edge: fast mode reads equations from the PDF text layer instead of VLM-OCRing them, so arXiv math falls from 83.9 to 23.4, and -disable_ocr scores 0.0 there by design. Outside the two math categories, old scans is the weakest split in every mode, topping out at 43.2. Licensing. This is where the four systems diverge most for commercial teams: * Marker: code is Apache 2.0. Model weights use a modified AI Pubs OpenRAIL-M license - free for research, personal use, and startups under $5M funding/revenue. Beyond that, commercial use of the weights requires a paid license. * MinerU: now under the MinerU Open Source License, based on Apache 2.0 with added conditions. A separate commercial license is required above 100M MAU or $20M monthly revenue, and online services built on it must disclose that fact. * Docling: MIT, with model licenses tracked separately in their original packages. * LiteParse: open source, from run-llama, with LlamaParse positioned as the paid cloud path for hard documents. Use case- comparison. Score alone does not pick the tool. Corpus type, hardware, licensing band and output format decide it. Try the interactive picker below to filter ten deployment scenarios by constraint and by tool, and see which parser fits your use case. Key takeaways. * Marker 2 balanced scores 76.0% on olmOCR-bench at 2.9 pg/s - over 5x MinerU's pipeline throughput. * It beats Docling on both axes at once: 76.0% against 50.3%, and 2.9 pg/s against 2.1 pg/s. * LiteParse trades structure for speed - 1721 pg/s with OCR off, but 20.4% against Marker's 43.6% on CPU. * Fast mode with -disable_ocr runs entirely on CPU, no inference server, at 23.7 pg/s. * Licensing splits the field: Docling is MIT, MinerU stays free to $20M monthly revenue, and Marker's weights need a paid license above $5M. * All benchmark and throughput numbers ship with a reproducible benchmarks/ harness. Interactive dynamic explainer. Links: GitHub repo | Release notes | Blog post | Announcement tweet Asif Razzaq is the CEO of Marktechpost Media Inc... As a visionary entrepreneur and engineer, Asif is committed to harnessing the potential of Artificial Intelligence for social good. His most recent endeavor is the launch of an Artificial Intelligence Media Platform, Marktechpost, which stands out for its in-depth coverage of machine learning and deep learning news that is both technically sound and easily understandable by a wide audience. The platform boasts of over 2 million monthly views, illustrating its popularity among audiences.

Marker 2: faster, CPU-ready, and more accurate. Marker 2 is a rewrite of its open-source PDF-to-markdown converter. It runs on CPU, picks a speed/accuracy mode automatically, and beats comparable pipeline OCR systems on both accuracy and throughput on olmOCR-bench. Marker grew to over 37,000 GitHub stars and wide usage across industries. It's popular because it turns messy PDFs into clean markdown, JSON, and HTML. But it was slower than Datalab liked, and had some accuracy issues on certain types of documents. So Datalab rewrote it. Marker 2 is faster, fully CPU-compatible, and more accurate. Against comparable pipeline OCR systems it wins on both axes at once: on olmOCR-bench, balanced mode scores 76.0% overall while running over 5x more pages/sec than MinerU's pipeline backend. pip install marker-pdf * GitHub * Hosted API - best-in-class accuracy, free $5 in credits What made this possible. Marker 2 didn't come from one change. It came from three pieces of infrastructure Datalab shipped over the last few months, then a rewrite that ties them together. * Surya OCR 2. Datalab trained and released a 650M-parameter OCR model that tops olmOCR-bench for its size class (83.3%, best under 3B params) and is extremely fast - 5.35 pages/sec on a single RTX 5090. It handles OCR, layout, reading order, and table recognition in one model. Marker calls it only where the PDF text layer falls short. * A 20M-parameter fast layout model. Datalab trained a lightweight rf-detr layout detector for Surya that runs quickly on CPU. It's what lets Marker read document structure - columns, tables, headers. * A rebuilt pdftext. Datalab rewrote Marker's text-extraction dependency to be 3x faster while keeping the same accuracy. It reads the embedded text layer in the PDF's true reading order. Datalab rewrote Marker to read the PDF text layer, and only call the VLM where you actually need it - garbled pages, scans, equations, low-confidence tables. That's what makes it both fast and accurate, and it's what lets a single mode scale from CPU-only to full-VLM. Modes: pick your speed/accuracy tradeoff. Marker 2 gives you three points on the speed/accuracy curve. The right one depends on your documents and your hardware. | Mode | What it does | Best on | olmOCR-bench | | balanced | Surya VLM for layout; re-OCRs a whole page whenever its embedded text is bad; OCRs inline math | GPU | 76.0% | | fast | Lightweight rf-detr/onnx layout + pdftext; minimal, surgical per-block VLM repair | CPU or GPU | 66.6% | | -disable_ocr | Pure text-layer extraction - no VLM at all | CPU | 43.6% | In both balanced and fast, tables are reconstructed from the PDF text layer on CPU, and only low-confidence reconstructions fall back to the VLM (balanced uses a stricter bar). -disable_ocr is the pure-CPU path: no inference server is started at all. New in Marker 2: the mode defaults by device. If you don't pass -mode, Marker picks balanced on a GPU and fast on CPU/MPS. Override it any time: marker_single paper.pdf # auto: balanced on GPU, fast on CPU marker_single paper.pdf -mode balanced # force highest quality marker_single paper.pdf -disable_ocr # pure CPU, no VLM Benchmarks. Datalab measure conversion quality with olmOCR-bench, AllenAI's third-party benchmark: 1,403 PDFs with unit tests covering math rendering, table structure, reading order, headers/footers, and old scans. Datalab report the macro-average across its 8 categories (matching how olmOCR-bench and Chandra report), scored with the official olmOCR-bench checker. Marker vs. comparable systems. Up (higher score) and right (faster) is better. The clean comparison is against other pipeline systems - tools that read the PDF text layer and OCR selectively - so MinerU's pipeline backend and docling. Marker balanced leads that group on score and throughput at once. | System | Overall | Digital-only | Throughput* | | Chandra 2 (hosted) | 85.8 | - | - | | Gemini Flash 3.5 (API) | 76.4 | 79.1 | - | | Marker - balanced (GPU) | 76.0 | 83.5 | 2.9 pg/s | | MinerU - pipeline (GPU) | 72.7 | 83.3 | 0.54 pg/s | | Marker - fast (GPU) | 66.6 | 71.6 | 7.4 pg/s | | docling (GPU) | 50.3 | 64.0 | 2.1 pg/s | | Marker - fast, no OCR (CPU) | 43.6 | 55.8 | 23.7 pg/s | | liteparse (CPU) | 22.4 | 27.3 | 8.9 pg/s | * Sustained concurrent pages/sec on one B200 - the deployment-relevant number, not single-stream latency. Chandra (hosted) and Gemini (API) have no local-hardware throughput. Digital-only is the macro-average over the 6 non-scanned categories. Marker balanced matches Gemini/MinerU quality while running over 5x more pages/sec than MinerU's pipeline (2.9 vs 0.54), and fast trades a little quality for a big speedup. This is the apples-to-apples pipeline comparison; MinerU also ships a full-page-VLM backend that scores higher, which is a different approach (more on that below). | Category | balanced | fast | no OCR | | arXiv math | 83.9 | 23.4 | 0.0 | | Tables | 73.4 | 69.0 | 46.1 | | Multi column | 76.6 | 76.0 | 67.0 | | Headers & footers | 95.9 | 93.2 | 92.8 | | Long tiny text | 71.3 | 68.3 | 43.2 | | Old scans math | 63.8 | 59.8 | 0.0 | | Old scans | 43.2 | 43.2 | 14.3 | | Baseline | 99.7 | 99.9 | 85.9 | | Overall | 76.0 | 66.6 | 43.6 | | Born-digital only | 83.5 | 71.6 | 55.8 | A couple of things worth noticing. Fast mode's math is low by design - it reads equations from the PDF text layer instead of VLM-OCRing them, so LaTeX-level math tests mostly miss. Use balanced for math-heavy documents. And -disable_ocr scores zero on math (equations have no text-layer LaTeX) - it's the pure text-layer path, meant for born-digital documents on CPU. Born-digital, on CPU. If you only have born-digital PDFs and no GPU, the honest comparison is against pure-CPU text extractors. Marker's fast -disable_ocr scores far higher than a plain text dump - while staying fast. Throughput comes from concurrency. Production throughput comes from concurrency, not per-page latency. Marker runs many thin conversion workers. The parent process budgets VLM concurrency across the workers, so throughput scales with server capacity rather than per-process VRAM. Sustained steady-state over the full 1,403-page olmOCR-bench set: | Mode | Throughput | Effective latency/page | | fast, no OCR | 23.7 pg/s | 42 ms | | fast | 7.4 pg/s | 134 ms | | balanced | 2.9 pg/s | 341 ms | fast, no OCR is pure CPU and needs no GPU at all. fast and balanced are GPU-assisted and still leave a single B200 with headroom (balanced saturates only ~30% of it), so throughput scales further with more or larger inference-server replicas. Using marker. Convert a single file: marker_single /path/to/file.pdf Convert a folder - many files at once, sharing one inference server: marker /path/to/folder -output_dir out From Python: from marker.converters.pdf import PdfConverter from marker.models import create_model_dict from marker.output import text_from_rendered converter = PdfConverter(artifact_dict=create_model_dict rendered = converter("FILEPATH") text, _, images = text_from_rendered(rendered) A few useful flags: * -mode balanced|fast - override the device default. * -disable_ocr - pure text-layer extraction, no VLM (CPU-only). * -use_llm - optionally add an LLM (Gemini, Claude, OpenAI-compatible, Vertex, Azure, OpenRouter, or Ollama) to improve tables, math, and forms. * -output_format markdown|json|html|chunks - the chunks format flattens each page's blocks for easy RAG. * -force_ocr - re-OCR everything, for PDFs with bad embedded text. For batch jobs, the defaults handle a single GPU machine out of the box: one vLLM server, a CPU-sized worker pool, concurrency budgeted to the GPU. Span multiple GPUs with VLLM_GPUS=0,1,2,3, or shard a file list across machines with -num_chunks / -chunk_idx. Run your own benchmarks. Everything above - both the olmOCR-bench scores and the throughput numbers, for Marker and the competitors - is reproducible with the harness in benchmarks/. Datalab don't vendor olmOCR-bench; you clone it, run benchmarks/inference.py to convert the bench PDFs at real worker concurrency, score with olmOCR-bench's own checker, and summarize. Datalab'd encourage you to do exactly that. Don't trust vendor benchmarks - including ours. Run Marker on your own documents and see how it does. Marker is a pipeline: it reads the text layer and OCRs selectively. That's the right tool for most documents, and it's fast. But if your documents need full-page VLM OCR - heavy math, scans, the highest possible accuracy - that's a different tool: * Chandra - its document VLM (85.8 on this bench), available in the hosted Datalab API with automatic correction and zero data retention by default. * Surya - the OCR VLM Marker uses under the hood, if you want to run full-page OCR yourself. The Datalab API runs higher-accuracy models without any infrastructure to manage - free $5 in credits to start.

Tell Datalab how you want your documents parsed. Custom Processors turn plain-language instructions and a few examples into a processor that parses your documents exactly the way you need. Datalab is excited to announce that Custom Processors are now available. Every document parsing tool eventually runs into the same wall: no two teams want their documents parsed the same way. One team needs bullet hierarchy preserved across a 40-page list. Another needs font and color carried into the HTML. A third needs the line items to actually add up to the total. Its state-of-the-art models handle the common case well, but that's not always representative of every unique situation. For a while Datalab tried to close that gap with flags. Skip headers and footers. Custom prompts for image descriptions. Merge these tables, split those. Every new customer edge case became another toggle, and the surface kept growing. Custom Processors are the answer. Instead of hunting for the right combination of flags, you tell Datalab how you want your documents parsed in plain instructions, and give Datalab a few representative examples. Datalab build a processor that does exactly that, making accurate, targeted modifications using custom models to its base Convert output. It's the experience of training your own model for your data, without the months of labeling. How it works. You have two paths: * Start from a template. Datalab has published processors for the most common needs - schema extraction, cleaned HTML, table normalization, and more. Pick one and run it today. * Bring your own documents. Send Datalab a sample plus a description of your desired output, and Datalab'll design a processor tailored to your data, evaluate its outputs with you, and refine it as Datalab learn your workflow. When does a custom processor make sense? A good litmus test is to ask yourself: How much customization or transformation is required on my data? * Objective, predictable output transformations: if the change you need follows a clear, deterministic pattern, its recommended solution is a static transformation script. * Subjective output tuning: if you need the output shaped to a judgment call (e.g., a house style, a style guide, a consistent treatment that doesn't have one objectively "correct" answer), then a custom processor is a strong fit, even when your input is perfectly predictable. As an example of the latter, one of its beta customers uses a custom processor to make sure image descriptions generated for construction documents follow a specific style guide. The input is consistent, but the desired output is subjective; doing it themselves would also involve running it through an LLM. Another factor to consider is how much modification you need. If you're scanning pages to pull a few numbers and a stray line break doesn't matter, a general parse makes sense. However, Datalab has come across many cases where accuracy is load-bearing. In areas like compliance, legal, healthcare, and financial reconciliation, even one misread line or transposition error has a real downstream cost, which is where a custom processor is most valuable. What teams are doing with it. Datalab ran a beta with a few customers, where Datalab looked for genuinely hard use cases to challenge the system. A few examples: * Long documents with complex, multi-page lists, that needed bullet hierarchy to stay consistent as those lists spilled across page breaks. * Color and font information that carried through into the HTML output. * Tables that needed to be merged and split to match their custom downstream schema. * Extracted values that needed to reconcile - line items that summed to the stated total. These represent real customer examples of specific, load-bearing details that make parsing more powerful in a real pipeline. Custom Processors let you specify them once instead of maintaining a pile of workarounds. Get started. Its free tier includes one custom processor creation per month. Its Team plan offers four custom processor creations per month (then $5 for any additional creations). Using a custom processor is billed at an additional $20 per 1000 pages. Browse the template gallery to self-serve a processor now, or reach out to [email protected] if you have a complex use case you'd like Datalab to build around. If you've ever hit a wall with edge cases, inconsistent formats, or custom output needs, this is for you.