LFM3-Audio-2B on Ollama: Better Speech, the Same Ears

Liquid AI's LFM3-Audio-2B became a one-command download this morning. ollama run lfm3-audio pulls 2.1 GB and starts a 2B-parameter model that takes text or audio and answers in text, 24 kHz speech, or both. The model itself is a day old — it shipped on October 27, 2026, inside the six-model LFM3 family. What is new on October 28 is delivery, and the first thing worth knowing sits in Liquid's own benchmark table: against the LFM2.5-Audio-1.5B it replaces, speech quality rose sharply, audio understanding nearly doubled, and English speech recognition did not improve at all.

The rest of this piece separates what is checkable today from what is not. The audio branch got one paragraph of a family blog post and a model card — there is no "Introducing LFM3-Audio" announcement of its own — and we could find no independent benchmark run of this model anywhere. Every number below is Liquid's unless the sentence says otherwise.

What shipped, and how thin the announcement was

Liquid's October 27 post, "Introducing LFM3: Every Modality for Specialized Intelligence", announced six 2B-class models trained from LFM3-1.7B-Base: text, vision, audio, omni, and two decision models specialised from the vision and omni branches. Audio is one of four modality branches and gets a single paragraph — the UTMOSv2 improvement, the 50 ms time-to-first-token figure, the 87× real-time codec. There is no audio-specific post, no audio benchmark blog, and no pricing entry for any LFM3 model on Liquid's pricing page.

Three artefacts put the model in front of a reader this week:

• Weights — LiquidAI/LFM3-Audio-2B on Hugging Face, under the LFM Open License v1.0, with a model card that carries the full comparison table.

• llama.cpp — PR #31257, merged October 27, adds LFM3-Audio-2B and LFM3-Omni-2B. It keeps the audio encoder convolutions and the codec unquantized, exposes a male or female voice through a TTS flag, and marks live ASR as a follow-up PR rather than part of the merge.

• Ollama — lfm3-audio, 2.1 GB, tags latest and 2b, showing 19 downloads and "updated an hour ago" at the time of capture. The page header says five models; two rows are published.

The Ollama listing is the one that matters most, because it is the only route that does not begin with reading a model card. It also arrived without an announcement of any kind — no post, no changelog, nothing on the model's own card pointing at it.

The spec sheet, including the figure almost everyone copied wrong

• Parameters — 2B total, on the LFM3 backbone with an in-house causal audio encoder and the LiquidCodec tokenizer

• Input — text, or audio sampled at 16 kHz

• Output — text, 24 kHz speech, or interleaved text and speech

• Context — 32K tokens covering input plus output. This is not the 256K figure being repeated in launch coverage: that belongs to LFM3-1.7B, the text model. The audio branch's own page says 32K.

• Languages — 18, listed as 19 locales because English appears twice, as British and American variants. Live ASR is English-only; translation is strongest to or from English.

• Licence — LFM Open License v1.0, free for commercial use below $10M annual revenue, with a paid commercial licence above that threshold.

• Footprint — 2.1 GB as the Ollama build.

Two of those rows deserve a pause. The context number is the one a summary will get wrong for months, because the family post leads with 256K and the audio card quietly says 32K. And the language count is a locale count in disguise: nineteen entries, eighteen languages, with English's two variants doing the extra work. Neither is a scandal, and both change what you would promise a user.

One command, and the field that contradicts the card

ollama run lfm3-audio is genuinely the whole setup. The page tags the model tools, audio and 2b, and the readme directly above the model table says it takes text or audio and responds with text, speech, or both. The model table disagrees: both tags list the input as "Text" and the context as a dash.

That is worth taking seriously rather than dismissing as a rendering quirk. Ollama has supported audio input since v0.20 in April 2026, when Gemma 4 brought an audio capability, an ollama transcribe command and OpenAI-style input_audio parts. The machinery exists. What is unconfirmed is whether it is wired for this checkpoint — the audio tag is a capability claim, not a test result. If your plan starts with "pipe a WAV into Ollama", verify it with one file before you design around it.

Speech output has the same shape from the other side. The llama.cpp merge exposes a TTS voice flag; Ollama's page documents no equivalent, and the readme describes speech output as a property of the model rather than a feature of the CLI. Flip every sentence around and the conclusion holds: the terminal path today is the text half of a speech model. Full-duplex voice chat needs the Python or llama.cpp route.

The scoreboard Liquid published

Six numbers, four of which have a predecessor value. All of them come from Liquid's model card, with no named test set, no harness and no variance.

• English ASR, word error rate ↓ — 6.23 for LFM3-Audio-2B against 6.13 for LFM2.5-Audio-1.5B. Flat, and the only row that did not move.

• Multilingual ASR, WER/CER ↓ — 6.03. No predecessor figure published.

• English TTS, UTMOSv2 ↑ — 3.83 against 3.22. A large move; 4.0 is usually treated as the near-human line.

• VoiceBench ↑ — 73.13 against 55.17.

• Audio understanding, MMAR ↑ — 50.60 against 25.85. Nearly double.

• Tool calling from speech, internal eval ↑ — 58.50. No predecessor figure.

Against the rest of the field in that same table, it is a good small model rather than a leader. Voxtral Mini 3B posts 5.51 WER and NVIDIA Audex 2B posts 5.99, both better than 6.23. Qwen2.5-Omni 3B takes audio understanding at 54.41 against 50.60. Gemma 4 E4B takes tool calling at 72.40 against 58.50, and Liquid's own parameter row puts that Gemma at 8B against this model's 2B — the "E4B" name counts active parameters, not total ones. The honest summary is competitive ASR, a clear step up in voice output, and solid audio reasoning for 2B — not a record holder in any column.

