„Warum ist OCR so langsam?“
3 Ursachen für langsame Batch-Verarbeitung – und wie Sie jede einzelne beheben
Die meisten OCR-Benchmarks sehen auf dem Papier gut aus. Tesseract verspricht Seiten in unter einer Sekunde. EasyOCR auf einer GPU schafft 190 Seiten pro Minute. Dann führen Sie Ihren eigenen Batch aus – 200 Lieferantenrechnungen, eine Mischung aus Handyfotos und gescannten PDFs – und plötzlich dauert jede Seite 30 Sekunden. Das Wochenende ist weg. Der Engpass liegt fast immer an einer von drei Ursachen. So finden Sie Ihre heraus.
Die wichtigsten Erkenntnisse
- 30 Sekunden pro Seite bei einem Batch von 200 Rechnungen – während dieselbe OCR-Engine im Benchmark unter einer Sekunde liegt – ist kein Fehler, sondern drei unabhängige Verlangsamungen, die sich in Ihrer Pipeline still summieren.
- Drei Multiplikatoren summieren sich in Ihrer Pipeline – keine GPU verlangsamt Sie um das 3- bis 7-fache, überdimensionierte Bilder fügen eine 4-fache Strafe hinzu, und sequenzielle Verarbeitung lässt drei Viertel Ihrer CPU ungenutzt – und jede Ursache kann in Minuten diagnostiziert und dann unabhängig behoben werden.
- Wenn Sie alle drei Lösungen ausgeschöpft haben und Ihr Batch immer noch über eine Stunde dauert, liegt der Engpass nicht mehr in der Pipeline – der schnellste verbleibende Schritt ist ein Architekturwechsel, nicht das weitere Drehen an Stellschrauben.
Symptom. Ihre CPU erreicht während der Verarbeitung 100 % Auslastung, und jede Seite dauert bei sauberen Dokumenten deutlich über eine Sekunde. Der Durchsatz verbessert sich nicht, wenn Sie mehr Dateien zu einem Batch hinzufügen – die Pipeline ist gesättigt.
Ursache. Nicht alle OCR-Engines sind unter der Haube gleich. Tesseract, der von Google gepflegte Open-Source-Benchmark, ist eine reine CPU-basierte Engine. Sie verwendet traditionelle Computer-Vision-Pipelines – Connected-Component-Analyse, Seitenlayout-Analyse und LSTM-basierte Zeichenerkennung – von denen keine GPU-Parallelität nutzt. Ein Benchmark eines Forschers maß Tesseract 5 mit etwa 0,8 Sekunden pro Seite auf einer modernen CPU mit sauberem Drucktext. Für ein paar Seiten akzeptabel. Bei 500 Seiten schmerzhaft.
EasyOCR verfolgt einen anderen architektonischen Ansatz. Sein Deep-Learning-Backbone (CRAFT-Textdetektion + ein PyTorch-Erkennungsnetzwerk) kann auf der GPU laufen – und wenn es das tut, ist es dramatisch schneller. Aber hier ist der Haken, den die meisten übersehen: EasyOCR fällt automatisch auf die CPU zurück, wenn keine kompatible GPU erkannt wird. Auf der CPU macht dieselbe Deep-Learning-Pipeline, die EasyOCR genau macht, es auch drei- bis viermal langsamer als im GPU-Modus. Benchmarks auf einer NVIDIA T4 zeigen EasyOCR GPU bei ~0,6 Sekunden pro Seite – vergleichbar mit Tesseract – während EasyOCR CPU auf ~2,5 Sekunden pro Seite kommt.
Die Lösung. Prüfen Sie, ob Ihre OCR-Pipeline tatsächlich eine GPU verwendet:
- Für EasyOCR: Stellen Sie sicher, dass
reader = easyocr.Reader(['en'], gpu=True)CUDA tatsächlich erkennt. Wenn die Bibliothek stillschweigend zurückfällt, verdoppelt sich Ihre Zeit pro Seite oder mehr. Führen Sie während der Verarbeitungnvidia-smiaus – wenn die GPU-Auslastung 0 % anzeigt, läuft Ihre Pipeline auf der CPU. - Für Tesseract gibt es keinen GPU-Umschalter – es unterstützt einfach keine GPU-Beschleunigung. Wenn Sie mehr als ein paar hundert Seiten verarbeiten, sollten Sie auf eine GPU-fähige Engine umsteigen.
- Spezielle OCR-Engines wie PaddleOCR sind von Grund auf für GPU gebaut. Unabhängige Geschwindigkeits-Benchmarks setzen PaddleOCR auf einer RTX 3090 bei etwa 190 Seiten pro Minute an – über 3 Seiten pro Sekunde – dank optimierter Batch-Inferenz und CUDA-Integration.
Wenn Ihre Hardware festgelegt ist (Laptop ohne diskrete GPU, gemeinsam genutzter Server, Cloud-VM ohne GPU), steht Ihnen der GPU-Pfad nicht direkt zur Verfügung. In diesem Fall umgeht ein cloudbasierter OCR-Dienst, der Dokumente auf GPU-gestützter Infrastruktur verarbeitet – ohne dass Sie die Hardware bereitstellen müssen – das Problem vollständig.
Für einen direkten Vergleich GPU-fähiger OCR-Engines siehe unsere Übersicht der besten Open-Source-OCR-Tools.
Ursache Nr. 2: Bilder, die weitaus größer sind, als es die OCR tatsächlich benötigt
Symptom. Die Verarbeitung kommt bei Seiten, die für Sie vollkommen lesbar aussehen, zum Stillstand. Ein 12-Megapixel-Handyfoto einer Quittung benötigt 5–8 Sekunden, während ein gescanntes PDF desselben Dokuments weniger als 2 Sekunden benötigt.
Ursache. Die meisten OCR-Engines verarbeiten jedes Pixel im Bild. Verdoppeln Sie die Auflösung auf jeder Achse – von 150 DPI auf 300 DPI – und Sie vervierfachen die Pixelanzahl: 2x die Breite mal 2x die Höhe. Eine Vervierfachung der Eingabe bedeutet eine etwa 4-fache Verarbeitungszeit für denselben Inhalt. Ein Smartphone-Foto mit 4000×3000 Pixeln enthält 12 Millionen Pixel. Dasselbe Dokument, gescannt mit 300 DPI (bei Briefgröße etwa 2550×3300), enthält 8,4 Millionen. Ein Dokument, gescannt mit 200 DPI – für die meisten OCR völlig ausreichend – enthält nur 3,7 Millionen Pixel.
Der ABBYY FineReader Engine Performance Guide, eines der maßgeblichsten Dokumente zur OCR-Leistungsoptimierung, gibt 200–400 DPI als empfohlenen Eingabebereich an. Unter 150 DPI verschlechtert sich die Zeichenerkennung. Über 400 DPI zahlen Sie Rechenzeit für keinen messbaren Genauigkeitsgewinn. Das gleiche Prinzip gilt für jede OCR-Engine, ob Open Source oder proprietär.
Die Lösung. Fügen Sie einen Vorverarbeitungsschritt hinzu, der Bilder vor der Übergabe an die OCR-Engine verkleinert. Das Ziel sind 150–300 DPI auf dem Ausgabebild – bei einem typischen Dokument etwa 1200–2500 Pixel auf der längsten Seite.
Eine einfache Python-Vorverarbeitungspipeline mit Pillow:
from PIL import Image
def resize_for_ocr(image_path, max_dim=2000):
img = Image.open(image_path)
# Nur verkleinern, niemals vergrößern
if max(img.size) > max_dim:
ratio = max_dim / max(img.size)
new_size = (int(img.size[0] * ratio),
int(img.size[1] * ratio))
img = img.resize(new_size, Image.LANCZOS)
return imgDieser einzelne Schritt kann die Verarbeitungszeit pro Seite je nach Quellbild um 40–70 % senken, ohne Auswirkungen auf die Extraktionsgenauigkeit. Eine vollständige Anleitung zur Bildvorbereitung – einschließlich Binarisierung, Entzerrung und Kontrastnormalisierung – finden Sie in unserem OCR-Leitfaden zur Bildvorverarbeitung.
Ursache Nr. 3: Sequenzielle Verarbeitung, obwohl Sie parallel arbeiten könnten
Symptom. Die CPU-Auslastung liegt während eines Batch-Laufs bei etwa 30–40 %. Die Pipeline verarbeitet Dateien einzeln nacheinander – Sie beobachten, wie der Fortschrittsbalken Datei für Datei vorrückt, ohne dass es je schneller wird.
Ursache. Die meisten OCR-Pipelines sind als einfache Schleifen geschrieben: for file in files: ocr. Dies ist standardmäßig single-threaded. Moderne CPUs haben 4, 8 oder 16 Kerne, aber eine sequenzielle Schleife nutzt genau einen davon. Die anderen Kerne bleiben untätig, während sich Seiten in der Warteschlange stapeln.
Die Lösung ist embarrassingly parallel – die OCR einer Seite ist unabhängig von der OCR jeder anderen Seite. Es gibt keinen gemeinsamen Zustand, der synchronisiert werden müsste. Das bedeutet, dass Sie auf einer Maschine mit N Kernen N Seiten gleichzeitig verarbeiten können und theoretisch einen N-fachen Durchsatz erreichen. In der Praxis ist die Skalierung bis zu 4–8 Kernen nahezu linear, darüber hinaus mit abnehmendem Nutzen aufgrund von Speicherbandbreite und I/O-Konflikten.
Die Lösung. Wickeln Sie Ihren OCR-Aufruf in ein paralleles Ausführungs-Framework:
- GNU Parallel (Linux/macOS): Der einfachste Ansatz für skriptbasierte Pipelines.
parallel -j 4 ocrmypdf {} output/{} ::: *.pdfführt vier OCR-Prozesse gleichzeitig aus. - Python multiprocessing: Verwenden Sie
multiprocessing.Pool, um Dateien auf Worker-Prozesse zu verteilen. Jeder Worker erhält seine eigene OCR-Engine-Instanz, und die Ergebnisse werden gesammelt, sobald sie fertig sind. - Batch-Verarbeitungswerkzeuge: Spezielle Batch-OCR-Tools wie OCRmyPDF unterstützen integrierte Parallelverarbeitung. Der Parameter
--jobssteuert die Parallelität. Die Kombination mit GNU Parallel (Begrenzung auf 2 Jobs, um eine I/O-Sättigung zu vermeiden) ist ein dokumentiertes Produktionsmuster.
Der wichtigste praktische Aspekt: Jeder parallele Worker benötigt genügend Arbeitsspeicher, um das Bild seiner Seite und die Zwischenpuffer zu halten. Wenn Sie 8 Worker auf einer Maschine mit 8 GB RAM ausführen, führt dies zu Swapping. Ein sicherer Ausgangspunkt sind 2 GB RAM pro parallelem Worker für Standard-Dokumentbilder. Skalieren Sie die Parallelität entsprechend Ihrem Speicherbudget, bevor Sie die CPU-Kernanzahl erreichen.
Eine vollständige Anleitung zur Einrichtung paralleler Batch-Pipelines finden Sie in unserem Leitfaden zur Batch-Verarbeitung mehrerer Dateien.
Wann Sie eskalieren sollten – Werkzeuge wechseln statt Feinabstimmung
Wenn Sie alle drei Ursachen geprüft haben – Ihre GPU ist aktiv, Ihre Bilder sind korrekt skaliert und Ihre Pipeline läuft parallel –, die Verarbeitung aber für Ihre Arbeitslast immer noch zu langsam ist, liegt der Engpass möglicherweise eher in der Architektur als in der Konfiguration.
Drei Signale deuten darauf hin, dass es an der Zeit ist, einen grundlegend anderen Ansatz in Betracht zu ziehen:
1. Ihr Volumen ist konstant hoch. Wenn Sie täglich 500+ Seiten verarbeiten und die Batch-Abschlusszeit ein wiederkehrender Schmerzpunkt ist, wird die Feinabstimmung einer lokalen OCR-Pipeline immer hinter dem zurückbleiben, was ein speziell entwickelter Cloud-Dienst leisten kann. Cloud-Extraktionsdienste laufen auf GPU-Clustern in Serverqualität mit automatischem Lastausgleich – ein einzelner Batch kann auf Dutzende paralleler Worker verteilt werden, ohne dass Sie Hardware bereitstellen müssen.
2. Ihre Dokumente sind vielfältig und unverarbeitet. Eine Pipeline, die für gescannte PDFs optimiert ist, wird bei Handyfotos, zerknitterten Belegen oder Dokumenten mit Handschrift Probleme bekommen. Jeder neue Eingabetyp erfordert unterschiedliche Vorverarbeitungsparameter. ImageToTable.ai verwendet Vision-Language-Modelle, die Dokumente semantisch lesen – die Seitenstruktur so interpretieren, wie es ein Mensch tun würde, ohne dass eine anpassung pro Dokumenttyp erforderlich ist. Es ist kein separater Vorverarbeitungsschritt zur Auflösungsnormalisierung erforderlich, da die Cloud-Pipeline die Skalierung vor der Inferenz automatisch übernimmt.
3. Sie benötigen Ergebnisse in Minuten, nicht in Stunden. Wenn ein Batch von 300 Seiten während einer Mittagspause verarbeitet und exportiert werden muss, wird eine sequenzielle lokale Pipeline – selbst eine für Geschwindigkeit optimierte – nicht liefern. Cloud-Batch-Verarbeitung parallelisiert über das gesamte Dokumentvolumen. Ein 300-Seiten-Batch, der auf einem einzelnen CPU-basierten Rechner 3–4 Stunden dauert, kann auf Cloud-Infrastruktur, die dieselbe Arbeit auf 20–40 parallelen GPU-Workern ausführt, in 5–10 Minuten abgeschlossen werden.
Häufig gestellte Fragen
Ist Tesseract schneller als EasyOCR?
Auf der CPU ist Tesseract in der Regel schneller – etwa 0,8 Sekunden pro Seite gegenüber 2,5 Sekunden pro Seite bei EasyOCR für sauberen gedruckten Text. Auf der GPU kehrt sich der Vergleich um: EasyOCR auf einer NVIDIA GPU läuft mit etwa 0,6 Sekunden pro Seite und erreicht oder übertrifft damit den Durchsatz von Tesseract, während es bei degradierten Bildern, handschriftlichen Anmerkungen und gemischten Layouts deutlich bessere Genauigkeit liefert. Die praktische Schlussfolgerung: Wenn Sie eine GPU haben, verwenden Sie EasyOCR (oder PaddleOCR). Wenn Sie nur eine CPU haben, bietet Tesseract einen besseren Durchsatz für saubere Dokumente, aber erwarten Sie eine geringere Genauigkeit bei komplexen Eingaben.
Welche Bildauflösung ist am besten für die OCR-Geschwindigkeit?
200–300 DPI ist der optimale Bereich für die meisten OCR-Engines. Unter 150 DPI sinkt die Zeichenerkennungsgenauigkeit merklich, insbesondere bei kleinen Schriftgrößen. Über 400 DPI zahlen Sie das 2- bis 4-fache an Verarbeitungszeit für einen vernachlässigbaren oder gar keinen Genauigkeitsgewinn. Für ein Standard-Dokument im Letter-Format (8,5"×11") erzeugt 200 DPI ein Bild von etwa 1700×2200 Pixeln – etwa 3,7 Megapixel. Das ist weitaus kleiner als ein typisches Smartphone-Foto und wird in einem Bruchteil der Zeit verarbeitet.
Kann ich mehrere GPUs verwenden, um OCR zu beschleunigen?
Ja, wenn Ihre OCR-Engine dies unterstützt und Ihr Arbeitsaufwand groß genug ist, um davon zu profitieren. PaddleOCR und EasyOCR können auf mehrere GPUs verteilt werden, indem verschiedene Dokumentenstapel verschiedenen GPU-Instanzen zugewiesen werden. In der Praxis verarbeitet eine einzelne moderne GPU (RTX 3090 oder höher) bereits 150–190 Seiten pro Minute für Standarddokumente, sodass Multi-GPU-Setups nur bei sehr hohen Volumina (10.000+ Seiten pro Tag) erforderlich sind. Der Hauptengpass verschiebt sich in diesem Maßstab von der Rechenleistung zum I/O – Lesen von Dateien, Schreiben von Ergebnissen – daher muss ein Multi-GPU-Setup mit schnellem Speicher (NVMe-SSDs) und ausreichend RAM kombiniert werden.
Wie viel schneller ist GPU vs. CPU bei OCR?
Bei einem Deep-Learning-basierten OCR-System wie EasyOCR oder PaddleOCR bringt GPU-Beschleunigung typischerweise eine 3- bis 7-fache Beschleunigung gegenüber reiner CPU-Verarbeitung, abhängig vom GPU-Modell und den Bildeigenschaften. Auf einer NVIDIA T4 (einer gängigen Cloud-GPU) läuft EasyOCR etwa 4× schneller als der CPU-Fallback. Auf Consumer-GPUs wie der RTX 3090 erreicht PaddleOCR über 190 Seiten pro Minute – eine 5- bis 7-fache Verbesserung gegenüber einer 4-Kern-CPU mit derselben Pipeline. Tesseract unterstützt keine GPU-Beschleunigung, daher wird die Geschwindigkeit allein von der CPU-Leistung bestimmt und ist nicht direkt vergleichbar.
Verringert eine Reduzierung der Bildgröße die OCR-Genauigkeit?
Eine Reduzierung der Bildgröße mindert die Genauigkeit nur, wenn die Mindestauflösung unterschritten wird, die die OCR-Engine zum Lesen kleiner Zeichen benötigt. Für die meisten gedruckten Dokumente sind 200 DPI für eine Zeichengenauigkeit von über 99 % ausreichend. Unter 150 DPI können feine Details verloren gehen: Fußnoten in 8-Punkt-Schrift, Dezimalpunkte und tiefgestellte Zeichen. Der sichere Ansatz ist, auf eine Zielauflösung von 200–300 DPI zu skalieren – das erhält die Lesbarkeit und eliminiert die 4–5 Megapixel redundanter Daten, die die Verarbeitung nur verlangsamen. Enthalten Ihre Dokumente sehr kleine Texte (z. B. juristisches Kleingedrucktes in 6–8 Punkt), sollten Sie 300 DPI als untere Grenze anpeilen.
Wann sollte ich aufhören zu optimieren und zu einem anderen Tool wechseln?
Wenn die Batch-Verarbeitungszeit von Pipeline-Overhead dominiert wird – Vorverarbeitung, Datei-I/O und Serialisierung – und nicht von der OCR-Engine selbst, haben Sie die praktische Grenze lokaler Optimierung erreicht. Anzeichen für einen nötigen Wechsel: Sie haben bereits GPU-Beschleunigung, Auflösungsnormalisierung und Parallelverarbeitung implementiert, aber ein Batch von 300 Seiten dauert immer noch über eine Stunde; oder Ihre Dokumente sind so vielfältig (Handyfotos, Scans, Screenshots, handschriftliche Anteile), dass die Vorverarbeitungsparameter pro Seite angepasst werden müssen. In diesen Fällen übertrifft ein cloudbasierter Extraktionsdienst, der über GPU-Worker parallelisiert und Dokumente semantisch liest – ohne anpassung pro Typ – eine lokal optimierte Pipeline sowohl in Geschwindigkeit als auch Genauigkeit.