LFM3-Omni-2B vs LFM2.5-VL-3B: The Successor That Sees Less

Liquid AI's newest multimodal model is worse at looking than the one it replaced. On RealWorldQA, LFM3-Omni-2B scores 66.68 and LFM2.5-VL-3B scores 73.1. On MMStar it is 55.67 against 63.3. On RefCOCO referring expression pointing it is 73.55 against 87.9. On MMBench, 73.68 against 81.0. Four of the five benchmarks the two models both report favour the older, larger, vision-only checkpoint, and the gap is not noise — it is between seven and fourteen points depending on the row. Routing between two models should not add a platform fee. 0% markup Provider list prices pass through unchanged.

That is not a scandal. It is what happens when you ask a smaller network to do more jobs at once, and it is the single most useful fact for anyone deciding between these two checkpoints. LFM3-Omni-2B is not the upgrade path for a vision product. It is a different product that happens to share a family name.

Two models doing different jobs

The confusion is understandable, because the two models look like consecutive generations of the same idea. Both come from Liquid AI, both are built for on-device deployment, both are non-reasoning, both inherit the LFM Open License v1.0, and both are pitched at roughly the same memory budget. LFM2.5-VL-3B shipped on August 12, 2026 as a vision-language specialist: a 2.6B text backbone paired with a 400M SigLIP2 NaFlex encoder, about 3.1B parameters in total.

LFM3-Omni-2B, published on October 27, 2026, is an any-to-any model. It takes text, images, video with or without a soundtrack, and 16 kHz audio, and it returns text, 24 kHz speech, or both. Vision is one of four input paths rather than the whole job. The parameter budget went from 3.1B to 2.17B while the number of tasks went from one to four, and the vision scores are where that arithmetic shows up.

• Parameters — 2.17B dense for LFM3-Omni-2B vs about 3.1B for LFM2.5-VL-3B, of which 400M is the vision encoder.

• Inputs — text, image, video and 16 kHz audio vs text, image and video.

• Outputs — text and 24 kHz speech vs text only.

• Context — 32,768 tokens vs 32,768 tokens. Identical, and both count input plus output.

• Vision budget — 2,048 visual tokens per image, native resolution vs native-resolution 512-pixel patches with a thumbnail path.

• Positioning — an omni replacement for a four-model pipeline vs a dedicated VLM for OCR, UI understanding and visual question answering.

• License — LFM Open License v1.0 in both cases, including the revenue threshold that governs commercial use.

Where the numbers actually overlap

Benchmark comparisons between models from different labs are usually dishonest, because the harnesses differ. This one is cleaner than most: both checkpoints were evaluated by the same company, in the same non-reasoning mode, and both report five of the same datasets. That does not make the numbers independent — they are not — but it does make them comparable to each other in a way that cross-lab tables rarely are.

• RealWorldQA — 66.68 for LFM3-Omni-2B vs 73.1 for LFM2.5-VL-3B. A 6.4-point drop on everyday-scene questions.

• MMStar — 55.67 vs 63.3. A 7.6-point drop on a benchmark built to resist data contamination.

• MMBench — 73.68 vs 81.0. A 7.3-point drop on broad multimodal capability.

• RefCOCO pointing — 73.55 vs 87.9. A 14.4-point drop, the widest gap in the set, on the task of locating a named object in an image.

• DocVQA — 92.47 vs 91.1. The exception: LFM3-Omni-2B is ahead by 1.4 points on document question answering.

The DocVQA result is the one that keeps this from being a simple "the new model is worse" story. Document text is the task where a unified model's ability to read a page at high resolution and reason about it in one pass can beat a pipeline — and it is also the task where Liquid's 2,048-token-per-image cap should hurt most. That the omni model wins there anyway suggests the vision degradation is not uniform across tasks. It is concentrated in spatial and referring tasks, which is exactly where you would expect a model with less dedicated visual capacity to struggle.

What the extra modalities cost

The audio path is not free, and the card is unusually clear about where the cost lands. The 32K context is shared across every modality: a video at 2 frames per second for 384 frames consumes most of the window before you have asked a question. Images are capped at 2,048 visual tokens each, which is roughly the resolution ceiling for reading dense text in a photograph. The vision-only model has the same 32K context but does not have to spend any of it on audio.

Speech output adds a second consideration that has nothing to do with benchmarks. LiquidCodec converts generated tokens into 24 kHz audio faster than real time, which is what makes streamed spoken replies possible. But the model card documents SGLang serving for text output only, and does not describe how the speech branch is served. If you need spoken answers from your own infrastructure, the reference implementation for that half of the model is missing. Compare that with LFM2.5-VL-3B, which has a year of tooling behind it — GGUF, MLX, vLLM, SGLang, ONNX, and reports of 228 tokens per second on an M5 Max at under 3.3 GB of memory.

Maturity is not a benchmark row, but it decides deployments. A model that runs everywhere today beats a model that runs on one path tomorrow, unless the extra modality is the reason you are there.

How to choose

If the job is reading screenshots, parsing documents, pointing at objects, or answering questions about a camera feed, LFM2.5-VL-3B is the better model and it is not close on the rows that matter. The 14-point RefCOCO gap in particular should end the discussion for any robotics or UI-automation use case. Being 3.1B parameters does not hurt when the alternative is a 2.17B model spending a third of its capacity on ears and a mouth.

If the job involves a person speaking to a device and the device speaking back — a kiosk, a phone assistant, a field tool where hands are busy — LFM3-Omni-2B is doing something LFM2.5-VL-3B cannot do at any parameter count. You are not choosing a worse vision model; you are choosing to collapse four models into one, and accepting the vision regression as the price of the collapse.

There is a third option that the benchmark table makes obvious: run both. A vision specialist for the frames, an omni model for the conversation. That is two checkpoints and about 7.4 GB in BF16, which is still inside the memory of a single mid-range GPU. OrcaRouter's routing DSL exists for exactly this composition — one endpoint, rules that send an image-and-text request to the specialist and a spoken request to the omni model, with automatic failover if either path fails. Neither checkpoint is on our catalogue today, so that is a pattern rather than a promise; the point is that the "which model" question has a third answer that neither vendor's launch post mentions.

The verdict

LFM3-Omni-2B is a genuine engineering achievement at 2.17B parameters, and a bad replacement for LFM2.5-VL-3B in any application that is primarily visual. The honest way to read the pair is as a fork in Liquid's own product line: one branch optimises for seeing, the other for participating in a conversation. The family name and the shared license make them look like a sequence. The benchmark table says they are siblings, and the older sibling is better at the thing it was built for.

What would change that assessment is an independent evaluation, because the entire comparison above rests on numbers Liquid produced about its own two models. It is possible that the omni model was evaluated on harder variants of these datasets, or in a mode that disadvantages it. Nothing in the card suggests so, and the consistent direction of four out of five rows argues against it. Until someone outside the company reproduces either table, the safest reading is also the simplest: the specialist sees better, and the omni model hears.