jina-ocr-v1

jina-ocr-v1 wandelt eine Seite in einem Durchgang in Markdown um: Text, Formeln, Tabellen und Lesereihenfolge zusammen. Der Unterschied liegt darin, wohin die Entwicklungsarbeit geflossen ist. Beim Parsing ist die Konkurrenz groß, deshalb setzt das Modell bei dem Teil an, der in der Produktion wirklich Geld kostet – dem Dekodieren. OCR-Ausgaben sind lokal vorhersagbar, deshalb schlägt das Modell drei Token im Voraus vor und lässt den Verifikator sie gierig prüfen. Weil die Prüfung gierig ist, ist das Ergebnis verlustfrei – byteidentisch mit der einfachen autoregressiven Dekodierung – und das Modell akzeptiert durchschnittlich 2,7 Token pro Verifikator-Durchgang statt eines.

Der Rest folgt aus demselben Ziel. Es ist eine Mixture of Experts mit 3,4B Gesamtparametern, aber nur rund 570M aktiv pro Token: Die Laufzeitkosten sind die eines kleinen Modells, die Kapazität nicht. In der Standardeinstellung mit dynamischer Auflösung erreicht es 91,14 auf OmniDocBench v1.6 und 83,4 auf olmOCR-Bench.

Die Sprachabdeckung wird vom Basismodell geerbt. DeepSeek-OCR wurde auf 30M PDF-Seiten über rund 100 Sprachen vortrainiert, und jina-ocr-v1 behält Encoder und Decoder des Basismodells bei, daher gilt dieselbe Breite auch für die Dokumentenanalyse.

ReaderLM-v2 konvertiert bereits extrahiertes HTML in Markdown. jina-ocr-v1 beginnt einen Schritt früher und liest die gerenderte Seite selbst.

Die Architektur erbt DeepEncoder und den Mixture-of-Experts-Decoder von DeepSeek-OCR. DeepEncoder hat rund 380M Parameter und verkettet eine 80M-SAM-Stufe über einen 16x-Faltungskompressor mit einer 300M-CLIP-L-Stufe, sodass eine 1024x1024-Seite nur 256 visuelle Token kostet. Der Gundam-Modus mit dynamischer Auflösung fügt pro zusätzlicher Kachel 100 Token hinzu, bis zu 1.156 Token pro Seite. Der Decoder ist DeepSeek-3B-MoE mit 12 Schichten, Hidden-Size 1280, 64 gerouteten Experten plus 2 geteilten bei Top-6-Routing, einem Wortschatz von 129.280 Token und einer Positionsobergrenze von 32.768.

Die Dekodiergeschwindigkeit kommt von FastMTP: einem einzelnen dichten Draft-Block, der rekursiv für K=3 Prädiktionsschritte angewendet wird statt K separaten Heads. Die Prüfung ist gierig, was den spekulativen Pfad verlustfrei macht. Der ausgegebene Text ist identisch mit dem einer einfachen autoregressiven Dekodierung.

Das Post-Training umfasst Instruction-Alignment, Robustheits-Feintuning an schwierigen und beschädigten Dokumenten sowie GRPO unter dichten, verifizierbaren Belohnungen – deterministische Prüfungen von Formeln, Tabellen und Struktur, die Teilleistung belohnen statt ein einzelnes Pass/Fail-Signal. Die Trainingsdaten mischen aufgeräumte öffentliche OCR-Korpora wie olmOCR-mix, FinePDFs, DoclingMatrix, SynthChartNet und UniMER mit historischem und beschädigtem Material aus Europeana-Zeitungen, Library-of-Congress-Transkripten und NARA-Pensionsakten, dazu gezielte synthetische Seiten mit olmOCR-Bench-artigen Unit-Tests, damit die Belohnung dort Abdeckung hat, wo es zählt.

Bei olmOCR-Bench erzielt das Modell insgesamt 83,4. Pro Subset: Base 99,9 – gleichauf mit dem besten Wert im Vergleich –, danach LongTiny 93,2, Tables 88,8, Hdr/Ftr 88,7, ArXiv 86,1, Multi-column 85,5, OldScans-Math 82,3 und OldScans 42,6. Auf OmniDocBench v1.6 erreicht es insgesamt 91,14, mit Text-Edit-Distance 0,046, Formel-CDM 93,28, Tabelle-TEDS 84,68, TEDS-S 89,01 und Leseordnungs-Edit-Distance 0,142.

