Surya2 vs Unlimited-OCR vs PaddleOCR-VL:
VLM-Benchmark für Kassenbons (2026)

Alle drei Engines sind dokumentparsende Vision-Language-Modelle (VLMs): neuronale Modelle, die ein gesamtes Dokumentbild lesen und verstandenen Text ausgeben — fallunabhängig, Label/Wert-Paare in einzelne Zeilen zusammengefasst, Zeilen in Lesereihenfolge neu angeordnet — anstelle der rohen Zeichenströme mit Originalgroßschreibung, die traditionelle OCR-Engines (Tesseract, PaddleOCR, EasyOCR, docTR — die anderen Engines im zugrunde liegenden Durchlauf) zurückgeben. Diese Ausgabekonvention ist es, die ihre Feldextraktionszahlen von Anfang an stark macht und ihre rohen Zeichenfehlernahlen irreführend, wie der nächste Abschnitt zeigt. Innerhalb der VLM-Familie unterscheiden sich die drei stark in Größe und Trainingsziel: Surya2 ist ein 650-Millionen-Parameter, textzentriertes Modell, das für saubere ganzseitige Transkription (90+ Sprachen) abgestimmt ist; PaddleOCR-VL ist ein kompakter 0,9B-Allrounder, der für Breite über Sprachen, Tabellen und Formeln gebaut wurde; Unlimited-OCR ist auf Langdokument- und Batch-Parsing ausgerichtet (einzelablesung von 40+ Seitigen Dokumenten ist sein vermarkteter Kern). Ein wichtiger Vorbehalt 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, bestraft also genau die Normalisierungen, die VLMs durchführen sollen. Der Feld-F1-Wert ist der fairere VLM-übergreifende Maßstab und ist der Rückgrat dieser Seite.

Warum CER für VLMs nicht verwendet werden sollte: Die 3,4-fache Streuung ist Ausgabekonvention, nicht Lesefähigkeit

Liest man nur die rohe CER-Spalte, sieht Unlimited-OCR wie ein gescheitertes Modell aus (0,6552 auf SROIE), während Surya2 weltklasse wirkt (0,1915, gleichauf mit dem traditionellen docTR’s 0,1971 für die beste rohe CER im 8-Engine-Durchlauf). 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 verbogen wirken, weil Fallunabhängigkeit Zeichen ersetzt, ohne Wörter zu zerstören. PaddleOCR-VL’s Zahlen kehren das Muster um: Seine CORD CER von 1,0805 ist die schlechteste aller 8 Engines, während sein CORD-Feld-F1 von 0,3412 der beste aller 8 ist — die eigene CSV des Benchmarks widerspricht der CER-Rangfolge.

Der Mechanismus hat zwei Ebenen. Ebene 1 — Normalisierungssteuer: dokumentparsende VLMs geben “verstandenen” Text aus — TAN CHAY YEE wird zu tan chay yee, INVOICE NO : PEGIV fasst ein Label und einen Wert in eine Zeile zusammen. CER ist exakte Zeichenübereinstimmung, daher wird jede gefaltete Großschreibung und jede zusammengefasste Zeile als Fehler gewertet, selbst wenn der Feldwert korrekt ist. Die Fehlerzerlegungsanalyse des Benchmarks für die veröffentlichten SROIE-Vorhersagen schreibt ungefähr ein Fünftel des rohen CER-Budgets Fallumwandlungen und ungefähr ein Zehntel Zeilenzusammenfassungen/-auslassungen zu; die drei Engines zahlen diese Steuer mit unterschiedlichen Raten — Unlimited-OCR’s starke Fallunabhängigkeit bläht seine CER weit über ihre WER auf, während PaddleOCR-VL’s Zeilen-/Label-Zusammenfassung ihre WER (0,6462) über ihre eigene CER (0,3370) treibt. Ebene 2 — Ground-Truth-Struktur-Inflation bei CORD: CORD’s Ground-Truth-Text bettet Annotationsstruktur ein (Menüeinträge, Koordinaten, Feldlabels), daher ist die CER systematisch für jede Engine zusätzlich zur tatsächlichen Sprachdiskrepanz aufgebläht — der CORD-CER-Cluster aller Engines von 0,90–1,08 (traditionell Tesseract 0,9523, docTR 0,9101 und jedes VLM eingeschlossen) bestätigt, dass die Inflation corpusweit 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 Durchläufe wurden mit error_rate 0.0 abgeschlossen. VLMs nicht anhand von CER bewerten: Die CER/WER-Divergenz von Unlimited-OCR (0,6552 vs. 0,4779) und die CORD-CER-gegen-Feld-F1-Inversion von PaddleOCR-VL (siehe unten) sind Ausgabekonvention-Artefakte genau der Art, die das Protokoll dieses Benchmarks für VLM-Zeilen kennzeichnet.

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

