TinyML in der Praxis: Engineering-Methoden und Performance-Benchmarks für die Komprimierung von Deep Learning auf MCUs

I. Definition und industrielle Bedeutung von TinyML

TinyML – die Bereitstellung von Machine-Learning-Modellen auf Mikrocontrollern (Microcontroller Unit, MCU) mit einem Energieverbrauch von nur wenigen Milliwatt – definiert die Grenzen der Edge-Intelligenz neu. Warden und Situnayake definieren in ihrem wegweisenden Werk^[1] TinyML als „Technologien und Methoden zur Ausführung von Machine-Learning-Inferenz auf Geräten mit extrem niedrigem Energieverbrauch", mit dem Kernziel, Milliarden bereits eingesetzter eingebetteter Geräte – von industriellen Sensoren bis zu Wearables – mit lokaler intelligenter Entscheidungsfähigkeit auszustatten, ohne auf Cloud-Konnektivität angewiesen zu sein.

Die industrielle Bedeutung dieses Ziels ist kaum zu überschätzen. Nach Schätzungen von ARM werden weltweit jährlich über 30 Milliarden MCUs ausgeliefert, doch der Anteil mit KI-Inferenzfähigkeit liegt unter 1 %. Wenn dieser Anteil signifikant gesteigert werden kann, entsteht ein völlig neues Ökosystem der „allgegenwärtigen Edge-Intelligenz" – von Predictive Maintenance über Anomalieerkennung bis hin zu Sprachweckwort und Gestenerkennung werden unzählige Anwendungsszenarien freigesetzt, die bisher daran scheiterten, dass „KI nur mit Internetverbindung möglich war".

Die Engineering-Herausforderungen von TinyML sind jedoch beträchtlich. Ein typischer MCU – wie der ARM Cortex-M4 – verfügt über lediglich 256 KB Flash-Speicher und 64 KB SRAM bei einer Taktfrequenz von 80–168 MHz. Im Vergleich dazu benötigt ein Standard-ResNet-50-Modell über 97 MB Speicherplatz und 3,8 GFLOPS Rechenleistung. Wie lässt sich ein Deep-Learning-Modell um das Hundertfache komprimieren und dabei eine akzeptable Inferenzqualität beibehalten? Genau das ist die zentrale Frage, die dieser Technische Report beantwortet.

II. Die drei Säulen der Modellkomprimierung: Pruning, Quantisierung, Destillation

2.1 Strukturiertes Pruning: Entfernung redundanter Neuronen

Han et al. stellten in ihrem wegweisenden „Deep Compression"-Paper^[2] eine dreistufige Modellkomprimierungs-Pipeline vor: Pruning, Quantisierung und Huffman-Codierung, die AlexNet um den Faktor 35 und VGG-16 um den Faktor 49 komprimierte – nahezu ohne Genauigkeitsverlust. Diese Arbeit legte das technische Fundament für das gesamte Gebiet der Modellkomprimierung.

In der TinyML-Praxis setzen wir hauptsächlich auf „strukturiertes Pruning" – das vollständige Entfernen unwichtiger Faltungsfilter oder Neuronen vollständig verbundener Schichten, im Gegensatz zu „unstrukturiertem Pruning" (Entfernung einzelner Gewichte). Der Grund: Unstrukturiertes Pruning erzeugt dünnbesetzte Matrizen, die auf MCUs schwer effizient nutzbar sind – MCUs verfügen nicht über spezialisierte Hardware für Sparse-Berechnungen, und der zusätzliche Speicher-Overhead für Sparse-Indizierung kann kontraproduktiv wirken. Strukturiertes Pruning reduziert direkt die Dimensionen des Berechnungsgraphen und bringt auf jeder Hardware eine substanzielle Beschleunigung.

Unsere Pruning-Strategie basiert auf L1-Norm-Wichtigkeitsbewertung – die Berechnung der L1-Norm der Gewichte jedes Faltungsfilters, wobei Filter mit den kleinsten Normen als am unwichtigsten betrachtet und entfernt werden. Bei MobileNetV2 stellten wir fest, dass 40 % der Filter sicher entfernt werden können, bei nur 1,8 % Genauigkeitsverlust. Weiteres Fine-Tuning kann den Verlust auf unter 0,6 % reduzieren.

2.2 Quantisierung: Von Gleitkomma zu Ganzzahl

