LFM3-Audio-2B op Ollama: betere spraak, dezelfde oren

Liquid AI's LFM3-Audio-2B is vanmorgen een download met één commando geworden. ollama run lfm3-audio haalt 2,1 GB binnen en start een model met 2B parameters dat tekst of audio aanneemt en antwoordt in tekst, 24 kHz spraak, of beide. Het model zelf is een dag oud — het verscheen op 27 oktober 2026, binnen de LFM3-familie van zes modellen. Wat nieuw is op 28 oktober, is de levering, en het eerste dat de moeite waard is om te weten, staat in Liquid's eigen benchmarktabel: vergeleken met LFM2.5-Audio-1.5B dat het vervangt, nam de spraakkwaliteit sterk toe, verdubbelde het audiobegrip bijna, en ging de Engelse spraakherkenning helemaal niet vooruit.

De rest van dit stuk scheidt wat vandaag controleerbaar is van wat niet. De audiotak kreeg één alinea van een blogpost over de familie en een modelkaart — er is geen aparte aankondiging "Introducing LFM3-Audio" — en we konden nergens een onafhankelijke benchmarkrun van dit model vinden. Elk getal hieronder is van Liquid, tenzij de zin anders vermeldt.

Wat er is uitgebracht, en hoe mager de aankondiging was

{{1}}Liquid's post van 27 oktober{{/1}}, {{2}}"Introductie van LFM3: elke modaliteit voor gespecialiseerde intelligentie"{{/2}}, kondigde zes modellen uit de 2B-klasse aan, getraind op basis van {{3}}LFM3-1.7B-Base{{/3}}: tekst, visie, audio, omni en twee beslissingsmodellen die zijn gespecialiseerd vanuit de {{4}}visie{{/4}}- en {{5}}omni{{/5}}-takken. {{6}}Audio{{/6}} is een van de vier modaliteitstakken en krijgt één alinea — de {{7}}UTMOSv2{{/7}}-verbetering, de {{8}}50 ms{{/8}} time-to-first-token-waarde, de {{9}}87×{{/9}} real-time codec. Er is geen {{10}}audio-specifieke post{{/10}}, geen {{11}}audio-benchmarkblog{{/11}} en geen {{12}}prijsvermelding{{/12}} voor welk {{13}}LFM3{{/13}}-model dan ook op {{14}}Liquid's prijspagina{{/14}}.

Drie artefacten plaatsten het model deze week voor een lezer:

• Gewichten — LiquidAI/LFM3-Audio-2B op Hugging Face, onder de LFM Open License v1.0, met een modelkaart die de volledige vergelijkingstabel bevat.

• llama.cpp — PR #31257, samengevoegd op 27 oktober, voegt LFM3-Audio-2B en LFM3-Omni-2B toe. Het houdt de convoluties van de audio-encoder en de codec ongekwantiseerd, biedt via een TTS-vlag een mannen- of vrouwenstem aan, en markeert live-ASR als een vervolg-PR in plaats van als onderdeel van de merge.

• Ollama — lfm3-audio, 2,1 GB, tags latest en 2b, met 19 downloads en "een uur geleden bijgewerkt" op het moment van vastleggen. De paginakop vermeldt vijf modellen; er zijn twee rijen gepubliceerd.

De Ollama-vermelding is degene die er het meest toe doet, omdat het de enige route is die niet begint met het lezen van een modelkaart. Die kwam ook zonder enige aankondiging — geen bericht, geen changelog, niets op de kaart van het model zelf dat erop wees.

Het specificatieblad, inclusief de figuur die bijna iedereen verkeerd overnam

• Parameters — 2B in totaal, op de LFM3-backbone met een intern ontwikkelde causale audio-encoder en de LiquidCodec-tokenizer

• Invoer — tekst, of audio gesampled op 16 kHz

• Uitvoer — tekst, 24 kHz-spraak, of verweven tekst en spraak

• Context — 32K tokens voor invoer plus uitvoer. Dit is niet het 256K-cijfer dat in de berichtgeving rond de lancering wordt herhaald: dat hoort bij LFM3-1.7B, het tekstmodel. De eigen pagina van de audiotak zegt 32K.

