LFM3-Omni-2B: The Omni Model That Speaks, and the Leak That Said It Couldn't

LFM3-Omni-2B answers in a voice. That single sentence is the news, because a week ago the best public evidence said the opposite. When the LFM3 family surfaced through an unmerged SGLang pull request, the checkpoints were wired for text output only, and our own write-up on that leak concluded, correctly at the time, that "LFM3 speaks" was unproven. On October 27, 2026, Liquid AI published the family announcement and the model card, and the card settles it: 24 kHz speech out, generated through a component called LiquidCodec, streamed faster than real time. An unproven model should not be load-bearing on day one. automatic failover Traffic can move by rule, and a failing path fails over without a code change.

Everything else about this release is quieter than that correction suggests. Liquid's announcement covers six models, and LFM3-Omni-2B gets three sentences in it — no benchmark table, no context length, no parameter count. The quantitative record lives entirely in the Hugging Face card, which is where every figure below comes from. That split is worth understanding before you plan around the model: the positioning is marketing, the numbers are a repository, and nothing in either has been independently tested.

What actually shipped, and when

The repository was created on October 21, 2026 at 16:58 UTC. The card was last modified on October 27 at 17:25 UTC, the same day as the family post. At the time of writing Hugging Face showed 83 downloads and 17 likes — modest numbers that fit a checkpoint published as one branch of a six-model family rather than as a headline release. The sibling repositories tell the same story: LFM3-VL-2B was created on October 19, LFM3-Audio-2B on September 8, and all of them were touched on October 27.

So this is not an unannounced model in the sense the brief implies. Liquid announced the family, named the six branches, and described what the omni model does. What the company did not do is announce LFM3-Omni-2B on its own terms. There is no standalone post, no launch-day evaluation write-up, no pricing page because there is no hosted endpoint, and no independent benchmark. The gap between "announced" and "documented" is where this article lives.

The card in full

The checkpoint is a single BF16 build of 2,166,928,384 parameters, which the card rounds to 2.17B. It sits on the LFM3-1.7B-Base trunk — the same tri-hybrid backbone as the rest of the family, with gated short convolutions carrying most of the layers and global attention reserved for a handful. On top of that trunk sit a vision encoder, a causal audio encoder and the LiquidCodec tokenizer that turns generated tokens back into waveform.

• Inputs — text, images at native resolution, video at 2 frames per second for 4 to 384 frames, and 16 kHz audio. Video input can include its own soundtrack.

• Outputs — text, 24 kHz speech, or both in the same response.

• Context — 32,768 tokens covering input and output together.

• Image budget — a maximum of 2,048 visual tokens per image, whatever the resolution.

• Languages — the card lists 16 text languages and 19 speech languages or locales; the repository metadata claims 23. The two figures do not reconcile on the page.

• License — LFM Open License v1.0, the custom terms Liquid has used since LFM2, not an OSI license.

• Reasoning — none. The card states that thinking mode is unsupported and that enable_thinking=True cannot be used.

Two of those lines matter more than the rest. The first is the 32K context, which is small for a 2026 multimodal model and a direct consequence of the on-device target: every token of context costs memory on a phone. The second is the license. LFM Open License v1.0 is not Apache-2.0, and the terms carry a revenue threshold that determines who can use the weights commercially without a separate agreement. If you are evaluating this model for a product, read the license before you read the benchmarks.

The numbers nobody announced

Liquid's post makes one comparative claim about LFM3-Omni-2B: that it beats models up to 10.7B parameters, "such as Qwen2.5-Omni-7B," on Daily-Omni, WorldSense and AV-SpeakerBench. No scores accompany that sentence. The card supplies them, and they are self-measured by Liquid AI — a vendor evaluation, not an independent one, and the only evaluation that exists.

On the three benchmarks the post names, the card reports Daily-Omni 70.09, WorldSense 47.10 and AV-SpeakerBench 46.79. OmniBench comes in at 46.32 overall with 48.25 on the speech subset. For spoken visual question answering — the model's headline trick, where you ask about an image out loud — the card lists RealWorldQA 64.68, MMStar 51.79, POPE 83.78, ERQA 39.43 and EmbSpatial 67.59. The audio rows are English ASR at 6.36 word error rate, multilingual ASR at 6.72, English speech synthesis at 3.80 UTMOSv2, VoiceBench 64.73 and audio-understanding MMAR 51.40. Its text-only vision scores, for completeness, are DocVQA 92.47, OCRBench 806 out of 1,000, MMMU validation 42.44 and MathVista mini 62.50.