The 6.23 against 6.13 gap is within what sampling noise produces and should not be read as a regression. The 3.83 against 3.22 gap is not — a 0.6-point UTMOS move is far outside that range. The defensible reading is that Liquid spent this generation on generation: better voice, better audio reasoning, and an ASR front end that held its ground while the encoders changed underneath it. We found no third-party reproduction of any row, so treat the ordering as a hypothesis until someone publishes one.

Why the codec outlives the model

LiquidCodec is the part of this release worth watching beyond the checkpoint. It packs 80 ms of speech into 12 discrete tokens, decodes back to 24 kHz with streaming support, and Liquid measures it at about 87× real time on a single CPU thread of an M4 Max. The causal encoder is what allows prefill during speech instead of after it, which is where the "as low as 50 ms" time-to-first-token figure comes from.

Those two numbers are the most quoted and least reproducible things in the launch. Both are vendor measurements on named Apple hardware, with no harness, no audio set and no percentile. They describe a best case. A phone, a Raspberry Pi or a shared x86 VM will not hit them, and nothing in the release says what it will hit instead.

Runtime support is unusually broad for a one-day-old model: Transformers 5.20.2 or newer with trust_remote_code, vLLM and SGLang for the BF16 checkpoint, llama.cpp for GGUF, MLX 4-bit on Apple silicon, ONNX Runtime for portability, and fine-tuning on a single GPU. The custom-code requirement is the thing to pin. LFM3-Audio loads from its own module and reads codec weights out of a separate audio_tokenizer directory, so an unpinned environment is a support ticket waiting to happen.

Local speech against a hosted endpoint

The reason a 2B audio model at 2.1 GB is interesting is that the alternative bills you for every second of audio. Self-hosting has a fixed cost — a machine you already own, a download, no per-minute metering. A hosted endpoint has a marginal cost per token and no operational surface at all.

Be precise about what each side covers. Hosted text-to-speech — the sort we route, such as gpt-4o-mini-tts at $0.60 in and $12.00 out per million tokens, or gemini-2.5-flash-preview-tts at $0.50 and $10.00 — turns text into speech and nothing else. LFM3-Audio-2B also listens, transcribes and translates, and runs with the network unplugged. They solve different halves of the same voice agent.

LFM3-Audio-2B is not on OrcaRouter. The audio models we serve are hosted speech endpoints, so the honest split for a voice product this month is local speech in and out with the Liquid model, and everything text-side behind one endpoint for 200+ models — 0% markup on provider list price, automatic failover when a provider stumbles, and a routing DSL if you want to compose several models into a single call. That is what makes a two-runtime setup survivable: one contract for the hosted half, one download for the local half.

For the local half the cost is not zero: 2.1 GB of weights, a process to keep alive, and no SLA. If the audio never leaves the building, that trade is easy. If it does, the hosted price is small enough that the operational burden usually decides the question.

Who should run it this week, and who should wait

Run it if you want a local voice loop on a laptop and can live with text-out in the terminal for now. Run it if you need speech output in a language where the hosted voice you have is weak or expensive — eighteen languages is more coverage than most small TTS models offer. Run it if you have recordings that cannot leave the machine and want transcription plus a summary out of one model. Run it if you are prototyping spoken tool calls and want the model on the same box as the tool.

Wait if ASR accuracy is the product. A 6.23 word error rate is respectable and behind three models in Liquid's own table. Wait if you need streaming transcription today — live ASR is a follow-up llama.cpp PR, and English-only when it lands. Wait if you need the model to know things: the card recommends retrieval and explicitly does not recommend agentic coding or multi-step reasoning at this size. And wait if you need a vendor SLA, because Liquid's pricing page lists d1, d1-ultra and LFM2.5-24B-A2B and no LFM3 audio endpoint at all.

Three questions the launch does not answer

Is LFM3-Audio-2B the same model as LFM3-Omni-2B?

No. They share the LFM3 backbone and both appeared in the same llama.cpp pull request, but Omni adds vision on top of audio and is the larger commitment of the two. If the job is a phone call, a meeting recording or a voice command, Audio is the smaller model doing the smaller job. If the job involves looking at something while listening to it, that is the omni branch.

Can it transcribe a live stream?

Not through llama.cpp yet. The merge marks live ASR as a follow-up, and the model card is explicit that live ASR is English-only even once it exists. Batch transcription over a recording is the supported path today, with 32K tokens of context — roughly the length limit to plan around for long files, since audio tokens and text tokens share that budget.

Does it need a GPU?

No, and that is the point of the GGUF build. The 2.1 GB Ollama artifact runs on CPU. What the 87× real-time figure measures is the codec, not the language model, so do not read it as end-to-end speed on your hardware. Apple silicon has the smoothest path through MLX or the merged llama.cpp support; on x86 expect CPU decode to be the bottleneck, and measure before you promise a latency number to anyone.

What would change this verdict

Three signals, in order of how much they would matter. First, the live ASR follow-up landing in llama.cpp — that converts a batch transcriber into something you could put behind a microphone, which is the use case most people actually want. Second, an independent WER run on a standard set; until one exists, the only thing keeping this model's ASR honest is a vendor table comparing it to a vendor's own previous model. Third, a published API price for the audio branch, which would tell us whether Liquid intends to sell listening as a service or keep it a weights play.

Until then, the accurate description is narrow and useful: a 2B speech model you can download in a minute, that talks better than the model it replaces, listens about as well, and has no independent witnesses yet. For a prototype on a laptop, that is enough. For a production transcript pipeline, it is not — and the gap between those two sentences is exactly the distance between a launch and an evaluation.