Ein Sensor misst eine Vibration, ein Mikrocontroller erkennt darin ein ungewöhnliches Muster und eine Maschine meldet eine mögliche Störung – ohne Video- oder Audiodaten in eine Cloud zu senden. Ein kleines Gerät hört auf ein Aktivierungswort, überwacht die Luftqualität oder unterscheidet Bewegungsabläufe, obwohl es nur wenige Milliwatt verbraucht. Genau hier beginnt TinyML.
Der Begriff steht für maschinelles Lernen auf besonders kleinen, sparsamen Computersystemen. Gemeint sind nicht Smartphones oder leistungsfähige Edge-Server, sondern häufig Mikrocontroller mit sehr begrenztem Arbeits- und Programmspeicher. Solche Bausteine stecken seit Jahrzehnten in Haushaltsgeräten, Maschinen, Fahrzeugen, Messsystemen und Spielzeug. Neu ist, dass sie nicht mehr nur fest programmierte Regeln abarbeiten müssen. Mit sorgfältig verkleinerten Modellen können sie Muster in Messdaten erkennen und direkt vor Ort Entscheidungen vorbereiten.
TinyML ist deshalb weniger eine Miniaturausgabe großer generativer KI als eine eigene technische Disziplin. Ihr Ziel lautet nicht: möglichst viele Fähigkeiten in ein Modell packen. Es lautet: eine klar definierte Aufgabe unter harten Grenzen zuverlässig, schnell und energieeffizient lösen.
Was ist TinyML?
TinyML – kurz für Tiny Machine Learning – bezeichnet Verfahren, mit denen Modelle des maschinellen Lernens auf extrem ressourcenbeschränkter Hardware ausgeführt werden. Typische Zielplattformen sind Mikrocontroller, digitale Signalprozessoren und kleine System-on-Chips, die eng mit Sensoren verbunden sind. Viele dieser Systeme arbeiten mit wenigen hundert Kilobyte bis einigen Megabyte Speicher, niedrigen Taktfrequenzen und einem Energiebedarf, der einen Betrieb über Monate oder Jahre mit einer Batterie ermöglichen soll.
Der Schwerpunkt liegt meist auf der Inferenz. Das bedeutet: Das Modell wurde zuvor auf leistungsfähigeren Rechnern trainiert und wird anschließend auf das kleine Gerät übertragen. Dort verarbeitet es neue Messwerte und liefert beispielsweise eine Klasse, eine Wahrscheinlichkeit, einen Schätzwert oder ein Anomaliesignal. Das eigentliche Training bleibt in vielen Anwendungen außerhalb des Mikrocontrollers, weil es erheblich mehr Speicher, Rechenleistung und Datenzugriffe verlangt.
TinyML ist ein Teilbereich von Edge AI, aber nicht jede Edge-KI ist TinyML. Eine Kamera mit einem leistungsfähigen KI-Beschleuniger, ein Industrie-PC oder ein Smartphone rechnet ebenfalls am Rand des Netzes. Sie besitzt jedoch eine ganz andere Leistungsklasse. TinyML beginnt dort, wo Energie, Speicher, Kosten und Baugröße so knapp werden, dass jedes Kilobyte und oft sogar jeder einzelne Rechenvorgang geplant werden muss.
| Ebene | Typische Hardware | Geeignete Aufgaben | Charakteristische Grenze |
|---|---|---|---|
| Cloud-KI | Rechenzentrum mit GPUs oder Spezialchips | Große Sprachmodelle, Training, komplexe Bild- und Videoanalyse | Netzverbindung, Latenz, Kosten und Datentransfer |
| Edge AI | Smartphone, Fahrzeugrechner, Gateway, Industrie-PC | Lokale generative KI, umfangreiche Vision-Modelle, Sensorfusion | Energie, Kühlung, Gerätekosten |
| TinyML | Mikrocontroller, Sensor-SoC, kleiner DSP | Aktivierungswörter, Anomalien, Gesten, Zustände, einfache Bilderkennung | Kilobyte-Speicher, Milliwatt-Leistung, enger Funktionsumfang |
Warum Mikrocontroller plötzlich lernen können
Mikrocontroller sind nicht plötzlich zu kleinen GPUs geworden. Der Fortschritt entsteht aus mehreren Entwicklungen, die ineinandergreifen. Moderne Controller rechnen effizienter, besitzen bessere Signalverarbeitungseinheiten und teilweise kleine Beschleuniger für neuronale Netze. Gleichzeitig sind Modelle kompakter geworden. Quantisierung, Pruning, Wissensdestillation und speziell entworfene Architekturen reduzieren Speicherbedarf und Rechenaufwand erheblich.
Hinzu kommen ausgereifte Softwarebibliotheken. Optimierte Rechenkerne nutzen die Befehlssätze der jeweiligen Prozessoren, statt eine für Server entworfene Laufzeitumgebung nur zu verkleinern. Werkzeuge übernehmen Teile der Modellkonvertierung, prüfen unterstützte Operatoren und messen, wie viel Flash, Arbeitsspeicher und Zeit eine Inferenz benötigt. Benchmarks wie MLPerf Tiny schaffen zudem vergleichbare Aufgaben für sehr kleine Systeme, etwa Schlüsselworterkennung, visuelle Aktivierung, Bildklassifikation und Anomalieerkennung.
Entscheidend ist jedoch ein dritter Faktor: Viele reale Sensoraufgaben sind enger begrenzt, als das Wort KI vermuten lässt. Ein Motorzustand, ein bestimmtes Geräusch oder eine Handbewegung erzeugt wiederkehrende Muster. Dafür muss ein Gerät kein allgemeines Weltwissen besitzen. Es benötigt ein gutes Signal, repräsentative Trainingsdaten und ein Modell, das genau diese eine Unterscheidung beherrscht.
Der Weg vom physikalischen Signal zur Entscheidung
Eine TinyML-Anwendung beginnt nicht beim neuronalen Netz, sondern in der physischen Welt. Mikrofon, Beschleunigungssensor, Kamera, Temperaturfühler, Stromsensor oder chemischer Sensor erzeugen Rohdaten. Diese werden abgetastet, gefiltert und in kurze Zeitfenster oder Bildausschnitte zerlegt. Erst danach erhält das Modell seine Eingabe.
1. Messen und abtasten
Die Abtastrate bestimmt, welche Informationen überhaupt sichtbar werden. Für langsame Temperaturverläufe reichen wenige Messungen pro Minute. Schwingungen einer Maschine oder Audiosignale benötigen deutlich höhere Frequenzen. Eine höhere Rate liefert aber nicht automatisch bessere Ergebnisse: Sie erzeugt mehr Daten, benötigt mehr Energie und vergrößert den Rechenaufwand. Forschung zu Zeitreihen zeigt, dass eine gezielte Reduktion der Messrate bei manchen Aufgaben Energie, Latenz und Speicherbedarf stark senken kann, ohne die Erkennungsqualität entsprechend zu verschlechtern.
2. Vorverarbeiten
Rohdaten enthalten Rauschen, Gleichanteile und Schwankungen. Deshalb werden sie normalisiert, gefiltert oder in eine andere Darstellung überführt. Bei Sprache und Geräuschen kommen häufig Spektralmerkmale zum Einsatz, die Frequenzverteilungen in kurzen Zeitfenstern beschreiben. Bei Bewegungssensoren können statistische Werte, Frequenzanteile oder mehrere Achsen kombiniert werden. Die Vorverarbeitung ist nicht bloß technisches Beiwerk: Ein ungeeignetes Signal lässt sich auch mit einem guten Modell nur schlecht retten.
3. Inferieren
Das Modell berechnet aus den Eingangswerten ein Ergebnis. Bei einer Klassifikation können das Wahrscheinlichkeiten für „normal“, „Unwucht“ und „Lagerschaden“ sein. Bei einer Regression entsteht ein Zahlenwert, etwa eine geschätzte Feuchtigkeit. Ein Anomalie-Modell lernt dagegen hauptsächlich den Normalzustand und meldet, wenn neue Messungen davon abweichen.
4. Entscheiden und handeln
Die Modellausgabe wird fast nie ungeprüft direkt in eine Aktion übersetzt. Eine robuste Anwendung ergänzt Schwellenwerte, Zeitregeln und Plausibilitätsprüfungen. Vielleicht muss eine Anomalie in mehreren aufeinanderfolgenden Fenstern auftreten, bevor ein Alarm ausgelöst wird. Bei sicherheitskritischen Geräten kann das KI-Ergebnis nur als zusätzlicher Hinweis dienen, während klassische Regeln die endgültige Steuerung übernehmen.
Damit entsteht eine kleine Verarbeitungskette: Sensor → Signalaufbereitung → Modell → Entscheidungslogik → Aktion oder Meldung. TinyML ist das lernende Element in dieser Kette, nicht das gesamte Produkt.
Wie klein ist „tiny“ wirklich?
Es gibt keine universelle Grenze, ab der ein Modell offiziell als TinyML gilt. In der Praxis wird der Begriff meist für Systeme verwendet, die ohne vollwertiges Desktop-Betriebssystem auskommen, sehr wenig Energie verbrauchen und mit stark begrenztem Speicher arbeiten. Viele Mikrocontroller besitzen getrennte Speicherbereiche: Flash hält Programm und Modell dauerhaft, SRAM enthält temporäre Daten während der Berechnung.
Ein Modell kann also in den Flash passen und trotzdem nicht laufen, wenn seine Zwischenaktivierungen zu viel Arbeitsspeicher benötigen. Bei neuronalen Netzen entstehen zwischen den Schichten sogenannte Aktivierungstensoren. Ihre Größe hängt unter anderem von Eingabeauflösung, Kanalzahl, Schichttyp und Implementierung ab. Deshalb reicht es nicht, nur die Dateigröße des Modells zu vergleichen.
Entwickler betrachten mindestens vier Budgets:
- Flash: Wie viel Platz benötigen Programmcode, Modellgewichte und Konstanten?
- SRAM: Wie groß sind Eingaben, Zwischenergebnisse, Puffer und Laufzeitstrukturen?
- Rechenzeit: Ist das Ergebnis schnell genug für die Anwendung?
- Energie: Wie viel Strom verbrauchen Sensor, Speicherzugriffe und Berechnung über den gesamten Betriebszyklus?
Gerade der letzte Punkt wird oft falsch eingeschätzt. Ein sehr schneller Prozessor ist nicht zwangsläufig schlechter für die Batterie. Wenn er eine Aufgabe in kurzer Zeit erledigt und danach wieder in einen tiefen Schlafzustand wechselt, kann das effizienter sein als eine langsamere Berechnung. Relevant ist die Energie pro vollständigem Ereignis, nicht allein die momentane Leistungsaufnahme.
Quantisierung: Wenn acht Bit genügen
Viele Modelle werden beim Training mit 32-Bit-Gleitkommazahlen berechnet. Auf Mikrocontrollern sind solche Werte teuer: Sie benötigen viel Speicher und nicht jeder Chip verarbeitet Gleitkommaoperationen effizient. Quantisierung ersetzt sie häufig durch 8-Bit-Ganzzahlen. Modellgewichte und Aktivierungen werden auf einen kleineren Wertebereich abgebildet. Dadurch schrumpft das Modell, Speicherzugriffe werden günstiger und optimierte Integer-Befehle können mehrere Operationen parallel ausführen.
Die einfache nachträgliche Quantisierung funktioniert bei manchen Modellen gut. Bei empfindlicheren Aufgaben wird das Modell quantisierungsbewusst trainiert. Dabei simuliert das Training bereits die späteren Rundungs- und Wertebereichseffekte. Das Modell lernt so, mit der geringeren numerischen Genauigkeit umzugehen.
Eine Verkleinerung auf vier Bit oder noch weniger ist möglich, aber nicht automatisch sinnvoll. Die Hardware muss das Format effizient unterstützen, und der Qualitätsverlust kann je nach Modell deutlich steigen. Für viele Mikrocontroller ist INT8 deshalb weiterhin ein praktischer Kompromiss aus Geschwindigkeit, Speicherbedarf, Werkzeugunterstützung und Genauigkeit.
Weitere Methoden, die Modelle mikrocontrollerfähig machen
Pruning
Beim Pruning werden Verbindungen oder ganze Strukturen entfernt, die nur wenig zum Ergebnis beitragen. Unstrukturiertes Pruning erzeugt viele einzelne Nullen. Das hilft jedoch nur, wenn Laufzeit und Hardware diese Sparsität ausnutzen können. Strukturiertes Pruning entfernt dagegen ganze Kanäle, Filter oder Blöcke und lässt sich auf eingebetteten Prozessoren häufig einfacher beschleunigen.
Wissensdestillation
Ein großes Lehrermodell erzeugt zusätzliche Zielinformationen für ein kleineres Schülermodell. Dieses lernt nicht nur die harten Klassenbezeichnungen, sondern auch feinere Ähnlichkeiten in den Ausgaben des Lehrers. So kann ein kompaktes Modell einen Teil der Leistungsfähigkeit eines größeren Systems übernehmen, ohne dessen gesamte Architektur zu kopieren.
Architektursuche und effiziente Bausteine
Mobile und Tiny-Netze verwenden Operationen, die weniger Multiplikationen und Speicherbewegungen benötigen. Dazu gehören separierbare Faltungen, schmale Bottlenecks und gezielt dimensionierte Eingaben. Automatische Architektursuche kann Varianten unter einem vorgegebenen Latenz- oder Speicherbudget bewerten. Entscheidend ist, das reale Zielgerät in die Optimierung einzubeziehen. Ein theoretisch kleines Modell kann auf einem bestimmten Mikrocontroller langsamer sein als ein etwas größeres Modell, dessen Operatoren besser unterstützt werden.
Operatorfusion und optimierte Kernel
Mehrere Rechenschritte lassen sich teilweise zusammenfassen, sodass Zwischenergebnisse nicht wiederholt in den Speicher geschrieben werden. Bibliotheken wie CMSIS-NN stellen für Arm-Cortex-M-Prozessoren optimierte neuronale Netzwerkfunktionen bereit. Vergleichbare Ansätze existieren für andere Architekturen. Solche Kernel sind ein wesentlicher Grund, warum identische Modelle auf ähnlich getakteten Chips sehr unterschiedliche Laufzeiten erreichen können.
Diese Optimierung ähnelt in ihrem Grundgedanken der Entwicklung kleiner offener Modelle: Nicht allein die Zahl der Parameter entscheidet, sondern das Zusammenspiel aus Architektur, Daten, Software und Hardware. Einen ausführlicheren Blick auf diesen Trend bietet unser Artikel über kleine offene KI-Modelle im Jahr 2026.
Welche Modelle eignen sich für TinyML?
TinyML arbeitet besonders gut mit klaren, wiederkehrenden sensorischen Mustern. Die folgenden Aufgaben gehören zu den häufigsten:
| Aufgabe | Typische Eingabe | Mögliche Anwendung |
|---|---|---|
| Schlüsselworterkennung | Kurze Audiofenster | Lokale Aktivierungswörter und einfache Sprachbefehle |
| Anomalieerkennung | Vibration, Strom, Schall, Temperatur | Zustandsüberwachung von Motoren, Pumpen und Anlagen |
| Gesten- und Aktivitätserkennung | Beschleunigung und Drehrate | Wearables, Werkzeuge, Bedienkonzepte |
| Einfache Bildklassifikation | Kleine Bilder oder Ausschnitte | Objektzustände, Zähler, Anwesenheit, Sortierung |
| Regression | Kombinierte Sensordaten | Schätzung von Feuchte, Verschleiß oder Prozessgrößen |
| Sensorfusion | Mehrere Sensortypen | Robustere Zustands- und Bewegungserkennung |
Generative Modelle spielen in dieser Leistungsklasse eine kleinere Rolle. Zwar gibt es Forschung zu extrem kompakten Sprach- und Sequenzmodellen, doch ein universeller Assistent auf einem klassischen Mikrocontroller bleibt etwas völlig anderes als TinyML im üblichen Sinn. TinyML gewinnt gerade dadurch, dass es nicht versucht, alles zu können.
Fünf Anwendungen mit praktischem Nutzen
1. Vorausschauende Instandhaltung
Ein Vibrationssensor an einem Motor kann charakteristische Veränderungen erkennen, bevor eine Störung offensichtlich wird. Das Gerät muss nicht permanent hochaufgelöste Rohdaten übertragen. Es kann lokal Merkmale berechnen und nur dann eine Meldung senden, wenn sich das Muster verändert. Das spart Funkenergie und reduziert die Datenmenge. Die Herausforderung liegt in den Trainingsdaten: Seltene Fehlerzustände sind schwer zu erfassen, und Maschinen unterscheiden sich durch Last, Montage und Umgebung.
2. Intelligente Gebäude
Belegungs- und Geräuscherkennung kann Heizung, Lüftung und Beleuchtung bedarfsgerechter steuern. Eine lokale Auswertung ist besonders interessant, wenn keine verständlichen Audioaufnahmen oder Bilder gespeichert werden sollen. Datenschutz entsteht dabei nicht allein durch das Wort „lokal“: Sensorauflösung, Puffer, Diagnosefunktionen und Updatewege müssen ebenfalls begrenzt und dokumentiert sein.
3. Landwirtschaft und Umweltmessung
Feuchte-, Licht-, Temperatur- und Bodensensoren können lokal kombiniert werden, um Bewässerung oder Warnmeldungen zu steuern. In Regionen mit instabiler Verbindung ist die Offline-Fähigkeit ein funktionaler Vorteil. Auch in Deutschland kann sie interessant sein, weil viele Messpunkte nur sporadisch Daten übertragen sollen. Das Modell muss jedoch saisonale Veränderungen und unterschiedliche Böden berücksichtigen; ein im Labor trainiertes System ist nicht automatisch auf jedem Feld zuverlässig.
4. Wearables und Medizintechnik
Bewegungsmuster, Herzsignale oder Atemdaten lassen sich direkt am Gerät vorverarbeiten. Das ermöglicht schnelle Reaktionen und reduziert die Übertragung sensibler Rohdaten. Bei medizinischen Anwendungen steigen allerdings die Anforderungen an Validierung, Risikomanagement und Nachvollziehbarkeit erheblich. Ein TinyML-Modell ist dann Teil eines regulierten Gesamtsystems und nicht bloß eine praktische Softwarefunktion.
5. Audio- und Bedienfunktionen
Aktivierungswörter sind ein klassisches Beispiel: Ein sehr kleines Modell hört kontinuierlich zu und aktiviert erst bei einem erkannten Muster ein leistungsfähigeres System. Ähnlich können Geräte Klatschen, Glasbruch, Alarmsignale oder Maschinenklänge unterscheiden. Der Vorteil ist die niedrige Latenz. Gleichzeitig müssen Fehlaktivierungen, Hintergrundgeräusche und unterschiedliche Stimmen bereits im Datensatz berücksichtigt werden.
Warum lokale KI nicht automatisch private KI ist
TinyML kann Datenschutz verbessern, weil Rohdaten das Gerät nicht verlassen müssen. Das reduziert Übertragungen und ermöglicht Funktionen ohne dauerhaftes Benutzerkonto. Trotzdem bleibt die gesamte Systemarchitektur entscheidend. Ein Gerät kann lokale Inferenz durchführen und gleichzeitig Diagnoseprotokolle oder Sensorausschnitte in die Cloud senden. Auch ein lokales Modell kann Rückschlüsse auf Personen ermöglichen.
Zu einem belastbaren Konzept gehören deshalb Datensparsamkeit, kurze Pufferzeiten, verschlüsselte Kommunikation, sichere Updates und eine klare Trennung zwischen Modellentscheidung und gespeicherten Rohdaten. Ebenso wichtig ist die Softwarelieferkette. Bibliotheken, Compiler, Firmware und Modellartefakte bilden gemeinsam das Produkt. Wie sich diese Bestandteile nachvollziehbar dokumentieren lassen, erklären wir im Beitrag zur Software Bill of Materials.
Sicherheit: Das Modell ist nur eine weitere Angriffsfläche
Ein vernetzter Mikrocontroller muss gegen manipulierte Firmware, unsichere Debug-Schnittstellen und gefälschte Updates geschützt werden. TinyML ergänzt weitere Risiken. Angreifer könnten Sensordaten so verändern, dass das Modell falsche Ergebnisse liefert. Ein gestohlener Modellstand kann geistiges Eigentum offenlegen. Bei schlecht abgesicherten Updateprozessen lässt sich ein vertrauenswürdiges Modell durch eine manipulierte Version ersetzen.
Technische Gegenmaßnahmen sind unter anderem signierte Firmware, Secure Boot, geschützte Schlüssel, Hardware-Vertrauensanker und eine verifizierte Updatekette. Auf Modellebene kommen robuste Datensätze, Grenzfalltests und Plausibilitätsregeln hinzu. Besonders wichtig ist ein sicherer Ausfallmodus. Wenn ein Modell unsicher ist oder der Sensor fehlerhafte Werte liefert, muss das Gerät in einen definierten Zustand wechseln, statt eine scheinbar präzise Entscheidung zu erzwingen.
Die schwierigste Ressource sind oft nicht die Rechenzyklen, sondern die Daten
TinyML-Demos lassen sich schnell bauen. Ein dauerhaft zuverlässiges Produkt erfordert wesentlich mehr Arbeit. Trainingsdaten müssen reale Gerätevarianten, Montagepositionen, Alterung, Temperatur, Hintergrundgeräusche und unterschiedliche Nutzer abbilden. Ein Bewegungsmodell, das am Handgelenk gut funktioniert, kann am Werkzeuggriff scheitern. Ein Geräuschklassifikator aus dem Labor kann in einer Werkhalle durch Reflexionen und konkurrierende Maschinen überfordert werden.
Hinzu kommt der sogenannte Data Drift. Prozesse verändern sich, Sensoren altern, Maschinen werden gewartet und Nutzer verhalten sich anders. Das Modell muss überwacht werden, obwohl es möglicherweise jahrelang offline arbeitet. Praktische Systeme speichern daher nicht zwangsläufig alle Rohdaten, aber sie sammeln zumindest aggregierte Qualitätsindikatoren: Wie oft war das Modell unsicher? Welche Eingangswerte lagen außerhalb des Trainingsbereichs? Haben Fehlalarme zugenommen?
Neue Daten müssen anschließend kontrolliert in Training und Test einfließen. Gerade seltene Störungen dürfen nicht versehentlich nur im Trainingssatz landen. Sonst wirkt das Modell im Labor besser, als es im Feld tatsächlich ist.
Wie eine TinyML-Entwicklung abläuft
- Aufgabe präzisieren: Welche Entscheidung soll getroffen werden, in welcher Zeit und mit welchen Folgen bei einem Fehler?
- Sensorik prüfen: Liefert der Sensor das relevante Signal in ausreichender Qualität? Welche Abtastrate ist nötig?
- Daten unter Realbedingungen sammeln: Nicht nur ideale Beispiele, sondern Varianten, Störungen und Grenzfälle.
- Baseline bauen: Zunächst eine einfache Regel oder ein klassisches Modell testen. Nicht jede Aufgabe benötigt ein neuronales Netz.
- Modell trainieren und komprimieren: Architektur, Eingabegröße und Quantisierung gemeinsam optimieren.
- Auf echter Hardware messen: Flash, SRAM, Latenz und Energie mit dem tatsächlichen Sensor und der späteren Firmware testen.
- Systemlogik ergänzen: Schwellenwerte, Wiederholungsregeln, sichere Zustände und Diagnose.
- Im Feld validieren: Unter wechselnden Bedingungen, über längere Zeit und mit Geräten aus der Produktion.
- Update- und Monitoringpfad planen: Modelle und Firmware müssen sicher aktualisierbar bleiben.
Dieser Ablauf verhindert einen häufigen Fehler: Ein beeindruckendes Notebook-Ergebnis wird zu früh als fertige Produktfunktion betrachtet. Erst auf der realen Hardware zeigt sich, ob Datenfluss, Energiebedarf und Modellqualität zusammenpassen.
Wie sich die Qualität eines TinyML-Systems messen lässt
Eine einzelne Genauigkeitszahl reicht für die Bewertung selten aus. Bei einem unausgeglichenen Datensatz kann ein Modell scheinbar sehr gut abschneiden, obwohl es den wichtigen Fehlerzustand kaum erkennt. Wenn 99 von 100 Messfenstern normal sind, erreicht ein Modell, das immer „normal“ ausgibt, bereits 99 Prozent Accuracy – und ist für die Wartung trotzdem wertlos.
Deshalb werden mehrere Kennzahlen benötigt. Die Sensitivität oder der Recall zeigt, welcher Anteil der tatsächlich relevanten Ereignisse erkannt wird. Die Precision beschreibt, wie viele ausgelöste Meldungen wirklich zutreffen. Beide Werte müssen zur Anwendung passen. Ein übersehener Defekt kann teuer sein; zu viele Fehlalarme führen jedoch dazu, dass Menschen die Warnungen ignorieren. Bei einem Aktivierungswort ist zusätzlich die Zahl falscher Aktivierungen pro Stunde oder Tag aussagekräftiger als ein abstrakter Durchschnittswert.
Auch die Zeitdimension zählt. Manche Modelle liefern für jedes kurze Fenster eine Vorhersage. Eine Anwendung reagiert aber erst, wenn mehrere Fenster nacheinander dieselbe Klasse zeigen. Dadurch verändert sich die praktische Fehlerrate. Tests sollten deshalb nicht nur einzelne Ausschnitte, sondern vollständige Audio-, Bewegungs- oder Maschinenverläufe auswerten.
Für die technische Seite gehören Latenz, Spitzenspeicher und Energie pro Inferenz in denselben Bericht wie die Modellqualität. Ein System kann mit einer hohen Erkennungsrate im Labor trotzdem ungeeignet sein, wenn der Sensor dauerhaft zu viel Strom benötigt oder die Berechnung nicht innerhalb des vorgesehenen Zeitfensters endet. Ebenso sollte der Energiebedarf im realen Betriebsprofil gemessen werden: Aufwachen, Sensor lesen, vorverarbeiten, inferieren, eventuell funken und wieder schlafen.
Schließlich braucht es getrennte Testgruppen. Daten von derselben Maschine, Person oder Aufnahmesitzung dürfen nicht zufällig auf Training und Test verteilt werden, wenn das Modell später auf neuen Geräten oder bei neuen Nutzern funktionieren soll. Sonst erkennt es möglicherweise Nebeneigenschaften des Versuchsaufbaus. Aussagekräftiger ist ein Test mit vollständig unbekannten Maschinen, Standorten oder Personen.
Ein gutes TinyML-Projekt definiert daher vor dem Training konkrete Abnahmekriterien: maximale Fehlalarme, minimaler Recall, zulässige Latenz, Speicherobergrenze, Batterieziel und Verhalten außerhalb des bekannten Datenbereichs. Erst wenn diese Werte gemeinsam erreicht werden, ist das Modell nicht nur klein, sondern produktionsreif.
Welche Software wird eingesetzt?
Im TinyML-Ökosystem gibt es offene Laufzeiten, herstellerspezifische Werkzeuge und kommerzielle Plattformen. TensorFlow Lite for Microcontrollers ist eine verbreitete C++-Laufzeit für eingebettete Systeme. Googles breiteres On-Device-Framework wird inzwischen unter dem Namen LiteRT weiterentwickelt; für klassische Mikrocontroller bleiben jedoch besonders schlanke Micro-Runtimes und unterstützte Operatoren entscheidend. Andere Wege nutzen MicroTVM, ONNX-basierte Konverter, herstellereigene Compiler oder direkt erzeugten C-Code.
Die Auswahl hängt weniger vom Markennamen als von fünf Fragen ab: Unterstützt das Werkzeug die Zielhardware? Sind alle Modelloperationen verfügbar? Kann es vollständig quantisierte Modelle erzeugen? Lassen sich Speicher und Latenz reproduzierbar messen? Und bleibt der Build über mehrere Produktjahre wartbar?
Offene Komponenten können Transparenz und Portierbarkeit erhöhen, lösen aber nicht automatisch alle Abhängigkeiten. Treiber, Compiler, optimierte Kernel und Hardwarebibliotheken bleiben Teil der Lieferkette. Die Entwicklung kleiner Modelle zeigt damit dieselbe Grundregel wie andere moderne KI-Projekte: Offenheit ist wertvoll, muss aber technisch und organisatorisch gepflegt werden.
Hardware: CPU, DSP, NPU und neue Sensorchips
Viele TinyML-Anwendungen laufen auf klassischen Mikrocontroller-Kernen. Arm Cortex-M ist weit verbreitet, zugleich gewinnen RISC-V-Plattformen an Bedeutung. Digitale Signalprozessoren beschleunigen wiederkehrende mathematische Operationen. Neuere Bausteine integrieren kleine NPUs, die Faltungen und Matrixoperationen effizienter ausführen können.
Der Beschleuniger allein entscheidet jedoch nicht über den Erfolg. Daten müssen zwischen Sensor, Speicher und Recheneinheit bewegt werden. Diese Transfers können einen großen Anteil der Energie verbrauchen. Deshalb richten sich neue Architekturen auf „Compute near Memory“ oder „In-Sensor Computing“: Vorverarbeitung und Teile der Inferenz rücken näher an den Ort, an dem die Daten entstehen. Dadurch müssen weniger Rohdaten durch das gesamte System transportiert werden.
Auch optische und neuromorphe Ansätze werden erforscht. Sie versprechen für bestimmte Aufgaben eine sehr hohe Effizienz, befinden sich aber je nach Technik in unterschiedlichen Reifestadien. Wie Rechnen mit Licht grundsätzlich funktioniert, zeigt unser Deep Dive zu Photonic Computing.
Was TinyML für deutsche und europäische Unternehmen bedeutet
Deutschland besitzt eine starke industrielle Basis in Maschinenbau, Automatisierung, Messtechnik, Medizintechnik und Fahrzeugtechnik. Genau dort entstehen viele Signale, die sich lokal auswerten lassen: Vibrationen, Ströme, Druck, Akustik, Temperatur und Bewegung. TinyML kann bestehende Produkte intelligenter machen, ohne jedes Gerät dauerhaft mit einem Rechenzentrum zu verbinden.
Für mittelständische Unternehmen sind drei Vorteile besonders relevant. Erstens können geringe Stückkosten eine Funktion auch in einfachen Geräten ermöglichen. Zweitens lässt sich die Datenmenge reduzieren, wenn nur Ereignisse und Kennzahlen statt kontinuierlicher Rohdaten übertragen werden. Drittens funktionieren Produkte auch bei schlechter Verbindung oder in abgeschotteten Produktionsnetzen.
Dem stehen neue Verantwortlichkeiten gegenüber. Wer ein lernendes Modell in ein Produkt integriert, muss dessen Grenzen dokumentieren, Qualitätsänderungen überwachen und sichere Updates gewährleisten. Je nach Anwendung greifen Produkt-, Datenschutz-, Cybersicherheits- und KI-Regeln. Eine lokale Berechnung kann die Einhaltung erleichtern, ersetzt aber weder Risikoanalyse noch technische Dokumentation.
Spart TinyML wirklich Energie?
Im Vergleich zur kontinuierlichen Übertragung hochauflösender Sensordaten kann lokale Inferenz deutlich effizienter sein. Funkmodule benötigen Energie, Netzinfrastruktur verarbeitet die Daten weiter und Cloud-Systeme müssen sie speichern oder analysieren. Wenn ein Mikrocontroller nur bei einem relevanten Ereignis sendet, sinken Datenverkehr und oft auch Betriebskosten.
Die Gesamtbilanz hängt jedoch vom System ab. Ein zusätzlicher Sensor, häufigere Messungen oder Millionen ständig aktive Geräte können Einsparungen wieder aufzehren. Auch das Training und die Herstellung der Hardware gehören zur Betrachtung. Nachhaltigkeit entsteht nicht automatisch durch kleine Modelle. Sie entsteht, wenn die lokale Intelligenz tatsächlich Übertragung, Rechenzeit, Wartungsfahrten oder Materialverbrauch reduziert und das Gerät lange nutzbar bleibt.
Wo TinyML an Grenzen stößt
- Enger Aufgabenbereich: Das Modell kann meist nur die Situation erkennen, für die es trainiert wurde.
- Begrenzte Aktualisierung: Geräte sind möglicherweise schwer erreichbar oder besitzen nur geringe Funkbandbreite.
- Seltene Fehlerdaten: Für Anomalien existieren oft wenige belastbare Beispiele.
- Hardwareabhängigkeit: Operatoren und Beschleuniger unterscheiden sich zwischen Plattformen.
- Erklärbarkeit: Ein Wahrscheinlichkeitswert erklärt noch nicht, warum sich eine Maschine anders verhält.
- Umgebungswechsel: Geräusch, Temperatur, Montage und Alterung verändern die Eingangsdaten.
- Sicherheitsanforderungen: Ein kleines Gerät kann dennoch Teil eines kritischen Prozesses sein.
In manchen Projekten ist eine klassische Regel besser. Wenn ein Grenzwert physikalisch klar definiert und stabil messbar ist, wäre ein neuronales Netz unnötig kompliziert. TinyML lohnt sich besonders dort, wo relevante Muster zu komplex für einfache Regeln sind, aber klein und regelmäßig genug für ein spezialisiertes Modell bleiben.
Die Zukunft: Intelligenz rückt bis in den Sensor
Die Entwicklung geht in drei Richtungen. Erstens werden Mikrocontroller und Beschleuniger leistungsfähiger, ohne ihren niedrigen Energiebedarf aufzugeben. Zweitens werden Modelle systematischer auf reale Hardwarebudgets zugeschnitten. Drittens wandert Vorverarbeitung immer näher an den Sensor.
Auch lokales Lernen wird erforscht. Ein Gerät könnte sich in engen Grenzen an seine individuelle Maschine oder Umgebung anpassen, ohne Rohdaten zu übertragen. Das ist technisch anspruchsvoll: Training benötigt Speicher und Energie, und unkontrollierte Anpassung kann die Qualität verschlechtern. Wahrscheinlicher sind zunächst hybride Verfahren, bei denen Geräte ausgewählte Statistiken oder sichere Updates austauschen.
Langfristig dürfte TinyML weniger als sichtbare Produktkategorie auftreten, sondern als unsichtbare Basistechnik. Ähnlich wie Mikrocontroller heute selbstverständlich Motoren, Anzeigen und Kommunikation steuern, könnten kleine Modelle kontinuierlich Sensoren interpretieren. Nutzer sehen dann nicht „eine KI“, sondern ein Gerät, das schneller reagiert, weniger Daten sendet und seinen Zustand besser versteht.
Fazit: TinyML ist KI mit einem klaren Auftrag
TinyML zeigt, dass Fortschritt in künstlicher Intelligenz nicht nur aus immer größeren Modellen und Rechenzentren besteht. Ein wenige Millimeter großer Chip kann nützliche Muster erkennen, wenn Aufgabe, Daten, Modell und Hardware konsequent aufeinander abgestimmt sind.
Die Technik eignet sich für Sensoren, Maschinen, Wearables und Geräte, die schnell, sparsam und auch offline reagieren müssen. Ihre Stärke liegt in der Spezialisierung: Ein TinyML-System versteht nicht die ganze Welt, aber möglicherweise genau das Geräusch, die Bewegung oder die Schwingung, die für seine Aufgabe entscheidend ist.
Damit verschiebt sich die Frage von „Wie viel KI passt in ein Gerät?“ zu „Welche kleinste, verlässlichste Form von Intelligenz löst das konkrete Problem?“ Genau diese Haltung macht TinyML technisch und wirtschaftlich interessant.