Read as a set, the scores describe a model that is competent at everything and excellent at nothing. A 46.79 on AV-SpeakerBench and a 47.10 on WorldSense are not numbers that win a leaderboard; they are numbers that suggest a 2.2B model can hold its own on audio-visual reasoning without falling apart. The DocVQA score is the outlier in the other direction and the most interesting single figure in the table — 92.47 from a 2.2B omni model is high, and it is the one row where this checkpoint clearly outperforms Liquid's own dedicated vision model, which reports 91.1.

What the leak got right, and the one thing it got wrong

The SGLang pull request that broke this family into public view was accurate about almost everything structural. It named the four checkpoints correctly, it described the shared backbone correctly, and it was right that the 256-token sliding window is an attention setting rather than the context limit. It was also right to be cautious: the pull request was unmerged, three CI checks were failing, and two of twenty-two omni validation checks still failed on ROUGE comparisons against development checkpoints.

Where it misled — and where we repeated it — was output modality. The runtime path it wired up returned text. There was no audio-output branch in that code, and the reasonable inference was that the family might have dropped speech synthesis, or that the first runtime cut was text-only. The shipped model does both. The lesson is not that the leak was careless; it is that a serving integration describes the path someone implemented, not the capability of the checkpoint behind it. A PR is evidence about a runtime, and we treated it as evidence about a model.

What is still not confirmed

Three things, and they are the three that would decide a production deployment.

First, there is no independent evaluation of any kind. Every number above was produced by the company that built the model, on its own harness, with no published methodology. There is no Artificial Analysis entry, no LMArena result, no third-party reproduction. Treat the benchmark table as a specification of intent, not a measurement.

Second, speech serving is undocumented outside the vendor's own path. The card says SGLang support covers text output and does not document how the speech branch is served. If your plan is "one model, spoken answers, on our own hardware," the card gives you no reference for the second half of that sentence. The repository lists no inference provider at the time of writing.

Third, the language figures disagree with each other. Sixteen text languages, nineteen speech locales, twenty-three in the metadata. That is probably three different definitions of the same thing, but nobody has published which one is right.

Why a 2.2B omni model is a different bet

The usual way to build a voice assistant in 2026 is a pipeline: an ASR model turns speech into text, a language model thinks, a vision model handles the camera, and a TTS model speaks the answer. Each stage is a separate checkpoint, a separate latency budget and a separate failure mode. LFM3-Omni-2B's pitch is that all four collapse into one 4.3 GB BF16 file that fits on a phone and never leaves it.

That is a real architectural argument, and it is the reason the benchmark scores matter less than the shape of the thing. A pipeline of four small specialist models will usually beat a single generalist on each individual task. What it cannot do is share representations: the omni model hears the tone of a question about an image, and the answer is conditioned on both at once. Whether that produces better answers is exactly what no independent evaluation has tested.

The practical way to use a checkpoint like this while it is unproven is to keep it off your critical path. OrcaRouter's routing DSL was built for that pattern — a specialist path and an experimental path behind one endpoint, so a new model can take traffic in proportion to its reliability rather than all at once, with automatic failover when it errors. LFM3-Omni-2B is not on our catalogue today, so nothing here is a claim that you can call it through us. When a model like this does land, that is the shape of deployment it suits: available, measured, and not load-bearing until it earns it.

What to watch

The next signal is not another benchmark table. It is whether anyone outside Liquid publishes one. A 2.2B omni model that genuinely holds 70.09 on Daily-Omni is a notable result for on-device work, and an independent reproduction — even a partial one — would be worth more than the vendor's full sheet. The second signal is the SGLang merge: when the speech path is documented in a serving stack, the model stops being a repository and starts being infrastructure.

Until then, the honest summary is narrow. LFM3-Omni-2B exists, it is smaller than almost everything it competes with, it takes four modalities in and gives two out, and it is the first Liquid model that can answer out loud. The leak said it couldn't. The card says it can, and for now the card is the only witness.