How the new OCR models read a page

Document reading has moved from character recognition to vision-language models that read a page as a whole and write it out as structured text. On clean pages, accuracy is now largely solved. The differences that matter are elsewhere: how a model splits the work, how many tokens a page costs, how it decides what to read first, and how much of its output can be checked. This note looks at those choices, using DeepSeek-OCR, DeepSeek-OCR 2, PaddleOCR-VL and Mistral OCR as reference points.

Two architectures

The first design is end-to-end. A single model takes the page image, encodes it into visual tokens and decodes the full content (text, tables, formulas) in one pass, usually as Markdown or HTML. Layout, reading order and recognition are learned jointly. DeepSeek-OCR follows this design.

The second design is two-stage. A dedicated layout model first detects the blocks on the page and their reading order; a recognition model then reads each block separately. PaddleOCR-VL follows this design: a layout model, PP-DocLayoutV2, handles detection and ordering, then a 0.9-billion-parameter vision-language model recognises text, tables, formulas and charts element by element.

The trade-off is classic. End-to-end models can use the whole page as context and avoid errors at block boundaries, but a single decoding error can derail everything that follows. Two-stage systems isolate failures to one block and parallelise well, but inherit any mistake the layout stage makes.

Compressing the page

A page of dense text can take thousands of text tokens. DeepSeek-OCR asks how few visual tokens can represent it, defining a compression ratio as the number of text tokens on the page divided by the number of visual tokens used to encode it.

Its encoder chains a window-attention stage built on SAM-base (about 80M parameters), a two-layer convolutional module that downsamples tokens 16× (a 1024×1024 page goes from 4,096 patch tokens to 256), and a global-attention stage built on CLIP-large (about 300M parameters). The decoder is a 3B-parameter mixture-of-experts model with about 0.5B parameters active per token.

On the authors’ benchmark, decoding precision is about 97% at compression ratios up to 10×, around 90% between 10× and 12×, and about 60% at 20×. Reported throughput exceeds 200,000 pages per day on a single A100-40G.

The token budget is the main cost lever of any page-level model: fewer visual tokens mean faster encoding, shorter attention and cheaper decoding. The result also suggests a broader use: visual tokens as a compact store for long text contexts, with precision traded against compression.

Learning the reading order

Most vision encoders flatten an image in raster order, top-left to bottom-right. For documents, that order is often wrong: columns, sidebars, footnotes and tables are not read line by line across the page.

DeepSeek-OCR 2 addresses this inside the encoder. It replaces the CLIP stage with a compact language-model architecture (Qwen2-0.5B) and appends a set of learnable “causal flow” queries after the visual tokens, as many queries as there are visual tokens. Visual tokens attend to each other bidirectionally; each query attends to all visual tokens and to the queries before it. Only the query outputs are passed to the decoder. The effect is a sequence reordered according to the page’s content rather than its pixel grid.

The visual budget stays between 256 and 1,120 tokens, using a 1024×1024 global view (256 queries) plus up to six 768×768 crops (144 queries each). On OmniDocBench v1.5, the authors report an overall score of 91.09, against 87.36 for the first version in its 9-crop configuration, and a reading-order edit distance falling from 0.085 to 0.057.

Why small models win

Document parsing does not need a general-purpose model. PaddleOCR-VL’s recognition model has 0.9B parameters in total: a NaViT-style encoder that accepts images at their native resolution, avoiding the distortion of resizing to a fixed grid, paired with a 0.3B-parameter language model (ERNIE-4.5-0.3B) chosen for fast decoding. It supports 109 languages and reports 92.86 on OmniDocBench v1.5.

On the same benchmark version, that is above the 88.03 reported for Gemini 2.5 Pro in DeepSeek’s evaluation, though the two figures come from different papers and settings. Two reasons explain why such compact models can compete with much larger general-purpose ones. The task is narrow and well supervised: the target output is the page itself, so training data can be generated and checked at scale. And most of the difficulty is perceptual, not linguistic: resolution, layout and structure matter more than world knowledge. A small decoder is then not a weakness but a choice: it decodes faster and costs less.

Auditable output

For production use, what a model returns matters as much as how well it reads. Plain Markdown loses the link between each piece of text and its place on the page.

Mistral OCR 4 illustrates the direction. Alongside the extracted content, it returns bounding boxes, a type for each block (title, table, equation, signature, and so on) and confidence scores at page and word level, across 170 languages, and can be deployed self-hosted, in a single container, for enterprise customers. Mistral reports a score of 85.20 on olmOCR-Bench and an average 72% win rate in human preference tests; these are vendor figures.

Boxes and per-word confidence change what can be built downstream. Every extracted value can be traced to a region of the page, low-confidence words can be routed to review, and structured fields can be validated against their expected formats before they are trusted.

Cost

The cost of reading a page has fallen far enough that converting an entire archive is an engineering decision rather than a budget one.

Hosted APIs price by the page: Mistral OCR 4 is listed at $4 per 1,000 pages, or $2 through its batch interface. Self-hosted open models move the cost to hardware: DeepSeek-OCR’s authors report more than 200,000 pages per day on a single A100-40G, and the authors of olmOCR, a 7B open model, estimate under $200 per million pages. These are vendor and author figures, measured under their own conditions, but the order of magnitude is clear: a million pages now costs hundreds to a few thousand dollars, not a project budget.

The real cost has moved elsewhere: to verification, to the pages that need a second reading, and to the downstream systems that must decide which values to trust.

Reading the benchmarks

Two benchmarks dominate. OmniDocBench evaluates full-page parsing across document types, scoring each element with its own metric: normalised edit distance for text and reading order, TEDS (a tree-edit-distance similarity on table structure) for tables, and CDM for formulas. In v1.5, its overall score averages the text, table and formula scores. olmOCR-Bench takes a different approach, checking pages against specific pass/fail facts: whether a given sentence is present, whether two passages appear in the right order, whether a table cell holds the right value.

Three cautions apply. Versions are not comparable: a score on OmniDocBench v1.5 says nothing about v1.6. Many published figures are reported by the model’s own authors, under their own settings. And an aggregate score can hide the failures that matter for a given use: a model can parse body text perfectly and still misread the one table that holds the figures.

Failure modes

The new models fail differently from classic OCR, and less visibly.

Fluent substitutions: a generative decoder can output a plausible word, name or number that is not on the page. The text reads cleanly; the error is invisible without the image.

Digit-level errors: on financial tables and identifiers, a single wrong digit inside otherwise perfect output is the most costly error and the hardest to spot.

Structural over-fitting: models trained heavily on tables can impose a table structure on text that is not tabular, or merge columns that should stay separate.

Input sensitivity: the same document can be read differently depending on whether it is submitted as a PDF or as images, and at which resolution.

Loops and omissions: repeated lines and silently skipped blocks remain possible, especially on long or degraded pages.

Summary

The choices that now separate document-reading models are architectural: end-to-end or layout-first, how many visual tokens a page costs, whether reading order is learned or assumed, and whether the output can be traced and checked. On clean pages, the reading itself is no longer the hard part. What remains hard is knowing, value by value, when a page has been read wrongly.