Felder extrahieren wie aus dem Nichts: Strukturierte Ausgabe ist das Merkmal der VLM-Familie

Führen Sie den Rohtext jeder Engine durch dieselben festen Regex-Muster für die vier SROIE-Belegfelder (Unternehmen, Datum, Adresse, Gesamtbetrag) — der traditionelle OCR- und regelbasierte Ansatz zur Schlüsselinformationsextraktion (KIE) — und die drei VLM (Vision-Language-Model) landen innerhalb einer 0,02-Punkte-Bandbreite: Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368, Surya2 0,3183. Alle drei belegen unter den acht getesteten Engines die Top vier; zwei davon schlagen die beste traditionelle Engine (PaddleOCR mit 0,3254), und die dritte liegt nur 0,007 Punkte dahinter. Ihr „verstandener Text“ erreicht die Feldverbraucher sogar ohne jeden LLM-Nachbearbeiter — das Familienmerkmal, das reinen Zeichen-OCR-Engines fehlt.

Der F1-Wert für Feldwerte ist der harmonische Mittelwert von Precision und Recall über die extrahierten Feldwerte gegenüber dem Soll: 1,0 bedeutet, jedes Belegfeld wurde perfekt wiederhergestellt, 0 bedeutet nichts. Der Mechanismus hinter dem Vorsprung der VLM-Familie ist die oben beschriebene Ausgabeform — derselbe fallunabhängige, beschriftungsstrukturierte Text, der die CER (Character Error Rate) erhöht, passt zufällig auch zu den Extraktionsmustern. Die Spalten „Regex-Feldextraktion“ sind die Benchmarks-Metriken `postprocessed_sroie_receipt_regex_*`: Sie messen OCR-Text + nachgelagerte regelbasierte Extraktion, nicht native strukturierte Ausgabe, und dasselbe Muster-Set wurde für jede Engine angewendet. Zur Gegenüberstellung: Die F1-Werte für die Regex-Felder der traditionellen Engines liegen 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, sroie_2019-Zeilen (0–1 gespeicherte Dezimalzahlen als % angezeigt). LLM-Nachbearbeiter: 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 jedes Engines angewendet wurden (nachbearbeitet, nicht native Extraktion). Surya2s 0.3183 ist der niedrigste Wert des Trios, belegt aber immer noch den vierten Platz von acht Engines und liegt 0.007 unter dem besten traditionellen Engine (PaddleOCR 0.3254, summary_metrics.csv field_f1_regex, paddleocr/sroie_2019 row).

Der LLM-Hebel: Die drei Motoren konvergieren

Füttert man den OCR-Text aller drei Motoren einem LLM-Nachbearbeiter (deepseek-v4-flash, Temperatur 0) mit einem strukturierten Extraktionsprompt, verengt sich die anfängliche Bandbreite zu einem fast gleichauf: Surya2 0.6139, Unlimited-OCR 0.6054, PaddleOCR-VL 0.5921 — eine Differenz von 0,022 Punkten, vollständig innerhalb der Benchmark-Konvergenzbandbreite von 0,57–0,62 für gesunde Motoren. Der Nachbearbeiter, nicht das VLM, wird zur entscheidenden Komponente.

