MiniCPM-V 4.7 porta un modello visivo da 35B in 3 GB: facciamo chiarezza sulla promessa dei 100 tok/s

Un modello da 35 miliardi di parametri non può stare in tre gigabyte. MiniCPM-V 4.7 35B-A3B funziona comunque in circa tre gigabyte, ed entrambe le affermazioni sono vere — è proprio questo il trucco, e il motivo per cui vale la pena rallentare sui numeri che circolano su questo rilascio. Il modello è la prima voce sparse mixture-of-experts di OpenBMB nella linea MiniCPM-V: 35,2 miliardi di parametri memorizzati, circa 3 miliardi attivi per token, Apache-2.0, pesi su Hugging Face. Legge immagini, set multi-immagine e video, e risponde in testo. Dal 10 ottobre funziona anche in llama.cpp upstream, che è dove la maggior parte delle persone lo ha incontrato. Quanto segue separa i tre numeri che tutti ripetono — 3 GB, 35B e il valore di 100 tok/s — e mostra quali di essi OpenBMB ha effettivamente pubblicato. Oltre 200 modelli ospitati, una chiave, prezzo di listino del provider trasferito con 0% di ricarico. Scopri cosa instrada OrcaRouter Il checkpoint open-weight resta sul tuo hardware; la via di fuga ospitata è un unico endpoint. I fallimenti documentati dell'IA e gli incidenti degli agenti dietro rilasci come questo sono raccolti in l'OrcaRouter AI Incident Archive dove ogni voce riporta le proprie fonti, gravità, livello di confidenza e flag di contestazione.

Tre gigabyte, trentacinque miliardi di parametri e nessuna contraddizione

L'aritmetica sembra impossibile solo se si presume che "in memoria" significhi "tutto quanto". MiniCPM-V 4.7 35B-A3B mantiene residenti circa 3 miliardi di parametri e carica in streaming il resto degli esperti man mano che il router li richiede — la formulazione della model card è Lookahead Expert Scheduling, un predittore di routing cross-layer che esegue il prefetch degli esperti di cui il layer successivo potrebbe aver bisogno, sovrapponendo tale caricamento al calcolo già in corso. La card tiene a precisare che la previsione guida solo il prefetch e la pianificazione; i token seguono comunque il routing reale del modello, e un esperto che il predittore non ha previsto viene caricato e valutato come qualsiasi altro.

Questa distinzione ha una conseguenza misurabile. Il repository GGUF pubblica l'intero modello in ogni quantizzazione comune, e nessuno di quei file pesa tre gigabyte:

• Q4_K_M — 21,2 GB su disco.

• Q8_0 — 36,9 GB.

• F16 — 69,4 GB.

• Proiettore visivo — 0,9 GB con compressione 4x, 1,1 GB a f16.

Quindi "3 GB" è un valore di memoria residente con lo streaming degli esperti su un telefono, non una dimensione di download e nemmeno un requisito di VRAM per un desktop. Se stai pianificando un deployment, il numero che governa il tuo disco e il tuo primo caricamento è 21.2 GB a Q4_K_M, mentre il numero che governa la tua occupazione a regime su un telefono è il ~3 GB del fornitore. Entrambi sono nella release. Rispondono a domande diverse, e gran parte della copertura li ha accorpati in un unico numero.

Da dove provengono 100 tok/s, e da dove no

Ecco la parte su cui vale la pena essere schietti. OpenBMB non pubblica una cifra di 100 tok/s per MiniCPM-V 4.7. Il numero sulla model card è 13+ token/s, su un iPhone 17 Pro Max, con circa 3 GB di memoria. Questa è l’unica dichiarazione di throughput su dispositivo fatta al rilascio, ed è misurata dal fornitore su hardware che nessuno fuori dal laboratorio ha riprodotto.

Esistono numeri più alti, e provengono da un artefatto diverso. Il fork llama.cpp-omni di OpenBMB — il repository che contiene le ottimizzazioni on-device — pubblica una propria tabella per il target 35B-A3B, stratificata in base a quali ottimizzazioni sono attivate:

