Le modèle qui tient dans votre poche
Le centre de gravité du déploiement de l’IA se déplace discrètement du cloud vers l’appareil. Le 4 août 2026, Liquid AI a lancé LFM2.5-2.6B, un modèle de 2,6 milliards de paramètres dont le slogan est littéralement « Deploy Agents Everywhere ». Il est conçu pour une tâche précise : exécuter des agents IA multi-étapes — ceux qui planifient, appellent des outils et enchaînent des tâches — sur des téléphones, ordinateurs portables et matériel en périphérie, là où la vitesse, la confidentialité et l’exécution locale comptent plus que l’échelle brute.
Les chiffres qui rendent cela intéressant sont ceux du déploiement, pas seulement ceux des tests. Liquid AI indique que le modèle maintient l’inférence sur CPU sous 2,5 Go de mémoire et décode à environ 220 jetons par seconde sur un Apple M5 Max, 113 jetons par seconde sur un Ryzen AI Max+, et environ 30 jetons par seconde sur un téléphone. Ces chiffres décrivent un modèle qui tourne de façon réactive sur du silicium grand public, non sur un GPU de datacenter. Il a été pré-entraîné sur environ 34 mille milliards de jetons avec un vocabulaire de 128K jetons et une phase dédiée d’extension de contexte à 128K, afin d’ingérer les longues entrées que génèrent les charges de travail agentiques.
Ce qui hisse ce modèle au-dessus d’une sortie de routine, c’est l’affirmation sur la performance relative. Bien qu’il soit le plus petit modèle de son propre tableau comparatif, Liquid AI affirme que LFM2.5-2.6B est « compétitif avec, et souvent supérieur à, des modèles près de quatre fois sa taille ». C’est le schéma vers lequel tout l’écosystème à poids ouverts a convergé au cours de 2026, un été où les modèles à poids ouverts ont rattrapé la frontière : la capacité par paramètre augmente assez vite pour qu’un modèle bien entraîné de moins de 3 milliards de paramètres accomplisse désormais un travail qui exigeait récemment quelque chose de l’ordre de 10 milliards de paramètres ou plus.
Ce que disent réellement les tests
Les scores publiés par Liquid AI sont des tests agentiques et d’utilisation d’outils, ce qui est le bon prisme pour un modèle vendu comme moteur d’agents. Selon les chiffres divulgués par l’entreprise pour LFM2.5-2.6B, il atteint 77,83 sur ToolSandbox (appel d’outils), 59,41 sur LiveCodeBench v6, 59,17 sur IFBench (suivi d’instructions), 51,87 sur AIME25 (raisonnement mathématique), et une moyenne Claw-Eval de 62,85. Ce ne sont pas des scores de modèle de pointe en valeur absolue, mais ils sont solides pour un modèle qui tient dans 2,5 Go et tourne sur un CPU d’ordinateur portable — précisément le compromis que le modèle est conçu pour gagner.
La distinction qui compte pour les acheteurs est celle entre leadership de test et adéquation au déploiement. Un modèle qui domine un classement public mais nécessite un H100 loué pour être servi est un produit différent d’un modèle au score légèrement inférieur mais tournant sur l’appareil déjà entre les mains de l’utilisateur. Pour les charges agentiques à haut volume — un assistant qui lit un document, appelle trois outils et renvoie une réponse structurée, répété des milliers de fois — le coût et la latence d’un aller-retour cloud comptent souvent plus que les derniers points de score. LFM2.5-2.6B est optimisé pour ce second scénario, et le score d’utilisation d’outils en particulier est ce qui rend un agent fiable plutôt que simplement fluide.
Pourquoi l’embarqué bat le cloud pour une classe croissante de tâches
Les arguments en faveur de l’exécution locale des agents ne sont pas idéologiques ; ils sont économiques et opérationnels. Chaque appel d’inférence cloud porte trois taxes : la latence (l’aller-retour réseau), le coût (la facturation par jeton qui croît avec le volume) et l’exposition de la confidentialité (les données de l’utilisateur quittant l’appareil). Pour une requête occasionnelle de robot conversationnel, ces taxes sont négligeables. Pour un agent à haute fréquence qui déclenche des centaines d’appels d’outils pour accomplir une tâche, elles s’accumulent vite — c’est précisément pourquoi un modèle qui garde toute la boucle sur l’appareil change les coûts unitaires.
Les données plus larges du marché confirment que c’est là que se trouve l’usage réel. Le rapport « state of open models » de l’été 2026 de Hugging Face a constaté que les modèles de moins de 1 milliard de paramètres ont capté 83 % de tous les téléchargements, tandis que les modèles au-dessus de 70 milliards de paramètres n’ont attiré qu’environ 3 % du volume en 2026. La conclusion sans détour du rapport est que « les petits modèles sont les seuls à tourner sur le matériel que la plupart des développeurs possèdent réellement ». Un modèle-agent de 2,6 milliards de paramètres qui tourne à vitesse utilisable sur un téléphone se situe pile dans la partie de la distribution où se produit la grande majorité du déploiement réel.
Publicité
Ce que cela signifie pour les équipes qui construisent des produits IA
1. Prototypez la voie embarquée avant de choisir par défaut une API cloud
Avant de câbler un agent à un point de terminaison cloud facturé, testez si un modèle de moins de 3 milliards de paramètres comme LFM2.5-2.6B peut porter la charge localement. Pour les tâches à haute fréquence et riches en outils, la voie embarquée peut éliminer entièrement les coûts d’API par appel et supprimer la latence d’un aller-retour réseau. Construisez d’abord le test local ; traitez l’appel cloud comme le recours pour les tâches que le petit modèle ne peut vraiment pas gérer, non comme le choix par défaut.
2. Mesurez le score d’appel d’outils, pas seulement la qualité de conversation
Pour les agents, la métrique décisive est l’utilisation fiable d’outils, non le poli conversationnel. Lors de l’évaluation d’un petit modèle, pondérez les tests d’appel d’outils et de suivi d’instructions (ToolSandbox, IFBench) au-dessus de la qualité de discussion ouverte, car un agent qui appelle la mauvaise fonction avec assurance est pire qu’un agent qui répond un peu moins éloquemment. Le score de 77,83 sur ToolSandbox de LFM2.5-2.6B est le chiffre à reproduire sur vos propres tâches avant de vous engager.
3. Budgétisez les avantages de confidentialité et hors ligne comme des fonctionnalités
L’inférence embarquée n’est pas qu’une économie de coût — c’est une fonctionnalité que vous pouvez vendre. Des données qui ne quittent jamais l’appareil sont plus faciles à concilier avec les obligations de protection des données, et un agent qui fonctionne hors ligne continue d’opérer là où la connectivité est faible ou intermittente. Pour les équipes servant des marchés à connectivité inégale ou aux attentes strictes de résidence des données, un modèle embarqué transforme ces contraintes en différenciateur plutôt qu’en limitation.
La vue d’ensemble : le seuil utile continue de baisser
L’importance de LFM2.5-2.6B tient moins à ce modèle unique qu’à la tendance sur laquelle il s’inscrit. Au cours de 2026, la taille minimale de modèle nécessaire pour accomplir un travail agentique réellement utile a baissé régulièrement, tandis que le matériel des appareils ordinaires n’a cessé de s’améliorer. Il en résulte une zone qui s’élargit où le meilleur choix de déploiement n’est pas le plus grand modèle qu’une organisation peut se permettre de louer, mais le plus petit qui accomplit la tâche — exécuté là où les données se trouvent déjà. Cela inverse l’hypothèse de la première ère des agents, lorsque la capacité était assez rare pour que chaque charge sérieuse réclame le plus grand modèle cloud disponible.
Pour un acheteur, le scénario de correction mérite d’être nommé : un petit modèle embarqué peut être une fausse économie si la tâche exige vraiment un raisonnement de pointe, et pousser un modèle sous-dimensionné dans un flux à enjeux élevés pour économiser sur les factures d’API est son propre mode d’échec. La discipline consiste à faire correspondre honnêtement le modèle à la tâche — réservez le modèle cloud de pointe au raisonnement que lui seul peut faire, et laissez un modèle comme LFM2.5-2.6B absorber le travail à haut volume, riche en outils et sensible à la latence qui constitue le gros du trafic réel des agents. Le signal le plus clair d’août 2026 est que la seconde catégorie est désormais bien plus grande qu’il y a un an, et qu’elle tourne sur du matériel que les gens transportent déjà.
Questions Fréquemment Posées
Qu’est-ce que LFM2.5-2.6B et quand est-il sorti ?
LFM2.5-2.6B est un modèle de langage de 2,6 milliards de paramètres lancé par Liquid AI le 4 août 2026, conçu spécifiquement pour exécuter des agents IA sur l’appareil — téléphones, ordinateurs portables et matériel en périphérie — plutôt que dans le cloud. Il a été pré-entraîné sur environ 34 mille milliards de jetons, maintient l’inférence sur CPU sous 2,5 Go de mémoire, et décode à environ 220 jetons par seconde sur un Apple M5 Max et environ 30 jetons par seconde sur un téléphone.
Comment un modèle de 2,6 milliards de paramètres peut-il rivaliser avec de bien plus gros ?
Liquid AI indique que LFM2.5-2.6B est « compétitif avec, et souvent supérieur à, des modèles près de quatre fois sa taille » sur les tests agentiques et d’utilisation d’outils, avec 77,83 sur ToolSandbox et 59,17 sur IFBench. Cela reflète une tendance plus large de 2026 : la capacité par paramètre a augmenté assez vite pour qu’un modèle bien entraîné de moins de 3 milliards de paramètres accomplisse un travail qui exigeait récemment bien plus gros — tout en tenant sur du matériel que la plupart des développeurs possèdent déjà.
Pourquoi l’IA embarquée compte-t-elle pour le coût et la confidentialité ?
Chaque appel d’inférence cloud porte latence, coût par jeton et exposition de la confidentialité car les données de l’utilisateur quittent l’appareil. Pour les agents à haute fréquence qui font de nombreux appels d’outils par tâche, ces coûts s’accumulent. Un modèle embarqué élimine la facture d’API par appel, supprime l’aller-retour réseau et garde les données locales — des avantages qui comptent surtout pour les charges à haut volume et pour les équipes aux exigences strictes de résidence des données ou de fonctionnement hors ligne.














