Feed a contract or a research paper to an agent, and the first step is not reasoning — it is reading the document into clean text. Sloppy reading means everything built on top inherits the garbage. Between late 2025 and early 2026 the open-source OCR arena filled up with new names: DeepSeek-OCR 2, PaddleOCR-VL 1.5, MinerU 2.5, dots.ocr, GOT-OCR2.0, and GLM-OCR. Put the six side by side and the first thing that jumps out is not a leaderboard score but a stark ratio: on the same page, GOT-OCR2.0 consumes a fixed 256 visual tokens while MinerU 2.5 averages 6,790 — a 26x gap. Add DeepSeek-OCR's first-generation Small mode (100 tokens) and the spread approaches 68x.
This article compares the six on three things: technical routes, what the benchmark numbers actually measure, and a dimension that can veto everything else — the license.
Why compare open-source OCR models again now
The burst is no accident: agent workflows have made document parsing the entry point — RAG pipelines need clean paragraph boundaries before chunking, review agents need scans turned into text before they can reason. Cloud APIs work, but your data leaves your perimeter and rate limits belong to someone else, so pulling open weights in-house has become the default move. Free weights are only the entry ticket, though; the real exam is which model runs on your GPUs, your document types, and your commercial constraints.
Scope first. Our August 2026 piece on AI OCR tools answered a different question: which cloud API to buy — Mistral OCR, TextIn, Datalab and other managed products, where the variables are price per page, concurrency, and SLA. This article answers another one: which open-source weights to deploy yourself, where the variables become VRAM, throughput, visual tokens per page, and license terms. A companion piece walks through deploying DeepSeek-OCR locally; this article helps you choose, that one helps you install (DeepSeek-OCR local deployment SOP).
Three routes: compression, fidelity, unification
Behind six names sit three philosophies.
Compressionists bet that document information is highly redundant. GOT-OCR2.0 is the radical case: 580M parameters, a 1024×1024 image squeezed into a fixed 256 visual tokens, end-to-end output of Markdown, HTML, and LaTeX — even SMILES formulas and music scores, what its authors call "OCR-2.0 species." DeepSeek-OCR 2 keeps the philosophy but adds a dial: visual tokens adjustable between 256 and 1,120, on a DeepEncoder V2 plus a 3B MoE decoder (6 of 64 experts active, ~570M active), with dynamic resolution and 8K context.
Fidelity-first models refuse to drop information. MinerU 2.5 decouples the job into two stages: layout analysis on a downsampled image, then high-resolution re-recognition of key regions — quality goes up, and so does the bill, about 6,790 visual tokens per page on average. dots.ocr takes the high-fidelity path too, at roughly 5,545 tokens per page with 200 dpi input.
Balanced and unified models split the difference. PaddleOCR-VL pairs a NaViT dynamic-resolution encoder with a 0.3B ERNIE-4.5 decoder in just 0.9B parameters, covering 109 languages. GLM-OCR uses a CogViT encoder with a 0.5B GLM decoder in a two-stage layout-plus-parallel-recognition pipeline. dots.ocr folds layout detection, text recognition, tables, and formulas into a single model switched by prompt, covering 100+ languages.
None of the routes wins outright: choose throughput for ten thousand pages or character-perfect reconstruction of a messy layout.
Spec sheet and licenses
| Model | Publisher | Parameters | License | Architecture notes | Weights |
|---|---|---|---|---|---|
| DeepSeek-OCR 2 | DeepSeek AI | 3B MoE (~570M active) | Apache-2.0 (official repo LICENSE; v1 is MIT) | DeepEncoder V2 + 3B MoE, tokens adjustable 256–1,120 | Hugging Face: deepseek-ai/DeepSeek-OCR-2; mirrored on ModelScope |
| PaddleOCR-VL 1.5 | Baidu | 0.9B | Apache-2.0 | NaViT dynamic encoder + ERNIE-4.5-0.3B decoder, 109 languages | Hugging Face / GitHub / PaddlePaddle site |
| MinerU 2.5 | Shanghai AI Lab | 1.2B | AGPL-3.0 | Two-stage: downsampled layout + full-resolution re-recognition | Hugging Face / ModelScope / GitHub (opendatalab/MinerU) |
| dots.ocr | rednote-hilab | 3B (Qwen2.5 base; ~1.7B also reported) | Apache-2.0 | Single model for layout, text, tables, formulas via prompts | Hugging Face: rednote-hilab/dots.ocr |
| GOT-OCR2.0 | StepFun | 580M | Apache-2.0 | High-compression encoder (1024×1024 to 256 tokens) + 8K decoder | Hugging Face: stepfun-ai/GOT-OCR2_0 |
| GLM-OCR | Z.ai | 0.9B | Weights MIT; code and layout component Apache-2.0 | CogViT encoder + GLM-0.5B decoder, PP-DocLayoutV3 layout | Hugging Face / GitHub; supports vLLM, SGLang, Ollama |
Three contested facts. First, DeepSeek-OCR 2's license was reported as both MIT and Apache-2.0 by different secondary sources; this article follows the LICENSE file in the official repository github.com/deepseek-ai/DeepSeek-OCR-2 and calls it Apache-2.0 — the first-generation model is MIT, which likely explains the confusion. Second, GLM-OCR's MIT comes from third-party listings, unverified against the official model card. Third, dots.ocr is reported both as 3B total and as a Qwen2.5-1.7B base; the conclusions do not change.
Also worth a line, though they missed the cut: Chandra OCR 2 (Datalab, 4B, self-reported 85.9 on olmOCR-Bench, OpenRAIL-M weights with a revenue-cap clause), HunyuanOCR (Tencent, 1B, self-reported 94.10 on v1.5), and olmOCR 2 (Ai2, 7B, self-reported 82.4).
Performance: the same-ruler problem
Here is the warning this article exists to deliver: every score below is labeled vendor-reported or third-party transcribed, and different benchmark versions are never ranked directly — because community leaderboards routinely mix OmniDocBench versions inside one table. MinerU 2.5's 90.67 comes from the paper edition (981 pages, 9 document classes); GLM-OCR's 94.62 and PaddleOCR-VL 1.5's 94.5 come from v1.5 (1,355 pages). Different question sets, one ranking — that is how "ranking inversions" get manufactured. Before trusting any OCR score, ask: which version, how many pages, who ran it.
| Model | Composite score | Benchmark caliber | Nature of the number |
|---|---|---|---|
| GLM-OCR | 94.62 | OmniDocBench v1.5 | Vendor-reported (via third-party listings) |
| PaddleOCR-VL 1.5 | 94.5 (1.6 self-reports 96.33 on v1.6) | v1.5 | Vendor-reported |
| HunyuanOCR (reference) | 94.10 | v1.5 | Vendor-reported |
| DeepSeek-OCR 2 | 91.09 (a competing 87.01 also circulates) | v1.5 | Vendor-reported / media-transcribed; both listed, not adjudicated |
| MinerU 2.5 | 90.67 | OmniDocBench paper edition (981 pages, 9 classes) | Vendor-reported (paper caliber) |
| dots.ocr | 88.41 | OmniDocBench composite | Third-party transcription (consistent with official release) |
| GOT-OCR2.0 | Edit distance 0.287 (lower is better) | OmniDocBench v1.0 edit distance | Vendor-reported (cited in DeepSeek's paper) |
In the v1.5 cohort, GLM-OCR and PaddleOCR-VL 1.5 sit within half a point of each other, both self-reporting above 94. PaddleOCR-VL's first release scored 92.6, was billed "world number one" in October 2025, and was overtaken weeks later by its own 1.5 update — vendor-reported records have a shelf life measured in weeks. DeepSeek-OCR 2's 91.09 has a competing 87.01 figure from the same batch of secondary sources, possibly a different token configuration or v1.5 sub-version; we list both without adjudicating. GOT-OCR2.0 only has a v1.0 edit-distance figure, which cannot be compared with anyone's v1.5 composite — a confusion the community keeps making.
Sub-scores reveal personalities. Third-party measurements suggest MinerU is strongest on rotated, multi-page, and borderless tables plus compound formulas; GOT shines on LaTeX and SMILES-style "OCR-2.0 species"; PaddleOCR-VL 1.5 adds stamp recognition and cross-page table stitching, with a self-reported reading-order error of 0.043. DeepSeek-OCR 2's "causal flow" semantic reordering reportedly cuts reading-order edit distance from 0.085 to 0.057 (vendor-reported); community tests put dots.ocr at 0.193, ahead of GOT's 0.287.
Third-party benchmarks need scrutiny too: on olmOCR-Bench, Chandra 2 tops the board with a self-reported 85.9, but the benchmark's maintainer, Datalab, sells its own commercial OCR API and calls the benchmark "saturated" in its docs. Referee and player in one; quote with a question mark.
The compression story has a counterweight: a third-party study by Northeastern University and the Chinese Academy of Sciences found DeepSeek-OCR's accuracy collapses from roughly 90% to about 20% once language-prior support is removed. Radical compression leans on the decoder's language priors; on pure graphics, exotic layouts, or unfamiliar scripts, the discount is bigger than the marketing suggests.
The token bill and the hardware bill
| Model | Visual tokens per page | Source |
|---|---|---|
| GOT-OCR2.0 | Fixed 256 | DeepSeek-OCR paper |
| DeepSeek-OCR (v1) | Small 100; Base 256 (182 effective); Gundam under 800 | Official paper |
| DeepSeek-OCR 2 | 256–1,120 adjustable | Secondary sources |
| MinerU 2.5 | Average 6,790 | DeepSeek-OCR paper |
| dots.ocr | ~5,545 at 200 dpi | DeepSeek-OCR paper comparison table |
| PaddleOCR-VL / GLM-OCR | No authoritative per-page figure published; secondhand estimates 1,500–6,000 | Unverified; not fabricated here |
This bill hits your wallet directly. The same page costs 26x more visual tokens on MinerU 2.5 than on GOT-OCR2.0, and throughput, KV cache, and context occupancy scale with it: ten thousand pages cost about 2.56 million visual tokens at GOT's fixed 256 versus about 67.9 million at MinerU's average — a gap that decides how many GPUs you buy. Compression ratio and accuracy are two ends of one slider: DeepSeek officially reports over 96% accuracy at 10x text compression, dropping to about 60% at 20x.
Hardware tickets come in two tiers. Lightweight: GOT-OCR2.0's 580M parameters run in about 2GB VRAM at FP16, about 1GB at Q4 (secondary sources) — the lowest bar of the six; MinerU 2.5's Pipeline mode runs on 6GB or even CPU, under 4GB after INT8 quantization; PaddleOCR-VL and GLM-OCR are quoted at 8GB and up. Heavy: full MinerU 2.5 does 1.7 pages per second on an RTX 4090 (vendor release notes); PaddleOCR-VL self-reports 1.86 pages per second on an A100; the first DeepSeek-OCR exceeded 200,000 pages per day on a single A100-40G, and DeepSeek-OCR 2 does roughly 2,500 tokens per second under vLLM on an A100 (secondary sources), with FP16 minimum around 16GB and Q4 around 2GB (secondary, unverified). In one line: compressionists save cards and money; fidelity-first spends tokens to buy layout fidelity.
Licenses and commercial red lines
Beyond performance, the license is this article's one-vote-veto dimension.
MinerU 2.5's weights are AGPL-3.0: if a network service runs a modified version, the server-side changes must be offered to users. For internal tooling the impact is limited; for a SaaS product it is a hard constraint. The popular claim that calling the unmodified original avoids copyleft is heavily disputed; the safe paths are accepting the obligations or negotiating a commercial license — not legal advice. Chandra OCR 2's OpenRAIL-M carries a revenue-cap clause: annual revenue above 2 million US dollars triggers a paid license — harmless for a small team, a time bomb for a funded company. The rest of the field is comparatively clean: PaddleOCR-VL, dots.ocr, GOT-OCR2.0, and DeepSeek-OCR 2 are all Apache-2.0; GLM-OCR is listed as MIT (unverified). MIT and Apache are practically equivalent commercially; the line that matters is "not AGPL, no revenue cap."
Practical advice: make the license the first filter and the benchmark the second, so you never pick a model your legal team then vetoes.
Tiered verdicts
Throughput and low-cost batch scanning: DeepSeek-OCR 2 — adjustable token dial, clean Apache-2.0, mature vLLM ecosystem; on a tight budget, GOT-OCR2.0 gets you in at 2GB. Complex academic documents and character-perfect formulas: MinerU 2.5 (if you accept AGPL) or dots.ocr (freer under Apache), budgeting three to four times the token spend. Multilingual and heterogeneous hardware: PaddleOCR-VL 1.5, with 109 languages plus Ascend and AMD ROCm support. Local tinkering: GLM-OCR, Ollama support, 8GB and up (secondary sources).
One last discipline: per-page visual tokens for PaddleOCR-VL and GLM-OCR have no authoritative public caliber — this article writes "not published" rather than inventing numbers. Before committing, run your own ten nastiest documents through every candidate; that beats any leaderboard.
FAQ
Q1: Which of the six should I pick? Choose by need: batch scanning points to DeepSeek-OCR 2 or GOT-OCR2.0; complex layouts to MinerU 2.5 or dots.ocr; multilingual work to PaddleOCR-VL 1.5; local tinkering to GLM-OCR. There is no all-around champion.
Q2: What is the minimum VRAM? Lowest bar is GOT-OCR2.0: about 2GB at FP16, about 1GB at Q4 (secondary-source figures). MinerU 2.5's Pipeline mode runs on 6GB or even CPU; PaddleOCR-VL and GLM-OCR start around 8GB; DeepSeek-OCR 2 needs about 16GB at FP16 or 2GB at Q4 (secondary, unverified). None are our own measurements — check official repos such as github.com/deepseek-ai/DeepSeek-OCR-2 before deploying.
Q3: Which licenses are cleanest for commercial use? PaddleOCR-VL, dots.ocr, GOT-OCR2.0, and DeepSeek-OCR 2 are all Apache-2.0 — commercial use and closed-source distribution allowed. GLM-OCR's weights are MIT while its code and PP-DocLayoutV3 layout component are Apache-2.0 (verified from the official README and LICENSE text). MinerU 2.5's AGPL-3.0 risks contagion for SaaS; Chandra OCR 2 has a paid clause above 2 million US dollars in annual revenue. Read the license text yourself before shipping.
Q4: Why can't leaderboard scores be compared directly? Because the benchmark versions differ: MinerU 2.5's 90.67 is the OmniDocBench paper edition (981 pages), GLM-OCR's 94.62 and PaddleOCR-VL 1.5's 94.5 are v1.5 (1,355 pages), and GOT-OCR2.0 only has a v1.0 edit-distance figure. Different question sets and metric directions make direct ranking self-deception.
Q5: Self-hosted open weights or cloud API? If data cannot leave your perimeter, volume is large, and you can maintain a GPU stack, self-hosting wins on long-run cost and independence from rate limits. For occasional use and SLA guarantees, a cloud API fits better. Our August piece on AI OCR tools covers the managed side.
Related reading
- A 39x Per-Token Cache Gap: Four Flagship Open-Weight Agent Models Compared
- A 0.9B Model Just Topped the OCR Leaderboard: How Real Is It?
- A 3B Model That Chews 200k Pages a Day: DeepSeek-OCR Deploy SOP
- Everyone Says Open: Which Model License Actually Lets You Ship
- DeepSeek Ships Again: Free Weights, Task Bills Cut by 60%