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

Drei Messgrößen, eine Seite: p50, p95 und Seiten/min

Diese Seite berichtet drei Messgrößen derselben Läufe, die unterschiedliche Fragen beantworten. p50 (der Median) ist die stationäre Inferenzzeit pro Seite im warm_then_scored-Modus — ein fester Aufwärmdurchlauf geht dem bewerteten Durchlauf voraus, und das Laden des Modells ist ausgeschlossen — und beantwortet daher die Frage “Wie schnell ist diese Engine pro Seite, sobald sie läuft?” p95 ist dieselbe Messung am 95. Perzentil: 5 % der Seiten dauerten länger. Seiten pro Minute ist der Wanduhr-Durchsatz einschließlich der Modellinitialisierung — die Zahl, die Batch-Jobs und abgerechnete GPU-Stunden bestimmt.

Die drei Messgrößen sind nicht austauschbar und stimmen voraussichtlich nicht überein. Das stationäre p50 schließt das Laden des Modells aus; die Wanduhr-Seiten/min schließen es ein; p95 erfasst First-Page-/Prefill-Effekte und Batch-Scheduling-Verhalten, die p50 ignoriert. Jedes Diagramm und jede Tabelle auf dieser Seite gibt an, welche Messgröße sie zeigt — behandeln Sie “108,7 ms” (p50, ohne Laden) und “449 Seiten/min” (Wanduhr, mit Laden) als zwei verschiedene Fakten über docTR, nicht als Widerspruch.

Drei Begriffe werden durchgehend verwendet: Tail-Latenz ist das Verhalten der langsamsten wenigen Prozent der Seiten (p95 und darüber) — für einen Nutzer, der auf eine einzelne Seite wartet, entscheidet der Tail, nicht der Median, über das Erlebnis. First-Page-/Prefill-Effekt sind die einmaligen Kosten des Vorbereitens eines Modells oder einer Pipeline vor der stationären Inferenz, die sich als langsame frühe Stichproben in einem Lauf zeigen. Wanduhr-Durchsatz zählt jede Millisekunde des Laufs, einschließlich der Initialisierung. Im Protokoll dieses Benchmarks sind p50/p95 stationäre Messungen und Seiten/min ist Wanduhr — die Lücke zwischen ihnen ist Init plus Scheduling-Overhead.

SROIE 2019: Median der Seitenlatenz pro Seite – Ranking

Bei 361 englischen Belegen liegen die traditionellen zweistufigen OCR-Engines am schnellen Ende und die Dokument-Parsing-VLMs am langsamen Ende — doch die Spannweite 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 das 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. Stationäre Latenz, Messmodus warm-then-scored (ohne Modell-Ladezeit).

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, sroie_2019-Zeilen (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 mit CPU (compute_type=cpu); alle anderen mit GPU. Die Latenz im stationären Zustand schließt das Laden des Modells aus; Seiten/min umfassen die Initialisierung (Wall-Clock).

Das Architekturmuster ist auf Familienebene klar — traditionelle Engines belegen die Ränge 1–4, VLMs die Ränge 5, 7, 8, mit Docling (ein Pipeline-Parser, keine reine OCR-Engine oder ein VLM) in der Mitte — aber die Lücke innerhalb jeder Familie ist groß. Der VLM-Cluster spannt 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 Familienzugehörigkeit.

p50 verbirgt den Schwanz: p95/p50-Verhältnisse über Engines hinweg

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

Der Mechanismus ist der First-Page/PreFill-Effekt: GPU-Engines zahlen einmalige Initialisierungskosten vor der stabilen Inferenz, und Batch-Scheduling kann langsame Stichproben serialisieren. Das ist protokollspezifisches Verhalten — diese p95-Werte spiegeln das Ausführungsmuster dieses Benchmarks wider (fester Test-Split, warm-then-scored), keine universelle Eigenschaft der Engines. Was die Daten zeigen, ist die Form des Schwanzes jeder Engine unter diesem Protokoll: PaddleOCR und Docling haben lange, schwere Schwänze 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 durch Division der veröffentlichten Werte abgeleitet, 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 den engsten Schwanz im Benchmark (1,6×) — aber sein p50 (1.600,7 ms) und p95 (2.521,9 ms) sind beide weit 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 Schwanz um einen langsamen Median ist immer noch langsam.

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

Ordnet man die Engines nach Seiten pro Minute, ändert sich die Reihenfolge. docTRs 449,3 Seiten/min gegenüber Surya2s 12,1 ergibt eine Spanne von 37× — breiter als die 24,5× p50-Spanne. Aber PaddleOCR, mit einem 11,2× p95-Ausläufer, hält dennoch 79,7 Seiten/min: nahe an EasyOCRs 124,5, vor PaddleOCR-VLs 68,2 und Doclings 56,7. Ein langsamer Median und ein schwerer Ausläufer verhindern keinen respektablen Batch-Durchsatz.

Die Erklärung liegt in der Messbasis: Seiten/min ist Wanduhr-Durchsatz inklusive Modellinitialisierung und Planung, während p50 die Inferenz im stationären Zustand für eine einzelne Seite ohne Last ist. Die Tabelle unten rechnet Seiten/min in die durchschnittliche Wanduhrzeit pro Seite um, die daraus folgt (60.000 ÷ Seiten/min — eine abgeleitete Schätzung, kein gemessener Wert) und zeigt die Lücke zu p50. PaddleOCRs implizierte Wanduhrzeit pro Seite (752,7 ms) ist 2,5× sein p50 im stationären Zustand (297,0 ms); Surya2s (4.940,0 ms) ist 1,9× sein p50 (2.668,0 ms). Der Overhead — Initialisierung, Planung, Pipeline-Kosten pro Aufruf — ist in p50 allein unsichtbar, weshalb ein niedriges p50 nicht automatisch 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 ÷ Seiten pro Minute, z. B. 60.000 / 79,7130 = 752,7) — eine Rechnung auf Basis des gemessenen Durchsatzes, kein separat gemessener Wert. Overhead = abgeleitete Wall-clock-Zeit ÷ gemessener p50. Seiten/min ist Wall-clock inklusive Modellinitialisierung; p50 ist der Steady-State ohne Last.