Quantisierung ist die wichtigste Komprimierungstechnik im TinyML-Bereich. Jacob et al. stellten auf der CVPR 2018^[4] ein vollständiges Quantisierungsverfahren vor, das Gewichte und Aktivierungswerte neuronaler Netze von 32-Bit-Gleitkommazahlen (FP32) in 8-Bit-Ganzzahlen (INT8) konvertiert und so eine Inferenz ausschließlich mit Ganzzahlarithmetik ermöglicht. Diese Technik bietet drei Vorteile: Modellgröße auf 25 % reduziert, Inferenzgeschwindigkeit 2–4-fach erhöht (durch Nutzung der Ganzzahl-Recheneinheiten des MCU), Energieverbrauch um etwa 30 % gesenkt.

In der Praxis testeten wir zwei Quantisierungsstrategien. Die „Post-Training-Quantisierung" (PTQ) ist die einfachste Methode – nach Abschluss des Modelltrainings wird mit einem kleinen Kalibrierungsdatensatz (typischerweise 100–500 Samples) die Verteilung der Aktivierungswerte jeder Schicht statistisch erfasst und daraus die Quantisierungsparameter bestimmt. Der Vorteil der PTQ liegt darin, dass kein erneutes Training erforderlich ist, sie kann aber bei bestimmten Modellen 2–3 % Genauigkeitsverlust verursachen.

Das „Quantization-Aware Training" (QAT) simuliert bereits während des Trainings die Quantisierungseffekte und lässt das Modell lernen, sich an die niedrigpräzise numerische Darstellung anzupassen. QAT kann den Genauigkeitsverlust typischerweise auf unter 0,5 % begrenzen, erfordert aber zusätzliche Trainingszeit. Für Modelle, die auf extrem speicherbeschränkten MCUs bereitgestellt werden, empfehlen wir QAT nachdrücklich.

2.3 Knowledge Distillation: Auf den Schultern von Riesen

Die 2015 von Hinton et al. vorgestellte Knowledge Distillation^[3] ist eine elegante Modellkomprimierungsmethode, die die Ausgabeverteilung eines großen „Lehrermodells" nutzt, um das Training eines kleinen „Schülermodells" anzuleiten. Die Kernintuition: Die Ausgabeverteilung des Lehrermodells enthält weitaus reichhaltigere Informationen als einfache korrekte Labels – wenn beispielsweise ein Katzenbild vom Lehrermodell klassifiziert wird, kann die Wahrscheinlichkeit für „Hund" deutlich höher sein als für „Auto", und diese in „Soft Labels" enthaltenen relativen Beziehungen tragen Informationen über semantische Ähnlichkeiten zwischen Klassen.

In unserem TinyML-Workflow spielt Knowledge Distillation die Rolle einer „Brücke" – sie transferiert das Wissen großer Cloud-Modelle auf Miniaturmodelle, die auf MCUs bereitgestellt werden können. Konkret verwenden wir ResNet-50 (25,6M Parameter) als Lehrermodell und eine Variante der MCUNet-Architektur^[5] (0,74M Parameter) als Schülermodell. Die Destillations-Verlustfunktion kombiniert Hard-Label-Kreuzentropie mit Soft-Label-KL-Divergenz bei einem Temperaturparameter von T=4.

Die Testergebnisse sind ermutigend: Auf einem 50-Klassen-Subset von ImageNet erreichte ein direkt trainiertes MCUNet eine Genauigkeit von 71,3 %, während das destillierte MCUNet auf 76,8 % stieg und damit 94,7 % der Lehrermodell-Genauigkeit (81,1 %) bewahrte. Noch wichtiger: Das destillierte Modell zeigte bei Grenzfällen (Ambiguous Cases) eine signifikant verbesserte Leistung, und der Kalibrierungsfehler (Calibration Error) sank um 42 %.

III. Deployment-Workflow: Von PyTorch zum ARM Cortex-M

3.1 Modellkonvertierungs-Pipeline

Die Bereitstellung eines in PyTorch trainierten Modells auf einem Cortex-M-MCU erfordert folgende Konvertierungsschritte: PyTorch → ONNX → TensorFlow → TensorFlow Lite → TensorFlow Lite Micro (TFLM). Das von David et al. auf der MLSys 2021 vorgestellte TFLM-Framework^[7] ist derzeit der De-facto-Standard für die Bereitstellung von Deep-Learning-Modellen auf MCUs – es bietet eine extrem schlanke Inferenz-Engine ohne dynamische Speicherzuweisung, ohne Standard-C-Bibliothek und mit Unterstützung der CMSIS-NN-Beschleunigung für die gängigen ARM Cortex-M-Serien.

