OCR-Latenz-Benchmark
p50/p95, Durchsatz und Spitzenwerte (2026)

Drei Kennzahlen, eine Seite: p50, p95 und Seiten/min

Diese Seite berichtet drei Kennzahlen derselben Durchläufe, die unterschiedliche Fragen beantworten. p50 (der Median) ist die稳态-seitliche Inferenzzeit im Modus warm_then_scored — ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, und das Modellladen ist ausgeschlossen — sie beantwortet also die Frage: „Wie schnell ist diese Engine pro Seite, wenn sie bereits läuft?" p95 ist dieselbe Messung am 95. Perzentil: 5 % der Seiten brauchten länger. Seiten pro Minute ist der Durchsatz in Echtzeit inklusive Modellinitialisierung — die Zahl, die Batch-Jobs und abgerechnete GPU-Stunden bestimmt.

Die drei Kennzahlen sind nicht austauschbar und nicht dazu gedacht, übereinzustimmen. Der稳态-p50 schließt das Modellladen aus; der Echtzeit-Durchsatz (Seiten/min) schließt es ein; p95 erfasst Erste-Seite-/Prefill-Effekte und Batch-Scheduling-Verhalten, die p50 ignoriert. Jedes Diagramm und jede Tabelle auf dieser Seite gibt an, welche Kennzahl sie zeigt — behandeln Sie „108,7 ms" (p50, ohne Laden) und „449 Seiten/min" (Echtzeit, mit Laden) als zwei verschiedene Fakten über docTR, nicht als Widerspruch.

Drei Begriffe, die durchgehend verwendet werden: Tail-Latenz ist das Verhalten der langsamsten wenigen Prozent der Seiten (p95 und darüber) — für einen Benutzer, der auf eine einzelne Seite wartet, entscheidet der Tail, nicht der Median, über das Erlebnis. Erste-Seite-/Prefill-Effekt ist der einmalige Aufwand, ein Modell oder eine Pipeline vor der稳态-Inferenz zu initialisieren, der sich als langsame frühe Stichproben in einem Durchlauf zeigt. Echtzeit-Durchsatz zählt jede Millisekunde des Durchlaufs, einschließlich Initialisierung. Im Protokoll dieses Benchmarks sind p50/p95稳态-Messungen und Seiten/min Echtzeit — die Lücke zwischen ihnen ist Init plus Scheduling-Overhead.

SROIE 2019: Median-Latenz pro Seite im Ranking

Bei 361 englischen Quittungen besetzen die traditionellen zweistufigen OCR-Engines das schnelle Ende und die dokumentenparsenden VLMs das langsame Ende — aber die Streuung innerhalb jeder Familie ist die Überraschung. docTR (108,7 ms) ist 2,7× schneller als die nächste traditionelle Engine (PaddleOCR, 297,0 ms), und die beiden langsamsten Engines sind beide VLMs (Unlimited-OCR 1.600,7 ms, Surya2 2.668,0 ms). Doch die schnellste VLM, PaddleOCR-VL mit 694,3 ms, läuft immer noch langsamer als jede traditionelle Engine.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, Zeilen sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (nur CPU), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1600,7, Surya2 2668,0. Stabile Latenz, Messmodus warm-then-scored (schließt Modell-Laden aus).

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, sroie_2019 rows (je 361 Stichproben, error_rate 0.0 für alle 8). p95/p50-Verhältnisse durch Division der CSV-Werte berechnet (z. B. 3331.3505 / 296.9897 = 11.22). Tesseract lief nur auf CPU (compute_type=cpu); alle anderen auf GPU. Die Latenz im稳态 schließt das Laden des Modells aus; Seiten/min ist die Gesamtzeit inkl. Initialisierung.

Das Architekturmuster ist auf Familienebene klar — traditionelle Engines belegen die Plätze 1–4, VLMs die Plätze 5, 7, 8, mit Docling (ein Pipeline-Parser, kein reiner OCR-Engine und kein VLM) dazwischen — aber die Spanne innerhalb jeder Familie ist groß. Der VLM-Cluster umfasst 3,8× (694,3 bis 2.668,0 ms) und der traditionelle Cluster 6,2× (108,7 bis 670,9 ms), was bedeutet, dass „VLM“ und „traditionell“ keine Latenzkategorien sind — das individuelle Engine-Design entscheidet weit mehr als die Zugehörigkeit zur Familie.