Eine zweite Anmerkung zur Abstimmung an den Extremen: Tesseract, die einzige CPU-Engine, erreicht auf SROIE 78,6 Seiten/min — im Wesentlichen gleichwertig mit PaddleOCRs 79,7 auf GPU — wobei sein p50 (670,9 ms, CPU) und seine Wall-clock-Zeit (763,0 ms) nahezu identisch sind, da eine einthreadige CPU-Engine kaum Initialisierungsaufwand zu verbergen hat. Sein p95 (1.507,0 ms) ist das 2,2-Fache seines p50 — eine der engsten Verteilungen im Benchmark. Die Durchsatzparität zwischen CPU und GPU wird ausführlich analysiert in Tesseract vs. PaddleOCR.

Interaktiv vs. Batch: Die 1.000-ms-Schwelle im Detail

Für einen Nutzer, der auf eine einzelne Seite wartet, ist 1.000 ms eine sinnvolle Grenze — ungefähr die Grenze dessen, was sich reaktionsschnell anfühlt. Beim p50-Wert bleiben 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.

Beim p95-Wert kehrt sich das Bild um: nur zwei Engines bleiben unter 1 Sekunde — docTR (281,4 ms) und EasyOCR (960,4 ms). Der Tail aller anderen Engines ü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-Zeilen). Wenn „interaktiv" bedeutet, dass der schlechteste Fall reaktionsschnell sein muss, ist der Tail — nicht der Median — das Auswahlkriterium, und nur zwei Engines erfüllen es.

Batch-Verarbeitung ist das andere Regime und verschiebt die Wirtschaftlichkeit zugunsten der Engines. Die Modellinitialisierung wird einmal pro Prozess/Batch bezahlt, sodass sequenzielle oder Batch-Verarbeitung die Init-Kosten auf mehr Seiten amortisiert — Latenz und Kosten pro Seite sinken beide, wenn die Batch-Größe wächst. Dies ist ein abgeleitetes Argument aus der Messbasis (Seiten/min inklusive Init; p50 ohne Init), kein neuer Benchmark-Lauf — dieselbe Argumentation und die durchgerechnete Arithmetik finden sich in der Methode der Kostenseite.

CORD (indonesische Belege): Gleiche Geschichte, andere Ausreißer

Tauscht man den Datensatz aus, bleiben die Rangfolgen weitgehend gleich — docTR bleibt am schnellsten, Surya2 am langsamsten — aber der Sprachwechsel verändert die Ausreißer. Bei CORD v2 explodiert Surya2s p95 auf 26.976,9 ms (≈27 s), das 18,2×-Fache seines eigenen p50 (1.485,3 ms) und das extreme Ausreißer-Ereignis des Benchmarks — während sein SROIE-Ausreißer-Verhältnis nur 2,2× betrug. Der Sprachinhalt verändert das Ausreißer-Verhalten; ein VLM, das bei englischen Belegen stabil ist, kann bei indonesischen auf halbminütige Wartezeiten ansteigen.

