Post cover image

July 17, 2026

Docling vs Marker vs MinerU: The Ultimate Open-Source PDF Parser Benchmark (2026) — Which Is Best…

The Real Open-Source PDF-to-Markdown Benchmark for 2026 — and Which One Belongs in Your RAG Pipeline

By Aditya Mangal

23 min read

By Aditya Mangal — Senior AI Engineer. I build OCR and Document AI pipelines for insurance and enterprise document processing, and I benchmark tools instead of trusting README charts.

None

TL;DR for the impatient engineer

· Docling (IBM) — the broadest and most permissive. MIT license, ingests everything from PDF to PPTX to email to audio, runs on pure CPU, and emits a clean structured DoclingDocument built for RAG. Absent from the public accuracy leaderboards, so you benchmark it yourself.

· Marker (Datalab) — the fastest at scale. Built on the Surya model suite, up to ~120 pages/sec on an H100 in batch, with an optional LLM-refinement pass. The catch is the license: GPL-3.0 code + a RAIL-M weight license that restricts commercial use above a revenue threshold.

· MinerU (OpenDataLab) — the accuracy leader. Its MinerU2.5 vision-language model (just 1.2B params) posts the top OmniDocBench numbers and is the strongest on tables, formulas, and CJK — but the accurate path needs a GPU.

· There is no single leaderboard that cleanly ranks all three. So this is not a "winner" article. It's a "which niche is yours" article, and the sneaky deciding factor is licensing, not accuracy.

· Verdict and decision tree at the end. If you read one section, read Licensing — the hidden decider and Who should use which.

Introduction

Every RAG system has a dirty secret, and it's not the vector database. It's the first stage: turning a pile of messy PDFs into clean, structured text a language model can actually reason over. Get that stage wrong and everything downstream — chunking, embedding, retrieval, generation — inherits the damage. A table that gets flattened into a word-salad, a two-column paper read straight across, a formula rendered as gibberish: none of that gets fixed by a better embedding model. Garbage in, garbage retrieved.

For years the honest answer to "how do I parse these documents" was a grim one: stitch together Tesseract, a layout heuristic, a table library, and a weekend of regex. In 2026 that has changed. Three open-source projects now do the whole job — PDF in, structured Markdown or JSON out — and they are good enough that the interesting question is no longer whether to use them but which one, and why.

Those three are Docling from IBM Research, Marker from Datalab, and MinerU from OpenDataLab (Shanghai AI Lab). All three are open source. All three convert documents to Markdown and JSON. All three have five-figure GitHub star counts. And yet they are built on completely different philosophies, licensed under completely different terms, and optimized for completely different constraints.

I build document pipelines for insurance and enterprise processing, where a mis-parsed table is not a cosmetic bug — it's a mispriced policy. So I don't pick a parser because it trended on Hacker News. I look at the architecture, the real benchmark numbers, the hardware bill, and — the part everyone forgets until legal calls — the license.

This article is that comparison. Here's the map:

· The three contenders — the philosophy behind each.

· Architecture — the pipelines and the actual models inside each tool.

· The benchmark reality — what the numbers say, and the honest caveats around them.

· Licensing — the hidden decider that overrides accuracy for most companies.

· Speed and hardware — CPU vs GPU, and what it costs.

· Decision tree and verdict — who should use which.

Engineering Note. All three tools move fast. As of mid-2026: Docling is at v2.111, Marker at v1.10.2, MinerU at v3.4.3, and MinerU's accuracy model is MinerU2.5. Version matters enormously for benchmark numbers — I flag it every time it does.

The Three Contenders

Before any numbers, understand what each project is trying to be. That intent explains every trade-off downstream.

Docling — the universal, permissive ingestion layer

