Una pagoda voxel, il 10% in meno di token e l'unica frase che OpenBMB sostiene davvero

La frase più citata questa settimana su MiniCPM-V 4.7 35B-A3B non è nella sua model card. È un tweet, pubblicato il 13 ottobre 2026, che recita: "MiniCPM-V 4.7 35B-A3B non solo ha usato meno token, ma ha anche prodotto una pagoda voxel migliore di Qwen 3.6 35B-A3." La dimostrazione a cui rimanda è un video di due modelli linguistici che scrivono ciascuno il codice per una pagoda giapponese voxel 3D, renderizzati fianco a fianco. È un artefatto davvero interessante: mostra un modello visione-linguaggio che riproduce in tre dimensioni una struttura costruita a partire da un prompt immagine, un compito più difficile che generare la didascalia di un'immagine. Ma vale la pena distinguere ciò che quel tweet è da ciò che non è, perché tre affermazioni diverse sono state fuse in una sola riga, e hanno tre livelli diversi di supporto. MiniCPM-V 4.7 35B-A3B è un checkpoint reale di OpenBMB e ha circa una settimana; Qwen3.6-35B-A3B è un rivale open-weights vecchio di nove mesi, anch'esso Apache-2.0, anch'esso un mixture-of-experts sparso della stessa dimensione nominale. Tutto ciò che segue riguarda quali delle affermazioni sull'efficienza che li circondano siano verificabili, e quale sia un JPEG di un grafico.

Tre affermazioni che indossano una sola frase

Il tweet raggruppa tre cose separabili, e meritano di essere separate perché solo una di esse è documentata.

• "Ha utilizzato meno token" — questa è un'affermazione misurabile sul consumo di token per un compito. La cifra che circola insieme alla demo è il 10% in meno di token rispetto a Qwen3.6 35B-A3B. Quel numero proviene dal creatore di terze parti che ha eseguito il confronto, non dalla valutazione di OpenBMB, ed è una singola coppia di prompt, non un benchmark.

• "Ha prodotto una pagoda voxel migliore" — questo è un giudizio, formulato osservando due pagode renderizzate. Non esiste alcuna rubrica, alcun sistema di valutazione, né una parte indipendente. È il tipo di affermazione che un essere umano fa in tre secondi e che un benchmark non può fare affatto, perché "pagoda migliore" non ha una verità di riferimento.

• "Efficienza più qualità è il vero campo di battaglia" — questa parte è una tesi, ed è proprio quella che OpenBMB sostiene per iscritto, con numeri a supporto, nella model card. Semplicemente non è la frase che ha fatto strada.

Questo conta perché le prime due affermazioni sono quelle memorabili e la terza è quella difendibile. Se stai decidendo se spendere 70 GB di download per un checkpoint, vuoi la terza.

Cosa ha effettivamente scritto OpenBMB, e quando

Prima la cronologia, perché è stata compressa dai racconti. I pesi sono stati pubblicati in silenzio: openbmb/MiniCPM-V-4.7-1Bè stato creato il 6 ottobre 2026 alle 17:40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Bil 7 ottobre alle 07:07 UTC. A quel punto nessuno dei due riportava una model card, un tag di licenza o un benchmark — ne abbiamo parlato qui all'epoca, ed era una situazione strana per un caricamento da 35 miliardi di parametri. Sei giorni dopo, il 12 ottobre 2026, OpenBMB ha effettuato il commit della documentazione in una sola seduta: model card, licenza Apache-2.0, grafici di valutazione, un README del repository riscritto che apriva con la nuova serie e un annuncio. Quel giorno i parametri non sono cambiati. La spiegazione sì.

Quindi l'impostazione onesta non è "MiniCPM-V 4.7 35B-A3B è stato lanciato questa settimana". È "MiniCPM-V 4.7 35B-A3B è diventato leggibile questa settimana". Tutto ciò che di esso è ora citabile è stato o caricato il 6 e il 7 ma non documentato, oppure scritto il 12 ed è un'affermazione del fornitore.

L'affermazione che la scheda del modello fa davvero

Ecco la frase, riportata testualmente dalla scheda, ed è più circoscritta del tweet: in modalità Instruct, la variante 35B-A3B "ottiene un punteggio complessivo più alto in meno tempo di inferenza rispetto a Qwen3.6 35B-A3B". Tutto qui. Nessun conteggio di token, nessun margine, nessuna ripartizione per benchmark in prosa. L'evidenza alla base è un diagramma a dispersione — punteggio medio di valutazione sull'asse verticale, tempo di inferenza in secondi su scala logaritmica su quello orizzontale — sul quale MiniCPM-V 4.7 35B-A3B si trova sopra e a sinistra di Qwen3.6-35B-A3B. La nota a piè di pagina del grafico stesso definisce la media come la media di cinque benchmark: MMStar, MMMU-Pro, CharXiv reasoning, BLINK e MathVista. I cerchi indicano la modalità Instruct, i rombi la modalità Thinking.