CORD v2 ist ein indonesischsprachiger Datensatz mit verschachtelten Feldern (Menü, Zwischensumme, Gesamtsumme); keines der 8 Engines wurde überwiegend mit Indonesisch trainiert, daher dient er auch als sprachübergreifender Stresstest. Seine Belege sind kürzer und weniger textdicht als die von SROIE, weshalb die meisten Engines hier schneller werden — docTR fällt 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 getrennt von der SROIE-Rangliste geführt (andere Sprache, andere Ground-Truth-Struktur); der Punkt dieser Tabelle ist, dass sich die Latenz mit dem Datensatz bewegt und der Ausreißer sich dramatisch verändern kann.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, Zeilen cord_v2. 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. Stationäre Latenz, warm-dann-bewertet (ohne Modell-Laden).

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 mit CPU. Die Latenz im stationären Zustand schließt das Laden des Modells aus; Seiten/min ist die Wanduhrzeit inklusive Initialisierung.

Surya2’s CORD p95 von 26.976,9 ms ist das größte einzelne Tail-Ereignis im Benchmark — eine von zwanzig Seiten dauerte etwa 27 Sekunden bei einem Datensatz, dessen Median bei 1,5 Sekunden lag. Zum Vergleich: Das ist 114× docTR’s CORD p95 (235,9 ms). Zwei Engines, die bei SROIE nahezu identisch waren (Surya2 2,2×, Unlimited-OCR 1,6× Tail-Verhältnis), weichen bei CORD stark voneinander ab (18,2× vs. 2,4×) — eine Erinnerung daran, dass das Tail-Verhalten eine Eigenschaft der Engine × Dokument-Kombination ist, nicht der Engine allein.

Latenz und Kosten laufen nach derselben Uhr

Da gemietete GPUs nach Wanduhr-Stunden 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 (cost_per_1000_pages 0,0479 bei SROIE); Surya2 ist sowohl die langsamste (2.668,0 ms p50) als auch die teuerste (1,0609) — gleiche Aufteilung, gleiche Rate. Die schweren VLMs sind langsam und teuer zugleich; die leichten traditionellen Engines sind schnell und günstig zugleich.

Die Korrelation ist nicht exakt, da die Kosten der Wanduhr-Seitenzahl pro Minute folgen (inklusive Initialisierung), während p50 diese ausschließt — PaddleOCR’s p50 (297,0 ms) ist schneller als EasyOCR’s (413,6 ms), doch PaddleOCR’s Kosten pro 1.000 Seiten (0,2214) sind etwa doppelt so hoch wie EasyOCR’s (0,1098), weil sein Wanduhr-Durchsatz weitaus geringer 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 Sie auf der Schwester-Seite OCR-Kosten pro 1.000 Seiten — diese Seite konzentriert sich auf Latenz und übernimmt nur die Korrelation.

Häufig gestellte Fragen

Welche ist die schnellste OCR-Engine pro Seite?

docTR war die schnellste in diesem Benchmark: 108,7 ms p50 und 281,4 ms p95 pro Seite bei SROIE 2019 (summary_metrics.csv latency_p50_ms / latency_p95_ms, doctr/sroie_2019 Zeile), mit einem Durchsatz von 449,3 Seiten/min. Die langsamste gemessene Engine, 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-Belege (summary_metrics.csv latency_p50_ms, sroie_2019-Zeilen) — eine 24,5×-Spannweite auf identischer Hardware. Im eingeschwungenen Zustand, warm-then-scored, ohne Modell-Ladezeit. Dieselben Engines auf CORD v2 liegen zwischen 100,4 und 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 Initialisierungskosten, und langsame Stichproben können serialisiert werden, sodass die langsamsten 5 % der Seiten — per Definition des 95. Perzentils — weit vom Median entfernt liegen. PaddleOCRs SROIE-p95 (3.331,4 ms) ist 11,2× sein p50 (297,0 ms); docTRs 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, keine universelle Engine-Eigenschaft.

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

Weil es verschiedene Messungen sind. Seiten/min ist der Wanduhr-Durchsatz einschließlich Modellinitialisierung und Scheduling; p50 ist die Inferenz im eingeschwungenen Zustand pro Seite ohne Modell-Ladezeit. Auf SROIE impliziert PaddleOCRs p50 (297,0 ms) grob 200 Seiten/min im reinen eingeschwungenen Zustand, aber der gemessene Durchsatz liegt bei 79,7 Seiten/min — eine abgeleitete Wanduhr-Zeit 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 im Tail ist die praktische Messlatte. Auf SROIE bleiben sechs von acht Engines bei p50 unter 1 Sekunde (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-Zeilen). Wenn der Worst Case reaktionsschnell wirken muss, entscheidet das p95; wenn der typische Fall reicht, entscheidet das p50.