Dies ist dasselbe Konvergenzmuster, das der vollständige 8-Motor-Lauf zeigt: Ein LLM versteht Semantik (Zahlen, Daten, Namen) anstatt Zeichenformen abzugleichen und absorbiert so die meisten Unterschiede in der Qualität des vorgelagerten Textes — vorausgesetzt, der Text ist lesbar genug, um darauf aufzubauen. Alle drei VLMs erfüllen diese Bedingung; alle drei landen innerhalb der Bandbreite. Der Hebel hat einen Preis: Ein LLM-Aufruf fügt pro Dokument eine mittlere Latenz von etwa 1,9–2,3 s zur OCR-Zeit 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 — API-bedingt und in der Art identisch), was die asynchrone Stapelverarbeitung gegenüber dem synchronen Warten auf einzelne Seiten bevorzugt. Die exakte Übereinstimmung auf Dokumentebene — der Anteil der Belege, bei denen alle vier Felder übereinstimmten — bleibt für alle drei niedrig (0,1219–0,1551), eine Erinnerung daran, dass der F1-Wert pro Feld die bedeutende Kennzahl für den Betrieb 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 ist API-bedingt und getrennt von der Motorlatenz (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 mehrsprachige Stresstest des Benchmarks — und genau hier trennen sich die drei VLMs (Vision-Language-Model) wirklich. Mit denselben englischen Regex-Mustern extrahiert PaddleOCR-VL indonesische Belegfelder mit 0,3412 Feld-F1 — dem höchsten Wert aller 8 Engines im gesamten Benchmark — während Surya2 0,2458 erreicht und Unlimited-OCR auf 0,1079 absinkt. Die Breite der Trainingsdaten des kompakten Generalisten zeigt sich genau dort, wo die textzentrierten und Langdokument-Modelle verlieren.

Alle CORD-CER-Werte werden durch das Benchmark-Protokoll isoliert und nie in ein SROIE-Ranking einbezogen: CORDs Ground Truth enthält die Annotationsstruktur (was den Roh-CER für jeden Engine zusätzlich zur tatsächlichen Sprachdiskrepanz aufbläht — der CER-Cluster aller Engines liegt bei 0,90–1,08), und die Regex-Muster wurden für englische Formate geschrieben. Der CORD-Vergleich unten beschränkt sich daher auf Feldmetriken. Unter einem LLM-Nachbearbeiter wird der Sprachschock absorbiert, wie bei SROIE: Das Trio konvergiert erneut zu 0,4678–0,5203 Feld-F1 (Surya2 0,5203, PaddleOCR-VL 0,5198, Unlimited-OCR 0,4678) — der Nachbearbeiter, nicht der Engine, leistet die mehrsprachige Schwerstarbeit.

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

Tabelle: summary_metrics.csv (field_f1_regex / cer) und field_method_comparison.csv (llm_field_value_f1), cord_v2-Zeilen. Fügen Sie CORD-Zahlen nicht in irgendein SROIE-Ranking ein: Der CER von CORD kombiniert echte Sprachunterschiede mit einer Aufblähung der Annotationsstruktur im Ground Truth (alle Engines clustern bei 0,90–1,08 — traditionelles Tesseract 0,9523, docTR 0,9101 eingeschlossen); der CER von PaddleOCR-VL von 1,0805 ist der höchste der 8 Engines, genau weil seine saubere, normalisierte Ausgabe am weitesten von CORDs strukturlastigem Ground Truth entfernt ist — während sein Regex-Feld-F1 der beste des Benchmarks ist.

Der Betriebsbereich: 3,8× Latenz, 5,2× Kosten

Die Feldgenauigkeit konvergiert; die Betriebskosten nicht. Auf derselben RTX 4090 mit derselben erfassten Rate von 0,76 $/Stunde hält PaddleOCR-VL 68,2 Seiten/min bei 694,3 ms p50 pro Seite für 0,205 $ pro 1.000 Seiten; Unlimited-OCR liegt mittig im Betriebsbereich bei 34,4 Seiten/min, 1.600,7 ms p50, 0,388 $ pro 1.000 Seiten; Surya2 ist der Ausreißer bei Preis und Latenz mit 12,1 Seiten/min, 2.668,0 ms p50, 1,061 $ pro 1.000 Seiten. Das schnellste VLM (Vision-Language-Model) ist 3,8× schneller und 5,2× billiger als das langsamste auf identischer Hardware.

Die Kosten werden berechnet als Laufzeit in Echtzeit × die RunPod RTX 4090-Rate (0,76 $/Stunde, Preis mit Zeitstempel in den Ausführungsmanifesten), einschließlich Modellinitialisierung — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden. Der Durchsatz sind Echtzeit-Seiten pro Minute, einschließlich derselben Initialisierung. Die Latenz p50/p95 sind steady-state Inferenzzeiten pro Seite, gemessen warm-then-scored (Modellladen ausgeschlossen); der Schwanz von Surya2 ist proportional schlechter — 5.872,2 ms p95 gegenüber 1.154,3 ms von PaddleOCR-VL —, weil VLM-Prefill/Decode-Spitzen den Schwanz auf den ersten Seiten dominieren. Zwei Zahlen, die man zusammen und nicht gegeneinander lesen sollte: PaddleOCR-VL hat den niedrigsten p50, wird aber im Echtzeit-Durchsatz von Unlimited-OCR auf CORD übertroffen (73,99 vs. 67,13 Seiten/min) — Echtzeit-Zahlen schließen die Modellinitialisierung ein, und die vLLM-Batch-Verarbeitung von Unlimited-OCR ist effizient genug, um die Reihenfolge dort umzukehren.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, sroie_2019-Zeilen. Surya2 2667,9800, Unlimited-OCR 1600,7459, PaddleOCR-VL 694,2519. Steady-state-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 = Laufzeit in Echtzeit × $0.76/Stunde inkl. Modellinitialisierung, Preis mit Zeitstempel in 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, $0.76/Stunde, Preis mit Zeitstempel in Manifesten); Kosten inkl. Modellinitialisierung, nicht reiner stationärer 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 Zusammenfassungstabelle

