La définition, sans la brochure
L’IA embarquée veut dire que le modèle tourne en local. Le fichier qui fait le travail est rangé dans le stockage de ton téléphone, il est chargé dans sa mémoire, et il produit son résultat sur place. Rien n’est envoyé et rien n’est attendu.
L’autre solution, qui reste la façon dont la majorité fonctionne, est le côté serveur. Ton appareil emballe l’entrée, l’expédie par le réseau, et affiche ce qui revient. Le modèle peut être énorme et s’améliorer sans cesse, et tu ne le verras jamais.
La même catégorie de logiciel, deux endroits où le poser. Voilà toute la distinction. Le mot « IA » porte beaucoup de poids dans la plupart des phrases où il apparaît.
Là où tu t’en sers déjà
Une bonne partie ne date pas d’hier et ne s’appelle même pas de l’IA.
Ton appareil photo décide où sont les visages avant que tu appuies sur le déclencheur. Ta galerie regroupe les photos selon qui s’y trouve. Ton clavier prédit le mot suivant à partir des précédents. Certains téléphones transcrivent la parole sans connexion, et certains traduisent un texte avec un pack de langue téléchargé.
Aucune de ces fonctions ne demande la permission d’envoyer quoi que ce soit, et la plupart des gens ne se sont jamais demandé où elles tournaient. Elles ont été faites en local parce que la latence comptait, ou parce qu’il aurait été absurde d’envoyer chaque image de la caméra.
Ce que le local t’apporte
Ça marche sans connexion. Pas de signal, mode avion, une cave, un pays où ton forfait ne s’applique pas. Si rien n’est demandé, aucune de ces situations n’est un événement.
Rien n’est transmis. Pour tout ce qui est délicat, c’est la propriété qui compte, et c’est un fait sur le logiciel plutôt qu’une promesse dans un document. Il n’y a pas d’envoi à intercepter, pas de serveur qui garde une copie, pas de politique de conservation à lire.
La latence est prévisible. Un résultat local dépend de ton matériel. Un résultat distant dépend de ta connexion, de la distance jusqu’au serveur et de sa charge. Le local n’est pas toujours plus rapide, mais il est régulier, et il n’échoue pas en silence quand le réseau est mauvais.
Souvent aucun compte. Un traitement côté serveur implique généralement de savoir qui demande. Un traitement local n’en a pas besoin.
Ce que ça coûte
Le prix est réel et ne disparaît pas avec une meilleure app.
De la mémoire et de l’espace. Le modèle doit tenir sur l’appareil et être gardé en mémoire pendant qu’il travaille. Sur un téléphone, cela entre en concurrence avec tout ce que tu as ouvert.
De la capacité en moins. Un modèle qui tient sur un appareil de poche est plus petit qu’un modèle tournant sur un serveur au matériel spécialisé, ce qui veut d’ordinaire dire une précision un peu inférieure, en particulier sur les entrées difficiles comme un accent marqué ou un enregistrement bruyant.
De la batterie et de la chaleur. Le travail réel produit de la chaleur, et un téléphone n’a pas de ventilateur. Tout ce qui dure doit être conçu avec soin ou devient désagréable à tenir en main.
Des mises à jour manuelles. Un modèle côté serveur s’améliore pour tout le monde d’un coup. Un modèle local s’améliore quand tu télécharges une nouvelle version.
Des écarts entre appareils. Un modèle qui tourne confortablement sur un téléphone récent peut peiner sur un appareil de cinq ans. Le traitement côté serveur cache cette différence, le traitement local l’expose.
Pourquoi c’est devenu praticable
L’idée n’a rien de neuf. Faire tourner un logiciel en local, c’est ainsi que l’informatique a fonctionné pendant des décennies. Ce qui a changé, c’est que les modèles utiles sont devenus assez petits pour tenir.
À peu près en même temps, les architectures de modèles sont devenues plus efficaces, donc un niveau de capacité donné a demandé moins de nombres pour s’exprimer. Des techniques de compression d’un modèle entraîné, qu’on regroupe sous le nom de quantification, ont permis de stocker ces nombres avec moins de précision et donc moins de place, généralement au prix d’une perte modeste de justesse. Et les processeurs de téléphone ont gagné du matériel dédié à exactement ce genre de calcul.
À côté de tout ça, certains modèles utiles ont été publiés avec leurs poids disponibles, ce qui a permis aux développeurs de poser un système de reconnaissance capable à l’intérieur d’une app au lieu de fabriquer le client du service de quelqu’un d’autre.
Rien de tout cela n’a rendu le traitement local meilleur que le côté serveur en capacité brute. Cela l’a rendu assez bon pour une large classe de tâches quotidiennes, ce qui est une chose différente et plus utile.
Là où ça n’a pas de sens
Le motif est appliqué à des endroits où il ne rentre pas.
Tout ce qui demande une connaissance du monde au-delà de ton appareil, de l’information récente, les données d’autres personnes, le contenu d’un service, ne peut pas recevoir de réponse en local, aussi bon que soit le modèle. Tout ce qui exige un très gros modèle ne tournera pas sur un appareil de poche en un temps raisonnable. Et tout ce qui est partagé entre plusieurs personnes est un problème de coordination, pas de calcul.
Le terrain idéal de l’embarqué est étroit et précis : une tâche bornée, sur une entrée que tu as déjà, où la latence compte ou l’entrée est délicate. La photo. La prédiction de texte. La traduction d’une page posée devant toi.
Et la dictée, qui se trouve être les trois à la fois.
La réserve sur la confidentialité
L’embarqué ne veut pas automatiquement dire discret.
Une app peut faire tourner son modèle en local et continuer d’envoyer des statistiques, d’exiger un compte, de sauvegarder ses données vers un cloud, et d’expédier le résultat même si le traitement s’est fait sur l’appareil. « Le modèle tourne sur ton appareil » et « rien de ce qui te concerne ne quitte ton appareil » sont deux affirmations différentes, et seule la seconde est ce que les gens veulent dire d’habitude.
Les contrôles utiles portent donc sur le comportement plutôt que sur l’architecture. Demande-t-elle un accès réseau, tout court ? Marche-t-elle en mode avion ? Ses données survivent-elles au passage à un nouveau téléphone, et si oui, où étaient-elles gardées ?
Comment savoir si une app le fait vraiment
Deux minutes, aucune compétence requise.
Installe-la, laisse finir le téléchargement du premier lancement, puis coupe les données mobiles et le Wi-Fi et sers-toi de la fonction. Si ça marche, ça marche en local. Si ça cale ou affiche une erreur de connexion, non.
Le téléchargement de départ est lui-même bon signe : un modèle local doit bien arriver d’une manière ou d’une autre, donc une app qui récupère quelques centaines de mégaoctets puis se tait se comporte exactement comme tu l’attends. Une app qui ne télécharge jamais rien et répond instantanément se sert du matériel d’un autre.
La parole est l’exemple le plus net
La dictée est l’endroit où le compromis se sent le plus facilement, et c’est pourquoi c’est souvent la première chose qu’on déplace sur l’appareil.
L’entrée est privée par nature, puisque tu prononces des phrases que tu ne publierais pas forcément. Le travail est court et borné, donc il convient à un téléphone. Et le mode d’échec de la version côté serveur saute aux yeux : pas de signal, pas de dictée.
LocalType est cet exemple sous forme de produit. C’est un clavier Android où le modèle vocal réside sur le téléphone et fait la reconnaissance sur place, sans le moindre chemin cloud dans l’app. Il livre trois tailles de modèle, 60, 190 et 539 Mo, pour que l’arbitrage entre mémoire et justesse te revienne plutôt qu’à nous. Celle du milieu a converti 6,9 secondes de parole en 4,1 secondes sur un téléphone de test à 4 Go de mémoire, et c’est le genre de chiffre à réclamer à toute app qui se dit embarquée. Il couvre aussi dix-huit langues à partir d’un seul modèle multilingue, et demande le réseau exactement une fois, pour aller chercher le modèle que tu as choisi.
Chaque coût listé plus haut s’applique à lui. Il occupe de la place, ses modèles sont plus petits que ce qu’un serveur ferait tourner, la précision varie selon la langue, et les téléphones anciens veulent le petit modèle. Ce ne sont pas des réserves accrochées à un argumentaire. C’est ce que veut dire l’embarqué.