OCR-Kosten pro 1.000 Seiten
8 Open-Source-Engines im Benchmark (2026)

Die Kosten pro 1.000 Seiten entsprechen der abgerechneten GPU-Zeit für die Verarbeitung von 1.000 Seiten zum aufgezeichneten Stundensatz — Wanduhr-Laufzeit × 0,76 $/Stunde, wobei die Wanduhr-Zeit die Modellinitialisierung einschließt. Das gesamte Kostenranking dieser Seite wird genau so berechnet; die konkrete Rechnung finden Sie im Abschnitt So schätzen Sie Ihre eigenen Kosten sowie in der Quellenzeile jeder Tabelle.

Da die Abrechnung stundenbasiert erfolgt, folgen die Kosten der Zeit, nicht der Genauigkeit: Eine Engine, die eine Seite in 109 ms liest, kostet bei gleichem Satz etwa 25× weniger als eine, die 2.668 ms benötigt. Die Kosten jeder Engine sinken weiter, wenn die Batch-Größe wächst, da die einmalige Modellinitialisierung auf mehr Seiten umgelegt wird — die unten genannten $-Beträge spiegeln das Ausführungsmuster des Benchmarks wider (fester Test-Split, warm_then_scored-Messung) und entsprechen nicht den Kosten Ihres eigenen Laufs.

SROIE 2019: Kostenranking pro 1.000 Seiten

Bei 361 englischen Belegen liegen die traditionellen zweistufigen OCR-Engines am unteren und die Dokument-Parsing-VLMs am oberen Ende des Kostenspektrums — doch die Spanne innerhalb jeder Familie überrascht: PaddleOCR-VL, ein kompaktes 0,9B-VLM, landet bei 0,2048 $, innerhalb von 4,3× der günstigsten Engine, während sein VLM-Gegenstück Surya2 22,2× so viel kostet wie die günstigste — eine 5,2×-Spanne allein innerhalb des VLM-Clusters.

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. docTR 0,0479, EasyOCR 0,1098, PaddleOCR-VL 0,2048, PaddleOCR 0,2214, Unlimited-OCR 0,3879, Docling 0,3978, Surya2 1,0609. Tesseract nur CPU: Zelle in der CSV leer (keine abgerechneten GPU-Stunden). Kosten = Wanduhr-Laufzeit × 0,76 $/Std. (RunPod RTX 4090, Preisstand August 2026), inkl. Modellinitialisierung.

Tabelle: summary_metrics.csv — cost_per_1000_pages / pages_per_minute, sroie_2019-Zeilen (je 361 Stichproben, error_rate 0.0). GPU-Lauf bei 0,76 $/Std. (RTX 4090, Preis in Manifests zeitgestempelt); Tesseract lief nur mit CPU (leere Kosten-Zelle ist beabsichtigt — keine abgerechneten GPU-Stunden, keine Nullkosten). Kosten beinhalten die Modellinitialisierung, daher sinken die Kosten pro Seite bei größeren Batches.

Kosten folgen dem Durchsatz, nicht der Genauigkeit

Ordnet man die Engines nach Kosten und nach Zeichengenauigkeit, stimmen die beiden Rangfolgen kaum überein. Die beste rohe Textqualität auf SROIE erzielt Surya2 (CER 0,1915) — die teuerste Engine mit $1,0609 — während die zweitbeste docTR gehört (CER 0,1971) — die günstigste mit $0,0479. Kosten sind eine Rechnung für Zeit: Surya2s 12,1 Seiten/min kaufen ~37× weniger Durchsatz als docTRs 449,3 Seiten/min zum gleichen Stundensatz.

