LFM3-1.7B-Base vs LFM2.5-2.6B-Base : moins de paramètres, moins de tokens, plus de contexte

L'arithmétique va dans le mauvais sens. LFM3-1.7B-Base, publié le 26 octobre 2026, est 36 % plus petit que LFM2.5-2.6B-Base, que Liquid AI a publié le 4 août 2026 — 1,73 milliard de paramètres contre 2,69 milliards. Il a également été entraîné sur moins de tokens : 22 000 milliards contre environ 34 000 milliards. Selon les deux chiffres que l'industrie utilise habituellement pour classer les modèles pré-entraînés, le checkpoint plus récent devrait être moins bon. L'affirmation de Liquid est l'inverse, du moins pour le modèle post-entraîné construit à partir de celui-ci, et la question intéressante pour quiconque choisit un tronc à affiner est de savoir laquelle de ces différences est réelle et laquelle est une histoire racontée avec une suite de benchmarks.Exécuter la comparaison devrait coûter du calcul, pas un second contrat. 0 % de marge OrcaRouter répercute les prix catalogue des fournisseurs avec 0 % de marge.

Il s’agit d’une comparaison au sein d’une même famille, ce qui la rend exceptionnellement nette. Même fournisseur, même famille de licences, même vocabulaire de 128 000 jetons, même taille cachée de 2 048, même rôle de base à base. Les deux checkpoints diffèrent par l’architecture, le volume de données, la longueur de contexte et la quantité de post-entraînement intégrée au tronc. Presque tout le reste est maintenu constant.

Le delta, dimension par dimension

• Paramètres — 1,73 Md pour LFM3-1.7B-Base contre 2,69 Md pour LFM2.5-2.6B-Base. Une réduction de 35,7 %, d’où la mention « 35 % de paramètres en moins » dans l’article de lancement de Liquid.

• Couches — 24 contre 30. Le modèle plus récent est à la fois moins profond et plus étroit.

• Mélange de couches — treize convolutions courtes à portes, cinq blocs d’attention à fenêtre glissante et six blocs d’attention complète pour LFM3 ; vingt-deux convolutions et huit blocs d’attention complète pour LFM2.5, sans niveau à fenêtre glissante.

• Attention — seize têtes de requête et quatre têtes clé-valeur dans LFM3, contre trente-deux et huit dans LFM2.5. Les deux conservent une dimension de tête de 128 et une taille cachée de 2 048.

• Largeur du feed-forward — 7 680 pour LFM3 contre 10 752 pour LFM2.5. C'est là que réside l'essentiel de la réduction du nombre de paramètres.

• Cache de convolution — sept pour LFM3 contre trois pour LFM2.5, avec une fenêtre glissante de 256 jetons ajoutée.

• Contexte — 262 144 tokens contre 128 000. Le checkpoint plus récent le double.

• Jetons de pré-entraînement — 22 billions contre environ 34 billions, les 3,5 derniers billions de la nouvelle exécution étant consacrés à des données de mi-entraînement sélectionnées, notamment des traces agentiques et des appels d'outils.

• Artefacts — LFM3-1.7B-Base n'est disponible qu'en safetensors BF16, pour 3,46 Go. LFM2.5-2.6B-Base est proposé en Safetensors ainsi qu'en versions GGUF, ONNX et MLX, s'exécute en moins de 2,5 Go une fois quantifié, et est pris en charge par Transformers, vLLM, SGLang, llama.cpp et MLX.

Où sont passés les paramètres

La réduction n’est pas répartie uniformément, et cela compte pour quiconque estime le coût du fine-tuning. Les embeddings sont liés dans les deux modèles et le vocabulaire est identique à 128 000 tokens, donc la matrice d’embeddings est inchangée. La taille cachée est inchangée à 2 048. Les économies proviennent de trois endroits : six couches de moins, deux fois moins de têtes d’attention et un bloc feed-forward environ 29 % plus étroit.