• iPhone 18 Pro Max, 12 GB — 3,38 tok/s di base, 11,34 con Lookahead Expert Scheduling, 17,16 con l'aggiunta della precisione mista, 20,51 anche con la testa draft DSpark.

• iPad Pro da 11 pollici M4, 16 GB — 2,97 tok/s baseline, 9,81 con LES, 14,92 con precisione mista, 17,39 con DSpark.

Quelli sono i valori più alti pubblicati per l'elaborazione sul dispositivo per questo modello, e il massimo della scala è 20.51 tok/s — un quinto di 100. Il divario conta perché cambia a cosa serve il modello. A 13 tok/s un'app per smartphone risponde a una domanda su una foto in un paio di secondi. A 100 tok/s lo considereresti un lettore in streaming di prima passata per il video. Il primo è un prodotto reale. Il secondo non è ciò che è stato distribuito, e chiunque faccia i propri calcoli sul numero del tweet rimarrà deluso di un fattore cinque.

La lettura onesta dell'affermazione di 100 tok/s è che si tratta della compressione di tre fatti distinti — 3 GB, funziona in locale, più veloce della generazione precedente di ampio margine — in un unico numero che nessuna delle fonti contiene. Il miglioramento generazionale è reale e consistente: da 3,38 a 20,51 tok/s è un salto di 6x sulla stessa classe di dispositivo, ottenuto combinando tre tecniche anziché con un chip più grande.

Il rilascio non è stato di un solo giorno, e le date contano

MiniCPM-V 4.7 è saltato fuori come capita ormai a molti rilasci open-weight: prima i file, poi le spiegazioni, e il supporto ai framework da qualche parte nel mezzo.

• 6 ottobre, 17:40 UTC — il modello 1B e le sue varianti AWQ, GPTQ e int4 compaiono su Hugging Face, oltre alle build GGUF alle 18:05.

• 7 ottobre, 07:07 UTC — arriva il repository 35B-A3B. Ancora nessuna model card.

• 8 ottobre — teste di decodifica speculativa DSpark per entrambe le dimensioni, e una build FP8 del 35B.

• 10 ottobre, 18:42 UTC — llama.cpp integra il supporto per il modello.

• 12 ottobre — OpenBMB esegue il commit della model card, dichiara la licenza Apache-2.0 e annuncia il rilascio come prodotto documentato.

• 15 ottobre — le teste DSpark sono collegate dalla scheda principale, con bozze GGUF per entrambi i target.

Quell'ordine di pubblicazione spiega gran parte della confusione nella copertura di secondo livello. Chi ha conosciuto il modello tramite llama.cpp nella seconda settimana di ottobre stava usando una release che ufficialmente non esisteva ancora, priva di tag di licenza e di grafico di benchmark, e i suoi numeri di throughput riflettono le scelte di quantizzazione del framework stesso, non qualcosa che OpenBMB abbia misurato.

Supporto per llama.cpp: unito, e non del tutto completato

La pull request upstream che ha aggiunto MiniCPM-V 4.7 è insolitamente chiara su cosa è cambiato, e la risposta è: quasi nulla a livello architetturale. Il modello è quasi identico a MiniCPM-V 4.6; la differenza è il 3D RoPE, una posizione a tre valori per token — tempo, riga, colonna — invece del singolo scalare usato dalla maggior parte dei modelli vision-language. Il supporto estende il percorso esistente di 4.6 per portare quella dimensione extra. La PR ha anche indicato il modello come "in arrivo" quando è stata aperta il 25 settembre, il che è un indizio ragionevole di quanto presto i pesi fossero in circolazione.