Jeder Konvertierungsschritt kann Präzisionsfehler einführen, weshalb wir in der Pipeline einen schichtweisen numerischen Validierungsmechanismus implementiert haben – nach jedem Konvertierungsschritt werden mit denselben Testeingaben die Ausgabewerte jeder Schicht verglichen, um sicherzustellen, dass der relative Fehler innerhalb von 1e-5 (FP32) oder 1 Quantisierungsstufe (INT8) liegt.

3.2 Speicherplanung

Die Speicherverwaltung auf MCUs unterscheidet sich grundlegend von Desktop-Umgebungen. Flash (nichtflüchtiger Speicher) wird für Modellgewichte verwendet, SRAM (flüchtiger Speicher) für die Aktivierungswerte während der Inferenz. Lin et al. stellten in ihrem MCUNet-Paper^[5] die „TinyNAS + TinyEngine"-Co-Design-Methode vor – mittels Neural Architecture Search wird die optimale Modellarchitektur für ein gegebenes Speicherbudget gefunden, gleichzeitig wird eine speicherbewusste Inferenz-Engine entwickelt, die die Wiederverwendungsrate des Aktivierungsspeichers maximiert.

In unserer Praxis ist die Speicherplanung die Phase, die die feinste Abstimmung erfordert. Am Beispiel des STM32F407 (1 MB Flash, 192 KB SRAM): Die Modellgewichte müssen auf unter 512 KB beschränkt werden (Freiraum für Anwendungscode und andere Funktionen), und der Spitzenwert des Aktivierungsspeichers muss unter 128 KB bleiben. Dies bedeutet, dass die „Breite" des Modells (Anzahl der Kanäle pro Schicht) nicht nur von den Genauigkeitsanforderungen bestimmt wird, sondern auch durch die harte Beschränkung der SRAM-Größe.

3.3 Hardware-Beschleunigung

Die FPU (Floating Point Unit) und der DSP-Befehlssatz (Digital Signal Processing) des ARM Cortex-M7 können die Inferenz neuronaler Netze erheblich beschleunigen. Unser TFLM-Deployment nutzt den CMSIS-NN-Kernel – eine von ARM offiziell bereitgestellte, für Cortex-M optimierte Beschleunigungsbibliothek für neuronale Netze, die SIMD-Befehle (Single Instruction Multiple Data) nutzt, um mehrere INT8-Multiply-Accumulate-Operationen in einem Taktzyklus auszuführen.

Praxistests zeigen, dass die CMSIS-NN-Beschleunigung im Vergleich zur reinen C-Implementierung auf dem Cortex-M7 eine 3,2-fache und auf dem Cortex-M4 eine 2,4-fache Steigerung der Inferenzgeschwindigkeit erzielt.

IV. Performance-Benchmark-Ergebnisse

4.1 Testplattformen und Aufgaben

Wir führten systematische Performance-Benchmarks auf drei Hardwareplattformen durch: STM32F407 (Cortex-M4, 168 MHz, 1 MB Flash, 192 KB SRAM), STM32F746 (Cortex-M7, 216 MHz, 1 MB Flash, 320 KB SRAM) und STM32H743 (Cortex-M7, 480 MHz, 2 MB Flash, 1 MB SRAM). Die Testaufgaben umfassten drei repräsentative Szenarien: Keyword Spotting (10 Klassen), Bildklassifikation (50-Klassen-ImageNet-Subset) und Anomalieerkennung bei Geräuschen.

Banbury et al. etablierten auf der NeurIPS 2021 mit dem MLPerf Tiny Benchmark^[6] ein standardisiertes Framework zur Leistungsbewertung im TinyML-Bereich. Unsere Tests folgen der MLPerf-Tiny-Methodik, um die Vergleichbarkeit der Ergebnisse sicherzustellen.

4.2 Keyword Spotting

Bei der 10-Klassen-Keyword-Spotting-Aufgabe auf dem Google Speech Commands-Datensatz erzielte unsere Komprimierungs-Pipeline (strukturiertes Pruning + INT8-Quantisierung + Knowledge Distillation) folgende Ergebnisse auf den drei Plattformen: STM32F407 – 91,2 % Genauigkeit, 58 ms Inferenzlatenz; STM32F746 – 92,8 % Genauigkeit, 23 ms Inferenzlatenz; STM32H743 – 93,5 % Genauigkeit, 11 ms Inferenzlatenz. Die Modellgröße beträgt nur 63 KB und passt problemlos auf alle Zielplattformen.