Docling comes out of IBM Research Zurich and was donated to the Linux Foundation in early 2026. Its bet is that the hard part of document AI is not just OCR accuracy — it's coverage, structure, and freedom to use it. So Docling ingests almost anything (PDF, DOCX, PPTX, XLSX, HTML, EPUB, images, even email and audio), runs happily on a CPU, ships under a fully permissive MIT license, and — crucially — emits a rich, lossless structured representation called DoclingDocument that was designed from day one for RAG ingestion, not just for a human to read.

Docling's pitch to a platform team: one library, every format, no GPU required, no license lawyer required.

Marker — the fast, batteries-included converter

Marker comes from Datalab and Vik Paruchuri, built on top of Datalab's own Surya model suite. Its bet is speed and Markdown quality at scale. Marker is the tool you reach for when you have a hundred thousand PDFs and an H100, and you want clean Markdown out the other end as fast as physically possible — with an optional LLM pass to clean up the hard 5% (spanning tables, inline math, form fields).

Marker's pitch: the fastest good-enough PDF-to-Markdown pipeline, with an escape hatch to an LLM when you need more.

MinerU — the accuracy specialist

MinerU comes from OpenDataLab at Shanghai AI Lab, and it has the most GitHub traction of the three. Its bet is accuracy, especially on the hard stuff — tables, formulas, and Chinese/CJK documents. MinerU ships two backends: a classical pipeline that runs on CPU, and MinerU2.5, a compact 1.2-billion-parameter vision-language model that posts the top scores on the OmniDocBench leaderboard while being a fraction of the size of the models it beats.

MinerU's pitch: state-of-the-art parsing accuracy from a tiny model — if you can give it a GPU.

Engineering Note. Notice that none of these three is "the OCR model." They are document conversion systems — orchestrations of layout detection, table structure recognition, formula recognition, OCR, and reading-order logic. The quality of the whole pipeline matters more than any single model in it. That's exactly why they're worth comparing as systems.

Architecture: What's Actually Inside

This is where the three diverge hardest. Let's open each one up.

Docling

Docling runs a classic, inspectable multi-stage pipeline, with an optional single-model VLM path bolted alongside it.

None

The two things to remember about Docling: first, OCR is optional and pluggable — for a born-digital PDF it never runs OCR at all, it reads the text layer, which is both faster and more accurate. Second, the output is a DoclingDocument, a structured object that preserves the document's hierarchy losslessly, which is why Docling slots so cleanly into RAG frameworks. Table structure is handled by IBM's own TableFormer, which is genuinely strong on financial tables.

Docling also ships a VLM path — Granite-Docling-258M (Apache-2.0, released January 2026, successor to the experimental SmolDocling preview) — for when you want a single small model to emit structured "DocTags" markup instead of running the full pipeline.

Marker

Marker is best understood as an orchestrator over the Surya model suite. Surya provides the individual models; Marker wires them into a document pipeline and adds an optional LLM refinement stage.

None

The key architectural fact: Marker's quality is Surya's quality. Surya OCR 2 (2026) consolidated much of the recognition into a single ~650M-parameter vision-language model that emits layout JSON or full-page HTML by prompt. And the — use_llm flag is Marker's secret weapon: for the genuinely hard cases — a table that spans three pages, a dense equation, a form with checkboxes — it can call out to an external LLM to clean up the result, trading latency and API cost for accuracy.

MinerU

MinerU offers two selectable backends and a hybrid that combines them — this flexibility is the whole point.

None

MinerU2.5 is the interesting one. It's a decoupled, coarse-to-fine VLM: Stage 1 does layout analysis on a cheap downsampled thumbnail, Stage 2 does content recognition on native-resolution crops of just the regions that matter. That two-stage trick is how a 1.2B model beats systems many times its size — it never wastes compute reading the whole page at full resolution. The pipeline backend, meanwhile, gives you a pure-CPU option for when you don't have a GPU and can accept lower accuracy.

Engineering Note. The architectural through-line: Docling and MinerU-pipeline are inspectable multi-stage systems you can run on a CPU; MinerU2.5 and Marker's Surya path lean on VLMs and want a GPU for full speed and accuracy. That single distinction — classical pipeline vs VLM — drives most of the cost and hardware trade-offs below.

