LFM3-Audio-2B på Ollama: Bättre tal, samma öron

Liquid AI:s LFM3-Audio-2B blev en nedladdning med ett enda kommando i morse. ollama run lfm3-audio hämtar 2,1 GB och startar en modell med 2B parametrar som tar emot text eller ljud och svarar med text, 24 kHz-tal eller båda. Själva modellen är en dag gammal – den släpptes den 27 oktober 2026 inom LFM3-familjen med sex modeller. Det nya den 28 oktober är leveransen, och det första man bör känna till finns i Liquid:s egen benchmarktabell: mot LFM2.5-Audio-1.5B som den ersätter, steg talkvaliteten kraftigt, ljudförståelsen nästan fördubblades och engelsk taligenkänning förbättrades inte alls.

Resten av den här artikeln skiljer det som går att kontrollera i dag från det som inte gör det. Audio-grenen fick ett stycke av ett familjeblogginlägg och ett modellkort — det finns inget eget "Introducing LFM3-Audio"-meddelande — och vi kunde inte hitta någon oberoende benchmarkkörning av den här modellen någonstans. Alla siffror nedan är Liquids om inte meningen säger något annat.

Vad som släpptes, och hur tunt tillkännagivandet var

Liquids inlägg den 27 oktober, ”Introducerar LFM3: alla modaliteter för specialiserad intelligens”, tillkännagav sex modeller i 2B-klassen som tränats från LFM3-1.7B-Base: text, vision, ljud, omni och två beslutsmodeller specialiserade från vision- och omnigrenarna. Ljud är en av fyra modalitetsgrenar och får ett enda stycke – UTMOSv2-förbättringen, siffran 50 ms till första token, codec i 87× realtid. Det finns inget ljudspecifikt inlägg, inget blogginlägg om ljudbenchmark och ingen prisuppgift för någon LFM3-modell på Liquids prissida.

Tre artefakter placerade modellen framför en läsare den här veckan:

• Vikter — LiquidAI/LFM3-Audio-2B på Hugging Face, under LFM Open License v1.0, med ett modellkort som innehåller den fullständiga jämförelsetabellen.

• llama.cpp — PR #31257, sammanfogad 27 oktober, lägger till LFM3-Audio-2B och LFM3-Omni-2B. Den behåller ljudkodarens faltningar och codec okvantiserade, exponerar en manlig eller kvinnlig röst via en TTS-flagga och markerar live-ASR som en uppföljande PR i stället för som en del av sammanslagningen.

• Ollama — lfm3-audio, 2,1 GB, taggarna latest och 2b, visar 19 nedladdningar och "uppdaterad för en timme sedan" vid tidpunkten för avbildningen. Sidhuvudet säger fem modeller; två rader är publicerade.

Ollama-listningen är den som betyder mest, eftersom det är den enda vägen som inte börjar med att läsa ett modellkort. Den dök också upp helt utan något slags tillkännagivande – inget inlägg, ingen ändringslogg, ingenting på modellens eget kort som pekade på den.

Databladet, inklusive figuren som nästan alla kopierade fel

• Parametrar – 2B totalt, på LFM3-stommen med en egenutvecklad kausal ljudkodare och LiquidCodec-tokeniseraren

• Indata — text eller ljud samplat vid 16 kHz

• Utdata – text, 24 kHz-tal eller interfolierad text och tal

• Kontext – 32K token som omfattar indata plus utdata. Det här är inte den 256K-siffra som upprepas i lanseringsrapporteringen: den tillhör LFM3-1.7B, textmodellen. Ljudgrenens egen sida anger 32K.

• Språk – 18, listade som 19 språkvarianter eftersom engelska förekommer två gånger, som brittisk och amerikansk variant. Live-ASR är endast på engelska; översättningen är starkast till eller från engelska.

• Licens — LFM Open License v1.0, gratis för kommersiell användning under 10 miljoner USD i årlig omsättning, med en betald kommersiell licens över den tröskeln.

• Fotavtryck — 2,1 GB som Ollama-bygget.

Två av de raderna förtjänar en paus. Kontextnumret är det som en sammanfattning kommer att få fel i månader, eftersom familjeinlägget inleder med 256K och ljudkortet i tysthet anger 32K. Och språkantalet är ett lokalantal i förklädnad: nitton poster, arton språk, där engelskans två varianter gör extrajobbet. Inget av dem är en skandal, och båda förändrar vad du skulle lova en användare.

Ett kommando, och fältet som motsäger kortet

ollama run lfm3-audio är verkligen hela uppsättningen. Sidan märker modellen med tools, audio och 2b, och readme-filen direkt ovanför modelltabellen säger att den tar emot text eller ljud och svarar med text, tal eller båda. Modelltabellen säger emot: båda taggarna anger indata som "Text" och kontexten som ett streck.

