Présentation de LFM3 : six modèles 2B, un seul socle et une fenêtre de 256 tokens qui n’est pas du contexte

La famille LFM3 de Liquid AI est arrivée le 27 octobre 2026 sous la forme de six checkpoints de classe 2B plutôt que d’un seul modèle phare : LFM3-1.7B pour le texte, LFM3-VL-2B pour la vision, LFM3-Audio-2B pour la parole, LFM3-Omni-2B pour tout à la fois, ainsi que deux modèles de décision, d1-2B et d1-omni-2B. Tous les six dérivent d’un unique socle pré-entraîné, LFM3-1.7B-Base, que Liquid a également publié. Le positionnement de l’entreprise est l’« intelligence spécialisée » — un refus délibéré de livrer un petit généraliste et de se battre sur le mauvais axe.

Moins d'un jour après l'annonce, un chiffre de la note technique était déjà mal interprété. L'architecture de LFM3 répertorie des couches d'attention à fenêtre glissante avec une fenêtre de 256 tokens. Il s'agit là de la géométrie de l'attention par couche, et non de la longueur de contexte du modèle. Le modèle textuel accepte 256 K tokens de contexte. Les lecteurs qui ont survolé le tableau des couches et en ont conclu que Liquid avait livré un modèle 2026 doté d'une mémoire de 256 tokens ont le mauvais modèle en tête, et il vaut la peine de rectifier cela avant que quoi que ce soit d'autre dans cet article n'ait de sens.

Ce qu’est réellement l’architecture tri-hybride

LFM3 remplace le mélange bidirectionnel de LFM2 par trois types de couches empilés dans un corps de 24 couches. Treize couches sont des convolutions courtes à portes, cinq sont de l’attention à fenêtre glissante avec une fenêtre de 256 tokens, et six sont de l’attention globale complète. Le noyau de convolution passe de 3 à 7. Trois modifications plus petites s’y ajoutent : une porte sigmoïde qui met à l’échelle indépendamment la sortie de chaque tête d’attention, des plongements rotatifs partiels dans les couches globales qui ne font tourner que la moitié la plus haute fréquence de chaque tête, et une normalisation en sandwich qui conditionne à la fois l’entrée et la sortie de chaque bloc.

Le pari est que les convolutions courtes portent à moindre coût l’essentiel de la structure locale, que l’attention clairsemée gère la distance intermédiaire et qu’une fine part d’attention globale recoud l’ensemble de la fenêtre de 256K. C’est pourquoi le cache KV reste suffisamment petit pour avoir son importance — Liquid rapporte un cache complet de 128K tokens à 1,6 GB, contre 4,3 GB pour Qwen3.5-4B et 5,6 GB pour MiniCPM5-2B sur la même mesure. Le modèle de texte lui-même tient dans environ 1 GB en précision 4 bits.

L'entraînement s'est déroulé en quatre étapes : 22 billions de tokens de pré-entraînement, une phase de mi-entraînement de 3,5 billions de tokens fortement axée sur les traces agentiques et les appels d'outils, qui a également porté la fenêtre de contexte à 256K, un affinage supervisé sur 1,75 billion de tokens, puis un apprentissage par renforcement mixte combiné à une distillation on-policy multi-domaines à partir de six enseignants spécialisés. Le vocabulaire compte 128K tokens, partagé avec LFM2.5-8B-A1B et conçu pour tokeniser les écritures non latines plus efficacement que son prédécesseur.

Les six modèles, et où se situe leur contexte

Liquid précise explicitement qu’il s’agit de modèles frères, et non de niveaux. Chacun reprend le même socle et est post-entraîné pour une forme de sortie différente.

• LFM3-1.7B — modèle dense pour texte et agents, 1,73 milliard de paramètres, contexte de 256K, appel natif d’outils et sortie structurée.

• LFM3-VL-2B — vision-langage, 1,9 milliard de paramètres, doté d’un encodeur visuel interne dont Liquid affirme qu’il nécessite environ un tiers des ressources de calcul de SigLIP2.

• LFM3-Audio-2B — ASR, TTS, traduction vocale et compréhension audio, avec un encodeur interne et LiquidCodec.

• LFM3-Omni-2B — le premier modèle omni de Liquid : texte, image, vidéo et audio en entrée, texte ou parole en sortie.

