🤖 machine learning

What changes after deployment? A survey on On-device Learning in TinyML

Diese Arbeit untersucht etwa 70 Arbeiten zu On-Device Learning (ODL) für TinyML, indem sie diese nach Regimen der Verteilungsänderung kategorisiert, um zu analysen, wie verschiedene Arten von Änderungen die anwendbaren Szenarien, Hardwareentscheidungen und Lösungsstrukturen beeinflussen, während sie gleichzeitig die anhaltende Lücke zwischen methodischen Benchmarks und dem realen Einsatz hervorhebt.

Ursprüngliche Autoren: Massimo Pavan, Luca Pezzarossa, Fabrizio Pittorino, Manuel Roveri, Xenofon Fafoutis

Veröffentlicht 2026-06-01

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Massimo Pavan, Luca Pezzarossa, Fabrizio Pittorino, Manuel Roveri, Xenofon Fafoutis

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben einen winzigen, superintelligenten Roboter-Assistenten, der in einem kleinen Gerät lebt, wie etwa einer Smartwatch oder einem Fabrik-Sensor. Dieser Roboter wurde in einer großen, schicken Schule (einem leistungsstarken Computer) trainiert, um Dinge zu erkennen – wie Ihre Stimme, ein bestimmtes Geräusch oder eine bestimmte Art von Bewegung. Sobald das Training abgeschlossen ist, wird der Roboter in sein neues Zuhause (das kleine Gerät) verschickt, um dort seinen Job zu erleden.

Das Problem: Der Schock im „neuen Viertel“
Das Paper argumentiert, dass es bei diesem Setup ein großes Problem gibt. Die Schule, in der der Roboter gelernt hat, war perfekt und sauber. Aber die reale Welt ist chaotisch. Sobald der Roboter anfangt zu arbeiten, verändert sich die Umgebung. Vielleicht wird der Hintergrundlärm lauter, Ihre Stimme klingt anders, wenn Sie müde sind, oder eine Maschine beginnt auf eine neue Weise zu vibrieren.

In den alten Tagen hätte der Roboter einfach genau das weitergemacht, was ihm beigebracht wurde, selbst wenn es falsch war. Das ist so, als würde ein Schüler, der den Lösungsschlüssel für einen Test auswendig gelernt hat, verwirrt sein, wenn der Lehrer eine etwas andere Frage stellt. Das Paper nennt dies eine „Verteilungsänderung“ (Distribution Change). Im Grunde sind die Daten, die der Roboter nach seinem Einsatz sieht, anders als die Daten, die er in der Schule gesehen hat.

Die Lösung: Der Roboter lernt während der Arbeit
Um dies zu beheben, haben die Autoren etwa 70 verschiedene Projekte untersucht, bei denen diese winzigen Roboter darauf trainiert werden, während sie arbeiten zu lernen. Dies wird „On-Device Learning“ genannt. Anstatt statisch zu sein, passt sich der Roboter in Echtzeit an seine neue Nachbarschaft an.

Das Paper weist jedoch darauf hin, dass nicht alle „neuen Viertel“ gleich sind. Die Autoren kategorisieren die Veränderungen in drei verschiedene Szenarien, wie drei verschiedene Arten von Umzugserfahrungen:

Der „Einmalige Umzug“ (Single-Change Regime):
Stellen Sie sich vor, Sie ziehen in ein neues Haus um, und die Möbel sind dort anders angeordnet, aber dann bleiben sie für immer so. Der Roboter muss dieses neue Layout nur einmal schnell lernen, und dann ist er fertig. Er muss nicht ewig weiterlernen.
- Beispiel: Einem Smart Speaker beibringen, Ihre spezifische Stimme oder ein neues Schlüsselwort, das Sie gerade gesagt haben, zu erkennen.
Der „Ständige Wetterumschwung“ (Concept Drift Regime):
Stellen Sie sich vor, Sie fahren ein Auto, bei dem sich die Straßenbedingungen alle paar Minuten ändern – Regen, dann Sonne, dann Nebel, dann Eis. Der Roboter muss seinen Fahrstil ständig anpassen, die alten Regeln vergessen (wie „schnell auf trockenen Straßen fahren“) und die neuen Regeln sofort lernen. Es ist ein niemals endender Zyklus der Anpassung.
- Beispiel: Ein Drucksensor in einer Fabrik, der aufgrund von Hitze oder Alterung langsam driftet und ständig neu kalibriert werden muss.
Die „Immer größer werdende Bibliothek“ (Continual Learning Regime):
Stellen Sie sich vor, Sie sind ein Bibliothekar, der jede Woche neue Bücher bekommt, aber Sie haben ein winziges Regal. Sie müssen etwas über die neuen Bücher lernen, ohne die alten Bücher, die Sie bereits kennen, wegzuwerfen. Wenn Sie die alten Bücher vergessen, um Platz für die neuen zu machen, nennt man das „katastrophales Vergessen“ (Catastrophic Forgetting). Der Roboter muss ständig neues Wissen hinzufügen, ohne das alte zu verlieren.
- Beispiel: Eine Gehirn-Computer-Schnittstelle, die im Laufe der Zeit neue Befehle eines Nutzers lernt, während sie die alten Befehle beibehält.

Der Realitätscheck der Hardware
Das Paper betrachtet auch die „Gehirne“ (Hardware), auf denen diese Roboter leben. Das sind keine leistungsstarken Laptops, sondern winzige Mikrochips mit sehr begrenztem Speicher und Akku.

Winzige Chips (Ultra-Constrained): Diese sind wie Taschenrechner. Sie können nur das Szenario des „Einmaligen Umzugs“ bewältigen. Sie sind zu schwach, um ständig weiterzulernen.
Standard-Chips (Standard MCUs): Diese sind wie Basis-Smartphones. Sie können alle drei Szenarien bewältigen, haben aber Schwierigkeiten mit der „Immer größer werdenden Bibliothek“, weil ihnen der Speicher ausgeht, wenn sie versuchen, alles zu behalten.
Super-Chips (PUL-Plattformen): Diese sind wie Mini-Supercomputer. Sie sind die einzigen, die stark genug sind, um das Szenario der „Immer größer werdenden Bibliothek“ effektiv zu bewältigen, aber sie sind teuer und schwer zu programmieren.

Die große Diskrepanz
Die Autoren fanden eine seltsame Lücke in der Forschungswelt:

Die „Laborwissenschaftler“ testen ihre Roboter meistens an perfekten, unordentlichen Bilddatensätzen (wie Fotos von Katzen und Hunden), die für echte winzige Geräte zu schwer sind. Sie konzentrieren sich darauf, den Lernalgorithmus im Vakuum perfekt zu machen.
Die „Praktiker der realen Welt“ arbeiten an tatsächlichen Problemen, wie der Reparatur von Sensoren oder der Erkennung von Gesten, verfügen aber oft nicht über standardisierte Tests, um ihre Arbeit zu vergleichen.

Aus diesem Grund bauen die „Laborwissenschaftler“ schicke Motoren, die nicht in die Autos der „Praktiker der realen Welt“ passen. Das Paper legt nahe, dass wir bessere Wege brauchen, um diese Roboter gemeinsam zu testen, indem wir das gesamte System (das Gehirn, den Speicher und die Lernmethode) betrachten, anstatt nur einen Teil davon.

Zusammenfassend
Dieses Paper ist eine Landkarte der aktuellen Landschaft der „lernenden Roboter“ auf winzigen Geräten. Es sagt uns, dass wir, um diese Roboter in der realen Welt nützlich zu machen, aufhören müssen, sie als statische Maschinen zu betrachten. Wir müssen sie so konzipieren, dass sie drei spezifische Arten von Veränderungen bewältigen können (einmalig, ständig oder wachsend), sie mit der richtigen Größe eines „Gehirns“ (Hardware) abgleichen und aufhören, sie isoliert zu testen. Wir müssen bessere Werkzeuge entwickeln, die es Ingenieuren ermöglichen, den gesamten Roboter auf einmal zu entwerfen, und nicht Stück für Stück.