p50 verschleiert die Spitzenwerte: p95/p50-Verhältnis über alle Engines

Der Median ist ein schlechter Prädiktor für den Worst Case. PaddleOCRs p95 auf SROIE (3.331,4 ms) beträgt 11,2× seines p50 (297,0 ms) — 5 % der Seiten dauerten über 3,3 Sekunden, obwohl die Median-Seite unter 300 ms dauerte. Für interaktive Workloads entscheidet dieses Verhältnis, nicht der p50, ob ein Benutzer 0,3 Sekunden oder 3,3 Sekunden wartet. docTRs p95 (281,4 ms) bleibt eng bei 2,6× seines p50.

Der Mechanismus ist der Erste-Seite/Vorabfüll-Effekt: GPU-Engines zahlen eine einmalige Anlaufkosten, bevor die stabile Inferenz beginnt, und Batch-Scheduling kann langsame Samples serialisieren. Das ist protokollspezifisches Verhalten — diese p95-Werte spiegeln das Ausführungsmuster dieses Benchmarks (fester Testsplit, Aufwärm- dann Bewertungsphase) wider, nicht eine universelle Eigenschaft der Engines. Was die Daten zeigen, ist die Form der Spitzenwerte jeder Engine unter diesem Protokoll: PaddleOCR und Docling haben lange, schwere Spitzenwerte auf SROIE; docTR, EasyOCR und Unlimited-OCR halten ihre nahe am Median.

Quelle: berechnet aus summary_metrics.csv — latency_p95_ms ÷ latency_p50_ms, sroie_2019-Zeilen (Verhältnis abgeleitet durch Division der veröffentlichten Werte, z. B. 3331,3505 / 296,9897 = 11,22). PaddleOCR 11,2×, Docling 4,4×, docTR 2,6×, EasyOCR 2,3×, Tesseract 2,2×, Surya2 2,2×, PaddleOCR-VL 1,7×, Unlimited-OCR 1,6×.

Beachten Sie, was das Verhältnis nicht aussagt: ein enges p95/p50-Verhältnis ist keine Geschwindigkeitsaussage. Unlimited-OCR hat die engsten Spitzenwerte im Benchmark (1,6×) — aber sein p50 (1.600,7 ms) und p95 (2.521,9 ms) sind beide viel langsamer als docTRs p95 (281,4 ms). Das Verhältnis misst die Form der Verteilung, nicht wo die Verteilung liegt. Lesen Sie die beiden Zahlen zusammen: ein enger Spitzenwert um einen langsamen Median herum ist immer noch langsam.

Durchsatz erzählt eine andere Geschichte: Seiten/min vs. p50

Rangieren Sie die Engines nach Seiten pro Minute, ändert sich die Reihenfolge. docTR’s 449,3 Seiten/min gegenüber Surya2’s 12,1 ergibt eine 37-fache Spanne — breiter als die 24,5-fache p50-Spanne. Aber PaddleOCR hält mit einem 11,2-fachen p95-Schwanz immer noch 79,7 Seiten/min: nahe an EasyOCR’s 124,5, vor PaddleOCR-VL’s 68,2 und Docling’s 56,7. Ein langsamer Median und ein schwerer Schwanz verhindern keinen respektablen Batch-Durchsatz.

Die Erklärung liegt in der Messgrundlage: Seiten/min ist der Wall-Clock-Durchsatz inklusive Modellinitialisierung und Scheduling, während p50 die steady-state Einzelseiten-Inferenz ohne Last misst. Die folgende Tabelle rechnet Seiten/min in die durchschnittliche Wall-Clock-Zeit pro Seite um, die sie impliziert (60.000 ÷ Seiten/min — eine abgeleitete Schätzung, keine gemessene Zahl) und zeigt die Differenz zu p50. PaddleOCR’s implizierte Wall-Clock-Zeit pro Seite (752,7 ms) ist 2,5-fach so hoch wie sein steady-state p50 (297,0 ms); Surya2’s (4.940,0 ms) ist 1,9-fach so hoch wie sein p50 (2.668,0 ms). Der Overhead — Initialisierung, Scheduling, Kosten pro Pipeline-Aufruf — ist in p50 allein unsichtbar, weshalb ein niedriger p50 nicht automatisch einen hohen Durchsatz bedeutet.