• d1-2B — un modèle de décision construit à partir de la branche de vision qui répond à des questions structurées en une seule passe avant avec des probabilités calibrées plutôt qu’en prose libre.

• d1-omni-2B — la même interface de décision sur la branche omni.

Les fenêtres de contexte ne sont pas uniformes, et c’est le détail que la couverture du lancement a laissé de côté. Liquid publie une fenêtre pour le modèle texte et le modèle de base — 256K, entrée et sortie combinées — et pour aucun des quatre autres. Ni l’annonce ni la documentation des modèles n’indiquent de longueur de contexte pour LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B ni pour l’un ou l’autre des modèles de décision. Des articles tiers ont fait circuler 128K pour le modèle vision et 32K pour le modèle omni, et ces chiffres sont peut-être exacts, mais au 28 octobre, ils ne figurent pas sur les pages de Liquid. Si vous prévoyez un agent qui lit de longs documents et examine aussi des captures d’écran, vous ne pouvez actuellement pas du tout déterminer la taille du contexte du modèle omni à partir de la documentation de première main. C’est une lacune qu’il vaut la peine de nommer plutôt que de combler à partir d’un blog qui l’a comblée à partir d’ailleurs.

Le tableau comparatif, lu honnêtement

Tous les chiffres de performance ci-dessous sont ceux de Liquid, produits sur le propre harnais de Liquid, et aucun n’a été reproduit de manière indépendante. Au 28 octobre 2026, il n’existe aucune entrée LFM3 sur Artificial Analysis — pas d’Intelligence Index, aucune mesure de vitesse ou de latence par un tiers neutre. Cela compte plus que d’habitude ici, car la comparaison sur laquelle s’appuie le lancement est une comparaison sur un même harnais, ce qui flatte le modèle pour lequel le harnais a été réglé.

LFM3-1.7B obtient 49,37 sur la moyenne de 27 benchmarks de Liquid. Le LFM2.5-2.6B de la société obtient 31,55 sur le même ensemble, d'où provient l'affirmation de « 35 % de paramètres en moins ». Les lignes intéressantes ne sont pas la moyenne :

• Utilisation d’outils — BFCL V4 71.39, ToolSandbox 80.36, τ³-bench 68.01, MCP-Atlas 32.57.

• Web agentique — WebArena-Verified 38,42 ; AutomationBench 41,29 ; BrowseComp-Plus 37,00 ; LiveClaw 45,60.

Codage agentique — SWE-bench Verified 43,40, SWE-bench Multilingual 23,00, Terminal-Bench 2.1 à 12,92.

• Suivi des instructions — IFEval 96.66, IFStruct 93.72, IFBench 73.03, Multi-IF 89.10.

• Connaissances — GPQA Diamond 63,37, HLE 7,17 sans outils et 13,90 avec.

• Contexte long — RULER 128K 65.56, AA-LCR 52.83.

Lu comme une forme plutôt qu’un total, le profil est cohérent : un très solide respect des instructions, un appel d’outils à tour unique respectable et une chute abrupte dès qu’une tâche exige de nombreuses étapes séquentielles. Terminal-Bench 2.1 à 12,92 et SWE-bench Multilingual à 23,00 ne sont pas des chiffres sur lesquels on construit un agent de codage autonome. Liquid ne le cache pas — la fiche modèle invite les utilisateurs à éviter le raisonnement complexe et le codage en plusieurs étapes, ce qui est un positionnement étonnamment direct de la part d’un fournisseur le jour du lancement.

Les allégations d’efficacité constituent l’autre moitié de l’argumentaire. En Q4_0 et avec un contexte de 32K, Liquid affirme que LFM3-1.7B était le modèle le plus rapide sur les trois appareils testés, de 1,8 à 2,8 fois plus rapide que le concurrent suivant, avec l’empreinte mémoire la plus faible. Sur un seul NVIDIA B300 avec SGLang en BF16, il a servi 3,6 milliards de tokens par jour avec 1 024 requêtes simultanées. L’entreprise a également exécuté plus de 300 000 agents LFM3-1.7B en parallèle sur l’archive d’e-mails Enron comme démonstration de résistance. Ce sont des chiffres du fournisseur, non audités, mais c’est le genre de chiffre qu’il est difficile de gonfler discrètement.

Licence et coût d’exploitation

