LFM3-Omni-2B vs Ming-3.0-audio-tiny : un remplacement de stack face à un spécialiste

Deux modèles, tous deux présentés comme petits, tous deux capables de répondre à voix haute, et presque rien d'autre en commun. LFM3-Omni-2B est un checkpoint dense de 2,17 milliards de paramètres de Liquid AI qui accepte du texte, des images, de la vidéo et de l'audio et renvoie du texte ou de la parole à 24 kHz. Ming-3.0-audio-tiny est un modèle à mélange d'experts de 9,3 milliards de paramètres d'inclusionAI, avec 2,7 milliards de paramètres actifs à chaque étape, et il accepte de l'audio et du texte et renvoie du texte ou de la parole à 44,1 kHz. L'un cherche à remplacer toute une pile d'assistant. L'autre cherche à être l'oreille la plus performante possible. Un spécialiste et un généraliste peuvent se trouver derrière une seule clé. un seul point de terminaison Les requêtes sont acheminées selon des règles, avec basculement automatique en cas d'échec d'un chemin.

Le nom rend les choses plus compliquées qu’elles ne devraient l’être. « Tiny » dans la famille Ming désigne sa position par rapport à Ming-3.0-audio-flash, et non sa taille absolue : avec 9.3B de paramètres au total, il compte plus de quatre fois le nombre de paramètres du modèle Liquid. Et LFM3-Omni-2B n’est pas un modèle audio auquel on a greffé la vision — c’est un modèle multimodal général qui se trouve avoir une voie audio. Les comparer ligne par ligne serait injuste pour les deux. Les comparer selon la tâche qu’ils accomplissent est la seule comparaison qui compte.

Ce que chacun est réellement

Ming-3.0-audio-tiny est un modèle audio-langage natif : un encodeur audio et un projecteur alimentent un socle linguistique MoE clairsemé, avec une étape Talker distincte qui génère de la parole lorsque vous le demandez. Il gère le chinois et l'anglais, y compris les accents et les dialectes, et il permet le clonage vocal à partir d'un extrait de référence accompagné de sa transcription. Les poids sont sous licence MIT et disponibles sur Hugging Face et ModelScope ; des quantifications communautaires existent pour MLX et GGUF, et il existe une démonstration ROCm fonctionnelle d'un assistant vocal à faible latence construit dessus. Le dépôt a été mis en ligne début septembre 2026 et la fiche et la configuration ont été actualisées à la mi-octobre, moment où il est devenu réellement utilisable.

LFM3-Omni-2B est la construction opposée. Un seul tronc dense avec un encodeur visuel, un encodeur audio causal et LiquidCodec pour la sortie vocale, entraîné de sorte qu’un seul ensemble de poids gère quatre modalités d’entrée et deux modalités de sortie. Il a été publié le 27 octobre 2026 comme une branche de la famille LFM3 à six modèles de Liquid, sans annonce autonome ni évaluation indépendante. La fiche indique 2,17 milliards de paramètres, un contexte de 32 768 tokens et la LFM Open License v1.0.

• Architecture — 2,17 B dense any-to-any contre 9,3 B au total avec 2,7 B actifs par token, MoE clairsemé plus un Talker de parole distinct.

• Entrées — texte, image, vidéo avec bande sonore, audio 16 kHz vs audio et texte uniquement.

• Sortie vocale — 24 kHz via LiquidCodec, diffusé plus vite que le temps réel, contre 44,1 kHz mono via le Talker, avec des voix prédéfinies nommées et le clonage.

• Langues — 16 langues de texte et 19 paramètres régionaux vocaux, contre le chinois et l’anglais, y compris les dialectes.

• Contexte — 32 768 jetons, indiqués sur la fiche, alors qu’aucune fenêtre de contexte n’est indiquée sur la fiche ; la configuration publiée décrit un budget de positions de 131 072 jetons.

• Licence — LFM Open License v1.0 avec un seuil de revenus contrairement à MIT.

• Empreinte — environ 4,3 Go en BF16 contre environ 21 Go en BF16, la quantification int8 des experts la ramenant à environ 12,5 Go.

Les deux lignes qui se chevauchent réellement

