ZoomGain-4B vs MiniCPM5 2B: Portability Is the Benchmark Nobody Publishes

There is a number missing from both model cards, and it is the one that decides most deployments. MiniCPM5-2B ships in GGUF, MLX, GPTQ and LiteRT builds, has a DSpark draft model for speculative decoding, and — the detail that tells you the most — carries FlagOS builds for nine different accelerator families including Ascend, Hygon, Kunlunxin and Metax. ZoomGain-4B ships in GGUF at three precisions and requires, in the card's own words, "a llama.cpp build with Q​wen3.5 multimodal support." One of these models runs almost anywhere. The other runs where you can build a specific runtime. Neither card calls this a benchmark, and for anyone who has to actually operate a model rather than cite it, this is the row that matters more than either model's accuracy column.

That framing is not a way of dodging the accuracy comparison — it comes later, and the accuracy comparison turns out to be less decisive than it looks, because the two models are not measured on the same axis and cannot be. MiniCPM5-2B from OpenBMB is a text model: 2.52 billion parameters, released 6 September 2026, tuned for agents, tool calls, code and long context. ZoomGain-4B from inclusionAI is a vision-language specialist published on 11 November 2026, trained by reinforcement learning on questions about fine visual detail. What follows is what each is measured on, what each costs to stand up, and where the honest dividing line sits.

The missing row: what it takes to run each one

Start with the artefact list, because it is the most concrete thing either publisher has given you.

• MiniCPM5-2B. A dense causal transformer on the standard LlamaForCausalLM class — 42 layers, GQA with 16 query heads and 2 KV heads, 131,072-token context, 2,516,756,480 total parameters of which 1,981,982,720 are non-embedding. Because the architecture is standard, it inherits every serving path anyone has already written for Llama-shaped models. The organisation publishes the SFT, Midtrain and Base variants as separate repos, plus GGUF, MLX and GPTQ quantisations, plus a DSpark draft model for speculative decoding, plus LiteRT for on-device Android, plus a 1B sibling with the same set of variants.

• ZoomGain-4B. 4,539,265,536 parameters in BF16 across a language model and a separate vision encoder. Three GGUF precisions — Q4_K_M at 2.71 GB, Q8_0 at 4.48 GB, F16 at 8.42 GB — each paired with an mmproj projector file that the card says is mandatory for image input. No MLX build, no GPTQ, no ONNX, no draft model. The only named runtime is llama.cpp with Q​wen3.5 multimodal support, which is a narrower requirement than it sounds: you need a build recent enough to know the qwen35 architecture, and the card tells you to supply both files explicitly rather than pointing at a finished path.

The asymmetry is not a criticism of inclusionAI. A vision model that was published nine days ago and has never been announced is not expected to have an Android runtime. It is simply the state of things, and it means the two models are not interchangeable on the dimension that costs money: MiniCPM5-2B will run on the hardware you already have, including a phone; ZoomGain-4B will run on a GPU, in a runtime you may have to compile, and nowhere else.

Two different definitions of "small"

Both are called small models and the word is doing different work in each case.

• Parameters, honestly counted. MiniCPM5-2B has 1.98B non-embedding parameters — the number that governs compute per token — inside a 2.52B total. ZoomGain-4B has 4.54B total, and roughly half a billion of that is the vision encoder and projector. Strip the vision stack and the two language backbones are within a rounding error of the same size. The difference in behaviour comes from what was trained on top, not from scale.

• What the training was aimed at. MiniCPM5-2B's card lists its strongest areas as code and math reasoning, long-context understanding, tool use and agentic tasks, and names its target as local assistants, coding agents and on-device deployment. ZoomGain-4B's card is about one thing: whether a model can answer a question whose answer is visible only when you zoom into the image.

• What each publisher chose to hand over. OpenBMB published the full variant ladder for MiniCPM5 — base, midtrained, SFT, RL-plus-OPD final, plus a draft model and prebuilt binaries for nine chip families. inclusionAI published three model repos, two datasets and a code repository containing the data-construction pipeline and the GRPO launchers. One is a product line; the other is a research release with the lab notebook attached.

• Licence. MiniCPM5-2B is Apache 2.0 on the card, applied to both repository and weights. ZoomGain's code is Apache 2.0 and the checkpoint terms are deferred to the checkpoint repository, which as of this week carries no licence tag in its metadata. Read the file before you ship.

The benchmark columns, and why they do not meet

There is no shared benchmark between these two models. Not one. ZoomGainBench is a set of questions about photographs and MiniCPM5-2B has no image encoder; every other benchmark in MiniCPM5's table is text and ZoomGain-4B has never been run on any of them. So instead of a head-to-head, here is what each publisher actually measured, kept separate on purpose.

MiniCPM5-2B, vendor-reported, average 53.9 across its suite:

• Code — LiveCodeBench v6 69.1, OJBench 32.5, SWE-bench Verified 46.4.

