Surya2 vs Unlimited-OCR vs PaddleOCR-VL:
Receipt-VLM-Benchmark (2026)

Alle drei Engines sind Dokument-Parsing-VLMs (Vision-Language-Modelle): neuronale Modelle, die ein gesamtes Dokumentbild lesen und verstandenen Text ausgeben — in Kleinschreibung normalisiert, Label/Wert-Paare zu einzelnen Zeilen zusammengeführt, Zeilen nach Lesereihenfolge sortiert — statt der rohen Zeichenströme mit ursprünglicher Groß-/Kleinschreibung, die traditionelle OCR-Engines (Tesseract, PaddleOCR, EasyOCR, docTR — die anderen Engines im zugrunde liegenden Lauf) zurückgeben. Diese Ausgabekonvention ist der Grund, warum ihre Feldextraktionswerte von Haus aus stark sind und ihre rohen Zeichenfehlerwerte irreführend wirken, wie der nächste Abschnitt zeigt. Innerhalb der VLM-Familie unterscheiden sich die drei deutlich in Größe und Trainingsziel: Surya2 ist ein 650M-Parameter-Modell mit Textfokus, optimiert für saubere Ganzseiten-Transkription (90+ Sprachen); PaddleOCR-VL ist ein kompakter 0.9B-Allrounder, gebaut für Breite über Sprachen, Tabellen und Formeln hinweg; Unlimited-OCR ist auf Langdokument- und Batch-Parsing ausgerichtet (das einseitige Lesen von Dokumenten mit 40+ Seiten ist sein beworbenes Kernmerkmal). Eine wichtige Einschränkung gilt für jede CER-Zahl unten: Character Error Rate (CER) zählt Einfügungen, Löschungen und Ersetzungen gegenüber den Ground-Truth-Zeichen und bestraft damit genau die Normalisierungen, die VLMs zu leisten trainieren. Feldbezogenes F1 ist der fairere VLM-übergreifende Maßstab und das Rückgrat dieser Seite.

Warum CER für VLMs nicht geeignet ist: Die 3,4×-Spreizung ist Ausgabekonvention, nicht Lesefähigkeit

Liest man nur die rohe CER-Spalte, wirkt Unlimited-OCR wie ein gescheitertes Modell (0,6552 auf SROIE), während Surya2 erstklassig aussieht (0,1915, gleichauf mit dem traditionellen docTR’s 0,1971 für das beste rohe CER im 8-Engine-Lauf). Beide Lesarten sind Artefakte des Ausgabestils. Derselbe Unlimited-OCR-Text, der 0,6552 CER erzielt, erreicht 0,4779 WER — seine Wörter überleben, während seine Zeichen verstümmelt wirken, weil die Kleinschreibungs-Normalisierung Zeichen ersetzt, ohne Wörter zu brechen. PaddleOCR-VLs Zahlen kehren das Muster um: Sein CORD-CER von 1,0805 ist das schlechteste aller 8 Engines, während sein CORD-Feld-F1 von 0,3412 das beste aller 8 ist — die eigene CSV des Benchmarks widerspricht der CER-Rangfolge.

Der Mechanismus hat zwei Ebenen. Ebene 1 — Normalisierungssteuer: Dokument-Parsing-VLMs geben “verstandenen” Text aus — TAN CHAY YEE wird zu tan chay yee, INVOICE NO : PEGIV führt ein Label und einen Wert zu einer Zeile zusammen. CER ist exakter Zeichenabgleich, daher wird jede gefaltete Groß-/Kleinschreibung und jede zusammengeführte Zeile als Fehler gewertet, selbst wenn der Feldwert korrekt ist. Die Fehlerzerlegungsanalyse des Benchmarks der veröffentlichten SROIE-Vorhersagen führt etwa ein Fünftel des rohen CER-Budgets auf Groß-/Kleinschreibungs-Ersetzungen und etwa ein Zehntel auf Zeilenzusammenführungen/-verluste zurück; die drei Engines zahlen diese Steuer in unterschiedlichem Maße — Unlimited-OCRs starke Faltung bläht sein CER weit über sein WER hinaus, während PaddleOCR-VLs Zeilen-/Label-Zusammenführung sein WER (0,6462) über sein eigenes CER (0,3370) treibt. Ebene 2 — Ground-Truth-Strukturinflation auf CORD: Der CORD-Ground-Truth-Text enthält Annotationsstruktur (Menüeinträge, Koordinaten, Feldlabels), sodass CER für jede Engine systematisch aufgebläht wird, zusätzlich zur echten Sprachdiskrepanz — das CORD-CER-Cluster über alle Engines von 0,90–1,08 (traditionelles Tesseract 0,9523, docTR 0,9101, und jedes VLM eingeschlossen) bestätigt, dass die Inflation korpusweit ist, nicht modellspezifisch.

