MiniCPM-V 4.7 vs WeVisOne-VL-4B: A Paragraph or a Polygon

The fastest way to choose between MiniCPM-V 4.7 and WeVisOne-VL-4B is to look at what comes out of them. WeVisOne-VL-4B returns coordinates: boxes normalised to a thousand-point grid, points, instance masks, and full-resolution alpha mattes produced by a 9.6-million-parameter decoder bolted onto a Qwen3-VL backbone. MiniCPM-V 4.7 returns sentences, pages of them, in a 262,144-token context that can hold a video. One of these is a perception component you wire into a pipeline. The other is a reader you ask questions. They are both Apache-2.0, both from Chinese labs, both released in October 2026 to almost no English trade-press coverage, and they are barely in the same product category.

The two arrived very differently. Tencent's WeChat Vision team put WeVisOne-VL-4B on Hugging Face and GitHub on 22 October 2026, alongside an arXiv paper and a 2B sibling, with no blog post and no press release. OpenBMB uploaded MiniCPM-V 4.7 on 6 and 7 October, dated the release 12 October in its repository, and announced it in an English PR Newswire release on 15 October that produced remarkably little English trade coverage. One arrived as a repository; the other as a repository plus a wire release. Most comparisons of them get the category wrong before they get the numbers wrong.

Two answers to the same question

WeVisOne-VL-4B is a fine-tune of Qwen3-VL that emits geometry as tokens. Boxes and points are encoded as decimal tokens from 0 to 1000, normalised to the image, and after each predicted box the model emits a special token whose hidden state feeds a separate mask decoder: a visual feature adapter, six deformable cross-attention blocks, and a cascade head that refines at stride four, two and one. The result is an instance mask and, for matting tasks, a full-resolution alpha channel. There is no second model in the loop and no SAM call; the whole pixel path is under ten million parameters attached to the language model. It is 4.83 billion parameters in bfloat16, which the model card rounds to 5B, and it takes one image per turn — video grids are rejected by the pixel decoder outright.

MiniCPM-V 4.7 is a generalist in two sizes. The 35B-A3B stores 35.2 billion parameters across 256 experts, routes eight per token for roughly 3 billion active, and holds a 262,144-token context with single-image, multi-image and video input. The 1B is a 1.55-billion-parameter dense model with the same context length and a 3.1 GB BF16 checkpoint. Both share a 27-layer SigLIP2 vision tower with mixed 4× and 16× visual-token compression, which is the mechanism that lets a quarter-million-token context stay affordable. Neither has a pointing, detection or segmentation primitive. You can ask either one where the cat is, and you will get a description of where the cat is.

That difference is not cosmetic. It determines whether your downstream code parses JSON or prose, whether a bad answer fails loudly or quietly, and whether the model can be composed with anything else without a second model to fix its output.

The numbers, and the category error waiting in them

Every figure below is vendor-reported. Tencent's come from the paper and README, with the comparison set chosen by the authors and no third-party reproduction. OpenBMB's come from the vendor model page, published as prose and chart images rather than a numeric table. Neither lab has an independent score for these models on a shared harness.

• Detection, LVIS F1 — WeVisOne-VL-4B 55.3 against the best baseline the authors list at 50.7. MiniCPM-V 4.7 publishes no detection number.

• Dense detection, Dense200 F1 — 71.3 for WeVisOne against 58.7 for the best baseline, and 15.2 for unmodified Qwen3-VL-4B. That last row is the most interesting one in the paper: the fine-tune is what turns a generalist into a localiser.

• Referring, RefCOCOg test F1 — 81.8 for WeVisOne-VL-4B against 77.6 for the strongest baseline the authors list. Its rejection rate on absent-target queries is where you should look first: 67.4 percent on RefCOCOg-Rej, 96.4 percent on the in-house WeRef-Bench, and 52.6 percent on PR-Bench. Same model, three different answers, because the distributions differ.

• Counting, PixMo-Count — 89.6 against 82.8. Segmentation, ReasonSeg val gIoU — 71.2 against 65.0.

• Matting, P3M-500-NP mean absolute difference — 7.3 against 15.4, lower being better, which is roughly half the error of the best purpose-built matting baseline the authors compared against.

• Reading, OCRBench — 91.2 for MiniCPM-V 4.7 35B-A3B and 86.1 for the 1B, against TotalText F1 of 52.0 for WeVisOne-VL-4B.

