MiniCPM-V 4.7 1B su un iPhone di tutti i giorni: cosa significa davvero «Va oltre il Pro Max»

MiniCPM-V 4.7 1B è un modello visione-linguaggio da 1,55 miliardi di parametri che OpenBMB ha caricato su Hugging Face il 6 ottobre 2026 e datato 12 ottobre nelle proprie note di rilascio. Ha una model card, undici varianti quantizzate, un tag Ollama e un'app demo on-device. Quello che non ha è una versione della storia che regga quando si fa il conto dell'hardware. L'affermazione che circola negli ambienti di sviluppo — che il modello ora funziona in un'app OnDeviceLLM su iPhone comuni, non solo su un Pro Max da 12GB — è la parte che vale la pena esaminare da vicino, perché "funziona su un telefono" e "funziona sul tuo telefono" sono separati da circa 3 GB di margine di memoria che la maggior parte degli iPhone non ha. I fallimenti documentati dell'IA e gli incidenti degli agenti dietro rilasci come questo sono raccolti in the OrcaRouter AI Incident Archive dove ogni voce riporta le proprie fonti, gravità, livello di confidenza e indicatore di contestazione.

Ecco qual è la situazione, con le cuciture bene in vista. Tutto ciò che segue è tratto direttamente dai file dei pesi, dalla documentazione ufficiale di OpenBMB o dalle specifiche pubblicate da Apple. Dove un numero proviene da un post di uno sviluppatore anziché da un artefatto riproducibile, questo articolo lo dichiara.

Che cosa è effettivamente noto e che cosa è solo affermato

Il modello è reale e scaricabile. Il checkpoint BF16 conta 1.554.476.272 parametri, pari a circa 3,1 GB su disco. Il repository include una scheda del modello completa — una rarità nella storia recente di questa famiglia — che indica un backbone testuale Q​wen3.5, una torre visiva SigLIP2 con 27 layer e larghezza nascosta di 1152, tile di input da 980 pixel, una finestra di contesto di 262.144 token e licenza Apache 2.0. La voce README di OpenBMB data la release al 2026-10-12; il repository Hugging Face è stato creato il 2026-10-06. Il divario di sei giorni è il ritardo tra caricamento e annuncio tipico di questa famiglia, ed è il motivo per cui un articolo di ottobre può ancora definire un repository vecchio di sei giorni un rilascio silenzioso.

Ciò che non è stabilito da alcun artefatto è l'affermazione specifica che il modello 1B giri in OnDeviceLLM su "iPhone di tutti i giorni oltre il 12GB Pro Max". Un post di uno sviluppatore è all'origine di questa impostazione. Il repository pubblico del progetto OnDeviceLLM — che è uno starter kit per app di chat e traduzione offline, non un prodotto distribuito sull'App Store — ha zero stelle e l'ultimo push risale al 27 luglio 2026. Precede di dieci settimane i pesi di MiniCPM-V 4.7, quindi qualsiasi supporto per questo modello al suo interno è recente e non documentato. Tratta "già in esecuzione in OnDeviceLLM" come il resoconto di qualcuno che l'ha fatto, non come un percorso di deployment supportato dal fornitore.

Questa distinzione è importante perché i dati on-device del fornitore stesso non riguardano affatto l'1B.

Il numero di 3 GB appartiene al 35B, non all'1B

L'affermazione di punta di OpenBMB — "13+ token/s con appena 3 GB di memoria su iPhone 17 Pro Max" — è associata alla variante 35B-A3B Mixture-of-Experts, in esecuzione sul più grande iPhone venduto da Apple. La tecnica alla base, Lookahead Expert Scheduling, mantiene la maggior parte dei pesi degli esperti sull'SSD e precarica quelli di cui il livello successivo potrebbe aver bisogno. È un impressionante esempio di ingegneria dei sistemi ed è il motivo per cui il nome 35B continua a comparire nella copertura relativa agli smartphone.