Technisches Resümee: Was ändert sich nach der Bereitstellung? Eine Untersuchung über On-Device Learning in TinyML

1. Problemstellung

Maschinelle Lernmodelle, die auf Mikrocontroller-Klasse-Geräten (TinyML) bereitgestellt werden, stehen vor einer grundlegenden Herausforderung: der Veränderung der Verteilung nach der Bereitstellung (post-deployment distribution change). Modelle, die offline auf kuratierten Datensätzen trainiert wurden, zeigen oft eine unzureichende Leistung, wenn sie realen Bedingungen ausgesetzt sind, bei denen sich die Datenverteilungen nach der Bereitstellung verschieben. On-Device Learning (ODL) adressiert dies, indem es den Lernprozess direkt auf dem Gerät ausführt. Die bestehende Literatur lässt jedoch eine einheitliche Charakterisierung darüber vermissen, wie Verteilungsänderungen auftreten. Vorherige Umfragen haben nicht explizit zwischen verschiedenen Arten von Verteilungsänderungs-Regimen unterschieden, was zu einer Vermischung von Lösungen führt, die unter grundlegend verschiedenen Einschränkungen und Annahmen operieren. Darüber hinaus besteht eine anhaltende Lücke zwischen methodischen Benchmarks (oft bildzentriert) und realen Deployment-Szenarien (oft sensorgestützt), was den Transfer algorithmischer Fortschritte auf praktische Anwendungen behindert.

2. Methodik

Diese Arbeit präsentiert eine umfassende Untersuchung von etwa 70 ODL-Arbeiten im TinyML-Bereich. Die Untersuchung ist nach einem primären Ordnungsprinzip strukturiert: dem Regime der Verteilungsänderung. Die Autoren kategorisieren die Literatur in drei distinkte Regime basierend auf der Natur des datengenerierenden Prozesses ( $P$ ) nach dem Bereitstellungszeitpunkt $T$ :

Single-Change Regime: Die Verteilung verschiebt sich genau einmal bei der Bereitstellung ( $p_{T-1} \neq p_T$ ) und bleibt danach stabil. Die Herausforderung besteht in der schnellen, effizienten Anpassung an neue Bedingungen für die restliche Lebensdauer des Geräts.
Concept Drift Regime: Die Verteilung ändert sich mehrfach kontinuierlich und unvorhersehbar ( $p_{t-1} \neq p_t$ ). Der Fokus liegt darauf, sich schnell an neue Bedingungen anzupassen, während irrelevantes vergangenes Wissen verworfen oder abgewichtet wird.
Continual Learning Regime: Neue Konzepte werden im Zeitverlauf inkrementell eingeführt. Die Lösung muss neues Wissen akkumulieren, ohne zuvor gelerntes Wissen zu vergessen (Adressierung von katastrophalem Vergessen). Obwohl dies in Bezug auf die Verteilungsänderung formal ähnlich wie Concept Drift ist, unterscheiden sich die Annahmen bezüglich der Relevanz vergangenen Wissens und die Evaluationskriterien signifikant.

Für jedes Regime analysiert die Untersuchung die Literatur durch drei komplementäre Linsen:

Anwendungslinse (Application Lens): Die realen Kontexte und Aufgaben (z. B. Keyword Spotting, Sensorkalibrierung, Gehirn-Maschine-Schnittstellen).
Hardware-Linse (Hardware Lens): Die Zielgeräte, die von extrem eingeschränkten Prozessoren (z. B. Cortex-M0, ISPU) bis hin zu Standard-MCUs (Cortex-M4/M7) und parallelen Ultra-Low-Power (PULP)-Plattformen reichen.
Lösungslinse (Solution Lens): Die technische Zusammensetzung der ODL-Lösungen, zerlegt in vier Komponenten:
- $R(\cdot)$ : Dimensionalitätsreduktion (z. B. gefrorene CNNs, statistische Merkmalsextraktoren).
- $B$ : Datenmanagement (Buffering-Strategien, Admissions-/Trigger-Bedingungen).
- $f_t(\cdot)$ : Der ML-Algorithmus (z. B. DNNs, SVMs, KNN).
- $L$ : Der Lernmechanismus (z. B. Backpropagation, Forward-only Updates, Prototypengenerierung).