Tabelle: summary_metrics.csv — cer- und wer-Spalten, sroie_2019-Zeilen. Exakte Werte: Surya2 cer 0.19147 / wer 0.27352; Unlimited-OCR cer 0.65524 / wer 0.47788; PaddleOCR-VL cer 0.33696 / wer 0.64623. Niedriger ist besser; alle drei Läufe wurden mit error_rate 0.0 abgeschlossen. VLMs nicht anhand der CER einstufen: Die CER/WER-Divergenz von Unlimited-OCR (0.6552 vs. 0.4779) und die CORD-CER-vs-Feld-F1-Inversion von PaddleOCR-VL (siehe unten) sind Artefakte der Ausgabekonventionen, wie sie das Protokoll dieses Benchmarks für VLM-Zeilen genau kennzeichnet.

Die Konsequenz aus Ebene 1 und 2 ist, dass jeder verbleibende Abschnitt dieser Seite die drei VLMs anhand der Feld-Extraktions-F1 (der Metriken, die ihre strukturierte Ausgabe direkt speist) und anhand der Betriebsgrenzen (Latenz, Durchsatz, Kosten) vergleicht — und CER nur zusammen mit seinen Einschränkungen zitiert. Dies ist die Protokollregel des Benchmarks für Dokument-Parsing-VLM-Zeilen und die richtige Perspektive: Eine Beleg-Pipeline konsumiert Felder (Firma, Datum, Adresse, Gesamtsumme), keine Zeichenströme.

Out-of-Box-Feldextraktion: Strukturierte Ausgabe ist das Markenzeichen der VLM-Familie

Wenn man den Rohtext jeder Engine durch dieselben festen Regex-Muster auf die vier SROIE-Belegfelder (Firma, Datum, Adresse, Gesamtbetrag) laufen lässt — der traditionelle OCR- und regelbasierte Ansatz zur Schlüsselinformationsextraktion (KIE) — landen die drei VLMs innerhalb einer 0,02-Punkte-Bandbreite: Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368, Surya2 0,3183. Alle drei rangieren unter den ersten vier des Acht-Engine-Laufs; zwei davon übertreffen die beste traditionelle Engine (PaddleOCR mit 0,3254), die dritte liegt 0,007 Punkte dahinter. Ihr „verstandener Text“ erreicht die Feldkonsumenten auch ohne LLM-Nachbearbeitung — das Familienmerkmal, das Rohtext-OCR-Engines nicht besitzen.

Der Feldwert-F1 ist das harmonische Mittel aus Präzision und Recall über die extrahierten Feldwerte im Vergleich zur Ground Truth: 1,0 bedeutet, dass jedes Belegfeld perfekt wiederhergestellt wurde, 0 bedeutet nichts. Der Mechanismus hinter dem Vorsprung der VLM-Familie ist die oben beschriebene Ausgabeform — derselbe case-folded, labelstrukturierte Text, der die CER erhöht, passt zufällig zu den Extraktionsmustern. Die Spalten „Regex-Feldextraktion“ sind die postprocessed_sroie_receipt_regex_*-Metriken des Benchmarks: Sie messen OCR-Text plus nachgelagerte regelbasierte Extraktion, nicht native strukturierte Ausgabe, und dasselbe Musterset wurde auf jede Engine angewendet. Zum Vergleich: Der Regex-Feld-F1 der traditionellen Engines liegt bei 0,0766 (docTR), 0,1477 (EasyOCR), 0,2237 (Docling) und 0,2335 (Tesseract) — sechs der sieben Nicht-VLM-Engines liegen unter dem schwächsten Mitglied des Trios.

