LFM3-Omni-2B vs MiniCPM-V 4.7 35B-A3B: The Newcomer and the Incumbent

Two numbers, both true, both misleading if you read them as a verdict: MiniCPM-V 4.7 35B-A3B has been downloaded about 289,000 times, and LFM3-Omni-2B has been downloaded 83 times. The gap looks like a rout. It is actually a calendar. OpenBMB's weights went up on 6 October 2026; Liquid AI's went up on 21 October and were announced on 27 October, one day before these numbers were read. A model that has existed for a week cannot have a download history, and a model with a six-week head start and an existing MiniCPM following will have one whether or not it deserves it.

So the interesting comparison is not popularity. It is what a team choosing a small multimodal model for a device should actually weigh: whether it needs to hear, whether it needs to be quantised six ways, and which licence will still be comfortable when the product has revenue.

What each model is

MiniCPM-V 4.7 35B-A3B is OpenBMB's first mixture-of-experts vision-language model: 35.2 billion stored parameters routed 8-of-256 per token, roughly 3 billion active, 40 text layers, behind a 27-layer vision tower at hidden size 1,152 that inserts at layer 6 of the text stack. It reads images, multi-image sets, video and text, and answers in text. There is no audio path anywhere in the 70.4 GB of weights. The card's headline claim is not accuracy but viability: more than 13 tokens per second on an iPhone 17 Pro Max using about 3 GB of memory, made possible by a Lookahead Expert Scheduling trick that predicts the next layer's experts and prefetches them while the current layer computes.

LFM3-Omni-2B is Liquid AI's omni entry in the LFM3 family: 2.17 billion dense parameters on an LFM3-1.7B backbone, with an LFM3 vision encoder and an LFM3 causal audio encoder feeding one 128,000-token vocabulary. It reads text, images, video with or without sound, and 16 kHz audio, and it writes text or 24 kHz speech, including interleaved text and speech in a single response. It is a non-reasoning model by design — the card states that enable_thinking=True is unsupported — and it is positioned for phones, laptops and edge hardware.

Both fit on a phone. Only one was designed around that.

It is easy to file both under "small model on a device" and move on. The engineering underneath is opposite.

OpenBMB's problem was memory bandwidth on a handset, so the model is sparse in a way that reduces what has to be read per token: 35.2B stored, 3B touched. The Lookahead Expert Scheduling is the giveaway — you only build expert prefetching when the bottleneck is moving weights, not multiplying them. LFM3-Omni-2B solves the same problem by being genuinely small: 2.17B dense, no routing at all, everything in 16-bit and still a few gigabytes.

The trade shows up in quantisation. MiniCPM-V 4.7 ships GGUF, AWQ, GPTQ, FP8, INT4 and BitsAndBytes builds, plus DSpark draft checkpoints for speculative decoding — a full menu for whatever accelerator you land on. LFM3-Omni-2B has BF16 weights on Hugging Face and an Ollama build in circulation, and that Ollama listing quotes a 125K context against the 32K in the model card. Whether that is a packaging bug or an undocumented capability is, as of writing, unresolved. If you need to run on a Rockchip NPU or an Intel laptop, the vendor with six quantisation formats is the safer bet on day one.

The line that decides most deployments

MiniCPM-V 4.7 35B-A3B cannot hear. No audio tower, no ASR path, no speech head. LFM3-Omni-2B can hear and can answer out loud, in 19 speech locales and 16 text languages.

For a document, chart, screenshot or video-frame workload, that difference is irrelevant and MiniCPM is the stronger pick on almost every other axis — bigger, more widely tested, better tooled. For anything with a microphone in the loop, it ends the comparison immediately. You cannot bolt hearing onto MiniCPM-V 4.7 without adding a separate ASR model and then a TTS model, at which point you are running three models to do what one 2.17B checkpoint does natively.

The reverse also holds. LFM3-Omni-2B reads images, but it is a 2.17B model reading them: its card reports OCRBench 806, DocVQA 92.47 and MMMU 42.44, with MMMU-Pro down at 27.28. Those are respectable numbers for the size and not competitive with a 35B model on hard document layouts. If the job is dense tables and scanned forms, the larger model wins on the task even before you consider the 8-of-256 routing that makes it cheap to run.

Where the numbers run out

Here is the uncomfortable part: there is no honest head-to-head table available, because OpenBMB publishes its MiniCPM-V 4.7 results as chart images rather than numeric tables. There are no MMStar, MMMU or OCRBench figures to quote from the 35B-A3B card. Anything that puts a number in that column is either from the 1B sibling — a different model with a different architecture — or invented.

LFM3-Omni-2B's card, by contrast, is a full table: MMStar 55.67, MMMU 42.44, MMMU-Pro 27.28, MMBench 73.68, SEEDBench 75.07, RealWorldQA 66.54, MathVista 62.50, POPE 89.34, DocVQA 92.47, InfoVQA 64.08, OCRBench 806, MVBench 58.03, Video-MME 57.70, plus a speech column running from English ASR at 6.36 word error rate to TTS UTMOSv2 at 3.80. All of it was measured by Liquid AI, with each compared model's own chat template and greedy decoding, and none of it has been reproduced.

A vendor table is better than a vendor chart, but it is not the same as an independent evaluation. Neither model has one. That is the state of play across the entire small-omni category right now, and it is why the deployment constraints end up mattering more than a point of MMMU.

Licences, read before the prototype ships

MiniCPM-V 4.7 is Apache 2.0. No revenue test, no field-of-use clause, no negotiation. LFM3-Omni-2B is under the LFM Open License v1.0, the revenue-threshold licence Liquid applies across LFM3. For a hobby project or an early startup the two are equivalent in practice. For a company past the threshold, one of them requires a conversation with a lawyer and the other does not — and that conversation is much cheaper to have now than after the model is in the product.

This is the least glamorous axis in the comparison and the one most likely to decide it at an actual company.

How the two fit into one architecture

The realistic answer for most teams is not "pick one". It is an on-device model for the common case and a hosted model for the requests the device model fumbles. Keeping that second half portable is the part that survives a change of device model: OrcaRouter gives one API across 200+ hosted models at 0% markup on the provider's list price, automatic failover when a provider drops, and a routing DSL that moves a request to a different model without a code change. Neither LFM3-Omni-2B nor MiniCPM-V 4.7 is on that catalogue — both are weight downloads, and this piece is not suggesting otherwise. The point is that the fallback tier should not be rebuilt every time the device tier changes, and with a device tier that is still moving every few weeks, it will change.

Which one to put on the device

Choose MiniCPM-V 4.7 35B-A3B if you need vision quality, a quantisation format you can actually deploy, Apache 2.0, and an ecosystem with six weeks of field reports behind it. Its download count is not a quality signal, but the bug reports that come with 289,000 downloads are a form of testing LFM3-Omni-2B does not have yet.

Choose LFM3-Omni-2B if the product needs a voice, if the device is memory-constrained enough that 3 GB of active weights is still too much, or if you want one checkpoint instead of an ASR-plus-LLM-plus-TTS stack. Accept the smaller model's vision scores, the revenue-threshold licence, and the fact that you are an early adopter of a model that is one day past its announcement.

What would settle it is a single independent run — the same harness, both models, OCRBench and MMMU and a speech task. Nobody has done it. Until someone does, the honest ranking is: MiniCPM for seeing, LFM3-Omni for speaking, and a spreadsheet for everything else.