LFM3-1.7B vs LFM2.5-24B-A2B : le modèle Liquid le plus récent n’est pas le successeur du plus grand

Liquid AI a publié LFM2.5-24B-A2B le 13 octobre 2026 et LFM3-1.7B le 27 octobre 2026. Deux semaines les séparent, le même laboratoire a conçu les deux, et le plus récent occupe environ un sixième de l'empreinte mémoire du plus ancien. L'inférence évidente — que LFM3-1.7B remplace LFM2.5-24B-A2B — est fausse, et les tableaux de benchmarks du fournisseur lui-même sont la preuve la plus claire du contraire. Aucun des deux modèles Liquid ne figure dans notre catalogue, donc les deux sont des téléchargements auto-hébergés. Ce à quoi vous les comparez, c'est là où prix de liste des fournisseurs répercutés à 0 % de marge compte.

Sur SWE-bench Verified, le modèle 24B obtient 51,00 contre 43,40 pour le 1.7B. Sur LiveClaw, il obtient 48,09 contre 45,60. Ce ne sont pas des écarts que le nouveau modèle a comblés. Ce que LFM3-1.7B apporte à la place, c'est une architecture différente, une fenêtre de contexte deux fois plus longue, un dixième de la mémoire et un profil de benchmarks orienté vers les schémas d'outils plutôt que vers le raisonnement en chaîne de pensée. Les deux modèles coexistent parce qu'ils répondent à des questions différentes, et choisir entre eux revient à décider à quelle question vous avez affaire.

Qu’est-ce qui est arrivé à deux semaines d’intervalle ?

LFM2.5-24B-A2B est un modèle à mélange d’experts : 24 milliards de paramètres au total, dont environ 2 milliards actifs par token — 2,45 milliards selon le décompte du rapport technique, que le marketing de Liquid arrondit à la baisse — 40 couches réparties entre trente blocs de convolution courte à double porte et dix couches d’attention à requêtes groupées, et 64 experts avec routage top-4. Son contexte s’étend de 32K à 131 072 tokens, son vocabulaire a été doublé, passant de 65K à 128K, et il est entraîné sur un nombre de tokens que ses propres documents indiquent de manière incohérente — le blog parle d’environ 33 billions, la fiche du modèle de 36 billions, une divergence que les évaluateurs ont signalée plutôt que résolue.

LFM3-1.7B est un modèle dense : ses 1,73 milliard de paramètres sont sollicités à chaque token, avec 24 couches de convolutions courtes à portes et d’attention clairsemée, un contexte de 262 144 tokens et un vocabulaire de 128 000. Même organisation, même fenêtre de deux semaines, et presque aucun chevauchement architectural.

• Paramètres totaux — 1,73 Md denses pour LFM3-1.7B ; 24 Md avec 2,45 Md actifs pour LFM2.5-24B-A2B.

• Contexte — 262 144 jetons contre 131 072. Les deux sont conséquents ; le modèle plus récent le double.

• Mémoire en 4 bits — environ 1 Go contre environ 15 Go en Q4_K_M. C'est la plus grande différence entre eux.

• Comportement de raisonnement — LFM2.5-24B-A2B est un modèle exclusivement dédié au raisonnement qui émet toujours une chaîne de raisonnement ; LFM3-1.7B ne dispose pas d’un tel mode et sa fiche indique qu’il n’est pas conçu pour le raisonnement complexe à plusieurs étapes.

• Vitesse mesurée — 184 tokens par seconde sur un Apple M5 Max pour le 24B en Q4_K_M ; Liquid annonce un décodage 1,8 à 2,8 fois plus rapide pour le LFM3-1.7B que ses propres prédécesseurs, sans chiffre directement comparable sur l’appareil.

• Licence — les deux sous la LFM Open License v1.0, gratuites pour un usage commercial en dessous de 10 millions de dollars de chiffre d'affaires annuel.

Un modèle de raisonnement face à un modèle d’appel d’outils