Die Architekturgewicht-Korrelation ist real, aber locker. Als Klasse liegen die Dokument-Parsing-VLMs (Surya2, Unlimited-OCR, PaddleOCR-VL) über den traditionellen zweistufigen OCR-Engines (docTR, EasyOCR, PaddleOCR), mit dem Pipeline-Parser Docling dazwischen. Aber innerhalb jeder Klasse ist die Spanne groß — der VLM-Cluster umfasst 5,2× ($0,2048 bis $1,0609) und der traditionelle Cluster 4,6× ($0,0479 bis $0,2214) — und PaddleOCR-VL, das kleinste VLM im Lauf mit 0,9B Parametern, liegt innerhalb des 4,3× der günstigsten Engine, während Surya2 22,2× beträgt. Die praktische Erkenntnis: gehen Sie davon aus, dass „genauer = teurer“ falsch ist, bis Sie es an Ihren eigenen Dokumenten messen; in diesem Benchmark ist die Beziehung zwischen Kostenrang und Genauigkeitsrang praktisch entkoppelt.

Quelle: summary_metrics.csv — Spalte pages_per_minute, Zeilen sroie_2019. Wanduhr-Seiten/min inklusive Modellinitialisierung. Tesseract lief nur auf CPU (78,6 Seiten/min auf CPU-Hardware).

Tabelle: summary_metrics.csv — cer / latency_p50_ms / pages_per_minute / cost_per_1000_pages, sroie_2019-Zeilen. Kostenverhältnisse durch einfache Division gegen docTR’s 0.0479 berechnet (z. B. 1.0609 / 0.0479 = 22.16). CER für Surya2 muss mit dem Case-Folding-Vorbehalt in der Methodik gelesen werden (VLM-Ausgaben sind case-normalisiert; CER überzeichnet VLM-Fehler). Tesseract’s Latenz basiert auf CPU-Hardware; seine Kostenzelle ist absichtlich leer (keine GPU-Abrechnung).

Die Latenzspalte ergänzt die Perspektive interaktiver Workloads: Kosten pro Volumen und Latenz pro Seite sind zwei Sichtweisen auf dieselbe Wall-Clock-Tatsache. docTRs p50 von 108,7 ms macht es sowohl am günstigsten pro 1.000 Seiten als auch die einzige Engine nahe der interaktiven Antwortzeit; Surya2s p50 von 2.668 ms macht es sowohl am teuersten als auch einen reine-Batch-Workload auf Belegen. Die Latenzdetails werden im begleitenden 8-Engine-Roundup analysiert.

CORD (indonesische Belege): Kosten sind datensatzabhängig

Tauscht man den Dokumentensatz, verschiebt sich die Kostenrangfolge — das beweist, dass die Kosten pro 1.000 Seiten keine Engine-Konstante sind. Auf CORD v2 wird EasyOCR zur günstigsten Engine ($0,0863) und docTR rutscht auf Platz zwei ($0,0939), während die Anker an beiden Enden halten: docTR bleibt nahe dem unteren Ende und Surya2 bleibt am teuersten ($1,1616). Die CORD-Spanne verengt sich auf 13,5×.

Der Mechanismus ist der Durchsatz auf dem tatsächlichen Dokumentensatz: CORDs indonesische Belege sind kürzer und weniger textdicht als SROIEs englische, sodass sich die Seiten-pro-Minute jeder Engine ändert und die Kosten pro 1.000 Seiten folgen. Die beiden Datensätze werden in diesem Benchmark bewusst getrennt gehalten — CORD trägt zudem eine Anmerkungsstruktur-Inflation in seiner Ground Truth, die seine CER-Werte unzuverlässig macht (siehe Methodik) — behandeln Sie die SROIE- und CORD-Spalten also als zwei unabhängige Datenpunkte, nicht als eine Rangliste.

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen cord_v2. EasyOCR 0,0863, docTR 0,0939, Unlimited-OCR 0,2063, PaddleOCR-VL 0,2409, PaddleOCR 0,3419, Docling 0,5382, Surya2 1,1616. Tesseract nur CPU (leere Zelle). Gleiche RTX 4090 @ $0,76/Std. (Preis zeitgestempelt), Kosten inkl. Modell-Init.

