Un LLM de 28,9 millions de paramètres tourne sur une puce à 8 dollars

Sur GitHub, un projet baptisé esp32-ai cumule déjà 775 étoiles pour une raison simple : son auteur, le développeur slvDev, a réussi à faire tourner un modèle de langage de 28,9 millions de paramètres sur un ESP32-S3, un microcontrôleur qui coûte environ 8 dollars. Aucune connexion réseau, aucun serveur : le texte s'affiche directement sur un petit écran branché à la puce, à raison d'environ 9,5 tokens par seconde.

Pour qui découvre le sujet : un microcontrôleur n'est pas un mini-ordinateur. C'est une puce pensée pour piloter un capteur, un moteur ou un écran, avec très peu de mémoire vive. Faire tenir un modèle de langage dedans, même minuscule, relevait jusqu'ici de la prouesse de laboratoire plus que du cas d'usage exploitable. Le précédent record connu sur ce type de puce plafonnait à 260 000 paramètres. Ce projet en embarque environ 100 fois plus, sur un matériel comparable.

Le mur de la RAM, et pourquoi il bloquait tout le monde

L'ESP32-S3 dispose de 512 Ko de SRAM (la mémoire rapide), de 8 Mo de PSRAM et de 16 Mo de flash. Historiquement, un modèle de langage devait tenir presque intégralement dans la mémoire rapide pour être exploitable, ce qui condamnait les puces de ce calibre à des modèles ridiculement petits.

La bascule vient d'un constat simple : dans un LLM, l'essentiel des paramètres ne sert pas à calculer, mais à stocker une table de correspondance, la table d'embeddings, qui associe chaque token à un vecteur. Cette table n'a pas besoin d'être en mémoire rapide en permanence. Il suffit d'aller y lire, à la demande, la poignée de lignes dont on a besoin pour le token en cours.

Per-Layer Embeddings : l'idée empruntée à Gemma

C'est exactement le principe des Per-Layer Embeddings (PLE), une technique introduite par Google dans ses modèles Gemma 3n et Gemma 4. Sur esp32-ai, la table d'embeddings représente 25 des 28,9 millions de paramètres du modèle. Elle est stockée en flash, la mémoire la plus lente et la plus abondante de la puce, et le firmware n'en lit que quelques lignes par token, environ 450 octets à chaque fois. Seule la petite partie du modèle qui fait le calcul proprement dit reste en mémoire rapide.

Résultat : la SRAM héberge le cœur qui raisonne à chaque token, la PSRAM sert de mémoire de travail et de tête de sortie, et la flash porte l'essentiel du poids du modèle sans jamais le charger en bloc. Le modèle complet pèse 14,9 Mo une fois quantifié en 4 bits, un volume que la flash de 16 Mo absorbe sans difficulté.

Ce que ça donne concrètement

• 28,9 millions de paramètres, dont 25 millions dans la table de flash.
• 9,5 tokens par seconde de bout en bout (9,7 tokens/seconde de calcul pur, hors accès mémoire).
• 14,9 Mo de poids modèle en quantification 4 bits.
• Une puce à environ 8 dollars, avec 512 Ko de SRAM, 8 Mo de PSRAM et 16 Mo de flash.
• Zéro connectivité réseau : tout tourne en local, sur la puce.

Ce que le modèle sait faire, et ce qu'il ne sait pas faire

Important de le préciser, pour ne pas survendre le projet : ce modèle a été entraîné sur TinyStories, un jeu de données de courtes histoires synthétiques conçu par des chercheurs de Microsoft Research pour qu'un petit modèle apprenne quand même à écrire des phrases cohérentes. Le résultat écrit donc de courtes histoires simples, globalement cohérentes. Il ne répond pas à des questions, ne suit pas d'instructions, n'écrit pas de code et ne connaît aucun fait. La technique Per-Layer Embeddings résout un problème de mémoire, pas un problème de capacité de raisonnement : c'est la petite partie qui calcule qui plafonne, pas celle qui stocke.

L'intérêt du projet est donc dans l'architecture, pas dans ce que le modèle peut dire. C'est une démonstration que le compromis mémoire/capacité change de nature dès qu'on accepte de sortir la donnée statique de la RAM.

Reproduire l'expérience

Le dépôt slvDev/esp32-ai est entièrement ouvert. Le firmware et le câblage sont documentés dans firmware/esp32_llm/README.md, le code d'entraînement et de quantification dans src/ et experiments/, et la méthode complète avec les mesures sur puce dans RESULTS.md. L'auteur a volontairement laissé l'historique de commits visible, bug de comptage de paramètres compris, avec la correction qui a suivi : une transparence assez rare qui vaut le détour pour quiconque veut comprendre où les chiffres annoncés peuvent dériver.

Le projet s'inscrit dans la lignée de llama2.c d'Andrej Karpathy, qui a popularisé l'idée qu'on peut entraîner un petit modèle de langage et le faire tourner en C pur, sans framework lourd.

Notre lecture chez CZSyn

Ce projet ne va pas remplacer un chatbot d'entreprise, et ce n'est pas son propos. Ce qui nous intéresse, côté agence, c'est le signal qu'il envoie sur l'IA embarquée à bas coût. Beaucoup de PME françaises pensent l'IA générative uniquement comme un appel API vers un fournisseur cloud, avec la latence, la facture et la dépendance réseau que cela implique. La technique démontrée ici, séparer ce qui doit rester en mémoire rapide de ce qui peut dormir en stockage lent, s'applique bien au-delà d'un ESP32 : c'est la même logique qui permet de faire tourner des modèles plus capables sur des serveurs contraints en RAM, ou sur des objets connectés qui doivent fonctionner sans connexion internet fiable, capteur industriel isolé, terminal de point de vente en zone blanche, dispositif embarqué sur un site sans réseau.

Pour un objet connecté qui doit générer un texte simple (une alerte formatée, une confirmation, un message de diagnostic) sans dépendre d'un serveur distant, ce type d'architecture ouvre une piste réelle, même si le modèle reste aujourd'hui limité à des tâches très bornées. La vraie question pour une entreprise n'est jamais « peut-on faire tourner un LLM localement », mais « quelle tâche précise a-t-on besoin d'automatiser, et avec quelle marge d'erreur acceptable ». Sur ce point, un modèle de quelques dizaines de millions de paramètres entraîné sur un usage étroit peut largement suffire, pour une fraction du coût d'un appel API à un modèle généraliste.

Sources primaires

• Dépôt GitHub officiel, slvDev/esp32-ai.
• Ronen Eldan et Yuanzhi Li (Microsoft Research), « TinyStories », arXiv:2305.07759.
• Andrej Karpathy, llama2.c.