Agents sur téléphone : ce que les mobile agents ouverts apportent vraiment (après OpenMobile-2)

Il y a un mois, un agent ne pouvait utiliser votre téléphone qu'en théorie : il existait des modèles entraînés sur des captures d'écran, mais aucun environnement public pour les tester, aucun dataset, aucun benchmark comparable. Le paper OpenMobile-2, publié fin octobre, change précisément cela : il ouvre les environnements de training, les recettes d'entraînement et les benchmarks, et avec des chiffres qui méritent d'être vérifiés.

Ce qu'est OpenMobile-2 et ce qu'il a rendu ouvert

OpenMobile-2 est un agent pour smartphone proche du niveau frontier, avec la différence que tout l'écosystème autour est public. Les chiffres clés du paper OpenMobile-2 (2610.14157) :

• MobileGym++, l'environnement de training : 35 apps de style commercial plus 110+ apps au total, avec plus de 300 tools répartis sur 50+ apps. Ce n'est pas un set de démos minimales : c'est un écosystème d'apps simulées où l'agent apprend vraiment à faire.
• ~12 000 trajectoires SFT et 2 000+ tâches RL vérifiables : les datasets de post-training sont ouverts, et les tâches RL sont vérifiables, c'est-à-dire que la tâche dit elle-même si elle a réussi.
• Benchmarks : AndroidWorld 79.9, MobileWorld 50.4, SPA-Bench de 31.9 à 59.6 — presque doublé après l'entraînement. SPA-Bench était le point faible (composition d'actions longues) et c'est exactement ce que les tâches RL ont résolu.

La partie qui compte pour ceux qui construisent : le code et les environnements sont sur github.com/OpenMobile2. Si vous voulez un agent pour téléphone, vous n'avez plus à partir de zéro : partez d'une recette qui a déjà produit un agent quasi frontier.

Le modèle : 9B qui tiennent en 4,5 Go

L'agent se base sur OpenMobile-2-9B, un modèle image-texte-vers-texte de 9 milliards de paramètres, dérivé de Qwen3.5-9B et fine-tuné sur les données OpenMobile-2 : captures d'écran Android et outils natifs des apps. Il existe aussi un frère de 27B, et le checkpoint supporte vLLM et SGLang.

Faisons les calculs de mémoire, car c'est la question qui décide de tout. En 4-bit, chaque paramètre pèse un demi-octet :

Modèle	Paramètres	Poids en 4-bit	+ KV cache	VRAM/RAM totale
OpenMobile-2-9B	9B	~4,5 Go	~1-2 Go (long contexte)	~5,5-6,5 Go
LFM3-1.7B	1,73B	~0,9 Go	~0,3-0,5 Go	~1,2-1,5 Go

Exigence matérielle	9B en 4-bit	1,7B en 4-bit
RAM/VRAM minimale	8 Go (juste)	4 Go
Téléphone réaliste	flagship 12-16 Go	téléphones milieu de gamme
PC ou GPU	n'importe quel GPU 8 Go (3060 et +)	CPU récent, sans GPU

Le 9B ne tient pas sur un téléphone milieu de gamme, mais tient sur un GPU grand public de 8 Go : c'est le modèle à faire tourner sur le PC qui pilote l'agent, ou sur les flagship 16 Go. Le 1,7B, lui, tient vraiment dans la poche.

Et c'est ici qu'entre en scène le deuxième morceau du jour, LiquidAI LFM3-1.7B : un modèle de 1,73 milliards de paramètres avec 256K de contexte, 16 langues — dont le français — et un post-training agentique explicite. En 4-bit il tient en ~1 Go de RAM, sous licence LFM Open v1.0. Ce n'est pas un généraliste : il est optimisé pour la boucle agent (penser → appeler un outil → observer → réessayer), et c'est précisément la boucle dont on a besoin sur téléphone, où chaque token coûte de la batterie.

Ce que signifie « on-device » en pratique

Trois architectures, avec une exigence différente. Le choix change tout :

