MiniCPM-V 4.7 35B-A3B vs PixelUMM: una licenza lo decide prima che lo facciano i benchmark

C'è una decisione che puoi prendere tra MiniCPM-V 4.7 35B-A3B e PixelUMM senza leggere un singolo benchmark, ed è probabilmente la decisione che conta di più. MiniCPM-V 4.7 35B-A3B è Apache-2.0. Il checkpoint del modello di PixelUMM non lo è: viene distribuito con la One-Way Noncommercial License di NVIDIA, che consente solo ricerca e valutazione, su un checkpoint che NVIDIA stessa dichiara "non è stato validato per la produzione o per usi ad alto rischio". Se stai costruendo qualcosa che intendi vendere, uno di questi due modelli è un non-starter e il resto del confronto è accademico. Se fai ricerca, il campo si apre, e la domanda interessante diventa contro cosa scommette davvero il design senza encoder di NVIDIA — perché scommette esattamente contro l'architettura che MiniCPM-V 4.7 utilizza.

Entrambi i modelli sono stati rilasciati in sordina. I pesi di PixelUMM sono approdati su Hugging Face alle 21:40 UTC del 1° ottobre 2026 senza alcun post sul blog, alcun comunicato stampa né alcun keynote; l'URL della pagina del progetto riporta ancora "preview". MiniCPM-V 4.7 è apparso il 6 ottobre allo stesso modo, e OpenBMB non vi ha inserito una scheda del modello, una licenza o una sezione di dichiarazioni fino al 12 ottobre. Nessuno dei due è stato valutato in modo indipendente da alcuno, e nessuno dei due ha una tabella di benchmark che un lettore possa citare — la scheda di PixelUMM non riporta alcun punteggio, e le dichiarazioni sulle prestazioni di MiniCPM-V 4.7 si trovano all'interno di immagini di grafici anziché nel testo. Ciò che segue separa ciò che dichiarano i repository da ciò che nessuno al di fuori dei due laboratori ha ancora confermato.

Che cos'è PixelUMM, in un paragrafo

PixelUMM è un Transformer decoder-only da 15.199.672.064 parametri con una testa di generazione pixel iterativa, costruito su un backbone Qwen3-8B fissato a una revisione specifica. La sua tesi è enunciata nella prima riga della scheda del modello ed è autenticamente controcorrente: nessun VAE e nessun encoder visivo. Dove un modello unificato convenzionale possiede due interfacce visive — un vision transformer che produce feature semantiche per la comprensione e un autoencoder variazionale che produce latenti di ricostruzione per la generazione — PixelUMM non ne possiede nessuna. Le immagini vengono tagliate in patch di pixel 16x16, i video in tubelet spazio-temporali di quattro frame, ed entrambi raggiungono il backbone attraverso nient'altro che proiezioni lineari a singolo strato, con il denoising iterativo che svolge il lavoro di generazione. L'articolo lo descrive come un Mixture-of-Transformers che abbina attenzione condivisa a parametri specifici per attività. Gestisce text-to-image, generazione di testo condizionata da immagini, comprensione condizionata da video e generazione di video, incluso text-to-video a 96 frame, 24 fps e quattro secondi.

La traccia intorno a esso è durata circa quattro settimane, tutte tranquille. Il repository GitHub nv-tlabs/PixelUMM è stato creato il 4 settembre 2026 con licenza Apache-2.0 ed è rimasto con un singolo commit per gran parte del mese. Il 28–29 settembre è arrivato il commit iniziale e arXiv ha assegnato il preprint 2609.38597, il cui elenco di autori comprende NVIDIA e l'Università di Waterloo. Il repository del modello stesso è apparso alle 21:40 UTC del 1° ottobre, otto minuti dopo un commit finale su GitHub che aggiungeva la citazione del paper. Il paper non riporta alcuna indicazione sulla sede — nessuna conferenza, nessun «accettato a» — il che lascia pensare a un team di ricerca che mette online un artefatto più che a un lancio di prodotto, anche se questa è un'osservazione sulle prove e non un'affermazione sulle intenzioni.

