WeVisOne-VL-4B vs MiniCPM-V 4.7 1B: Two Opposite Bets on What a Visual Token Is For

MiniCPM-V 4.7 1B scores 86.1 on OCRBench. WeVisOne-VL-4B scores 52.0 on TotalText. Put those two numbers beside each other and the 1B model appears to beat the 4B model by thirty-four points on reading text — which would be a remarkable result, and is also a category error. OCRBench measures whether a model can transcribe the characters in an image. TotalText, as Tencent reports it, measures F1 for localizing each text instance across IoU thresholds from 0.5 to 0.95. One is recognition, the other is geometry. MiniCPM-V 4.7 1B and WeVisOne-VL-4B were released nine days apart in October 2026, both from Chinese labs, both Apache 2.0, and they disagree fundamentally about what visual tokens are for: one compresses them away, the other spends them on precision.

That disagreement is the whole comparison. Everything else — parameter counts, memory, benchmark rows — follows from it.

Compression versus precision

MiniCPM-V 4.7 1B inherits an intra-ViT early compression scheme from LLaVA-UHD v4 and exposes it as a runtime switch between 4× and 16× visual token compression. The point is to fit more image, and more video, into a fixed budget: the model card claims a 262,144-token context, a default of 128 video frames, and a 448×448 tiling scheme with a configurable slice count. Compress early, keep the sequence short, and a 1B model can look at a long video on a phone.

WeVisOne-VL-4B makes the opposite trade. Its evaluation runs at up to 1,960 visual tokens per image and its pixel decoder operates on pre-merging ViT features, deliberately keeping the high-resolution detail that early compression throws away. That is why it can produce a full-resolution alpha matte at stride 1 and why it cannot process a video grid at all: the decoder rejects it. Precision costs tokens, and tokens cost latency.

Neither bet is wrong. They are answers to different questions. MiniCPM asks "how much can I see at once on a phone?" WeVisOne asks "how exactly can I describe where a thing is?"

The size story is stranger than 1B versus 4B

• Parameters — WeVisOne-VL-4B 4.83B dense vs MiniCPM-V 4.7 1B named as 1B, though its repository metadata lists 2B in BF16

• Weight format — F32 safetensors at roughly 19 GB vs BF16 at about 3.1 GB, or 0.67 GB at Q4_K_M plus a 0.90–1.11 GB vision projector

• Context — not published for WeVisOne-VL-4B vs 262,144 tokens on paper for MiniCPM-V 4.7 1B

• Video — rejected by the pixel decoder vs 128 frames by default

• Multimodal input — single image per turn vs image and video

• Quantization — none shipped by the vendor vs int4, AWQ, GPTQ, GGUF and FP8 variants

• On-device runtimes — none vs iOS, Android, HarmonyOS, plus llama.cpp and Ollama

• License — Apache 2.0 for Tencent-authored code vs Apache 2.0

The memory row is the one that reframes the comparison. A 1B model at four bits fits in under a gigabyte before the vision projector; a 4.83B model in F32 needs roughly nineteen. These are not competitors for the same slot. One is a component you ship inside an application; the other is a service you run on a GPU.

Reading the benchmark rows without fooling yourself

Both vendors published tables, and both tables are self-selected. MiniCPM-V 4.7 1B reports OCRBench 86.1, MathVista 74.3, CharXiv Reasoning 48.8, LongVideoBench 53.4 and MotionBench 54.55. WeVisOne-VL-4B reports LVIS F1 mean 55.3, RefCOCOg test 81.8, PixMo-Count test 89.6, TotalText F1 mean 52.0, ReasonSeg val gIoU 71.2 and P3M-500-NP MAD 7.3. Not one benchmark appears in both lists. There is no defensible way to compute a winner from these documents, and any article that does is inventing a result.

The fair reading is narrower and still useful. MiniCPM-V 4.7 1B is unusually strong at reasoning over images for its size — a 74.3 on MathVista from a model that fits in a phone is the number its authors are proudest of, and it is vendor-reported and unreproduced. WeVisOne-VL-4B is unusually strong at producing geometry — masks, mattes, boxes, and a measured refusal rate of 96.4% on WeRef-Bench when the object is not present. MiniCPM's card publishes no rejection metric, and WeVisOne's publishes no reasoning benchmark. Each model is silent exactly where the other is loud.

What each one cannot do

WeVisOne-VL-4B cannot watch a video, cannot hold a multi-turn conversation about an image, and cannot run on a phone. It has no published tokens-per-second figure and no quantized builds, which means anyone deploying it is committing to a GPU and to benchmarking the throughput themselves. The fine-tuning code is still an unchecked box on the project's TODO list.

MiniCPM-V 4.7 1B cannot return a mask or an alpha matte. It will tell you a person is in the image and roughly where; it will not hand you a soft-edged cutout. It also carries the ordinary risks of a brand-new model family: a new model_type in Transformers, a minimum version requirement of 5.18.0, and early reports of video-decoding breakage in some CUDA and torchcodec combinations. Its 262K context is a paper figure — post-training has not been shown to exploit it fully.

The cost of a second call

In practice these two models are not substitutes, and the interesting architecture uses both: a small, cheap model to describe and reason about the image, and a perception model to return the geometry. That turns one inference call into two, which is where cost stops being a footnote.

OrcaRouter's contribution to that shape is the boring one that matters — a single key across more than 200 models, with provider list price passed through at 0% markup and automatic failover when an upstream endpoint degrades. A vendor price cut on the generalist side lands on our side the same day, because there is no markup layer to update. Neither WeVisOne-VL-4B nor MiniCPM-V 4.7 1B is in that catalogue today, so the perception half of the pipeline is still something you host. What you avoid is a second contract and a second set of credentials for the half that is.

How you would run either one

WeVisOne-VL-4B is the more demanding install. The model card documents Transformers, vLLM, SGLang and Docker Model Runner, but mask_decoder.pt is a required component: load the checkpoint without the project's inference package and you get boxes and text, no masks. Decoding is greedy at up to 1,960 visual tokens per image, and there is no published throughput figure, so the first thing you will do on your own hardware is measure it.

MiniCPM-V 4.7 1B is the easier one. It needs Transformers 5.18.0 or newer, and the ecosystem arrived with it — llama.cpp, Ollama, SGLang and vLLM builds, plus int4, AWQ, GPTQ and FP8 quantizations, and a separate 213M-parameter DSpark draft model for speculative decoding. If your target is a phone, an Intel box or a Rockchip board, this is the path with paved road on it.

Which bet to take

If the constraint is the device, take MiniCPM-V 4.7 1B. Nothing about WeVisOne-VL-4B is designed for a phone, and the quantization, runtime support and video handling on the MiniCPM side are the product of a lab that has shipped several generations of on-device models.

If the constraint is the output — you need masks, mattes, dense small-object boxes, or a reliable "not present" answer — take WeVisOne-VL-4B and budget for the GPU. Understand that you are working from a two-day-old paper with no independent evaluation, and that the matting numbers are Tencent's own.

If you need both, you need two models. That is the honest conclusion, and it is the one both vendors' own benchmark tables support: they optimized for different things and neither one tried to beat the other.