Un modèle de langue qui tient dans le flash n'est pas un chatbot, et prétendre le contraire est la manière dont les projets d'IA embarquée perdent leur crédibilité. C'est un petit moteur de texte, privé et hors ligne. Utilisé pour les bonnes tâches, il est réellement utile ; utilisé comme un GPT de poche, il déçoit. Voici le partage honnête, avec les prototypes fonctionnels tirés du journal d'expériences du projet.
Cinq choses qu'il sait faire
- Classification de commandes et d'intentions. Un petit classifieur d'octets sur le squelette Atome a atteint 100 % de précision en test sur un jeu de commandes à six classes (données synthétiques) — utile pour le routage de commandes vocales ou textuelles hors ligne sur un appareil.
- Détection d'anomalies sur des chaînes de capteurs. Un classifieur binaire « mauvaise lecture » a atteint 91,7 % de précision en test — le type de garde toujours actif que l'on veut sur l'appareil plutôt que dans le cloud.
- Tri par intention. Un classifieur d'intention à cinq classes a atteint 100 % de précision en test sur son jeu synthétique, suffisant pour aiguiller une requête vers le bon gestionnaire.
- Continuation de texte en domaine étroit. Entraînez-le sur un seul corpus — une FAQ, l'aide d'une commande, la grammaire des journaux d'un appareil — et il s'exprime couramment dans ce périmètre.
- Incertitude par token, gratuitement. Le routeur expose un signal d'entropie par position sans coût supplémentaire — un point d'accroche pour un comportement « je ne suis pas sûr » sans modèle additionnel.
Trois choses qu'il ne peut pas faire
- Conversation en domaine ouvert. À l'échelle du kilooctet, vouloir tout couvrir produit du texte incohérent. C'est une question de capacité, pas un bug à corriger.
- Battre un vrai modèle quand on a la RAM. Au-delà d'environ un million de paramètres, un transformeur FP32 classique l'emporte ; utilisez-le si votre matériel le permet.
- Revendiquer des performances sur silicium. Les chiffres de déploiement sont des mesures QEMU, pas un débit sur puce physique ; il n'y a donc pas encore de revendication de consommation ni de tokens par seconde.
Concevoir autour des forces
Le schéma qui fonctionne consiste à traiter le modèle embarqué comme une fonction de texte étroite et fiable, et à garder tout ce qui est ouvert hors du chemin critique. Un thermostat qui interprète une poignée de commandes vocales, un capteur qui signale des lectures malformées, un jouet qui répond dans un petit monde scripté — tout cela joue sur les forces d'un modèle de classe kilooctet : confidentialité, latence nulle, indépendance de la connectivité et aucun coût par inférence. Les précisions des prototypes ci-dessus portent sur des jeux synthétiques en test et sont documentées dans la chronologie du projet ; considérez-les comme des preuves de concept, pas des benchmarks produit.
Concevoir un assistant étroit et fiable
La différence entre un modèle embarqué utile et un modèle frustrant tient presque toujours à la discipline de périmètre. Un modèle de classe kilooctet vous récompense quand vous réduisez le problème jusqu'à en faire une classification ou une continuation strictement bornée, et vous punit quand vous lui posez des questions ouvertes. En pratique, cela signifie définir à l'avance l'ensemble exact des intentions ou des réponses, entraîner sur des données qui ressemblent à ce que l'appareil verra réellement, et ajouter un repli explicite pour tout ce qui sort de l'ensemble. Le signal d'entropie du routeur par token est utile ici : quand le modèle est incertain partout, c'est le signal de revenir à un défaut sûr plutôt que d'émettre une supposition assurée.
La confidentialité et le coût comme atouts produit
Deux propriétés d'un modèle embarqué méritent d'être énoncées à une équipe produit en termes commerciaux clairs. D'abord, la confidentialité est structurelle : parce que le modèle tourne sur la puce sans accès réseau, les données brutes — un flux microphone, un journal de capteur, les mots d'un utilisateur — ne quittent jamais l'appareil, ce qui supprime des catégories entières de risques de conformité et de fuite au lieu de les atténuer. Ensuite, la courbe de coût est plate : il n'y a aucun coût par inférence, donc une fonctionnalité exécutée un million de fois par jour sur une flotte d'appareils coûte autant à opérer qu'une exécutée une seule fois. Pour des fonctionnalités à fort volume et toujours actives, cette courbe plate est souvent l'avantage décisif face à une API cloud facturée à l'appel.
Le cadrage honnête demeure : c'est un spécialiste, pas un généraliste. Utilisé comme une fonction de texte étroite, privée et toujours disponible, c'est une vraie capacité produit ; utilisé comme substitut d'un grand modèle, il déçoit. Accordez la tâche à l'outil et un modèle de classe kilooctet gagne sa place sur la carte.
Obtenir de bons résultats d'un petit modèle
Les équipes qui réussissent avec des modèles de classe kilooctet partagent quelques habitudes. Elles collectent des données d'entraînement qui reflètent la vraie distribution d'entrée de l'appareil plutôt qu'un texte générique, car un petit modèle dépense sa capacité limitée sur ce que vous lui montrez. Elles gardent l'ensemble d'étiquettes petit et sans ambiguïté, puisque chaque classe supplémentaire dilue la précision d'un modèle minuscule. Elles construisent un chemin de repli explicite pour les cas peu confiants au lieu de forcer une réponse, en utilisant le signal d'entropie du routeur comme indicateur de confiance bon marché. Et elles valident sur un jeu réellement mis de côté, pas sur les données ajustées, pour que la précision rapportée soit celle qu'elles verront sur le terrain. Rien de tout cela n'est une pratique exotique d'apprentissage automatique ; c'est une discipline ordinaire appliquée à un modèle dont le budget ne laisse aucune place au gaspillage, et c'est la différence entre un prototype qui démontre bien et une fonctionnalité qui tient dans un produit.
En résumé
Un modèle de langue de classe kilooctet gagne sa place quand vous le traitez comme une fonction de texte étroite, privée et toujours disponible, et que vous concevez autour de ses forces : classification de commandes et d'intentions, détection d'anomalies, routage d'intention, continuation étroite et incertitude par token gratuite. Gardez le périmètre serré, entraînez sur des données qui reflètent la vraie entrée de l'appareil, ajoutez un repli explicite en cas de faible confiance, et validez sur des données mises de côté. Faites cela et les prototypes deviennent des produits ; demandez-lui d'être un GPT de poche et il ne le sera pas. Accordez la tâche à l'outil et un modèle qui tient dans le flash devient une vraie capacité.
Questions fréquentes
À quoi sert concrètement un LLM sur microcontrôleur ?
Des tâches de texte étroites et fiables : classification de commandes et d'intentions, détection d'anomalies sur des chaînes de capteurs, routage d'intention et continuation de texte en domaine étroit — le tout hors ligne et privé. Pas de conversation en domaine ouvert.
Un LLM embarqué est-il privé ?
Oui — le moteur d'Atome n'a aucun accès réseau, donc les données ne quittent jamais l'appareil. Cela élimine toute une catégorie de questions de confidentialité et de conformité pour les applications sensibles.