L'1B non ha bisogno di nulla di tutto ciò. È un modello denso che entra in memoria del tutto. Sulla carta questo lo rende il più democratico dei due, ed è per questo che l'angolazione "iPhone di tutti i giorni" ha basi solide. Ma l'aritmetica è meno favorevole di quanto suggerisca l'inquadratura:

• Pesi BF16 — 3,1 GB su disco, e all'incirca lo stesso quantitativo residente una volta caricati, prima di qualsiasi cache KV o attivazione visiva • Q8_0 GGUF — 1,08 GB di pesi, più un proiettore visivo da 0,90 GB con l'impostazione di compressione 4×, oppure 1,11 GB a 16× • Q4_K_M GGUF — 0,67 GB di pesi, con lo stesso sovraccarico del proiettore • Proiettore visivo — questa è la parte che la gente dimentica; non si riduce con la quantizzazione del modello linguistico e va conteggiato una volta per ogni modello caricato • Contesto — fino a 262.144 token sulla carta; ogni token della cache KV è memoria aggiuntiva che la scheda del modello non mette in budget

Una build Q4 con il proiettore 16× si aggira intorno a 1,8 GB di pesi. Aggiungi una cache KV funzionante per qualche migliaio di token di conversazione e segnaposto immagine, e stai chiedendo a un'app qualcosa nell'intervallo 2,2–2,8 GB. Su un Pro Max da 12 GB è una situazione comoda. Su un iPhone da 8 GB, dove il sistema operativo e ogni altra app residente competono già per lo stesso pool, un'app che chiede 2,5 GB sta chiedendo una gran parte di ciò che resta. iOS lo concederà, oppure farà scattare il jetsam sull'app sotto pressione.

Perché la riga sulla RAM di un iPhone è la vera specifica

Apple non pubblica la RAM degli iPhone nelle proprie specifiche di marketing e non ha mai incoraggiato gli sviluppatori a considerare il telefono come un computer con memoria indirizzabile. È questo il vincolo contro cui si scontra l'affermazione "oltre il Pro Max da 12GB". Da diverse generazioni, la fascia Pro Max dispone di più memoria rispetto ai modelli standard, e il divario tra "il telefono nel video di recensione" e "il telefono nella tasca di un lettore" è esattamente il divario da cui dipende la narrazione on-device di questo modello.

La versione onesta dell'affermazione è più ristretta e comunque interessante: un modello vision da 1B che prima richiedeva un laptop o un telefono di punta ora entra nel budget di memoria di un telefono di fascia media, se si usa una quantizzazione a 4 bit e si accetta un contesto più breve. Questo è un vero passo indietro di classe hardware. Non equivale a "gira su ogni iPhone", e la differenza vale la pena di essere dichiarata chiaramente perché decide se un lettore può rilasciare il prodotto.

La scheda del modello non risolve la questione. Documenta il supporto per iOS, Android e HarmonyOS, il supporto dei chip dal giorno zero da parte di Rockchip, Houmo, Intel, AMD e Arm, e rimanda a un repository di deployment edge con applicazioni e codice sorgente. Da nessuna parte elenca la memoria minima del dispositivo, una matrice dei dispositivi testati o una velocità di token per dispositivo per il modello 1B. L'unico dispositivo indicato nei materiali demo del modello 1B stesso è un iPhone 17 Pro Max — lo stesso dispositivo del titolo del 35B.

In cosa il modello è davvero bravo, a 1B

Il motivo per cui vale la pena fare i calcoli sulla memoria è che un modello da 1 miliardo di parametri che esegue la comprensione di documenti e schermate su un telefono appartiene a una categoria di prodotto diversa da quella di un chatbot. Significa che uno scontrino, un modulo, un menu, un'etichetta o uno screenshot possono essere trasformati in testo strutturato senza un round trip di rete — nessun caricamento, nessun costo per immagine, nessun limite minimo di latenza imposto da una torre cellulare.