Réduire le bloc feed-forward est le moyen le plus économique de diminuer un transformer, car ce bloc contient la plupart des paramètres de chaque couche. Diminuer de moitié le nombre de têtes d’attention réduit aussi bien le cache clé-valeur que les poids, ce qui explique pourquoi un modèle dont le contexte est doublé peut encore être décrit comme tenant dans environ 1 Go en 4 bits. Le compromis, c’est la capacité : un MLP plus étroit a moins de place pour stocker des associations factuelles, et un nombre de têtes plus faible donne au modèle moins de motifs d’attention indépendants avec lesquels travailler. L’argument de Liquid est que de meilleures données et un meilleur mélange de couches compensent largement. Cet argument est testable et, à la date de publication, personne en dehors de l’entreprise ne l’a testé.

D'où provient le contexte

Doubler le contexte de 128K à 256K sans doubler le coût de l’attention nécessite de ne pas effectuer d’attention globale. La pile de LFM3 y parvient en envoyant cinq de ses vingt-quatre couches vers une fenêtre glissante de 256 tokens et treize vers des convolutions, ne laissant que six couches voir la séquence entière. La configuration comporte aussi un facteur rotatif partiel de 0,5 sur les couches d’attention globale, appliquant des embeddings rotatifs à la moitié des dimensions de chaque tête, ainsi qu’un thêta rotatif d’un million sur ces couches, contre dix mille sur les couches glissantes.

Le post de lancement de Liquid donne un chiffre concret pour ce que cela apporte : à 128K tokens, le cache KV du modèle texte est de 1,6 Go. Pour LFM2.5-2.6B-Base, aucun chiffre équivalent n’est publié. La comparaison est donc indicative plutôt qu’exacte — la nouvelle architecture est conçue pour tenir un contexte plus long dans moins de mémoire, et le chiffre fourni par le fournisseur est la seule mesure disponible.

Pourquoi moins de tokens est l’affirmation intéressante

De trente-quatre billions de jetons à vingt-deux billions, c’est une réduction de 35 % du calcul de pré-entraînement au niveau des données, et c’est la direction opposée à celle de la plupart des générations de modèles. L’histoire habituelle, c’est plus de données, plus de paramètres, un meilleur modèle. L’histoire de Liquid, c’est moins des deux, avec une nouvelle architecture et un mélange de données qui ajoute des articles scientifiques, du code au niveau du dépôt, des mathématiques et un éventail plus large de sources de connaissances.

L’étape de mi-entraînement de 3,5 billions de tokens est ce qui distingue ce point de contrôle d’un simple pré-entraînement. Elle s’appuie sur des données sélectionnées de meilleure qualité, avec une part plus importante de traces agentiques et d’appels d’outils, et c’est là que la fenêtre de contexte est étendue. Cette étape explique aussi pourquoi le modèle de base dispose d’un gabarit de conversation : les données de mi-entraînement ont été formatées sous forme de conversations, avec et sans traces de raisonnement.

Rien de tout cela ne peut être vérifié de l’extérieur. Les décomptes de tokens sont auto-déclarés, les compositions des données ne sont pas publiées, et aucune ablation ne montre quelle modification a produit quel gain. L’affirmation est plausible — la qualité des données a battu à plusieurs reprises le volume brut au cours des deux dernières années — mais plausible n’est pas mesuré.

Ce qu’une comparaison base par base peut trancher

Il peut établir les spécifications, le coût et la compatibilité, et c’est ce que fait cette page. Il ne peut pas établir la qualité, car aucun des deux checkpoints ne dispose d’un benchmark publié. Liquid n’a publié aucune évaluation pour LFM2.5-2.6B-Base et n’en a pas publié non plus pour LFM3-1.7B-Base. Les deux fiches recommandent le checkpoint pour un fine-tuning intensif et renvoient les lecteurs ailleurs pour le chat.

La seule preuve de qualité de la famille est la paire post-entraînée. Liquid rapporte que LFM3-1.7B obtient une moyenne de 49,37 sur sa propre suite, contre 31,55 pour LFM2.5-2.6B, le modèle plus récent utilisant 35 % de paramètres en moins. Il s’agit d’un écart important, et c’est un chiffre fourni par le fournisseur, mesuré sur une suite choisie par le fournisseur, comparant deux modèles qui diffèrent tant par leur post-entraînement que par leur tronc. C’est la preuve que la recette LFM3 produit un meilleur modèle instruct. Ce n’est pas une preuve que le checkpoint de base constitue un meilleur point de départ, car le post-entraînement appliqué par-dessus pourrait expliquer toute la différence.

