Cette page est la comparaison complète entre Atome LM EDGE et TensorFlow Lite for Microcontrollers sur le banc que nous avons mesuré le plus soigneusement : UCI HAR, reconnaissance d'activité humaine, 2 947 fenêtres de test issues de 30 sujets, le même réseau convolutif temporel de 6 567 paramètres compilé par les deux moteurs.
Elle contient l'axe sur lequel nous perdons et ceux que personne n'a mesurés. Ce n'est pas de la modestie : un banc qui ne se lit que dans un sens n'est pas un banc, et un ingénieur embarqué qui choisit un runtime a besoin de la forme du compromis, pas d'un titre.
Qui est qui
- Nous : le moteur C99 Atome LM EDGE — un réseau convolutif temporel int8 à forme fixe, sans interpréteur, sans tas, sans zone de travail.
- L'adversaire : TensorFlow Lite for Microcontrollers (TensorFlow 2.21.0), le runtime Google standard pour microcontrôleurs, sur la même architecture.
- L'adversaire, au niveau noyau : CMSIS-NN v4.1.0 — la bibliothèque optimisée d'ARM, et le code que X-CUBE-AI génère en dessous. Là où un nombre de cycles est comparé, CMSIS-NN est le chiffre de l'adversaire, pas le nôtre.
1 · Précision — une égalité, et c'en est vraiment une
La découpe est par sujet : les 30 personnes du jeu de test n'apparaissent jamais à l'entraînement, la seule découpe qui ait un sens pour un objet porté. La sélection de modèle se fait sur une validation extraite des sujets d'entraînement. Le jeu de test est noté une seule fois. Cinq graines par bras.
| Graine | Atome LM EDGE | TensorFlow Lite for Microcontrollers (budget égal) |
|---|---|---|
| 0 | 0,8992 | 0,9067 |
| 1 | 0,9182 | 0,9074 |
| 2 | 0,9053 | 0,9362 |
| 3 | 0,9091 | 0,8975 |
| 4 | 0,9155 | 0,9006 |
| moyenne ± é.t. | 0,9095 ± 0,0077 | 0,9097 ± 0,0154 |
Différence appariée : -0,000204, contre un 2·SE apparié de 0,017222. L'écart est environ quatre-vingts fois plus petit que le bruit. Notre bras devance sur 3 graines sur 5 — ce que fait une pièce de monnaie.
C'est une égalité et nous l'appelons une égalité. Une version antérieure de cette comparaison annonçait un gain à partir d'une seule graine. C'était faux : la moyenne sur 5 graines ne le soutient pas.
2 · Flash et RAM — un gain, 4,64×
| Octets | Atome LM EDGE | TensorFlow Lite for Microcontrollers | Rapport |
|---|---|---|---|
| Poids du modèle | 7 044 | 32 800 | 4,66× |
| Moteur en flash | 8 400 | 38 912 | 4,63× |
| Flash total | 15 444 | 71 712 | 4,64× |
| RAM d'exécution | 3 072 | 6 656 | 2,17× |
L'écart est structurel. TensorFlow Lite for Microcontrollers embarque un interpréteur : il lit un FlatBuffer au démarrage, parcourt une table d'opérateurs et dispatche, ce qui exige une zone de tenseurs. Notre moteur n'a pas d'interpréteur à porter, parce que la forme du réseau est compilée. C'est un coût réel de leur côté et une contrainte réelle du nôtre : changer de modèle impose de recompiler le firmware, là où eux remplacent un fichier.
La variante ternaire descend plus bas : 4 765 octets de poids contre le FlatBuffer de 18 840 octets du même run — 3,95× — vérifiée de bout en bout, le vrai moteur C étant d'accord avec la référence sur 2947/2947 fenêtres. Sa précision est 0,9053 sur une graine : c'est un artefact déployable, pas un résultat.
3 · Coût par décision sur fenêtre glissante — un gain, 27,3×
Un runtime sans état expose une convolution par tenseur, sans moyen de conserver l'historique entre deux appels. Demandez-lui une décision : il recalcule toute la fenêtre. Redemandez un échantillon plus tard : il recalcule toute la fenêtre, y compris les 127 échantillons qui n'ont pas bougé.
Notre moteur garde des anneaux d'activation par couche et calcule un seul nouveau pas de temps par couche et par échantillon. L'API adverse ne sait pas exprimer cela. Ce n'est pas une course de vitesse, c'est une capacité que l'interface n'a pas.
| Cortex-M4 @ 80 MHz | Cycles | ms |
|---|---|---|
| Fenêtre complète — ce qu'un runtime sans état doit faire | 7 453 884 | 93,2 |
| Convolution CMSIS-NN par fenêtre | 2 556 548 | 32,0 |
| Nous, en flux, par décision | 93 598 | 1,17 |
La limite, énoncée avec le résultat. Cela ne vaut que pour des fenêtres qui se recouvrent. Le flux gagne quand une décision est nécessaire plus souvent que tous les 27 échantillons face à CMSIS-NN. Au pas de 128 — fenêtres disjointes — le flux coûte 1,6× plus cher, et il réclame environ 10 Kio de RAM d'état (24 732 o de bss contre 6 192 o).
4 · Latence par fenêtre — une perte, 2,89×
| Cortex-M4, une fenêtre | Cycles | Cycles / MAC | ms @ 80 MHz |
|---|---|---|---|
| Atome LM EDGE, convolution seule | 7 390 036 | 9,13 | 92,4 |
CMSIS-NN arm_convolve_s8 | 2 556 548 | 3,13 | 32,0 |
| Rapport | nous 2,89× plus lents | ||
CMSIS-NN y parvient en restructurant toute la convolution — im2col vers un grand GEMM — au prix d'une zone de travail de 16 Kio (24 048 o de bss contre 6 192 o chez nous). Nous avons essayé trois variantes SIMD de notre boucle interne : les trois étaient plus lentes que le code scalaire, le surcoût d'appel par canal de sortie dépassant les sept multiplications-accumulations qu'il effectue.
5 · Ce que nous n'avons pas mesuré
| Non mesuré | Pourquoi c'est important |
|---|---|
| Latence et énergie sur silicium | Tous les cycles Cortex-M de cette page viennent d'une émulation Unicorn 2.1.4 sur la table DDI 0403E. 61 % des instructions exécutées n'y figurent pas et comptent pour un cycle : les absolus sont des bornes inférieures, les rapports sont la partie fiable. |
| X-CUBE-AI lui-même | L'outil stm32ai n'a jamais été exécuté ici — il exige un compte ST que nous n'avons pas. Ce qui est mesuré, c'est CMSIS-NN v4.1.0, la bibliothèque que X-CUBE-AI génère en dessous. |
| Cortex-M33 | La compilation ARMv8-M faute sous le modèle ARM d'Unicorn et n'atteint jamais son écriture semihosting sous QEMU mps2-an505. Aucun chiffre M33 n'existe. |
| Un deuxième jeu de données | Toutes les précisions de cette page sont UCI HAR. Un banc est un banc. |
Lequel choisir
- TensorFlow Lite for Microcontrollers si vous devez changer de modèle sans recompiler le firmware, si votre composant a de la place, ou si votre inférence est ponctuelle et critique en latence.
- Atome LM EDGE si la flash est la contrainte qui mord, si vous classez une fenêtre de capteur qui glisse en continu, ou s'il vous faut prouver que ce qui tournait sur le bureau est bit à bit ce qui tourne sur l'appareil.
- La précision ne tranche pas sur cette tâche : les deux sont dans le bruit l'un de l'autre.
Questions
Atome LM est-il plus précis que TensorFlow Lite for Microcontrollers ?
Non. Sur UCI HAR, avec une découpe par sujet sans fuite et 5 graines, c'est une égalité : 0,9095 ± 0,0077 pour Atome LM EDGE contre 0,9097 ± 0,0154 pour TFLite Micro.
De combien Atome LM EDGE est-il plus petit que TFLite Micro ?
4,64× sur la flash totale pour le même réseau de 6 567 paramètres : 15 444 octets contre 71 712. La RAM d'exécution est 2,17× plus petite.
Atome LM est-il plus rapide que TFLite Micro ?
Cela dépend entièrement du glissement de la fenêtre. Par décision sur fenêtre glissante, 27,3× moins cher que CMSIS-NN. Par fenêtre ponctuelle, 2,89× plus lent.
Ces chiffres sont-ils mesurés sur silicium réel ?
Non. Les cycles viennent d'une émulation Unicorn 2.1.4 : les absolus sont des bornes inférieures, les rapports sont fiables car les deux bras passent par le même banc. Les précisions, elles, ne sont pas émulées : elles viennent du vrai moteur C99 sur les 2 947 fenêtres de test.