Jina AI veröffentlicht jina-ocr-v1 – mit der höchsten Seitenverarbeitungsleistung unter den 14 Modellen.

• Jina AI hat jina-ocr-v1 veröffentlicht – ein Dokumente-Parsingmodell, das auf DeepSeek-OCR basiert. Dieses Modell erreicht…2,57 Seiten pro Sekundeauf einer NVIDIA A100-GPU.
• Das Modell nutzt die spekulative Decodierung mit FastMTP sowie die Mixture of Experts-Architektur, um eine optimale Leistung zu erbringen.Ohne Verlust – identische Byte-AusgabeWährenddessen wird die Rechenlast verringert.
• In Jinas internen Benchmarks belegte jina-ocr-v1 den ersten Platz bei der Leistung auf Seiten, von 14 getesteten Systemen.Rangt als dritter in den Genauigkeit-Messungen..
• Die Veröffentlichung passt zu der Strategie von Elastic.Geringere Kosten pro SeiteZur Dokumentenaufnahme in den Retrieval-Augmented-Generation-Pipelines.
• Das Modell ist unter einer CC BY-NC 4.0-Lizenz verfügbar.Kommerzielle Nutzung, die Kontakt erfordertMit Jina AI.

Jina AI hat offiziell jina-ocr-v1 veröffentlicht – ein Dokumentparsingmodell, das dazu dient, PDF-Dateien, scannte Dokumente, Tabellen und Diagramme direkt in Markdown umzuwandeln. Das Modell wurde nach dem Training mit DeepSeek-OCR weiterentwickelt und behält seine Mixture of Experts (MoE)-Architektur bei. Diese Struktur umfasst insgesamt etwa 3,4 Milliarden Parameter – von denen nur 570 Millionen pro Token aktiv sind. Diese Konstruktion ermöglicht es dem Modell, bei geringen Betriebskosten zu funktionieren, während gleichzeitig eine hohe Leistungsfähigkeit gewährleistet wird.

Ein wichtiger Unterschied ist die Integration der schnellen MTP-Dekodierung. Diese Methode erstellt drei Tokens im Voraus und überprüft sie anschließend genau. Dadurch wird sichergestellt, dass das Ergebnis ohne Verluste und exakt dem Standardautoregressive-Dekodieren entspricht. Bei K=3 beträgt die durchschnittliche Anzahl der verwendeten Tokens 2,73 pro Schritt – was die Inferenz erheblich beschleunigt.

In den internen Benchmarkdaten erreichte jina-ocr-v1 bei OmniDocBench v1.6 eine Bewertung von 91,14. Auch bei olmOCR-Bench erzielte das Modell eine Bewertung von 83,4 – das ist ein Anstieg von 7,4 Punkten gegenüber dem Basismodell DeepSeek-OCR. Das Modell übertrifft somit 14 andere getestete Systeme in den Durchsatztests. Bei einem einzelnen NVIDIA A100-GPU mit 32 gleichzeitigen Anfragen kann das Modell 2,57 Seiten pro Sekunde verarbeiten. Das ist etwa 22% schneller als DeepSeek-OCR, das nur 2,10 Seiten pro Sekunde verarbeitet.

Wie reduziert die Architektur die Inferenzkosten?

Der Vorteil des Modells hinsichtlich der Geschwindigkeit beruht auf der Kompaktheit der Ausgabe und der reduzierten Decodierungsprozesse. Es erzeugt nur etwa 1.085 Tokens pro Seite – im Vergleich zu Konkurrenten wie Surya OCR 2, die etwa 3.568 Tokens pro Seite erzeugen. Die Architektur verwendet einen DeepEncoder mit einem konvolutionellen Kompressor sowie der CLIP-L-Stufe, um die Anzahl der visuellen Tokens zu reduzieren. Dadurch ist eine dynamische Bearbeitung der Auflösung möglich.

Der DeepEncoder enthält etwa 380 Millionen Parameter. Er kombiniert das SAM-Verfahren – einen 16-fach konvolutionellen Kompressor – mit CLIP-L. Dadurch wird der visuelle Eingang in 256 Tokens pro Seite komprimiert. Bei komplexen Seiten erhöht sich die Anzahl der Tokens auf 1.156. Nach dem Training erfolgt die Anpassung der Anweisungen sowie die Verbesserung der Robustheit der Modelle auf dekadenten Seiten mittels GRPO. Die Belohnungen sind deterministisch und werden anhand von Referenztranskriptionen bewertet.

Bei günstigerem Hardware-Setup wie dem NVIDIA L4 gibt die spekulative Decodierung eine Geschwindigkeitssteigerung von 1,95x im Eager-Modus. Das Modell eignet sich am besten für den Einsatz in großen Dokumentenverarbeitungsprozessen, wo die Kosten pro Seite entscheidend sind. Es unterstützt 100 verschiedene Sprachen und kann komplexe Strukturen wie Formeln und Tabellen mit hoher Genauigkeit verarbeiten.

Welche Kompromisse und Einschränkungen bezüglich der Genauigkeit gibt es?

Obwohl die Durchlaufleistung gut ist, ist die Genauigkeit eher konkurrenzfähig – nicht besonders stark. Auf der OmniDocBench v1.6-Prüfung erreicht das Modell eine Bewertung von 91,14, während PaddleOCR-VL-1.6 mit 96,34 abschneidet. Auf der olmOCR-Bench-Prüfung liegt das Modell hinter chandra-ocr-2, welches 85,8 erreicht. Das Modell hat Schwierigkeiten mit veralteten Scans – auf dem OldScans-Subset erhält es nur eine Bewertung von 42,6.

Die Benchmarks wurden selbstständig mit unkontrollierten Hardware-Einstellungen erstellt. Das bedeutet, dass die „Erstplatzierungs-Performance“ speziell auf Jinas Infrastruktur zugeschnitten ist. Das Modell entfernt Header und Footers – bei stark abgenutzten Scans kann eine menschliche Überprüfung erforderlich sein. Es ist über den Jina Reader verfügbar, einer OpenAI-kompatiblen API. Die Gewichte des Modells sind unter CC BY-NC 4.0 selbsthosted verfügbar.

Für Investoren ist der wichtigste Wert nicht die technische Revolution, sondern die Kostensenkung. Elastic hat Jina übernommen, um die Kosten pro Seite bei der Erfassung von Dokumenten in seinen RAG-Pipelines zu senken. Diese Verbesserung trägt zur Unit-Economics von Elastic bei – aber es handelt sich dabei um keine konkrete Wettbewerbsvorteile. Die zugrunde liegende Architektur ist Open-Source und somit leicht kopierbar. Die Gewichte sind auf Hugging Face verfügbar; dafür benötigt man vLLM 0.21+.