Talen — 18, vermeld als 19 locales omdat Engels twee keer voorkomt, als Britse en Amerikaanse variant. Live-ASR is alleen Engels; vertaling is het sterkst van en naar het Engels.

• Licentie — LFM Open License v1.0, gratis voor commercieel gebruik onder $10M jaaromzet, met een betaalde commerciële licentie boven die drempel.

• Voetafdruk — 2,1 GB als de Ollama-build.

Twee van die rijen verdienen het om even bij stil te staan. Het contextnummer is het nummer dat een samenvatting maandenlang verkeerd zal hebben, omdat de familiepost met 256K begint en de audiokaart stilletjes 32K vermeldt. En het aantal talen is een verkapt aantal locales: negentien vermeldingen, achttien talen, waarbij de twee Engelse varianten het extra werk doen. Geen van beide is een schandaal, en beide veranderen wat je een gebruiker zou beloven.

Eén commando, en het veld dat de kaart tegenspreekt

ollama run lfm3-audio is echt de complete setup. De pagina voorziet het model van de tags tools, audio en 2b, en de readme direct boven de modeltabel zegt dat het tekst of audio accepteert en reageert met tekst, spraak of beide. De modeltabel spreekt dat tegen: beide tags vermelden de invoer als "Text" en de context als een streepje.

Dat is het serieus nemen waard, in plaats van het af te doen als een weergavefout. Ollama ondersteunt audio-invoer sinds v0.20 in april 2026, toen Gemma 4 een audiomogelijkheid, een commando ollama transcribe en OpenAI-achtige input_audio-onderdelen introduceerde. De machinerie bestaat. Wat niet bevestigd is, is of die voor dit checkpoint is aangesloten — de audiotag is een capaciteitsclaim, geen testresultaat. Als je plan begint met "een WAV naar Ollama pipen", verifieer het dan met één bestand voordat je eromheen gaat ontwerpen.

Spraakuitvoer heeft vanaf de andere kant dezelfde vorm. De llama.cpp-merge biedt een TTS-stemvlag; de pagina van Ollama documenteert geen equivalent, en de readme beschrijft spraakuitvoer als een eigenschap van het model in plaats van een functie van de CLI. Draai elke zin om en de conclusie blijft gelden: het terminalpad is vandaag de teksthelft van een spraakmodel. Full-duplex spraakchat vereist de Python- of llama.cpp-route.

Het scorebord dat Liquid publiceerde

Zes getallen, waarvan vier een voorgangerwaarde hebben. Ze komen allemaal van Liquid's model card, zonder genoemde testset, zonder harness en zonder variantie.

• Engelse ASR, woordfoutpercentage ↓ — 6,23 voor LFM3-Audio-2B tegenover 6,13 voor LFM2.5-Audio-1.5B. Vlak, en de enige rij die niet veranderde.

• Meertalige ASR, WER/CER ↓ — 6,03. Geen voorgaand cijfer gepubliceerd.

• Engelse TTS, UTMOSv2 ↑ — 3,83 tegen 3,22. Een grote sprong; 4,0 wordt gewoonlijk beschouwd als de grens voor bijna-menselijke kwaliteit.

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

• Audiobegrip, MMAR ↑ — 50,60 tegen 25,85. Bijna een verdubbeling.

• Tool calling op basis van spraak, interne evaluatie ↑ — 58,50. Geen voorgaand cijfer.

Vergeleken met de rest van het veld in diezelfde tabel is het een goed klein model, geen koploper. Voxtral Mini 3B scoort 5,51 WER en NVIDIA Audex 2B scoort 5,99, beide beter dan 6,23. Qwen2.5-Omni 3B behaalt 54,41 op audioverstaan tegenover 50,60. Gemma 4 E4B behaalt 72,40 op tool calling tegenover 58,50, en Liquid's eigen parameterrij zet die Gemma op 8B tegenover 2B voor dit model — de naam "E4B" telt actieve parameters, niet het totaal. De eerlijke samenvatting is competitieve ASR, een duidelijke stap vooruit in stemoutput en solide audioreasoning voor 2B — geen recordhouder in welke kolom dan ook.

