Optimisation LLM embarquée pour agents mobiles Android

Pourquoi la qualité d’un agent mobile commence par la latence perçue

Un agent téléphone paraît intelligent quand il répond au bon moment. Vous dictez « prépare une réponse à ce message », l’écran affiche un brouillon, le destinataire est clair, puis vous confirmez. Si l’attente est trop longue, l’utilisateur reprend le téléphone à la main. L’optimisation LLM embarquée pour agents mobiles commence donc par une question d’expérience : combien de temps faut-il pour comprendre, proposer et afficher une action fiable ?

La latence ne se limite pas au temps de génération du texte. Sur un téléphone, elle inclut le réveil du modèle, la mémoire disponible, la batterie, le passage entre apps, la disponibilité au premier plan et le moment où l’utilisateur voit une étape confirmable. Un agent mobile doit être assez rapide pour rester dans le flux, mais assez lisible pour laisser l’utilisateur corriger une action sensible.

Google décrit Gemini Nano via Android AICore comme une voie d’IA générative sur l’appareil, avec une latence d’inférence faible, des cas d’usage sensibles à la confidentialité et des expériences sans réseau quand le support est disponible. Cette direction compte pour les agents : certaines décisions courtes peuvent être traitées près du téléphone, au lieu de dépendre de chaque aller-retour réseau.

Chez FoneClaw, nous mesurons la qualité du point de vue de l’action. Une réponse rapide doit ouvrir la bonne app, afficher le résultat, garder une confirmation pour un message ou un réglage important et proposer une reprise simple quand le contexte est ambigu. Pour le cadre plus large des actions téléphone, notre guide sur le contrôle du téléphone par agent IA explique pourquoi le modèle seul ne suffit pas.

Taille du modèle, quantification et petits modèles utiles

Sur ordinateur, un grand modèle peut être choisi pour sa profondeur. Sur téléphone, la taille du modèle devient une contrainte quotidienne : mémoire, température, batterie, stockage, temps de chargement et disponibilité pendant qu’une autre app est ouverte. Un LLM mobile efficace n’est pas forcément le plus massif ; c’est celui qui traite la bonne tâche au bon coût.

La quantification consiste à représenter le modèle avec moins de précision numérique pour réduire sa taille et son coût d’exécution. Les adaptateurs ajoutent des capacités ciblées sans remplacer toute la base du modèle. Le choix de petits modèles permet de confier des tâches simples à une IA plus légère : classer une notification, reformuler un message court, reconnaître une intention, préparer une commande locale.

Apple décrit dans ses mises à jour sur les modèles Foundation des travaux liés à la quantification, aux adaptateurs, au partage du cache KV et à une séparation entre modèle local et modèle serveur. L’intérêt pour un lecteur Android n’est pas de copier une architecture Apple, mais de comprendre que tous les acteurs mobiles travaillent sur le même problème : rendre l’IA utilisable dans les limites d’un téléphone.

Dans un flux FoneClaw, cette logique se traduit par un tri des tâches. Un modèle léger peut aider à préparer une réponse courte ou à repérer une action probable. Une demande complexe peut appeler un raisonnement plus riche. L’utilisateur voit ensuite une action Android prise en charge : brouillon, rappel, navigation, app ouverte ou confirmation. La taille du modèle devient utile quand elle améliore ce parcours concret.

AICore, Gemini Nano, ML Kit GenAI, LiteRT et LiteRT-LM sur Android

Pour qu’un LLM embarqué serve un agent mobile, il lui faut un chemin d’exécution stable. Le modèle ne vit pas seulement dans un fichier ; il doit être téléchargé, chargé, appelé, mis à jour, limité par quotas, relié à l’app et cohérent avec les capacités du téléphone. C’est le rôle des environnements Android et des outils développeur.

La Prompt API de ML Kit GenAI illustre cette approche : elle exige des appareils Android compatibles, vérifie la disponibilité de la fonctionnalité, peut télécharger Gemini Nano, prend en compte la préparation initiale pour réduire la latence du premier appel, et documente les limites de tokens ainsi que les quotas par app. Pour l’utilisateur final, ces détails deviennent visibles sous forme de disponibilité, vitesse, attente initiale ou message de repli.

Google regroupe aussi des outils côté appareil dans Google AI Edge, avec MediaPipe, LiteRT et LiteRT-LM. La page LiteRT-LM met en avant des exemples de LLM locaux, avec des dimensions comme prefill, decode, temps avant le premier token, backends CPU/GPU, mémoire et exécution locale hors ligne.

Ces chemins techniques ne donnent pas automatiquement la même expérience sur chaque téléphone. Ils créent plutôt une grille d’évaluation : l’app peut-elle accéder au modèle ? Le modèle est-il déjà prêt ? Le quota est-il disponible ? La mémoire tient-elle ? Le résultat arrive-t-il assez vite pour qu’une action Android reste naturelle ? C’est ici que notre conception FoneClaw relie le moteur IA au geste utilisateur.