„Besser“ hängt von der Arbeitslast ab, und bei diesen drei VLMs trennen sich die Achsen klar: Die Genauigkeit bei Feldern konvergiert (Regex und LLM), der rohe Zeichentext bevorzugt Surya2, mehrsprachige Felder bevorzugen PaddleOCR-VL, und jede Kosten-/Latenz-/Durchsatz-Achse bevorzugt PaddleOCR-VL mit Unlimited-OCR in der Mitte. Die ehrliche Erkenntnis ist, dass bei Belegen mit jedem Nachbearbeiter in der Pipeline die Wahl des VLM wenig ausmacht — 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

Welches VLM (Vision-Language-Model) für die Dokumentenanalyse ist bei Quittungen am genauesten?

Bei der Feldextraktion gibt es bei englischen Quittungen ein Dreier-Rennen: SROIE-Regex-Feld-F1 von 0,3183–0,3376 und LLM-Feld-F1 von 0,5921–0,6139 für Surya2, Unlimited-OCR und PaddleOCR-VL (field_method_comparison.csv, sroie_2019-Zeilen). Bei indonesischen Quittungen ändert sich die Antwort: PaddleOCR-VL’s CORD-Regex-Feld-F1 von 0,3412 ist der beste Wert aller 8 Engines im Benchmark (summary_metrics.csv, field_f1_regex, cord_v2-Zeilen). Der rohe CER sollte nicht zum Ranking von VLMs verwendet werden — er zählt Ausgabekonventionen (Groß-/Kleinschreibung, Zeilenzusammenführung) als Fehler (siehe den Abschnitt „Warum nicht CER verwenden“ oben).

Warum hat Unlimited-OCR den schlechtesten CER, aber den besten Regex-Feld-F1 bei SROIE?