That last bullet is the trap. OCRBench measures text recognition; TotalText F1 measures text localisation. Putting 86.1 next to 52.0 and declaring a 34-point win is a category error, and it is the kind of error that gets copied from one comparison post to the next. The honest statement is that the two models were not tested on the same task, and the only thing the numbers establish is that MiniCPM is built to transcribe and WeVisOne is built to locate.

Memory is the real price

WeVisOne-VL-4B is a 9.66 GB bfloat16 checkpoint before its mask decoder, and Tencent ships no quantised variant. The 19 GB figure on the comparison card is the same checkpoint converted to F32, which doubles it; either way you still need the custom inference code: mask_decoder.pt is a required component, not an optional add-on, and a stock Transformers load will give you boxes and text but no masks. The documented serving paths are the project's own inference package, which wraps either a Transformers backend or a vLLM backend, plus a Gradio demo; greedy decoding and a cap of 1,960 visual tokens per image are the evaluation settings. This is a GPU service.

MiniCPM-V 4.7 35B-A3B is roughly 70 GB of BF16 weights across sixteen shards, which is worse on paper and better in practice because only about 3 billion parameters are active per token. OpenBMB's entire pitch is that the inactive experts can be streamed from storage rather than held in memory, using Lookahead Expert Scheduling to prefetch the experts the next layer is likely to need, plus layer-wise quantisation and DSpark speculative decoding. The vendor claim is 13 or more tokens per second on an iPhone 17 Pro Max using about 3 GB of memory. Nobody independent has reproduced that, and the claim depends on all three techniques working together rather than any one of them.

The 1B changes the economics completely: 3.1 GB at BF16, about 0.67 GB as a Q4_K_M GGUF, which is why the esp32-eye cat monitor can run it on a MacBook as a gate that fires at most every 1.5 seconds. The same build found the 1B unreliable at telling four similar cats apart, so it is a presence detector rather than a fine-grained recogniser — a useful boundary for anyone planning to use it as a cheap classifier.

Put plainly: WeVisOne buys geometry with 9.66 GB and a GPU. MiniCPM buys reading with 70 GB or 3 GB depending on which size you take, and a phone-class runtime if OpenBMB's scheduling claims hold.

What breaks in production

WeVisOne's failure modes are documented and specific. Alpha quality degrades on fine boundaries, heavy occlusion and genuinely transparent materials. The model is sensitive to prompt wording, so "the woman's hair" and "her hair" are not guaranteed to return the same matte. It cannot take video, it has no chain-of-thought, so there is no way to ask it to reason about an ambiguous query before committing to a box, and its rejection behaviour has a weak spot the paper's headline number hides: 96.4 percent on WeRef-Bench but around 52.6 percent on PR-Bench. A component that refuses absent targets most of the time is useful; one that refuses them half the time on a different distribution needs a guard.

MiniCPM-V 4.7's failure modes are the generalist's: it will describe an image fluently whether or not the description is grounded, and there is no rejection channel at all. Nothing in the card tells you when the model does not know. For a reader that is tolerable — a human reads the paragraph. For a pipeline that needs a box, it is disqualifying, because you would be parsing prose into coordinates and hoping.

If what you need is a hosted general vision model this week rather than a self-hosted specialist, neither of these is in OrcaRouter's catalogue, and it is worth saying so before the pitch: the practical route is a general-purpose model that is hosted, called through one key across more than 200 models at 0% markup on provider list prices, with automatic failover if an upstream endpoint wobbles. That gets you a working pipeline; it will not give you alpha mattes, and it is a different product from either of the two models this page is about.

Choosing between them

Take WeVisOne-VL-4B if your output is geometry: counting objects in a retail shelf, cutting a product out of a photo, highlighting a region for a user, or refusing when the thing is not there. The matting number is genuinely unusual, the rejection channel is a real engineering feature, and the 9.66 GB is the price of a component that returns something a program can use.

Take MiniCPM-V 4.7 35B-A3B if your output is understanding: a long PDF, a dashboard, a video, a page of mixed text and figures. Take the 1B if you need a cheap gate in front of something more expensive, and do not ask it to tell two similar cats apart.

The comparison that would actually settle this does not exist yet: an independent harness that runs both models on the same detection and OCR set, with the same image budget. Until someone publishes it, the defensible position is the boring one — these models do different jobs, the vendor tables do not overlap, and the only number that should move your decision is the size of the thing you have to deploy.