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.
Listen to this story
The audio brief
Story brief
3 key pointsJina 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...
- 01
Jina reports top throughput among 14 systems tested, but the result is measured under concurrency 32 on an A100.
- 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.
- 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
- jina.aijina-ocr-v1: Faster Document Parsing on Low-Budget GPUs
Loading discussion...
Reader comments
Newest comments first. Replies stay oldest first.