Notes de migration pour toute personne utilisant LFM2.5

Les deux checkpoints partagent une taille de vocabulaire, une taille cachée et une famille de tokeniseurs, ce qui donne l’impression que la migration est plus simple qu’elle ne l’est. Ils ne partagent pas le code de modélisation : LFM2.5 se charge en tant que Lfm2ForCausalLM et LFM3 en tant que Lfm3ForCausalLM, tous deux via du code personnalisé avec trust_remote_code=True. Un script d’entraînement écrit pour l’un ne chargera pas l’autre sans changer la classe de modèle, et les gabarits de chat diffèrent dans leur gestion des traces de réflexion.

La principale différence opérationnelle concerne le packaging. LFM2.5-2.6B-Base propose des versions GGUF, ONNX et MLX et fonctionne avec llama.cpp, vLLM, SGLang, Transformers et MLX. LFM3-1.7B-Base est fourni sous la forme d’un unique fichier safetensors BF16 ; les versions quantifiées et multiplateformes existent pour le modèle LFM3-1.7B post-entraîné, pas pour le checkpoint de base. Si votre pipeline dépend d’un artefact GGUF, vous devrez le convertir vous-même et valider le résultat.

La prise en charge du fine-tuning est le contrepoids. LFM3-1.7B-Base fournit des liens vers des notebooks TRL pour le fine-tuning supervisé et le pré-entraînement continu, et la documentation décrit le parcours à partir de là. Le checkpoint plus petit, le contexte de 256K et le mid-training agentique visent précisément le type d’adaptation de domaine que démontrent ces notebooks.

De quel tronc faut-il partir ?

Partez de LFM3-1.7B-Base si vous démarrez un nouveau fine-tune, que votre tâche bénéficie d’un contexte long et que vous pouvez travailler en BF16 avec Transformers ou convertir les poids vous-même. La réduction de 35 % des paramètres représente de vraies économies sur une session d’entraînement sur un seul GPU, le doublement du contexte constitue un véritable changement de capacités, et le template de chat raccourcit la phase supervisée.

Restez sur LFM2.5-2.6B-Base si vous disposez déjà d’un pipeline opérationnel, dépendez d’un artefact GGUF ou ONNX, ou avez besoin d’un checkpoint bénéficiant d’un an d’outillage communautaire à son actif. Le modèle plus récent n’a que trois jours. Son homologue instruct dispose de builds quantifiés et d’un support dès le premier jour dans vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX et ONNX Runtime, mais ce n’est pas le cas du checkpoint de base, et cet écart constitue le coût pratique d’être en avance.

Si vous avez un doute, lancez l’expérience plutôt que de lire le marketing.Prenez un petit échantillon de vos propres données, exécutez la même recette de pré-entraînement continu sur les deux trunks pendant le même nombre d’étapes, et évaluez sur un ensemble de validation que vous avez constitué avant de commencer. Cela représente quelques heures de GPU et répond à une question qu’aucun tableau de fournisseur ne peut trancher. Lorsque les deux fine-tunes existent, placez-les tous les deux derrière un seul point de terminaison : OrcaRouter, dont le DSL de routage peut répartir le trafic entre eux, et le basculement automatique signifie qu’une mauvaise expérience ne devient pas une mauvaise journée de production. La plateforme répercute les prix catalogue des fournisseurs à 0 % de marge, donc le coût du test est celui du calcul, pas un second contrat.

Le nombre à surveiller

L’affirmation qui permettrait de trancher n’est pas une moyenne de plus. C’est une évaluation de modèle de base — n’importe quelle évaluation de modèle de base — publiée par Liquid ou par un tiers, comparant LFM3-1.7B-Base et LFM2.5-2.6B-Base après une recette de fine-tuning identique. Tant qu’elle n’existe pas, l’écart générationnel est documenté dans l’architecture et la configuration, plausible au vu des nombres de tokens, et non prouvé là où cela compte. Le checkpoint plus récent est plus petit, avec un contexte plus long et mieux préparé pour l’entraînement. Savoir s’il est meilleur est une question à laquelle le dépôt ne répond pas.