Het verschil van 6,23 tegen 6,13 valt binnen wat steekproefruis oplevert en mag niet als een regressie worden gelezen. Het verschil van 3,83 tegen 3,22 is dat niet — een UTMOS-verschuiving van 0,6 punt valt ver buiten dat bereik. De verdedigbare lezing is dat Liquid deze generatie aan generatie heeft besteed: betere stem, betere audio-reasoning en een ASR-front-end die standhield terwijl de encoders eronder veranderden. We vonden geen reproductie door derden van enige rij, dus behandel de rangorde als een hypothese tot iemand er een publiceert.

Waarom de codec het model overleeft

LiquidCodec is het onderdeel van deze release dat de moeite waard is om verder te bekijken dan de checkpoint. Het verpakt 80 ms spraak in 12 discrete tokens, decodeert terug naar 24 kHz met streamingondersteuning, en Liquid meet het op ongeveer 87× realtime op één CPU-thread van een M4 Max. De causale encoder zorgt ervoor dat prefill tijdens de spraak kan plaatsvinden in plaats van erna, en daar komt het cijfer van 'slechts 50 ms' voor tijd-tot-eerste-token vandaan.

Die twee getallen zijn de meest geciteerde en minst reproduceerbare zaken bij de lancering. Beide zijn leveranciersmetingen op specifiek genoemde Apple-hardware, zonder testharnas, zonder audioset en zonder percentiel. Ze beschrijven een bestcasescenario. Een telefoon, een Raspberry Pi of een gedeelde x86-VM zullen die niet halen, en niets in de release zegt wat ze in plaats daarvan wel zullen halen.

De runtime-ondersteuning is ongewoon breed voor een model van één dag oud: Transformers 5.20.2 of nieuwer met trust_remote_code, vLLM en SGLang voor het BF16-checkpoint, llama.cpp voor GGUF, MLX 4-bit op Apple-silicon, ONNX Runtime voor draagbaarheid, en fine-tuning op één GPU. De vereiste voor aangepaste code is het punt dat je moet vastpinnen. LFM3-Audio laadt vanuit zijn eigen module en leest codec-gewichten uit een aparte map audio_tokenizer, dus een omgeving zonder vastgepinde versies is een supportticket dat staat te wachten om te gebeuren.

Lokale spraak versus een gehoste endpoint

De reden dat een 2B-audiomodel van 2,1 GB interessant is, is dat het alternatief je voor elke seconde audio factureert. Zelf hosten heeft vaste kosten — een machine die je al bezit, een download, geen meting per minuut. Een gehost endpoint heeft marginale kosten per token en helemaal geen operationeel oppervlak.

Wees precies over wat elke kant dekt. Gehoste tekst-naar-spraak — het soort dat wij routeren, zoals gpt-4o-mini-tts tegen $0.60 in en $12.00 out per miljoen tokens, of gemini-2.5-flash-preview-tts tegen $0.50 en $10.00 — zet tekst om in spraak en niets anders. LFM3-Audio-2B luistert ook, transcribeert en vertaalt, en werkt met het netwerk losgekoppeld. Ze lossen verschillende helften van dezelfde spraakagent op.

LFM3-Audio-2B staat niet op OrcaRouter. De audiomodellen die we aanbieden zijn gehoste spraakeindpunten, dus de eerlijke opsplitsing voor een spraakproduct deze maand is lokale spraak in en uit met het Liquid-model, en alles aan de tekstkant achter één eindpunt voor meer dan 200 modellen — 0% opslag op de lijstprijs van de provider, automatische failover wanneer een provider hapert, en een routing-DSL als je meerdere modellen in één aanroep wilt samenbrengen. Dat is wat een opstelling met twee runtimes levensvatbaar maakt: één contract voor de gehoste helft, één download voor de lokale helft.

Voor de lokale helft is de kostprijs niet nul: 2,1 GB aan gewichten, een proces dat in leven moet blijven en geen SLA. Als de audio het gebouw nooit verlaat, is die afweging makkelijk. Als dat wel gebeurt, is de prijs van de gehoste versie klein genoeg dat de operationele last meestal de kwestie beslist.

Wie moet het deze week doen, en wie moet wachten?