Tabelle: summary_metrics.csv — latency_p50_ms / pages_per_minute, sroie_2019 rows. Wall-clock ms/Seite ist eine abgeleitete Schätzung (60,000 ÷ pages_per_minute, z.B. 60,000 / 79.7130 = 752.7) — eine arithmetische Berechnung auf Basis des gemessenen Durchsatzes, keine separat gemessene Kennzahl. Overhead = abgeleiteter Wall-clock ÷ gemessener p50. Seiten/min ist der Wall-clock inkl. Modellinitialisierung; p50 ist der stationäre Zustand ohne Ladevorgang.

Eine zweite Anmerkung zu den Extremwerten: Tesseract, die einzige CPU-Engine, hält 78.6 Seiten/min auf SROIE — nahezu identisch mit PaddleOCR’s 79.7 auf GPU — wobei sein p50 (670.9 ms, CPU) und Wall-clock (763.0 ms) nahezu identisch sind, da eine CPU-Engine mit einem einzelnen Thread wenig Initialisierungs-Overhead zu verbergen hat. Sein p95 (1,507.0 ms) beträgt das 2,2-fache seines p50 — einer der engsten Verteilungsschwänze im Benchmark. Die Durchsatzparität zwischen CPU und GPU wird im Detail in Tesseract vs. PaddleOCR analysiert.

Interaktiv vs. Stapel: Die 1.000-ms-Schwelle

Für einen Benutzer, der auf eine einzelne Seite wartet, ist 1.000 ms eine nützliche Grenze — ungefähr die Schwelle dessen, was sich reaktiv anfühlt. Gemessen am p50 liegen sechs von acht Engines darunter bei SROIE: docTR (108,7 ms), PaddleOCR (297,0 ms), EasyOCR (413,6 ms), Tesseract (670,9 ms, CPU), PaddleOCR-VL (694,3 ms), Docling (732,0 ms). Nur Unlimited-OCR (1.600,7 ms) und Surya2 (2.668,0 ms) überschreiten sie im Median.

Gemessen am p95 kehrt sich das Bild um: nur zwei Engines liegen noch unter 1 Sekunde — docTR (281,4 ms) und EasyOCR (960,4 ms). Der Spitzenwert jeder anderen Engine überschreitet sie: PaddleOCR 3.331,4 ms, Docling 3.239,8 ms, Unlimited-OCR 2.521,9 ms, Tesseract 1.507,0 ms, PaddleOCR-VL 1.154,3 ms, Surya2 5.872,2 ms (summary_metrics.csv latency_p95_ms, sroie_2019 rows). Wenn “interaktiv” bedeutet, dass sich der schlimmste Fall reaktiv anfühlen muss, ist der Spitzenwert — nicht der Median — das Auswahlkriterium, und nur zwei Engines erfüllen es.

Stapelverarbeitung ist der andere Modus, und er ändert die Ökonomie zugunsten der Engines. Die Modellinitialisierung wird einmal pro Prozess/Stapel bezahlt, daher amortisiert die sequenzielle oder Stapelverarbeitung die Initialisierungskosten über mehrere Seiten — die Latenz pro Seite und die Kosten pro Seite sinken mit der Stapelgröße. Dies ist ein abgeleitetes Argument aus der Messgrundlage (Seiten/min beinhaltet Init; p50 schließt es aus), kein neuer Benchmark-Lauf — dieselbe Begründung und ihre durchgerechnete Arithmetik finden sich in der Methodik der Kosten-Seite.

CORD (Indonesische Quittungen): Gleiche Geschichte, andere Verläufe

Tauscht man den Datensatz aus, bleiben die Rangfolgen im Großen und Ganzen bestehen — docTR bleibt am schnellsten und Surya2 am langsamsten — aber die Sprachänderung formt die Verläufe neu. Bei CORD v2 explodiert der p95-Wert von Surya2 auf 26.976,9 ms (≈27 s), 18,2× seines eigenen p50 (1.485,3 ms) und das Extrem-Verlaufsereignis des Benchmarks — während sein SROIE-Verhältnis ein bescheidenes 2,2× betrug. Sprachinhalt verändert das Verlaufsverhalten; ein VLM, der bei englischen Quittungen stabil ist, kann bei indonesischen auf Wartezeiten von einer halben Minute ansteigen.

