„Warum ist OCR so langsam?“
3 Hauptursachen für langsame Stapelverarbeitung – und wie Sie jede beheben

Ursache #1: Keine GPU-Beschleunigung bei rechenintensiven Pipelines

Symptom. Die CPU läuft während der Verarbeitung dauerhaft bei 100 % Auslastung, und jede Seite benötigt bei sauberen Dokumenten weit über eine Sekunde. Der Durchsatz steigt nicht, wenn Sie mehr Dateien zu einem Batch hinzufügen – die Pipeline ist ausgelastet.

Ursache. Nicht alle OCR-Engines sind unter der Haube gleich. Tesseract, der von Google gepflegte Open-Source-Benchmark, ist eine rein CPU-basierte Engine. Sie verwendet traditionelle Computer-Vision-Pipelines – Connected-Component-Analyse, Seitenlayout-Analyse und LSTM-basierte Zeichenerkennung –, die alle keine GPU-Parallelität nutzen. Ein Forscher-Benchmark maß Tesseract 5 mit etwa 0,8 Sekunden pro Seite auf einer modernen CPU bei sauberem gedrucktem Text. Akzeptabel für ein paar Seiten. Schmerzhaft bei 500.

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 ist dieselbe Deep-Learning-Pipeline, die EasyOCR genau macht, auch drei- bis viermal langsamer als im GPU-Modus. Benchmarks auf einer NVIDIA T4 zeigen EasyOCR GPU mit etwa ~0,6 Sekunden pro Seite – vergleichbar mit Tesseract – während EasyOCR CPU auf ~2,5 Sekunden pro Seite ansteigt.

Die Lösung. Prüfen Sie, ob Ihre OCR-Pipeline tatsächlich eine GPU verwendet:

• Stellen Sie bei EasyOCR sicher, dass reader = easyocr.Reader(['en'], gpu=True) tatsächlich CUDA erkennt. Wenn die Bibliothek stillschweigend zurückfällt, verdoppelt sich Ihre Zeit pro Seite. Führen Sie während der Verarbeitung nvidia-smi aus – zeigt die GPU-Auslastung 0 %, läuft Ihre Pipeline auf der CPU.
• Bei 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 die GPU ausgelegt. 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 dedizierte 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 unseren Überblick über die besten Open-Source-OCR-Tools.

Ursache #2: Bilder sind viel größer als die OCR eigentlich braucht

Symptom. Die Verarbeitung kommt auf Seiten zum Erliegen, die für Sie perfekt lesbar aussehen. Ein 12-Megapixel-Handyfoto eines Belegs braucht 5–8 Sekunden, während ein gescannter PDF desselben Dokuments unter 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 Breite mal 2x Höhe. Die vierfache Eingabemenge bedeutet etwa die 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 (ca. 2550×3300 für Letter-Format), enthält 8,4 Millionen. Ein mit 200 DPI gescanntes Dokument – 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 leidet die Zeichenerkennung. Über 400 DPI bezahlen Sie mit Rechenzeit für keinen messbaren Genauigkeitsgewinn. Dasselbe 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. Ziel sind 150–300 DPI im 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 img

Dieser einzelne Schritt kann die Verarbeitungszeit pro Seite um 40–70 % senken, je nach Ausgangsbildern, ohne Auswirkung auf die Extraktionsgenauigkeit. Eine vollständige Anleitung zur Bildvorbereitung – einschließlich Binarisierung, Entzerrung und Kontrastnormalisierung – finden Sie in unserem Leitfaden zur OCR-Bildvorverarbeitung.

Ursache #3: Sequenzielle Verarbeitung, obwohl Parallelisierung möglich wäre

Symptom. Die CPU-Auslastung liegt während eines Batch-Durchlaufs bei etwa 30–40 %. Die Pipeline verarbeitet Dateien nacheinander – Sie beobachten, wie der Fortschrittsbalken Datei für Datei vorrückt, ohne dass es schneller wird.

Ursache. Die meisten OCR-Pipelines sind als einfache Schleifen geschrieben: for datei in dateien: ocr(datei). Das 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 Behebung ist trivial parallelisierbar – 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, Sie können auf einem N-Kern-Rechner N Seiten gleichzeitig verarbeiten und theoretisch den N-fachen Durchsatz erzielen. In der Praxis ist die Skalierung bis zu 4–8 Kernen nahezu linear, darüber hinaus sinkt der Nutzen aufgrund von Speicherbandbreite und E/A-Konflikten.

