« Tourne sur l'edge » a été étiré jusqu'à ne presque plus rien vouloir dire. Des fournisseurs l'affirment pour des modèles qui réclament un Raspberry Pi, un téléphone ou un repli cloud. Voici un test en cinq points auquel soumettre toute affirmation d'IA embarquée — y compris la nôtre — pour distinguer le marketing de l'ingénierie en une minute environ.
Les cinq questions
- Tient-il dans la RAM ? Pas « après diffusion depuis une carte SD » — le modèle plus ses activations et son cache tiennent-ils dans la SRAM de la puce ? C'est la RAM, pas le nombre de paramètres, la vraie limite.
- Tient-il dans le flash ? Les poids empaquetés plus le code du moteur, sous la taille de flash du composant.
- Est-il sans tas ? Un malloc à l'exécution sur un MCU signifie fragmentation et panne mémoire en pleine inférence. Tampons statiques, sinon cela ne compte pas.
- Est-il reproductible ? Pouvez-vous cloner un dépôt et régénérer les chiffres, ou ne vivent-ils que dans une présentation ?
- Est-il mesuré, pas estimé ? Des tailles de compilation réelles et des tests de parité, ou de l'à-peu-près et des chiffres ronds ?
Noter Atome face à sa propre checklist
L'équité, c'est s'appliquer le test à soi-même. Tient en RAM et en flash : mesuré par configuration dans le RAM_TABLE.md du dépôt, à partir d'une vraie compilation Cortex-M3. Sans tas : oui, tampons statiques fixes, environ 2,6 Ko de .text. Reproductible : clonez le dépôt, lancez les 146 tests et les scripts. Mesuré : parité bit-exacte Python-vers-C à 3,7×10⁻⁷. Quatre sur cinq, preuves à l'appui.
Celle qu'il échoue honnêtement
La cinquième case porte une réserve que nous ne masquerons pas : « mesuré sur silicium physique ». Les chiffres de déploiement d'Atome sont des mesures QEMU Cortex-M3, pas un banc avec un wattmètre sur une vraie carte. C'est la prochaine case à cocher, et nous ne la cocherons pas avant qu'elle soit vraie. Soumettez chaque fournisseur — nous compris — aux mêmes cinq questions, et traitez une réponse manquante comme un « non » jusqu'à preuve du contraire. Le but de la checklist n'est pas de couronner un gagnant ; c'est de redonner un sens à « tourne sur un microcontrôleur ».
Comment appliquer la checklist en pratique
La checklist est surtout utile comme un ensemble de questions à poser à un fournisseur ou à votre propre équipe, avec une règle simple : une réponse manquante ou évasive compte comme un non. Demandez le pic de RAM et le flash sur un composant nommé, pas un nombre de paramètres. Demandez si le moteur alloue à l'exécution, et si oui où se situe la borne. Demandez un dépôt que vous pouvez cloner et une commande qui reproduit le chiffre phare. Demandez si les chiffres de déploiement viennent d'une vraie compilation ou d'une estimation. Chaque question a une réponse concrète et vérifiable, et l'absence de l'une est elle-même une information. Le but n'est pas d'embarrasser qui que ce soit ; c'est de convertir une affirmation marketing vague en un petit nombre de faits vérifiables.
Pourquoi nous nous y soumettons aussi
Il serait facile d'écrire une checklist qui nous attribue commodément cinq sur cinq. Nous ne l'avons pas fait, parce que l'objet de l'exercice est la confiance, et la confiance vient de l'aveu de la case que l'on n'a pas cochée. Atome valide la tenue en RAM, la tenue en flash, l'absence de tas, la reproductibilité et la mesure — quatre sur cinq, preuves à l'appui dans le dépôt — et échoue ouvertement à la cinquième, la mesure sur silicium physique, parce que les chiffres sont QEMU Cortex-M3 et que nous ne présenterons pas de l'émulation comme du silicium. Publier l'écart est tout l'intérêt : une checklist que l'on réussit toujours est un outil marketing, tandis qu'une checklist qui peut vous recaler est un outil. Appliquez-la-nous, et appliquez-la à tous les autres.
Signaux d'alerte qui doivent vous rendre sceptique
Quelques schémas signalent de manière fiable qu'une affirmation d'edge-AI ne survivra pas au contact d'un vrai microcontrôleur. Méfiez-vous des nombres de paramètres cités sans chiffre de mémoire, car des paramètres sans octets masquent la contrainte qui compte vraiment. Méfiez-vous des démonstrations qui se révèlent tourner sur un Raspberry Pi ou un téléphone tout en étant décrites comme « sur l'edge », car un ordinateur Linux avec des gigaoctets est une autre catégorie de machine. Traitez les chiffres « estimés » ou suspectement ronds avec prudence, surtout quand aucun dépôt ni sortie de compilation ne les étaye. Et soyez sceptique face à toute revendication de performance sur silicium qui ne peut pointer une mesure sur un composant nommé. Aucun de ces signaux ne prouve la mauvaise foi — parfois ce n'est qu'un langage relâché — mais chacun invite à poser la question précise et vérifiable qui se cache dessous avant de bâtir une feuille de route sur la réponse.
En résumé
Considérez « tourne sur un microcontrôleur » comme une affirmation à tester, pas une formule à croire. Posez les cinq questions — tient en RAM, tient en flash, sans tas, reproductible, mesuré — exigez un composant nommé et un dépôt clonable, et lisez toute réponse manquante comme un non. Appliquée honnêtement, la checklist place Atome à quatre sur cinq, avec la case de mesure sur silicium ouvertement non cochée. C'est la norme à laquelle tout le domaine devrait être soumis, nous compris, car un test que l'on peut échouer est le seul qui vaille la peine d'être passé.
Questions fréquentes
Comment savoir si un LLM tourne vraiment sur un microcontrôleur ?
Vérifiez cinq points : il tient dans la SRAM de la puce, il tient dans le flash, il est sans tas, les chiffres sont reproductibles depuis un dépôt, et ils sont mesurés plutôt qu'estimés. Une réponse manquante doit se lire comme un non.
Atome lm passe-t-il sa propre checklist edge-AI ?
Sur quatre points sur cinq, oui — tient en RAM, tient en flash, sans tas, reproductible et mesuré. Le cinquième, la mesure sur silicium physique, n'est pas encore fait : les chiffres sont QEMU Cortex-M3, et nous le disons.