LFM3-Omni-2B : le modèle Omni qui parle, et la fuite qui affirmait qu’il ne pouvait pas parler

LFM3-Omni-2B répond avec une voix. Cette seule phrase est la nouvelle, car il y a une semaine, les meilleures preuves publiques disaient le contraire. Lorsque la famille LFM3 a émergé via une pull request SGLang non fusionnée, les checkpoints étaient configurés pour une sortie texte uniquement, et notre propre article sur cette fuite concluait, à juste titre à l'époque, que « LFM3 parle » n'était pas prouvé. Le 27 octobre 2026, Liquid AI a publié l'annonce de la famille et la fiche modèle, et la fiche tranche : sortie vocale à 24 kHz, générée via un composant appelé LiquidCodec, diffusée en streaming plus vite que le temps réel. Un modèle non prouvé ne devrait pas être un élément porteur dès le premier jour. basculement automatique Le trafic peut être déplacé par règle, et un chemin défaillant bascule sans modification de code.

Tout le reste de cette annonce est plus discret que ne le laisse entendre cette correction. L'annonce de Liquid couvre six modèles, et LFM3-Omni-2B n'y a droit qu'à trois phrases — pas de tableau de benchmarks, pas de longueur de contexte, pas de nombre de paramètres. Le dossier quantitatif tient entièrement dans la fiche Hugging Face, d'où proviennent tous les chiffres ci-dessous. Cette séparation mérite d'être comprise avant de bâtir des projets autour du modèle : le positionnement relève du marketing, les chiffres viennent d'un dépôt, et rien dans l'un comme dans l'autre n'a été testé de façon indépendante.

Ce qui a réellement été livré, et quand

Le dépôt a été créé le 21 octobre 2026 à 16:58 UTC. La fiche a été modifiée pour la dernière fois le 27 octobre à 17:25 UTC, le même jour que la publication de la famille. Au moment de la rédaction, Hugging Face affichait 83 téléchargements et 17 mentions J'aime — des chiffres modestes qui correspondent davantage à un checkpoint publié comme une branche d'une famille de six modèles qu'à une sortie phare. Les dépôts frères racontent la même histoire : LFM3-VL-2B a été créé le 19 octobre, LFM3-Audio-2B le 8 septembre, et tous ont été touchés le 27 octobre.

Donc, il ne s’agit pas d’un modèle non annoncé au sens où le brief le laisse entendre. Liquid a annoncé la famille, nommé les six branches et décrit ce que fait le modèle omni. Ce que l’entreprise n’a pas fait, c’est annoncer LFM3-Omni-2B en tant que tel. Il n’y a pas d’article autonome, pas de compte rendu d’évaluation le jour du lancement, pas de page de tarification puisqu’il n’y a pas de point de terminaison hébergé, et pas de benchmark indépendant. C’est dans l’écart entre « annoncé » et « documenté » que se situe cet article.

La carte en entier

Le checkpoint est une unique build BF16 de 2 166 928 384 paramètres, que la fiche modèle arrondit à 2,17 B. Il repose sur le tronc LFM3-1.7B-Base — le même squelette tri-hybride que le reste de la famille, avec des convolutions courtes à portes qui constituent la majorité des couches et une attention globale réservée à une poignée d’entre elles. Sur ce tronc se trouvent un encodeur visuel, un encodeur audio causal et le tokenizer LiquidCodec qui retransforme les tokens générés en forme d’onde.

• Entrées — texte, images à leur résolution native, vidéo à 2 images par seconde pour 4 à 384 images, et audio à 16 kHz. L’entrée vidéo peut inclure sa propre bande-son.

• Sorties — texte, parole à 24 kHz, ou les deux dans la même réponse.

• Contexte — 32 768 jetons couvrant ensemble l’entrée et la sortie.

• Budget d’images — un maximum de 2 048 tokens visuels par image, quelle que soit la résolution.

• Langues — la carte répertorie 16 langues textuelles et 19 langues ou paramètres régionaux vocaux ; les métadonnées du dépôt en annoncent 23. Les deux chiffres ne concordent pas sur la page.

• Licence — LFM Open License v1.0, les conditions personnalisées utilisées par Liquid depuis LFM2, et non une licence OSI.