1. Tout sur le téléphone (1-3B). LFM3-1.7B ou des modèles de la même classe : l'agent tourne en local, lit les captures d'écran, appelle les accessibility services d'Android. Latence très basse, zéro cloud, mais capacité limitée : tâches à pas courts, une ou deux apps à la fois.

2. Agent sur le PC, téléphone en périphérique (9B+). OpenMobile-2-9B sur un GPU 8 Go, qui observe l'écran du téléphone et pilote le tactile. C'est la voie la plus solide aujourd'hui : matériel généreux, modèle capable, et le téléphone reste l'appareil que l'utilisateur tient en main.

3. Hybride : petits pas en local, raisonnement dans le cloud. Le petit modèle gère les pas répétitifs (classifier, remplir, naviguer) et n'envoie au grand modèle que les pas qui comptent. Gartner estime que 9 pas agentiques sur 10 sont routiniers et que les modèles open-weight les gèrent au niveau des frontier — c'est l'architecture qui arrange aussi les entreprises (voir les actus du jour).

Et les limites ?

Soissons honnêtes sur ce qui ne fonctionne pas :

• Le téléphone n'est pas un serveur. 1,7B en 4-bit tient dans 1 Go, mais la batterie en paie une autre : une boucle agent qui tourne des minutes chauffe et décharge. Les chiffres réels de consommation n'existent pas encore en public.
• Les captures d'écran ont un coût. Chaque capture est une image à traiter : sur un téléphone à 1,7B, cela signifie des secondes par observation. C'est pourquoi les tâches longues restent le terrain du 9B ou plus.
• Vérifiable ≠ généralisable. Les 2 000 tâches RL vérifiables sont une excellente base, mais elles couvrent les environnements du paper. Les apps que vous utilisez, avec leurs popups et leurs versions d'aujourd'hui, restent un test à faire vous-même.
• AndroidWorld 79.9 n'est pas votre téléphone. Les benchmarks mesurent des tâches scriptées en environnement contrôlé. Le saut vers un usage réel (contacts, calendrier, messagerie avec vos données) reste ouvert — et c'est précisément parce que les données restent sur l'appareil que cela a du sens en local.

Par où commencer

Si vous voulez toucher au concret, la séquence minimale :

1. Jouez avec MobileGym++ depuis le repo OpenMobile2-Code : c'est un environnement, pas besoin de téléphone. Voyez ce que l'agent sait faire et où il se trompe.
2. Téléchargez LFM3-1.7B depuis Hugging Face et lancez-le en local : le checkpoint 4-bit tient en ~1 Go, et avec Ollama ou llama.cpp vous le servez sur un PC avec 4-8 Go de RAM, sans GPU. Si cela ne marche pas : vérifiez d'avoir téléchargé le checkpoint quantisé (le BF16 pèse ~3,5 Go) et que les pilotes sont à jour.
3. Testez la boucle agent. Demandez-lui une tâche à deux pas — « ouvre la calculatrice et calcule 12×8 » — et lisez les logs : vous devez voir pensée, appel d'outil, observation. Si l'appel d'outil saute, élargissez le contexte et vérifiez que le prompt système décrit les outils disponibles.
4. Pour le 9B il faut un GPU 8 Go (RTX 3060 et +) : servez le checkpoint avec vLLM, puis pointez l'environnement OpenMobile-2 vers votre endpoint. Un setup d'un soir, pas d'une semaine.

En résumé

Après OpenMobile-2, les agents pour téléphone ne sont plus une expérience de laboratoire : environnements, datasets et benchmarks sont ouverts, et un agent quasi frontier a une recette publique que vous pouvez réutiliser. La division pratique est simple : 1,7B (~1 Go de RAM, dans la poche) pour les pas courts en local, 9B en 4-bit (~4,5 Go de poids) pour les tâches longues, sur un GPU grand public de 8 Go. Les limites restent l'énergie, le coût des captures d'écran et la généralisation hors des environnements du paper — mais la direction est claire : le téléphone devient l'appareil où l'IA locale se fait remarquer en premier, et vous pouvez maintenant mesurer vous-même à quel point c'est vrai.

Sources : paper OpenMobile-2 · OpenMobile-2-9B · LFM3-1.7B · OpenMobile2-Code

Article généré par IA