Vale la pena conoscere questo residuo prima di costruirci sopra una funzionalità di grounding. Da quel merge, llama.cpp upstream assegna ai token marker dell'immagine posizioni errate nei prompt di MiniCPM-V 4.7: i token dell'immagine in sé finiscono correttamente, ma <slice>, </slice> e i marker di fine riga vengono numerati come testo normale invece di ricevere le coordinate dell'angolo della tile come fa l'implementazione di riferimento get_rope_index. Il sintomo visibile è che le coordinate restituite risultano sistematicamente basse quando chiedi dove si trova qualcosa in un'immagine. Una correzione con un unit test esiste come pull request aperta, datata 14 ottobre, e al 20 ottobre è ancora aperta. Se il tuo carico di lavoro è «descrivi questo», non te ne accorgerai. Se è «dammi il bounding box», sì, e dovresti aspettare il merge oppure usare il fork che contiene il percorso corretto.

Un'altra cosa sopravvive al ciclo di andata e ritorno: per il modello 1B, il proiettore visivo è il download più grande. I pesi Q4_K_M sono 672 MB; il proiettore f16 è 1,11 GB. La più piccola distribuzione utile di 1B è quindi di circa 1,8 GB di file, la maggior parte dei quali sono occhi più che linguaggio — un dettaglio che rende errata qualsiasi aspettativa del tipo "1B significa 1 GB".

Cosa eseguire, e su cosa

Se l'obiettivo è provarlo questa settimana, il percorso con minore attrito è llama.cpp o Ollama sui repository GGUF, puntando il client multimodale sul file mmproj corrispondente. Su una GPU da 24 GB, Q4_K_M a 21,2 GB lascia pochissimo spazio per il contesto: una finestra di 8K token più i riquadri immagine non ci sta comodamente, quindi punta su Q4_K_S o su una quantizzazione più piccola se vuoi anche un prompt lungo. Su un Mac con 32 GB o più, Q8_0 è praticabile ed è la cosa più vicina al comportamento di riferimento. Su un telefono, solo le app proprietarie del produttore e il fork llama.cpp-omni includono il lavoro di pianificazione degli esperti; llama.cpp standard ti dà la correttezza, non i 20 tok/s.

Il punto in cui un layer di routing si guadagna il suo posto, qui, è dall'altro lato della chiamata locale. Un modello da 3B attivi su un telefono è eccellente nei compiti di routine — leggi questo scontrino, questo scaffale sembra rifornito, cosa dice questo cartello — e ogni tanto incontrerà una pagina che non riesce a completare. OrcaRouter mette oltre 200 modelli ospitati dietro un'unica chiave, trasmette il prezzo di listino di ogni provider con 0% di ricarico così una variazione di prezzo del fornitore è attiva lo stesso giorno, e passa automaticamente al failover quando un upstream peggiora. Il pattern che funziona è local-first con una via di fuga verso modelli ospitati, non solo locale. Il checkpoint open-weight resta tuo da ospitare; il router gestisce tutto ciò che il telefono gli passa.

MiniCPM-V 4.7 non è servito da OrcaRouter, e non intendiamo insinuare il contrario. È un checkpoint che esegui tu.

Cosa risolverebbe i tre numeri

Una misurazione indipendente del modello 35B su un telefono specifico, con l'app e la quantizzazione dichiarate, risolverebbe la questione della velocità effettiva — incluso se 20,51 tok/s sopravvive al cronometro di qualcun altro. Una definizione pubblicata del dato di 3 GB — resident set, allocazione di picco o qualcos'altro — risolverebbe la questione della memoria. E una tabella per benchmark con punteggi reali, anziché i cinque grafici collegati che la scheda attualmente include, consentirebbe di verificare l'affermazione «meglio di Qwen3.6 35B-A3B in meno tempo» rispetto alla ponderazione scelta da OpenBMB. Nessuna di queste cose esiste ancora. Finché non esisteranno, la frase accurata è quella noiosa: un modello sparso da 35B che gira su un telefono a una velocità riportata di oltre 13 token al secondo in circa 3 GB, con un download da 21 GB e un percorso framework unificato che presenta ancora un bug aperto relativo a una coordinata.