Lokale OCR auf Apple-Geräten: dots.ocr trifft Core ML
💡 Quellen-Hinweis: Dieser Beitrag ist eine redaktionelle Zusammenfassung basierend auf einem Originalbericht von Hugging Face Blog.
Leistungsfähige Texterkennung muss nicht zwingend in der Cloud laufen. Der Hugging-Face-Beitrag zeigt am Beispiel von dots.ocr, wie ein modernes OCR-Modell auf Apple-Hardware gebracht werden kann. Das rund drei Milliarden Parameter große System kombiniert einen selbst trainierten Vision-Encoder mit 1,2 Milliarden Parametern und ein Qwen2.5-Sprachmodell mit 1,5 Milliarden Parametern. Für die lokale Ausführung wird der Bildteil mit Core ML umgesetzt, während das Sprachmodell über MLX läuft.
Vom PyTorch-Modell zum Core-ML-Paket
Die Konvertierung erfolgt in zwei Schritten: Zunächst wird der PyTorch-Ausführungsgraph per torch.jit.trace erfasst, danach übersetzt coremltools diesen in ein ML-Package. Das Team beginnt bewusst mit statischen Eingabeformen, FLOAT32 und GPU-Ausführung. Erst wenn das Modell korrekt läuft, sollen geringere Präzision, dynamische Formen und Apples Neural Engine folgen. Dieses schrittweise Vorgehen erleichtert es, Abweichungen zwischen Original und konvertierter Variante einzugrenzen.
Mehrere Hürden zeigen, warum Modellkonvertierung selten auf Anhieb gelingt. Core ML behandelt etwa torch.arange anders als erwartet, wodurch Datentypen bei einer Matrixoperation nicht zusammenpassen. Weitere Probleme entstehen durch Logik für Videos, Bildstapel und Sequenzmasken. Da die Zielanwendung jeweils nur ein einzelnes Bild verarbeitet, entfernen die Entwickler unnötige Pfade, ersetzen dynamische Schleifen und vereinfachen die Attention-Maskierung. Nach diesen Anpassungen stimmt das Ergebnis eng mit PyTorch überein: Die mittlere Differenz wird mit rund 0,000011 angegeben.
Funktioniert, ist aber noch nicht effizient
Der erste Erfolg ist vor allem ein Machbarkeitsnachweis. Das unoptimierte FLOAT32-Paket ist größer als fünf Gigabyte, und bereits ein Durchlauf des Vision-Encoders benötigt mehr als eine Sekunde. Für mobile Apps ist das noch zu schwerfällig. Weitere Teile der Serie sollen deshalb die Verbindung von Core ML und MLX sowie Quantisierung, dynamische Eingaben und die Verlagerung auf die Neural Engine behandeln.
Warum der Ansatz relevant ist
Lokale OCR bietet Datenschutz, Offline-Verfügbarkeit und planbare Kosten. Gleichzeitig macht der Bericht deutlich, dass On-Device-KI mehr verlangt als einen Exportbefehl: Modelle müssen auf ihren tatsächlichen Einsatzzweck reduziert und Compilergrenzen verstanden werden. Für Entwickler ist das praktische Muster übertragbar: zuerst einen minimalen Pfad korrekt konvertieren, Ergebnisse gegen das Ausgangsmodell prüfen und erst danach auf Speicherbedarf, Energieverbrauch und Geschwindigkeit optimieren.
Originalquelle: Hugging Face Blog – SOTA OCR with Core ML and dots.ocr