Die Untersuchung formalisiert zudem das ODL-Problem, definiert Beschränkungen für Speicher ( $M_D$ ), Taktfrequenz ( $F_D$ ), Leistung und Ausführungszeit ( $E$ ) und etabliert Evaluationsprotokolle spezifisch für jedes Regime (z. B. prequential Evaluation für Concept Drift, longitudinale Evaluation für Continual Learning).

3. Kernbeiträge

Regime-zentrierte Taxonomie: Dies ist die erste Untersuchung, die die gesamte ODL-Literatur um das Regime der Verteilungsänderung (Single-Change, Concept Drift, Continual Learning) organisiert. Sie argumentiert, dass Lösungen, die für ein Regime entwickelt wurden, aufgrund unterschiedlicher Annahmen über vergangenes Wissen und Anpassungsziele nicht direkt mit Lösungen eines anderen Regimes vergleichbar sind.
Umfassender Umfang: Die Untersuchung deckt ca. 70 Arbeiten ab, was vorangegangene Bemühungen (die ca. 10 Arbeiten untersuchten) signifikant erweitert und den substanziellen Forschungsstand nach 2023 erfasst.
Multi-Linsen-Analyse: Durch die gleichzeitige Analyse der Arbeiten durch die Anwendungs-, Hardware- und Lösungslinsen zeigt die Untersuchung querschnittliche Muster auf, wie etwa die Korrelation zwischen Hardware-Kapazität und Regime-Komplexität sowie die Diskrepanz zwischen methodenorientierter und anwendungsorientierter Forschung.
Identifikation struktureller Lücken: Das Paper identifiziert eine Diskrepanz zwischen methodischen Beiträgen (oft fokussiert auf Backpropagation-Optimierung auf Standard-Benchmarks) und anwendungsorientierten Arbeiten (die Priorität auf Label-Effizienz und reale Constraints setzen). Es hebt hervor, dass methodische Arbeiten selten die Knappheit an gelabelten Daten und die vollen Pipeline-Beschränkungen (Speicher, Latenz, Energie) gleichzeitig adressieren.

4. Zentrale Ergebnisse und Erkenntnisse

Anwendungsergebnisse

Fehlausrichtung der Aufgaben: Methodenorientierte Arbeiten verwenden überwiegend Bildklassifizierungs-Benchmarks (CIFAR, MNIST), die für reale TinyML-Szenarien oft zu rechenintensiv sind. Umgekehrt konzentrieren sich anwendungsorientierte Arbeiten auf Aufgaben wie Keyword Spotting (KWS), Human Activity Recognition (HAR) und Sensorkalibrierung, denen es an standardisierten Benchmarks mangelt.
Strategien zur Label-Akquisition: Erfolgreiche anwendungsorientierte Arbeiten behandeln die Label-Akquisition als primäre Designanforderung. Zu den Strategien gehören Few-Shot Learning, Self-Supervised Learning (unter Nutzung von Hilfssensoren), Unsupervised Learning (für Anomalieerkennung) und implizites Labeling via strukturierter Stimuli.
Regime-Verteilung: Anwendungsorientierte Arbeiten sind stark im Single-Change Regime konzentriert (z. B. KWS-Personalisierung, Sensorkalibrierung). Die Regime Concept Drift und Continual Learning werden von methodenorientierten Arbeiten dominiert, wobei nur sehr wenige reale Anwendungsszenarien berichtet werden.

Hardware-Ergebnisse

