‍Wie wir ausgeklügelte KI-Modelle von Cloud-Servern auf mobile Geräte verlagert haben.

Jeder unbemerkte Kratzer, jede Delle oder jeder Riss ist nicht nur kosmetischer Natur; er bedeutet potenzielle Tausende von Reparaturkosten, Haftungsrisiken und lähmenden, unerwarteten Fahrzeugausfällen, die die Zeitpläne ins Chaos stürzen. An den hauchdünnen Rändern der Straßenlogistik kann das Ignorieren von Details kostspielig sein. Basierend auf Kundenfeedback variieren die Reparaturkosten für einen Anhänger zwischen 1.600€ und 4.500 Euro pro Jahr.

In den letzten zwei Jahren nutzte Checkturio maschinelles Lernen und KI, um Prozesse rund um das Lkw-Management zu automatisieren. Wir verwenden zwar mehrere ML-Modelle zur Unterstützung von Flottenmanagern und Fahrern, aber unser komplexestes ist das visuelle Schadenerkennungsmodell, das in der Cloud auf leistungsstarken GPUs läuft. Die Fahrer machen Fotos, die App lädt sie hoch und unsere Modelle analysieren die Bilder auf Probleme. Wir waren zwar mit der Leistung der Modelle zufrieden, aber dieser Cloud-orientierte Ansatz war in der realen Umgebung nicht ohne Probleme.

Die Einschränkungen eines entfernten Gehirns

Die Einschränkungen wurden immer offensichtlicher. Die Fahrer sahen sich mit frustrierenden Latenzverzögerungen konfrontiert, da die Hin- und Rückfahrt — das Hochladen eines Fotos, das Warten auf die Cloud-Verarbeitung, das Herunterladen des Ergebnisses — oft über unsere Ziele für die Reaktionsfähigkeit hinausging und sich auf das Benutzererlebnis auswirkte. Latenz war auch ein besonderes Problem in abgelegenen Depots oder Parkplätzen mit schlechter Netzabdeckung — genau dort, wo viele Aktivitäten stattfinden.

Darüber hinaus verbrauchen selbst komprimierte Bilder mobile Daten — insbesondere dann, wenn Fahrer ihre eigenen Telefone verwenden müssen, um Berichte zu erstellen.

Die vielleicht größte Hürde war das Offline-Hindernis. Inspektionen sind nicht verhandelbar; sie müssen unabhängig von der Konnektivität stattfinden. Unsere App verfügte zwar über einen Offline-Fallback, aber wir mussten die UX für beide Szenarien optimieren, und trotz unserer Bemühungen war das Offline-Erlebnis im Vergleich zum KI-gestützten Erlebnis unterdurchschnittlich.

Schließlich summierten sich mit unserem Wachstum die Kosten für die Verarbeitung von Hunderttausenden von Bildern — Berechnung, Datenübertragung —. Diese kombinierten Einschränkungen machten es deutlich: Für eine wirklich zuverlässige, effiziente und kostengünstige Schadensmeldung in Echtzeit mussten wir die Informationen näher an den Benutzer übertragen, auf das Mobilgerät selbst.

Der Trend zu On-Device-Intelligence

Die direkte Übertragung des Schadenserkennungsmodells auf das Mobilgerät des Fahrers bot mehrere Vorteile. Der unmittelbarste Vorteil war die sofortige Befriedigung: Die Inferenz erfolgt lokal und liefert nahezu in Echtzeit Feedback direkt in der App-Oberfläche, wodurch unsere Ziele für die Nutzerfreundlichkeit erreicht wurden. Dadurch werden auch echte Offline-Funktionen freigeschaltet, sodass die KI-Unterstützung überall und jederzeit zuverlässig funktioniert, völlig unabhängig von der Netzwerkkonnektivität.

‍

Abgesehen von der Benutzerfreundlichkeit führt die Ausführung von KI am Edge zu reduzierten Cloud-Kosten, da die Datenübertragung und die Fernberechnung minimiert werden. Entscheidend ist, dass die KI auf dem Gerät die Tür zu völlig neuen Workflow-Möglichkeiten öffnet und interaktivere und optimiertere Funktionen innerhalb der mobilen App ermöglicht — wie beispielsweise die Anleitung des Benutzers, Daten besser zu erfassen —, die bei cloudbasierter Latenz einfach nicht praktikabel waren.

Herausforderungen auf dem Weg zu Edge

