Jina AI Releases Document Parser, Claims 2.57 Pages Per Second

The open-weight model combines speculative decoding with API access, while its reported results point to damaged scans as a practical limitation.

By 3 min read
Jina AI Releases Document Parser, Claims 2.57 Pages Per Second
Jina AI Releases Document Parser, Claims 2.57 Pages Per Second

Listen to this story

The audio brief

About 1:46
0:001:46
Read transcript
Jina AI has released jina-ocr-v1, a document parser that turns PDFs, scans, tables, charts, and invoices into structured Markdown, while claiming a top speed of 2.57 pages per second. That figure comes from one NVIDIA A100 at concurrency 32, across a comparison of 14 systems, so it describes a heavily parallel setup rather than every workload. The model has 3.4 billion parameters, but its mixture-of-experts decoder activates about 570 million for each generated token. Its main speed feature is FastMTP, a speculative-decoding head that proposes three tokens ahead. The main decoder checks those proposals, and Jina says the resulting sequence matches ordinary greedy decoding; the gain is throughput, not a different transcription. On an NVIDIA L4 at batch size one, Jina reports a 1.95-times speedup. The tradeoff is accuracy. Jina reports 91.14 on OmniDocBench version 1.6 and 83.4 on olmOCR-Bench. PaddleOCR-VL-1.6 leads the first benchmark at 96.34, while chandra-ocr-2 leads the second at 85.8. The model’s 42.6 score on the OldScans portion also points to a practical weakness with damaged historical pages, especially when a benchmark rewards omitting headers and footers rather than preserving everything. Teams can use Jina Reader, an OpenAI-compatible endpoint, or download the weights and custom code. But those weights carry a CC BY-NC 4.0 license, so commercial self-hosting requires contacting Jina. The key question is whether its speed advantage survives on the messy documents a deployment actually needs to preserve.

Story brief

3 key points

Jina AI’s new jina-ocr-v1 targets high-volume document workflows with a 3.4-billion-parameter mixture-of-experts architecture and speculative decoding that activates roughly 570 million decoder parameters per token. The company reports 2.57 pages per second on one A100 at concurrency 32 and a 1.95× speedup on an L4 at batch size one. Accuracy is competitive but not leading every benchmark, while self-hosting is...

  1. 01

    Jina reports top throughput among 14 systems tested, but the result is measured under concurrency 32 on an A100.

  2. 02

    PaddleOCR-VL-1.6 leads OmniDocBench at 96.34 versus jina-ocr-v1’s 91.14; chandra-ocr-2 leads olmOCR-Bench at 85.8.

  3. 03

    FastMTP proposes three tokens ahead and requires vLLM 0.21 or later plus one-time registration.

Turning a document into useful AI input often means extracting far more than plain text: reading order, tables, equations and layout all need to survive the conversion. Jina AI has now released jina-ocr-v1, a model designed to turn rendered document pages into structured Markdown while reducing the decoding work that can make high-volume parsing slow.

A parser built around the output bottleneck

The 3.4-billion-parameter model accepts PDFs, scans, tables, charts and invoices, then returns Markdown in one pass. It uses a mixture-of-experts decoder, a design that activates about 570 million decoder parameters for each generated token rather than the whole model at once.

The central speed feature is FastMTP, Jina’s speculative-decoding head. Instead of waiting for the main model to produce every next token, it proposes three tokens ahead; the main decoder then checks those proposals greedily. Jina says the process commits the same sequence as ordinary greedy decoding, changing throughput rather than the resulting transcription.

Speed is not a claim to overall accuracy leadership

Jina reports scores of 91.14 on OmniDocBench v1.6 and 83.4 on olmOCR-Bench. Those are strong results, but the company’s own tables show that jina-ocr-v1 does not lead every accuracy comparison: PaddleOCR-VL-1.6 scores 96.34 on OmniDocBench, while chandra-ocr-2 scores 85.8 on olmOCR-Bench.

That distinction matters for buyers deciding whether a faster pipeline is sufficient for the documents they actually hold. The reported olmOCR-Bench score includes 42.6 on OldScans, while the model’s header-and-footer column specifically rewards omission. A faithful full-page transcription therefore scores low on that test, making the benchmark’s definition of success different from an archive that needs every page element preserved.

Several ways in, one important license boundary

Jina offers the model through downloadable weights, its Jina Reader service and an OpenAI-compatible endpoint. Reader can fetch a document URL, render it and return Markdown when a request uses the jina-ocr-v1 response setting. For teams that want to run the model themselves, Jina says the repository includes the weights and custom modeling code; FastMTP requires vLLM version 0.21 or later and a one-time registration step.

What the release offers

  • Hosted document conversion through Reader and a direct API endpoint.
  • Self-hosted weights and custom code for deployments that can use the required runtime.
  • Weights under CC BY-NC 4.0, which Jina says are for non-commercial use; commercial users must contact the company.

The release is a reminder that document AI is not one problem. A system can be accurate on tables, fast at producing concise Markdown and economical on a lower-cost GPU, yet still need careful validation on degraded historical material or workflows that require complete page fidelity. Jina’s numbers make a case for its speed-focused design; real deployment will determine whether that tradeoff matches the source documents at hand.

Sources

  1. jina.aijina-ocr-v1: Faster Document Parsing on Low-Budget GPUs

Loading discussion...

YOUR READING SPACE

Notifications