LLM à 1000 TPS : ce que cela change pour les agents téléphone

La vitesse ne fait pas tout l’agent

La question pratique n’est pas seulement de savoir si un modèle peut générer 1000 tokens par seconde. La vraie question est plus concrète : qu’est-ce qu’un LLM à 1000 TPS pour agents IA sur téléphone change quand l’utilisateur veut accomplir une action réelle, comme trier des notifications, préparer un message, vérifier un trajet ou avancer dans une tâche longue ? La vitesse réduit l’attente, mais elle ne remplace ni le système, ni les permissions, ni les confirmations.

Dans une conversation classique, l’inférence rapide rend la réponse plus fluide. Sur téléphone, l’effet est plus profond, parce qu’un agent ne fait pas que répondre. Il doit comprendre l’objectif, proposer une étape, lire un retour, ajuster son plan, puis passer à l’action suivante. Si chaque étape attend plusieurs secondes, l’utilisateur perd confiance. Si le modèle répond presque instantanément, la boucle devient plus naturelle.

Mais cette fluidité ne suffit pas à faire un agent fiable. Un modèle rapide peut proposer une action, mais il ne sait pas automatiquement si l’application l’autorise, si Android expose le bon contrôle, si une permission manque ou si l’utilisateur doit confirmer. Pour le contexte général de ce qu’un agent IA Android doit gérer, nous gardons ce lien comme repère sans répéter ici tout le guide d’exécution mobile.

Chez FoneClaw, nous traitons la vitesse du modèle comme une force en amont. Elle aide à raisonner, reformuler, vérifier et réagir plus vite. Notre travail produit commence ensuite : transformer cette intention en actions Android prises en charge, visibles, confirmables et capables de revenir à l’utilisateur quand le téléphone réel impose une limite.

Ce que MiMo UltraSpeed prouve vraiment

Le signal récent le plus net vient de Xiaomi. Selon la page officielle MiMo de Xiaomi, MiMo-V2.5-Pro-UltraSpeed est un mode d’expérience UltraSpeed de MiMo-V2.5-Pro, présenté comme un modèle phare 1T. Xiaomi revendique une vitesse d’inférence maximale dépassant 1000 tokens/s, avec une sortie autour de 500 à 1000 TPS, contre 50 à 100 TPS pour MiMo-V2.5-Pro dans cette présentation.

La même page met en avant des capacités pertinentes pour les agents : entrée et sortie texte, appel d’outils, streaming et prise en charge du cache. Xiaomi cite aussi des scénarios qui dépendent fortement de la latence, comme le trading quantitatif, le contrôle des risques en temps réel, la recherche scientifique et l’aide au codage en direct. Nous devons lire ces informations comme des affirmations officielles de Xiaomi, vérifiées dans ce cadre le 15 juillet 2026, et non comme un benchmark indépendant.

Ce que MiMo V2.5 Pro UltraSpeed prouve surtout, c’est qu’un modèle peut être optimisé pour réduire très fortement le temps de réponse. Cela change l’ergonomie des agents. Un agent qui attend moins peut vérifier plus souvent, maintenir un dialogue plus naturel et corriger plus rapidement une étape. Pour une lecture plus large des modèles agentiques sans transformer cette page en classement, nous renvoyons à MiMo V2.5 Pro UltraSpeed comme sujet adjacent.

Ce signal ne prouve pas que tous les agents téléphone auront cette vitesse, ni que FoneClaw utilise MiMo. Il ne prouve pas non plus que l’automatisation mobile devient simple. Il montre plutôt que la partie raisonnement peut devenir suffisamment rapide pour déplacer le goulot d’étranglement vers l’action réelle : permissions, écrans, apps, confirmations et fiabilité de l’exécution.

Pourquoi la latence change surtout les tâches longues

La latence compte un peu dans une réponse unique. Elle compte beaucoup dans une tâche longue. Sur téléphone, une tâche utile n’est presque jamais une seule phrase. Prenons un exemple : l’utilisateur reçoit plusieurs messages sur un rendez-vous, veut vérifier l’adresse, regarder le trajet, préparer une réponse et créer un rappel. L’agent doit lire, planifier, demander peut-être une précision, préparer un brouillon, vérifier le contexte et attendre une validation.

Si chaque micro-étape prend trois ou quatre secondes, le parcours devient lourd. L’utilisateur commence à se demander si l’agent a compris ou s’il est bloqué. Avec une inférence rapide, les petites étapes deviennent moins coûteuses. L’agent peut proposer plus vite, reformuler plus vite, comparer deux options plus vite et corriger une erreur de contexte avant que l’utilisateur abandonne.

Cette amélioration est encore plus visible dans les tâches répétitives : nettoyage de notifications, regroupement de rappels, préparation de messages similaires, vérification de disponibilité ou enchaînement de petites actions productives. La vitesse n’ajoute pas une nouvelle permission, mais elle rend le dialogue de contrôle plus léger. L’utilisateur peut demander “montre-moi avant d’envoyer” ou “vérifie l’adresse” sans avoir l’impression d’arrêter toute la tâche.

Il faut toutefois garder la limite. Une réponse rapide n’est pas une action réussie. Si l’application ne permet pas l’étape, si la permission n’est pas accordée ou si la décision est sensible, le modèle peut aller vite sans pouvoir finaliser. La latence réduit l’attente dans la boucle planifier, agir, vérifier ; elle ne supprime pas la nécessité d’un vrai cadre d’action sur téléphone.

