InstMeter: An Instruction-Level Method to Predict Energy and Latency of DL Model Inference on MCUs

Die Arbeit stellt InstMeter vor, eine präzise und dateneffiziente Methode zur Vorhersage von Energieverbrauch und Latenz bei der Inferenz von Deep-Learning-Modellen auf Mikrocontrollern auf Basis von Taktzyklen, die im Vergleich zu bestehenden Ansätzen deutlich geringere Fehler aufweist und die Suche nach optimalen Modellen im Rahmen des Neural Architecture Search (NAS) verbessert.

Das Wesentliche

Das Problem: Der „Blackbox"-Koch

Stellen Sie sich vor, Sie wollen einen kleinen, batteriebetriebenen Computer (einen Mikrocontroller, wie in einer Smartwatch oder einem Hörgerät) bauen, der lernen kann, Dinge zu erkennen – zum Beispiel, ob jemand „Hey" sagt oder ein Bild eines Hundes zeigt.

Um das zu tun, braucht man einen Deep-Learning-Modell (eine Art mathematisches Gehirn). Das Problem ist: Diese Gehirne sind oft zu groß oder zu hungrig für die kleinen Batterien der Geräte.

Bisher haben Forscher versucht vorherzusagen, wie viel Energie und Zeit ein solches Modell braucht, indem sie grobe Schätzwerte nutzten.

• Die alte Methode: Sie zählten einfach, wie viele Rechenaufgaben das Modell macht (wie viele Zutaten in einem Rezept). Aber das ist wie zu sagen: „Ein Kuchen braucht 5 Eier", ohne zu wissen, ob der Ofen heiß ist oder ob der Koch langsam oder schnell arbeitet. Das Ergebnis war oft ungenau. Man musste tausende von Modellen ausprobieren, um eine gute Schätzung zu bekommen – das kostet viel Zeit und Batterie.

Die Lösung: InstMeter – Der „Tacho" für den Computer

Die Forscher (Hao Liu, Qing Wang und Marco Zuniga) haben InstMeter erfunden. Das ist wie ein hochpräziser Tacho und ein Kraftstoffverbrauchsmesser für den kleinen Computer.

Hier ist die Idee in einfachen Bildern:

1. Der Blick unter die Motorhaube (Befehle statt Zutaten)

Statt nur zu zählen, was das Modell tut (die Zutaten), schaut InstMeter genau hin, wie der Computer es tut.

• Die Analogie: Stellen Sie sich vor, Sie wollen wissen, wie lange ein Auto braucht, um eine Strecke zu fahren.
  • Die alte Methode zählt nur die Kilometer.
  • InstMeter schaut sich den Motor an. Es zählt jeden einzelnen Hub des Kolbens (die Befehle oder Instructions). Jeder Befehl kostet eine bestimmte Menge Zeit und Energie, genau wie jeder Kolbenhub Treibstoff verbraucht.

2. Die Magie der Geradlinigkeit (Das Lineal)

Das Geniale an InstMeter ist, dass es linear funktioniert.

• Die alte Methode: War wie ein gekrümmtes, verwickeltes Seil. Um zu wissen, wie viel Energie man braucht, musste man das Seil tausendmal abmessen, um die Krümmung zu verstehen.
• InstMeter: Ist wie ein Lineal. Wenn Sie wissen, wie viele Befehle (Kolbenhübe) das Modell ausführt, können Sie die Energie und Zeit fast sofort berechnen.
  • Beispiel: Wenn 100 Befehle 10 Millisekunden dauern, dann dauern 200 Befehle einfach 20 Millisekunden. Es gibt keine versteckten Krümmungen.

3. Der Trick: Die Brücke zwischen Plan und Realität

Wie weiß InstMeter, wie viele Befehle ausgeführt werden, ohne das Modell jedes Mal auf dem echten Chip laufen zu lassen?

