LFM3-Audio-2B sur Ollama : meilleure parole, les mêmes oreilles

de Liquid AILFM3-Audio-2B est devenu téléchargeable en une seule commande ce matin. ollama run lfm3-audio télécharge 2,1 Go et lance un modèle à 2 milliards de paramètres qui prend en entrée du texte ou de l’audio et répond en texte, en parole à 24 kHz, ou les deux. Le modèle lui-même n’a qu’un jour — il est sorti le 27 octobre 2026, au sein de la famille LFM3 composée de six modèles. La nouveauté du 28 octobre, c’est la distribution, et la première chose à savoir se trouve dans le propre tableau de benchmarks de Liquid : face au LFM2.5-Audio-1.5B qu’il remplace, la qualité de la parole a nettement augmenté, la compréhension audio a presque doublé, et la reconnaissance vocale en anglais ne s’est pas améliorée du tout.

Le reste de cet article distingue ce qui est vérifiable aujourd’hui de ce qui ne l’est pas. La branche audio n’a eu droit qu’à un paragraphe d’un billet de blog consacré à la famille et à une fiche modèle — il n’existe pas d’annonce « Introducing LFM3-Audio » qui lui soit propre — et nous n’avons trouvé aucune évaluation comparative indépendante de ce modèle, où que ce soit. Tous les chiffres ci-dessous proviennent de Liquid, sauf indication contraire dans la phrase.

Ce qui a été livré, et à quel point l’annonce était mince

L'article de Liquid du 27 octobre, {{1}}« Présentation de LFM3 : toutes les modalités pour une intelligence spécialisée »{{/1}}, a annoncé six modèles de classe 2B entraînés à partir de {{2}}LFM3-1.7B-Base{{/2}} : texte, vision, audio, omni, et deux modèles de décision spécialisés à partir des branches vision et omni. L'audio est l'une des quatre branches de modalité et ne fait l'objet que d'un seul paragraphe — l'amélioration UTMOSv2, le chiffre de 50 ms de délai jusqu'au premier token, le codec à 87× temps réel. Il n'existe pas d'article spécifique à l'audio, pas d'article de blog sur les benchmarks audio, et aucune entrée de tarification pour un modèle {{3}}LFM3{{/3}} sur la page de tarification de Liquid.

Trois artefacts ont mis le modèle sous les yeux d’un lecteur cette semaine :

• Poids — LiquidAI/LFM3-Audio-2B sur Hugging Face, sous la licence LFM Open License v1.0, avec une fiche modèle qui contient le tableau comparatif complet.

• llama.cpp — PR #31257, fusionnée le 27 octobre, ajoute LFM3-Audio-2B et LFM3-Omni-2B. Elle laisse non quantifiées les convolutions de l’encodeur audio et le codec, expose une voix masculine ou féminine via un indicateur TTS, et classe l’ASR en direct comme PR de suivi plutôt que comme partie intégrante de la fusion.

• Ollama — lfm3-audio, 2,1 Go, tags latest et 2b, affichant 19 téléchargements et « mis à jour il y a une heure » au moment de la capture. L'en-tête de la page indique cinq modèles ; deux lignes sont publiées.

Le référencement Ollama est celui qui compte le plus, car c’est la seule voie qui ne commence pas par la lecture d’une fiche de modèle. Il est aussi apparu sans aucune annonce — pas de billet, pas de journal des modifications, rien sur la fiche du modèle lui-même qui le mentionne.

La fiche technique, y compris le chiffre que presque tout le monde a mal copié.

• Paramètres — 2B au total, sur le backbone LFM3 avec un encodeur audio causal interne et le tokenizer LiquidCodec

• Entrée — texte, ou audio échantillonné à 16 kHz

• Sortie — texte, parole à 24 kHz, ou texte et parole entrelacés

• Contexte — 32K jetons couvrant l’entrée et la sortie. Il ne s’agit pas du chiffre de 256K répété dans la couverture du lancement : celui-ci appartient à LFM3-1.7B, le modèle texte. La page propre à la branche audio indique 32K.

• Langues — 18, répertoriées comme 19 locales car l’anglais apparaît deux fois, en variantes britannique et américaine. La reconnaissance vocale en direct (ASR) fonctionne uniquement en anglais ; la traduction est la plus performante vers l’anglais ou depuis l’anglais.