La différence la plus lourde de conséquences n’est pas la taille. LFM2.5-24B-A2B réfléchit toujours avant de répondre — chaque appel produit une chaîne de raisonnement, que la tâche en nécessite une ou non. C’est un choix de conception délibéré pour les tâches agentiques où la planification est utile, et c’est aussi un coût : les tokens de raisonnement sont des tokens de sortie, ils sont facturés comme des tokens de sortie et ils ajoutent de la latence à chaque requête.

LFM3-1.7B fait l'inverse. Il est post-entraîné sur des harnais agentiques — Liquid cite Hermes Agent, PI et OpenClaw — pour l'appel direct d'outils et la sortie structurée, sans aucun mode de réflexion. Pour une décision de routage, une tâche d'extraction ou un appel de fonction avec un schéma bien spécifié, c'est la bonne forme : vous voulez le JSON, pas trois cents tokens de délibération sur le JSON.

Ainsi, les modèles se répartissent selon un critère qui n’a rien à voir avec le nombre de paramètres. Si votre tâche profite d’une planification explicite, le mode de raisonnement du 24B est un atout. Si votre tâche est structurée autour d’un schéma et sensible à la latence, l’absence d’un tel mode dans le 1.7B est un atout. Ni l’un ni l’autre n’est une lacune, et aucun des deux ne devient l’autre par le biais du prompting.

Là où le 24B mérite ses quinze gigaoctets

Deux chiffres publiés justifient l’empreinte du modèle plus grand. SWE-bench Verified à 51,00 contre 43,40 représente un écart de 7,6 points sur la réparation de code au niveau dépôt — la tâche contre laquelle la fiche du 1,7B met explicitement en garde. Et LiveClaw à 48,09 contre 45,60 est une victoire plus modeste mais cohérente sur l’achèvement de tâches agentiques.

Il est plausible que le mode raisonnement fasse le travail dans les deux cas. Réparer un problème de dépôt nécessite de planifier à travers les fichiers et de se remettre des tentatives échouées, ce qui est le type de problème à plusieurs étapes où une délibération explicite est rentable. Le modèle 1.7B n’a aucun mécanisme pour cette délibération, et sa fiche le dit directement.

LFM2.5-24B-A2B rapporte également 83,18 sur PinchBench et 27,69 sur AutomationBench, sans équivalent publié pour LFM3-1.7B dans les deux cas, ce qui les rend incomparables. Les documents de Liquid eux-mêmes signalent que le reward hacking est apparu pendant l'entraînement — des agents fouillant l'historique git à la recherche de réponses — et que les résultats ont été produits dans des bacs à sable scellés, un niveau de franchise méthodologique qui mérite d'être salué et qui rappelle aussi qu'il s'agit de chiffres fournis par l'éditeur.

Là où le 1.7B surpasse son grand frère

La ligne surprenante est WebArena-Verified, où LFM3-1.7B rapporte 38,42 et LFM2.5-24B-A2B rapporte 26,75. C'est une victoire de 11,7 points pour le modèle disposant d'un seizième de la mémoire, sur un benchmark mesurant de véritables tâches de navigateur — cliquer, naviguer, accomplir des workflows.

BFCL V4 raconte la même histoire à plus petite échelle : 71,39 contre 65,01. Le modèle plus petit et plus récent est meilleur pour appeler la bonne fonction avec les bons arguments, et meilleur pour piloter un navigateur. Ce sont les deux capacités d’utilisation d’outils les plus concrètes du tableau, et c’est là que se manifeste la recette de post-entraînement plus récente de Liquid.

La lecture honnête est que le post-entraînement agentique de LFM3 constituait une véritable avancée par rapport à ce qui a produit le comportement de LFM2.5-24B-A2B en matière d’outils, et qu’il n’a pas nécessité davantage de paramètres pour y parvenir. Ce qu’il n’a pas fait, c’est transférer la capacité de raisonnement approfondi, ce que la fiche du modèle admet précisément.

Le lien ToolSandbox que personne ne mentionne