Quelle: field_method_comparison.csv — Spalten regex_field_value_f1 / llm_field_value_f1, Zeilen sroie_2019 (gespeicherte Dezimalzahlen 0–1 als % angezeigt). LLM-Nachbearbeitung: deepseek-v4-flash (Spalte llm_model). 361 Stichproben pro Engine (llm_ok_count).

Tabelle: field_method_comparison.csv — Regex-Spalten, sroie_2019-Zeilen. Dies sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet werden (nachbearbeitet, nicht native Extraktion). Surya2s 0.3183 ist der niedrigste Wert des Trios, belegt aber dennoch den vierten Platz von acht Engines und liegt 0.007 unter der besten traditionellen Engine (PaddleOCR 0.3254, summary_metrics.csv field_f1_regex, paddleocr/sroie_2019-Zeile).

Der LLM-Hebel: Die drei Engines konvergieren

Füttert man den OCR-Text aller drei Engines einem LLM-Nachbearbeitungsschritt (deepseek-v4-flash, Temperatur 0) mit einem strukturierten Extraktions-Prompt zu, verengt sich die Bandbreite ohne Nachbearbeitung zu einem nahezu Gleichstand: Surya2 0.6139, Unlimited-OCR 0.6054, PaddleOCR-VL 0.5921 — eine Spreizung von 0,022 Punkten, vollständig innerhalb des Konvergenzbands von 0,57–0,62 des Benchmarks für gesunde Engines. Der Nachbearbeitungsschritt, nicht das VLM (Vision-Language-Model), wird zur entscheidenden Komponente.

Dies ist dasselbe Konvergenzmuster, das der vollständige Lauf mit 8 Engines aufweist: Ein LLM versteht Semantik (Zahlen, Daten, Namen), anstatt Zeichenformen abzugleichen, und absorbiert dadurch die meisten Unterschiede in der Qualität des vorgelagerten Texts — solange der Text lesbar genug ist, um darauf aufzubauen. Alle drei VLMs erfüllen die Voraussetzungen; alle drei liegen innerhalb des Bands. Der Hebel hat seinen Preis: Ein LLM-Aufruf fügt pro Dokument zusätzlich zur OCR-Zeit eine mediane Latenz von etwa 1,9–2,3 s hinzu (1.946,7 ms für den Text von PaddleOCR-VL, 1.982,0 ms für den von Unlimited-OCR, 2.261,7 ms für den von Surya2 — durch die API verursacht und in ihrer Art identisch), was eine asynchrone Batch-Verarbeitung gegenüber synchronen Wartezeiten pro Seite begünstigt. Die Exaktheit auf Dokumentebene — der Anteil der Belege, bei denen alle vier Felder übereinstimmten — bleibt bei allen drei niedrig (0,1219–0,1551), eine Erinnerung daran, dass der F1-Wert pro Feld die aussagekräftige operative Kennzahl ist.

Tabelle: field_method_comparison.csv — llm_*-Spalten, sroie_2019-Zeilen. LLM-Modell: deepseek-v4-flash bei Temperatur 0 (Spalte llm_model). Die LLM-Latenz wird durch die API verursacht und ist getrennt von der Engine-Latenz (summary_metrics.csv latency_p50_ms).

CORD (indonesische Belege): Der kompakte Generalist gewinnt

CORD v2 (100 indonesische Belege, verschachtelte Felder menu/sub_total/total) ist der sprachübergreifende Stresstest des Benchmarks — und hier trennen sich die drei VLM (Vision-Language-Model) wirklich. Mit denselben englischen Regex-Mustern extrahiert PaddleOCR-VL indonesische Belegfelder mit 0,3412 Feld-F1 — der höchste Wert aller 8 Engines im gesamten Benchmark — während Surya2 0,2458 erreicht und Unlimited-OCR auf 0,1079 fällt. Die Trainingsbreite des kompakten Generalisten zeigt genau, wo die textzentrierten und Langdokument-Modelle Boden verlieren.