Tabelle: summary_metrics.csv — cost_per_1000_pages, cord_v2-Zeilen (je 100 Stichproben). CORD wird getrennt vom SROIE-Ranking geführt (andere Sprache, andere Ground-Truth-Struktur); der Vergleich soll zeigen, dass die Kosten pro 1.000 Seiten mit dem Dokumentensatz variieren, nicht dass ein Ranking „gewinnt“.

Monatliche Volumenszenarien (abgeleitete Schätzungen)

Die Werte pro 1.000 Seiten multiplizieren sich direkt in die Volumenrechnung, die Budgetverantwortliche benötigen. Bei 100.000 Seiten/Monat auf der SROIE-Kostenbasis beträgt die GPU-Zeit von docTR 4,79 $/Monat und die von Surya2 106,09 $/Monat — eine Differenz von rund 101 $/Monat, die sich bei 1 Million Seiten auf etwa 1.013 $/Monat ausweitet. Dies sind arithmetische Erweiterungen der gemessenen Werte pro 1.000 Seiten, keine zusätzlichen Läufe.

Tabelle: Abgeleitete Schätzungen auf der SROIE-2019-Kostenbasis — keine gemessenen Läufe. Jede Zelle ist eine einfache Multiplikation der gemessenen cost_per_1000_pages (docTR 0,0479, Surya2 1,0609; summary_metrics.csv sroie_2019-Zeilen) mit dem Volumen in Tausend, zum gleichen RTX-4090-Satz von 0,76 $/Std., Preisstand August 2026. Nur GPU-Zeit — keine CPU, kein Speicher, kein Egress, keine Orchestrierung und keine LLM-Nachbearbeitung. Bei 10 Millionen Seiten/Monat erreicht Surya2 allein auf dieser Basis rund 10.609 $/Monat (10.000 × 1,0609 $).

Tesseracts reales Kostenprofil: Keine GPU-Rechnung, aber nicht kostenlos

Tesseract ist die einzige reine CPU-Engine im Benchmark, und seine Kosten-Zelle ist bewusst leer — es verbrauchte keine abgerechneten GPU-Stunden, also gibt es nichts zu $0,76/Std. abzurechnen. Das ist nicht dasselbe wie kostenlos: Die CPU-Infrastruktur, auf der es läuft (eigene Hardware oder eine gemietete CPU-Instanz), ist ein realer Kostenfaktor, den dieser Benchmark nicht beziffert, und seine Feld-Extraktionsgrenze kann die Kosten nachgelagert in die Höhe treiben.

Bei SROIE hielt Tesseract auf der CPU weiterhin 78,6 Seiten/Min. — mehr als vier der sieben GPU-Engines (PaddleOCR-VL 68,2, Docling 56,7, Unlimited-OCR 34,4, Surya2 12,1). Bei geringem Volumen auf bereits bereitgestellter CPU-Infrastruktur ist das wirklich kosteneffizient: keine GPU-Miete. Der Haken zeigt sich, wenn Felder und nicht nur Text das Ergebnis sind: Tesseracts schwacher Basistext begrenzt, was eine nachgelagerte LLM wiederherstellen kann — sein CORD-LLM-Feld-F1 liegt bei 0,163 bei einem CORD-CER von 0,9523 (field_method_comparison.csv, Zeile tesseract/cord_v2) — die GPU-Ersparnis kann also durch Ausgaben für Nachbearbeitung und Korrektur anderswo zunichtegemacht werden. Der CPU-vs.-GPU-Kompromiss ist Thema des eigenen Tesseract vs. PaddleOCR-Vergleichs; die Grenze der Nachbearbeitung wird im Vergleich regelbasierter vs. LLM-Extraktion behandelt.

Pipeline-Kosten ≠ Engine-Kosten: Die Grenze der LLM-Nachbearbeitung

