Fuite sur LFM3 : la prochaine famille de Liquid AI se compose de quatre petits modèles Omni

Une pull request ouverte sur GitHub le 27 octobre 2026 cherche à apprendre à SGLang à servir une famille de modèles qui n’existe pas publiquement. Elle nomme quatre checkpoints — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B et LFM3-Omni-2B — et se lit par rapport aux LFM2.5-2.6B et LFM2.5-24B-A2B déjà livrés comme un plan de ce que Liquid AI construira ensuite. La PR n’est pas fusionnée. Ses trois vérifications CI échouent toutes. Liquid AI n’a rien annoncé de tout cela. Ce diff non fusionné constitue l’intégralité des informations publiques sur LFM3 à ce jour, et il est plus instructif que la plupart des annonces de lancement — à condition de le lire pour ce qu’il est.

Soyons donc précis au sujet des éléments de preuve, car ils sont minces dans une direction et inhabituellement détaillés dans une autre. Rien ici ne constitue une date de sortie, un prix, une condition de licence ou un score de benchmark. Il n’existe ni fiche modèle LFM3, ni dépôt Hugging Face, ni article de blog, ni référence dans une API. Ce qui existe, c’est une contribution de tugot17 — Piotr Mazurek, qui au cours des deux derniers mois a intégré la prise en charge du runtime LFM dans SGLang, llama.cpp et mlx-vlm — ainsi que les documents publiés par Liquid sur la génération LFM2.5 que celle-ci s’apprête à remplacer. Tout ce qui suit est étiqueté en conséquence.

Ce que la pull request met réellement sur la table

Le titre de la PR est [Feat] lfm3 : Ajout de la prise en charge du texte, de la vision, de l’audio et d’Omni, et il porte deux étiquettes qui vous indiquent de quel type de changement il s’agit : jit-kernel et Multi-modal. Il ajoute la génération de texte native pour une famille de quatre, chacune avec son propre chemin de point de contrôle :

• LFM3-1.7B — texte en entrée, texte en sortie, le modèle de langage simple à la base de la famille

• LFM3-VL-2B — texte, images et vidéo en entrée, texte en sortie

• LFM3-Audio-2B — entrée texte et audio, sortie texte, et également connecté au point de terminaison /v1/audio/transcriptions

• LFM3-Omni-2B — en entrée : texte, images, audio et vidéo, y compris la bande-son d'une vidéo ; en sortie : texte

Un détail dans cette liste mérite qu’on s’y attarde. Chaque variante produit du texte. Il n’existe aucune sortie audio nulle part dans la PR, et la surface non conversationnelle du modèle audio, c’est la transcription — parole en entrée, texte en sortie. C’est plus restreint que la gamme audio actuelle de Liquid, où LFM2.5-Audio-1.5B est documenté comme gérant l’ASR, la TTS et le chat vocal entrelacé au sein d’un seul modèle. Soit la première version SGLang ne couvre que la moitié génératrice de texte de LFM3-Audio, soit la famille omni abandonne réellement la synthèse vocale. La PR ne permet pas de trancher, et quiconque vous affirme qu’elle le fait ne fait que deviner. Considérez que « LFM3 parle » n’est pas prouvé.

Le reste du diff relève de détails d’implémentation qui, malgré tout, permettent de dater le travail. Des encodeurs vision et audio avec leurs projecteurs, un backbone partagé, une intégration de cache hybride, des noyaux de convolution CuTe DSL avec une solution de repli PyTorch, et une note indiquant que FlashInfer utilise par défaut le prefill paginé pour que l’attention à fenêtre glissante se comporte correctement. La validation a été exécutée sur des H100 en FP16 en utilisant ce que la description appelle les checkpoints de développement — quatre mots qui compteront plus tard.

La phrase sur l’architecture, et le nombre que les gens vont mal lire

La PR décrit LFM3 comme un squelette partagé de convolutions courtes à portes avec attention complète et à fenêtre glissante. Il s’agit de la lignée LFM2 poursuivie, non remplacée : LFM2.5-24B-A2B est documenté comme un hybride de convolutions courtes à portes et d’attention à requêtes groupées sur 40 couches. Ce qui semble nouveau dans la fuite, c’est la composante explicite à fenêtre glissante qui accompagne l’attention complète.

Les notes de validation mentionnent une invite dépassant une fenêtre glissante de 256 tokens, et c'est le chiffre qui sera cité hors contexte toute la semaine. Ce n'est pas la longueur de contexte de LFM3. Dans une conception hybride, les couches d'attention n'ont besoin de voir que localement, car les couches de convolution portent le signal longue portée — c'est toute la prémisse de l'architecture, et c'est pourquoi la famille peut contenir 131 072 tokens de contexte sur LFM2.5-24B-A2B alors que la plupart de ses couches ne font pas du tout d'attention quadratique. Une fenêtre d'attention de 256 tokens est une indication sur l'endroit où le modèle regarde à l'intérieur d'une couche, pas sur la quantité de texte qu'il peut accepter. La PR ne précise pas le contexte total de LFM3, et personne en dehors de Liquid ne le connaît encore.

