Deep Networks auf mobilen Geräten

Kleine CNNs und Edge AI

Ein Skizzen-CNN ist der Idealfall für On-Device-Inferenz: winzig, mit fester Eingabe, und die Daten entstehen ohnehin auf dem Gerät. DrawLa rechnet trotzdem auf dem Server. Dieser Artikel erklärt beides — warum die Technik dafür spricht und warum die Anwendung dagegen.

Was „klein" konkret heißt

Das Modell hinter DrawLa hat 2 004 345 Parameter und belegt in fp32 genau 8,0 Megabyte. Nach einer Quantisierung auf 8-Bit-Integer blieben rund zwei Megabyte übrig — weniger als ein einzelnes Foto aus der Kamera desselben Telefons.

Diese Größenordnung ändert die Diskussion grundlegend. Bei einem Sprachmodell ist die Frage, ob es überhaupt auf ein Gerät passt. Bei zwei Megabyte stellt sie sich nicht mehr; es geht nur noch darum, ob man es dort haben will.

Warum CNNs auf mobiler Hardware gut planbar sind

Der entscheidende Vorteil ist die feste Eingabegröße. Ein Tensor der Form 1 × 96 × 96 bedeutet: Jede Vorhersage belegt gleich viel Speicher, dauert gleich lang und erzeugt dieselben Zwischenergebnisse. Ein mobiler Compiler kann den gesamten Speicherplan vorab festlegen, statt zur Laufzeit nachzuallozieren.

Bei variabel langen Sequenzen ist das grundlegend anders: Dort wächst der Bedarf mit der Eingabe, und der ungünstigste Fall muss immer eingeplant werden. Für ein Zeichenspiel hieße das, ausgerechnet bei ausführlichen Zeichnungen langsamer zu werden.

Hinzu kommt, dass Faltungen, Batch Normalization und einfache Aktivierungen genau die Operationen sind, für die mobile Beschleuniger gebaut wurden. Bei Batch-Größe 1 — dem Normalfall in einer interaktiven App — zählen kurze Latenz und geringe Wärmeentwicklung mehr als Durchsatz.

Quantisierung

Klein wird ein Modell nicht nur durch wenige Parameter, sondern auch dadurch, wie genau die Zahlen gespeichert werden. Quantisierung senkt Gewichte und Aktivierungen von 32-Bit-Gleitkomma auf 8-Bit-Ganzzahlen: ein Viertel des Speichers, ein Viertel der Speicherbandbreite und deutlich weniger Energie pro Vorhersage.

Skizzenerkennung ist dafür ein dankbarer Fall. Die Eingabe ist ein Graustufenbild mit Werten zwischen 0 und 1, die Struktur ist regelmäßig, die Klassenzahl fest. Der Genauigkeitsverlust bleibt bei solchen Modellen typischerweise im Bereich weniger Zehntelprozentpunkte — bei einer Aufgabe, deren Top-1-Genauigkeit ohnehin von der Mehrdeutigkeit der Vorlagen begrenzt wird, fällt das nicht ins Gewicht.

Wie eine mobile Pipeline aussähe

Touch-Striche sammeln
  → zentrieren, skalieren, rastern
  → Tensor 1 × 96 × 96
  → quantisiertes CNN auf NPU/GPU/CPU
  → Top-5-Wahrscheinlichkeiten

Bemerkenswert daran: Die Rasterung ist der einzige Teil, der neu geschrieben werden müsste — heute läuft sie in Python auf dem Server. Und sie muss pixelgenau dasselbe tun, sonst sieht das Modell Eingaben, wie es sie im Training nie gesehen hat. Diese Portierung ist die eigentliche Arbeit, nicht das Modell selbst.

Die Hardwareseite ist inzwischen breit ausgebaut. Qualcomm etwa beschreibt mit GenieX eine On-Device-Runtime, die Modelle je nach Eignung auf NPU, GPU oder CPU verteilt. Das zielt auf große Sprach- und Bildmodelle, zeigt aber den Trend, von dem kleine Netze automatisch mitprofitieren.

Warum DrawLa es trotzdem nicht tut

Alles bisher Gesagte spricht für den Weg aufs Gerät. Drei Gründe sprechen in einem Wettbewerbsspiel dagegen — und sie wiegen schwerer.

Fairness. Die Erkennung vergibt Punkte. Läuft sie auf dem Gerät, entscheidet mit, wie schnell dieses Gerät ist und welche Quantisierung dort zum Einsatz kam. Zwei Spieler mit identischer Zeichnung bekämen unterschiedliche Ergebnisse — inakzeptabel, sobald es um eine Rangliste geht.

Manipulierbarkeit. Was auf dem Gerät läuft, lässt sich verändern. Ein lokaler Klassifikator, der Punkte vergibt, ist eine Einladung: Man müsste nicht einmal das Modell anfassen, sondern nur die gemeldete Antwort. Serverseitige Bewertung macht diese ganze Angriffsart gegenstandslos.

Aktualisierbarkeit. Ein besseres Modell ist auf dem Server in Minuten ausgerollt und wirkt sofort für alle. Auf dem Gerät hinge es an einem App-Update, an den Store-Prüfungen und daran, ob Spieler es überhaupt installieren. Über Wochen liefen dann mehrere Modellstände nebeneinander — in derselben Partie.

Die Faustregel: Rechnet das Modell nur für den Nutzer, gehört es aufs Gerät. Bewertet es ihn im Vergleich zu anderen, gehört es auf den Server.

Wo On-Device klar gewinnt

Für andere Anwendungsformen kehrt sich die Abwägung um. Ein reiner Übungsmodus ohne Wettbewerb hat keine Fairnessfrage — dort wäre lokale Erkennung schlicht besser: sofort, offline, ohne dass eine Zeichnung das Gerät verlässt.

Ebenso bei allem, was Skizzen als Eingabewerkzeug nutzt: Notiz-Apps, Formularerkennung, Zeichenwerkzeuge. Dort gibt es keinen Gegner, keine Punkte und damit keinen Grund für einen Netzwerkweg.

Denkbar wäre auch ein hybrider Betrieb: lokal für Solo und für die Vorschau während des Zeichnens, serverseitig für alles, was gewertet wird. Der Preis dafür sind zwei Erkennungspfade, die dauerhaft übereinstimmen müssen — Aufwand, der sich nur lohnt, wenn Offline-Betrieb ein echtes Ziel ist.

Welche Exportwege es für iOS und Android gibt, beschreibt iPhone & Android. Wie das Modell entstanden ist, steht unter QuickDraw mit PyTorch, und die Modellfamilien vergleicht RNN gegen CNN.