LFM3-1.7B contre Gemma 4 26B A4B : deux recettes pour un token bon marché, et une seule tient sur un téléphone

Sur le papier, ces deux modèles adoptent la même approche pour le même problème. LFM3-1.7B, annoncé par Liquid AI le 27 octobre 2026, et Gemma 4 26B A4B, publié par Google DeepMind le 2 avril 2026, existent tous deux pour répondre à une question : comment faire tenir un modèle capable dans un petit budget mémoire ? Ils apportent des réponses opposées. Liquid a réduit la taille du modèle. Google a conservé un modèle de grande taille et ne paie qu’une fraction de celui-ci par token. Les poids sont gratuits, donc la facture correspond à ce que facture l’hébergeur compétent le moins cher. Nous répercutons les prix catalogue des fournisseurs avec 0 % de marge.

La distinction semble être un détail anecdotique d’architecture jusqu’à ce que vous calculiez le coût d’un déploiement, moment où elle devient la seule chose qui compte. Gemma 4 26B A4B active 3,8 milliards de paramètres par token, mais vous devez tout de même en stocker 25,2 milliards quelque part. LFM3-1.7B active la totalité de ses 1,73 milliard de paramètres et en stocke exactement autant. L’une est peu coûteuse à calculer. L’autre est peu coûteuse à posséder.

Deux recettes pour un token bon marché

Gemma 4 26B A4B est un modèle de type mélange d'experts : 128 experts routés plus un expert partagé, 30 couches, avec environ huit experts activés par token. Cela lui confère la capacité de connaissances d'un modèle dense de 25,2B et un coût arithmétique plus proche de celui d'un modèle de 4B. Selon la formulation de Google elle-même, il atteint environ 97 % du score MMLU-Pro du modèle dense Gemma 4 31B pour environ 12 % des FLOPs.

LFM3-1.7B prend l’autre voie. Il est entièrement dense — chaque paramètre intervient sur chaque token — et les économies viennent d’une architecture repensée plutôt que de la sparsité. La pile tri-hybride de Liquid compte 24 couches : 13 convolutions courtes à portes, cinq couches d’attention à fenêtre glissante, six couches d’attention complète. L’essentiel de la modélisation de séquence est assuré par des convolutions, peu coûteuses, et l’attention complète n’apparaît que six fois. C’est ainsi qu’un modèle de 1,73 milliard de paramètres prend en charge un contexte de 262 144 tokens et un vocabulaire de 128 000 tokens sans que le cache KV ne dévore la machine.

• Paramètres totaux — 1,73 Md pour LFM3-1.7B ; 25,2 Md pour Gemma 4 26B A4B.

• Actifs par token — 1,73 Md contre environ 3,8 Md. C'est la seule ligne où les deux sont comparables.

• Mémoire en 4 bits — environ 1 Go contre environ 18 Go. C'est la ligne qui décide du déploiement.

• Contexte — 262 144 tokens sur les deux, à nouveau une véritable égalité.

• Modalité — texte uniquement, par opposition aux entrées texte et image, avec appel natif de fonctions et un mode de réflexion configurable.

• Licence — LFM Open License v1.0, gratuite en dessous de 10 millions de dollars de revenu annuel ; Apache 2.0 sans seuil pour Gemma 4 26B A4B.

Pourquoi 3,8B actifs ne signifie pas 3,8B de mémoire

C'est l'erreur la plus courante lorsqu'on lit une fiche technique de mélange d'experts, alors autant être direct. Les paramètres actifs régissent le calcul et, approximativement, la vitesse. Ils ne régissent pas la taille du fichier que vous téléchargez ni la VRAM que vous réservez. Gemma 4 26B A4B a besoin que ses 25,2 milliards de paramètres soient résidents en totalité pour effectuer le routage entre experts ; en 4 bits, cela approche 18 Go. Vous pouvez l'héberger sur une seule carte de 24 Go, et Google fournit des builds FP8 et NVFP4 pour rendre cela praticable, mais vous ne pouvez pas le mettre sur un téléphone.

LFM3-1.7B pèse environ 1 Go en 4 bits — la fiche de Liquid indique qu'il tient sur un téléphone ou un ordinateur portable, et à cette taille, l'affirmation est crédible plutôt que marketing. Il conserve aussi un cache KV de 1,6 Go à 128K tokens, ce qui est le chiffre qui détermine réellement combien de requêtes simultanées à long contexte vous pouvez supporter.

La conséquence pratique : un déploiement 26B-A4B relève d’une décision de serveur d’inférence, tandis qu’un déploiement 1.7B relève d’une décision de livraison d’application. Ce sont des projets différents, avec des équipes différentes et des structures de coûts différentes, et aucun benchmark ne comble l’écart entre eux.

Ce que chaque fournisseur a publié, et ce que cela vous dit

Google a publié un vaste tableau pour Gemma 4 26B A4B : 82,6 sur MMLU-Pro, 82,3 sur GPQA Diamond, 88,3 sur AIME 2026 sans outils, 77,1 sur LiveCodeBench v6, un Elo Codeforces de 1718, 73,8 sur MMMU-Pro et 44,1 sur MRCR v2 à 128K avec huit aiguilles. Tous ces chiffres sont rapportés par le fournisseur, aucun n’a été reproduit indépendamment. Le suivi de tiers place son Elo LMArena autour de 1438.