Warum brauchte eine OCR-Engine 27 Sekunden für eine Quittung?

Der p95-Wert von Surya2 auf CORD v2 lag bei 26.976,9 ms (≈27 s) — das ist das 18,2-Fache seines eigenen p50 (1.485,3 ms) und das größte Tail-Ereignis im Benchmark (summary_metrics.csv latency_p95_ms / latency_p50_ms, Zeile surya2/cord_v2). Sein Tail auf SROIE war mit dem 2,2-Fachen moderat, der Ausschlag ist also spezifisch für die Kombination Engine × CORD — Sprachinhalte und Scheduling haben das Tail-Verhalten verändert, nicht nur der Median.

Ist Tesseract OCR ohne GPU schnell genug?

Auf der CPU erreichte Tesseract 78,6 Seiten/min auf SROIE 2019 mit einem p50 von 670,9 ms — langsamer als die traditionellen GPU-Engines, aber schneller als alle drei VLMs beim Durchsatz (PaddleOCR-VL 68,2, Docling 56,7, Unlimited-OCR 34,4, Surya2 12,1 Seiten/min) und mit einem engen Tail (2,2-Fache). In diesem Benchmark läuft es nur auf der CPU (summary_metrics.csv, Zeile tesseract/sroie_2019); ob es „schnell genug“ ist, hängt von Ihrem Volumen ab und davon, ob Sie Felder statt Text benötigen — siehe das CPU-Kostenprofil in Tesseract vs PaddleOCR.

Wird OCR pro Seite schneller, wenn man mehr Seiten verarbeitet?

Ja, bis zu einer stabilen Untergrenze — als abgeleiteter Effekt der Messbasis, nicht durch einen neuen Lauf. Die Modellinitialisierung wird einmal pro Prozess/Batch bezahlt (sie steckt in Seiten/min, aber außerhalb des p50), daher amortisiert Batch- oder sequenzielle Verarbeitung sie: Bei hohem Volumen nähert sich die Wanduhrzeit pro Seite dem stabilen p50 plus Scheduling an. Die SROIE-Werte von docTR liegen bereits nahe an dieser Untergrenze (p50 108,7 ms gegenüber abgeleiteten 133,5 ms Wanduhrzeit pro Seite); bei Surya2 (p50 2.668,0 gegenüber 4.940,0 ms) zeigt sich mehr Initialisierungs-Overhead, der zu amortisieren ist.

Woher stammen die Latenzzahlen auf dieser Seite?

Jede Zahl ist eine Zeile der veröffentlichten results/summary_metrics.csv des First-Party-Benchmarks (latency_p50_ms, latency_p95_ms, pages_per_minute), gehostet unter ImageToTableai/benchmark-ocr, mit einem redigierten manifest.json pro Lauf, der den Messmodus (warm_then_scored), Modellversionen und Umgebungs-Fingerprints dokumentiert. Die Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Publikationen.

Methodik & Quellen

Protokoll

Diese Seite berichtet die Latenzdimension eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Umfrage von Drittangaben. Nur feste Test-Splits: SROIE 2019 Test (361 englische Belege, flache Felder Firma/Datum/Adresse/Summe) und CORD v2 Test (100 indonesische Belege, verschachtelte Felder Menü/Zwischensumme/Summe); Trainings-Splits wurden nie ausgewertet. Jedes (Engine × Datensatz)-Paar verwendete dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Aufwärmdurchlauf 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 einzelnen NVIDIA RTX 4090 (24 GB). Tesseract lief nur mit CPU (compute_type=cpu) und ist in jeder Tabelle entsprechend gekennzeichnet. Eine GPU-Stufe, ein Standort/Zeitpunkt — die Bereichsangabe auf dieser Seite.
• Engines: alle Modelle laufen out-of-the-box, ohne Fine-Tuning. Versionen gemäß 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-basiert, PaddleOCR-VL 1.6.
• Messmodus: warm_then_scored — Latenzwerte sind stationäre Inferenz pro Seite ohne Modellladen; Seiten/min ist Wanduhrzeit inklusive Modellinitialisierung (gemäß performance.run_wall_time_ms des jeweiligen Laufs in den redigierten Manifesten).
• Laufstufe: alle 16 Läufe sind official; nur offizielle Läufe sind gemäß Benchmark-Protokoll zur Veröffentlichung berechtigt (reports/receipt_v1_official_protocol.md).

Definitionen der Metriken

