LFM3-VL-2B vs MiniCPM-V 4.7 35B-A3B: The Column That Isn't the Model

Open the benchmark table for LFM3-VL-2B and you will find a MiniCPM column. It is labelled MiniCPM-V 4.7 1B. That is the small sibling. The model most people mean when they say MiniCPM-V 4.7 — OpenBMB's MiniCPM-V 4.7 35B-A3B, the first mixture-of-experts checkpoint in the MiniCPM-V line — is not in Liquid AI's table at all, and on the benchmarks both labs publish it is not close to the 1B. So the matchup people are actually weighing, LFM3-VL-2B against MiniCPM-V 4.7 35B-A3B, has to be assembled by hand from two vendor tables that share benchmark names but not evaluation harnesses. What follows is that assembly, with the seams left visible.

The size mismatch is the second surprise. One model is 1.92 billion dense parameters and fits in a few gigabytes. The other stores 35.21 billion parameters and touches roughly 3 billion of them per token. Read as a spec sheet, that is not a matchup at all. Read as two answers to the same question — what can you run on a device you do not control — it is a genuinely interesting disagreement about how to get there.

Two models, one name

The naming collision is doing real damage to how this comparison gets read. Liquid AI's card is scrupulous about it: the column says 1B, and the 1B is a legitimate peer for a 1.92B model. But search results, aggregators and casual references all collapse "MiniCPM-V 4.7" into one thing, and the 35B-A3B is the variant with the audience — 289,535 downloads and 1,095 likes on Hugging Face against 155,428 and a few hundred for the 1B sibling, as of 28 October 2026.

Dates explain part of that gap and not the rest. OpenBMB's 35B-A3B repository was created on 7 October 2026, with the release dated 12 October on the project's own materials. Liquid AI's LFM3-VL-2B repository went up on 19 October and the LFM3 family was announced on 27 October. LFM3-VL-2B has had nine days of public life, so its 255 downloads are a calendar fact, not a verdict. The likes ratio is the more interesting line: 45 for LFM3-VL-2B, 1,095 for the MiniCPM. People who downloaded the latter liked it enough to say so.

What each one actually is

• Parameters — LFM3-VL-2B is 1.92B dense: a 1.73B language backbone, a 164M in-house vision encoder and a 25M projector. MiniCPM-V 4.7 35B-A3B stores 35.21B across 256 experts and routes 8 of them per token, roughly 3B active.

• Backbone — 24 LFM3 layers, split 13 gated short convolutions, 5 sliding-window attention layers and 6 global attention layers, against 40 transformer layers at hidden size 2,048.

• Vision path — a 14-layer encoder of 8 gated depthwise 2D convolutions and 6 bidirectional attention layers on 16×16 patches with 2D rotary embeddings, against a 27-layer tower at hidden size 1,152 inserted at layer 6 of the text stack, with early token compression inside the encoder and switchable 4× or 16× visual downsampling.

• Context — 128K tokens on LFM3-VL-2B, 256K on the MiniCPM, both input plus output.

• Inputs — text, images and video at 2 frames per second for the Liquid model; text, images and video for the OpenBMB one. Neither hears audio, in either direction.

• Weights on disk — about 3.8 GB at BF16 versus about 65.6 GiB at BF16.

• Licence — LFM Open License v1.0, which Liquid describes as free for commercial use below $10 million in annual revenue, versus Apache 2.0 with no revenue condition.

The architectural disagreement is the whole story. Liquid bet that a small dense model plus a purpose-built vision encoder beats a SigLIP-style tower on compute per image, and published a category table to prove it. OpenBMB bet that you can keep a 35B model's capability and still run it on a phone by making the expensive part stream rather than reside. Both are bets about memory, made in opposite directions.

The gap is real, and it is narrower than the framing

Here is what the two vendor tables say when you put the right rows side by side. All of it is self-reported by the labs, and the harness caveats come after.

• MMMU — LFM3-VL-2B 55.7 with thinking on, 48.6 with it off; MiniCPM-V 4.7 35B-A3B 80.22 at 4× visual compression, 80.00 at 16×.

• MMStar — 74.4 against 80.67 at 4×, 80.13 at 16×.

• OCRBench v1 — 86.3 against 91.20 at 4×, 90.40 at 16×.

• MathVista — 84.2 with thinking, 68.5 without, against 88.00 at 4× and 87.30 at 16×.