Cache KV, préremplissage, génération et préparation initiale

Les termes cache KV, prefill, decode et warmup peuvent sembler éloignés d’un agent téléphone. Ils expliquent pourtant pourquoi une action répétée peut paraître instantanée ou lente. Quand un modèle traite le contexte initial, il prépare une représentation interne. Lorsqu’il génère ensuite la réponse, il produit les tokens un par un. Le cache KV garde une partie de ce travail pour éviter de tout recalculer.

Le prefill correspond au traitement du contexte de départ : consigne, historique court, état visible, texte de notification. Le decode correspond à la génération de la réponse. Le temps avant le premier token influence la sensation de réactivité. La préparation initiale, souvent appelée warmup dans la documentation technique, permet de rendre le premier appel moins abrupt lorsque la fonctionnalité est prête.

LiteRT-LM documente précisément ces dimensions : prefill, decode, temps avant le premier token, mémoire, CPU/GPU et exécution locale. Dans un agent Android, ces mesures importent parce que les workflows sont souvent répétitifs. Résumer les notifications du matin, préparer un message, classer une alerte ou créer un rappel utilisent des structures proches. Réutiliser une partie du contexte peut améliorer la sensation de vitesse.

La longueur du contexte reste une contrainte. Plus l’agent doit lire d’informations, plus la mémoire et le temps augmentent. Chez FoneClaw, nous privilégions des actions visibles et ciblées : prendre le bon extrait, proposer la suite, afficher le résultat et confirmer. Le but n’est pas d’avaler tout le téléphone ; c’est de traiter assez de contexte pour aider l’action actuelle.

Choisir entre inférence locale et raisonnement cloud

Le traitement local est idéal quand la demande est courte, sensible au temps ou proche du téléphone : reformuler un message bref, reconnaître une intention, préparer un rappel, classer une notification, résumer un extrait visible. Le cloud garde son intérêt pour des raisonnements plus longs, des connaissances plus larges ou des tâches qui dépassent les capacités disponibles sur l’appareil.

Cette répartition doit rester compréhensible pour l’utilisateur. Une action locale peut être rapide et disponible sans réseau sur les appareils et fonctionnalités compatibles. Une action cloud peut être plus riche, mais dépend de la connexion, de quotas, de délais et de choix de confidentialité. Pour approfondir ce débat sans le dupliquer ici, notre article agent IA local ou cloud traite les trajectoires générales.

La question pratique est : quelle décision doit être prise maintenant ? Si l’agent prépare un brouillon de réponse à partir d’un message visible, le local peut suffire. Si l’utilisateur demande une analyse longue ou une comparaison complexe, un raisonnement distant peut être pertinent. Dans les deux cas, FoneClaw garde le même principe produit : action Android prise en charge, résultat visible, confirmation quand l’action engage l’utilisateur.

Le choix de traitement fait partie d’une architecture mobile plus large. Notre article sur la fondation en trois couches de l'agent OS explique comment système, modèle et actions se combinent. Ici, l’optimisation LLM embarquée pour agents mobiles se concentre sur le niveau ressenti : temps de réponse, batterie, confiance et reprise en main.

Checklist pour évaluer une fonction LLM embarquée sur téléphone

Quand une app annonce une fonction d’IA locale, posez des questions simples. L’appareil est-il compatible ? Le modèle est-il téléchargé ? La fonction marche-t-elle sans réseau dans certains cas ? Quelle est la première latence après ouverture ? La batterie tient-elle pendant plusieurs usages ? Le résultat peut-il être corrigé avant action ?

• Compatibilité : vérifier le modèle de téléphone, la version Android et les services nécessaires.
• Disponibilité : regarder si la fonction est déjà installée, téléchargée à la demande ou réservée à certains appareils.
• Latence : tester le premier appel et les appels répétés, car la préparation initiale change la sensation.
• Quota : repérer les limites par app, tokens ou usage quand elles sont documentées.
• Batterie : observer l’usage réel pendant une journée, pas seulement une démonstration courte.
• Confidentialité : comprendre quelles étapes restent sur l’appareil et lesquelles utilisent un service distant.
• Repli : vérifier ce qui apparaît quand la fonction est indisponible, lente ou ambiguë.

Les sources actuelles montrent que l’écosystème avance vite : Android Developers sur Gemini Nano, ML Kit GenAI, Google AI Edge, LiteRT-LM et le framework Apple Foundation Models décrivent chacun une partie du mouvement vers l’IA sur appareil.

Pour FoneClaw, la conclusion reste orientée produit : l’optimisation locale a de la valeur quand elle rend une action téléphone plus rapide, plus lisible et plus facile à confirmer. Un bon agent mobile n’est pas seulement un modèle embarqué ; c’est un chemin clair entre intention, contexte visible, action Android et reprise en main.