Jede Zahl auf dieser Seite ist die GPU-Rechnung der OCR-Engine und sonst nichts. Produktions-Pipelines zur Extraktion fügen dem OCR-Text häufig einen LLM-Feldextraktionsschritt hinzu — der Benchmark führte einen aus (deepseek-v4-flash) über alle 16 Läufe — und dieser Schritt ist eine separate, tokenbasierte API-Kosten, die in keiner Engine-Zahl hier auftaucht.

Die Vergleichs-CSV erfasst die Token-Anzahlen für den Nachbearbeitungsschritt bei SROIE — z. B. kostete der OCR-Text von docTR 151.131 Prompt- + 25.377 Completion-Token, um die vier Belegfelder zu extrahieren — und diese Token-Anzahlen sind die Grundlage für die Schätzung der Zusatzkosten. Diese Seite rechnet Token bewusst nicht in Dollar um: LLM-Preise variieren je nach Anbieter, Plan und Modell, und jede Dollarzahl wäre sofort veraltet. Engine-Kosten und Pipeline-Kosten sind zwei Posten im Budget; der LLM-Posten hängt von Ihrem Prompt-Design und Anbieter ab, nicht von der OCR-Engine.

Tabelle: field_method_comparison.csv — llm_prompt_tokens / llm_completion_tokens, sroie_2019 rows; llm_model = deepseek-v4-flash. Die Token-Zahlen decken einen Feld-Extraktionsdurchlauf (vier Belegfelder) über den 361-seitigen SROIE-Test-Split ab. Sie dienen als Grundlage zur Schätzung der LLM-Nachbearbeitungskosten; eine Dollar-Umrechnung wird nicht angegeben, da die LLM-Preise je nach Anbieter und Tarif variieren.

So schätzen Sie Ihre eigenen Kosten

Sie müssen keinen 8-Engine-Benchmark erneut ausführen, um eine belastbare Kostenschätzung für Ihre eigene Arbeitslast zu erhalten. Die Methode des Benchmarks — Wanduhrzeit × Ihr Stundensatz — lässt sich in vier Schritten und einem durchgerechneten Beispiel reproduzieren.

Dies ist eine überschlägige Methode, die aus der eigenen Kostenbasis des Benchmarks abgeleitet ist (Wanduhrzeit × Satz, inkl. Modellinitialisierung); sie ist keine Finanzberatung, und Ihre genauen Zahlen variieren je nach Hardware, Dokumentmischung, Batch-Größen und Auslastung. Der Satz von $0,76/Std. ist ein zeitgestempelter On-Demand-Preis von August 2026 — leiten Sie ihn zu aktuellen Sätzen neu ab.

Häufig gestellte Fragen

Wie viel kostet OCR pro 1.000 Seiten?

Zwischen $0,048 (docTR) und $1,061 (Surya2) pro 1.000 Seiten auf SROIE 2019, gemessen auf einer RTX 4090 bei $0,76/Std. mit Preisstand August 2026 (summary_metrics.csv cost_per_1000_pages, sroie_2019-Zeilen). Die Kosten beinhalten die Modellinitialisierung, daher sinken die Kosten pro Seite mit wachsender Batch-Größe. Auf CORD v2 liegen dieselben Engines zwischen $0,086 (EasyOCR) und $1,162 (Surya2).

Welche Open-Source-OCR-Engine ist am günstigsten im Betrieb?

docTR war die günstigste GPU-Engine mit $0,0479 pro 1.000 Seiten auf SROIE (449,3 Seiten/Min., summary_metrics.csv doctr/sroie_2019-Zeile) — und der Vorbehalt zur Datensatzabhängigkeit ist wichtig: Auf CORD v2 lag EasyOCR ($0,0863) knapp vor docTR ($0,0939). Die Antwort auf „am günstigsten“ hängt von Ihrem Dokumentbestand ab; die Anker (docTR nahezu am niedrigsten, Surya2 hoch) blieben auf beiden Datensätzen stabil.

Warum ist die schnellste Engine auch die günstigste?