Die Lösung. Wickeln Sie Ihren OCR-Aufruf in ein paralleles Ausführungs-Framework ein:

• GNU Parallel (Linux/macOS): Der einfachste Ansatz für skriptbasierte Pipelines. parallel -j 4 ocrmypdf {} ausgabe/{} ::: *.pdf führt vier OCR-Prozesse gleichzeitig aus.
• Python multiprocessing: Verwenden Sie multiprocessing.Pool, um Dateien auf Worker-Prozesse zu verteilen. Jeder Worker erhält eine eigene OCR-Engine-Instanz, und die Ergebnisse werden nach Abschluss eingesammelt.
• Batch-Verarbeitungstools: Spezielle Batch-OCR-Tools wie OCRmyPDF unterstützen integrierte Parallelverarbeitung. Der Parameter --jobs steuert die Gleichzeitigkeit. Die Kombination mit GNU Parallel (Begrenzung auf 2 parallele Jobs, um E/A-Sättigung zu vermeiden) ist ein dokumentiertes Produktionsmuster.

Die wichtigste praktische Überlegung: Jeder parallele Worker benötigt genügend Arbeitsspeicher, um das Seitenbild und die Zwischenpuffer zu halten. Der Betrieb von 8 Workern auf einem Rechner mit 8 GB RAM führt zu Swapping. Ein sicherer Ausgangspunkt sind 2 GB RAM pro parallelem Worker für Standard-Dokumentbilder. Skalieren Sie die Parallelität entsprechend Ihres Speicherbudgets, bevor Sie die CPU-Kernanzahl erreichen.

Eine vollständige Anleitung zum Einrichten paralleler Batch-Pipelines finden Sie in unserem Leitfaden zur Batch-Verarbeitung mehrerer Dateien.

Wann Sie eskalieren sollten — Werkzeugwechsel statt Feintuning

Wenn Sie alle drei Ursachen geprüft haben — Ihre GPU ist aktiv, Ihre Bilder sind richtig skaliert und Ihre Pipeline läuft parallel —, die Verarbeitung aber dennoch zu langsam für Ihre Arbeitslast ist, liegt der Engpass möglicherweise in der Architektur und nicht in der Konfiguration.

Drei Signale deuten darauf hin, dass ein grundlegend anderer Ansatz sinnvoll ist:

1. Ihr Volumen ist konstant hoch. Wenn Sie täglich 500+ Seiten verarbeiten und die Batch-Laufzeit ein wiederkehrendes Problem ist, wird das Tuning einer lokalen OCR-Pipeline immer hinter dem zurückbleiben, was ein speziell entwickelter Cloud-Dienst leisten kann. Cloud-Extraktionsdienste laufen auf serverbasierten GPU-Clustern mit automatischem Lastausgleich — ein einzelner Batch kann auf Dutzende parallele Worker verteilt werden, ohne dass Sie Hardware bereitstellen müssen.

2. Ihre Dokumente sind vielfältig und unverarbeitet. Eine Pipeline, die für saubere gescannte PDFs optimiert ist, hat Schwierigkeiten mit Handyfotos, zerknitterten Quittungen oder Dokumenten mit Handschrift. Jeder neue Eingabetyp erfordert andere Vorverarbeitungsparameter. ImageToTable.ai verwendet visuelle Sprachmodelle, die Dokumente semantisch lesen — das Seitenlayout so interpretieren, wie es ein Mensch tun würde, ohne anpassung pro Dokumenttyp. Es benötigt keinen separaten Vorverarbeitungsschritt zur Auflösungsnormalisierung, da die Cloud-Pipeline die Skalierung vor der Inferenz automatisch übernimmt.

3. Sie brauchen 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 auf Geschwindigkeit getunte — nicht liefern. Die Cloud-Batchverarbeitung parallelisiert über das gesamte Dokumentenvolumen. Ein 300-Seiten-Batch, der auf einem einzelnen Rechner mit CPU 3–4 Stunden dauert, kann in 5–10 Minuten auf einer Cloud-Infrastruktur abgeschlossen werden, die dieselbe Arbeit auf 20–40 parallele GPU-Worker verteilt.

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.