Cos'è MiniCPM-V 4.7 35B-A3B

MiniCPM-V 4.7 35B-A3B è il primo modello MoE di OpenBMB nella serie MiniCPM-V: 256 esperti con 8 attivi per token, 40 livelli, una finestra di contesto di 262.144 token e un vocabolario di 248.144 token, per circa 3B parametri attivi su 35,2B totali. La visione passa attraverso un modulo SigLIP2 con compressione precoce intra-ViT di LLaVA-UHD v4 e una modalità selezionabile di compressione mista 4x/16x dei token visivi — 16x per impostazione predefinita per il throughput, 4x quando i dettagli fini contano. Comprende immagini singole, immagini multiple e video, e risponde in testo. Non genera immagini.

Il claim principale della scheda è che questo è il primo modello MoE open-source con inferenza on-device lossless e fluida, resa possibile da Lookahead Expert Scheduling, quantizzazione fine-grained layer-wise e campionamento speculativo tramite le bozze separate di DSpark, a una velocità dichiarata di oltre 13 token al secondo su un iPhone 17 Pro Max. Tale cifra è dichiarata dal fornitore, non riprodotta e non circostanziata. La scheda sostiene inoltre un punteggio complessivo in modalità Instruct superiore a quello di Qwen3.6 35B-A3B con un tempo di inferenza inferiore — un'affermazione che compare all'interno di un'immagine di grafico, il che significa che non è un numero citabile e non dovrebbe essere trattato come tale.

Il punto in cui MiniCPM-V 4.7 è inequivocabilmente in vantaggio non è in alcun tabellone, ma nel cast di supporto, tutto reale e scaricabile: pesi base, FP8, int4, AWQ, GPTQ e GGUF; supporto su SGLang, vLLM, llama.cpp, Ollama e OpenVINO; app per iOS, Android e HarmonyOS; e Rockchip, Houmo, Intel, AMD e Arm elencati per il silicio dal day-zero. Sei settimane fa l'onesta critica a questo modello era che si trattava di un checkpoint non documentato. Ora non è più così — è un checkpoint documentato senza benchmark. Problema diverso, più piccolo.

L'argomento architetturale che si nasconde dietro il confronto

I due modelli sono in disaccordo su qualcosa di fondamentale, e vale la pena dargli un nome, perché è la parte di questo confronto che avrà una durata più lunga di quella di entrambi i modelli.

• Come la visione raggiunge il modello linguistico — PixelUMM utilizza pixel grezzi e una singola proiezione lineare, senza alcun codificatore di visione preaddestrato nell'intera architettura; MiniCPM-V 4.7 utilizza un codificatore SigLIP2 con compressione anticipata intra-ViT e un rapporto di downsampling configurabile.

• Come funziona la generazione — PixelUMM predice i pixel in modo iterativo tramite una head di flow matching addestrata congiuntamente con la predizione testuale autoregressiva; MiniCPM-V 4.7 genera testo e nient'altro.

• Cosa comporta — PixelUMM ottiene un unico insieme di pesi che sia descrive un'immagine sia ne genera una, al prezzo di una licenza esclusivamente per la ricerca e nessuna validazione di produzione; MiniCPM-V 4.7 ottiene un modello piccolo, quantizzabile e deployabile su telefono che può leggere il mondo ma non ridisegnarlo.

• Conteggio dei parametri — 15,2B quasi denso rispetto a 35,2B totali con 3B attivi. Il conteggio dei parametri attivi è quello che predice il costo di inferenza, e su questo asse il modello MiniCPM è il più piccolo dei due di un ordine di grandezza.

• Pesi su disco — il repository di PixelUMM contiene 491 file in quattro varianti di checkpoint; la build di base di MiniCPM-V 4.7 è composta da sedici shard BF16 per circa 70 GB.