Le cifre 1B pubblicate da OpenBMB, tutte dichiarate dal fornitore e nessuna riprodotta in modo indipendente al momento in cui scriviamo, collocano OCRBench a 86,1, MathVista a 74,3, CharXiv Reasoning a 48,8, LongVideoBench a 53,4 e MotionBench a 54,55. Il confronto principale del fornitore è con Q​wen3.5 0.8B, sul quale afferma di prevalere sia nel punteggio complessivo sia nell'efficienza di inferenza, e con MiniCPM-V 4.6, rispetto al quale afferma di migliorare in tutte le capacità principali. Quelli sono i benchmark del fornitore stesso, eseguiti dal fornitore, e la model card li presenta sotto forma di grafici anziché di una tabella con i dettagli dell'harness.

Due dettagli architetturali contano più dei punteggi per chiunque lo stia effettivamente mettendo in produzione:

• Compressione mista dei token visivi 4×/16× — chi effettua la chiamata sceglie, per ogni richiesta, se un'immagine diventa una sequenza di token dettagliata o una sequenza economica, così la scansione di una ricevuta e una miniatura possono condividere lo stesso deployment • Compressione anticipata Intra-ViT, mutuata da LLaVA-UHD v4 — i token visivi vengono tagliati all'interno del vision encoder anziché dopo di esso, ed è proprio questo che rende sostenibile il percorso 4× in primo luogo • Slicing — le immagini ad alta risoluzione vengono suddivise in tasselli 448×448 più una panoramica a bassa risoluzione, con il numero di sezioni come parametro di runtime (la scheda consiglia 36 per le immagini, 1 per i video) • Campionamento video — max_num_frames ha un valore predefinito di 128, e stack_frames compone i sottoframe in una griglia, ed è così che un telefono riesce a gestire una registrazione dello schermo senza tenere ogni frame in memoria

Per il caso d'uso dello scontrino menzionato nel prompt, la pipeline è: acquisire, ridimensionare a circa 980 pixel sul lato lungo, eseguire a 4× con un numero elevato di slice e richiedere un output strutturato. Il percorso 4× a 36 slice è l'impostazione costosa; il percorso 16× usa circa un quarto dei token ed è quello in cui il telefono rimane reattivo. Se 16× sia sufficiente per leggere uno scontrino termico è una domanda a cui solo le tue immagini possono rispondere, e nessun benchmark pubblicato nella scheda riporta l'accuratezza OCR per modalità di downsample.

Il divario tra "demo" e "app"

Ci sono tre cose tra una demo funzionante e un'app iOS pronta per il rilascio, e nessuna di esse corrisponde ai pesi del modello.

Il primo è il packaging. Il modello viene distribuito nei formati Transformers, GGUF, AWQ, GPTQ e int4. Solo GGUF ha un runner on-device maturo su iOS — llama.cpp e i suoi derivati — e solo il repository GGUF contiene il file separato del proiettore visivo (mmproj) necessario al percorso multimodale. Se parti dal checkpoint BF16 aspettandoti un drop-in a file singolo, scoprirai che il proiettore è un secondo artefatto con una dimensione propria.

Il secondo è il budget termico. Un modello da 1B che genera qualche centinaio di token è un carico a burst; un modello da 1B che fa OCR su una pagina da 36 slice è un carico sostenuto. La GIF dimostrativa del fornitore è una registrazione dello schermo, non una traccia termica. Nessun dato pubblicato nella scheda fornisce i token al secondo sostenuti su alcun telefono, ed è proprio questo il numero che decide se un'app di scansione sembra istantanea al terzo documento o al trentesimo.

