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

Ce papier présente InstMeter, une méthode au niveau des instructions exploitant les cycles d'horloge des microcontrôleurs pour prédire avec une grande précision et une faible dépendance aux données les coûts énergétiques et de latence des modèles d'apprentissage profond, surpassant ainsi les approches existantes et optimisant la recherche d'architectures neuronales.

L'essentiel

🌟 Le Problème : Deviner la consommation d'une "boîte noire"

Imaginez que vous êtes un architecte qui doit construire des maisons (des modèles d'intelligence artificielle) pour des micro-contrôleurs. Ce sont de minuscules ordinateurs, comme ceux qui se cachent dans vos montres connectées, vos écouteurs ou vos thermostats intelligents.

Ces petits appareils ont deux règles strictes :

1. La batterie est minuscule (comme une pièce de monnaie).
2. Ils doivent réagir instantanément (pas de temps d'attente pour ouvrir une porte).

Le problème, c'est que pour concevoir la meilleure maison possible, les ingénieurs doivent tester des milliers de modèles. Mais comment savoir combien d'énergie un modèle va consommer ou combien de temps il va prendre pour réfléchir, sans avoir à le construire et à le tester physiquement à chaque fois ?

Jusqu'à présent, les experts utilisaient des méthodes approximatives, un peu comme essayer de deviner le poids d'un camion en comptant le nombre de roues. C'est rapide, mais souvent faux, car cela ignore la route, le trafic ou le type de moteur.

💡 La Solution : InstMeter, le "Compteur de Pas"

Les chercheurs de l'Université de Delft ont créé InstMeter. Voici comment ça marche, avec une analogie simple :

1. Au lieu de compter les "roues", on compte les "pas"

Les anciennes méthodes regardaient la taille du modèle (le nombre de paramètres). C'est comme si on essayait de prédire la fatigue d'un coureur en regardant la longueur de ses chaussures. Ce n'est pas très précis.

InstMeter, lui, regarde ce qui se passe réellement à l'intérieur du micro-contrôleur. Il compte le nombre de cycles d'horloge (les "battements de cœur" du processeur).

• L'analogie : Imaginez que chaque instruction que le micro-contrôleur exécute est un pas que le coureur fait.
• Chaque pas prend exactement le même temps et coûte exactement la même énergie, peu importe la longueur du coureur ou la couleur de ses chaussures.
• Si vous connaissez le nombre de pas, vous connaissez exactement la distance parcourue (la latence) et l'énergie dépensée.

2. Le secret : La "Carte au Trésor" (Mapping)

Pour savoir combien de pas un modèle va faire, il faut lire le code. Mais le code est écrit en deux langues :

• Le code source (ce que les humains écrivent, comme une recette de cuisine).
• Le code assembleur (ce que la machine lit, comme une liste de mouvements précis pour un robot).

Le défi était de relier la recette aux mouvements du robot. Les chercheurs ont créé un algorithme intelligent qui agit comme un traducteur ultra-rapide. Il regarde la recette, identifie les boucles (les étapes qui se répètent), et les relie directement aux mouvements du robot dans le code machine.

Grâce à cette "carte", ils peuvent dire : "Ah, ce modèle va faire 5000 pas de plus que l'autre."

🚀 Pourquoi c'est une révolution ?

1. Une précision incroyable avec très peu d'effort

Les anciennes méthodes avaient besoin de tester des milliers de modèles pour apprendre à faire des prédictions (comme un élève qui doit lire 1000 livres pour comprendre un sujet).
InstMeter, grâce à sa logique linéaire (1 pas = 1 unité d'énergie), n'a besoin que de 5 à 10 exemples pour être précis. C'est comme si un élève pouvait prédire le résultat d'un examen après avoir lu seulement 5 pages, car il a compris la logique fondamentale.

• Résultat : Ils ont réduit l'erreur de prédiction d'énergie par 3 fois et celle de la vitesse par 6,5 fois par rapport aux meilleurs outils actuels.

2. Une économie de temps et d'argent

Tester un modèle sur un vrai micro-contrôleur prend du temps (il faut compiler, uploader, mesurer).

• Avant : Pour entraîner un prédicteur, il fallait des jours de collecte de données.
• Avec InstMeter : On peut construire un prédicteur en 30 minutes avec quelques données.

3. Robuste partout

Le papier montre que cette méthode fonctionne aussi bien sur :

• Différents types de puces (ARM, RISC-V).
• Différentes températures (du froid au chaud).
• Différents logiciels de compilation.
  C'est comme si votre compteur de pas fonctionnait aussi bien sur du bitume, du sable ou de la neige, sans avoir besoin de changer de chaussures.

🎯 L'Impact : Trouver la "Perle Rare"

Dans le domaine de la Recherche d'Architecture Neurale (NAS), on cherche automatiquement le meilleur modèle possible.

• Avec les anciennes méthodes, l'algorithme choisissait souvent des modèles qui semblaient bons sur le papier, mais qui épuisaient la batterie en réalité.
• Avec InstMeter, l'algorithme trouve des modèles qui respectent parfaitement la limite de batterie tout en étant aussi intelligents que possible. C'est comme trouver la voiture la plus économe en carburant qui est aussi la plus rapide, sans avoir à faire des milliers de tests sur piste.

En résumé

InstMeter est un outil qui change la façon dont on conçoit l'intelligence artificielle pour les petits appareils. Au lieu de deviner avec des approximations, il compte les "pas" réels que l'ordinateur va faire. C'est plus simple, plus rapide, et surtout, beaucoup plus précis, permettant de créer des appareils intelligents qui durent plus longtemps et réagissent plus vite.

Résumé technique

1. Problématique

Le déploiement de modèles d'apprentissage profond (Deep Learning - DL) sur des microcontrôleurs (MCU) est en pleine expansion, permettant le développement de dispositifs intelligents et compacts. Cependant, la conception de ces modèles nécessite un équilibre précis entre précision, latence et consommation d'énergie, contraintes critiques pour les appareils embarqués (batteries limitées, temps réel).

Pour faciliter cette conception, la communauté utilise la Recherche d'Architecture Neurale (NAS), qui explore des milliers d'architectures. Le goulot d'étranglement majeur réside dans l'évaluation rapide et précise de la latence et de l'énergie de chaque modèle candidat.

• Limites des méthodes actuelles (SOTA) : Les prédicteurs existants reposent sur des proxies de haut niveau, tels que le nombre d'opérations MAC (Multiply-Accumulate) ou les paramètres du modèle.
• Le problème de la non-linéarité : Ces paramètres ont une relation non-linéaire avec la consommation réelle d'énergie et la latence sur les MCU. Cette non-linéarité est causée par les optimisations du compilateur (élimination de code mort, réordonnancement d'instructions, sélection de fonctions noyau spécifiques) qui transforment le code source en instructions machine (désassemblage).
• Conséquence : Pour capturer ces relations complexes, les méthodes actuelles nécessitent des milliers d'échantillons d'entraînement (souvent 1000 à 5000), ce qui est coûteux en temps et en ressources, surtout pour les plateformes MCU où la collecte de données est lente.

2. Méthodologie : InstMeter

Les auteurs proposent InstMeter, un prédicteur au niveau des instructions qui exploite la linéarité fondamentale entre les cycles d'horloge du MCU et les métriques de performance (énergie et latence).

Principe Fondamental

Contrairement aux méthodes basées sur les MAC, InstMeter modélise le coût d'exécution en fonction du nombre total de cycles d'horloge exécutés.

• Relation Linéaire : L'énergie ($E$) et la latence ($L$) suivent une équation linéaire simple :
  $$E \text{ (ou } L) = a \cdot \text{Cycles} + b$$
  Où $a$ est le coût par cycle (Joules/cycle ou secondes/cycle) et $b$ est une surcharge fixe par inférence.
• Avantage : Grâce à cette linéarité, InstMeter ne nécessite que quelques échantillons d'entraînement (moins de 10) pour être précis, contre des milliers pour les méthodes SOTA.

Défi Technique : Le Mappage Source-Désassemblage

Pour calculer le nombre de cycles sans exécuter le modèle sur le matériel à chaque fois, InstMeter doit mapper le code source (C++) du framework TFLM (TensorFlow Lite for Microcontrollers) vers le code désassemblé (instructions assembleur).

• Observation clé : Les paramètres du modèle (taille du filtre, batch size) modifient principalement les variables de boucle dans le code source, tandis que la structure des instructions désassemblées reste identique.
• Solution proposée : Un algorithme de mappage structurel et sémantique :
  1. Mappage Structurel : Génération de Graphes de Flux de Contrôle (CFG) pour le code source et le désassemblage. Les relations entre les boucles (inclusion $\subset$, intersection $\cap$) sont utilisées pour établir des correspondances grossières.
  2. Mappage Sémantique : Pour résoudre les ambiguïtés, l'algorithme utilise des caractéristiques sémantiques, notamment les opérateurs de comparaison (ex: <, >, ==) qui sont omniprésents dans les boucles et conservent une cohérence entre le source et le binaire, contrairement aux noms de variables qui sont souvent obscurcis par le compilateur.
  3. Algorithme : Utilisation de l'algorithme VF2 pour le matching de graphes, suivi d'une optimisation par scalarisation aléatoire des poids des caractéristiques sémantiques pour sélectionner le meilleur mappage.

Processus de Prédiction

1. Profilage (une seule fois par architecture) : Mappage des fonctions noyau TFLM pour créer une bibliothèque d'instructions associant chaque type d'instruction à son nombre d'exécutions et son coût en cycles (CPI).
2. Estimation : Pour un nouveau modèle, on calcule le nombre total de cycles en sommant les cycles de chaque opérateur (basé sur les paramètres du modèle et la bibliothèque).
3. Calibration : Avec seulement 5 à 10 modèles réels mesurés, on détermine les coefficients $a$ et $b$ de l'équation linéaire pour prédire l'énergie et la latence.

3. Contributions Clés

1. Transformation Paradigmatique : Passage d'une estimation non-linéaire (basée sur les paramètres du modèle) à une estimation linéaire (basée sur les cycles d'horloge), réduisant drastiquement le besoin de données d'entraînement.
2. Algorithme de Mappage Innovant : Développement d'une méthode de mappage source-désassemblage fine (au niveau des boucles) combinant des features structurelles (CFG) et sémantiques (opérateurs de comparaison), permettant une précision élevée sans nécessiter de milliers d'échantillons.
3. Nouveau Dataset de Référence : Création d'un dataset complet de 2125 modèles avec mesures de vérité terrain (énergie/latence) couvrant :
   • 4 MCU (ARM Cortex-M4, M7, M33 et RISC-V ESP32-C3).
   • Différentes versions de compilateurs (GCC v7.3, v10.3), options d'optimisation (-Os, -O2), versions TFLM, températures (21°C, 43°C) et scénarios d'application (KWS, Image).
4. Performances Supérieures : Démonstration que InstMeter surpasse les méthodes de l'état de l'art avec une fraction des données d'entraînement.

4. Résultats Expérimentaux

Les évaluations ont été menées sur les architectures ARM et RISC-V mentionnées ci-dessus.

• Précision vs Données d'Entraînement :
  • InstMeter : Avec seulement 5 échantillons, il atteint une erreur relative médiane inférieure à 30% pour 90% des modèles.
  • Méthodes MAC (SOTA) : Nécessitent ~50 échantillons pour une erreur de ~200% (soit 6.5x pire avec 10x plus de données).
  • nn-Meter (SOTA) : Nécessite ~500 échantillons pour une erreur de ~100% (soit 3x pire avec 100x plus de données).
• Scénarios NAS : Dans une recherche d'architecture, InstMeter permet d'exploiter pleinement le budget énergétique, identifiant des modèles optimaux avec une précision d'inférence supérieure et des erreurs de prédiction inférieures à 10%, là où les autres prédicteurs échouent à respecter les contraintes.
• Généralisation et Robustesse :
  • Cross-Architecture : Fonctionne bien sur M4, M7, M33 et ESP32-C3.
  • Conditions Variables : Reste robuste face aux changements de température (21°C vs 43°C), de DVFS (Dynamic Voltage and Frequency Scaling), de versions TFLM et de versions GCC.
  • Optimisations : Même avec des optimisations agressives (-O2), l'erreur reste contenue, bien que légèrement supérieure à -Os ou -O0.

5. Signification et Impact

• Efficacité de la NAS : InstMeter rend la recherche d'architecture sur MCU beaucoup plus rapide et fiable, car elle ne nécessite pas de collecter des milliers de points de données coûteux pour chaque nouvelle plateforme ou configuration.
• Transparence et Reproductibilité : En s'appuyant sur des cycles d'horloge (une métrique fondamentale du matériel) plutôt que sur des "boîtes noires" non-linéaires, le modèle est plus interprétable.
• Ressources Ouvertes : Les auteurs publient leurs codes sources, leurs bibliothèques d'instructions pour plusieurs MCU, et l'ensemble des données de benchmark, comblant ainsi un vide important dans la recherche sur les DL embarqués.

En résumé, InstMeter résout le problème de la prédiction coûteuse et imprécise de l'énergie et de la latence sur les microcontrôleurs en exploitant la linéarité intrinsèque des cycles d'horloge, permettant une conception de modèles DL plus efficace et accessible.