Les poids sont disponibles sur Hugging Face en versions BF16, FP8, NVFP4, GGUF, MLX et ONNX, avec une prise en charge dès le premier jour dans vLLM, SGLang, Transformers, llama.cpp, MLX, ONNX Runtime, Ollama et LM Studio. La licence est la LFM Open License v1.0 : utilisation commerciale sans redevance en dessous de 10 millions de dollars de chiffre d’affaires annuel, avec un accord distinct au-delà. C’est ce seuil, et non le nombre de paramètres, qui détermine si LFM3 est gratuit pour une entreprise donnée.

Liquid exploite également une API hébergée, et les informations publiques y sont plus limitées que ne le laisse penser le lancement. La documentation indique l’ID du modèle et une limite de 256 K pour l’entrée et la sortie, mais aucune grille tarifaire. Des rapports tiers situent le tarif hébergé de LFM3-1.7B à environ 0,08 $ par million de jetons d’entrée et 0,20 $ par million de jetons de sortie, les variantes vision, audio, omni et décision étant facturées plus cher ; Liquid n’a pas publié ces chiffres sur ses propres pages, il faut donc les considérer comme rapportés plutôt que confirmés. L’auto-hébergement, en revanche, n’a aucun prix par jeton — le coût est celui de la machine, et en quantification 4 bits, cette machine peut être un téléphone.

Là où OrcaRouter convient — et là où il ne convient pas

LFM3 ne figure pas au catalogue d'OrcaRouter, et nous n'allons pas prétendre le contraire. C'est un logiciel à poids ouverts que vous exécutez vous-même ou que vous appelez via l'API propre à Liquid. Ce à quoi le routeur sert, c'est la couche qui l'entoure. Un spécialiste de 1,7 B est rarement le seul modèle d'un pipeline : il gère l'appel d'outil, la classification ou l'extraction, et un modèle plus grand gère le tour qui demande du jugement. OrcaRouter place ces modèles hébergés derrière une seule clé, sans marge — le prix catalogue du fournisseur est répercuté tel quel — de sorte que le chemin d'escalade de LFM3 vers un modèle de pointe est une règle de routage plutôt qu'un second contrat. Son basculement automatique en cas d'échec compte surtout pour précisément la charge de travail que cible LFM3, où un seul petit modèle est la seule chose qui sépare une requête d'une erreur.

Le DSL de routage est l’ajustement le plus intéressant. Combiner un spécialiste et un généraliste en un seul appel — un travail de type LFM3 routé vers un petit modèle, tout le reste étant basculé vers un modèle hébergé — est le schéma de déploiement pour lequel cette famille a été conçue. Tout l’argument de Liquid est qu’un modèle 2B bat un modèle de pointe sur une tâche étroite à une fraction du coût. Un routeur est le moyen de capter cette économie sans faire reposer le pipeline dessus.

Quoi regarder

La question ouverte n’est pas de savoir si LFM3 est bon dans ce qu’il prétend faire. C’est de savoir si ces affirmations résistent à un harnais que Liquid n’a pas écrit. Les chiffres agentiques de la famille sont ceux à retester en premier, car WebArena-Verified à 38,42 et AutomationBench à 41,29 se situent bien au-dessus de ce qu’un modèle de 1,7 B a historiquement réussi à faire, et les benchmarks agentiques sont les plus sensibles à l’échafaudage des prompts et à la politique de nouvelles tentatives. Une exécution indépendante qui se situe à quelques points du tableau de Liquid ferait de LFM3 le choix par défaut pour l’appel d’outils sur appareil. Une exécution qui se situe dix points en dessous en ferait un bon suiveur d’instructions avec un récit agentique exagéré.

Tant que cette exécution n’existe pas, le résumé honnête est le suivant : LFM3 est une famille de petits modèles bien conçue et d’une franchise inhabituelle, avec un mélange de couches réellement inédit, un véritable avantage mémoire, des poids publiés à un seuil de licence exploitable, et aucune vérification indépendante d’aucun benchmark phare. La fenêtre de 256 tokens du tableau d’architecture n’est pas la longueur de contexte. Tout le reste dans le lancement mérite d’être pris pour argent comptant jusqu’à preuve du contraire — et mérite d’être mesuré par vous-même avant de le présenter à vos utilisateurs.