• Licence — LFM Open License v1.0, gratuite pour un usage commercial en dessous de 10 M$ de chiffre d'affaires annuel, avec une licence commerciale payante au-delà de ce seuil.

• Empreinte — 2,1 Go pour la version Ollama.

Deux de ces lignes méritent qu’on s’y arrête. Le chiffre du contexte est celui qu’un résumé continuera de rater pendant des mois, car la publication de la famille met en avant 256K et la fiche audio indique discrètement 32K. Et le nombre de langues est un décompte de locales déguisé : dix-neuf entrées, dix-huit langues, les deux variantes de l’anglais faisant le travail supplémentaire. Ni l’un ni l’autre n’est un scandale, et les deux changent ce que vous promettriez à un utilisateur.

Une commande, et le champ qui contredit la carte

ollama run lfm3-audio constitue vraiment toute l'installation. La page attribue au modèle les tags tools, audio et 2b, et le readme juste au-dessus du tableau des modèles indique qu'il accepte du texte ou de l'audio et répond par du texte, de la parole, ou les deux. Le tableau des modèles n'est pas d'accord : les deux tags indiquent l'entrée comme « Text » et le contexte comme un tiret.

Cela mérite d’être pris au sérieux plutôt que d’être balayé comme une bizarrerie de rendu. Ollama prend en charge l’entrée audio depuis la v0.20, en avril 2026, lorsque Gemma 4 a apporté une capacité audio, une commande ollama transcribe et des parties input_audio de style OpenAI. La mécanique existe. Ce qui n’est pas confirmé, c’est si elle est raccordée pour ce checkpoint — l’étiquette audio est une déclaration de capacité, pas un résultat de test. Si votre plan commence par « envoyer un WAV dans Ollama », vérifiez-le avec un seul fichier avant de concevoir quoi que ce soit autour.

La sortie vocale présente la même configuration vue de l'autre côté. La fusion llama.cpp expose un indicateur de voix TTS ; la page d'Ollama ne documente aucun équivalent, et le readme décrit la sortie vocale comme une propriété du modèle plutôt que comme une fonctionnalité de la CLI. Inversez chaque phrase et la conclusion tient : le parcours terminal est aujourd'hui la moitié texte d'un modèle vocal. Le chat vocal full-duplex nécessite la voie Python ou llama.cpp.

Le tableau des scores publié par Liquid

Six chiffres, dont quatre ont une valeur précédente. Tous proviennent de la fiche modèle de Liquid, sans ensemble de test nommé, sans harnais et sans variance.

• ASR anglais, taux d’erreur de mots ↓ — 6,23 pour LFM3-Audio-2B contre 6,13 pour LFM2.5-Audio-1.5B. Stable, et la seule ligne qui n’a pas bougé.

• ASR multilingue, WER/CER ↓ — 6,03. Aucun chiffre pour le prédécesseur n’a été publié.

• TTS anglais, UTMOSv2 ↑ — 3,83 contre 3,22. Une progression importante ; 4,0 est généralement considéré comme le seuil quasi humain.

• VoiceBench ↑ — 73,13 contre 55,17.

• Compréhension audio, MMAR ↑ — 50,60 contre 25,85. Presque le double.

• Appel d’outils à partir de la parole, évaluation interne ↑ — 58.50. Aucun chiffre pour la version précédente.

Face au reste du champ de ce même tableau, il s’agit d’un bon petit modèle plutôt que d’un leader. Voxtral Mini 3B affiche un WER de 5,51 et NVIDIA Audex 2B affiche 5,99, tous deux meilleurs que 6,23. Qwen2.5-Omni 3B obtient 54,41 en compréhension audio, contre 50,60. Gemma 4 E4B obtient 72,40 en appel d’outils, contre 58,50, et la ligne de paramètres de Liquid place elle-même ce Gemma à 8B contre 2B pour ce modèle — le nom « E4B » compte les paramètres actifs, et non les paramètres totaux. Le résumé honnête : un ASR compétitif, une nette progression en sortie vocale et un raisonnement audio solide pour un 2B — sans détenir de record dans aucune colonne.

