Comparatif

Le meilleur petit LLM pour un microcontrôleur à 2 $

2026-06-03 · Tilelli Lab · 6 min de lecture

« Petit modèle » est une expression glissante, et la plupart des comparatifs esquivent la seule question qui compte pour l'embarqué : tient-il réellement dans la mémoire de la puce ? Cet article met quatre options connues côte à côte face à de vrais budgets de microcontrôleurs. Les chiffres d'Atome proviennent de sa table mesurée publique ; les autres sont issus du dimensionnement propre à chaque projet et du matériel pour lequel ils ont été conçus.

Les concurrents

PileEmpreinte minimale réalisteMatériel cibleTient sur un MCU à 2 $ ?
TinyLlama 1.1B (4-bit)~550 MBGPU / phone
llama2.c (Stories260K, FP32)~1 MB+Pi / desktop✗ on MCU SRAM
TinyMaix / TFLite-Microtens–hundreds KBMCU (vision/keyword)✓ — but not LLMs
Atome lm~42 KB flash / ~14 KB RAMMCU (byte LM)

Lire le tableau honnêtement

TinyMaix est de l'excellente ingénierie — mais il exécute des réseaux convolutifs et des détecteurs de mots-clés, pas des modèles de langue autorégressifs. Si votre tâche est la détection de mot de réveil ou la classification d'images, c'est le bon outil et Atome ne l'est pas. llama2.c est un magnifique transformeur en un seul fichier, mais les points de contrôle réellement exécutés réclament un mégaoctet ou plus de mémoire de travail, ce qui implique un Raspberry Pi plutôt qu'un STM32. TinyLlama est, malgré son nom, un modèle de classe GPU : superbe sur un téléphone, impossible sur un Cortex-M.

Atome lm est le cas particulier qui comble la lacune laissée par les autres : un véritable modèle de langue au niveau de l'octet dont les poids ternaires se compriment en quelques dizaines de kilooctets de flash et dont le moteur sans tas tient dans la SRAM d'un composant à quelques centimes. Il n'est pas meilleur que TinyLlama en langue ; c'est le seul des quatre à seulement tourner sur la puce.

Là où Atome n'est pas la réponse

Deux disqualifications honnêtes. Si vous avez un Raspberry Pi, un NPU ou un téléphone, vous disposez de mégaoctets à gigaoctets — prenez un modèle plus grand et gagnez en qualité ; la niche d'Atome est précisément là où ceux-ci n'arrivent pas. Et à l'échelle, Atome perd : porté à environ 944K paramètres, un transformeur FP32 classique le bat d'environ 11 % en perplexité. Le pari d'Atome est délibérément le régime sous le million de paramètres, classe microcontrôleur, et non la qualité en domaine ouvert.

Comment choisir

La bonne comparaison n'est jamais « quel petit modèle est le meilleur » dans l'abstrait — c'est « lequel tient sur ma puce et ma tâche ». Pour un microcontrôleur à 2 $ exécutant une tâche de langue étroite sans réseau, Atome est actuellement le seul des quatre à seulement se charger.

Pourquoi le nombre de paramètres est une spec trompeuse

Les tableaux comparatifs adorent les nombres de paramètres parce que c'est un chiffre unique, mais pour l'embarqué ils masquent ce qui décide de la faisabilité. Deux modèles au même nombre de paramètres peuvent avoir des empreintes mémoire radicalement différentes selon la précision des poids, la taille du tokeniseur, la longueur de séquence et la stratégie de cache. Un modèle FP32 d'1M de paramètres, ce sont 4 Mo de poids ; un modèle ternaire d'1M de paramètres, quelques centaines de kilooctets. Le vocabulaire compte aussi : un modèle avec un vocabulaire BPE de 32 000 tokens embarque une grande table d'embedding, alors que le tokeniseur d'octets d'Atome n'a que 256 entrées et aucun fichier de vocabulaire séparé. Quand vous comparez des petits LLM, comparez les octets en RAM et en flash, pas les paramètres.

Le rôle de chaque outil

Vus ainsi, les quatre ne sont pas vraiment concurrents ; ils occupent des barreaux différents de la même échelle. L'erreur que ce comparatif veut corriger est de traiter un modèle de classe téléphone comme s'il était embarqué. Une fois chacun placé sur le barreau qui lui revient, le choix est facile : partez de la mémoire de votre matériel et de l'étendue de votre tâche, et le bon outil est généralement évident.

Coût total de possession, pas seulement la taille du modèle

Quand vous comparez ces piles pour un vrai produit, la taille du modèle n'est qu'une ligne d'un budget plus long. Une approche adossée au cloud ajoute des frais d'inférence récurrents, une exigence de connectivité, et une charge de confidentialité et de conformité qui croît avec la sensibilité des données. Un ordinateur embarqué de classe Raspberry Pi ajoute un coût unitaire, une consommation, un temps de démarrage et un système d'exploitation complet à maintenir et sécuriser. Un microcontrôleur nu exécutant Atome n'ajoute pratiquement rien de tout cela : le modèle fait partie du firmware que vous livriez déjà, il n'y a aucun coût par inférence, aucune dépendance réseau, et aucun système d'exploitation à corriger. Pour un appareil à fort volume, ces économies récurrentes et par unité éclipsent souvent toute différence de qualité brute du modèle, et c'est pourquoi la bonne comparaison pèse le système entier, pas seulement le benchmark.

En résumé

Pour un microcontrôleur à 2 $ exécutant une tâche de langue étroite sans réseau, Atome est actuellement le seul des quatre à seulement se charger — non parce qu'il est le modèle le plus intelligent, mais parce qu'il est conçu pour ce budget mémoire. TinyLlama a sa place sur les téléphones, llama2.c sur un Raspberry Pi, et TinyMaix sur la vision et les mots-clés. Notez les candidats en octets de RAM et de flash plutôt qu'en nombre de paramètres, pesez le coût du système entier plutôt que le seul benchmark, et le choix pour un MCU nu se fait généralement de lui-même.

Questions fréquentes

Quel est le meilleur LLM à faire tourner sur un ESP32 ou un STM32 ?

Pour un véritable modèle de langue qui tient dans la mémoire d'un MCU, Atome lm est conçu pour cela ; pour la vision ou les mots-clés, utilisez TinyMaix. Les grands modèles comme TinyLlama ne tiennent pas dans la SRAM d'un microcontrôleur.

TinyLlama est-il assez petit pour un microcontrôleur ?

Non. TinyLlama compte 1,1 milliard de paramètres — environ 550 Mo même en 4 bits — soit des milliers de fois la SRAM de n'importe quel microcontrôleur. Il vise les téléphones et les GPU.

← Tous les articles Code & données sur GitHub