The Benchmark Reality

Here is the honest state of benchmarking these three, and you need to hear it before you look at a single number: there is no public leaderboard that cleanly ranks all three of them on the same suite. MinerU is on every board. Marker appears on some. Docling is essentially absent from the standardized public leaderboards — its published story is timing benchmarks from its own paper plus third-party blog tests. Anyone who shows you a tidy "Docling 87 vs Marker 84 vs MinerU 91" table is stitching together numbers from different suites, different versions, and different corpora. So I won't.

What I can give you is each tool's real, cited standing on the boards it actually appears on — with the caveats loud.

OmniDocBench (the document-parsing composite: text edit distance, table TEDS, formula, reading order).

None None

MinerU2.5 per-category (v1.5, from its paper): text edit 0.047, formula CDM 88.46, table TEDS 88.22, TEDS-S 92.38, reading-order edit 0.044 — leading its cohort on every axis.

Engineering Note — read this before quoting the 95.69. OmniDocBench v1.5 and v1.6 are different suites and their scores are not directly comparable. OpenDataLab itself explains the jump from 90.67 to 95.69 as coming "not from scaling params but through data engineering" and a bench-version change. Treat the low-90s as MinerU's honest, cross-consistent standing and the mid-90s as a newer-bench, vendor-reported figure. And every number in this table is self-reported — the point of the harness later is that you verify on your own docs.

olmOCR-Bench (AllenAI — pass/fail unit tests over 7,000 checks).

None None

Marker's own weak spot shows up here too: on old, degraded scans it scores just 51.9 — historical/damaged documents are where Marker struggles most, even as it excels on clean multi-column and long-tiny-text pages.

Engineering Note. Marker's two olmOCR-Bench numbers (76.1 vs 83.2) are different versions on different bench revisions — not a contradiction, just non-comparable. This is the recurring theme of open-source OCR benchmarking: the tools move faster than the leaderboards, so any single number is a snapshot, not a verdict.