• Math — AIME 2025 86.5, AIME 2026 86.5, MATH-500 94.6.

• Knowledge — MMLU-Pro 70.8, GPQA-Diamond 70.2.

• Long context — AA-LCR 59.0, NoLiMa 68.1, LongBench v2 43.7.

• Tool use and agents — τ²-Bench Telecom 97.1, BFCL v4 66.6, BrowseComp-ZH 43.5, GAIA Text-103 88.7.

ZoomGain-4B, vendor-reported:

• Perception, held-in benchmark — 55.81 on ZoomGainBench against 30.03 for its Qwen3.5-4B parent.

• Perception, held-out average — 60.96 across ten benchmarks the training never saw, against 54.20 for the parent. That is the 6.76-point gain worth quoting.

• Individual held-out moves — Visual Probe 43.30 to 57.28, O3-Bench 54.20 to 63.19, HR-Bench 4K 81.25 to 87.25, MME-RealWorld-Lite 57.89 to 61.59.

Read those two lists side by side and the shape of the decision is obvious. MiniCPM5-2B has been tested on seventeen things a developer cares about and scores respectably on nearly all of them; the τ²-Bench Telecom figure of 97.1 and GAIA Text-103 at 88.7 are the standout numbers and they are the ones its positioning rests on. ZoomGain-4B has been tested on perception and essentially nothing else, and the gain it delivers — about seven points on average, on unseen benchmarks — is real but narrow.

If you needed one sentence: MiniCPM5-2B is a generalist small model with an unusually deep benchmark sheet, and ZoomGain-4B is a specialist whose seven-point average gain would be invisible on a generalist leaderboard because the generalist leaderboard does not contain the questions it is good at.

Where the two would actually coexist

The workloads where both are the right answer share a shape: a document, a screenshot, a photo, a form. Something has to look at the image and extract a value, and something has to do everything after that — parse the schema, call the right tool, validate, retry, route to a human.

The extraction is ZoomGain-shaped. Small text, tight crops, an answer that is either correct or wrong, and a model that has been explicitly trained on the difference between reading a label in a crop and reading the same label in a full frame. ZoomGain-4B's held-out numbers on HR-Bench 4K (81.25 to 87.25 after training) and MME-RealWorld-Lite are exactly the profile of a model that got better at dense detail without getting worse at everything else.

The rest is MiniCPM5-shaped, and on tool use it is unusually strong for its size — τ²-Bench Telecom at 97.1 is a number that most models three times larger do not reach, and BFCL v4 at 66.6 says the function-calling is not a demo.

Running both means two runtimes, two licences, and a second thing to break. It is also where a router earns its keep rather than being a slogan: the image call goes to the vision endpoint, the tool-call turn goes to the cheap text one, and a stall on either falls over to the other automatically instead of surfacing as a 504 in your pipeline. One key, one invoice, and the failover logic in one place rather than duplicated in two SDKs.

Worth being explicit about what we do and do not carry. MiniCPM5-2B is not on our catalogue today. We do host the Q​wen3.5 family — the 35B-A3B at $0.057 in and $0.459 out per million tokens, the 27B at $0.086 and $0.688, both multimodal — and that family is the base ZoomGain-4B was trained from, which makes it the closest hosted approximation if you want to test whether crop-and-ask improves your accuracy before committing to a self-hosted 4B. For the tool-calling half, the same catalogue gives you something to call today. What we cannot do is host ZoomGain-4B, and no amount of routing changes that: it is a download, not an API.

The honest verdict

Pick MiniCPM5-2B if you want a small model you can deploy this week on hardware you already own, in a runtime that already exists, with an Apache 2.0 licence and a benchmark sheet broad enough to predict how it will behave. It is the finished object of the two. Its 1.98B non-embedding parameters make it cheap per token, its tool-calling numbers are the best thing in its column, and the chip-vendor builds mean it is not a datacentre-only proposition.

Pick ZoomGain-4B if the specific error you are trying to eliminate is visual and fine-grained, and you are willing to run a GPU with a niche llama.cpp build to fix it. Its case rests on one credible number — a 6.76-point average gain across ten held-out perception benchmarks from 9,000 training samples — and on a benchmark, data and harness that let you check the claim yourself rather than trust it.

Do not pick either if you have not yet measured what your pipeline gets wrong. MiniCPM5-2B's weakest published results are search-agent and long-document reasoning (BrowseComp-ZH 43.5, LongBench v2 43.7), and ZoomGain-4B has never been asked a question that was not about a picture. Buying either to solve a problem you have not characterised is how three-billion-parameter models end up in production doing nothing.

The unglamorous conclusion: the two models are not rivals, they are two adjacent stages of the same job, and the reason this comparison keeps getting framed as a contest is that benchmarks are easier to publish than portability. MiniCPM5-2B wins the column that gets published. ZoomGain-4B wins a column that does not exist yet, on a single task, by about seven points, and comes with a runtime requirement that would stop most teams at the door.