Det är värt att ta på allvar i stället för att avfärda det som en renderingskonstighet. Ollama har stött ljudinmatning sedan v0.20 i april 2026, då Gemma 4 medförde en ljudkapacitet, ett ollama transcribe-kommando och input_audio-delar i OpenAI-stil. Maskineriet finns. Det som inte är bekräftat är om det är kopplat för denna checkpoint – ljudtaggen är ett kapabilitetspåstående, inte ett testresultat. Om din plan börjar med "skicka en WAV till Ollama", verifiera det med en fil innan du designar utifrån det.

Talutdata har samma form från andra hållet. llama.cpp-sammanslagningen exponerar en TTS-röstflagga; Ollamas sida dokumenterar ingen motsvarighet, och readme-filen beskriver talutdata som en egenskap hos modellen snarare än en funktion i CLI:t. Vänd på varje mening och slutsatsen håller: terminalvägen är i dag textdelen av en talmodell. Röstchatt i full duplex kräver Python- eller llama.cpp-vägen.

Resultattavlan som Liquid publicerade

Sex siffror, varav fyra har ett föregångarvärde. Alla kommer från Liquids modellkort, utan namngiven testuppsättning, utan testramverk och utan varians.

• Engelsk ASR, ordfelsfrekvens ↓ — 6,23 för LFM3-Audio-2B mot 6,13 för LFM2.5-Audio-1.5B. Oförändrat, och den enda raden som inte rörde sig.

• Flerspråkig ASR, WER/CER ↓ — 6,03. Ingen siffra för föregångaren har publicerats.

• Engelsk TTS, UTMOSv2 ↑ — 3,83 mot 3,22. Ett stort steg; 4,0 betraktas vanligtvis som gränsen för nära mänsklig nivå.

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

• Ljudförståelse, MMAR ↑ — 50,60 mot 25,85. Nästan dubbelt.

• Verktygsanrop från tal, intern utvärdering ↑ — 58.50. Ingen tidigare siffra.

Jämfört med resten av fältet i samma tabell är det en bra liten modell snarare än en ledare. Voxtral Mini 3B noterar 5,51 WER och NVIDIA Audex 2B noterar 5,99, båda bättre än 6,23. Qwen2.5-Omni 3B tar ljudförståelse på 54,41 mot 50,60. Gemma 4 E4B tar verktygsanrop på 72,40 mot 58,50, och Liquid:s egen parameterrad placerar den Gemman på 8B mot den här modellens 2B – namnet "E4B" räknar aktiva parametrar, inte totala. Den ärliga sammanfattningen är konkurrenskraftig ASR, ett tydligt steg upp i röstutdata och solid ljudresonemang för 2B – inte någon rekordhållare i någon kolumn.

Gapet mellan 6,23 och 6,13 ligger inom det som samplingsbrus kan åstadkomma och bör inte tolkas som en regression. Gapet mellan 3,83 och 3,22 är det inte – en förflyttning på 0,6 poäng i UTMOS ligger långt utanför det intervallet. Den försvarbara tolkningen är att Liquid lade den här generationen på generation: bättre röst, bättre ljudresonemang och en ASR-frontend som höll ställningen medan encodrarna förändrades under den. Vi hittade ingen tredjepartsreproduktion av någon rad, så behandla ordningen som en hypotes tills någon publicerar en.

Varför kodeken överlever modellen

LiquidCodec är den del av den här utgåvan som är värd att uppmärksamma utöver checkpointen. Den packar 80 ms tal i 12 diskreta tokens, avkodar tillbaka till 24 kHz med stöd för strömning, och Liquid mäter den till cirka 87× realtid på en enda CPU-tråd på en M4 Max. Den kausala kodaren är det som gör att prefill kan ske under talet i stället för efter det, vilket är där siffran "så låg som 50 ms" för time-to-first-token kommer ifrån.

De två siffrorna är det mest citerade och minst reproducerbara i lanseringen. Båda är leverantörsmätningar på namngiven Apple-hårdvara, utan testramverk, utan ljudset och utan percentil. De beskriver ett bästa fall. En telefon, en Raspberry Pi eller en delad x86-VM kommer inte att nå dem, och ingenting i utgivningen säger vad den i stället kommer att nå.

Körtidsstödet är ovanligt brett för en modell som bara är en dag gammal: Transformers 5.20.2 eller nyare med trust_remote_code, vLLM och SGLang för BF16-checkpointen, llama.cpp för GGUF, MLX 4-bit på Apple silicon, ONNX Runtime för portabilitet och finjustering på en enda GPU. Kravet på anpassad kod är det man måste låsa. LFM3-Audio läses in från sin egen modul och läser codec-vikter ur en separat audio_tokenizer-katalog, så en miljö utan låsta versioner är ett supportärende som bara väntar på att inträffa.

Lokalt tal mot en hostad slutpunkt

Anledningen till att en 2B-ljudmodell på 2,1 GB är intressant är att alternativet fakturerar dig för varje sekund ljud. Självhosting har en fast kostnad – en maskin du redan äger, en nedladdning, ingen mätning per minut. En hostad slutpunkt har en marginell kostnad per token och ingen operativ yta alls.