Speed (from Docling's own paper, NVIDIA L4 GPU, older tool versions — directional).

None None

…but that per-page number misses Marker's real strength: batch throughput. Marker's README projects up to ~122 pages/sec on an H100 in batch mode (~0.18 s/page effective), at a heuristic quality score in the mid-90s. MinerU2.5's VLM backend runs at ~2.1 pages/sec on an A100–80G (up to ~4.5 pages/sec on an H200), and reports being multiples faster than comparable VLM parsers like MonkeyOCR-Pro and dots.ocr. The honest summary: for raw high-volume batch, Marker on a big GPU is hard to beat; for accuracy-per-dollar, MinerU2.5; for CPU-only or mixed-format ingestion, Docling or MinerU-pipeline.

The honest takeaway from all of this: MinerU has the strongest published accuracy, Marker has the strongest batch throughput, and Docling has the strongest coverage and licensing — but they've never been cleanly measured head-to-head on the same corpus. So the benchmark that decides it is the one you run on your own documents. The harness is at the end.

How Each Handles the Hard Cases

Averages hide everything that matters. A parser that is 90% accurate overall can still be useless for your corpus if your corpus is 80% tables and the tool's table handling is where that missing 10% lives. So here is how the three behave on the five document features that actually break pipelines.

None

Complex tables. This is MinerU's home turf. Its table TEDS scores lead the OmniDocBench cohort, and it handles merged cells, spanning rows, and nested headers more reliably than the other two out of the box. Docling is a close and sometimes-better second specifically on financial tables, thanks to TableFormer's ACCURATE mode — IBM built that model on financial data and it shows. Marker's base table handling is the weakest of the three, but this is exactly what — use_llm is for: the refinement pass merges spanning tables and repairs structure, closing much of the gap at the cost of an LLM call per document.

Math and formulas. MinerU again leads, emitting clean LaTeX for dense inline and display math — its formula CDM score is the best of the three, and it's the safe pick for scientific and academic PDFs. Docling handles formulas but degrades on genuinely complex expressions (nested integrals, large matrices), where third-party tests put it well below MinerU. Marker's formula quality, like its tables, jumps meaningfully with the LLM pass and is mediocre without it.

Scanned and degraded documents. Here the ranking scrambles. Marker's biggest published weakness is old scans — it scores in the low 50s on olmOCR-Bench's old-scans category, meaning historical, faxed, or heavily-degraded documents are its worst case. MinerU and Docling both fare better on scans; Docling's pluggable OCR backends (you can swap Tesseract for RapidOCR or EasyOCR) give you a knob to turn when the default fails. If your corpus is dominated by bad scans, benchmark this category specifically — it's where the tools diverge most.

Multi-column and reading order. All three have dedicated reading-order logic, and all three are competent on standard two-column academic layouts. Marker is actually strong here (it scores well on olmOCR-Bench's multi-column and long-tiny-text categories). MinerU's explicit layout stage and Docling's RT-DETR layout model both handle reading order well. The failure mode to watch across all three is the exotic layout — a magazine spread, a newspaper, a form with a non-obvious flow — where you should eyeball the output rather than trust it.

Chinese, CJK, and multilingual. MinerU is the clear leader for Chinese and CJK — it was built by a Chinese lab, supports 109 languages, and its accuracy on Chinese documents is a genuine differentiator. Marker covers 90+ languages via Surya and is solid on major scripts. Docling's coverage depends on which OCR backend you plug in. If your documents are heavily Chinese, Japanese, Korean, or Arabic, MinerU is the default and the gap is real, not marginal.

Engineering Note. The practical upshot: build your evaluation corpus out of your hardest document types, not a random sample. If 20% of your documents are scanned financial tables in Chinese, that 20% should be 60% of your test set, because that's where the tools separate and where a wrong choice costs you. A blended average across easy and hard documents will tell you they're all "about 90%" and teach you nothing.

Licensing — the Hidden Decider

Here is the section that will change more real-world decisions than any accuracy number, and it's the one nobody puts in their comparison table.

None None

Read that Marker row twice. Marker's model weights carry a RAIL-M license with a revenue threshold. If your company is past roughly $2M in funding or revenue and you ship Marker in a commercial product, you are outside the free tier — and the code itself is GPL-3.0, which has its own copyleft implications for anything you link against it. For a solo developer, a researcher, or an early startup, none of this matters and Marker is a gift. For a mid-size or enterprise company, this single fact can eliminate Marker from the shortlist before accuracy ever enters the conversation.

Docling, by contrast, is MIT top to bottom — the most permissive license there is — which is a big part of why IBM and Red Hat push it for enterprise RAG. MinerU sits in between: broadly permissive, but with extra conditions worth a legal skim.

Best Practice. Decide licensing before accuracy, not after. It is heartbreaking to benchmark three tools for two weeks, pick the most accurate one, and then have legal veto it in the code review. Filter on license first; benchmark only what survives.

Speed, Hardware, and Cost

The classical-pipeline vs VLM split from the architecture section is really a hardware-and-cost split.

None

The engineering reading:

· No GPU? Docling or MinerU's pipeline backend. Docling wins on format coverage and license; MinerU-pipeline wins on table/formula accuracy.

· One consumer GPU, need best accuracy? MinerU2.5 — a 1.2B model that fits comfortably and beats far larger systems.

· A fleet of big GPUs and millions of pages? Marker in batch, license permitting.

Engineering Note. Don't over-index on per-page latency in isolation. A tool that is 0.86 s/page single-threaded but does 122 pages/sec batched (Marker) will crush a 0.21 s/page tool that doesn't batch as well, once you're processing at real volume. Measure your throughput at your batch size and concurrency — a single-document timing is marketing, not capacity planning.

Running Each One

All three are a pip install and a few lines. Here's the shape of each.

# ---- Docling: broadest coverage, MIT, CPU-friendly ----
# pip install docling
from docling.document_converter import DocumentConverter

conv = DocumentConverter()
result = conv.convert("report.pdf")          # PDF, DOCX, PPTX, HTML, image, ...
print(result.document.export_to_markdown())  # or export_to_dict() for lossless JSON

# ---- Marker: fast Markdown, optional LLM refinement ----
# pip install marker-pdf
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("report.pdf")           # add use_llm=True config for the refinement pass
markdown, _, images = text_from_rendered(rendered)

# ---- MinerU: pick your backend ----
# pip install "mineru[core]"
mineru -p report.pdf -o ./out -b pipeline    # CPU-capable, fast
mineru -p report.pdf -o ./out -b vlm-vllm     # MinerU2.5 VLM, GPU, highest accuracy

Tip. For a RAG pipeline, don't just export Markdown and chunk it blindly. Docling's export_to_dict() and MinerU's JSON preserve the document hierarchy (headings, tables, reading order) — chunk on that structure (by section, keeping tables intact) instead of on a fixed token window. The parser you pick matters far less than whether you throw away its structure immediately afterward.

Feeding a RAG Pipeline: The Part That Actually Matters

Most RAG-quality problems that get blamed on the retriever or the embedding model are actually parsing problems in disguise. Here is the failure that happens in nine out of ten first-draft pipelines: you export the document to Markdown, run it through a fixed 512-token splitter, and embed the chunks. That splitter has no idea it just cut a table in half, orphaned a heading from its section, or spliced the last paragraph of one topic onto the first of the next. Your retriever then returns half a table and the model hallucinates the other half.

The fix is to chunk on structure, not on token count — and this is precisely why the structured output of these parsers matters more than the Markdown. Docling's DoclingDocument and MinerU's JSON both preserve the document's hierarchy: which text is a heading, which block is a table, what the reading order is. Chunk on that.

None 
# Structure-aware chunking with Docling — keep tables whole, split on sections
from docling.document_converter import DocumentConverter
from docling.chunking import HybridChunker

doc = DocumentConverter().convert("policy.pdf").document
chunker = HybridChunker(max_tokens=512)          # respects tables, headings, reading order

chunks = []
for ch in chunker.chunk(doc):
    # each chunk carries its section path + never splits a table mid-way
    chunks.append({"text": ch.text, "meta": ch.meta.export_json_dict()})

Two rules that will do more for RAG quality than any embedding-model upgrade:

  1. Never split a table. A table is an atomic unit of meaning. Keep it whole in one chunk (converting it to Markdown or a linearized "row: col=value" form), and prepend the section heading so the retriever has context.

  2. Carry the hierarchy into metadata. Store each chunk's heading path ("Section 3 > Coverage > Exclusions") as metadata. It improves retrieval and lets you cite sources precisely — which, in insurance and legal, is not optional.

Best Practice. Evaluate parsing and retrieval together, not separately. A parser that scores two TEDS points lower but produces cleaner section boundaries can beat a "more accurate" one on end-to-end RAG answer quality. The number that matters is not the parser's benchmark — it's whether your system answers the question correctly.

The Reproducible Harness

Talk is cheap; run all three on your own documents. Here is a harness that converts a folder of PDFs with each tool, times them, and writes the outputs side by side so you can score them against your ground truth.

"""
parse_bench.py — Docling vs Marker vs MinerU on YOUR documents.
Runs each tool over a folder, records wall-clock time, saves Markdown for scoring.
"""
import time, pathlib, subprocess, json

CORPUS = pathlib.Path("corpus")        # your PDFs
OUT = pathlib.Path("out"); OUT.mkdir(exist_ok=True)

# ---- Docling ----
from docling.document_converter import DocumentConverter
_docling = DocumentConverter()
def run_docling(pdf):
    t0 = time.perf_counter()
    md = _docling.convert(str(pdf)).document.export_to_markdown()
    return md, time.perf_counter() - t0

# ---- Marker ----
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered
_marker = PdfConverter(artifact_dict=create_model_dict())
def run_marker(pdf):
    t0 = time.perf_counter()
    md, _, _ = text_from_rendered(_marker(str(pdf)))
    return md, time.perf_counter() - t0

# ---- MinerU (CLI) ----
def run_mineru(pdf, backend="pipeline"):
    t0 = time.perf_counter()
    subprocess.run(["mineru", "-p", str(pdf), "-o", str(OUT / "mineru"),
                    "-b", backend], check=True)
    md = (OUT / "mineru" / pdf.stem / "auto" / f"{pdf.stem}.md").read_text(encoding="utf-8")
    return md, time.perf_counter() - t0

def main():
    rows = []
    for pdf in sorted(CORPUS.glob("*.pdf")):
        for name, fn in [("docling", run_docling), ("marker", run_marker), ("mineru", run_mineru)]:
            try:
                md, secs = fn(pdf)
                (OUT / f"{pdf.stem}__{name}.md").write_text(md, encoding="utf-8")
                rows.append({"doc": pdf.name, "tool": name, "sec": round(secs, 2), "chars": len(md)})
                print(f"{pdf.name:30s} {name:8s} {secs:6.2f}s")
            except Exception as e:
                print(f"{pdf.name:30s} {name:8s} FAILED: {e}")
    pathlib.Path("bench.json").write_text(json.dumps(rows, indent=2))

if __name__ == "__main__":
    main()

Then score the out/*.md files against your hand-labeled ground truth with whatever metric fits your documents — normalized edit distance for text, TEDS for tables, field-F1 for structured extraction. The outputs sitting side by side make the differences obvious fast; you will usually see within ten documents which tool fits your corpus.

Tip. Version-pin all three (docling==, marker-pdf==, mineru==) and commit bench.json with the git SHA. These tools change monthly; you want a reproducible artifact, not a memory of "MinerU was better that one time."

Production Deployment Notes

Getting a good result on one PDF is a demo. Running at volume is engineering.

· Isolate the GPU tools behind a queue. MinerU2.5's VLM backend and Marker both want a warm GPU worker pool with a job queue in front, not a per-request cold start. Load the models once per worker; never per document.

· Set hard timeouts and a fallback chain. A single pathological PDF (a 900-page scan, a corrupt file) can wedge a worker. Cap per-document time, and on failure fall back to a cheaper path — e.g. Docling's pipeline or a raw text-layer extraction — rather than dropping the document silently.

· Watch memory, not just latency. Marker's ~3–5 GB per worker and MinerU2.5's ≥8 GB VRAM set your concurrency ceiling. Size your worker count to VRAM, and monitor peak memory under real batch sizes, because that's what OOM-kills a worker at 2 a.m.

· Cache by content hash. Documents get reprocessed constantly in real systems (re-ingests, retries, pipeline reruns). Hash the file bytes and cache the parsed result; parsing is expensive enough that this pays for itself immediately.

· Keep a provider-agnostic interface. Wrap all three behind one parse(path) -> StructuredDoc function so you can A/B them, fall back between them, and swap the "best" one when the leaderboard shifts next month — which it will.

Engineering Note. The single highest-leverage production decision is the fallback chain. In insurance processing I run the fast, cheap parser by default and escalate only the low-confidence or failed documents to the heavy VLM path. Most documents are easy; spend your GPU budget on the hard ones, not on the 80% that a CPU pipeline handles fine.

Strengths and Weaknesses

Docling. Strengths: the broadest input coverage of any of the three (Office, HTML, EPUB, email, even audio); fully permissive MIT license; strong pure-CPU story; a lossless DoclingDocument model purpose-built for RAG; IBM / Red Hat / Linux Foundation backing and an OpenShift operator; TableFormer is genuinely strong on financial tables. Weaknesses: weaker than MinerU on complex formulas and dense math; absent from the standardized public leaderboards, so its accuracy is harder to cite objectively; the Granite-Docling VLM path is still maturing.

Marker. Strengths: fastest at batch scale on big GPUs; clean general Markdown; strong on headers, multi-column, and long/tiny text; the — use_llm escape hatch meaningfully lifts tables, math, and forms; 90+ languages via Surya. Weaknesses: the license (GPL-3.0 code + RAIL-M weights with a revenue threshold) is a real commercial blocker; weak on old/degraded scans (~52 on olmOCR-Bench old-scans); not in the OmniDocBench top tier.

MinerU. Strengths: the highest published accuracy (MinerU2.5 tops OmniDocBench for its cohort); best on tables, formulas, and CJK/multilingual; a remarkably efficient 1.2B VLM that beats much larger models; the two-backend design lets you trade accuracy for a CPU-only run; the most GitHub traction of the three. Weaknesses: the accurate VLM path requires a GPU (≥8 GB); a ~20 GB footprint and heavier setup; the license carries extra conditions beyond a clean Apache-2.0.

Engineering Note. See the pattern: each tool's biggest strength is another's biggest weakness. Docling's coverage-and-license vs MinerU's accuracy vs Marker's speed. There is no free lunch — only which constraint you're most willing to relax.

The Real Cost (Beyond the GPU Bill)

Since all three are open source, the model itself is free — which fools teams into thinking the systems are equally cheap. They aren't. The real cost has three layers, and only the first one shows up on a cloud invoice.

None

Compute cost. For the CPU paths (Docling, MinerU-pipeline), the marginal cost per page is essentially electricity — negligible. For the GPU paths, do the arithmetic: a rented A100 at roughly $1.50/hour running MinerU2.5 at ~2 pages/sec processes ~7,200 pages/hour, putting you around $0.0002 per page at good utilization. Marker on an H100 in batch at ~120 pages/sec is even cheaper per page — if you keep the GPU saturated. Below steady high volume, the GPU sits idle and the per-useful-page cost balloons; that's the same utilization trap that governs every self-hosted model.

License cost. This is the layer nobody budgets for. Marker's RAIL-M weights above the revenue threshold mean a commercial license negotiation — an unknown dollar figure and a legal review that can take longer than the entire integration. Docling's MIT license makes that cost exactly zero, forever. When you price the three, price the lawyer-hours too; for an enterprise, Docling's permissiveness can be worth more than any per-page compute saving.

Engineering and maintenance cost. The heaviest tool to operate is the one with the biggest footprint and the most moving parts. MinerU's ~20 GB install and dual backends buy you accuracy but cost you setup and upkeep. Docling's single CPU-friendly library is the cheapest to operate. Marker sits in between. Multiply your honest guess of engineer-days by a loaded engineer rate and this often dwarfs the compute line entirely.

Engineering Note. The cheapest tool at scale is rarely the cheapest tool to adopt. A team that picks the most accurate GPU pipeline and then spends three weeks fighting CUDA versions and a license review has spent more than a team that shipped Docling on a CPU in an afternoon and moved on. Optimize for total cost of ownership, not the per-page number.

Who Should Use Which

None

Stated plainly:

· Use Docling if you need the widest format coverage, a permissive MIT license, a CPU-only deployment, or clean structured output for a RAG pipeline. It is the safest default for most enterprises, and the license alone wins it a lot of rooms.

· Use MinerU if you have a GPU and accuracy on tables, formulas, or Chinese/CJK documents is your top priority. Its 1.2B VLM is the most accurate open option, and the pipeline backend is a solid CPU fallback.

· Use Marker if you are an individual, researcher, or early-stage startup processing high volumes and you want the fastest clean Markdown — and you've confirmed the license fits your situation.

Best Practice. Build a thin parse(document) -> StructuredDoc interface with all three behind it and a golden-set regression test. Parsers improve monthly and the "best" one will change; you want swapping to be a config flag, not a rewrite.

Frequently Asked Questions

Which is best for a pure-CPU deployment? Docling or MinerU's pipeline backend. Docling wins on format coverage and its MIT license; MinerU-pipeline wins on table and formula accuracy. Marker technically runs on CPU (and Apple MPS) but it's slow there and the license is the bigger constraint.

Which is best for Chinese or CJK documents? MinerU, and it isn't close. It was built by a Chinese lab, supports 109 languages, and leads on CJK accuracy. Marker (90+ languages via Surya) is a reasonable second.

I have millions of pages and a GPU fleet. Which is fastest? Marker in batch mode — up to ~120 pages/sec on an H100 — provided its GPL-3.0 + RAIL-M license fits your company's size and product. If it doesn't, MinerU2.5's VLM backend is the fastest license-clean option at high accuracy.

Can I use Marker in a commercial product? Only if you fit its license: free for research, personal use, and startups under roughly $2M in funding/revenue. Above that, you need a commercial license, and the code is GPL-3.0. Check with legal before you build on it — this is the number-one thing that eliminates Marker from enterprise shortlists.

Which produces the best output for RAG? Docling, by design — its DoclingDocument structure and native chunkers were built for RAG ingestion. MinerU's JSON is also structure-rich. The key is to chunk on that structure rather than blindly splitting Markdown by token count.

Do I even need a dedicated parser, or can a general vision-language model do this? For clean, born-digital PDFs a strong VLM can get surprisingly far. For high-volume, cost-sensitive, or accuracy-critical pipelines — especially tables and formulas — a dedicated parser is faster, cheaper, and more reliable. (That trade-off is worth its own article, and it's the next one in this series.)

Are the benchmark numbers in this article trustworthy? They are real and cited, but they are mostly vendor self-reported, on different benchmark suites and versions, and Docling is absent from the major boards entirely. Treat them as directional. The only number that decides your deployment is the one you get running the harness above on your own documents.

Which should I default to if I just want one? For most teams shipping real systems: Docling — MIT license, every format, CPU-friendly, RAG-ready output. Reach for MinerU when accuracy on hard documents is the priority and you have a GPU, and Marker when you're small, fast-moving, and processing high volumes.

Final Verdict

If you force me to one line: MinerU is the most accurate, Marker is the fastest, and Docling is the one you can actually use everywhere without asking permission — and for most teams, that last property wins.

MinerU2.5 is the most impressive engineering result of the three: a 1.2-billion-parameter model that tops a leaderboard against systems many times its size, by being clever about resolution instead of throwing parameters at the problem. If accuracy on hard documents is your job and you have a GPU, it's my default.

Marker is the most impressive throughput result: on a big GPU in batch it will out-run the others by a wide margin, and the LLM-refinement escape hatch is a genuinely good design. But its license quietly disqualifies it for a large slice of commercial users, and that has to be the first thing you check, not the last.

Docling is the most impressive product decision: MIT-licensed, every format, CPU-friendly, structured output built for RAG, and enterprise backing that means it isn't going anywhere. It is not the top of any accuracy leaderboard — partly because it isn't on the major ones — but "runs anywhere, ingests anything, and legal says yes" is worth more than three points of TEDS to most teams shipping real systems.

The meta-lesson is the same one that shows up every time I benchmark document AI: the leaderboard number is the least important input to the decision. Licensing, hardware, format coverage, and how cleanly the output feeds your RAG pipeline decide more real deployments than accuracy does. Run all three on your documents, filter on license first, and let your own corpus — not a README chart — make the call.

I write about OCR, Document AI, and production AI systems — benchmarking real tools on real documents instead of trusting launch charts. If you found this useful, the next piece pits OCR pipelines against general vision-language models to answer a question this article dances around: do you even need a dedicated parser, or is a VLM enough?

None

☕ Before You Go …

Code runs on logic… but creators run on coffee ☕

If this blog helped you even a little, consider supporting:

👉 https://www.buymeacoffee.com/adityamangg

It keeps these deep dives coming.