Alle CORD-CER-Werte werden vom Benchmark-Protokoll isoliert und niemals in ein SROIE-Ranking eingemischt: Die Ground Truth von CORD enthält Annotationsstrukturen (was den rohen CER für jede Engine zusätzlich zur echten Sprachdiskrepanz erhöht — der CORD-CER-Cluster aller Engines liegt bei 0,90–1,08), und die Regex-Muster wurden für englische Formate geschrieben. Der CORD-Vergleich unten umfasst nur Feldmetriken. Mit einem LLM-Postprozessor wird der Sprachschock absorbiert, wie bei SROIE: Das Trio konvergiert wieder auf 0,4678–0,5203 Feld-F1 (Surya2 0,5203, PaddleOCR-VL 0,5198, Unlimited-OCR 0,4678) — der Postprozessor, nicht die Engine, leistet die sprachübergreifende Hauptarbeit.

Quelle: summary_metrics.csv — Spalte field_f1_regex, Zeilen cord_v2 (gespeicherte Dezimalzahlen 0–1 als % angezeigt). PaddleOCR-VL 0,3412 ist das Maximum von field_f1_regex über alle 16 Zeilen der Datei; der zweitbeste CORD-Regex-Wert ist Surya2 0,2458.

Tabelle: summary_metrics.csv (field_f1_regex / cer) und field_method_comparison.csv (llm_field_value_f1), cord_v2-Zeilen. CORD-Zahlen nicht in ein SROIE-Ranking einmischen: Der CORD-CER kombiniert echte Sprachabweichungen mit einer durch Annotationsstruktur bedingten Inflation in der Ground Truth (alle Engines gruppieren sich bei 0,90–1,08 — einschließlich traditionellem Tesseract 0,9523 und docTR 0,9101); PaddleOCR-VLs CER von 1,0805 ist der höchste der 8 Engines, gerade weil seine saubere, normalisierte Ausgabe am weitesten von CORDs strukturlastiger Ground Truth entfernt ist — während sein Regex-Feld-F1 das beste des Benchmarks ist.

Die Betriebshüllkurve: 3,8× Latenz, 5,2× Kosten

Die Feldgenauigkeit konvergiert, die Betriebskosten nicht. Auf derselben RTX 4090 zum gleichen aufgezeichneten Satz von $0,76/Std. erreicht PaddleOCR-VL 68,2 Seiten/Min. bei 694,3 ms p50 pro Seite für $0,205 pro 1.000 Seiten; Unlimited-OCR liegt in der Mitte der Hüllkurve mit 34,4 Seiten/Min., 1.600,7 ms p50, $0,388 pro 1.000 Seiten; Surya2 ist der Preis- und Latenz-Ausreißer mit 12,1 Seiten/Min., 2.668,0 ms p50, $1,061 pro 1.000 Seiten. Der schnellste VLM ist 3,8× schneller und 5,2× günstiger als der langsamste auf identischer Hardware.

Die Kosten werden berechnet als Wanduhr-Laufzeit × der RunPod-RTX-4090-Satz ($0,76/Stunde, Preis in den Lauf-Manifesten zeitgestempelt), einschließlich Modellinitialisierung — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden. Der Durchsatz ist die Wanduhr-Seitenzahl pro Minute, einschließlich derselben Initialisierung. Die Latenz p50/p95 sind stationäre Inferenzzeiten pro Seite im Warmzustand, gemessen und bewertet (Modellladen ausgeschlossen); Surya2s Schwanz ist proportional schlechter — 5.872,2 ms p95 gegenüber PaddleOCR-VLs 1.154,3 ms — weil VLM-Prefill/Decode-Spitzen den Schwanz bei den ersten Seiten dominieren. Zwei Zahlen, die Sie zusammen statt gegeneinander lesen sollten: PaddleOCR-VL hat das niedrigste p50, wird aber beim Wanduhr-Durchsatz von Unlimited-OCR auf CORD übertroffen (73,99 vs. 67,13 Seiten/Min.) — Wanduhr-Zahlen enthalten die Modellinitialisierung, und Unlimited-OCRs vLLM-Batchverarbeitung ist effizient genug, um die Reihenfolge dort umzudrehen.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, sroie_2019-Zeilen. Surya2 2667,9800, Unlimited-OCR 1600,7459, PaddleOCR-VL 694,2519. Stationäre Latenz (Messmodus warm_then_scored).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. Surya2 1,0609, Unlimited-OCR 0,3879, PaddleOCR-VL 0,2048. Kosten = Wanduhr-Laufzeit × 0,76 $/Std. inklusive Modellinitialisierung, Preis mit Zeitstempel in den Ausführungsmanifesten (August 2026).

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, Zeilen sroie_2019. Alle drei Engines auf GPU (RTX 4090, Preis 0,76 $/Std. mit Zeitstempel in den Manifesten); Kosten inklusive Modellinitialisierung, nicht reiner Steady-State-Durchsatz. Exakte Werte: Surya2 p50 2668,0 / p95 5872,2 / 12,1 Seiten/Min. / $1,0609; Unlimited-OCR p50 1600,7 / p95 2521,9 / 34,4 Seiten/Min. / $0,3879; PaddleOCR-VL p50 694,3 / p95 1154,3 / 68,2 Seiten/Min. / $0,2048.