Weil die Rechnung auf Wanduhr-Stunden zu $0,76/Std. basiert: Die Engine, die eine Seite in 109 ms verarbeitet (docTR), zahlt ~1/25 der Stunden, die eine 2.668-ms-Engine (Surya2) pro Seite zahlt (summary_metrics.csv latency_p50_ms / cost_per_1000_pages, sroie_2019-Zeilen). Bei gemessener GPU-Abrechnung ist Durchsatz gleich Kosten — weshalb die Kosten- und die Durchsatz-Rangfolge nahezu Spiegelbilder sind.

Ist Tesseract OCR kostenlos?

Nein — Tesseract ist nur für CPU ausgelegt, verbraucht also keine abgerechneten GPU-Stunden, und seine Kosten-Zelle ist in der Benchmark-CSV bewusst leer, aber das ist keine Null: Die CPU-Infrastruktur, auf der es läuft, verursacht reale Kosten, und seine Obergrenze bei der Felderkennung (CORD-LLM-Feld-F1 0,163, field_method_comparison.csv tesseract/cord_v2-Zeile) kann die Ausgaben in die nachgelagerte Nachbearbeitung treiben. Bei geringem Volumen auf bereits bereitgestellter CPU-Hardware kann es durchaus kosteneffektiv sein — 78,6 Seiten/Min. auf SROIE, schneller als vier der sieben GPU-Engines — aber „keine GPU-Rechnung“ und „kostenlos“ sind zwei verschiedene Aussagen.

Warum ist Surya2 pro 1.000 Seiten so teuer?

Weil es die langsamste Engine im Benchmark ist: 12,1 Seiten/min bei SROIE bedeutet die meisten Wall-Clock-Stunden pro 1.000 Seiten zum gleichen Satz von 0,76 $/Std. (summary_metrics.csv pages_per_minute / cost_per_1000_pages, surya2/sroie_2019-Zeile). Bemerkenswert ist auch, dass es die beste Zeichengenauigkeit hat (CER 0,1915) — das klarste Beispiel des Benchmarks dafür, dass Kosten der Zeit folgen, nicht der Genauigkeit.

Sinken die OCR-Kosten pro Seite mit wachsendem Volumen?

Ja, bis zu einer Untergrenze. Die Kosten hier umfassen die Modellinitialisierung, die einmal pro Prozess/Batch bezahlt wird; der docTR-Lauf des Benchmarks zahlte die Initialisierung innerhalb von 81.867 ms für 361 Seiten (manifest performance.run_wall_time_ms), sodass bei 1 Million Seiten diese Initialisierung auf nahezu null verdünnt wird und die Kosten sich dem reinen Steady-State-Durchsatz annähern. Die Untergrenze sind die Steady-State-Kosten selbst — docTRs 0,0479 $/1K bei SROIE liegt bereits nahe seiner Untergrenze; Surya2s 1,0609 $ spiegelt wirklich langsame Steady-State-Inferenz wider, nicht nur Initialisierungs-Overhead.

Was ist in diesen Zahlen pro 1.000 Seiten nicht enthalten?

LLM-Nachbearbeitung (separate API-Kosten pro Token; Tokenzahlen in field_method_comparison.csv), CPU/Infrastruktur für Tesseract-artige Stacks, Speicher und Egress, Orchestrierung, GPU-Auslastungslücken und Cloud-/API-OCR-Dienste — nichts davon ist in der GPU-Rechnung der Engine enthalten, die diese Zahlen darstellen. Cloud-APIs rechnen auch pro Aufruf mit funktionsabhängiger Preisgestaltung ab, ein anderes Kostenmodell als gemietete GPU-Wall-Clock-Zeit; sie werden auf dieser Seite nicht benchmarkt.

Woher stammen diese Zahlen?

Jede Zahl ist eine Zeile der veröffentlichten CSVs des First-Party-Benchmarks — results/summary_metrics.csv (Kosten pro 1.000 Seiten, Durchsatz, Latenz, Genauigkeit) und results/field_method_comparison.csv (LLM-Postprocessor-Tokens und Feld-F1) — gehostet unter ImageToTableai/benchmark-ocr, mit einer redigierten manifest.json pro Lauf, die den Satz von 0,76 $/Std., den Preiszeitstempel vom August 2026, Modellversionen und Umgebungs-Hashes dokumentiert.