• CharXiv reasoning — 70.2 against 75.60 at 4×, 69.20 at 16×.

MMMU is where the 35B earns its size: a 24.5-point gap over the thinking configuration, 31.6 points over the no-thinking one. That is the college-level multimodal reasoning benchmark, and the margin is large enough to survive any reasonable objection about harness differences.

Everything else is closer than the framing suggests. OCRBench is a 4.9-point gap. MathVista is 3.8 points when LFM3-VL-2B thinks. On CharXiv reasoning the Liquid model loses by 5.4 points in thinking mode — and beats the 35B's 16× number by a point. A 2B model within five points of a 35B on document OCR and charts is the finding that should get more attention than the MMMU headline.

Now the caveats, because they matter. Liquid's figures come from a single run over 62 benchmarks on vLLM 0.27.1, normalised to 0–100, with reasoning mode enabled for every model except the configurations marked otherwise. OpenBMB's five numbers are published as chart images rather than a numeric table and were transcribed here from a third-party aggregator's reading of those charts, so treat the decimals as approximate. The two labs do not agree on visual token budgets, prompting or decoding settings, and the 4× versus 16× split on the OpenBMB side changes its scores by up to six points on its own. This is two sets of claims sitting next to each other, not a controlled experiment.

Where the small model has numbers the big one does not publish

Liquid published 62 rows. OpenBMB published five. That asymmetry is the most under-reported fact in this comparison, and it cuts in a direction that flatters the smaller model.

• Visual grounding — RefCOCO-avg 90.5, RefCOCO-M 95.2, Point-Bench 73.8, RefSpatial-Bench 49.8 for LFM3-VL-2B. No equivalent row appears in MiniCPM-V 4.7 35B-A3B's published evaluation.

• GUI understanding — ScreenSpot-Pro 55.5, ScreenSpot-v2 at 94.6 desktop, 92.2 mobile, 89.9 web. Again, nothing published on the OpenBMB side.

• Embodied reasoning — EmbSpatial-Bench 82.9, RoboSpatial-Home 63.4, Where2Place 44.9. Same absence.

• Video — Video-MME 62.8 without subtitles, MVBench 69.4, MLVU 71.3, ActivityNet-QA 71.2. MiniCPM-V 4.7 supports video and the card discusses it at length, but the numeric table does not carry a video row we could verify.

This is absence of evidence, not a win by default. If you are building a robotics or screen-agent pipeline, the honest position is that the 35B's capability on those tasks is unknown rather than weak. But "unknown" is itself a procurement problem: you cannot plan a deployment around a number nobody published, and LFM3-VL-2B is the only one of the two whose grounding and GUI performance you can read before you download it.

The memory argument cuts both ways

The usual reason to pick a 2B over a 35B is that the 2B fits. LFM3-VL-2B does fit, entirely and predictably: about 3.8 GB in BF16, resident, no paging, no surprises when the device is under load. That is a genuinely strong property for a product you ship to hardware you do not control.

MiniCPM-V 4.7 35B-A3B does not fit anywhere near a phone at 65.6 GiB, and OpenBMB's entire design exists because of that. Lookahead Expert Scheduling predicts the next layer's routing and prefetches the experts it expects; fine-grained layer-wise quantization shrinks those experts so they move faster; DSpark speculative sampling covers the decoding stalls. The vendor claim is 13-plus tokens per second on an iPhone 17 Pro Max using about 3 GB of memory, and 17-plus on an iPad Pro M4 with 16 GB.

So the on-device claim is not "the 35B is small." It is "the 35B streams, and the streaming is smooth enough to be usable." Those are different bets with different failure modes. A resident 3.8 GB model degrades gracefully — it is either loaded or it is not. A streaming 65.6 GiB model degrades with flash bandwidth, thermal throttling and cold-start latency, all of which vary by device in ways a benchmark on one iPhone does not capture.

The practical split: if you control neither the storage speed nor the thermal envelope, resident is the lower-risk path. If you are shipping to recent flagship hardware and want the accuracy, OpenBMB's approach is no longer theoretical — it is a released model with a working fork behind it.

Day-one tooling is not a tie

LFM3-VL-2B ships BF16 weights that need transformers 5.21 or newer, plus GGUF including a quantization-aware-distilled Q4_0 checkpoint, an MLX 4-bit build and an ONNX export. Server support is not finished: vLLM is described as in progress, SGLang sits in review at pull request 46858, and llama.cpp is in review at pull request 31252 with an explicit note that video input is not supported yet. The card also recommends the qwen3 reasoning parser and qwen3_coder tool-call parser for vLLM and SGLang, a detail that tells you how recently this was wired up.