Wer gewinnt wann: Die Übersichtstabelle

“Besser” hängt vom Arbeitsaufkommen ab, und bei diesen drei VLMs trennen sich die Achsen klar: Die Feldgenauigkeit konvergiert (Regex und LLM), roher Zeichentext bevorzugt Surya2, sprachübergreifende Felder bevorzugen PaddleOCR-VL, und jede Kosten-/Latenz-/Durchsatzachse bevorzugt PaddleOCR-VL mit Unlimited-OCR in der Mitte. Die ehrliche Schlussfolgerung ist, dass bei Belegen mit einem beliebigen Postprozessor in der Pipeline die Wahl des VLM kaum eine Rolle spielt — und ohne einen solchen schlägt der günstige kompakte Generalist die teuren Spezialisten auf den Achsen, die normalerweise zählen.

Häufig gestellte Fragen

Welcher Dokument-Parsing-VLM ist bei Belegen am genauesten?

Bei der Feldextraktion ist es bei englischen Belegen ein Dreier-Kopf-an-Kopf-Rennen: SROIE-Regex-Feld-F1 0.3183–0.3376 und LLM-Feld-F1 0.5921–0.6139 über Surya2, Unlimited-OCR und PaddleOCR-VL (field_method_comparison.csv, sroie_2019-Zeilen). Bei indonesischen Belegen ändert sich die Antwort: PaddleOCR-VLs CORD-Regex-Feld-F1 von 0.3412 ist der beste aller 8 Engines im Benchmark (summary_metrics.csv, field_f1_regex, cord_v2-Zeilen). Rohes CER sollte nicht zur Bewertung von VLMs verwendet werden — es zählt Ausgabekonventionen (Kleinschreibung, Zeilenverbindung) als Fehler (siehe Abschnitt “Warum CER nicht verwenden” oben).

Warum hat Unlimited-OCR das schlechteste CER, aber das beste Regex-Feld-F1 bei SROIE?

Weil die beiden Metriken unterschiedliche Ausgaben bewerten. Unlimited-OCRs starke Kleinschreibung erhöht die Zeichenfehler — sein CER von 0.6552 gegenüber WER von 0.4779 ist der Hinweis — während derselbe normalisierte Text zufällig besser zu den festen Extraktionsmustern passt als bei jeder anderen Engine: SROIE-Regex-Feld-F1 0.3376, der Spitzenwert des 8-Engine-Laufs (summary_metrics.csv cer / wer, field_method_comparison.csv regex_field_value_f1, sroie_2019-Zeilen).

Warum ist PaddleOCR-VLs CORD-CER das schlechteste im Benchmark, während sein CORD-Feld-F1 das beste ist?

Weil CORDs Ground Truth die Annotationsstruktur einbettet und PaddleOCR-VLs Ausgabe die sauberste und am stärksten normalisierte ist — am weitesten von diesem strukturbehafteten Text entfernt, daher ist seine Editierdistanz am größten (CER 1.0805). Derselbe Ausgabestil speist die Extraktionsmuster gut: CORD-Regex-Feld-F1 0.3412, der beste aller 8 Engines (summary_metrics.csv, cer / field_f1_regex, cord_v2-Zeilen). Diese Umkehrung ist die eigene Demonstration des Benchmarks, dass CORD-CER keine Qualitätsmessung pro Modell ist.

