NVIDIA Nemotron 3.5 Super VL vs MiniCPM-V 4.7 35B-A3B: 3 GB in a pocket against 4× H100 in a rack

One of these runs on an iPhone. The other runs on four H100s. That is the whole comparison, and everything else is detail. MiniCPM-V 4.7 35B-A3B is OpenBMB's first Mixture-of-Experts entry in the MiniCPM-V line, and the model card's claim is specific enough to check: more than 13 tokens per second on an iPhone 17 Pro Max using roughly 3 GB of memory, with the run described as smooth rather than as a demo. N​VIDIA N​emotron 3.5 Super VL is a 120B-total, 12B-active vision-language model whose card puts the deployment envelope at 4× H100 or 2× GB200. Both are open weights. Both are vision-language models. They are not options for the same decision.

What makes them worth comparing anyway is that they agree on the mechanism and disagree on the scale. Both are Mixture-of-Experts models built to trade total size for per-token cost. Both compress visual tokens before the language model has to think about them. Both are betting that the future of vision-language work is many models in many places rather than one large model behind one API. They just placed their bets three orders of magnitude apart in hardware.

The active-parameter coincidence

N​VIDIA N​emotron 3.5 Super VL is 120B total with 12B active per token — a Mamba-2–Transformer hybrid MoE with a C-RADIO vision encoder and 512 routed experts per MoE layer, holding up to 1M tokens of context. MiniCPM-V 4.7 35B-A3B is 35B total with 3B active. Different by a factor of four in total size and four in active compute, but the same architectural instinct: keep the parameter count high for knowledge and the per-token cost low for speed.

OpenBMB's contribution to that problem is Lookahead Expert Scheduling, which is what lets a 3B-active model keep its experts resident without thrashing the memory bus — the reason it can run in 3 GB rather than needing a workstation. The implementation lives in a fork, llama.cpp-omni, and the claim attached to it is careful: the first open-source MoE model to run smoothly on-device without compromising performance. Whether "without compromising" holds against a 120B model is not something the card addresses, and it should not — a model that runs on a phone is not competing with one that needs four H100s on accuracy. It is competing on being there at all.

• Total / active parameters — N​emotron 3.5 Super VL: 120B / 12B. MiniCPM-V 4.7 35B-A3B: 35B / 3B.

• Deployment target — N​emotron 3.5 Super VL: 4× H100 or 2× GB200, served via vLLM or SGLang. MiniCPM-V 4.7 35B-A3B: phone, laptop, edge box — iOS, Android and HarmonyOS are all named.

• Memory at the smallest end — N​emotron 3.5 Super VL: not applicable. MiniCPM-V 4.7 35B-A3B: about 3 GB.

• Context — N​emotron 3.5 Super VL: up to 1M tokens, video up to two minutes. MiniCPM-V 4.7 35B-A3B: not the model's selling point; the card leads on footprint and speed.

• Licence — N​emotron 3.5 Super VL: OpenMDW-1.1. MiniCPM-V 4.7 35B-A3B: Apache-2.0.

Two different answers to "tokens are expensive"

Both teams attacked the same bottleneck — the number of visual tokens a picture costs — and arrived at different places.

MiniCPM-V 4.7 35B-A3B does it inside the vision encoder, with early compression derived from LLaVA-UHD v4, and then uses mixed 4× and 16× visual-token compression depending on what the image needs. Fine detail gets the expensive path; a receipt gets the cheap one. The compression happens before the language model is involved, which is what makes the on-device numbers possible.

N​emotron 3.5 Super VL does not lead with token compression at all. Its answer is context: 1M tokens, so you can afford to keep the detail rather than throw it away, and a hybrid Mamba-2 layer to keep the cost of a very long sequence from exploding. The model's own video path is configured generously by default — 2 FPS and 256 frames, dropping to 1 FPS and 128 frames at 1080p — which is a sampling answer, not a compression answer.

Those are incompatible philosophies and both are correct for their deployment. If you have 3 GB, you compress. If you have 4× H100, you keep the detail and pay for context.

What the numbers can and cannot tell you

Here is the honest position on both sides.

N​emotron 3.5 Super VL's benchmark table is broad and vendor-collected through NeMo Gym: GPQA-Diamond 89.52, SWE-bench Verified 71.10, MMLongBench-Doc 62.82, OCRBench v2 at 68.12 English and 59.15 Chinese, CharXiv reasoning 80.82, V* 85.60. N​VIDIA chose the baselines. None of it has been independently reproduced.

