Liquid AI a sorti LFM2.5-8B-A1B, un modèle Mixture-of-Experts open-weight qui active seulement 1,5B de ses 8,3B paramètres totaux par token. Le chiffre qui compte pour les bâtisseurs, c'est le throughput on-device : 253 tokens/sec sur un CPU de laptop M5 Max sous 6GB de mémoire, ~30 tokens/sec sur mobile, pis 18,5K tokens/sec sur un H100 (plus de 1,6B tokens/jour à haute concurrence). C'est le move d'économie de déploiement — tu paies le coût d'inférence de 1,5B actifs en puisant dans un pool de connaissances de 8,3B paramètres, sur du hardware qui rentre dans un sac à dos. Les poids sont sur HuggingFace sous la licence LFM1.0 avec checkpoints base pis post-trained, roulables aujourd'hui sur llama.cpp, MLX, vLLM, pis SGLang.
L'architecture est hybride, pas un MoE transformer vanille. Des 24 couches, 18 sont des blocs de convolution LIV double-gated pis 6 sont des couches grouped-query attention, avec le routing MoE par-dessus — le design conv-heavy est ce qui garde le coût en params actifs pis l'empreinte mémoire assez bas pour l'edge. La fenêtre de contexte a doublé à 131 072 depuis le 32K du prédécesseur ; le vocabulaire a grossi à 128K tokens avec des gains de compression tunés pour le Hindi, Thai, Vietnamien, Indonésien, pis Arabe. Les sauts de benchmark sur LFM2-8B-A1B sont gros : IFEval 79,44 → 91,84 (matchant Gemma-4-26B malgré bien moins de params actifs), MATH500 74,80 → 88,76, taux de non-hallucination AA-Omniscience 7,46 → 63,47, Tau² Telecom 13,60 → 88,07. Les limitations honnêtes sont déclarées par Liquid : le petit compte de params actifs cape la capacité de connaissances, donc c'est pas adapté pour de la programmation lourde ou du travail knowledge-intensive sans retrieval augmentation, pis c'est text-only — pas de vision ni audio.
La lecture écosystème : le MoE-on-edge est maintenant une vraie catégorie distincte des modèles dense small. Qwen, Gemma, pis Phi compétitionnent en dense sous-10B ; le pari de LFM2.5-8B-A1B, c'est que l'activation sparse te donne un plafond de qualité plus haut au même coût d'inférence, ce qui est le bon tradeoff spécifiquement pour l'on-device où la bande passante mémoire, pas le compute, est la contrainte qui lie. Le chiffre de 1,5B actifs, c'est ce qui lui permet de rouler sur un téléphone à vitesse utilisable — un modèle dense 8,3B le ferait pas. Pour l'agent stack, un modèle on-device avec tool calling pis contexte 128K change l'architecture de ce qui peut rouler sans round-trip cloud : des agents locaux qui lisent de longs documents, appellent des outils, pis raisonnent, avec le cloud réservé aux appels knowledge-heavy que le modèle lui-même flag comme hors de sa profondeur (c'est ça que le saut de non-hallucination à 63,47 mesure vraiment — le modèle qui sait quand il sait pas).
Si tu ships de l'IA edge ou on-device lundi matin : les chiffres de 253-tok/s-sur-CPU-laptop pis ~30-tok/s-sur-mobile sont ceux à benchmarker contre ton propre hardware cible, pis la licence LFM1.0 est la chose à lire avant d'assumer l'usage commercial. Si tu bâtis de l'infra agent : paire ça avec une couche RAG pour les tâches de connaissances qu'il flag comme hors profondeur, pis t'as un agent local-first qui touche le cloud seulement quand il le faut. La nouvelle structurelle, c'est que le sparse on-device a battu le dense on-device sur la frontière qualité-par-param-actif — watch si Qwen pis Gemma suivent avec des variantes MoE edge.