CORD v2 ist ein indonesischsprachiger Datensatz mit verschachtelten Feldern (menu, sub_total, total); keiner der 8 Engines wurde überwiegend auf Indonesisch trainiert, weshalb er auch als sprachübergreifender Stresstest dient. Seine Quittungen sind kürzer und weniger textdicht als die von SROIE, weshalb die meisten Engines hier schneller werden — docTR sinkt auf 100,4 ms p50 (500,4 Seiten/min), PaddleOCR auf 108,2 ms p50 (141,0 Seiten/min). CORD wird in diesem Benchmark bewusst von der SROIE-Rangliste getrennt (andere Sprache, andere Ground-Truth-Struktur); der Punkt dieser Tabelle ist, dass sich die Latenz mit dem Datensatz verschiebt und sich die Verläufe drastisch ändern können.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, cord_v2-Zeilen. docTR 100,4, PaddleOCR 108,2, EasyOCR 192,8, PaddleOCR-VL 249,3, Docling 338,0, Tesseract 474,6 (nur CPU), Unlimited-OCR 608,2, Surya2 1485,3. Stabile Latenz, warm-then-scored (ohne Modell-Ladezeit).

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, cord_v2 Zeilen (je 100 Stichproben). p95/p50-Verhältnisse durch Division der CSV-Werte berechnet (z. B. 26976.9306 / 1485.3493 = 18.16). Tesseract lief nur auf CPU. Die Latenz im稳态 schließt das Laden des Modells aus; Seiten/min ist die Gesamtzeit inkl. Initialisierung.

Surya2s CORD-p95 von 26.976,9 ms ist das einzelne größte Spitzenereignis im Benchmark — eine von zwanzig Seiten dauerte etwa 27 Sekunden auf einem Datensatz, dessen Median bei 1,5 Sekunden lag. Zur Einordnung: Das sind 114× docTRs CORD-p95 (235,9 ms). Zwei Engines, die bei SROIE nahezu identisch waren (Surya2 2,2×, Unlimited-OCR 1,6× Spitzenverhältnisse), weichen bei CORD stark voneinander ab (18,2× vs. 2,4×) — eine Erinnerung daran, dass das Spitzenverhalten eine Eigenschaft der Kombination aus Engine × Dokument ist und nicht der Engine allein.

Latenz und Kosten laufen auf derselben Uhr

Da gemietete GPUs nach Echtzeitstunden abgerechnet werden, sind Latenz und Kosten dieselbe Messung, zweimal betrachtet: docTR ist sowohl die schnellste Engine (108,7 ms p50) als auch die günstigste (Kosten_pro_1000_Seiten 0,0479 bei SROIE); Surya2 ist sowohl die langsamste (2.668,0 ms p50) als auch die teuerste (1,0609) — gleiche Aufteilung, gleicher Satz. Die schweren VLMs sind langsam und teuer zusammen; die leichten traditionellen Engines sind schnell und günstig zusammen.

Die Korrelation ist nicht exakt, da den Kosten die Echtzeit-Seiten/min zugrunde liegen (einschließlich Initialisierung), während p50 diese ausschließt — PaddleOCRs p50 (297,0 ms) ist schneller als EasyOCRs (413,6 ms), doch PaddleOCRs Kosten pro 1.000 Seiten (0,2214) sind etwa doppelt so hoch wie EasyOCRs (0,1098), weil sein Echtzeit-Durchsatz deutlich niedriger ist (79,7 vs. 124,5 Seiten/min; summary_metrics.csv cost_per_1000_pages / pages_per_minute, sroie_2019-Zeilen). Die vollständige Kostenrangliste, die Kostenformel und die dahinterstehende Arithmetik finden sich auf der Schwesterseite OCR-Kosten pro 1.000 Seiten — diese Seite konzentriert sich auf Latenz und nutzt lediglich die Korrelation.

Häufig gestellte Fragen

Welche OCR-Engine ist am schnellsten pro Seite?

docTR war in diesem Benchmark am schnellsten: 108,7 ms p50 und 281,4 ms p95 pro Seite auf SROIE 2019 (summary_metrics.csv latency_p50_ms / latency_p95_ms, doctr/sroie_2019 Zeile) mit 449,3 Seiten/min. Die langsamste gemessene, Surya2, war bei p50 24,5× langsamer (2.668,0 ms) und beim Durchsatz 37× langsamer (12,1 Seiten/min).

Was ist eine typische OCR-Latenz pro Seite auf einer GPU?