4.3 Bildklassifikation

Die 50-Klassen-ImageNet-Subset-Bildklassifikationsaufgabe ist deutlich anspruchsvoller. Bei einer Eingangsauflösung von 96×96 RGB beträgt die komprimierte MCUNet-Variante 348 KB. Die Inferenzlatenz auf dem STM32F407 beträgt 412 ms (ungeeignet für Echtzeitanwendungen), auf dem STM32H743 sinkt sie auf 87 ms (akzeptabel für Anwendungen mit über 10 Bildern pro Sekunde). In puncto Genauigkeit erreicht das INT8-quantisierte Modell 75,1 %, gegenüber 76,8 % des FP32-Originalmodells – ein Verlust von nur 1,7 %.

4.4 Anomalieerkennung bei Geräuschen

Die Anomalieerkennung bei Geräuschen verwendet eine Autoencoder-Architektur mit einer Modellgröße von nur 28 KB. Auf allen drei Plattformen wurde eine Inferenzlatenz unter 10 ms erreicht, bei einer AUC (Area Under the Curve) von 0,94. Diese Aufgabe demonstriert das enorme Potenzial von TinyML in industriellen IoT-Szenarien für Predictive Maintenance – ein batteriebetriebener Akustiksensor kann die Anomalieerkennung lokal durchführen, ohne Roh-Audiodaten in die Cloud hochladen zu müssen.

V. Best Practices und Zukunftsperspektiven

5.1 Engineering Best Practices

Basierend auf unserer Praxiserfahrung haben wir folgende Best Practices für das TinyML-Deployment zusammengestellt:

• Erst quantisieren, dann prunen: Entgegen der Intuition haben wir festgestellt, dass die Reihenfolge „erst Quantization-Aware Training, dann strukturiertes Pruning" eine bessere Endgenauigkeit liefert als die umgekehrte Reihenfolge (durchschnittliche Verbesserung von 0,8 %).
• Repräsentativität des Kalibrierungsdatensatzes beachten: Die Qualität der Post-Training-Quantisierung hängt stark vom Kalibrierungsdatensatz ab. Stellen Sie sicher, dass der Kalibrierungsdatensatz Grenzfälle aller Klassen abdeckt und nicht nur einfache Samples enthält.
• End-to-End-Automatisierungs-Pipeline aufbauen: Jeder Schritt vom Modelltraining bis zum MCU-Deployment sollte automatisiert sein, einschließlich schichtweiser numerischer Validierung und Hardware-in-the-Loop-Tests.
• Mixed-Precision-Quantisierung nutzen: Nicht alle Schichten benötigen die gleiche Quantisierungspräzision. Die erste und letzte Schicht sind typischerweise empfindlicher gegenüber Quantisierung und können mit höherer Präzision (INT16) beibehalten werden, während mittlere Schichten INT8 verwenden.

5.2 Zukunftsperspektiven

Das TinyML-Gebiet entwickelt sich rasant weiter. Wir sehen drei Richtungen, die in den nächsten 2–3 Jahren die Leistungsgrenzen von TinyML erheblich erweitern werden: Erstens, fortschrittlichere Neural Architecture Search-Methoden – wie die von Lin et al.^[5] mit MCUNet initiierte hardwarebewusste NAS, die Modellstrukturen weiter für spezifische MCU-Architekturen optimieren wird. Zweitens, aufkommende Binarisierungs- und Ternarisierungstechniken für Netzwerke – die Quantisierung auf 1–2 Bit vorantreiben und KI-Inferenz auf Ultra-Low-Power-Cortex-M0+-Prozessoren ermöglichen könnten. Drittens, On-Device-Training – derzeit sind Inferenz und Training bei TinyML getrennt, doch mit zunehmender Speicherkapazität und Rechenleistung wird inkrementelles Fine-Tuning auf MCUs möglich, was eine wirklich adaptive Edge-Intelligenz realisiert.

TinyML ist nicht nur eine technische Herausforderung, sondern auch ein Paradigmenwechsel im Denken – von „größere Modelle, mehr Daten, stärkere Rechenleistung" hin zu „cleverere Architekturen, präzisere Komprimierung, intelligenteres Deployment". Der Wert dieses Denkansatzes reicht weit über den eigentlichen Anwendungsbereich von TinyML hinaus.