Pourquoi une pull request sur le runtime est le signal, et non du bruit

Il est raisonnable de se méfier d’une lecture de la stratégie produit à partir d’un diff d’infrastructure. Dans ce cas précis, le schéma est trop cohérent pour être ignoré, car Liquid livre la prise en charge des moteurs avec les poids plutôt qu’après. LFM2.5-2.6B liste llama.cpp, MLX, vLLM, SGLang, ONNX et Transformers 5.0+ parmi les cibles dès le premier jour. LFM2.5-24B-A2B était pris en charge dans llama.cpp, MLX, vLLM, SGLang et ONNX au lancement. Une famille qui arrive avec cinq runtimes prêts doit avoir ses noyaux écrits avant l’annonce, ce qui signifie que les PR arrivent d’abord et que l’article de blog suit.

L’auteur correspond exactement à cette chronologie. L’historique public de Mazurek est une suite de travaux d’intégration LFM : le décodage spéculatif DSpark pour LFM2-VL dans SGLang en septembre, les corrections de LFM2.5-VL-3B et des modèles de draft DSpark dans llama.cpp le même mois, le décodage spéculatif hérité du modèle texte dans mlx-vlm, et une réutilisation de configuration LFM2-MoE dans SGLang le 13 octobre. LFM3 est l’entrée suivante de cette séquence, déposée le week-end où la famille a changé de nom.

Deux absences en disent autant que la présence. Il n’existe pas de pull request correspondante dans Hugging Face Transformers pour LFM3 — une recherche dans ce dépôt ne renvoie rien — et la PR SGLang charge ses checkpoints via Transformers 5.19.0 standard avec --trust-remote-code, ce que l’on fait lorsque l’architecture n’est pas encore native dans la bibliothèque. Il y a aussi un commit qui rejette explicitement le décodage spéculatif pour LFM3, donc le travail DSpark livré pour la génération 2.5 n’est pas encore repris. Précoce, et incomplet par conception.

La question de la taille que personne n'a résolue

Ici, la fuite et l’ambition affichée tirent en sens opposés, et cette tension est ce qu’il y a de plus intéressant dans le document.

Maxime Labonne, responsable du pré-entraînement chez Liquid, a décrit l’objectif de LFM3 comme consistant à vérifier si l’approche par convolution courte, qui fonctionne à l’échelle de 350 M à 1,2 Md, peut tenir au-delà de 10 Md de paramètres — le régime où les architectures à attention ont historiquement eu l’avantage. C’est une question de mise à l’échelle, et cela implique un grand modèle.

Les checkpoints divulgués sont de 1,7B et trois de 2B. Aucun d’entre eux n’est au-dessus du seuil dont il est question.

Deux lectures tiennent. La première est qu’il s’agit de la première vague compacte — une famille omni pour téléphones et voitures avant l’arrivée d’un grand frère, ce qui correspond à la façon dont Liquid a toujours commencé par de petits modèles et à la façon dont la PR les décrit comme des jalons de développement plutôt que des versions finales. La seconde est que 1,7B et 2B sont simplement les tailles qui étaient pratiques pour valider les kernels, et ne nous disent rien sur ce qui sera livré. La position honnête est que la fuite prouve que la famille existe et prouve sa forme ; elle ne prouve pas son plafond. Si vous attendez un modèle Liquid de >10B, cette PR ne promet ni n’exclut un tel modèle.

Ce que LFM3 hérite, pour le meilleur et pour le pire

La référence à battre est récente et bien documentée. LFM2.5-24B-A2B est sorti le 13 octobre 2026 avec 24 B de paramètres totaux dont 2 B actifs, 40 couches, 64 experts et un routage top-4, un contexte de 131 072 jetons, un vocabulaire de 128 K et 33 T de jetons de pré-entraînement. LFM2.5-2.6B, sorti début août, tient dans moins de 2,5 Go avec un contexte de 128 K. LFM2.5-VL-3B associe la base 2.6B à un encodeur visuel SigLIP2.

Il faut le dire clairement : tous les benchmarks que Liquid publie pour ces modèles sont exécutés par le fournisseur sur les propres harnais de Liquid, sans aucune évaluation indépendante associée. Les chiffres phares du LFM2.5-24B-A2B — AutomationBench 27,69, BFCLv4 65,01, ToolSandbox 80,71, IFEval 96,75 — sont ceux de Liquid, et le même tableau le montre perdant face à Qwen3.6-35B-A3B sur WebArena Verified (26,75 contre 37,62), GPQA Diamond et SWE-Bench Verified. Les tableaux de fournisseurs qui incluent des pertes sont plus crédibles que ceux qui n'en incluent pas, mais crédible n'est pas synonyme de vérifié. Il n'existe aucun chiffre LFM3, quel qu'il soit, donc il n'y a encore rien à comparer.