• Die Forscher haben eine Brücke gebaut zwischen dem Plan (dem C++-Code, den Programmierer schreiben) und der Realität (dem Maschinencode, den der Chip versteht).
• Sie haben einen cleveren Algorithmus entwickelt, der die Schleifen im Plan (z. B. „Mache das 1000 Mal") mit den tatsächlichen Befehlen im Chip verbindet.
• Das Ergebnis: Sie müssen das Modell nicht tausendmal testen. Sie brauchen nur wenige Probeläufe (wie 5 bis 10), um die genaue Beziehung zwischen Befehlen und Energie zu lernen. Danach kann InstMeter jede beliebige neue Schätzung in Sekunden machen.

Warum ist das so wichtig?

Stellen Sie sich vor, Sie sind ein Architekt, der ein Haus bauen will, aber Sie wissen nicht, wie viel Beton Sie brauchen.

• Mit der alten Methode: Sie müssten tausende Häuser bauen, um zu sehen, ob das Fundament hält. Das wäre teuer und langsam.
• Mit InstMeter: Sie können mit einem Lineal und ein paar Messungen sofort sagen: „Für dieses Haus brauchen wir genau 500 Ziegelsteine."

Die Vorteile im Überblick:

1. Extrem schnell: Man braucht 100-mal weniger Daten zum Lernen als bei anderen Methoden.
2. Sehr genau: Die Vorhersagen sind viel genauer (bis zu 6,5-mal besser bei der Zeit und 3-mal besser bei der Energie).
3. Robust: Es funktioniert auf verschiedenen Chips (ARM und RISC-V), bei verschiedenen Temperaturen (kalt oder warm), mit verschiedenen Programmiersprachen-Versionen und sogar wenn man den Computer auf „Energiesparmodus" oder „Turbo-Modus" stellt.

Fazit

InstMeter ist wie ein Wunderwerkzeug für Ingenieure. Es erlaubt ihnen, die perfekten, energieeffizienten KI-Modelle für kleine Geräte zu finden, ohne tausende von Batterien zu verschwenden. Es verwandelt ein kompliziertes, unvorhersehbares Rätsel in eine einfache Addition: Anzahl der Befehle = Genau verbrauchte Energie.

Dank dieser Erfindung können wir in Zukunft intelligentere Uhren, Hörgeräte und Sensoren bauen, die länger halten und schneller reagieren.

Technische Zusammenfassung

1. Problemstellung

Deep Learning (DL) Modelle werden zunehmend auf Mikrocontrollern (MCUs) eingesetzt, was kompakte und intelligente Geräte ermöglicht. Das Design effizienter Modelle erfolgt oft mittels Neural Architecture Search (NAS), die Tausende von Architekturen evaluiert, um die beste unter Ressourcenbeschränkungen (Speicher, Energie, Latenz) zu finden.

Das zentrale Problem besteht darin, den Energieverbrauch und die Latenz dieser Modelle präzise vorherzusagen, ohne jedes Modell physisch auszuführen (was zeit- und ressourcenintensiv ist).

• Bestehende Ansätze (SOTA): Aktuelle Methoden basieren auf groben Proxy-Metriken wie Multiply-Accumulations (MACs) oder Modellparametern.
• Nachteile: Diese Parameter haben eine nicht-lineare Beziehung zu den tatsächlichen Energie- und Latenzkosten auf MCUs. Gründe hierfür sind Compiler-Optimierungen, spezifische Kernel-Implementierungen und Instruktionsscheduling.
• Folge: Um diese Nicht-Linearität zu lernen, benötigen SOTA-Methoden (z. B. nn-Meter oder MAC-basierte Regressoren) enorme Trainingsdatensätze (oft 1.000 bis 5.000 Samples), was die Entwicklung verlangsamt und die Generalisierung erschwert.

2. Methodik: InstMeter

InstMeter ist ein Framework, das die Vorhersage von einem nicht-linearen in ein lineares Problem transformiert, indem es auf der Ebene der Maschinencode-Instruktionen ansetzt.

Kernidee:
Die tatsächlichen Kosten (Energie und Latenz) werden direkt durch die Anzahl der CPU-Taktszyklen bestimmt, die für die Ausführung der Instruktionen benötigt werden. Da die Beziehung zwischen Taktszyklen und Energie/Latenz auf MCUs inhärent linear ist, kann ein einfacher linearer Regressor verwendet werden:
$$E (\text{oder } L) = a \cdot \text{Cycles} + b$$
Wobei $a$ die Energie pro Zyklus (bzw. Zeit pro Zyklus) und $b$ ein fester Overhead pro Inferenz ist.

Schlüsselkomponenten:

1. Instruction Profiling (Quellcode-zu-Disasm-Mapping):

   • Um die Zyklenzahl zu berechnen, müssen die ausgeführten Instruktionen und deren Häufigkeit bekannt sein.
   • Herausforderung: Der Quellcode (C++) enthält Schleifenvariablen, aber keine Instruktionendetails. Der Disassemblierter Code (Disasm) enthält Instruktionen, aber die Variablenwerte sind durch Compiler-Optimierungen verschleiert (z. B. var_C8 statt kernel_x).
   • Lösung: InstMeter nutzt eine neuartige Mapping-Methode, die Quellcode und Disasm-Code auf Schleifenebene verknüpft.
     • Strukturelle Merkmale: Es werden Control Flow Graphs (CFGs) erstellt, um die Beziehungen zwischen Schleifen (Teilmenge, Schnittmenge) zu analysieren.
     • Semantische Merkmale: Da Variablennamen oft verloren gehen, werden Vergleichsoperatoren (z. B. <, >) als semantische Merkmale genutzt, da diese sowohl im Quellcode als auch in den Verzweigungsanweisungen des Disasm-Codes konsistent auftreten.
     • Ein Algorithmus (basierend auf VF2 für Graph-Matching und gewichteter Ähnlichkeitsberechnung) ordnet die Schleifen des Quellcodes den entsprechenden Schleifen im Disasm-Code zu.

2. Instruktionsbibliothek:

   • Einmalig wird eine Bibliothik erstellt, die jedem Operator (z. B. Conv2D) die Anzahl der Instruktionen und deren Zykluskosten (CPI) zuordnet.
   • Für ein neues Modell wird nicht kompiliert; stattdessen werden die Zyklen basierend auf den Modellparametern (Schleifengrößen) und der Bibliothik berechnet.

3. Datenkollektion:

   • Aufgrund der Linearität des Modells werden nur wenige Trainingsdaten (z. B. 5 Samples) benötigt, um die Parameter $a$ und $b$ zu bestimmen.

3. Hauptbeiträge

1. Paradigmenwechsel: Umwandlung der Energie/Latenz-Schätzung von einem nicht-linearen in ein lineares Problem durch die Nutzung von Taktszyklen als Proxy. Dies reduziert den Trainingsbedarf drastisch.
2. Neues Mapping-Verfahren: Entwicklung eines effizienten Algorithmus zur feinkörnigen Abbildung von Quellcode-Schleifen auf Disasm-Code unter Verwendung struktureller und semantischer Merkmale (Vergleichsoperatoren), ohne DL-Modelle selbst zu nutzen.
3. Umfassender Datensatz: Erstellung eines Benchmark-Datensatzes mit 2.125 Modellen, gemessen auf vier MCUs (ARM Cortex-M4, M7, M33 und RISC-V ESP32-C3) unter verschiedenen Bedingungen (Compiler-Optimierungen, GCC-Versionen, Temperaturen, DVFS, Anwendungen).
4. Leistungsnachweis: Nachweis, dass InstMeter mit minimalen Trainingsdaten (5 Samples) deutlich genauere Ergebnisse liefert als SOTA-Methoden, die tausende Samples benötigen.

4. Ergebnisse

Die Evaluation wurde auf drei ARM-MCUs und einem RISC-V-MCU durchgeführt und verglich InstMeter mit MAC-basierten Methoden und nn-Meter.

• Genauigkeit:
  • InstMeter reduziert den Vorhersagefehler für Energie um das 3-fache und für Latenz um das 6,5-fache im Vergleich zu SOTA.
  • Mit nur 5 Trainingsproben erreicht InstMeter für 90% der Modelle einen relativen Fehler von unter 30%.
  • Im Vergleich dazu benötigt nn-Meter 500 Samples und erreicht bei 90% der Modelle einen Fehler von ca. 100%.
• Trainingsbedarf:
  • InstMeter benötigt 100-mal weniger Daten als nn-Meter und 10-mal weniger als MAC-basierte Methoden, um bessere Ergebnisse zu erzielen.
• NAS-Szenario:
  • In der neuronalen Architektursuche (NAS) konnte InstMeter Modelle identifizieren, die näher am Energie-Budget lagen und eine höhere Inferenzgenauigkeit aufwiesen als Modelle, die mit anderen Prädiktoren gefunden wurden.
• Robustheit und Generalisierung:
  • Das System zeigte hohe Stabilität über verschiedene Compiler-Optimierungen (-Os, -O2), GCC-Versionen, Temperaturen (21°C vs. 43°C), Spannungs-/Frequenz-Skalierung (DVFS) und Anwendungsszenarien (Keyword Spotting, Bilderkennung).
  • Die Vorhersagegenauigkeit blieb auch bei Wechseln der TFLM-Versionen (v2.4 vs. vCI) erhalten.

5. Bedeutung und Ausblick

InstMeter adressiert eine kritische Lücke im Bereich des Edge-Deep-Learning: Die Notwendigkeit schneller, genauer und datensparsamer Vorhersagemodelle für ressourcenbeschränkte Hardware.

• Praktische Relevanz: Durch die Reduzierung des Trainingsaufwands von Stunden/Tagen auf Minuten ermöglicht InstMeter eine effizientere Suche nach optimalen DL-Architekturen für MCUs.
• Reproduzierbarkeit: Die Autoren stellen den Quellcode, die Instruktionendictionaries und die umfangreichen Benchmark-Datensätze öffentlich zur Verfügung.
• Zukunftsaussichten: Während das System aktuell auf TFLM-basierten Software-Stacks beruht, bietet es eine solide Basis für die Erweiterung auf Hardware-Beschleuniger und die Berücksichtigung thermischer Effekte (Leckströme bei hohen Temperaturen), die in zukünftigen Arbeiten adressiert werden sollen.

Zusammenfassend beweist InstMeter, dass eine tiefgehende Analyse der Hardware-Instruktionen (Instruction-Level) effizientere und genauere Vorhersagen ermöglicht als oberflächliche Modellparameter-Analysen, und setzt damit einen neuen Standard für die Bewertung von DL-Modellen auf Mikrocontrollern.