Hardware-Regime-Korrelation: Es besteht eine monotone Beziehung zwischen Hardware-Kapazität und Regime-Komplexität.
- Extrem eingeschränkte Prozessoren (Cortex-M0, ISPU) erscheinen fast ausschließlich im Single-Change Regime aufgrund strenger Speicher- und Rechenlimits.
- Standard-MCUs (Cortex-M4/M7) decken alle drei Regime ab, sind jedoch im Bereich Continual Learning aufgrund von Speicherbeschränkungen für Replay-Buffer unterrepräsentiert.
- PULP-Plattformen (Multi-Core, z. B. GAP9) dominieren das Continual Learning Regime, da sie die einzige Klasse sind, die derzeit in der Lage ist, die hohen Speicher- und Rechenanforderungen von Continual-Learning-Algorithmen zu unterstützen.
Berichtslücken: Die Berichterstattung zur Hardware ist inkonsistent. Metriken wie Peak-RAM und Energie werden oft pro Instanz, pro Batch oder pro Epoche ohne Standardisierung angegeben, was einen Vergleich zwischen den Arbeiten erschwert.

Lösungsergebnisse

Komponenten-Muster:
- Dimensionalitätsreduktion ( $R$ ): Gefrorene vortrainierte CNNs sind die dominante Wahl für Bild-/Audio-Inputs, während Identitätsfunktionen oder statistische Extraktoren für niedrigdimensionale Sensordaten verwendet werden.
- Datenmanagement ( $B$ ): Der voll-online Betrieb ( $|\Delta|=1$ ) dominiert die Single-Change und Concept Drift Regime. Explizites Buffering ist in der Struktur des Continual Learning notwendig, um katastrophales Vergessen zu verhindern.
- Lernmechanismus ( $L$ ): Volle Backpropagation ist der Standard für Continual Learning (unterstützt durch Replay-Buffer). In Single-Change und Concept Drift sind leichtere Alternativen (Forward-only Updates, prototypenbasierte Klassifikatoren, KNN) verbreitet.
Optimierungslücke: Methodische Arbeiten optimieren intensiv Backpropagation (Sparsifizierung, Quantisierung), doch diese Optimierungen werden in anwendungsorientierten Deployments selten übernommen. Dies deutet auf eine Diskrepanz hin, bei der algorithmische Verbesserungen nicht gegen die vollen Pipeline-Constraints (z. B. Labeling-Strategie, Kosten des Daten-Buffering) validiert werden.

5. Bedeutung und Behauptungen

Das Paper behauptet, dass das Regime der Verteilungsänderung der kritische, jedoch bisher übersehene Faktor ist, der die Machbarkeit und das Design von ODL-Lösungen bestimmt. Durch die explizite Unterscheidung zwischen Single-Change, Concept Drift und Continual Learning bietet die Untersuchung einen Rahmen für einen sinnvollen Vergleich, der in der bisherigen Literatur fehlte.

Die Autoren behaupten bescheiden, dass ihre Arbeit eine strukturelle Lücke im Feld aufzeigt: Algorithmischer Fortschritt und Anwendungsentwicklung bewegen sich parallel, jedoch mit geringer wechselseitiger Durchdringung. Sie argumentieren, dass das Feld Folgendes benötigt:

Standardisierte Evaluationsframeworks: Benchmarks, die Hardware-Budgets, Komponenten der Lösung und Deployment-Constraints (einschließlich Label-Knappheit) festlegen, um einen fairen Vergleich zu ermöglichen.
End-to-End Design-Tools: Software-Frameworks, die die gesamte ODL-Pipeline ( $R, B, f, L$ ) als gemeinsam optimierbare Objekte behandeln, anstatt Komponenten isoliert zu optimieren.
Hardware für ODL: Ein Wandel weg von der Anpassung von Cloud-Training-Architekturen hin zum Design von Hardware, die spezifisch auf ODL-Constraints ausgelegt ist (knappe Labels, kein On-Device-Validation, strikte Power-Budgets).

Die Untersuchung schließt mit dem Hinweis, dass ODL zwar den Umfang von TinyML-Anwendungen erweitert, die Verwirklichung dieser Vision jedoch die Adressierung der Fehlausrichtung zwischen methodischen Benchmarks und realen Deployment-Szenarien erfordert, insbesondere im Hinblick auf Label-Effizienz und die spezifischen Anforderungen nicht-stationärer Lernregime.