jina-ocr-v1

jina-ocr-v1 wandelt eine Seite in einem Durchgang in Markdown um: Text, Formeln, Tabellen und Leseordnung zusammen. Den Unterschied macht, wo die Ingenieursleistung hing. Die Analysequalität ist ein gesättigtes Feld, also greift das Modell den Teil an, der in der Produktion wirklich Geld kostet – das Dekodieren. OCR-Ausgaben sind lokal vorhersagbar, daher entwirft das Modell drei Token im Voraus 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 bis zu 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, einen 16x-konvolutionellen Kompressor und danach eine 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 Instruktion-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. chandra-ocr-2 führt bei der Qualität mit 85,8, läuft aber nur 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 emittiert mehr Token pro Sekunde mit 3.760.

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 zielt auf GPUs mit kleinem Budget. Eine L4 oder Vergleichbares genügt für die interaktive Analyse eines einzelnen Dokuments, und spekulative Dekodierung bringt den größten Zugewinn im Eager-Mode – aktivieren Sie dort K=3 und K=1, wenn Sie mit CUDA-Graphs arbeiten. 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 Massen-Aufnahme von Dokumenten, PDF-zu-Markdown-Pipelines, gescannte und historische Archive und jede Arbeitslast, bei der Seiten pro Sekunde pro Dollar wichtiger ist als der letzte Benchmark-Punkt. Kopf- und Fußzeilen werden transkribiert statt verworfen – das ist für die Archivalqualität das gewünschte Verhalten, schneidet aber in Tests auf Textabwesenheit schlecht ab. 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.