Wie viel schneller und günstiger ist PaddleOCR-VL als Surya2?

3,8× geringere p50-Latenz (694,3 ms gegenüber 2.668,0 ms), 5,6× höherer Durchsatz (68,2 gegenüber 12,1 Seiten/min) und 5,2× geringere Kosten pro 1.000 Seiten (0,205 $ gegenüber 1,061 $) auf derselben RTX 4090 bei 0,76 $/Std. (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, sroie_2019-Zeilen).

Macht ein LLM-Nachbearbeitungsschritt die drei VLMs gleichwertig?

Fast — 0,5921 bis 0,6139 LLM-Feld-F1 auf SROIE, eine Spanne von 0,022 Punkten innerhalb des Konvergenzbands von 0,57–0,62 der Benchmark (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen). Die Kosten dieser Konvergenz liegen bei etwa 1,9–2,3 s zusätzlicher medianer LLM-Latenz pro Dokument (llm_median_latency_ms, gleiche Zeilen), was für asynchrone Stapelverarbeitung spricht.

Welches der drei VLMs sollte eine Belegverarbeitungspipeline wählen?

Das hängt von der Achse ab, die Ihre Pipeline nutzt. Für native sprachübergreifende Felder ohne Nachbearbeitung ist PaddleOCR-VLs CORD-Regex-F1 (0,3412) das einzige gemessene nutzbare Niveau. Für günstigste und schnellste VLM-Bereitstellung ebenfalls PaddleOCR-VL (694,3 ms, 0,205 $/1.000 Seiten). Für sauberen rohen englischen Text, wenn Kosten und Latenz keine Rolle spielen, ist Surya2s CER (0,1915) am stärksten. Für einen ausgewogenen Punkt bei mittlerem Volumen Unlimited-OCR (1.600,7 ms, 0,388 $/1.000 Seiten, bestes SROIE-Feld-F1 ohne Anpassung). Mit einem LLM-Nachbearbeitungsschritt in der Pipeline spielt die Wahl bei Belegen kaum eine Rolle — alle drei liegen im Konvergenzband. Diese Ergebnisse gelten für englische und indonesische Belege auf einer GPU-Stufe im August 2026; jede Produktionsentscheidung sollte auf dem Zielkorpus erneut getestet werden (siehe Einschränkungen).

Woher stammen die Zahlen auf dieser Seite?

Jede Kennzahl ist eine Zeile der veröffentlichten CSVs des First-Party-Benchmarks — results/summary_metrics.csv (CER/WER, Feld-F1, Latenz, Kosten, Durchsatz) und results/field_method_comparison.csv (Regex- vs. LLM-Nachbearbeitung, llm_model = deepseek-v4-flash) — gehostet unter ImageToTableai/benchmark-ocr, mit einem redigierten manifest.json pro Lauf für Umgebungs-Fingerprints. Die Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Publikationen.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen dreifachen Ausschnitt eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Übersicht über Drittanbieter-Behauptungen und keine Anbietervergleichsseite. Nur feste Test-Splits: SROIE-2019-Test (361 englische Belege, flache Felder company/date/address/total) und CORD-v2-Test (100 indonesische Belege, verschachtelte Felder menu/sub_total/total); Trainings-Splits wurden nie ausgewertet. Alle drei Engines sahen dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Aufwärmdurchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzzahlen im stationären Zustand liegen). Alle drei Läufe wurden mit error_rate 0.0 abgeschlossen (Spalte error_rate in summary_metrics.csv). Der zugrunde liegende Lauf enthält insgesamt acht Engines; diese Seite vergleicht nur die drei genannten VLMs, und die vollständigen Ergebnisse der 8 Engines werden separat unter Traditional OCR vs Document Parsing VLMs veröffentlicht.

Laufzeitumgebung