Il terzo è il resto del tuo stack. L'inferenza on-device gestisce l'immagine. Non gestisce la parte in cui riconcili la ricevuta estratta con un registro, escali una riga ambigua a un modello più grande o passi al fallback quando il telefono è così vecchio che l'app rifiuta di caricare i pesi. Questo è il confine in cui un router si guadagna il suo posto invece di sostituire qualcosa: OrcaRouter mette oltre 200 modelli ospitati dietro un unico endpoint compatibile OpenAI a markup 0%, passando direttamente il prezzo di listino di ciascun provider, con failover automatico e un DSL di routing per configurazioni primary-and-fallback. Un estrattore lato telefono può affidare i suoi casi incerti a un modello vision ospitato, e la stessa chiave copre entrambi i percorsi. MiniCPM-V 4.7 1B stesso non è in quel catalogo — è un checkpoint che esegui tu stesso — quindi il router è il percorso di escalation, non il modo per chiamare questo modello.

Il pattern del rilascio silenzioso, e perché continua a generare questa confusione

MiniCPM-V 4.7 è arrivato senza un evento di lancio. Il repository 35B-A3B è apparso il 6 ottobre 2026 senza alcuna model card — la scheda è arrivata sei giorni dopo, insieme alla nota di rilascio datata. Il modello 1B ha seguito lo stesso schema: prima il repository, poi la documentazione, con la scoperta da parte della community per tutto il tempo. Nel frattempo, la copertura si basa su qualunque artefatto esista, ed è per questo che i primi articoli descrivevano un modello MoE da 35B e poi hanno dovuto essere rivisti quando sono comparsi il modello 1B e la sua scheda.

Questa non è una critica all'ingegneria di OpenBMB. È una descrizione di come si diffondono le informazioni su questo modello, ed è il motivo per cui un'affermazione come "gira sugli iPhone di tutti i giorni" può viaggiare più velocemente dei dati sulla memoria che la qualificano. Il repository è la fonte primaria. La card è la fonte primaria. Lo screenshot di uno sviluppatore che mostra un'app funzionante sul suo telefono è un dato, non una specifica.

Cosa fare con questo, concretamente

Se hai un Pro Max o un iPad. Scarica il GGUF Q8_0 e il proiettore 16×, eseguilo tramite llama.cpp o Ollama e prova i tuoi documenti con entrambe le impostazioni di downsampling. Otterrai un percorso locale funzionante per OCR e image-QA in un pomeriggio, e il modello 1B è abbastanza piccolo da poterlo mantenere residente insieme ad altre app.

Se hai un iPhone standard. Inizia con Q4_K_M e il proiettore 16×, limita il numero di slice a un valore modesto e misura. L'aritmetica della memoria dice che dovrebbe starci; il comportamento termico e di jetsam sotto uso prolungato è la parte che nessuno ha pubblicato. Testa sul dispositivo più vecchio che intendi supportare, non sul più recente.

Se stai costruendo un prodotto. Considera il modello sul dispositivo come percorso rapido e un modello ospitato come percorso di correttezza. L'escalation è una decisione di routing, e integrarla fin dal primo giorno costa meno che aggiungerla in un secondo momento, dopo il primo ticket di assistenza per uno scontrino che il telefono ha letto male.

L'affermazione da cui è partito questo articolo — che un modello multimodale da 1B ora giri su telefoni sotto il livello Pro Max — è plausibile sul piano dell'aritmetica della memoria e non dimostrata nella documentazione pubblicata. È uno stato normale per un modello così giovane, ed è un motivo per testare invece di aspettare. I pesi sono Apache 2.0, le quantizzazioni esistono, e l'unica cosa che ti separa da una risposta è un pomeriggio con il tuo hardware.

In sostanza: MiniCPM-V 4.7 1B è un modello di visione reale, documentato, con licenza Apache-2.0, che occupa circa 1,8 GB a Q4 con il suo proiettore visivo — abbastanza piccolo da rendere i telefoni di fascia media un obiettivo credibile e non solo il Pro Max da 12 GB. Il fornitore non ha pubblicato una matrice dei dispositivi né un valore minimo di memoria, e l'affermazione "iPhone di tutti i giorni" proviene da una segnalazione di uno sviluppatore anziché dalla scheda del modello. Provalo sul tuo dispositivo prima di basare i tuoi piani su di esso.