La notizia non è l'ennesimo modello multimodale, ma il momento in cui un'architettura MoE open source arriva davvero su un telefono. OpenBMB ha presentato MiniCPM-V 4.7, variante 35B-A3B, primo modello mixture-of-experts della serie MiniCPM-V. Il dato dichiarato è 13+ token/s su iPhone 17 Pro Max in decodifica. Non è un numero da laboratorio su scheda enterprise, ma un riferimento a un dispositivo consumer.

Nei modelli MoE, ogni token attiva solo una parte dei parametri totali, il che riduce il costo computazionale per token. Il problema storico è che questa efficienza teorica si paga con una maggiore pressione sulla memoria e con una schedulazione più complessa, soprattutto quando si esce dai rack dei data center.

MiniCPM-V 4.7 affronta il problema con tre leve: Lookahead Expert Scheduling, una pianificazione anticipata degli esperti introdotta con questo modello; quantization layer-wise a granularità fine; e integrazione dello speculative sampling DSpark. Insieme, secondo OpenBMB, consentono di non sacrificare le prestazioni rispetto a una versione non compressa. Va preso come dichiarazione del produttore, ma il cambio di approccio è netto: non si comprime solo a valle, si riprogetta la pipeline di inference per convivere con i vincoli di un telefono.

Il secondo segnale è la densità di capacità. Il team presenta il modello come nuovo Pareto frontier per MLLM: in modalità Instruct, il 35B-A3B otterrebbe un punteggio complessivo più alto in meno tempo di inference rispetto a Qwen3.6 35B-A3B. Al di là del singolo confronto, il punto strutturale è che la metrica si sposta dai parametri totali alla capacità utile per unità di tempo e di memoria.

Sul fronte architetturale, l'eredità LLaVA-UHD v4 emerge nella compressione anticipata dei token visivi dentro il vision encoder. MiniCPM-V 4.7 supporta compressione mista 4x/16x dei token visivi, così gli sviluppatori possono bilanciare dettaglio visivo e costo di inference per task.

Il supporto piattaforma è altrettanto rilevante: iOS, Android, HarmonyOS e, a livello chip, Rockchip, Houmo, Intel, AMD e Arm con disponibilità day-0. Non è solo una questione di porting: significa che il modello entra in ecosistemi embedded e local computing prima ancora che si consolidi il mercato dei soli smartphone. Per chi gestisce deployment self-hosted o edge, questo riduce la dipendenza da una singola architettura di silicio.

Sul lato tooling, il modello è compatibile con SGLang, vLLM, llama.cpp e Ollama per l'inference; SWIFT e LLaMA-Factory per il fine-tuning. Le varianti quantizzate GGUF, BNB, AWQ e GPTQ, a cui si aggiunge il supporto FP8, coprono gran parte degli scenari di deploy, dal laptop al server edge. FP8 è interessante perché riduce il footprint di memoria senza spingere verso formati a più bassa precisione; per carichi multimodali, questo può fare la differenza in termini di TCO.

La novità meno evidente ma forse più strategica è Self-Replay Fine-Tuning. L'idea è estendere le capacità del modello a basso costo riducendo il forgetting delle capacità esistenti. In un contesto on-premise, dove i dati proprietari restano sotto controllo, un percorso di fine-tuning con meno rischio di dimenticare le capacità generali rende più praticabile la personalizzazione verticale.

L'effetto di secondo ordine è una pressione sugli incentivi. I provider cloud di multimodal inference perdono una fetta di workload a bassa latenza che può restare on-device; i produttori di chip embedded guadagnano un modello open source capace di sfruttare i loro siliconi senza attendere software proprietario. Il terzo ordine è più interessante: se la densità di capacità diventa il criterio di scelta, la corsa ai parametri totali perde senso per i deployment vincolati a energia e memoria. Conterà di più la qualità dell'infrastruttura di quantization e scheduling che il numero di parametri dichiarato.

Per chi valuta questi trade-off tra dettaglio visivo, latenza e memoria, AI-RADAR pubblica framework analitici su /llm-onpremise.

La disponibilità immediata dei GGUF e il supporto in llama.cpp/Ollama rendono il modello testabile su hardware comune, non solo su dispositivi flagship. È il tipo di condizione che storicamente ha determinato l'adozione di un modello open source sul campo, più dei benchmark da laboratorio. MiniCPM-V 4.7 non risolve da solo il tema della sovranità dei dati, ma sposta il confine: se un MoE multimodale può girare su silicio locale, la decisione di inviare immagini e video a un'API cloud diventa una scelta, non un obbligo tecnico.