MiniCPM-V 4.7 35B-A3B supports SGLang, vLLM, llama.cpp and Ollama, with SWIFT and LLaMA-Factory for fine-tuning, GGUF, BitsAndBytes, AWQ, GPTQ, FP8 and int4 builds, and day-zero support for chip platforms from Rockchip, Houmo, Intel, AMD and Arm across iOS, Android and HarmonyOS. The on-device path runs through OpenBMB's own llama.cpp-omni fork rather than upstream llama.cpp.

For a production deployment this month, that is not a close call. For a research spike, a laptop demo or a fine-tune you intend to own, LFM3-VL-2B works today through transformers and you will not spend a week on build flags.

The licence line more teams will trip on

Apache 2.0 against the LFM Open License v1.0 is a bigger practical difference than the MMMU gap, because it applies to every deployment rather than to the hard cases. Apache 2.0 carries no revenue condition, no field-of-use restriction and no ambiguity about whether a quantised or distilled derivative inherits the terms. The LFM Open License v1.0 is free for commercial use below $10 million in annual revenue by Liquid's own description, which means a company above that line is having a licensing conversation before it ships, not after.

That single clause reshuffles the comparison for a lot of buyers. A startup under the threshold gets a smaller, faster, better-documented-on-grounding model for nothing. A company over it gets a model that needs a signature — at which point the 35B's Apache 2.0 becomes a feature you are paying attention to.

What neither vendor will tell you

There is no independent head-to-head. No third-party lab has run both models on the same harness, and the closest thing to a neutral scoreboard — Liquid's own table — compares LFM3-VL-2B to the 1B, not the 35B. Every number in this article comes from the lab that built the model it describes.

Two other gaps are worth naming. Neither model has a per-token price we could verify, so a cost comparison here would be invented. And neither is in the OrcaRouter catalogue as of 28 October 2026 — a search for minicpm returns no matching models, and LFM3-VL-2B is not listed either. That makes this a self-hosting or vendor-API decision today, not a routing decision.

Which one to pick

• Documents, charts, dense text and hard multimodal reasoning, with a serving stack you control — MiniCPM-V 4.7 35B-A3B. The MMMU margin is the one result large enough to survive the harness caveats, and Apache 2.0 removes the licence question entirely.

• A device you do not control, with a fixed memory budget and no tolerance for streaming latency — LFM3-VL-2B. Resident at 3.8 GB, and the only one of the two with published grounding, GUI and embodied numbers to plan against.

• Screen agents, robotics and spatial tasks — LFM3-VL-2B by default, because it is the only side with published evidence. Treat the 35B as unproven there rather than weak.

• Production this month with minimal integration work — MiniCPM-V 4.7 35B-A3B. SGLang, vLLM, llama.cpp and Ollama support against three "in review" or "in progress" notes.

• A company above $10 million in annual revenue — MiniCPM-V 4.7 35B-A3B, unless the on-device constraint is hard enough to justify a licensing conversation.

How OrcaRouter fits, honestly

It does not fit yet, and saying otherwise would be the kind of thing that gets a blog post ignored. Neither model is in the OrcaRouter catalogue today, so there is no key to hand you and no price to quote.

What is true is what happens when a vision model does land there: one OpenAI-compatible endpoint across 200-plus models, provider list price passed through at 0% markup so a vendor price change is live the same day, and automatic failover so a single provider's outage does not take your route down. For a comparison like this one — two models that disagree about memory, with no independent benchmark to settle it — the useful pattern is to run both behind one endpoint and measure on your own images rather than argue about whose chart is right.

What to watch

Four things would change this article. Pull request 31252 merging with video support, which would put LFM3-VL-2B's video path on standard llama.cpp. vLLM support leaving "in progress", which would make it a serious serving option rather than a demo. An independent evaluation running both models on one harness — the single most valuable missing artifact in this comparison. And Liquid AI adding the 35B to its own comparison table, which would tell you the lab considers it the real peer.

Until any of those land, the defensible summary is narrower than either vendor's framing: the 35B wins the reasoning benchmark that matters and loses nothing on OCR, the 2B wins on grounding evidence and predictability, and the licence decides more deployments than the benchmark does.