MiniCPM-V 4.7 35B-A3B vs PixelUMM: One Licence Decides This Before the Benchmarks Do

There is a decision you can make between MiniCPM-V 4.7 35B-A3B and PixelUMM without reading a single benchmark, and it is probably the decision that matters most. MiniCPM-V 4.7 35B-A3B is Apache-2.0. PixelUMM's model checkpoint is not — it ships under NVIDIA's One-Way Noncommercial License, which permits research and evaluation only, on a checkpoint that NVIDIA itself says "has not been validated for production or high-stakes use." If you are building something you intend to sell, one of these two models is a non-starter and the rest of the comparison is academic. If you are doing research, the field opens up, and the interesting question becomes what NVIDIA's encoder-free design is actually betting against — because it is betting against exactly the architecture MiniCPM-V 4.7 uses.

Both models shipped quietly. PixelUMM's weights landed on Hugging Face at 21:40 UTC on 1 October 2026 with no blog post, no press release and no keynote; the project page URL still reads "preview". MiniCPM-V 4.7 appeared on 6 October the same way, and OpenBMB did not put a model card, a licence or a claims section on it until 12 October. Neither has been independently evaluated by anyone, and neither has a benchmark table a reader can quote — PixelUMM's card reports no scores at all, and MiniCPM-V 4.7's performance claims live inside chart images rather than in text. What follows separates what the repositories state from what nobody outside the two labs has yet confirmed.

What PixelUMM is, in one paragraph

PixelUMM is a 15,199,672,064-parameter decoder-only Transformer with an iterative pixel-generation head, built on a Qwen3-8B backbone pinned to a specific revision. Its thesis is stated in the first line of the model card and it is genuinely contrarian: no VAE and no vision encoder. Where a conventional unified model carries two visual interfaces — a vision transformer producing semantic features for understanding and a variational autoencoder producing reconstruction latents for generation — PixelUMM carries neither. Images are cut into 16-by-16 pixel patches, video into four-frame spatiotemporal tubelets, and both reach the backbone through nothing more than single-layer linear projections, with iterative denoising doing the generation work. The paper describes it as a Mixture-of-Transformers pairing shared attention with task-specific parameters. It handles text-to-image, image-conditioned text generation, video-conditioned understanding and video generation, including text-to-video at 96 frames, 24 fps and four seconds.

The trail around it ran about four weeks, all of it quiet. The GitHub repository nv-tlabs/PixelUMM was created on 4 September 2026 under Apache-2.0 and sat with a single commit for most of the month. On 28–29 September the initial commit landed and arXiv assigned preprint 2609.38597, whose author list runs across NVIDIA and the University of Waterloo. The model repository itself appeared at 21:40 UTC on 1 October, eight minutes after a final GitHub commit adding the paper citation. The paper carries no venue line — no conference, no "accepted to" — which reads like a research team pushing an artifact live rather than a product launch, though that is an observation about the evidence and not a claim about intent.

What MiniCPM-V 4.7 35B-A3B is

MiniCPM-V 4.7 35B-A3B is OpenBMB's first MoE entry in the MiniCPM-V series: 256 experts with 8 active per token, 40 layers, a 262,144-token context window and a 248,144-token vocabulary, giving roughly 3B active parameters out of 35.2B total. Vision runs through a SigLIP2 module with LLaVA-UHD v4 intra-ViT early compression and a selectable mixed 4x/16x visual token compression mode — 16x by default for throughput, 4x when fine detail matters. It understands single images, multiple images and video, and it answers in text. It does not generate images.

The card's headline claim is that this is the first open-source MoE model with lossless, smooth on-device inference, delivered by Lookahead Expert Scheduling, fine-grained layer-wise quantisation and speculative sampling through the separate DSpark drafts, at a reported 13-plus tokens per second on an iPhone 17 Pro Max. That figure is vendor-reported, unreproduced and unqualified. The card also claims a higher overall Instruct-mode score than Qwen3.6 35B-A3B in less inference time — a claim that appears inside a chart image, which means it is not a quotable number and should not be treated as one.

