MiniCPM-V 4.7 vs NVIDIA Nemotron 3.5 Super VL: The Cheapest Box That Actually Runs Each One

Both of these are open-weight vision-language models, both are mixture-of-experts, and both compress visual tokens before the language model sees them. The decision between MiniCPM-V 4.7 35B-A3B and NVIDIA Nemotron 3.5 Super VL is therefore not a decision about architecture. It is a decision about the smallest machine you are willing to buy, and about what that machine buys you in pages per hour. Priced that way, the two models land in different procurement conversations entirely: one runs off a 21 GB download on hardware you probably already own, the other wants four H100s in BF16 or a single H200 in FP4. This piece does the arithmetic that the spec sheets leave to you — memory tier by memory tier, and page by page. The vision stack stays on your hardware. The orchestration around it does not have to. See the hosted catalogue 200-plus hosted models on one key, list price passed through at 0% markup. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

Two quantisation ladders, two very different floors

OpenBMB and NVIDIA solved the same problem — a model too large for the device you want to run it on — in opposite directions. MiniCPM-V 4.7 35B-A3B keeps a small active set resident and streams experts in from storage, then ships the whole thing in every GGUF size so you can pick your floor. Nemotron 3.5 Super VL keeps the full model resident and instead trains a 4-bit tier (NVFP4) that cuts the memory requirement roughly fourfold without a post-hoc quantisation penalty.

• MiniCPM-V 4.7 35B-A3B, Q4_K_M — 21.2 GB on disk. Fits a 24 GB consumer GPU with a thin margin, or a 32 GB Mac with room to spare.

• MiniCPM-V 4.7 35B-A3B, Q8_0 / F16 — 36.9 GB / 69.4 GB. A 48 GB card or a 96 GB workstation, depending on how much context you want alongside the weights.

• Nemotron 3.5 Super VL, BF16 — roughly 231.8 GiB of weights across 64 shards. NVIDIA's own serving recipe is tensor-parallel 4 on 4x H100, or TP2 on 2x GB200.

• Nemotron 3.5 Super VL, NVFP4 — deploys on 1x DGX Spark, 1x H200, 2x H100 or 1x GB200, per its model card.

That last line is the number that changes the purchasing conversation. A 120B model on one H200 instead of four H100s is not a marginal saving; it is the difference between a cluster reservation and a single node. And because NVIDIA does the 4-bit conversion during training with quantisation-aware distillation rather than after the fact, it claims no inference overhead — a claim the card states but does not substantiate with a published BF16-versus-NVFP4 accuracy delta.

Pages per hour, which is the number that decides anything

Throughput in tokens per second is a poor proxy for document work, because the cost of a page is dominated by how many visual tokens the encoder emits before the language model says a word. This is where the two designs diverge most sharply, and where the marketing language is least useful.

MiniCPM-V 4.7 35B-A3B compresses inside the vision tower, using an early-compression technique OpenBMB credits to LLaVA-UHD v4, with mixed 4x and 16x downsampling. The default is 16x; 4x is the fine-detail path, chosen per image. A dense page of text gets the cheap path, a parts diagram gets the expensive one. The compression happens before the language model is involved, which is precisely what makes a 35B model viable on a phone.

Nemotron 3.5 Super VL does not lead with compression. Its answer is context: up to one million tokens, video input up to two minutes, and a hybrid Mamba-2 layer to keep a very long sequence from becoming quadratic. Its video recipe samples at 2 FPS and 256 frames by default, dropping to 1 FPS and 128 frames at 1080p — a sampling policy rather than a compression trick, and one you can tune upward if the workload is dense motion.

The practical consequence: MiniCPM-V 4.7 gives you a fixed, low per-page token cost and asks you to accept the detail loss; Nemotron 3.5 Super VL lets you keep the detail and asks you to pay for the context. For a hundred-page contract review, the first is cheaper per page and the second is better at the page where the clause is in a 6-point footnote. For a two-minute surgical video, only the second is in the conversation at all.

One of these releases ships numbers; the other ships charts

This is the part of the comparison that no amount of hardware arithmetic fixes, so it belongs here rather than buried in a footnote.