Draai het als je een lokale spraakloop op een laptop wilt en voorlopig kunt leven met tekstuitvoer in de terminal. Draai het als je spraakuitvoer nodig hebt in een taal waarin de gehoste stem die je hebt zwak of duur is — achttien talen is meer dekking dan de meeste kleine TTS-modellen bieden. Draai het als je opnamen hebt die de machine niet mogen verlaten en je transcriptie plus een samenvatting uit één model wilt. Draai het als je gesproken tool-aanroepen aan het prototypen bent en het model op dezelfde machine als de tool wilt.

Wacht even als ASR-nauwkeurigheid het product is. Een woordfoutpercentage van 6,23 is respectabel en staat achter drie modellen in Liquid's eigen tabel. Wacht even als je vandaag streamingtranscriptie nodig hebt — live ASR is een vervolg-PR voor llama.cpp, en alleen Engels wanneer die er komt. Wacht even als je wilt dat het model dingen weet: de modelkaart raadt retrieval aan en raadt agentic coding of meerstapsredenering op deze grootte expliciet af. En wacht even als je een leveranciers-SLA nodig hebt, want Liquid's prijspagina vermeldt d1, d1-ultra en LFM2.5-24B-A2B en helemaal geen LFM3-audio-endpoint.

Drie vragen die de lancering niet beantwoordt

Is LFM3-Audio-2B hetzelfde model als LFM3-Omni-2B?

Nee. Ze delen de LFM3-backbone en beide verschenen in dezelfde llama.cpp pull request, maar Omni voegt visie toe bovenop audio en is van de twee de grotere investering. Als het om een telefoongesprek, een vergaderopname of een spraakcommando gaat, is Audio het kleinere model voor de kleinere taak. Als de taak inhoudt dat je naar iets kijkt terwijl je ernaar luistert, dan is dat de omni-tak.

Kan het een livestream transcriberen?

Nog niet via llama.cpp. De merge markeert live-ASR als een vervolgstap, en de modelkaart is expliciet dat live-ASR alleen Engels is, zelfs zodra het bestaat. Batchtranscriptie van een opname is vandaag de ondersteunde route, met 32K tokens context — ongeveer de lengtelimiet om voor lange bestanden rekening mee te houden, aangezien audiotokens en teksttokens dat budget delen.

Heeft het een GPU nodig?

{{1}}Nee, en dat is juist het punt van de GGUF-build.{{/1}} {{2}}Het Ollama-artefact van 2,1 GB draait op de CPU.{{/2}} {{3}}Wat de realtimefactor van 87× meet, is de codec, niet het taalmodel, dus lees het niet als end-to-end-snelheid op jouw hardware.{{/3}} {{4}}Apple silicon heeft het soepelste pad via MLX of de samengevoegde llama.cpp-ondersteuning; op x86 moet je verwachten dat CPU-decodering de bottleneck is, en meet voordat je iemand een latentiegetal belooft.{{/4}}

Wat zou deze uitspraak veranderen?

Drie signalen, in volgorde van hoe belangrijk ze zouden zijn. Ten eerste: de live-ASR-follow-up die in llama.cpp landt — dat verandert een batchtranscriber in iets dat je achter een microfoon kunt zetten, en dat is de use case die de meeste mensen eigenlijk willen. Ten tweede: een onafhankelijke WER-run op een standaardset; totdat die bestaat, is het enige dat de ASR van dit model eerlijk houdt een leverancierstabel die het vergelijkt met het eigen vorige model van de leverancier. Ten derde: een gepubliceerde API-prijs voor de audiotak, die ons zou vertellen of Liquid luisteren als dienst wil verkopen of het een weights-play wil laten blijven.

Tot dan is de nauwkeurige beschrijving beperkt en nuttig: een 2B-spraakmodel dat je in een minuut kunt downloaden, dat beter praat dan het model dat het vervangt, ongeveer even goed luistert en nog geen onafhankelijke getuigen heeft. Voor een prototype op een laptop is dat genoeg. Voor een productie-transcriptiepijplijn niet — en de kloof tussen die twee zinnen is precies de afstand tussen een lancering en een evaluatie.