• p50 (Median-Latenz): die mediane Inferenzzeit pro Seite im stabilen Zustand — 50 % der Seiten waren schneller. Modell-Laden ausgenommen (warm-then-scored).
• p95 (Tail-Latenz): das 95. Perzentil der Inferenzzeit pro Seite — 5 % der Seiten dauerten länger. Spiegelt First-Page-/Prefill-Effekte und das Batch-Scheduling-Verhalten unter dem Protokoll dieses Laufs 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 für den Tail, keine Geschwindigkeitsaussage.
• Seiten pro Minute: Wanduhr-Durchsatz inklusive Modell-Initialisierung. Die Batch-Jobs- und Abrechnungssicht.
• Wanduhr-ms/Seite (abgeleitet): 60.000 ÷ Seiten/min — Arithmetik auf dem gemessenen Durchsatz, als abgeleitete Schätzung gekennzeichnet, kein Messwert.

Quellenliste

1. summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Engines × 2 Belegdatensätze (sroie_2019, cord_v2). Spalten umfassen latency_p50_ms, latency_p95_ms, pages_per_minute, compute_type, error_rate. Jede Latenz- und Durchsatzzahl auf dieser Seite stammt aus einer Zeile hier.
2. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository mit den Ergebnis-CSVs, redigierten Lauf-Manifesten, eingefrorenem Protokoll (reports/receipt_v1_official_protocol.md) und Datensatz-Stichprobenlisten (feste Test-Splits) zur Reproduktion.
3. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit Umgebungs-Fingerprint, Modellversionen, Messmodus (warm_then_scored), Wanduhrzeit und 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

• Eine GPU-Stufe, ein Standort/eine Zeit: Alle GPU-Werte stammen von einer RTX 4090 an einem Standort, erhoben im August 2026. Andere GPUs, Multi-GPU-Serving und andere Zeitplanungen verschieben Latenz und Durchsatz; messen Sie auf Ihrer eigenen Hardware, bevor Sie sich festlegen.
• Nur Belege: SROIE (Englisch) und CORD (Indonesisch) Belege. Die Latenz bei Rechnungen, Formularen, Verträgen oder langen Dokumenten ist nicht gemessen; die obigen Ranglisten sind nicht über Belege hinaus verallgemeinerbar — und die CORD-Ergebnisse sind nicht in die SROIE-Rangliste eingearbeitet.
• p95 ist protokollspezifisch: p95-Werte spiegeln First-Page-/Prefill-Effekte und Batch-Scheduling unter dem Ablaufmuster dieses Benchmarks wider (feste 361/100-Seiten-Aufteilungen, warm-up dann bewertet). Sie sind eine Formaussage dieses Laufs, keine universelle Worst-Case-Garantie.
• p50/p95 schließen Modell-Laden aus, Seiten/min schließt es ein: Die beiden Grundlagen sind bewusst unterschiedlich (Steady-State-Inferenz vs. Wanduhr-Durchsatz) und werden nie als dieselbe Zahl dargestellt. Die abgeleitete Wanduhr-Zeit pro Seite (60.000 ÷ Seiten/min) ist Arithmetik auf gemessenem Durchsatz, keine separat gemessene Größe.
• 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, Abrechnung pro Aufruf, Autoscaling) unterscheiden sich grundlegend von den hier gemessenen lokalen Engines.
• Kein Batch-Größen-Sweep: Die Init-Amortisierung wird aus der Messbasis abgeleitet (Seiten/min enthält Init, p50 schließt es aus) und mit der Methode der Kostenseite abgeglichen — es wurde kein Batch-Größen-Experiment durchgeführt, daher ist die Skalierung pro Batch eine Schätzung, keine Messung.
• Stichprobengröße und Versions-Pinning: 361 + 100 Stichproben; die Ergebnisse gelten für die oben aufgeführten Modellversionen vom August 2026. Neuere Engine-Versionen können die Latenz verschieben; einstellige Prozentunterschiede sollten als Rauschen behandelt werden.

Verwandte Referenzen: OCR-Kosten pro 1.000 Seiten · OCR-Pipelines im Vergleich zu Dokument-Parsing-VLMs · docTR vs. Surya2: CER-Gleichstand, Kostenlücke · docTR vs. Docling: Single-Pass vs. Pipeline · Tesseract vs. PaddleOCR: Legacy-CPU vs. moderne GPU

Weiterführende Lektüre: was KI-OCR-Genauigkeit tatsächlich misst · KI-Extraktion aus Bildern im Vergleich zu traditionellen OCR-Pipelines · Preise für KI-Dokumentextraktion (2026)