jina-ocr-v1

jina-ocr-v1 turns a page into Markdown in one pass: text, formulas, tables and reading order together. What makes it different is where the engineering went. Parsing quality is crowded, so the model attacks the part that actually costs money in production, which is decoding. OCR output is locally predictable, so the model drafts three tokens ahead and lets the verifier check them greedily. Because verification is greedy, the result is lossless, byte-identical to plain autoregressive decoding, and the model commits up to 2.7 tokens per verifier pass instead of one.

The rest follows from the same goal. It is a mixture of experts with 3.4B total parameters but only about 570M active per token, so the running cost is that of a small model while the capacity is not. It scores 91.14 on OmniDocBench v1.6 and 83.4 on olmOCR-Bench at its default dynamic-resolution setting.

Language coverage is inherited from the base model. DeepSeek-OCR was pretrained on 30M PDF pages spanning about 100 languages, and jina-ocr-v1 keeps that encoder and decoder, so the same breadth applies to document parsing.

ReaderLM-v2 converts already-extracted HTML into Markdown. jina-ocr-v1 starts one step earlier and reads the rendered page itself.

The architecture inherits the DeepEncoder and the mixture-of-experts decoder of DeepSeek-OCR. DeepEncoder is about 380M parameters and chains an 80M SAM stage into a 16x convolutional compressor and then a 300M CLIP-L stage, so a 1024x1024 page costs only 256 visual tokens. The Gundam dynamic-resolution mode adds 100 tokens per extra tile, up to 1,156 tokens per page. The decoder is DeepSeek-3B-MoE with 12 layers, hidden size 1280, 64 routed experts plus 2 shared under top-6 routing, a 129,280-token vocabulary and a 32,768-position limit.

Decoding speed comes from FastMTP, a single dense draft block applied recursively for K=3 prediction steps rather than K separate heads. Verification is greedy, which makes the speculative path lossless. The emitted text is identical to what plain autoregressive decoding would produce.

Post-training runs instruction alignment, robustness fine-tuning on difficult and degraded documents, and GRPO under dense verifiable rewards, which are deterministic formula, table and structural checks that award partial credit instead of a single pass/fail signal. Training data mixes cleaned public OCR corpora such as olmOCR-mix, FinePDFs, DoclingMatrix, SynthChartNet and UniMER with historical and degraded material from Europeana newspapers, Library of Congress transcripts and NARA pension files, plus targeted synthetic pages carrying olmOCR-Bench-style unit tests so the reward has coverage where it matters.

On olmOCR-Bench the model scores 83.4 overall. Per subset it reaches Base 99.9, tied best in the comparison, then LongTiny 93.2, Tables 88.8, Hdr/Ftr 88.7, ArXiv 86.1, Multi-column 85.5, OldScans-Math 82.3 and OldScans 42.6. On OmniDocBench v1.6 it reaches 91.14 overall, with text edit distance 0.046, formula CDM 93.28, table TEDS 84.68, TEDS-S 89.01 and reading-order edit distance 0.142.

The efficiency result is the point of the model. Measured on one A100 SXM4 40GB at concurrency 32 over 1,403 pages, it sustains 2.57 pages per second, the best in the comparison and roughly twice the 1.22 of olmOCR-2, while spending 1085 output tokens per page and 2792 output tokens per second. Models that score higher are far slower. chandra-ocr-2 leads on quality at 85.8 but runs at 0.38 pages per second, and dots.mocr scores 83.9 at 0.55. The token figures are competitive but not the best in the pool. PaddleOCR-VL-1.6 is leaner per page at 1048, and Surya OCR 2 emits more tokens per second at 3760.

Speculative decoding is what makes a cheap GPU viable. On an NVIDIA L4 at batch size 1, FastMTP lifts eager-mode decoding from 42.7 to 83.1 output tokens per second at K=3, a 1.95x speedup at a 57.6% acceptance rate. With CUDA graphs the baseline is already 158.3 tokens per second, and K=1 is the best operating point at 185.6 for a 1.17x gain. These L4 numbers are measured at batch size 1 on different hardware and are not comparable with the A100 throughput figures above.

Use the default dynamic-resolution setting for general documents. It is the configuration behind the reported scores. Output is Markdown, so tables and formulas arrive already structured and need no separate post-processing step. The model targets low-budget GPUs. An L4 or similar is enough for interactive single-document parsing, and speculative decoding gives the largest gain in eager mode, so enable K=3 there and K=1 when running with CUDA graphs. Because verification is greedy, turning speculation on or off changes throughput but never the text.

Best suited to bulk document ingestion, PDF-to-Markdown pipelines, scanned and historical archives, and any workload where pages per second per dollar matters more than the last point of benchmark score. Headers and footers are transcribed rather than dropped, which is the desired behavior for archival fidelity but scores low on text-absence tests. OldScans remains the weakest subset at 42.6, so heavily degraded scans still warrant a human check.

If your input is HTML that has already been fetched, ReaderLM-v2 is the cheaper tool for the same Markdown target. For visual question answering over a page rather than transcription, use jina-vlm. For retrieval over the parsed output, pair with jina-embeddings-v4.