Das Effizienz-Ergebnis ist der springende Punkt des Modells. Auf einer A100 SXM4 40GB gemessen, bei 32 gleichzeitigen Anfragen über 1.403 Seiten hält es 2,57 Seiten pro Sekunde – das beste Ergebnis im Vergleich und etwa doppelt so hoch wie die 1,22 von olmOCR-2 – bei 1.085 Ausgabe-Tokens pro Seite und 2.792 Ausgabe-Tokens pro Sekunde. Modelle mit höheren Scores sind deutlich langsamer. Infinity-Parser2-Pro führt bei der Qualität mit 87,6, braucht aber 2,13 Sekunden pro Seite in seiner gebatchten H100-Konfiguration (TP=2, C=8, doc2json), und Infinity-Parser2-Flash erreicht 86,0 bei 0,95 Sekunden pro Seite; chandra-ocr-2, der im eigenen Vergleich dieses Modells bei der Qualität mit 85,8 führt, läuft mit 0,38 Seiten pro Sekunde, und dots.mocr erreicht 83,9 bei 0,55. Die Token-Zahlen sind konkurrenzfähig, aber nicht die besten im Feld. PaddleOCR-VL-1.6 ist pro Seite schlanker mit 1.048, und Surya OCR 2 gibt mit 3.760 mehr Token pro Sekunde aus.

Spekulative Dekodierung macht günstige GPUs erst praktikabel. Auf einem NVIDIA L4 bei Batch-Size 1 hebt FastMTP die Eager-Mode-Dekodierung bei K=3 von 42,7 auf 83,1 Ausgabe-Token pro Sekunde – eine 1,95×-Beschleunigung bei einer Annahmequote von 57,6 %. Mit CUDA-Graphs liegt die Basis bereits bei 158,3 Token pro Sekunde, und K=1 ist mit 185,6 der beste Betriebspunkt für eine 1,17×-Steigerung. Diese L4-Zahlen wurden bei Batch-Size 1 auf anderer Hardware gemessen und sind nicht mit den A100-Durchsatz-Zahlen oben vergleichbar.

Verwenden Sie die Standardeinstellung mit dynamischer Auflösung für allgemeine Dokumente. Sie liegt den berichteten Scores zugrunde. Die Ausgabe ist Markdown, sodass Tabellen und Formeln bereits strukturiert ankommen und keinen separaten Nachverarbeitungs-Schritt brauchen. Das Modell ist für günstige GPUs ausgelegt. Eine L4 oder Vergleichbares genügt für die interaktive Analyse eines einzelnen Dokuments, und spekulative Dekodierung bringt den größten Zugewinn im Eager-Modus – aktivieren Sie dort K=3; mit CUDA-Graphs ist K=1 der beste Betriebspunkt. Weil die Prüfung gierig ist, ändert das Ein- oder Ausschalten der Spekulation den Durchsatz, aber nie den Text.

Am besten geeignet für die Massenerfassung von Dokumenten, für PDF-zu-Markdown-Pipelines, für gescannte und historische Archive und für jede Arbeitslast, bei der Seiten pro Sekunde pro Dollar wichtiger ist als der letzte Benchmark-Punkt. Kopf- und Fußzeilen werden verworfen statt transkribiert: Das Subset Hdr/Ftr ist ein Textabwesenheitstest, der das Auslassen belohnt, und das Modell erzielt dort 88,7 – laufende Kopfzeilen und Seitenzahlen erscheinen daher nicht in der Ausgabe. OldScans bleibt das schwächste Subset mit 42,6; stark beschädigte Scans erfordern daher weiterhin eine manuelle Prüfung.

Wenn Ihre Eingabe bereits abgerufenes HTML ist, ist ReaderLM-v2 das günstigere Werkzeug für dasselbe Markdown-Ziel. Für die visuelle Fragebeantwortung auf einer Seite statt Transkription verwenden Sie jina-vlm. Für Retrieval über die geparste Ausgabe kombinieren Sie sie mit jina-embeddings-v4.