Le duo modèle rapide et modèle profond

Une architecture d’agent efficace ne repose pas toujours sur un seul modèle qui fait tout. Une idée utile consiste à combiner un modèle rapide pour les petites vérifications et un modèle plus profond pour les décisions difficiles. Le premier maintient la conversation en temps réel, détecte les retours simples et prépare les étapes immédiates. Le second intervient quand il faut raisonner plus longuement, arbitrer entre options ou gérer une demande ambiguë.

Sur téléphone, ce duo peut améliorer l’expérience. Le modèle rapide peut suivre une conversation pendant que l’utilisateur avance : “oui, utilise cette adresse”, “non, prends l’autre contact”, “garde le message en brouillon”. Le modèle plus profond peut intervenir lorsque l’action demande de comprendre plusieurs contraintes, comme choisir entre deux horaires, comparer deux trajets ou reformuler un message délicat.

Ce schéma ne décrit pas une implémentation FoneClaw précise. Il décrit une logique de conception : la vitesse brute ne suffit pas si elle n’est pas placée au bon endroit. Un modèle ultra-rapide utilisé pour une décision complexe peut répondre trop vite mais mal. Un modèle profond utilisé pour chaque micro-confirmation peut rendre l’expérience lente. L’architecture compte autant que le nombre de tokens par seconde.

Le point décisif est le passage d’un état à l’autre. Quand l’agent doit-il continuer vite ? Quand doit-il ralentir pour vérifier ? Quand doit-il demander à l’utilisateur ? Quand doit-il refuser d’aller plus loin ? Les meilleurs agents ne seront pas seulement ceux qui parlent vite, mais ceux qui savent choisir le bon niveau de raisonnement pour chaque étape.

Pourquoi les actions téléphone exigent encore une couche d’action

Un modèle raisonne. Un téléphone agit. Entre les deux, il faut une couche qui traduit l’intention en étapes réelles : ouvrir une app, préparer un message, afficher un brouillon, demander une permission, lire un état, proposer une confirmation ou revenir à l’utilisateur. Même avec une inférence rapide, cette partie reste indispensable. Elle décide si la proposition du modèle devient une action fiable ou seulement une phrase plausible.

Sur Android, les actions sont liées à des permissions, des écrans, des applications et des choix utilisateur. Un agent peut comprendre “envoie un message à Paul”, mais il doit vérifier le destinataire, préparer le contenu, éviter l’envoi silencieux si la confirmation est nécessaire et gérer le cas où l’app ne permet pas l’étape attendue. Un modèle à 1000 TPS peut accélérer la préparation ; il ne remplace pas ce contrôle.

C’est pourquoi nous séparons la vitesse de raisonnement et les actions sur téléphone. Le téléphone n’est pas seulement un terminal de chat. Il porte les notifications, les apps, les capteurs, les permissions et les points de validation. Une bonne expérience agentique doit respecter ce terrain au lieu de prétendre que le modèle peut l’effacer.

Chez FoneClaw, notre rôle est précisément dans cette zone. Nous ne revendiquons pas tous les appareils, toutes les apps ou toutes les permissions. Nous travaillons sur des actions Android prises en charge. Quand l’action est possible, nous cherchons à la rendre plus directe. Quand une validation est utile, nous gardons l’étape visible. Quand une limite apparaît, nous redonnons la main au lieu de masquer le problème.

Notre leçon chez FoneClaw

Chez FoneClaw, nous voyons les modèles ultra-rapides comme une amélioration majeure de la partie amont : compréhension, reformulation, planification, vérification et dialogue. Moins de latence signifie moins de friction dans les tâches longues. Cela peut rendre les agents plus patients, plus réactifs et plus confortables à utiliser sur téléphone.

Cette évolution a désormais une application concrète chez FoneClaw. FoneClaw a obtenu un accès de test interne à MiMo V2.5 Pro UltraSpeed et utilise ce modèle de classe 1T, dont Xiaomi annonce un pic au-delà de 1000 TPS, pour améliorer l’expérience FoneClaw. Pour un agent téléphone, l’avantage n’est pas une vitesse abstraite : c’est une meilleure réactivité pour comprendre l’intention, corriger les étapes et exécuter plus vite les actions mobiles prises en charge.

Mais notre conclusion produit reste claire : la vitesse ne remplace pas le cadre d’action. Un agent mobile fiable doit savoir ce qu’il peut faire, ce qu’il doit montrer, ce qui exige confirmation et ce qui sort du périmètre. Nous ne prétendons pas utiliser MiMo, atteindre 1000 TPS ou contrôler toutes les applications Android. Nous prenons la tendance comme une leçon : plus le raisonnement devient rapide, plus l’exécution doit être propre.

Notre approche consiste donc à relier deux mondes. D’un côté, les modèles plus rapides peuvent rendre les boucles de décision presque instantanées. De l’autre, les actions Android restent concrètes : destinataires, messages, rappels, itinéraires, notifications, permissions et écrans visibles. FoneClaw se situe dans ce second travail, celui qui transforme l’intention en étapes prises en charge.

Le point à retenir est simple : 1000 TPS change l’expérience des agents parce que l’attente devient moins lourde. Mais l’époque des agents téléphone ne sera pas gagnée par la vitesse seule. Elle dépendra de la manière dont cette vitesse s’insère dans un produit qui respecte le téléphone réel, les permissions réelles et la décision de l’utilisateur.