• Hardware: Alle drei Engines liefen auf derselben NVIDIA RTX 4090 (24 GB); GPU-Kosten berechnet zum RunPod-On-Demand-Satz von $0,76/Std., Preis mit Zeitstempel in jedem redigierten Manifest des Laufs (August 2026).
• Engines: Standardkonfiguration, ohne Feintuning. Versionen festgelegt: Surya2 (surya-ocr 0.22.1) und PaddleOCR-VL 1.6, beide vLLM-basiert; Unlimited-OCR vLLM-basiert ohne öffentlich festgelegte Version (siehe Einschränkungen) — gemäß der Modelltabelle des öffentlichen Repos (README.md) und der Lauf-Manifeste.
• LLM-Nachbearbeitung: deepseek-v4-flash über API bei Temperatur 0 für deterministische Ausgabe (die Spalte llm_model in field_method_comparison.csv); es war das einzige Modell, das für alle LLM-Feldzeilen bei allen drei Engines verwendet wurde.
• Kostenbasis: Wanduhr-Laufzeit × $0,76/Std., einschließlich Modellinitialisierung — Batch-Verarbeitung senkt die Kosten pro Seite.
• Feldnachbearbeitung: Die SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (Spalten regex_* in field_method_comparison.csv) — Felder, die aus OCR-Text durch einen festen Mustersatz extrahiert werden. Sie messen OCR + nachgelagerte Extraktion, nicht native strukturierte Ausgabe eines Modells; die Spalten LLM_* messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden nie vermischt.

Definitionen der Metriken

• CER (Character Error Rate): Editierdistanz (Einfügungen + Löschungen + Ersetzungen) zwischen OCR-Text und Ground Truth, geteilt durch die Anzahl der Ground-Truth-Zeichen. Niedriger ist besser. Ungünstig für Dokument-Parsing-VLMs: Es wertet Groß-/Kleinschreibung, Zusammenführung von Label/Wert und Zeilenumbrüche als Fehler, selbst wenn die Feldwerte korrekt sind. Auf dieser Seite wird es nur zusammen mit seinen Einschränkungen angegeben.
• WER (Word Error Rate): dieselbe Editierdistanz-Berechnung auf Wortebene. Wo CER und WER stark voneinander abweichen (Unlimited-OCR: 0,6552 vs. 0,4779), markiert die Lücke, wo die Ausgabenormalisierung – nicht das Fehllesen – den Schaden verursacht.
• Feldwert-F1 (Regex): harmonisches Mittel aus Präzision und Recall über extrahierte Feldwerte unter Verwendung fester Regex-Muster auf OCR-Text (traditionelle OCR + regelbasierte KIE-Pipeline). Spalte: regex_field_value_f1. Ein Wert von 0 bedeutet, dass keine Feldwerte wiederhergestellt wurden.
• Feldwert-F1 (LLM): dieselbe Metrik auf der Ausgabe des LLM-Nachbearbeiters (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie vermischt.
• Dokumentfelder exakt: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten – eine viel strengere Messlatte als das F1 pro Feld.
• Latenz p50/p95 & Seiten/min: Inferenzzeit pro Seite im stationären Zustand (warm, dann bewertet, ohne Modellladen) und Wanduhr-Durchsatz einschließlich Modellinitialisierung.
• Kosten pro 1.000 Seiten: abgerechnete GPU-Stunden für 1.000 Seiten zum aufgezeichneten Satz von 0,76 $/Std.

Quellenliste

1. summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Modelle × 2 Datensätze. Spalten: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Jede CER/WER-, Latenz-, Kosten- und Durchsatzzahl auf dieser Seite stammt aus den Zeilen surya2, unlimited_ocr und paddleocr_vl_vllm hier.
2. field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), regex/llm-Feldwert-Genauigkeit und F1, document-fields-exact, llm_median_latency_ms, Token-Anzahl. Jede Regex/LLM-Feld-F1-Zahl stammt aus den drei benannten Engine-Zeilen hier.
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository, das die Ergebnis-CSVs, redigierte Lauf-Manifeste, das eingefrorene Protokoll und Datensatz-Stichprobenlisten (feste Test-Splits) zur Reproduktion hostet.
4. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit Modellversionen, GPU/Treiber, torch/CUDA/Python-Versionen, Kostenmetadaten mit Preiszeitstempel und Artefakt-Hashes.
5. Huang et al., „ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction“ (2019). SROIE-2019-Datensatzdefinition, Aufgabenstruktur und Lizenz (CC-BY-4.0).
6. Park et al., „CORD: A Consolidated Receipt Dataset for Post-OCR Parsing“ (2020). CORD-v2-Datensatzdefinition, verschachteltes Feldschema und Lizenz (CC-BY-4.0).