Das Potenzial war zwar klar, aber der Weg zum Edge war nicht einfach. Wir standen vor einigen technischen Herausforderungen. YOLOv8 bietet zwar leichte „Nano“ - und „Small“ -Varianten, die sich theoretisch für Mobilgeräte eignen, aber das zuverlässige Erkennen der oft subtilen visuellen Hinweise, die für die Schadensbeurteilung entscheidend sind — schwache Kratzer, beginnende Korrosion, geringfügige strukturelle Veränderungen — profitiert häufig von den umfassenderen Funktionen zur Merkmalsextraktion, die in den größeren, rechenintensiveren Versionen des Modells zu finden sind. Daher bestand unsere zentrale Herausforderung darin, das Modell für diese nuancierten Erkennungen zu einem Paket zusammenzufassen, das innerhalb der Einschränkungen mobiler Geräte laufen konnte.

Ein weiteres Problem war die vielfältige Hardwarelandschaft der Mobilgeräte. Unsere Lösung musste auf einem breiten Spektrum von Geräten, die jeweils über unterschiedliche Prozessoren, Speicherkapazitäten und spezielle Chips verfügten, zuverlässig funktionieren. Wir mussten uns auch der Bedenken hinsichtlich des Batterieverbrauchs bewusst sein.

Unweigerlich stießen wir auf den klassischen Kompromiss zwischen Genauigkeit und Leistung. Um Modelle kleiner und schneller zu machen, müssen oft einige Genauigkeitseinbußen hingenommen werden. Die Suche nach dem optimalen Punkt, an dem das Modell zuverlässig genau blieb (wir haben Metriken wie Map50-95 genau beobachtet) und gleichzeitig leistungsstark genug für den Rand war, war ein entscheidender Kompromiss. Schließlich fügte React Native eine weitere Ebene der Komplexität hinzu. Unsere Checkturio-App verwendet dieses plattformübergreifende Framework, was bedeutet, dass wir die Ausführung nativer KI-Codes effizient in ihre Architektur integrieren und verwalten mussten. Dabei war uns bewusst, dass die Verarbeitung komplexer Modellausgaben direkt in JavaScript zu Leistungsengpässen führen kann.

Unsere Optimierungs- und Integrationsstrategie

Um diese Hürden zu überwinden, war ein systematischer, mehrstufiger Ansatz erforderlich. Unser erster Schritt bestand darin, das Modell durch Quantisierung auf eine Diät umzustellen. Insbesondere verwendeten wir die Quantisierung nach dem Training, um die numerische Präzision der Modellparameter von 32-Bit-Gleitkommazahlen (FP32) auf 8-Bit-Ganzzahlen (INT8) zu reduzieren. Dadurch wurde der Platzbedarf des Modells erheblich verkleinert und es konnte die schnelleren, energieeffizienteren Funktionen der mobilen Chips für die Berechnung von Ganzzahlen nutzen. Dies erforderte zwar eine geringfügige, akzeptable Anpassung der Präzision, die Leistungssteigerungen waren jedoch erheblich.

Als Nächstes benötigten wir das richtige Toolkit für den mobilen Einsatz. Wir haben das quantisierte Modell umgewandelt in TensorFlow Lite (TFLite) format, Googles spezialisiertes Framework, das auf Effizienz auf mobilen und eingebetteten Geräten ausgelegt ist. TFLite wendet bei dieser Konvertierung automatisch mehrere wichtige Optimierungen an, z. B. die Verschmelzung mehrerer mathematischer Operationen zu einzelnen Schritten (Operator Fusion), die Vereinfachung des Berechnungsdiagramms des Modells und das Zusammenfalten der Normalisierungsebenen in benachbarte, was alles zu einem schlankeren, schnelleren Modell beiträgt. Wir haben Tools wie LiterT verwendet, um die Leistungsvorteile von TFLite schon früh zu validieren.

Die Integration dieses TFLite-Modells in unsere React Native-Anwendung erforderte eine sorgfältige Überlegung. Wir haben uns für die React-Native-Fast-Tflite-Bibliothek entschieden, da sie einen direkten Low-Level-Zugriff auf die TFLite-C++-API bietet und Hardwarebeschleunigung unterstützt. Die Implementierung umfasste den Aufbau einer Pipeline innerhalb von React Native: die Bearbeitung der Bildvorverarbeitung, um die Eingabe für das Modell korrekt zu formatieren, die Ausführung der Inferenz mithilfe der TFLite-Laufzeit über den Wrapper und die Verwaltung des Nachbearbeitungsschritts, der die Dekodierung des komplexen Ausgangstensors des Modells und die Anwendung von Algorithmen wie Non-Maximum Suppression (NMS) zur Verfeinerung der erkannten Schadensbereiche beinhaltete.