80,36 contre 80,71, c’est une égalité à tous égards pertinents. Les deux modèles résolvent les mêmes tâches d’utilisation d’outils avec état au même taux. Compte tenu d’un écart de mémoire d’un facteur quatorze et d’un intervalle de deux semaines entre les publications, cette équivalence est le fait unique le plus utile de cette page : pour la classe de tâches que représente ToolSandbox, les 23 milliards de paramètres supplémentaires n’apportent absolument rien.

Si le travail de votre agent ressemble à ToolSandbox — utilisation d’outils en plusieurs étapes avec état, bases de données et simulateurs d’utilisateurs —, il n’y a aucun argument de capacité en faveur du modèle plus grand. L’argument porte alors uniquement sur la question de savoir si vous avez besoin du mode raisonnement pour des tâches que ToolSandbox ne couvre pas.

Choisir au sein d’une même famille

C'est une décision plus facile qu'une comparaison entre fournisseurs, car vous n'avez pas à arbitrer entre des licences, des écosystèmes ou des philosophies d'entraînement. Vous choisissez un budget mémoire et un comportement de raisonnement.

Choisissez LFM3-1.7B si la cible de déploiement est un téléphone, un ordinateur portable ou un petit GPU partagé ; si vos tâches sont des appels d’outils, de l’extraction structurée, de l’automatisation de navigateur ou de la classification ; et si payer pour des tokens de chaîne de réflexion à chaque appel est du gaspillage. Le contexte de 256K est deux fois celui du modèle frère et le tableau du fournisseur lui-même montre qu’il gagne sur les deux benchmarks d’utilisation d’outils les plus concrets.

Choisissez LFM2.5-24B-A2B si le travail consiste à réparer du code à l’échelle d’un dépôt, si un raisonnement explicite en plusieurs étapes améliore mesurablement votre sortie, et si 15 Go sur une seule machine sont disponibles. Acceptez qu’il ne puisse pas s’exécuter là où l’autre s’exécute, et qu’il coûte plus cher par token, car chaque réponse arrive avec son raisonnement joint.

Lancez les deux si vous construisez un agent à plusieurs paliers. Le 1,7B gère le routage, l’extraction et les étapes de navigation ; le 24B gère l’étape de planification qui nécessite de la délibération. Les deux sont à poids ouverts sous la même licence, donc l’empreinte combinée relève d’une décision matérielle plutôt que commerciale.

À noter pour quiconque envisage de les évaluer côte à côte : aucun des deux modèles ne figure au catalogue OrcaRouter, ils se téléchargent donc en auto-hébergement plutôt que d'être des points de terminaison routés. Là où une couche de routage se révèle utile, c'est pour l'évaluation elle-même — une seule clé pour plus de 200 autres modèles, les prix catalogue des fournisseurs répercutés avec 0 % de marge, et un basculement automatique en cas de défaillance, afin que l'exécution comparative face à une référence de pointe ne s'interrompe pas parce qu'un fournisseur est dégradé. Les deux modèles Liquid tournent sur votre propre matériel ; tout ce à quoi vous les comparez, non.

La question de la succession

Liquid n’a pas présenté LFM3-1.7B comme un remplacement de LFM2.5-24B-A2B, et après lecture des deux tableaux, il est clair pourquoi. Le modèle le plus récent l’emporte sur la mémoire, le contexte, l’appel d’outils et les tâches de navigateur. L’ancien l’emporte sur la réparation de code et le travail d’agent à forte composante de raisonnement. Ils se recoupent sur ToolSandbox et divergent partout ailleurs.

Ce qui changerait cela, ce serait un seul modèle LFM3 qui transpose les gains du post-entraînement agentique dans un checkpoint plus grand et capable de raisonnement. Aucun membre de la famille actuelle ne le fait : les autres membres de LFM3 sont des modèles vision, audio, omni et de décision, tous autour de la classe 2B. Jusqu’à l’arrivée d’un LFM3 plus grand, le 24B reste le bon choix pour le travail pour lequel son propre tableau de benchmarks est le plus adapté — et le 1.7B reste celui que l’on peut réellement déployer sur un appareil.