• Raisonnement — aucun. La carte indique que le mode de réflexion n'est pas pris en charge et que enable_thinking=True ne peut pas être utilisé.

Deux de ces lignes comptent plus que les autres. La première est le contexte de 32K, qui est petit pour un modèle multimodal de 2026 et une conséquence directe de la cible embarquée : chaque token de contexte coûte de la mémoire sur un téléphone. La seconde est la licence. LFM Open License v1.0 n’est pas Apache-2.0, et ses conditions comportent un seuil de revenus qui détermine qui peut utiliser les poids commercialement sans accord distinct. Si vous évaluez ce modèle pour un produit, lisez la licence avant de lire les benchmarks.

Les chiffres que personne n’a annoncés

Le post de Liquid formule une affirmation comparative au sujet de LFM3-Omni-2B : qu’il surpasse les modèles jusqu’à 10,7 milliards de paramètres, « comme Qwen2.5-Omni-7B », sur Daily-Omni, WorldSense et AV-SpeakerBench. Aucun score n’accompagne cette phrase. La fiche les fournit, et ils sont auto-mesurés par Liquid AI — une évaluation de fournisseur, pas une évaluation indépendante, et la seule évaluation qui existe.

Sur les trois benchmarks cités dans l’article, la fiche rapporte Daily-Omni 70,09, WorldSense 47,10 et AV-SpeakerBench 46,79. OmniBench atteint 46,32 au global, avec 48,25 sur le sous-ensemble parole. Pour la réponse visuelle à des questions à l’oral — la fonction phare du modèle, où l’on pose une question sur une image à voix haute —, la fiche indique RealWorldQA 64,68, MMStar 51,79, POPE 83,78, ERQA 39,43 et EmbSpatial 67,59. Les lignes audio sont l’ASR anglais avec un taux d’erreur de mot de 6,36, l’ASR multilingue à 6,72, la synthèse vocale anglaise à 3,80 UTMOSv2, VoiceBench 64,73 et la compréhension audio MMAR 51,40. Ses scores en vision texte uniquement, pour être exhaustif, sont DocVQA 92,47, OCRBench 806 sur 1 000, MMMU validation 42,44 et MathVista mini 62,50.

Lus comme un ensemble, les scores décrivent un modèle compétent en tout et excellent en rien. Un 46,79 sur AV-SpeakerBench et un 47,10 sur WorldSense ne sont pas des chiffres qui gagnent un classement ; ce sont des chiffres qui suggèrent qu’un modèle de 2,2B peut tenir son rang en raisonnement audio-visuel sans s’effondrer. Le score DocVQA est l’exception dans l’autre sens et le chiffre isolé le plus intéressant du tableau — 92,47 pour un modèle omni de 2,2B, c’est élevé, et c’est la seule ligne où ce checkpoint surpasse clairement le modèle de vision dédié de Liquid, qui annonce 91,1.

Ce que la fuite a correctement révélé, et l’unique point sur lequel elle s’est trompée.

La pull request SGLang qui a porté cette famille à la connaissance du public était exacte sur presque tous les aspects structurels. Elle nommait correctement les quatre checkpoints, décrivait correctement le tronc commun partagé, et elle avait raison de souligner que la fenêtre glissante de 256 tokens est un paramètre d’attention plutôt qu’une limite de contexte. Elle avait également raison de se montrer prudente : la pull request n’avait pas été fusionnée, trois contrôles CI échouaient, et deux des vingt-deux contrôles de validation omni échouaient encore sur les comparaisons ROUGE avec les checkpoints de développement.

Ce qui a induit en erreur — et ce que nous avons répété —, c’était la modalité de sortie. Le chemin d’exécution qu’il avait mis en place renvoyait du texte. Il n’y avait aucune branche de sortie audio dans ce code, et l’inférence raisonnable était que la famille avait peut-être abandonné la synthèse vocale, ou que la première version du runtime était uniquement textuelle. Le modèle livré fait les deux. La leçon n’est pas que la fuite était négligente ; c’est qu’une intégration de service décrit le chemin que quelqu’un a implémenté, pas la capacité du checkpoint derrière. Une PR est une preuve concernant un runtime, et nous l’avons traitée comme une preuve concernant un modèle.