NVIDIA's model card carries a benchmark table of roughly forty rows, and it is unusually forthcoming: it names the baselines, and several rows show the model losing. Against Qwen3.5-122B-A10B, its own numbers put MMLU-ProX at 76.91 versus 83.2, tau2-bench telecom at 73.19 versus 87.2, OCRBench v2 Chinese at 59.15 versus 67.3, and MathVision at 78.16 versus 83.3. It wins GPQA-Diamond 89.52 to 86.7, SWE-bench Pro 51.78 to 44.9 and CritPt 10.86 to 1.1. Every figure, including the baselines, was collected through NVIDIA's own NeMo Gym harness — the card says so directly, and publishes reproducibility notes. Vendor-run, honestly labelled, with the losses left in.

MiniCPM-V 4.7's card carries five evaluation charts and no numeric table. The comparative claims are directional: a higher overall score in less inference time than Qwen3.6 35B-A3B in Instruct mode, and substantial gains over Qwen3.5 0.8B for the 1B variant. There is no per-benchmark score to quote, no baseline list to inspect, and no published weighting for the composite being plotted. That is not the same as a bad model — the engineering is documented in config.json and the weights are checkable byte for byte — but it does mean the accuracy half of this comparison cannot be built. Anyone who presents a table of MiniCPM-V 4.7 scores against Nemotron 3.5 Super VL numbers is reading one vendor's chart as if it were a measurement and the other's table as if it were neutral.

The runtime paths, and which one bites you later

MiniCPM-V 4.7's deployment story is a menu: SGLang, vLLM, llama.cpp and Ollama, an OpenVINO path for Intel CPU, GPU and NPU, fine-tuning through SWIFT and LLaMA-Factory, quantisation in GGUF, BNB, AWQ, GPTQ and FP8, and day-0 support claimed for Rockchip, Houmo, Intel, AMD and Arm silicon alongside iOS, Android and HarmonyOS. Breadth is the product. The cost of breadth is that nobody has validated your particular combination, and the current upstream llama.cpp path has a live defect: image marker positions are computed incorrectly, so returned coordinates sit systematically low when you ask where something is. A tested fix is open and unmerged as of 20 October.

Nemotron 3.5 Super VL's story is narrow and deep: vLLM at a pinned image tag and SGLang at a pinned tag, with Multi-Token Prediction built into the architecture so no separate drafter is needed. The card specifies versions because the versions are the validated combination. Drifting from them is how a working deployment becomes a debugging session.

If you are choosing hardware to fit the model, take MiniCPM-V 4.7. If you are choosing a model to fit hardware you already have, take Nemotron 3.5 Super VL and follow its card's versions exactly.

Where a router belongs in a two-box architecture

The pattern that shows up in production is not a choice between these two. It is a small model on the device or the local box doing work that must be instant and private, and a large model handling work that must be right. MiniCPM-V 4.7 35B-A3B is built for the first role; Nemotron 3.5 Super VL is built for the second, with a one-million-token window and 12B active parameters to carry long documents and agentic loops.

Running both means two model stacks, two sets of failure modes and — once you add a text model for the orchestration around them — three. That is where OrcaRouter helps without overstating what it is: neither checkpoint is in our catalogue, because both are open weights you host yourself, but the text and code models that surround them are. One key across 200-plus hosted models, provider list price passed through with 0% markup, and automatic failover when an upstream degrades. The vision stack stays on your hardware; the rest of the pipeline stops needing a new contract every time you add a stage.

What each one costs you to be wrong about

Buy the small box and discover you needed long-document reasoning, and you have spent a few thousand dollars and a week. Buy four H100s and discover the workload was receipts, and you have spent a great deal more for capability you never invoke. That asymmetry is the real argument for starting on the cheap tier and escalating — and it is why the on-device release deserves the attention it is getting even though its benchmark story is thinner.

The tiebreaker, if you have both boxes available, is where the pixels live. Frames that cannot leave the building go to the model that runs inside it. Frames that need a million tokens of context and a reasoning loop go to the one that was built for that, and you accept the pinned runtime versions as the price of admission.