Methodik & Quellen

Protokoll

Diese Seite berichtet die Kostendimension eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Umfrage zu Behauptungen Dritter. 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).

Laufzeitumgebung und Kostenbasis

• Hardware: alle GPU-Läufe auf einer NVIDIA RTX 4090 (24 GB); GPU-Kosten zum RunPod-On-Demand-Satz von $0.76/Std. berechnet, mit dem Preiszeitstempel (price_recorded_at_utc 2026-08-13T08:00:00Z) in jedem Lauf’s redigierten Manifest. Tesseract lief nur auf CPU und hat keine GPU-Kosten (leere Kosten-Zelle in der CSV — beabsichtigt, keine Null).
• Kostenformel: Kosten pro 1.000 Seiten = Wanduhr-Laufzeit × $0.76/Std. × (1.000 / verarbeitete Seiten), einschließlich Modellinitialisierung. Verifiziert durch das durchgerechnete docTR-Beispiel im Abschnitt So schätzen Sie (81.867 ms → $0,0479/1K).
• Engines: alle Modelle laufen out-of-the-box, ohne Feintuning. Versionen gemäß den Lauf-Manifesten gesperrt (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).
• LLM-Nachbearbeitung: deepseek-v4-flash per API bei Temperatur 0 (Spalte llm_model in field_method_comparison.csv); deren Token-Zahlen werden als Basis für separate Pipeline-Kosten berichtet — die OCR-Engine-Kosten enthalten sie nie.
• Feld-Nachbearbeitung: SROIE-Feldmetriken sind postprocessed_sroie_receipt_regex_* / LLM-Varianten — Felder aus OCR-Text extrahiert, nicht aus nativer strukturierter Ausgabe.
• CORD-Hinweis: CORD-Ground-Truth-Text enthält Annotationsstruktur, die das rohe CER für jede Engine erhöht; CORD-Zeilen werden daher getrennt von SROIE-Rankings gehalten. Kostenwerte (wanduhrbasiert) sind von der CER-Einschränkung nicht betroffen, aber beide Datensätze sind dennoch nur Belege.

Metrikdefinitionen

• Kosten pro 1.000 Seiten: abgerechnete GPU-Stunden für 1.000 Seiten zum aufgezeichneten Satz von 0,76 $/Std., Wanduhrzeit inklusive Modellinitialisierung. Leer für reines CPU-Tesseract.
• Seiten pro Minute: Wanduhr-Durchsatz inklusive Modellinitialisierung.
• Latenz p50/p95: Inferenzzeit pro Seite im stabilen Zustand (warm, dann bewertet; ohne Modellladezeit).
• CER/WER: Editierdistanz (Einfügungen + Löschungen + Ersetzungen) über die Ground-Truth-Zeichen/-Wörter. Empfindlich gegenüber Groß-/Kleinschreibung und Formatierungskonventionen — VLM-Ausgaben werden normalisiert, daher überschätzt CER den VLM-Fehler (siehe Übersichtsseite).
• Feldwert-F1: harmonisches Mittel aus Präzision und Recall über extrahierte Feldwerte, pro Nachbearbeitungsstufe (Regex oder LLM).

Quellenliste

1. summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Engines × 2 Belegdatensätze (sroie_2019, cord_v2). 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 Kosten-, Durchsatz-, Latenz- und CER-Angabe auf dieser Seite stammt aus einer Zeile 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, llm_prompt_tokens, llm_completion_tokens. Jede Tokenanzahl und LLM-Feld-F1-Angabe stammt aus einer Zeile hier.
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository mit den Ergebnis-CSVs, redigierten Laufmanifesten, eingefrorenem Protokoll und Datensatz-Stichprobenlisten (feste Test-Splits) zur Reproduktion.
4. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit Umgebungs-Fingerabdruck, Modellversionen, Kostenmetadaten (gpu_hourly_usd, price_recorded_at_utc), Wanduhrzeit 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