Var noga med att precisera vad varje sida omfattar. Hostad text-till-tal – den typ vi routar, till exempel gpt-4o-mini-tts till $0.60 in och $12.00 ut per miljon tokens, eller gemini-2.5-flash-preview-tts till $0.50 och $10.00 – omvandlar text till tal och inget annat. LFM3-Audio-2B lyssnar också, transkriberar och översätter, och körs med nätverket urkopplat. De löser varsin halva av samma röstagent.

LFM3-Audio-2B finns inte på OrcaRouter. Ljudmodellerna vi tillhandahåller är hostade taländpunkter, så den ärliga uppdelningen för en röstprodukt den här månaden är lokal tal in och ut med Liquid-modellen, och allt på textsidan bakom en slutpunkt för 200+ modeller – 0 % påslag på leverantörens listpris, automatisk failover när en leverantör strular, och en routing-DSL om du vill kombinera flera modeller i ett enda anrop. Det är det som gör en uppsättning med två körtider hållbar: ett avtal för den hostade halvan, en nedladdning för den lokala halvan.

För den lokala delen är kostnaden inte noll: 2,1 GB vikter, en process som måste hållas vid liv och ingen SLA. Om ljudet aldrig lämnar byggnaden är den avvägningen enkel. Om det gör det är priset för den hostade lösningen litet nog att den operativa bördan vanligtvis avgör frågan.

Vem bör köra det den här veckan, och vem bör vänta

Kör det om du vill ha en lokal röstslinga på en laptop och kan leva med textutdata i terminalen tills vidare. Kör det om du behöver talutdata på ett språk där den hostade röst du har är svag eller dyr — arton språk är större täckning än de flesta små TTS-modeller erbjuder. Kör det om du har inspelningar som inte får lämna maskinen och vill få transkription plus en sammanfattning från en enda modell. Kör det om du prototypar talade verktygsanrop och vill ha modellen på samma maskin som verktyget.

Vänta om ASR-noggrannhet är produkten. En ordfelsfrekvens på 6,23 är respektabel och ligger efter tre modeller i Liquids egen tabell. Vänta om du behöver strömmande transkribering i dag – live-ASR är en uppföljande llama.cpp-PR, och endast engelska när den väl finns. Vänta om du behöver att modellen kan saker: modellkortet rekommenderar retrieval och avråder uttryckligen från agentisk kodning eller resonemang i flera steg i den här storleken. Och vänta om du behöver ett leverantörs-SLA, eftersom Liquids prissida listar d1, d1-ultra och LFM2.5-24B-A2B och ingen LFM3-ljudendpoint alls.

Tre frågor som lanseringen inte besvarar

Är LFM3-Audio-2B samma modell som LFM3-Omni-2B?

Nej. De delar LFM3-stommen och båda dök upp i samma llama.cpp-pull request, men Omni lägger till vision ovanpå ljud och är den större satsningen av de två. Om jobbet är ett telefonsamtal, en mötesinspelning eller ett röstkommando är Audio den mindre modellen som gör det mindre jobbet. Om jobbet innebär att titta på något medan man lyssnar på det, är det omni-grenen.

Kan den transkribera en livestream?

Inte via llama.cpp ännu. Sammanslagningen markerar live-ASR som en uppföljning, och modellkortet är tydligt med att live-ASR endast är på engelska även när det väl finns. Batchtranskribering av en inspelning är den väg som stöds i dag, med 32K token kontext – ungefär den längdgräns man bör planera för vid långa filer, eftersom ljudtoken och texttoken delar den budgeten.

Behöver det ett grafikkort?

Nej, och det är poängen med GGUF-bygget. Ollama-artefakten på 2,1 GB körs på CPU. Det som siffran 87× realtid mäter är kodeken, inte språkmodellen, så tolka det inte som end-to-end-hastighet på din hårdvara. Apple silicon har den smidigaste vägen via MLX eller det sammanslagna llama.cpp-stödet; på x86 bör du räkna med att CPU-avkodning är flaskhalsen, och mät innan du lovar någon en latenssiffra.

Vad skulle ändra denna dom?

Tre signaler, i ordning efter hur mycket de skulle spela roll. Först: att live-ASR-uppföljningen landar i llama.cpp – det förvandlar en batchtranskriberare till något man kan sätta bakom en mikrofon, vilket är det användningsfall de flesta faktiskt vill ha. För det andra: en oberoende WER-körning på ett standarddataset; tills en sådan finns är det enda som håller den här modellens ASR ärlig en leverantörstabell som jämför den med leverantörens egen tidigare modell. För det tredje: ett publicerat API-pris för ljuddelen, vilket skulle säga oss om Liquid avser att sälja lyssnande som en tjänst eller behålla det som en satsning på modellvikter.

Fram till dess är den korrekta beskrivningen snäv och användbar: en 2B-talmodell som du kan ladda ner på en minut, som talar bättre än modellen den ersätter, lyssnar ungefär lika bra och ännu inte har några oberoende vittnen. För en prototyp på en bärbar dator räcker det. För en produktionspipeline för transkription gör det inte det — och gapet mellan de två meningarna är exakt avståndet mellan en lansering och en utvärdering.