Where MiniCPM-V 4.7 is unambiguously ahead is not on any scoreboard but in the supporting cast, all of which is real and downloadable: base, FP8, int4, AWQ, GPTQ and GGUF weights; support across SGLang, vLLM, llama.cpp, Ollama and OpenVINO; iOS, Android and HarmonyOS apps; and Rockchip, Houmo, Intel, AMD and Arm listed for day-zero silicon. Six weeks ago the honest criticism of this model was that it was an undocumented checkpoint. That is no longer true — it is a documented checkpoint with no benchmarks. Different problem, smaller one.

The architecture argument hiding behind the comparison

The two models disagree about something fundamental, and it is worth naming because it is the part of this matchup with a shelf life longer than either model.

• How vision reaches the language model — PixelUMM uses raw pixels and a single linear projection, with no pretrained vision encoder anywhere in the stack; MiniCPM-V 4.7 uses a SigLIP2 encoder with intra-ViT early compression and a configurable downsample ratio.

• How generation works — PixelUMM predicts pixels iteratively through a flow-matching head trained jointly with autoregressive text prediction; MiniCPM-V 4.7 generates text and nothing else.

• What that buys — PixelUMM gets one set of weights that both describes an image and produces one, at the cost of a research-only licence and no production validation; MiniCPM-V 4.7 gets a small, quantisable, phone-deployable model that can read the world but not redraw it.

• Parameter count — 15.2B dense-ish against 35.2B total with 3B active. The active-parameter count is the one that predicts inference cost, and on that axis the MiniCPM model is the smaller of the two by an order of magnitude.

• Weights on disk — PixelUMM's repository carries 491 files across four checkpoint variants; MiniCPM-V 4.7's base build is sixteen BF16 shards at roughly 70 GB.

• Licence — Apache-2.0 versus NVIDIA One-Way Noncommercial for the checkpoint, with Apache-2.0 applying only to PixelUMM's source code and the Qwen3-8B base being separately Apache-2.0. The PixelUMM card also notes it includes modified code derived from BAGEL, so upstream terms apply on top.

• Public evaluation — none, on both sides. MiniCPM-V 4.7 at least makes performance claims; PixelUMM's card states no benchmark numbers at all.

Which one you can actually put in front of a user

Follow the licence and the deployment story together and the choice mostly makes itself.

PixelUMM is the more interesting research artifact and the less usable product. A noncommercial checkpoint blocks the obvious commercial uses outright, there is no serving recipe on the card, no quantised build, no context-length figure, and 83 likes against zero recorded downloads means essentially nobody outside the authors has run it. Its value right now is as a strong, published argument that vision encoders may be unnecessary in unified models. That argument is worth tracking whether or not you ever load the weights.

MiniCPM-V 4.7 is the one with a path to production, and the path is narrow but real. Apache-2.0 removes the licensing question. Six quantisation formats and five inference runtimes mean you are not writing custom kernels. Two or more GPUs for the unquantised build is the barrier; the quantised builds and the on-device story are the workaround, and the on-device claim is precisely the one that has not been independently verified. Treat it as a model you can run today and a performance claim you cannot yet bank on.

For teams whose answer is "neither, we will call something", the closest hosted equivalent to the MiniCPM shape is Qwen3.6 35B A3B — same 35B total, same 3B active, same 262K context, same text-image-video intake — and it is served through OrcaRouter at the provider's list price with zero markup, $0.25 per million input tokens and $1.48 per million output tokens, with automatic failover if a provider route degrades. That is not a substitute for either model in this article; it is the control group that tells you what self-hosting a 70 GB sparse multimodal MoE is actually buying you.

Where this lands

Strip out the architecture and you are left with two quiet releases pointing in opposite directions. NVIDIA published a paper-grade artifact under a licence that stops most people using it, and a repository with no recipe, no benchmarks and no downloads. OpenBMB published a documented, permissively licensed, multi-runtime model with a compelling efficiency claim and no evaluation table to support it.

The one thing that would settle each: for PixelUMM, any independent reproduction at all — 0 downloads means there is no outside datapoint in existence, and the encoder-free thesis is exactly the kind of claim that either holds up or falls apart on contact with a second implementation. For MiniCPM-V 4.7, a benchmark table, or a reproduced acceptance length on the DSpark draft, which is the only part of the family carrying published numbers. Neither exists yet. Both are the reason these two models are still worth watching rather than filing away — they are earlier in their public life than the coverage suggests, and neither has been called a launch by the lab that made it.