MiniCPM-V 4.7 35B-A3B's card presents its benchmark results as vendor charts rather than a numeric table, so there is no figure to quote and no baseline list to inspect. The strongest specific claim in the card is comparative and directional — a higher overall score in less inference time than Qwen3.6 35B-A3B in Instruct mode — which is a claim about efficiency within its own weight class, not about capability against a model twelve times its size.

So a comparison table of these two on benchmark numbers does not exist and cannot be built. Anyone presenting one is combining a vendor chart with a vendor table and calling the result a measurement.

The deployment detail that decides more projects than accuracy does

MiniCPM-V 4.7 35B-A3B shipped with day-0 support for Rockchip, Houmo, Intel, AMD and Arm silicon, alongside SGLang, vLLM, llama.cpp and Ollama, and quantization in GGUF, BNB, AWQ, GPTQ and FP8. It also integrates with SWIFT and LLaMA-Factory for fine-tuning. That list is the real product. A model that runs on the accelerator you already bought, in the quantization format your runtime already supports, is a model you can ship this quarter.

N​emotron 3.5 Super VL's runtime story is narrower and deeper: vLLM at vllm/vllm-openai:v0.32.0 and SGLang at lmsysorg/sglang:v0.5.20, with EAGLE speculative decoding at topk 1 and Multi-Token Prediction built into the architecture. Two runtimes, both first-class, both specified to the exact version. That is what a datacenter deployment wants — a validated path, not a menu.

If you are choosing hardware to fit the model, take MiniCPM-V 4.7 35B-A3B. If you are choosing the model to fit hardware you already have, take N​emotron 3.5 Super VL and follow its card's versions exactly.

The case for running both

The pattern that shows up in real products is not a choice between these two. It is a small VLM on the device handling the work that has to be instant and local — reading a form, describing a scene, filtering out the frames nobody cares about — and a large VLM in the datacenter handling the work that has to be right. MiniCPM-V 4.7 35B-A3B is explicitly designed for the first role. N​emotron 3.5 Super VL is designed for the second.

That architecture has a cost, and the cost is that you are now running two model stacks and a text stack, with three sets of credentials and three sets of failure modes. OrcaRouter is the part that removes the second problem: 207 models behind one key at provider list price with zero markup, so a vendor price change lands on your bill the same day, and automatic failover when an upstream degrades. Neither N​VIDIA N​emotron 3.5 Super VL nor MiniCPM-V 4.7 35B-A3B is in that catalogue — both are open weights you host yourself, which is the point of choosing either. What one key gets you is the surrounding text and code models, so the pipeline does not need a new contract every time you add a stage.

Which one, decided by where the pixels are

Take MiniCPM-V 4.7 35B-A3B if the inference has to happen where the data is — on a phone, in a vehicle, on a factory floor, in a clinic where the image cannot leave the building — or if your users are offline, or if the per-call cost of a hosted VLM is the thing killing the unit economics. Its licence is Apache-2.0, its quantization menu is wide, and its silicon support list is deliberately long.

Take N​VIDIA N​emotron 3.5 Super VL if the work is long-context and reasoning-heavy: multi-page documents, mixed layouts, charts that need interpretation, two-minute video clips, agentic tool use. The 1M-token context and 12B active parameters are the reason it exists, and no on-device model substitutes for them.

If you are unsure, the deciding question is not accuracy. It is whether the image is allowed to leave the device. That answer picks the model before any benchmark is consulted.

MiniCPM-V 4.7 35B-A3B's card is the source for the on-device claims — the 13-plus tokens per second, the roughly 3 GB footprint, the day-0 silicon list and the quantization formats — all of which are the model's own reported results. Read the silicon list before you commit, because "supported" there means a runtime path exists, not that your specific board has been benchmarked.

N​VIDIA's N​emotron developer page is where the 4× H100 / 2× GB200 guidance and the runtime versions are published, along with the link to the technical report behind the benchmark table. The version numbers in the card are exact for a reason: vLLM v0.32.0 and SGLang v0.5.20 with EAGLE topk 1 are the validated combination, and drifting from them is how a working deployment becomes a debugging session.

The larger point is that the vision-language field has stopped converging on one shape. OpenBMB is pushing a 3B-active model into pockets and N​VIDIA is pushing a 12B-active model across a million tokens of context, in the same month, under licences that both permit commercial use. Picking between them is picking a deployment, and the deployment is decided by where the pixels live.

Benchmarks age and prices move; the failure record does not: the documented AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.