Jina AI’s 3.4B OCR model targets faster page parsing

Jina AI has released jina-ocr-v1, a page-oriented document parser that converts rendered PDF pages, scans, tables, and charts into Markdown in one generation pass. The model contains 3.4 billion parameters and activates about 570 million per generated token through a mixture-of-experts decoder. Jina built it by post-training DeepSeek-OCR.

Developers can download the weights from Hugging Face or select the model through the Jina Reader API with this request header:

x-respond-with: jina-ocr-v1

The downloadable weights use the CC BY-NC 4.0 license, which restricts commercial use. Commercial teams should review the model license and Jina’s API terms separately. Expert routing reduces computation per token, although self-hosted deployments still need memory for the complete model.

FastMTP cuts decoding work

FastMTP, Jina’s speculative decoding mechanism, drafts three tokens ahead and uses the main decoder to verify them greedily. OCR output often contains locally predictable sequences, allowing the model to accept several drafted tokens during one verifier pass. Jina reports an average of 2.7 committed tokens per pass.

The mechanism reuses one dense draft block recursively for K prediction steps. Under the same greedy decoding settings, Jina reports byte-identical output with speculation enabled or disabled. That property lets teams tune throughput without changing parsed documents or adding another source of output variance.

Quality and speed, side by side

Jina reports scores of 91.14 on OmniDocBench v1.6 and 83.4 on olmOCR-Bench at the default dynamic-resolution setting. The olmOCR-Bench score, reported on a 100-point scale, comprises these subsets:

Throughput testing on 1,403 pages used one A100 SXM4 40GB GPU at concurrency 32. jina-ocr-v1 processed 2.57 pages per second, generating an average of 1,085 output tokens per page and 2,792 output tokens per second.

The cross-model figures use different hardware, batch settings, and implementations, so they do not provide a controlled hardware comparison. They do show Jina’s intended trade-off: its reported olmOCR-Bench score trails Infinity-Parser2-Pro by 4.2 points while its parser emphasizes page throughput.

L4 settings change with execution mode

An NVIDIA L4 at batch size 1 shows the effect of both speculative decoding and runtime overhead. In eager mode, K=3 raises output speed from 42.7 to 83.1 tokens per second, a 1.95× increase. The draft-token acceptance rate is 57.6%.

CUDA graphs replay a captured GPU workload and reduce repeated kernel-launch overhead, which raises the baseline substantially. Jina recommends K=3 for eager execution and K=1 with CUDA graphs.

A compressed visual front end

DeepEncoder contributes about 380 million parameters. It sends page images through an 80M-parameter Segment Anything Model stage, a 16× convolutional compressor, and a 300M-parameter CLIP-L stage. The compressor reduces a 1024×1024 page to 256 visual tokens, limiting the sequence length passed to the decoder.

The Gundam dynamic-resolution mode adds image tiles for pages that need more detail. Each extra tile contributes 100 visual tokens, with a maximum of 1,156 tokens per page.

The DeepSeek-3B-MoE decoder contains 64 routed experts and two shared experts. Top-6 routing selects six routed experts for each token, producing the model’s roughly 570 million active parameters per generation step.

Post-training rewards exact structure

Jina’s post-training recipe contains three stages:

1. Instruction alignment for document-to-Markdown conversion.
2. Robustness fine-tuning on difficult and degraded documents.
3. Group Relative Policy Optimization, or GRPO, with deterministic structural rewards.

GRPO scores candidate outputs relative to others in the same group. The reward system checks formulas, tables, and document structure, then assigns partial credit for correct components. Those dense signals allow a mostly correct table to receive useful training feedback when one cell or delimiter is wrong.

Training data combines public OCR corpora, historical records, degraded scans, and targeted synthetic pages. Named sources include olmOCR-mix, FinePDFs, DoclingMatrix, SynthChartNet, UniMER, Europeana newspapers, Library of Congress transcripts, and NARA pension files. Synthetic examples include pages designed around olmOCR-Bench-style unit tests. Jina describes the full recipe in its technical report.

Best fits and hard limits

jina-ocr-v1 fits several common document-processing workloads:

• Bulk PDF conversion: The reported A100 throughput and single-L4 support suit page-at-a-time ingestion pipelines.
• Tables and formulas: The model emits structured Markdown and scores 88.8 on the olmOCR-Bench table subset.
• Multilingual archives: DeepSeek-OCR was pretrained on 30 million PDF pages spanning about 100 languages. Jina says its post-training focuses on 25 languages.
• Retrieval pipelines: Omitting repeated page furniture can reduce boilerplate in chunks used for retrieval-augmented generation.

Deployment constraints include:

• Headers and footers: The parser drops them, including page numbers that may be required for citation or archival workflows.
• Degraded scans: OldScans is the weakest reported subset at 42.6, making validation advisable for damaged or low-quality material.
• Maximum benchmark quality: Infinity-Parser2-Pro scores 87.6 on olmOCR-Bench, 4.2 points above jina-ocr-v1’s reported result.
• Commercial self-hosting: The CC BY-NC 4.0 weights require a license review before commercial use.

Choose the model from the source format

Source format and task determine which Jina model fits the pipeline:

As OCR benchmark scores converge, decoder cost becomes a larger part of deployment planning alongside accuracy, document coverage, and licensing. FastMTP addresses that cost directly: under Jina’s reported L4 eager-mode settings, it nearly doubles token throughput while preserving the output produced by greedy decoding.