L’écart de 6,23 contre 6,13 se situe dans ce que produit le bruit d’échantillonnage et ne doit pas être interprété comme une régression. L’écart de 3,83 contre 3,22, lui, ne l’est pas — un mouvement UTMOS de 0,6 point sort largement de cette plage. L’interprétation défendable est que Liquid a consacré cette génération à la génération : une meilleure voix, un meilleur raisonnement audio et un front-end ASR qui a tenu bon alors que les encodeurs changeaient sous ses pieds. Nous n’avons trouvé aucune reproduction tierce d’une ligne que ce soit, alors considérez le classement comme une hypothèse jusqu’à ce que quelqu’un en publie une.

Pourquoi le codec survit au modèle

LiquidCodec est l’élément de cette version qui mérite d’être suivi au-delà du point de contrôle. Il compresse 80 ms de parole en 12 tokens discrets, décode vers 24 kHz avec prise en charge du streaming, et Liquid le mesure à environ 87× le temps réel sur un seul thread CPU d’un M4 Max. L’encodeur causal est ce qui permet le prefill pendant la parole plutôt qu’après, d’où provient le chiffre de « seulement 50 ms » pour le time-to-first-token.

Ces deux chiffres sont les éléments les plus cités et les moins reproductibles du lancement. Tous deux proviennent de mesures du fournisseur sur du matériel Apple nommément cité, sans banc d’essai, sans corpus audio et sans percentile. Ils décrivent un cas optimal. Un téléphone, un Raspberry Pi ou une VM x86 mutualisée ne les atteindront pas, et rien dans la publication ne précise ce qui sera atteint à la place.

La prise en charge des environnements d’exécution est inhabituellement étendue pour un modèle âgé d’un jour : Transformers 5.20.2 ou version ultérieure avec trust_remote_code, vLLM et SGLang pour le checkpoint BF16, llama.cpp pour GGUF, MLX 4-bit sur Apple silicon, ONNX Runtime pour la portabilité, et le fine-tuning sur un seul GPU. L’exigence de code personnalisé est le point à épingler. LFM3-Audio se charge depuis son propre module et lit les poids du codec dans un répertoire audio_tokenizer distinct, donc un environnement non épinglé est un ticket d’assistance qui n’attend que de se produire.

Parole locale face à un point de terminaison hébergé

La raison pour laquelle un modèle audio 2B de 2.1 GB est intéressant, c’est que l’alternative vous facture chaque seconde d’audio. L’auto-hébergement a un coût fixe — une machine que vous possédez déjà, un téléchargement, pas de facturation à la minute. Un point de terminaison hébergé a un coût marginal par token et aucune surface opérationnelle du tout.

Soyez précis sur ce que couvre chaque partie. La synthèse vocale hébergée — le type que nous acheminons, comme gpt-4o-mini-tts à 0,60 $ en entrée et 12,00 $ en sortie par million de tokens, ou gemini-2.5-flash-preview-tts à 0,50 $ et 10,00 $ — transforme le texte en parole et rien d’autre. LFM3-Audio-2B écoute aussi, transcrit et traduit, et fonctionne avec le réseau débranché. Ils résolvent deux moitiés différentes du même agent vocal.

LFM3-Audio-2B n'est pas disponible sur OrcaRouter. Les modèles audio que nous servons sont des points de terminaison vocaux hébergés, donc la répartition honnête pour un produit vocal ce mois-ci consiste en de la parole locale en entrée et en sortie avec le modèle Liquid, et tout ce qui concerne le texte derrière un seul point de terminaison pour plus de 200 modèles — 0 % de marge sur le prix catalogue du fournisseur, un basculement automatique en cas de défaillance d'un fournisseur, et un DSL de routage si vous voulez composer plusieurs modèles en un seul appel. C'est ce qui rend viable une configuration à deux exécutions : un contrat pour la moitié hébergée, un téléchargement pour la moitié locale.

Pour l'option locale, le coût n'est pas nul : 2,1 Go de poids, un processus à maintenir en vie et aucun SLA. Si l'audio ne quitte jamais le bâtiment, l'arbitrage est aisé. S'il en sort, le tarif de la version hébergée est suffisamment modeste pour que la charge opérationnelle tranche généralement la question.

Qui devrait s’en occuper cette semaine, et qui devrait attendre ?