Zwischen 108,7 ms (docTR) und 2.668,0 ms (Surya2) p50 pro Seite über 8 Open-Source-Engines auf einer RTX 4090, SROIE 2019 Quittungen (summary_metrics.csv latency_p50_ms, sroie_2019 Zeilen) — eine 24,5-fache Streuung auf identischer Hardware. Im稳态, warm-then-scored, ohne Modell-Laden. Dieselben Engines auf CORD v2 erstrecken sich von 100,4 bis 1.485,3 ms p50.

Warum ist die OCR-p95-Latenz so viel höher als p50?

Wegen des First-Page/Prefill-Effekts und des Batch-Scheduling-Verhaltens: GPU-Engines zahlen einmalige Anlaufkosten, und langsame Samples können serialisiert werden, sodass die langsamsten 5 % der Seiten — per Definition des 95. Perzentils — weit vom Median entfernt liegen. PaddleOCR’s SROIE p95 (3.331,4 ms) ist 11,2× sein p50 (297,0 ms); docTR’s p95 (281,4 ms) ist nur 2,6× sein p50 (summary_metrics.csv latency_p95_ms / latency_p50_ms, sroie_2019 Zeilen). Die p95-Werte sind protokollspezifisch — sie spiegeln das Ausführungsmuster dieses Benchmarks wider, nicht eine universelle Engine-Eigenschaft.

Warum stimmen OCR-Latenz und Seiten pro Minute nicht überein?

Weil es unterschiedliche Messungen sind. Seiten/min ist der Durchsatz in Echtzeit einschließlich Modell-Initialisierung und Scheduling; p50 ist die steady-state pro Seite Inferenz ohne Modell-Laden. Auf SROIE impliziert PaddleOCR’s p50 (297,0 ms) im reinen steady-state etwa 200 Seiten/min, aber der gemessene Durchsatz beträgt 79,7 Seiten/min — eine abgeleitete Echtzeit von 752,7 ms pro Seite, 2,5× sein p50 (summary_metrics.csv latency_p50_ms / pages_per_minute, paddleocr/sroie_2019 Zeile). Für Batch-Jobs planen Sie mit Seiten/min; für interaktive Wartezeiten mit p50 und p95.

Was ist eine gute OCR-Latenz für interaktive Nutzung?

Unter 1.000 ms am Ende ist die praktische Grenze. Bei SROIE liegen sechs von acht Engines unter 1 Sekunde bei p50 (docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9, PaddleOCR-VL 694,3, Docling 732,0 ms), aber nur docTR (281,4 ms) und EasyOCR (960,4 ms) halten ihr p95 unter 1 Sekunde (summary_metrics.csv latency_p50_ms / latency_p95_ms, sroie_2019 rows). Wenn der schlimmste Fall reaktionsschnell sein muss, entscheidet das p95; wenn der typische Fall ausreicht, entscheidet das p50.

Warum hat eine OCR-Engine 27 Sekunden für einen Beleg gebraucht?

Surya2s p95 bei CORD v2 betrug 26.976,9 ms (≈27 s) — 18,2× sein eigenes p50 (1.485,3 ms) und das größte Spitzenereignis im Benchmark (summary_metrics.csv latency_p95_ms / latency_p50_ms, surya2/cord_v2 row). Seine Spitze bei SROIE war moderat mit 2,2×, sodass der Ausreißer spezifisch für die Kombination Engine × CORD ist — Sprachinhalte und Scheduling veränderten das Spitzenverhalten, nicht nur den Median.

Ist Tesseract OCR ohne GPU schnell genug?

Auf CPU hielt Tesseract 78,6 Seiten/min bei SROIE 2019 mit einem p50 von 670,9 ms — langsamer als die GPU-traditionellen Engines, aber bei Durchsatz schneller als alle drei VLMs (PaddleOCR-VL 68,2, Docling 56,7, Unlimited-OCR 34,4, Surya2 12,1 Seiten/min) und mit einer engen Spitze (2,2×). Es ist in diesem Benchmark CPU-only (summary_metrics.csv tesseract/sroie_2019 row); ob es „schnell genug" ist, hängt von Ihrem Volumen und davon ab, ob Sie Felder statt Text benötigen — siehe das CPU-Kostenprofil in Tesseract vs PaddleOCR.

Wird OCR pro Seite schneller, wenn Sie mehr Seiten verarbeiten?