Weil die beiden Metriken unterschiedliche Ausgaben bewerten. Unlimited-OCR’s starke Groß-/Kleinschreibung-Normalisierung bläht die Zeichenfehler auf — sein CER von 0,6552 gegenüber einem WER von 0,4779 ist der Hinweis —, während derselbe normalisierte Text zufällig besser zu den festen Extraktionsmustern passt als jeder andere Engine: SROIE-Regex-Feld-F1 0,3376, der Spitzenwert des 8-Engine-Runs (summary_metrics.csv cer / wer, field_method_comparison.csv regex_field_value_f1, sroie_2019-Zeilen).

Warum ist PaddleOCR-VL’s CORD-CER der schlechteste im Benchmark, während sein CORD-Feld-F1 der beste ist?

Weil CORD’s Ground Truth die Annotationsstruktur einbettet und PaddleOCR-VL’s Ausgabe die sauberste und am stärksten normalisierte ist — am weitesten entfernt von diesem strukturlastigen Text, weshalb seine Edit-Distanz am größten ist (CER 1,0805). Derselbe Ausgabestil speist die Extraktionsmuster gut: CORD-Regex-Feld-F1 0,3412, der beste Wert aller 8 Engines (summary_metrics.csv, cer / field_f1_regex, cord_v2-Zeilen). Diese Umkehrung ist die eigene Demonstration des Benchmarks, dass CORD-CER kein qualitätsbezogener Messwert pro Modell ist.

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

3,8× niedrigere p50-Latenz (694,3 ms vs. 2.668,0 ms), 5,6× höhere Durchsatzrate (68,2 vs. 12,1 Seiten/min) und 5,2× niedrigere Kosten pro 1.000 Seiten ($0,205 vs. $1,061) auf derselben RTX 4090 bei $0,76/Stunde (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, sroie_2019-Zeilen).

Macht ein LLM-Nachbearbeiter die drei VLMs gleichwertig?

Fast — 0,5921 bis 0,6139 LLM-Feld-F1 auf SROIE, eine Streuung von 0,022 Punkten innerhalb der Benchmark-Konvergenzband von 0,57–0,62 (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen). Der Preis dieser Konvergenz sind etwa 1,9–2,3 s zusätzliche mediane LLM-Latenz pro Dokument (llm_median_latency_ms, gleiche Zeilen), was für asynchrone Stapelverarbeitung spricht.

Welches der drei VLMs sollte eine Belegverarbeitung wählen?

Es hängt von der Achse ab, die Ihre Pipeline verbraucht. Für native mehrsprachige Felder ohne Nachbearbeiter ist der CORD-Regex-F1 von PaddleOCR-VL (0,3412) der einzige gemessene brauchbare Wert. Für günstigste, schnellste VLM-Bereitstellung wieder PaddleOCR-VL (694,3 ms, $0,205/1K Seiten). Für sauberen rohen englischen Text, wenn Kosten und Latenz keine Rolle spielen, ist die CER von Surya2 (0,1915) die stärkste. Für einen mittleren, ausgewogenen Punkt Unlimited-OCR (1.600,7 ms, $0,388/1K Seiten, bestes Out-of-the-Box-SROIE-Feld-F1). Mit einem LLM-Nachbearbeiter in der Pipeline spielt die Wahl bei Belegen kaum eine Rolle — alle drei landen im Konvergenzband. Diese Ergebnisse gelten für englische und indonesische Belege auf einer GPU-Stufe im August 2026; jede Produktionsentscheidung sollte auf dem Zielkorpus neu ausgeführt werden (siehe Einschränkungen).

Woher stammen die Zahlen auf dieser Seite?