• Licenza — Apache-2.0 rispetto a NVIDIA One-Way Noncommercial per il checkpoint, con Apache-2.0 che si applica solo al codice sorgente di PixelUMM e la base Qwen3-8B che è separatamente Apache-2.0. La scheda di PixelUMM osserva inoltre che include codice modificato derivato da BAGEL, quindi i termini a monte si applicano in aggiunta.

• Valutazione pubblica — nessuna, da entrambe le parti. MiniCPM-V 4.7 almeno avanza dichiarazioni sulle prestazioni; la scheda di PixelUMM non riporta alcun numero di benchmark.

Quale si può effettivamente mettere davanti a un utente

Segui insieme la licenza e la storia del deployment e la scelta si farà quasi da sola.

PixelUMM è l'artefatto di ricerca più interessante e il prodotto meno utilizzabile. Un checkpoint non commerciale blocca del tutto gli ovvi usi commerciali, non c'è alcuna ricetta di serving sulla scheda, nessuna build quantizzata, nessun dato sulla lunghezza del contesto, e 83 like contro zero download registrati significano che essenzialmente nessuno al di fuori degli autori lo ha eseguito. Il suo valore al momento è quello di essere un forte argomento pubblicato secondo cui gli encoder visivi potrebbero essere superflui nei modelli unificati. Vale la pena tenere d'occhio quell'argomento, indipendentemente dal fatto che tu arrivi mai a caricare i pesi.

MiniCPM-V 4.7 è il modello con un percorso verso la produzione, e il percorso è stretto ma reale. Apache-2.0 elimina la questione della licenza. Sei formati di quantizzazione e cinque runtime di inferenza significano che non devi scrivere kernel personalizzati. La barriera è rappresentata da due o più GPU per la build non quantizzata; le versioni quantizzate e quelle on-device sono la soluzione alternativa, e la promessa on-device è proprio quella che non è stata verificata in modo indipendente. Consideralo un modello che puoi eseguire oggi e una promessa di prestazioni su cui non puoi ancora fare affidamento.

Per i team la cui risposta è "nessuno dei due, chiameremo qualcos'altro", l'equivalente hosted più vicino alla forma di MiniCPM è Qwen3.6 35B A3B — stessi 35B totali, stessi 3B attivi, stesso contesto da 262K, stesso input testo-immagine-video — ed è servito tramite OrcaRouter al prezzo di listino del provider senza alcun ricarico, $0,25 per milione di token in input e $1,48 per milione di token in output, con failover automatico se una rotta del provider si degrada. Non è un sostituto per nessuno dei due modelli in questo articolo; è il gruppo di controllo che ti dice cosa ti sta effettivamente dando l'auto-hosting di un MoE multimodale sparse da 70 GB.

Dove questo arriva

Togli l'architettura e ti restano due rilasci silenziosi che puntano in direzioni opposte. NVIDIA ha pubblicato un artefatto di livello scientifico con una licenza che impedisce ai più di usarlo, e un repository senza ricetta, senza benchmark e senza download. OpenBMB ha pubblicato un modello documentato, con licenza permissiva e multi-runtime, con una convincente rivendicazione di efficienza e nessuna tabella di valutazione a supportarla.

L'unica cosa che risolverebbe la questione per ciascuno: per PixelUMM, qualsiasi riproduzione indipendente — 0 download significa che non esiste alcun dato esterno, e la tesi senza encoder è esattamente il tipo di affermazione che o regge o crolla al contatto con una seconda implementazione. Per MiniCPM-V 4.7, una tabella di benchmark, o una lunghezza di accettazione riprodotta sul draft DSpark, che è l'unica parte della famiglia a portare numeri pubblicati. Nessuno dei due esiste ancora. Entrambi sono il motivo per cui questi due modelli meritano ancora di essere tenuti d'occhio invece di essere archiviati — sono più indietro nella loro vita pubblica di quanto suggerisca la copertura, e nessuno dei due è stato definito un lancio dal laboratorio che li ha creati.