Questa è un'affermazione reale e specifica su un compromesso bidimensionale, ed è la cosa più forte della release. Vale anche la pena notare ciò che il grafico non può dirti: non ci sono etichette numeriche sui punti tracciati, quindi non puoi ricavare un punteggio o un tempo, solo una direzione. La direzione, così come disegnata, favorisce MiniCPM su entrambi gli assi contemporaneamente.

Ed è stato misurato dal fornitore. I dati di valutazione della scheda riportano la dicitura «I risultati provengono da report pubblici e dalla nostra valutazione locale utilizzando checkpoint ufficiali». Valutazione locale significa l'hardware di OpenBMB, il sistema di valutazione di OpenBMB, la selezione della modalità di OpenBMB. È una cosa normale che una scheda di modello faccia e una cosa anomala da far passare come fatto. Nessuna parte indipendente ha eseguito questi due checkpoint con un sistema di valutazione condiviso. Nessuna classifica ha indicizzato alcuno dei due risultati. Al momento in cui scriviamo, l'affermazione ha esattamente una fonte, e la fonte vende il modello.

Da dove dovrebbe derivare l'efficienza dei token

L'argomento sull'efficienza non si basa sul grafico dei benchmark. Si basa su tre scelte ingegneristiche, e vale la pena comprenderle, perché sono ciò che determina se il vantaggio si trasferisce o meno al proprio hardware.

• Lookahead Expert Scheduling (LES) — la tecnica di punta. Un mixture-of-experts sparso memorizza molti più parametri di quanti ne attivi per token, e su un dispositivo che non può contenere ogni esperto in memoria, i pesi vengono paginati dentro e fuori e la decodifica si blocca. LES utilizza la previsione di routing cross-layer per precaricare gli esperti che probabilmente serviranno al layer successivo, e dà priorità al calcolo per gli esperti che il router reale ha effettivamente selezionato e che risultano già caricati. OpenBMB ci tiene a precisare che la previsione guida solo il prefetching e la pianificazione; il routing a livello di token del modello rimane invariato, e gli esperti che il predittore non ha individuato vengono comunque caricati e valutati. La scheda dichiara un'accelerazione di 5× su dispositivi reali grazie a questo, senza perdita di capacità.

• Quantizzazione a grana fine, livello per livello — riduce l'ingombro dei pesi degli esperti e il traffico di memoria, che è l'altra metà del lavoro per far entrare un pattern di caricamento on-device.

• Campionamento speculativo DSpark — un percorso di modello draft abbinato, pubblicato separatamente come openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, e integrato insieme al lavoro su scheduling e quantizzazione.

Combinati, questi producono il numero di punta della release: oltre 13 token al secondo usando circa 3 GB di memoria su un iPhone 17 Pro Max. È un dato del fornitore, su hardware del fornitore, con software del fornitore — un'app scritta da OpenBMB. È il tipo di affermazione che o è l'intero prodotto o non è nulla, e attualmente non c'è modo per nessuno al di fuori dell'azienda di verificarla, perché riprodurla richiede lo stack on-device su cui gira la demo del telefono.

L'efficienza dei token è reale, ma qui è una matrice, non uno scalare.

C'è un dettaglio in questa release che è stato appiattito in ogni riassunto che ne è stato fatto, ed è quello che in realtà governa l'economia dei token.

• MiniCPM-V 4.7 35B-A3B supporta la compressione mista dei token visivi 4x e 16x, selezionabile per richiesta. L'impostazione 16x unisce i token visivi per la velocità; 4x ne mantiene quattro volte tanti, per il dettaglio. Il valore predefinito della card è 16x, e il parametro deve essere passato sia al template di chat sia alla chiamata generate, altrimenti il numero di segnaposto e il vision encoder non concordano.

• La tabella comparativa vision-language dello stesso fornitore registra l'impostazione di compressione usata per la riga di ciascun modello. In quella tabella, la riga MiniCPM-V 4.7 35B-A3B è a 4x — l'impostazione che preserva i dettagli, ovvero quella costosa — e la riga Qwen3.6 35B-A3B è a 16x. Una riga Gemma 4 31B è elencata a 9x; le due righe Qwen 27B a 4x.

• Una nota a piè di pagina afferma chiaramente che MiniCPM-V 4.7 supporta entrambe le impostazioni, mentre gli altri modelli nella tabella supportano solo un rapporto di compressione fisso.

Leggendo tutto insieme, il quadro cambia. Se la riga MiniCPM ottiene i suoi punteggi visione-linguaggio all’impostazione avida di token mentre la riga Qwen li ottiene a quella parsimoniosa di token, allora le due colonne stanno confrontando quantità diverse di dettaglio visivo, e la storia dell’efficienza non è “stesso input, meno token” — è “input regolabile, ed ecco la colonna che vince sulla qualità”. Questa è un’affermazione più interessante e più onesta di quella del tweet, e OpenBMB l’ha pubblicata in una nota a piè di pagina invece di metterla in evidenza.

Significa anche che il numero che ti interessa davvero — token per unità di dettaglio visivo — non può essere ricavato affatto da questa tabella. Richiede di eseguire entrambi i modelli con la stessa impostazione, cosa che nessuno ha pubblicato.