Jede Zahl ist eine Zeile der veröffentlichten CSVs des First-Party-Benchmarks — results/summary_metrics.csv (CER/WER, F1-Wert, Latenz, Kosten, Durchsatz) und results/field_method_comparison.csv (Regex vs. LLM-Nachbearbeitung, llm_model = deepseek-v4-flash) — gehostet auf ImageToTableai/benchmark-ocr, mit einem geschwärzten manifest.json pro Durchlauf für Umgebungsfingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten Arbeiten zu SROIE 2019 und CORD.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen dreiteiligen Ausschnitt eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Umfrage zu Behauptungen Dritter und keine Hersteller-Vergleichsseite. Nur feste Test-Splits: SROIE 2019 Test (361 englische Quittungen, flache Felder Unternehmen/Datum/Adresse/Summe) und CORD v2 Test (100 indonesische Quittungen, verschachtelte Felder Menü/Teilsumme/Summe); Trainings-Splits wurden nie ausgewertet. Alle drei Engines sahen dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im steady-state liegen). Alle drei Läufe schlossen mit error_rate 0.0 ab (Spalte error_rate in summary_metrics.csv). Der zugrunde liegende Lauf umfasste insgesamt acht Engines; diese Seite vergleicht nur die drei genannten VLMs (Vision-Language-Model), und die vollständigen Ergebnisse aller acht Engines werden separat auf 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-Tarif von $0.76/hr, Preis mit Zeitstempel im geschwärzten Manifest jedes Laufs (August 2026).
• Engines: Out-of-the-Box, kein Fine-Tuning. Versionen fixiert: Surya2 (surya-ocr 0.22.1) und PaddleOCR-VL 1.6, beide vLLM-geserved; Unlimited-OCR vLLM-geserved ohne öffentlich fixierte Version (siehe Einschränkungen) — laut Modelltabelle des öffentlichen Repos (README.md) und den Lauf-Manifesten.
• LLM-Nachbearbeiter: deepseek-v4-flash via API bei Temperatur 0 für deterministische Ausgabe (Spalte llm_model in field_method_comparison.csv); es war das einzige Modell für alle LLM-Felder aller drei Engines.
• Kostenbasis: Echte Laufzeit × $0.76/hr, inklusive Modellinitialisierung — Batch-Verarbeitung senkt die Kosten pro Seite.
• Feld-Nachbearbeitung: SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (Spalten regex_* in field_method_comparison.csv) — Felder, die aus dem OCR-Text durch ein festes Muster-Set extrahiert wurden. Sie messen OCR + nachgelagerte Extraktion, nicht native strukturierte Ausgabe irgendeines Modells; die Spalten LLM_* messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden nie vermischt.

Metrikdefinitionen

• 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. Unfair für dokumentparsende VLMs: Es bewertet Groß-/Kleinschreibung, Zusammenführung von Labels/Werten und Zeilenumordnung als Fehler, auch wenn die Feldwerte korrekt sind. Auf dieser Seite nur zusammen mit seinen Einschränkungen zitiert.
• 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 Normalisierung der Ausgabe, nicht das Fehllesen, den Schaden anrichtet.
• Feldwert-F1 (Regex): Harmonisches Mittel aus Precision und Recall über extrahierte Feldwerte mit festen Regex-Mustern 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 für die Ausgabe des LLM-Nachbearbeiters (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie gemischt.
• Dokumentfelder exakt: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — ein viel strengerer Maßstab als der pro-Feld-F1-Wert.
• Latenz p50/p95 & Seiten/min: Stabilisierte Inferenzzeit pro Seite (warm-then-scored, schließt Modellladen aus) und Durchsatz in Echtzeit inklusive Modellinitialisierung.
• Kosten pro 1.000 Seiten: Abgerechnete GPU-Stunden für 1.000 Seiten zum erfassten Satz von $0,76/Stunde.

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 Durchsatz-Zahl auf dieser Seite lässt sich auf die surya2-, unlimited_ocr- und paddleocr_vl_vllm-Zeilen hier zurückführen.
2. field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), regex/llm field-value accuracy and F1, document-fields-exact, llm_median_latency_ms, token counts. Jede regex/LLM field-F1-Zahl lässt sich auf die drei benannten Engine-Zeilen hier zurückführen.
3. ImageToTableai/benchmark-ocr repository. Öffentliches Repository mit den Ergebnis-CSVs, geschwärzten Ausführungsmanifesten, eingefrorenem Protokoll und Datensatz-Beispiellisten (feste Testsplits) zur Reproduktion.
4. results/manifests/ (GitHub). Ein geschwärztes manifest.json pro veröffentlichter Ausführung (16 Ausführungen) 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