Lancez-le si vous voulez une boucle vocale locale sur un ordinateur portable et pouvez vous contenter pour l’instant d’une sortie texte dans le terminal. Lancez-le si vous avez besoin d’une sortie vocale dans une langue où la voix hébergée dont vous disposez est faible ou coûteuse — dix-huit langues, c’est plus de couverture que n’en offrent la plupart des petits modèles TTS. Lancez-le si vous avez des enregistrements qui ne peuvent pas quitter la machine et voulez obtenir une transcription et un résumé à partir d’un seul modèle. Lancez-le si vous prototypes des appels d’outils vocaux et voulez le modèle sur la même machine que l’outil.

Attendez si la précision de l’ASR est le produit. Un taux d’erreur sur les mots de 6,23 est respectable et se place derrière trois modèles dans le propre tableau de Liquid. Attendez si vous avez besoin de transcription en streaming dès aujourd’hui — l’ASR en direct est une PR de suivi pour llama.cpp, et uniquement en anglais lorsqu’elle arrivera. Attendez si vous avez besoin que le modèle ait des connaissances : la fiche recommande la recherche documentaire et ne recommande explicitement pas le codage agentique ni le raisonnement multi-étapes à cette taille. Et attendez si vous avez besoin d’un SLA fournisseur, car la page de tarification de Liquid liste d1, d1-ultra et LFM2.5-24B-A2B et aucun point de terminaison audio LFM3 du tout.

Trois questions auxquelles le lancement ne répond pas

Le LFM3-Audio-2B est-il le même modèle que le LFM3-Omni-2B ?

Non. Ils partagent le backbone LFM3 et tous deux sont apparus dans la même pull request llama.cpp, mais Omni ajoute la vision par-dessus l'audio et constitue l'engagement le plus lourd des deux. Si la tâche est un appel téléphonique, un enregistrement de réunion ou une commande vocale, Audio est le plus petit modèle qui fait le plus petit travail. Si la tâche consiste à regarder quelque chose tout en l'écoutant, c'est la branche omni.

Peut-il transcrire un flux en direct ?

Pas encore via llama.cpp. Le merge indique que l’ASR en direct est une étape ultérieure, et la fiche modèle précise explicitement que l’ASR en direct est réservé à l’anglais, même une fois qu’il existera. La transcription par lots d’un enregistrement est la voie prise en charge aujourd’hui, avec 32 K tokens de contexte — soit à peu près la limite de longueur à anticiper pour les fichiers longs, puisque les tokens audio et les tokens texte partagent ce budget.

A-t-il besoin d'un GPU ?

Non, et c’est justement l’intérêt de la version GGUF. L’artefact Ollama de 2,1 Go s’exécute sur CPU. Le chiffre de 87× le temps réel mesure le codec, pas le modèle de langage ; ne l’interprétez donc pas comme une vitesse de bout en bout sur votre matériel. Apple silicon offre la voie la plus fluide via MLX ou la prise en charge fusionnée de llama.cpp ; sur x86, attendez-vous à ce que le décodage CPU soit le goulot d’étranglement, et mesurez avant de promettre un chiffre de latence à qui que ce soit.

Qu'est-ce qui changerait ce verdict

Trois signaux, par ordre de l’importance qu’ils auraient. Premièrement, l’arrivée du suivi ASR en direct dans llama.cpp — cela transforme un transcripteur par lots en quelque chose que l’on pourrait placer derrière un microphone, ce qui est le cas d’usage que la plupart des gens veulent réellement. Deuxièmement, une évaluation WER indépendante sur un ensemble standard ; tant qu’il n’en existe pas, la seule chose qui garantit l’honnêteté de l’ASR de ce modèle est un tableau fournisseur le comparant au modèle précédent du même fournisseur. Troisièmement, un tarif d’API publié pour la branche audio, qui nous dirait si Liquid compte vendre l’écoute comme un service ou la conserver comme une offre de poids.

D’ici là, la description exacte est étroite et utile : un modèle vocal 2B que l’on peut télécharger en une minute, qui parle mieux que le modèle qu’il remplace, écoute à peu près aussi bien, et n’a encore aucun témoin indépendant. Pour un prototype sur un ordinateur portable, cela suffit. Pour une chaîne de transcription en production, non — et l’écart entre ces deux phrases correspond exactement à la distance entre un lancement et une évaluation.