La tabella, con le avvertenze allegate

La scheda include due tabelle del fornitore, una per visione-linguaggio e una per linguaggio, entrambe in modalità Instruct, entrambe su un campo che comprende due modelli Qwen di classe 35B-A3B, una Gemma 31B e due Qwen 27B. Le cifre riportate di seguito sono state lette dal grafico PNG dello stesso fornitore, e l'avvertenza è strutturale: i numeri esistono solo come pixel in quel grafico, non come tabella, quindi quanto segue è stato estratto tramite lettura automatica e sono possibili piccoli errori di trascrizione.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 contro Qwen3.6 35B-A3B a 90,40. Un divario di 0,8 punti, sulla stessa esecuzione del fornitore.

• OmniDocBench v1.6 — circa 98,2 per MiniCPM contro circa 93,3 per il modello Qwen, che è il divario singolo più ampio nella tabella e quello che conterebbe di più se venisse riprodotto, dato che l'analisi dei documenti è dove vengono solitamente spesi i budget di token.

• MMMU — circa 80,2 contro 80,0, un testa a testa alla risoluzione di un'immagine di un grafico.

• MMMU-Pro — circa 69,7 contro 67,7, su una riga in cui un Qwen 27B si posiziona più in alto di entrambi.

• Tabella delle lingue — la stessa struttura, con le celle più eclatanti sul rispetto delle istruzioni e sul codice. IFBench è riportato intorno a 47,7 contro 35,3, e LiveCodeBench-v6 intorno a 97,0 contro 54,3. Queste due sono abbastanza ampie da dover essere considerate le celle meno credibili del rilascio finché qualcun altro non le esegue: uno scarto di 43 punti su un benchmark di codice tra due modelli MoE aperti di dimensioni simili, misurato da una delle due parti, è un'affermazione che richiede un secondo strumento.

Riportati dal fornitore, collaudati sul banco di prova del fornitore, non replicati. Questo è tutto. Se questi dati reggono a un banco di prova indipendente, la tesi sulla frontiera di Pareto è corretta e il video della pagoda è una nota a piè di pagina. Se non reggono, il video della pagoda è tutto ciò che c'è.

Ciò che dicono i numeri di adozione, che non ha nulla a che vedere con la qualità

Un numero in questo confronto non è contestato da nessuno, e non è un benchmark. Il contatore dei download di Hugging Face, letto il 13 ottobre 2026, mostra 630 per openbmb/MiniCPM-V-4.7-35B-A3Bcontro circa 3,6 milioni per Qwen/Qwen3.6-35B-A3B— un repository creato il 15 aprile 2026 e quindi posizionato circa nove mesi più avanti lungo la curva di adozione. Quel divario misura il tempo, non il merito, ed è il motivo per cui la questione dell'efficienza viene posta proprio in questa direzione: il nuovo arrivato deve argomentare su base per token precisamente perché non ha avuto nove mesi per essere la scelta predefinita.

C'è anche una piccola contraddizione interna nella scheda che vale la pena segnalare. Il repository porta il tag "On-Device Model" ereditato dal resto della famiglia, e un MoE sparso da 35,2 miliardi di parametri in 70,4 GB di pesi BF16 non è on-device in nessun senso che chi scarica riconoscerebbe. La storia on-device è reale, ma passa attraverso la quantizzazione e lo streaming degli esperti costruiti sopra il checkpoint, non attraverso il checkpoint. Calcola il budget rispetto alla build quantizzata e all'app, non rispetto al tag.

Cosa fare al riguardo questa settimana

La posizione pratica è ristretta e chiara. Se vuoi che l'affermazione sull'efficienza venga verificata, non c'è ancora nulla da verificare: è il grafico di un singolo fornitore, e l'unico numero a cui è associato un dato per attività (10% in meno di token, una pagoda) proviene dalla singola demo di una terza parte. Se vuoi eseguire il modello, i pesi sono Apache-2.0, l'architettura è documentata e l'impostazione di downsampling è a tua scelta, il che è una leva autentica e sottovalutata: 16x quando conta il throughput, 4x quando il grafico ti sta mostrando un documento.

Una metà di questo confronto è oggi raggiungibile tramite un'API ospitata e l'altra no, e vale la pena essere precisi su quale sia quale. qwen/qwen3.6-35b-a3bè un modello ospitato su OrcaRouter — si trova nel catalogo dietro una sola chiave, al prezzo di listino di Qwen senza nulla aggiunto sopra, e inoltra le richieste al provider che è in salute invece che a uno che hai fissato. MiniCPM-V 4.7 non è ospitato da noi; è un checkpoint open-weights che servi tu stesso. Questa asimmetria è la cosa utile qui. Puoi mettere il lato Qwen di questo confronto in una baseline questo pomeriggio, eseguire l'harness di OpenBMB sui tuoi dati contro di esso, e lasciare che il grafico del fornitore sia l'ipotesi invece della risposta.

Il che, dato che l'intera discussione riguarda l'efficienza sul tuo hardware, è l'unica misurazione che avrebbe mai potuto risolverla.