Qu'est-ce qui n'est toujours pas confirmé ?

Trois choses, et ce sont les trois qui décideraient d’un déploiement en production.

D'abord, il n'existe aucune évaluation indépendante, de quelque nature que ce soit. Tous les chiffres ci-dessus ont été produits par l'entreprise qui a construit le modèle, sur son propre banc d'essai, sans méthodologie publiée. Il n'y a aucune entrée Artificial Analysis, aucun résultat LMArena, aucune reproduction par un tiers. Considérez le tableau des benchmarks comme une spécification d'intention, et non comme une mesure.

Deuxièmement, le service de la parole n’est pas documenté en dehors de la voie propre au fournisseur. La fiche indique que la prise en charge de SGLang couvre la sortie texte et ne documente pas comment la branche parole est servie. Si votre projet est « un seul modèle, des réponses parlées, sur notre propre matériel », la fiche ne vous donne aucune référence pour la seconde moitié de cette phrase. Au moment de la rédaction, le dépôt ne répertorie aucun fournisseur d’inférence.

Troisièmement, les chiffres des langues ne concordent pas entre eux. Seize langues pour le texte, dix-neuf paramètres régionaux pour la voix, vingt-trois dans les métadonnées. Il s’agit probablement de trois définitions différentes de la même chose, mais personne n’a publié laquelle est correcte.

Pourquoi un modèle omni de 2,2 milliards représente un pari différent

La façon habituelle de créer un assistant vocal en 2026 est un pipeline : un modèle ASR transforme la parole en texte, un modèle de langage réfléchit, un modèle de vision gère la caméra et un modèle TTS prononce la réponse. Chaque étape est un checkpoint distinct, un budget de latence distinct et un mode de défaillance distinct. L’argument de vente de LFM3-Omni-2B est que les quatre se réduisent à un seul fichier BF16 de 4,3 Go qui tient sur un téléphone et ne le quitte jamais.

C'est un véritable argument architectural, et c'est la raison pour laquelle les scores aux benchmarks comptent moins que la forme de la chose. Un pipeline de quatre petits modèles spécialisés battra généralement un seul généraliste sur chaque tâche individuelle. Ce qu'il ne peut pas faire, c'est partager des représentations : le modèle omni perçoit le ton d'une question portant sur une image, et la réponse est conditionnée par les deux à la fois. Savoir si cela produit de meilleures réponses est précisément ce qu'aucune évaluation indépendante n'a testé.

La façon pratique d’utiliser un checkpoint comme celui-ci tant qu’il n’est pas éprouvé consiste à le garder hors de votre chemin critique. Chez OrcaRouter, le DSL de routage a été conçu pour ce schéma — un chemin spécialisé et un chemin expérimental derrière un seul point de terminaison, afin qu’un nouveau modèle puisse recevoir du trafic proportionnellement à sa fiabilité plutôt que d’un seul coup, avec basculement automatique en cas d’erreur. LFM3-Omni-2B ne figure pas aujourd’hui dans notre catalogue, donc rien ici n’affirme que vous pouvez l’appeler via nous. Lorsqu’un modèle comme celui-ci verra le jour, voilà le type de déploiement qui lui convient : disponible, mesuré et non porteur de charge tant qu’il n’a pas fait ses preuves.

Quoi regarder

Le prochain signal n’est pas un autre tableau de benchmarks. C’est de savoir si quelqu’un en dehors de Liquid en publie un. Un modèle omni de 2,2 B qui tient véritablement 70,09 sur Daily-Omni est un résultat notable pour le travail embarqué, et une reproduction indépendante — même partielle — vaudrait plus que la fiche complète du fournisseur. Le deuxième signal est la fusion SGLang : lorsque le chemin vocal est documenté dans une pile de serving, le modèle cesse d’être un dépôt et commence à être une infrastructure.

D’ici là, le résumé honnête est étroit. LFM3-Omni-2B existe, il est plus petit que presque tout ce avec quoi il est en concurrence, il prend quatre modalités en entrée et en donne deux en sortie, et c’est le premier modèle Liquid capable de répondre à voix haute. La fuite disait qu’il ne le pouvait pas. La fiche dit qu’il le peut, et pour l’instant, la fiche est le seul témoin.