Einschränkungen

• Die CER-Ungerechtigkeit gegenüber VLMs ist der Grund, warum diese Seite auf Feldmetriken basiert: Dokument-Parsing-VLMs falten Groß-/Kleinschreibung, fassen Label-/Wertzeilen zusammen und ordnen Text neu, sodass rohe CER-Werte Ausgabekonventionen als Fehler werten — die CER-Divergenz von Unlimited-OCR (0,6552) gegenüber WER (0,4779) und die CORD-Inversion von PaddleOCR-VL (schlechtester CER 1,0805, bestes Feld-F1 0,3412) sind beide Artefakte dieser Bestrafung. Jeder Vergleich, der VLMs anhand von CER bewertet — auch auf dieser Seite — sollte als Maß für den Ausgabestil betrachtet werden, nicht für die Lesefähigkeit.
• Dokumentumfang — nur Belege: SROIE + CORD. Nichts hier misst die Layout-/Tabellen-/Formel-/Langdokument-Verarbeitung, bei der Dokument-Parsing-VLMs ihre größten Vorteile beanspruchen; alle beworbenen Stärken der drei Engines (einschließlich Unlimited-OCRs 40+ Seiten umfassender Einzeldurchlauf-Parsing) sind nicht gemessen. Verwenden Sie diese Seite nicht, um zu schlussfolgern: „VLM X gewinnt bei allem.“
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von ein paar Hundertstel (einschließlich der 0,022-Punkte-LLM-F1-Spanne) sollten als Rauschen behandelt werden, nicht als technische Wahrheit.
• Einzelne GPU-Stufe und einzelner Preis: Alle Zahlen stammen von einer RTX 4090 bei 0,76 $/Std., Preisstand August 2026 in den Lauf-Manifesten. Andere GPUs, Multi-GPU-Serving, Batch-Scheduling oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie Kosten zu aktuellen Tarifen neu ab, bevor Sie budgetieren.
• Einzelner LLM-Nachbearbeiter: Alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt das absolute Feld-F1; die Konvergenzreihenfolge kann sich an den Rändern bewegen. LLM-Latenz (~1,9–2,3 s Median, field_method_comparison.csv llm_median_latency_ms) entsteht durch die API und ist nicht Teil der Latenz einer Engine selbst.
• CORD-Quarantäne: Die CORD-Grundwahrheit enthält Annotationsstruktur, und die Regex-Muster wurden für englische Formate geschrieben; CORD-CER (0,90–1,08 über alle Engines) spiegelt Sprachmismatch + Grundwahrheits-Inflation wider, nicht die Qualität pro Modell. CORD-Zeilen werden mit Rahmen zitiert und niemals in ein SROIE-Ranking gemischt (Protokollregel).
• Versions-Pinning: Die Ergebnisse gelten für Surya2 0.22.1, PaddleOCR-VL 1.6 und Unlimited-OCR vLLM-betrieben (August 2026). Unlimited-OCR hat keine öffentlich gepinnte Versionsnummer in der veröffentlichten Modelltabelle des Benchmarks, daher kann seine Zeile nicht einer genauen Version zugeordnet werden; neuere Versionen einer Engine können jede Zahl auf dieser Seite verschieben.
• Regex-Abstimmung: Das Musterset wurde einmal pro Datensatz geschrieben. Eine pro Format stark abgestimmte Musterbibliothek könnte bei eigenen Layouts höher punkten — zu den Wartungskosten, die das LLM entfernt.

Verwandte Referenzen: docTR vs Surya2 Beleg-Benchmark · Traditionelle OCR vs. Dokument-Parsing-VLMs · welche Extraktionsmethode bei unübersichtlichen Layouts gewinnt · feldbasierte Bewertung vs. zeichenbasierte Bewertung · Beleg-OCR-Genauigkeit

Weiterführende Lektüre: KI-OCR im Vergleich zur herkömmlichen OCR · Bilddatenextraktion vs. OCR-Engines · Preise für KI-Dokumentextraktion (2026)