• CER-Ungerechtigkeit gegenüber VLMs ist der Grund, warum diese Seite auf Feldebenen-Metriken basiert: Dokumentparsende VLMs ignorieren Groß-/Kleinschreibung, fassen Beschriftungs-/Wert-Zeilen zusammen und ordnen Text neu an, sodass rohe CER-Werte Konventionsfehler als Fehler ausweisen — die Divergenz von Unlimited-OCR’s CER (0,6552) und WER (0,4779) sowie PaddleOCR-VL’s CORD-Inversion (schlechtester CER 1,0805, bester Feld-F1 0,3412) sind beides Artefakte dieser Steuer. Jeder Vergleich, der VLMs anhand von CER rangiert — einschließlich dieser Seite — sollte als Maß für den Ausgabestil und nicht für die Lesefähigkeit betrachtet werden.
• Dokumentumfang — nur Quittungen: SROIE + CORD. Hier wird nichts gemessen, was Layout/Tabellen/Formeln/lange Dokumente betrifft, wo dokumentparsende VLMs ihre größten Vorteile behaupten; die vermarkteten Stärken aller drei Engines (einschließlich Unlimited-OCR’s 40+ Seiten-Einzel-Parsing) sind ungemessen. Verwenden Sie diese Seite nicht, um zu dem Schluss zu kommen: „VLM X gewinnt bei allem."
• Stichprobengröße: 361 englische + 100 indonesische Quittungen. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von einigen Hundertstel (einschließlich der 0,022-Punkte-LLM-F1-Spanne) sollten als Rauschen und nicht als ingenieurtechnische Wahrheit behandelt werden.
• Einzelne GPU-Stufe und einzelner Preis: Alle Zahlen stammen von einer RTX 4090 zu 0,76 $/Stunde, Preis mit Zeitstempel August 2026 in den Ausführungsmanifesten. Andere GPUs, Multi-GPU-Bedienung, Stapelplanung oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie die Kosten vor der Budgetierung mit aktuellen Raten ab.
• Einzelner LLM-Nachbearbeiter: Alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt den absoluten Feld-F1; die Konvergenzreihenfolge kann an den Rändern schwanken. Die LLM-Latenz (~1,9–2,3 s Median, field_method_comparison.csv llm_median_latency_ms) wird durch die API verursacht und ist kein Teil der Latenz der Engine selbst.
• CORD-Quarantäne: CORD Ground Truth enthält Annotationstrukturen und die Regex-Muster wurden für englische Formate geschrieben; CORD CER (0,90–1,08 bei allen Engines) spiegelt Sprachmismatch + Ground-Truth-Inflation wider, nicht die Qualität pro Modell. CORD-Zeilen werden mit Einordnung zitiert und nie in irgendein SROIE-Ranking einbezogen (Protokollregel).
• Versionsfixierung: Die Ergebnisse gelten für Surya2 0,22.1, PaddleOCR-VL 1,6 und Unlimited-OCR vLLM-gespeist (August 2026). Unlimited-OCR hat in der veröffentlichten Modelltabelle des Benchmarks keine öffentlich fixierte Versionsnummer, sodass seine Zeile nicht auf eine exakte Version zurückgeführt werden kann; neuere Versionen jeder Engine können jede Zahl auf dieser Seite verschieben.
• Regex-Abstimmung: Die Mustermenge wurde einmal pro Datensatz geschrieben. Eine pro Format, stark abgestimmte Musterbibliothek könnte auf eigenen Layouts höher punkten — mit dem Wartungsaufwand, den das LLM eliminiert.

Verwandte Referenzen: docTR vs Surya2 Quittungs-Benchmark · Traditionelles OCR vs Dokumentparsende VLMs · Regex vs LLM-Feldextraktion · Feldebenen- vs Zeichenebenen-Genauigkeit · Quittungs-OCR-Genauigkeit

Weiterführende Lektüre: AI-OCR vs. traditionelle OCR-Genauigkeit · KI-Bilddatenextraktion vs. traditionelle OCR · KI-Dokumentextraktion Preise (2026)