LFM3-Omni-2B vs MiniCPM-V 4.7 1B: When the Smaller Model Reads Better

On paper this is not a fair fight. LFM3-Omni-2B has 2.17 billion parameters; MiniCPM-V 4.7 1B is marketed as a 1B model. The larger model should win the vision benchmarks. It does not. MiniCPM scores 86.1 on OCRBench against 80.6, 69.5 on MMStar against 55.67, 56.9 on MMMU against 42.44, and 74.3 on MathVista against 62.5. Every vision benchmark the two cards share favours the model with the smaller name, usually by a wide margin, and MiniCPM also carries eight times the context window. Fusion costs more per call than routing to a single model. It is billed at the provider list price with no markup added.

Three things explain that, and none of them is a defect in either model. MiniCPM-V 4.7 1B is a specialist that spent its whole parameter budget on seeing. LFM3-Omni-2B is a generalist that spent its budget on seeing, hearing and speaking. And the MiniCPM number that matters most — 86.1 on OCRBench — was measured with its 4× visual token setting, which trades compute for detail in a way a 2,048-token-per-image cap cannot. Understanding that trade is the whole decision.

Why the smaller model reads better

MiniCPM-V 4.7 1B is built around a single idea: compress visual tokens early, and let the user choose how hard to compress. The model applies 4× or 16× token compression inside the vision encoder, before the language model sees anything. At 16× it is cheap and fast, suited to captioning and scene description. At 4× it keeps four times as many tokens, which is what document OCR and dense chart reading need. OpenBMB's headline numbers are reported at the 4× setting.

LFM3-Omni-2B takes the opposite approach. It processes images at native resolution but caps the visual budget at 2,048 tokens per image, and that cap is shared with an audio encoder, a video path and a speech decoder inside a 2.17B dense network. The 2,048-token ceiling is a reasonable choice for a model that has to fit on a phone alongside three other modalities. It is a hard ceiling on how much page detail can reach the language model, and DocVQA 92.47 suggests the model wrings a lot out of it — but OCRBench 80.6 says it is not enough to beat a specialist that can spend 4× the tokens on the same page.

There is a second, quieter factor. MiniCPM's context window is 262,144 tokens. LFM3-Omni-2B's is 32,768. For a single screenshot neither matters. For a 40-page PDF, a long video, or a multi-turn document conversation, the difference is not a benchmark row — it is whether the task is possible at all.

Specification, without the marketing rounding

One number needs correcting before any comparison. MiniCPM-V 4.7 1B is called a 1B model, and its dense parameter count is roughly 1.3 to 1.55 billion depending on how you count the vision tower. Hugging Face's sidebar rounds it to "2B params," which is how a 1B model ends up looking like a 2B model in a catalogue. The file size is the honest guide: about 3.1 GB in BF16, against 4.3 GB for LFM3-Omni-2B.

• Parameters — 2.17B dense for LFM3-Omni-2B vs roughly 1.3B to 1.55B dense for MiniCPM-V 4.7 1B.

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

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

• Context — 32,768 tokens vs 262,144 tokens.

• Visual tokens — capped at 2,048 per image vs switchable 4× or 16× compression inside the encoder.

• License — LFM Open License v1.0 vs Apache-2.0.

• Release — October 27, 2026 vs October 12, 2026.

• Footprint — about 4.3 GB BF16 vs about 3.1 GB BF16, roughly 5 GB of VRAM to serve.

Every row the two cards share

The comparison is unusually clean for a cross-lab table, because both vendors report the same four vision datasets and both are non-reasoning models evaluated in instruct mode. It is still two vendor evaluations, and neither has been independently reproduced.

• OCRBench — 80.6 for LFM3-Omni-2B (806 of 1,000) vs 86.1 for MiniCPM-V 4.7 1B. A 5.5-point gap on document text recognition.

• MMStar — 55.67 vs 69.5. A 13.8-point gap, the largest in the set.

• MMMU validation — 42.44 vs 56.9. A 14.5-point gap on university-level multimodal reasoning.