Ja, bis zu einen stabilen Grenzwert — als abgeleiteter Effekt der Messbasis, nicht als neuer Durchlauf. Die Modellinitialisierung wird einmal pro Prozess/Batch bezahlt (sie ist in Seiten/min enthalten, aber außerhalb von p50), sodass Batch- oder sequenzielle Verarbeitung sie amortisiert: Bei hohem Volumen nähert sich die pro Seite verstrichene Zeit dem stabilen p50 plus Scheduling. docTRs SROIE-Zahlen sind bereits nah an diesem Grenzwert (p50 108,7 ms vs. abgeleitete verstrichene Zeit 133,5 ms pro Seite); Surya2s (p50 2.668,0 vs. 4.940,0 ms) zeigt mehr Initialisierungsaufwand zur Amortisierung.

Woher stammen die Latenzzahlen auf dieser Seite?

Jede Zahl ist eine Zeile der veröffentlichten results/summary_metrics.csv (latency_p50_ms, latency_p95_ms, pages_per_minute) des First-Party-Benchmarks, gehostet unter ImageToTableai/benchmark-ocr, mit einem geschwärzten manifest.json pro Durchlauf, das den Messmodus (warm_then_scored), die Modellversionen und die Umgebungsfingerabdrücke aufzeichnet. Datensatzdefinitionen stammen aus den unten zitierten Arbeiten zu SROIE 2019 und CORD.

Methodik & Quellen

Protokoll

Diese Seite berichtet über die Latenzdimension eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — nicht über eine Umfrage zu Behauptungen Dritter. Nur feste Test-Splits: SROIE 2019 test (361 englische Quittungen, flache Felder Firma/Datum/Adresse/Gesamtbetrag) und CORD v2 test (100 indonesische Quittungen, verschachtelte Felder Menü/Teilsumme/Gesamtbetrag); Trainings-Splits wurden nie ausgewertet. Jedes (Engine × Datensatz)-Paar verwendete dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus). Alle 16 Läufe wurden mit error_rate 0.0 abgeschlossen (Spalte error_rate in summary_metrics.csv). Die Daten wurden im August 2026 erhoben.

Laufzeitumgebung

• Hardware: alle GPU-Läufe auf einer einzigen NVIDIA RTX 4090 (24 GB). Tesseract lief nur auf CPU (compute_type=cpu) und ist in jeder Tabelle entsprechend gekennzeichnet. Eine GPU-Stufe, ein Ort/Zeitpunkt — der Bereichsangabe auf dieser Seite.
• Engines: alle Modelle laufen out-of-the-box, ohne Feinabstimmung. Versionen laut den Lauf-Manifesten festgelegt: Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR vLLM-served, PaddleOCR-VL 1.6.
• Messmodus: warm_then_scored — Latenzzahlen sind steady-state pro Seite Inferenz ohne Modell-Laden; pages/min ist die reale Zeit inkl. Modell-Initialisierung (pro Lauf performance.run_wall_time_ms in den geschwärzten Manifesten).
• Lauf-Stufe: alle 16 Läufe sind official; nur offizielle Läufe sind gemäß dem Benchmark-Protokoll (reports/receipt_v1_official_protocol.md) zur Veröffentlichung zugelassen.

Metrikdefinitionen

• p50 (Median-Latenz): die mediane Inferenzzeit pro Seite im stabilen Zustand — 50 % der Seiten waren schneller. Schließt das Laden des Modells aus (warm_then_scored).
• p95 (Tail-Latenz): die 95. Perzentil-Inferenzzeit pro Seite — 5 % der Seiten dauerten länger. Spiegelt Effekte der ersten Seite/Präfüllung und das Batch-Scheduling-Verhalten unter dem Protokoll dieses Durchlaufs wider; protokollspezifisch, keine universelle Engine-Konstante.
• p95/p50-Verhältnis: abgeleitet durch Division der beiden CSV-Spalten (z. B. 3331.3505 / 296.9897 = 11,22). Ein Formindikator des Tails, keine Geschwindigkeitsaussage.
• Seiten pro Minute: Durchsatz in Echtzeit inkl. Modellinitialisierung. Die Perspektive für Batch-Jobs und Abrechnung.
• Echtzeit-ms/Seite (abgeleitet): 60.000 ÷ Seiten/min — eine arithmetische Berechnung auf Basis des gemessenen Durchsatzes, gekennzeichnet als abgeleiteter Schätzwert, nicht als Messwert.

Quellenverzeichnis

1. summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Engines × 2 Beleg-Datensätze (sroie_2019, cord_v2). Spalten umfassen latency_p50_ms, latency_p95_ms, pages_per_minute, compute_type, error_rate. Jede Latenz- und Durchsatzangabe auf dieser Seite lässt sich auf eine Zeile hier zurückführen.
2. ImageToTableai/benchmark-ocr Repository. Öffentliches Repository mit den Ergebnis-CSVs, geschwärzten Lauf-Manifesten, dem eingefrorenen Protokoll (reports/receipt_v1_official_protocol.md) und Datensatz-Beispiellisten (feste Test-Splits) zur Reproduktion.
3. results/manifests/ (GitHub). Ein geschwärztes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit dem Umgebungs-Fingerabdruck, den Modellversionen, dem Messmodus (warm_then_scored), der Echtzeit und den Artefakt-Hashes.
4. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). SROIE 2019 Datensatzdefinition, Aufgabenstruktur und Lizenz (CC-BY-4.0).
5. 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

• Einzelne GPU-Klasse, einzelner Standort/Zeitpunkt: Alle GPU-Werte stammen von einer RTX 4090 an einem Standort, erhoben im August 2026. Andere GPUs, Multi-GPU-Betrieb und unterschiedliche Scheduling verschieben Latenz und Durchsatz; messen Sie auf eigener Hardware, bevor Sie sich festlegen.
• Nur Quittungen: SROIE (Englisch) und CORD (Indonesisch) Quittungen. Die Latenz bei Rechnungen, Formularen, Verträgen oder langen Dokumenten ist ungemessen; die obigen Rankings sind nicht über Quittungen hinaus verallgemeinerbar — und die Ergebnisse von CORD sind nicht in das SROIE-Ranking eingerechnet.
• p95 ist protokollspezifisch: p95-Werte spiegeln Erste-Seite/Präfill-Effekte und Batch-Scheduling unter dem Laufmuster dieses Benchmarks (feste 361/100-Seiten-Aufteilungen, Aufwärm-then-Scored) wider. Sie sind eine Formablesung dieses Laufs, keine universelle Worst-Case-Garantie.
• p50/p95 schließen Modellladen aus, Seiten/min schließt es ein: Die beiden Grundlagen sind absichtlich unterschiedlich (steady-state inference vs. Wall-Clock-Durchsatz) und werden nie als dieselbe Zahl dargestellt. Abgeleiteter Wall-Clock pro Seite (60.000 ÷ Seiten/min) ist eine Arithmetik auf gemessenem Durchsatz, keine separat gemessene Zahl.
• CPU/GPU-Asymmetrie: Tesseract (CPU) wird mit GPU-beschleunigten Engines verglichen; seine Latenz spiegelt CPU-Hardware wider. Es ist in jeder Tabelle markiert, aber die Asymmetrie ist dem Vergleich inhärent.
• Keine Cloud/API-Modelle: AWS Textract, Google Document AI, Azure AI Document Intelligence und gehostete OCR/VLM-APIs sind nicht enthalten; ihre Latenzmodelle (Netzwerk, pro-Aufruf-Abrechnung, Autoscaling) unterscheiden sich grundlegend von den hier gemessenen lokalen Engines.
• Keine Batch-Größen-Untersuchung: Die Init-Amortisierung wird aus der Messgrundlage abgeleitet (Seiten/min schließt Init ein, p50 schließt es aus) und mit der Methode der Kosten-Seite abgeglichen — es wurde kein Batch-Größen-Experiment durchgeführt, daher ist die Skalierung pro Batch eine Schätzung, keine Messung.
• Stichprobengröße und Versionsfixierung: 361 + 100 Stichproben; die Ergebnisse gelten für die oben aufgeführten Modellversionen vom August 2026. Neuere Engine-Releases können die Latenz verschieben; einstellige Prozentunterschiede sollten als Rauschen behandelt werden.

Verwandte Referenzen: OCR-Kosten pro 1.000 Seiten · Traditionelles OCR vs. Document Parsing VLMs · docTR vs. Surya2: CER-Gleichstand, Kostenunterschied · docTR vs. Docling: Einzel-Durchlauf vs. Pipeline · Tesseract vs. PaddleOCR: Legacy-CPU vs. Modernes GPU

Verwandte Lektüre: AI-OCR vs. Traditionelle OCR-Genauigkeit · KI-Bildextraktion vs. Traditionelles OCR · KI-Dokumentextraktion Preise (2026)