Um die Geschwindigkeit wirklich zu erhöhen, haben wir die TFLite-Delegierten genutzt, um die Berechnung an spezielle Hardwarebeschleuniger auf den Telefonen auszulagern. Wir haben uns in erster Linie auf den CPU-Delegierten konzentriert (XN-PACK), das eine hochoptimierte Multithread-Ausführung auf dem Hauptprozessor und den GPU-Delegierten ermöglicht (OpenGL für Android, Metal für iOS), die den Grafikprozessor für umfangreiche parallele Berechnungen nutzen, ideal für bildbasierte Aufgaben. Während wir uns mit NNAPI von Android und CoreML von iOS befasst haben, haben wir sie letztendlich von unserer plattformübergreifenden Kernstrategie ausgeschlossen, da NNAPI Probleme mit der Gerätekompatibilität hat und CoreML dazu neigt, plattformspezifische Workflows unserem universellen TFLite-Ansatz vorzuziehen.

Erfolgsmessung im mobilen Labyrinth

Strenges Benchmarking war unerlässlich, um unseren Ansatz zu validieren. Mithilfe von AWS Device Farm und automatisierten Appium-Tests haben wir die INT8- und FP32-Modelle für unsere Zielpalette der besten Android- und iOS-Geräte evaluiert.

Die Quantisierung hat sich bewährt, wobei das INT8-Modell sein FP32-Gegenstück auf der CPU durchweg übertraf, manchmal sogar um fast das Doppelte. Der GPU-Delegierte war unbestreitbar an der Spitze der Geschwindigkeit und beschleunigte die Inferenz im Vergleich zur CPU — oft erzielte er Beschleunigungen um das 1,5-Fache bis über das Dreifache. Interessanterweise schrumpfte auf der GPU selbst der Leistungsunterschied zwischen INT8 und FP32 oft, da moderne GPUs beide Datentypen effizient verarbeiten.

Wir haben beobachtet, dass Multithreading auf der CPU Vorteile bietet, aber diese Gewinne stagnierten in der Regel, sobald die Anzahl der Threads die verfügbaren Hochleistungskerne überstieg. Entscheidend war, dass wir auch die „React Native Tax“ gemessen haben — den inhärenten Aufwand, der mit der Ausführung von nativem Code innerhalb des plattformübergreifenden Frameworks einhergeht. Im Vergleich zu rein nativen Benchmarks wies unsere React Native-Implementierung Verlangsamungsfaktoren auf, die ungefähr zwischen 1,3x und über 4x lagen, was hauptsächlich durch die Verarbeitung der Modellausgaben innerhalb der JavaScript-Ebene beeinflusst wurde.

‍

Den Rollout steuern: Ein strategischer und hybrider Ansatz

Der Einsatz von Edge-KI erfordert eine sorgfältige Strategie. Unser schrittweiser Rollout priorisiert Benutzer mit Geräten, die in unseren Tests nachgewiesene Stabilitäts- und Leistungssteigerungen nachgewiesen haben. Um die Zuverlässigkeit zu gewährleisten, fungiert unsere cloudbasierte Inferenz als Backup und übernimmt nahtlos die Arbeit, wenn bei der Edge-Verarbeitung unter bestimmten Bedingungen Probleme auftreten.

Wir überwachen kontinuierlich die reale Leistung und vergleichen die Effizienz und Genauigkeit von Edge-Modellen genau mit denen von Cloud-Modellen, um Optimierungen zu validieren. Dieser iterative Prozess wird durch unsere Fähigkeit beschleunigt, Edge-Modelle unabhängig von den Versionen im App Store zu aktualisieren. Diese Entkopplung ermöglicht schnellere Modellverbesserungen, gezielte Bereitstellungen und sorgt dafür, dass die Kernanwendung schlank bleibt.

Was kommt als Nächstes?

Ein wichtiger Bereich für die weitere Optimierung innerhalb von React Native ist die Behebung der Engpässe, die derzeit bei der Vor- und Nachbearbeitung auftreten. Unser Plan ist es, diese rechenintensiven Aufgaben, insbesondere die Verarbeitung der Ausgabedaten des Modells, mithilfe dedizierter nativer Plugins zu implementieren.

Edge AI: Bereit für die Primetime

Unser Weg, KI zur Schadenserkennung auf den neuesten Stand zu bringen, lieferte wertvolle Erkenntnisse. Wir konnten bestätigen, dass selbst Mobilgeräte, die mehrere Jahre alt sind, optimierte Modelle effektiv ausführen können, was die ursprünglichen Hardware-Erwartungen übertrifft. Durch die Quantisierung wurde die erforderliche Leistungssteigerung erzielt, ohne dass die Qualität der Schadenserkennung wesentlich beeinträchtigt wurde.

Obwohl wir immer noch schnell innovieren und Modelle häufig aktualisieren und ein Cloud-lastiger Ansatz vorerst unsere Hauptstrategie bleibt, werden wir schrittweise mehr Benutzer auf Anwendungsvarianten umstellen, bei denen KI-Inferenz lokal ausgeführt wird.

‍