Liquid a publié un tableau plus restreint pour LFM3-1.7B, axé sur le travail agentique : 71,39 sur BFCL V4, 80,36 sur ToolSandbox, 68,01 sur τ³-bench, 45,60 sur LiveClaw, 38,42 sur WebArena-Verified. Il indique également 96,66 sur IFEval, 73,03 sur IFBench, 63,37 sur GPQA Diamond, 73,46 sur LiveCodeBench v6 et 65,56 sur RULER à 128K. Liquid ne publie pas de chiffre MMLU-Pro pour LFM3-1.7B, et cette absence n’est pas un zéro — elle signifie simplement que la mesure n’a pas été effectuée.

Seuls LiveCodeBench v6 et GPQA Diamond se recoupent proprement. Gemma 4 26B A4B l’emporte sur les deux, de 3,6 et 18,9 points respectivement. Là où la suite de Liquid devient agentique, il n’existe aucun chiffre Gemma auquel se comparer — Google rapporte τ²-bench à 68,2, et τ² n’est pas τ³, donc placer 68,01 à côté serait une comparaison fabriquée déguisée en comparaison rigoureuse.

Où le 1.7B reste dans la conversation

Un écart de 3,6 points sur LiveCodeBench est plus petit que ne le prédirait le ratio de paramètres de 14 pour 1, et la raison est architecturale. La programmation compétitive récompense la capacité à retenir un schéma et à produire une fonction correcte — une compétence qui bénéficie davantage d’un signal d’entraînement propre que d’une capacité brute. Si les questions de codage constituaient l’ensemble de la tâche, le 26B l’emporterait et cette section serait courte.

Ce qui maintient réellement la pertinence de LFM3-1.7B, c’est la combinaison d’un contexte de 262 144 tokens et d’une empreinte de 1 Go. Un modèle capable de contenir un document volumineux et de s’exécuter sur l’appareil qui le lit est un produit différent d’un modèle capable de contenir le même document sur un serveur. Liquid rapporte 65,56 sur RULER à 128K, ce qui n’est pas un score de contexte long spectaculaire — Gemma 4 26B A4B rapporte 81,4 sur la même famille de benchmarks — mais il est bel et bien mesuré, sur l’appareil, pour un gigaoctet.

Et en matière de suivi d’instructions, le petit modèle n’a pas à rougir : 96,66 sur IFEval et 73,03 sur IFBench sont de solides chiffres pour cette catégorie de taille, tous deux rapportés par le fournisseur. Pour une charge de travail d’appel d’outils ou de sortie structurée, c’est plus proche de la métrique qui compte que ne l’est GPQA Diamond.

Ce que la couche de routage change réellement

Gemma 4 26B A4B figure au catalogue d’OrcaRouter — une seule clé API donne accès à ce modèle aux côtés de plus de 200 autres modèles, avec les prix catalogue des fournisseurs répercutés à 0 % de marge, de sorte qu’un changement de tarif d’un fournisseur est appliqué le jour même plutôt que d’attendre un cycle de révision des prix. Cela compte ici plus que d’habitude, car il s’agit d’un modèle dont l’économie repose entièrement sur les prix des fournisseurs : les poids sont gratuits, donc le montant à payer est celui facturé par l’hébergeur compétent le moins cher, et ce montant évolue.

Le basculement automatique est l'autre moitié. Un modèle mixture-of-experts de 26B avec un contexte de 256K est exactement le type de charge de travail qui atteint les limites de capacité en pic, et le routage entre fournisseurs signifie qu'un mauvais après-midi d'un seul hôte n'est pas votre panne. LFM3-1.7B n'a besoin de rien de tout cela, car il fonctionne sur du matériel que vous contrôlez et n'a aucun fournisseur à partir duquel effectuer un basculement. Ce n'est ni un point en sa faveur ni un point à sa charge — c'est une conséquence du choix de l'autre recette.

La présentation honnête de notre rôle : nous routons le grand modèle sparse, nous ne servons pas le petit modèle dense, et la décision entre les deux n’est pas une décision qu’un routeur peut prendre à votre place.

Décider en une seule passe

Si la cible de déploiement dispose de moins de 20 Go de mémoire — un téléphone, un ordinateur portable, un Jetson, un AI PC — alors Gemma 4 26B A4B n’est pas un candidat et la comparaison s’arrête là. Prenez LFM3-1.7B, planifiez la récupération autour de la lacune de connaissances que Liquid signale elle-même, et utilisez-le pour l’appel d’outils et l’extraction structurée là où ses chiffres sont réellement compétitifs.

Si vous servez depuis un GPU et que la charge de travail est riche en connaissances, multimodale ou nécessite le niveau de raisonnement de la classe 82.3 GPQA Diamond et 82.6 MMLU-Pro, Gemma 4 26B A4B est le meilleur modèle et les 18 Go sont le prix d’entrée. Apache 2.0 élimine entièrement la question des licences, ce qui, pour une grande organisation, vaut plus que quelques points de benchmark.

Si vous construisez un produit qui est déployé sur les deux — un assistant embarqué qui escalade les requêtes difficiles vers un serveur —, les deux ne sont pas du tout concurrents. Ce sont les deux niveaux d'une même architecture, et la question d'ingénierie intéressante est de savoir où tracer la ligne d'escalade, et non quel modèle l'emporte dans un tableau comparatif.

La question ouverte n’est pas la capacité, qui est tranchée en faveur de Google, mais de savoir si un modèle de 1 Go avec un contexte de 256K suffit pour les tâches agentiques étroites dont la plupart des produits embarqués ont réellement besoin. La fiche modèle de Liquid elle-même est d’une franchise inhabituelle en indiquant qu’il ne s’agit pas d’un modèle de raisonnement. Cette franchise vaut plus que l’écart LiveCodeBench, car elle vous dit quelle moitié de votre charge de travail envoyer où.