Les tableaux de benchmark inter-laboratoires relèvent surtout du théâtre, car chaque laboratoire choisit son propre banc d’essai. Ici, le chevauchement est suffisamment faible pour être énoncé précisément : deux jeux de données apparaissent dans les deux rapports de fournisseurs, et tous deux sont des tâches audio où la méthodologie est raisonnablement standard.

• Taux d'erreur sur les mots de l'ASR en anglais — 6,36 pour LFM3-Omni-2B contre 4,36 pour Ming-3.0-audio-tiny. Plus la valeur est basse, mieux c'est, et Ming devance de deux points absolus, soit environ un tiers d'erreurs en moins.

• VoiceBench — 64,73 vs 74,29. Ming est en avance de 9,6 points sur le suivi d’instructions orales et le comportement d’assistant vocal.

Sur les tâches que les deux modèles mesurent, le spécialiste l’emporte, et c’est le résultat attendu. Ming consacre 2,7 milliards de paramètres actifs à l’écoute et à la parole. LFM3-Omni-2B consacre 2,17 milliards à l’écoute, à la parole, à la vision et à la lecture en même temps. Un modèle qui ne divise pas sa capacité en quatre devrait être meilleur dans le seul domaine où il œuvre, et c’est bien le cas.

Ce que Ming rapporte et que LFM3-Omni-2B ne rapporte pas est une liste plus longue : taux d’erreur de caractères ASR en chinois 3,79, taux d’erreur de caractères sur les dialectes 10,29, BigBenchAudio 99,20, MMAU 75,90, MMAU-Pro 56,42, précision sur l’audio long 56,39 et BFCL-v3 Audio 79,80. Ce sont de bons chiffres pour un modèle de cette taille, et ils décrivent un système qui a été évalué spécifiquement sur le raisonnement audio plutôt que comme une colonne d’un tableau multimodal. Les équivalents les plus proches de la fiche Liquid sont la compréhension audio MMAR 51,40 et un score d’appel d’outils de 52,20 — mais le benchmark d’appel d’outils n’est pas le même test que BFCL-v3 Audio, et mettre ces deux chiffres côte à côte serait le genre de comparaison que ce billet de blog existe pour éviter.

Le benchmark que cette confrontation ne peut pas trancher

La question intéressante n’est pas de savoir quel modèle entend mieux. C’est de savoir si un seul modèle omni peut effectuer un raisonnement audio-visuel qu’un pipeline ne peut pas faire. Ming-3.0-audio-tiny n’a aucune voie visuelle : il ne peut pas regarder une image et décrire ce qui se passe, ni répondre à une question sur la bande-son d’une vidéo tout en regardant la vidéo. LFM3-Omni-2B peut faire les deux, et Liquid rapporte Daily-Omni 70.09 et WorldSense 47.10 pour exactement cette capacité.

Ces chiffres n’ont pas d’équivalent dans la fiche de Ming, car Ming ne s’attaque pas à cette tâche. La comparaison se ramène donc à une question de périmètre plutôt que de qualité : si votre application est une interface vocale vers un flux audio, Ming est l’oreille la plus performante et celle qui demande le moins de calcul actif. Si votre application combine une caméra, un microphone et un haut-parleur, LFM3-Omni-2B fait quelque chose que Ming ne peut pas faire, quelle que soit sa taille, et l’écart audio est le prix à payer pour la caméra.

La taxe n’est pas négligeable. Deux points de taux d’erreur sur les mots en anglais dans une interface vocale, c’est la différence entre une transcription que l’on peut parcourir rapidement et une qu’il faut corriger. Si le chemin audio est le produit principal et la vision un bonus, la recommandation honnête est d’utiliser Ming pour l’audio et un modèle de vision distinct pour les images, même si cela implique deux points de contrôle.

La facture mémoire décide de plus de déploiements que le benchmark.

Ming-3.0-audio-tiny nécessite environ 21 Go de poids en BF16, ou environ 12,5 Go avec une quantification int8 des experts, et un déploiement complet avec sortie audio peut répartir le Thinker et le Talker sur deux GPU. LFM3-Omni-2B nécessite environ 4,3 Go. Ce n’est pas une petite différence : c’est la différence entre un seul GPU de milieu de gamme et une machine autour de laquelle il faut planifier, et c’est la différence entre un téléphone et un serveur.