• Eine einzige GPU-Stufe und ein einziger Preiszeitpunkt: Alle GPU-Zahlen stammen von einer RTX 4090 bei 0,76 $/Std., Preis erfasst im August 2026. GPU-Spot-/On-Demand-Preise ändern sich — zu aktuellen Tarifen neu ableiten; andere GPUs, Multi-GPU-Serving und Batch-Planung verschieben Durchsatz und Kosten.
• Nur Belege: SROIE (englisch) und CORD (indonesisch) Belege. Kosten, Durchsatz und Genauigkeit bei Rechnungen, Formularen, Verträgen oder langen Dokumenten sind nicht gemessen; die obigen Ranglisten sind nicht über Belege hinaus verallgemeinerbar.
• Kosten enthalten Modell-Initialisierung — abhängig von der Batch-Größe: Die Zahlen spiegeln das Laufmuster des Benchmarks wider (feste 361/100-Seiten-Aufteilungen, warm-then-scored). Kleinere Batches zahlen die Initialisierung wiederholt und kosten mehr pro 1.000 Seiten; größere Batches nähern sich dem stationären Minimum an.
• CPU/GPU-Asymmetrie: Tesseract (CPU) wird mit GPU-beschleunigten Engines verglichen. Sein Kostenvorteil spiegelt fehlende GPU-Abrechnung wider, nicht fehlende Kosten — CPU-Infrastruktur, Strom und Personalzeit sind nicht quantifiziert, und seine Feld-Erkennungsgrenze (CORD-LLM-Feld-F1 0,163) kann Ausgaben in die Nachbearbeitung verschieben.
• Keine Cloud-/API-Modelle: AWS Textract, Google Document AI, Azure AI Document Intelligence und gehostete OCR-/VLM-APIs sind nicht enthalten; ihre aufruf- und funktionsbasierte Preisgestaltung unterscheidet sich grundlegend von der Abrechnung nach Wanduhrzeit für gemietete GPUs, und es wird kein Vergleich impliziert.
• Auslastung und Leerlaufzeiten nicht modelliert: Die Zahlen gehen davon aus, dass die GPU für die Wanduhrzeit des Laufs abgerechnet wird und sonst ungenutzt ist; reale Bereitstellungen mit Leerlauf-, Multi-Tenant- oder unterausgelasteten GPUs haben andere effektive Kosten.
• LLM-Nachbearbeitungskosten nicht in Dollar umgerechnet: Token-Anzahlen (field_method_comparison.csv) sind die Grundlage; LLM-Preise variieren je nach Anbieter und Plan und bleiben bewusst dem Leser überlassen.
• Abgeleitete Szenarien nicht gemessen: Die monatliche Volumentabelle ist einfache Arithmetik auf Basis der SROIE-Kosten, gekennzeichnet als abgeleitete Schätzungen — keine zusätzlichen Benchmark-Läufe.
• Stichprobengröße und Versions-Pinning: 361 + 100 Stichproben; Ergebnisse gelten für die oben aufgeführten Modellversionen vom August 2026. Neuere Engine-Versionen können Kosten/Durchsatz verschieben; Unterschiede im einstelligen Prozentbereich sollten als Rauschen behandelt werden.

Verwandte Referenzen: Traditionelle OCR vs. Dokument-Parsing-VLMs · docTR vs. Surya2: CER-Gleichstand, Kostenschere · Tesseract vs. PaddleOCR: CPU-Kostenprofil · wie Regex und LLMs Felder extrahieren · Aufschlüsselung der Dokumentverarbeitungskosten

Weiterführende Lektüre: KI-Dokumentextraktions-Preise (2026) · feldgenaue Genauigkeit bei KI-OCR vs. traditioneller OCR · wie KI-Vision-Extraktion Bilder anders liest als OCR