La licence sera également reportée. Les récents checkpoints LFM de Liquid sur Hugging Face sont chacun étiquetés license: other — une licence LFM sur mesure, et non Apache-2.0 ou MIT. Quelle que soit la licence sous laquelle LFM3 est distribué, partez du principe que les mêmes conditions personnalisées s’appliquent jusqu’à ce qu’une fiche modèle indique le contraire, et lisez-les avant de construire un produit sur les poids.

Quand cela pourrait réellement arriver

Personne ne connaît la date, y compris ceux qui font des pronostics à titre professionnel. Une question sur Manifold Markets concernant la date de sortie de LiquidAI LFM3 donne le T4 2026 à 40 %, le T1 2027 à 21 %, le T2 2027 à 21 %, le T3 2026 à 11 % et le T2 2026 à 7 % — sur un volume total d’environ Ṁ160, ce qui est suffisamment faible pour que les pourcentages reflètent une poignée de traders plutôt qu’un consensus. À lire comme « quelque part dans les deux prochains trimestres, probablement », et pas plus précisément que cela.

La mécanique plaide pour le plus tôt possible plutôt que pour plus tard. Le travail sur le kernel intégré à un runtime majeur relève de l’ingénierie de fin de phase, et non de début de phase — on n’écrit pas des kernels de convolution CuTe et on ne câble pas de cache hybride pour un modèle qui sort dans un an. Le nom de la famille s’est stabilisé en LFM3 sur quatre variantes et quatre chemins de checkpoint. Mais la PR n’est pas fusionnée, avec les trois vérifications au rouge, nécessite une revue d’approbation qu’elle n’a pas, et 2 des 22 contrôles de validation omni et 2 des 16 contrôles de vision échouent encore à leur comparaison ROUGE. C’est une branche en plein vol, pas une release candidate.

Ce que cela signifie si vous choisissez un modèle cette semaine

Rien concernant LFM3 ne devrait changer une décision que vous prenez aujourd'hui. Il n'est pas disponible, pas tarifé, pas évalué par des benchmarks et pas sous licence publique. Si vous avez besoin d'un petit modèle multimodal maintenant, la génération LFM2.5 est la vraie réponse, et ses contraintes — des scores rapportés par le fournisseur, une licence personnalisée et un profil de codage que les propres tableaux de Liquid comme les analyses externes désignent comme le point faible — sont les éléments à mettre dans la balance.

Ce à quoi la fuite est réellement utile, c’est à la planification. Elle vous indique qu’une famille omni compacte arrive, qu’elle arrivera probablement sur plusieurs runtimes à la fois, et que sa variante audio pourrait ne pas synthétiser la parole. Si votre feuille de route supposait que la prochaine étape de Liquid était un modèle texte plus grand, les éléments dont on dispose jusqu’ici ne soutiennent pas cette hypothèse.

La fragmentation des environnements d’exécution est le problème pratique que cette famille va créer. L’habitude de Liquid de livrer simultanément dans llama.cpp, MLX, vLLM, SGLang et ONNX est bonne pour la portabilité et gênante pour quiconque veut un seul point de terminaison : cinq moteurs, cela signifie cinq formes de déploiement, cinq ensembles de particularités de prétraitement et cinq dates différentes auxquelles un correctif arrive. Le catalogue de plus de 200 modèles d’OrcaRouter ne comprend pas un seul checkpoint LFM aujourd’hui, il n’y a donc aucun moyen d’appeler LFM3 par son intermédiaire, et rien ici ne doit être interprété comme une promesse qu’il y en aura un. Ce à quoi sert réellement une couche de routage dans cette situation, c’est la jointure entre un modèle non éprouvé et un chemin de production — envoyer une partie du trafic vers quelque chose de nouveau pendant qu’un modèle connu reste derrière, avec le basculement qui rattrape l’écart, voilà comment évaluer le successeur d’une famille non publiée sans parier une fonctionnalité destinée aux clients sur un marché de prédiction à 40 %.

Les questions ouvertes à surveiller

Quatre éléments régleront la question plus vite que toute spéculation supplémentaire : de savoir si les quatre chemins de checkpoints deviennent de véritables dépôts Hugging Face téléchargeables — à l’heure actuelle, une recherche dans l’organisation LiquidAI ne renvoie rien sous LFM3, et les dépôts nommés dans la PR ne sont pas résolubles publiquement ; si une PR Transformers apparaît, ce qui signalerait que l’architecture est correctement intégrée en amont plutôt qu’exécutée via du code distant ; si les contrôles de validation en échec se règlent, car 2 échecs omni sur 22 font la différence entre une démo et une fusion ; et si un membre de la famille de plus de 10B apparaît, ce qui est la question à laquelle Labonne a déclaré que LFM3 existait pour répondre.

En attendant, la phrase la plus exacte que quiconque puisse écrire au sujet de LFM3 est celle par laquelle cet article a commencé : une pull request existe, elle n'est pas fusionnée, et elle nomme quatre petits modèles omni que Liquid AI n'a pas annoncés. C'est un signal réel — simplement un signal précoce, et les signaux précoces méritent d'être lus comme tels.