La comparaison s'inverse selon ce que vous mesurez. Les 2,7 milliards de paramètres actifs de Ming le rendent économique par token malgré sa taille totale, ce qui est tout l'intérêt d'un MoE clairsemé. LFM3-Omni-2B est dense, donc chaque token coûte la totalité des 2,17 milliards — mais le modèle entier tient dans une fraction de la mémoire et tourne sur du matériel que Ming ne peut pas exploiter.

C’est ici que l’économie du routage devient concrète. OrcaRouter répercute les prix catalogue des fournisseurs sans marge, ainsi un spécialiste moins cher et un généraliste plus cher peuvent se trouver derrière une même clé sans second contrat, et une modification tarifaire d’un fournisseur se répercute sur votre facture le jour même plutôt qu’au prochain renouvellement. Ni LFM3-Omni-2B ni Ming-3.0-audio-tiny ne figurent aujourd’hui à notre catalogue, il s’agit donc d’une affirmation sur la façon dont la plateforme fixe ses prix, et non de la promesse que vous pouvez appeler l’un ou l’autre de ces modèles via nous dès maintenant. Mais le schéma que ces deux modèles créent — un spécialiste bon marché pour le cas courant, un généraliste pour le cas difficile — est exactement celui auquel un routeur sert.

La question de la licence, qui est la véritable bifurcation

Ming-3.0-audio-tiny est sous licence MIT. LFM3-Omni-2B est sous la LFM Open License v1.0, un accord personnalisé comportant un seuil de chiffre d'affaires qui détermine si l'utilisation commerciale nécessite un accord distinct. Pour un prototype de recherche, la différence est théorique. Pour un produit, c'est la première chose que le service juridique demandera, et elle peut l'emporter sur un écart de benchmark de n'importe quelle ampleur.

MIT explique aussi pourquoi Ming dispose déjà de ports communautaires : builds MLX, quantifications GGUF, une démo d’assistant vocal ROCm. Ils existent parce que la licence les a rendus faciles, et c’est grâce à eux que Ming est déployable aujourd’hui sur du matériel que Liquid n’a jamais testé. LFM3-Omni-2B a été publié le 27 octobre avec 83 téléchargements, et il ne dispose que d’un seul chemin de service documenté, uniquement pour la sortie texte. Son écosystème n’existe pas encore.

L'asymétrie pratique est flagrante. En matière de précision audio, d'efficacité mémoire par paramètre actif, de couverture linguistique pour le chinois et les dialectes, de clonage vocal et de liberté de licence, Ming-3.0-audio-tiny est le choix le plus sûr aujourd'hui. En matière de couverture des modalités et d'empreinte brute, LFM3-Omni-2B est le seul des deux capable de regarder une pièce et d'en parler.

Qui devrait récupérer quoi

Choisissez Ming-3.0-audio-tiny si vous développez un produit vocal — transcription, dialogue parlé, clonage de voix, analyse d'appels — et que vous n'avez pas besoin de vision ou êtes prêt à l'associer à un modèle visuel séparé. La licence MIT, les quantifications existantes et l'avantage de deux points en ASR en font le déploiement le moins risqué, et son architecture clairsemée maintient le coût par token à un niveau bas malgré les 9,3B au total.

Choisissez LFM3-Omni-2B si l’appareil dispose d’une caméra et d’un microphone et que la contrainte est la mémoire. Un checkpoint de 4,3 Go qui voit, entend et parle appartient à une catégorie d’objet différente de celle d’un spécialiste audio de 21 Go, et aucune précision ASR ne compense un modèle qui ne tiendra pas. Acceptez que vous achetez de l’étendue, pas de la profondeur, et que chaque chiffre audio qui lui est associé est déclaré par le fournisseur et non reproduit.

Ce que la fiche d’aucun des deux modèles ne vous dit, c’est comment ils se comportent dans la même application. Ce test — même audio, même appareil, même budget de latence — n’a été réalisé par personne en dehors des deux entreprises. Tant qu’il ne l’a pas été, la décision repose sur le périmètre et les licences, que l’on peut connaître aujourd’hui, plutôt que sur la précision, qui, elle, ne l’est pas.