Le chiffre intéressant n'est pas le prix. C'est qu'il n'y en a pas.

Ce blog a passé une bonne partie des deux dernières semaines sur le prix au token : la baisse de 80 % de Luna, Fable 5 à 50 $ par million en sortie, DeepSeek à 0,87 $. Tous ces raisonnements supposent qu'un compteur tourne.

LFM2.5-2.6B, de Liquid AI, publié aujourd'hui, est un modèle agentique de 2,6 milliards de paramètres qui tourne entièrement sur l'appareil — 30 tokens par seconde sur un téléphone, en moins de 2,5 Go. Il n'y a pas de compteur. Et Liquid dit clairement que c'est là l'objectif, non un effet secondaire : « les agents peuvent désormais être massivement parallélisés sur du matériel local, exécutant des tâches de fond qui consomment des millions de tokens à coût marginal nul ».

Moins cher change votre facture. Gratuit change votre architecture. Personne ne lance une centaine d'agents de fond spéculatifs susceptibles de brûler chacun un million de tokens quand la sortie coûte 6 $ par million. À coût marginal nul, ce n'est qu'une boucle.

Côté efficacité, c'est un grand chelem

Les mesures de Liquid sur processeur (quantification Q4_K_M, contexte d'entrée de 4 000 tokens) portent sur trois appareils, et LFM2.5-2.6B l'emporte dans toutes les cases — préremplissage le plus rapide, décodage le plus rapide, mémoire la plus faible — aussi bien face à Gemma-4 qu'à Qwen3.5 :

(Décodage en tokens par seconde et par appareil ; mémoire mesurée sur le M5 Max. Le préremplissage suit le même ordre : 6 705 tokens par seconde sur M5 Max, contre 2 401 pour Qwen3.5-9B.)

C'est la colonne du téléphone qui compte, et il ne s'agit pas vraiment d'une comparaison de vitesse. À 7 Go, Qwen3.5-9B ne tourne pas sur un téléphone, en pratique ; et à 8 tokens par seconde, il serait de toute façon inutilisable. Avec ses 2,4 Go et ses 30 tokens par seconde, LFM2.5-2.6B se situe du bon côté d'un seuil, et non un peu plus loin sur une courbe.

Sur GPU, la même efficacité se traduit en débit : environ 15 000 tokens de sortie par seconde à forte concurrence sur un seul H100, ce que Liquid évalue à quelque 1,3 milliard de tokens par jour depuis une seule carte.

Pourquoi il est rapide : l'architecture, pas seulement la taille

Liquid met cela au crédit de « l'architecture LFM2, efficace » puis passe à autre chose. Le mécanisme mérite pourtant d'être détaillé, car il explique la colonne mémoire bien mieux que « c'est un modèle plus petit ».

LFM2 est une architecture hybride : majoritairement des blocs de convolution courte à portes, avec seulement une minorité de blocs d'attention à requêtes groupées (GQA) — un rapport d'environ 1 pour 3 entre attention et convolution dans les modèles les plus petits de la famille. Les blocs sont de type LIV — Linear Input-Varying — des opérateurs dont les poids sont générés à la volée à partir de l'entrée même sur laquelle ils s'appliquent. Ce cadre rassemble convolutions, récurrences et attention sous un même principe : la dépendance à l'entrée.

Ce qui compte pour un déploiement embarqué : un transformeur classique applique une attention softmax à chaque couche, et chaque couche conserve un cache clé-valeur qui grandit avec la longueur de la séquence. Les blocs de convolution de LFM2, eux, ne consultent aucun token passé : chacun entretient un état de taille fixe, mis à jour token après token, sans le moindre cache. L'essentiel de la mémoire du réseau est donc constant par rapport à la longueur du contexte, et non linéaire.

Cela éclaire autrement le tableau ci-dessus. Les 2,4 Go de LFM2.5-2.6B face aux 7,0 Go de Qwen3.5-9B, sur un contexte de 4 000 tokens, ne traduisent pas seulement un écart de taille : c'est surtout que la majorité des couches ne traîne aucun cache par token. Et l'écart devrait se creuser sur des entrées plus longues — précisément le régime d'un modèle agentique doté de 128 000 tokens de contexte : longues sorties d'outils, traces qui s'accumulent, brouillons en plusieurs étapes.

Cet agencement n'a pas non plus été conçu à la main : Liquid indique avoir mené une recherche d'architecture intégrant le matériel dans la boucle, sous contraintes explicites de latence et de mémoire embarquée. D'où un avantage qui se manifeste en débit processeur mesuré, et pas seulement en nombre d'opérations flottantes.

(Les détails d'architecture proviennent des publications de Liquid sur LFM2 et du rapport technique LFM2 ; les rapports de blocs précis sont documentés pour des modèles antérieurs de la famille, et la configuration exacte de cette version peut donc différer.)

Comment un modèle de 2,6 milliards de paramètres devient agentique : tout se joue à l'entraînement

Les petits modèles sont d'ordinaire médiocres sur les tâches agentiques : l'usage d'outils, la planification et la recherche d'information en plusieurs étapes sont exactement ce qui disparaît quand on réduit la taille. Liquid y répond par un post-entraînement en quatre étapes, dont la troisième constitue la nouveauté.

Deux passes de SFT : d'abord une couverture large, puis un façonnage ciblé sur les tâches agentiques, le raisonnement et l'usage d'outils. Le mélange de données est environ sept fois plus gros que celui du LFM2.5-8B-A1B maison, et pondéré vers l'usage d'outils, la recherche web, le génie logiciel et les traces d'agents.

Spécialisation des professeurs. À partir de ce checkpoint SFT commun, Liquid entraîne un expert par domaine — suivi d'instructions, mathématiques, connaissances et maîtrise des hallucinations, code, usage d'outils, contexte long —, chacun par un SFT ciblé complété de RLVR. Les entraîner séparément permet à chaque expert de se spécialiser en profondeur, sans subir les gradients concurrents d'objectifs sans rapport.

MOPD — Multi-Domain On-Policy Distillation. Les spécialistes forment ensuite un élève unique — mais sans lui faire imiter leurs trajectoires. L'élève produit ses propres déroulés selon sa propre politique, et chaque requête est aiguillée vers le professeur du domaine correspondant, qui commente la réponse de l'élève token par token. Le détail de conception qui fait tenir l'ensemble : comme tous les professeurs descendent du même checkpoint SFT que l'élève, leurs retours restent proches de la distribution de ce dernier — assez proches pour le guider sans déstabiliser l'entraînement. C'est une vraie réponse au mode de défaillance classique de la distillation, où l'élève se voit tiré vers une distribution de professeur qu'il est incapable de représenter.

Apprentissage par renforcement agentique dans de vrais harnais. La dernière étape mène un apprentissage par renforcement multi-tours à l'intérieur de Hermes Agent, OpenClaw et d'autres harnais de production — pas dans un simulateur. Chaque déroulé dispose de son propre bac à sable, et l'optimisation se fait par GRPO contre une récompense fondée sur le résultat, combinant une grille d'évaluation confiée à un LLM juge, des vérifications programmatiques et un garde-fou de sécurité strict. S'entraîner dans de vrais harnais expose le modèle à leurs outils, à leurs consignes système et à leurs schémas d'interaction réels.

Une note d'infrastructure, à signaler pour quiconque bâtit des systèmes comparables : un Harness Proxy permet de traiter les harnais tiers comme des boîtes noires, sans les modifier, tout en capturant les trajectoires token par token dont l'apprentissage par renforcement a besoin — le tout validé par contrôle de cohérence linéaire des trajectoires, détection des tokens discordants et Rollout Routing Replay.

Le harnais, encore une fois

S'entraîner à l'intérieur d'OpenClaw et de Hermes Agent, puis sortir avec un mode d'emploi pour se déployer derrière une API compatible OpenAI et y brancher n'importe quel harnais : c'est le schéma que ce blog croise sans arrêt, sous des angles différents : YC ouvrant le code d'une plateforme d'agents neutre vis-à-vis du harnais, DeepSeek adoptant l'API Responses d'OpenAI, et maintenant un fournisseur de modèle qui optimise face à des harnais qu'il ne possède pas.

L'interface s'est standardisée au point qu'un modèle peut être entraîné contre l'écosystème d'un concurrent, et en faire un argument de vente. Voilà à quoi ressemble une couche banalisée vue de l'intérieur — et le couteau coupe des deux côtés pour Liquid : adoption facile, mais remplacement tout aussi facile le jour où paraîtra un meilleur modèle de 2,6 milliards de paramètres.

Le mot « ouvert » en fait, une fois de plus, beaucoup

Les poids sont sur Hugging Face, en version de base et post-entraînée, avec un support GGUF, MLX, vLLM, SGLang et ONNX dès le premier jour. Mais la licence est la LFM Open License v1.0, fondée sur Apache 2.0 et non conforme à l'OSI : les droits commerciaux s'éteignent pour toute entité réalisant 10 millions de dollars ou plus de chiffre d'affaires annuel, laquelle doit alors négocier un accord payant distinct.

Sur l'échelle d'ouverture à six barreaux, c'est un cas d'école de niveau 3 : gratuit jusqu'à ce que vous grossissiez. À noter, le seuil est deux fois plus bas que celui de Kimi K3, fixé à 20 millions de dollars — et, contrairement à la clause de K3, qui ne vise que les revendeurs de modèle en tant que service, celle de Liquid s'applique à l'usage commercial en général. Pour un développeur indépendant ou une jeune pousse, cela revient à de l'Apache 2.0. Pour une entreprise de taille moyenne qui l'intègre à un produit, c'est une négociation de licence.

Ce n'est pas un reproche : le modèle économique se tient parfaitement pour une société qui vend du déploiement embarqué. Mais l'exemple s'ajoute aux autres — le mot « open » dans un nom de licence ne renseigne toujours sur presque rien.

Là où il perd

Liquid le dit franchement, et il faut le saluer : le code est le seul domaine où les modèles plus gros gardent l'avantage. LFM2.5-2.6B domine tous les benchmarks de suivi d'instructions et presque tous ceux d'usage d'outils — il ne s'incline que devant Qwen3.5-9B sur BFCLv4 —, mène sur AA Omniscience et devance les deux modèles Gemma sur les tâches agentiques. Mais sur le code, les gros modèles l'emportent, et Liquid l'écrit noir sur blanc dans son annonce.

Le point compte plus qu'un écart de benchmark ordinaire, car les agents de programmation constituent aujourd'hui la charge agentique la plus rentable du secteur. Autrement dit, l'argument « l'inférence gratuite change votre architecture » est le plus fort là précisément où ce modèle est le plus faible. À court terme, le scénario réaliste n'est pas le local qui remplace le cloud, mais le local qui absorbe le volume — recherche de fond, tri de documents, passes de classification, surveillance continue — avec escalade vers un modèle de pointe pour les 10 % difficiles. Ce qui est, notablement, la même architecture de routage autour de laquelle Microsoft a bâti MDASH, atteinte depuis l'autre extrémité de la courbe des coûts.

Tous les chiffres cités ici viennent de Liquid, sur un panel de comparaison choisi par Liquid — la réserve habituelle, celle que ce blog applique aux tableaux d'Alibaba comme aux autres. Les mesures d'efficacité en sont la moitié la plus crédible : le débit et la mémoire sur du matériel nommément désigné sont ce qu'un tiers peut le plus facilement réfuter.

À surveiller ensuite

• Le « nombre de tokens par jour et par appareil » va devenir une métrique couramment citée. Le prix au million de tokens n'a aucun sens pour un modèle local ; c'est le débit soutenu sous un plafond de mémoire qui détermine ce que l'on peut construire.
• L'agent d'arrière-plan va devenir la catégorie de produit embarquée. Non pas l'assistant conversationnel sur votre téléphone, mais les cent traitements qui tournent pendant que vous ne regardez pas, et qui n'ont de sens économique qu'à coût marginal nul.
• L'écart sur le code sera la prochaine cible, et il sera difficile à combler. Tous les laboratoires qui sortent un petit modèle agentique viseront ce terrain, parce que c'est là qu'est l'argent — et c'est aussi la capacité qui résiste le plus obstinément à la compression.