• MathVista mini — 62.50 vs 74.3. An 11.8-point gap on visual mathematics.

Four rows, four losses, gaps between five and fifteen points. There is no row where the omni model wins, which is a cleaner result than the LFM3-versus-LFM2.5 comparison produced and a harder one to explain away. The most defensible reading is that a 1.4B specialist with a 256K context and a 4× token budget is simply a better reader than a 2.17B generalist with a 32K context and a 2,048-token image cap. Capacity spent on one modality beats capacity divided across four, at this scale.

Two caveats belong in the same breath, because neither card volunteers them. MiniCPM's 86.1 is measured at 4× compression, and the same model at its default 16× setting would score lower and run cheaper — the card does not publish that number. And OpenBMB's model card carries no benchmark table at all; the figures appear as prose and chart images on the product page, which is a weaker form of publication than a table with a methodology note. Both sets of numbers are vendor claims. The direction of the gap is consistent enough that it probably survives independent testing; the exact size probably does not.

Context is the row that decides real workloads

A 32K context is generous for a single image and cramped for a document. At roughly 2,048 visual tokens per image, LFM3-Omni-2B can hold about a dozen full images in its window before the conversation history starts competing for space. MiniCPM-V 4.7 1B's 262,144 tokens is not a modest improvement; it is a different class of workload. Long PDFs, multi-page forms, hour-long video summaries and agent loops that keep screenshots in context are all feasible at 256K and all constrained at 32K.

This is the least discussed and most consequential difference between the two models. Benchmark tables reward single-image accuracy; production document pipelines fail on the fourteenth page. If your use case involves more than a handful of images per conversation, the 32K window is a harder limit than any of the four benchmark gaps above.

What MiniCPM cannot do

It cannot hear. There is no audio input path, no speech output, and no video soundtrack handling. If the application is a person talking to a device about what the camera sees, MiniCPM-V 4.7 1B is one component of a pipeline that needs at least two more models — an ASR system and a TTS system — plus the glue to move text between them.

LFM3-Omni-2B collapses that pipeline into one 4.3 GB checkpoint. Its audio scores are unremarkable next to dedicated speech models — English ASR 6.36 word error rate, VoiceBench 64.73 — but they exist inside the same forward pass as the vision path, which means the model can answer a spoken question about an image without a transcript ever being written. For a hands-free field tool or a kiosk, that is the feature. For a document pipeline, it is dead weight in the parameter budget.

OrcaRouter's model fusion is the other way to get both behaviours: a panel where a document specialist and an omni model answer the same prompt and the response is composed from both. That is a product capability rather than a claim about these two checkpoints — neither is on our catalogue today — but it is the architectural answer to a matchup where each model is clearly better at a different half of the job. Fusion costs more per call than routing to one model, and it is worth it exactly when a wrong answer costs more than the tokens.

The decision

If the work is reading — OCR, invoices, forms, charts, screenshots, long PDFs, dense UI — MiniCPM-V 4.7 1B is the better model on every published measure, it has eight times the context, it is Apache-2.0 instead of a custom license with a revenue threshold, and it is smaller on disk. That is not a close call, and the fact that it is called a 1B model should not obscure it.

If the work is a conversation with a device that has a camera and a microphone, LFM3-Omni-2B is the only one of the two that can participate. It reads less well, holds less context, and ships under stricter terms, and none of that matters if the alternative requires three models and a pipeline.

There is a third case worth naming: a product that needs both, where the document path and the voice path are separate features. Then the correct architecture is not one model but two, routed by request type — the reader for documents, the omni model for voice — and the only question is whether you want to run both or let a single endpoint decide. That is the question this batch of comparisons keeps arriving at, and it is the right one. The models are close enough in footprint that running both is a real option; they are far enough apart in capability that running only one is a compromise whichever you pick.

What would change the verdict is an independent evaluation of either model, and specifically one that tests MiniCPM at its default 16× compression rather than the 4× setting its headline numbers use. That single number could close most of the gap — or widen it. Until someone publishes it, the vendor tables are what we have, and they point in one direction.