Il "3B di parametri attivi" di MiniCPM-V 4.7 non è nella model card — l'ho misurato dai pesi

Il numero più ripetuto riguardo a MiniCPM-V 4.7 35B-A3B non è stampato da nessuna parte nella sua documentazione. L'affermazione — "solo 3B parametri attivi (!) — gira persino su un iPhone" — proviene da un post di terze parti del 13 ottobre 2026, e la model card del fornitore, il README del repository e le note di lancio non indicano mai una cifra di parametri attivi. Non è tanto una critica all'affermazione quanto una lacuna che vale la pena colmare: il checkpoint codifica la propria risposta. Quindi, prima di ogni altra cosa qui, ho estratto l'indice safetensors e ogni header di shard per openbmb/MiniCPM-V-4.7-35B-A3B e ho contato. Per confronto, l'altro modello nello stesso post — Qwen3.8-27B, rilasciato il 13 agosto 2026 — è un denso da 27B e non ha una simile ambiguità da risolvere: ogni parametro è attivo su ogni token. La domanda interessante è se "3B attivi" sopravvive al contatto con i pesi, e la risposta è: sopravvive, ma solo se si definisce la parola "attivi" alla maniera del fornitore, e il numero onesto è più vicino a 4B una volta contate le parti che non si può evitare di eseguire.

Il registro, letto dal checkpoint stesso

Il file di indice elenca 40 livelli linguistici più una torre di visione e un proiettore, 35.212.875.824 parametri in totale in BF16 — 70,43 GB di pesi da scaricare. Questo corrisponde al "35B" nel nome. La domanda MoE è quale frazione di ciò venga toccata per token:

• Totale memorizzato — 35,21 miliardi di parametri, 70,43 GB in BF16. Ogni esperto è su disco, indipendentemente dal fatto che venga utilizzato.

• Budget del router — 8 esperti selezionati per token, su 256, per ogni layer MoE. Configurato in config.json come num_experts_per_tok: 8. Ogni esperto è piccolo: 3,15 M di parametri.

• Percorso MoE per layer — 8 esperti (25,17M) + un esperto condiviso (3,15M) + il gate del router (0,52M) ≈ 28,83M.

• Percorso di attenzione per layer — l'architettura è ibrida: 30 dei 40 layer utilizzano attenzione lineare (33,72M ciascuno), 10 utilizzano attenzione completa (27,26M ciascuno). Totale ≈ 2,44B su tutti i 40 layer per l'attenzione più l'aritmetica MoE, ripetuto per token.

• In più, ciò che non puoi saltare — embedding dei token 508,2 M, LM head 508,2 M, torre di visione 522,3 M, proiettore 30,7 M.

• Le due risposte difendibili — ~2,44B attivi sul solo percorso attention-and-MoE; ~4,01B se si contano embedding, output head, vision tower e projector, che una richiesta di visione esercita effettivamente.

Quindi "3B active" non è sbagliato. È un arrotondamento per eccesso di 2,44B, e si colloca nel divario tra i due numeri sopra. Solo che non è una cifra pubblicata da OpenBMB, e non è la stessa cosa del suffisso "A3B" — quel suffisso fa parte del nome del modello, e i materiali del fornitore stesso non lo trasformano mai in una misura.

Perché il suffisso e il numero non sono la stessa cosa

Le convenzioni di denominazione nell'ecosistema open-weights implicano un numero di parametri attivi: un modello chiamato 30B-A3B, o 235B-A22B, ti sta dicendo che attiva all'incirca quel numero di parametri per token. L'implicazione è di solito affidabile, ma è una convenzione, non un contratto, e MiniCPM-V 4.7 è un caso in cui nulla nella scheda, nel README o nel post di lancio converte l'"A3B" in un numero su cui pianificare la memoria. Finché qualcuno non conta, il suffisso è un'etichetta.

Il conteggio di cui sopra è aritmetica, non un'inferenza da quell'etichetta. È anche il motivo per cui le cifre di ~2,44B e ~4,01B differiscono: se contare la tabella di embedding e la testa di output sia una vera decisione, non una questione di pedanteria. In un modello denso, gli embedding sono una piccola fetta di un budget di 27B. In un modello sparso, dove il percorso di calcolo per token è di appena qualche miliardo di parametri, una tabella di embedding da 508M e una testa LM da 508M non sono più rumore: insieme costituiscono circa un quinto del percorso attivo, e sono memorizzate a larghezza piena mentre gli esperti sono quantizzati.

Una conseguenza che vale la pena affermare chiaramente: qui il rapporto tra parametri memorizzati e parametri attivi è di circa 8,8 a 1 nella lettura restrittiva. È proprio per questo che un modello da 35B può essere presentato come un modello per telefono, ed è anche il motivo per cui non lo è nel modo in cui lo è un modello denso da 3B. L'archiviazione non si riduce quando il router ignora un esperto.

L'affermazione sull'iPhone è un'affermazione separata con una base di prove separata

Tutto ciò che di concreto riguarda le prestazioni on-device in questa release è dichiarato dal fornitore e non riprodotto. Il dato specifico è di oltre 13 token al secondo con circa 3 GB di memoria su un iPhone 17 Pro Max, con lo stesso checkpoint dimostrato su un iPad M4. OpenBMB lo attribuisce a tre tecniche che lavorano insieme — Lookahead Expert Scheduling, che prevede il routing cross-layer e pre-carica gli esperti, la quantizzazione fine-grained layer-wise e il campionamento speculativo DSpark — e descrive il risultato come il primo modello MoE open source a funzionare senza problemi on-device senza perdere capacità. Non esiste alcuna misurazione indipendente di quel throughput nel registro pubblico, nessuna riproduzione da parte di terzi e nessuna analisi pubblicata di quale quantizzazione presupponga il dato dei 3 GB.

Questo è importante per un motivo specifico: 3 GB è il numero che determina se l'affermazione è interessante per te, ed è il numero che conosciamo meno. Un MoE da 35B i cui pesi degli esperti risiedono per lo più su memoria flash non è un modello da 3 GB, è un modello il cui working set residente riesce a stare in 3 GB una volta che previsioni di routing, prefetch e una cache di esperti quantizzata fanno tutti il loro lavoro. Sono esattamente le condizioni in cui il throughput di benchmark e il throughput reale divergono — il primo prompt scalda la cache, e il comportamento che ti fa ottenere 13 token al secondo in una demo è una schedulazione, non una proprietà dei pesi.

Considera i 13 token al secondo come un'affermazione su una tecnica, non sul checkpoint. Il checkpoint è ciò che puoi verificare oggi: 35,21B memorizzati, 8 di 256 esperti instradati per token, da ~2,44B a ~4,01B attivi a seconda di cosa conteggi, Apache-2.0, quantizzazioni day-0 in GGUF, AWQ, GPTQ, int4 e FP8, e un elenco di fornitori di chip supportati che include Rockchip, Houmo, Intel, AMD e Arm.

Cosa decide e cosa non decide il conteggio attivo

Il conteggio dei parametri attivi è un proxy di calcolo. Ti dice quanta moltiplicazione matriciale avviene per token, il che corrisponde alla velocità con cui viene eseguita una decodifica limitata dalla GPU. Non ti dice quanta memoria serve per contenere il modello, che è determinata dal totale — 70,43 GB di pesi BF16, o circa un quarto di ciò a 4 bit, prima di considerare una cache KV. Su un modello con contesto da 256K, anche quella cache non è certo un dettaglio trascurabile.

• Velocità di decodifica — determinata dai parametri attivi (~2,44B–4,01B qui). È a questo che si riferisce l'affermazione di 13 token/s.

• Memoria residente — determinata dal numero totale di parametri (35,21 miliardi memorizzati), poi ridotta dalla quantizzazione e da qualunque insieme di esperti rimanga residente.

• Archiviazione e caricamento — determinati dall'intera dimensione di 70,43 GB in BF16. Il routing sparso non riduce il download.

• Larghezza di banda, non i flops — su un telefono il vincolo limitante è far passare gli esperti attraverso un bus di memoria, ed è per questo che esiste la tecnica di scheduling e perché un conteggio degli attivi da solo non predice nulla sulla latenza mobile.

Il risultato pratico: se disponi di una GPU con memoria sufficiente a contenere i pesi quantizzati, il conteggio attivo è ciò che determina il tuo throughput e «3B attivi» è una buona cosa. Se sei tu la ragione per cui la frase «gira su un iPhone» compare in un post, il conteggio totale è il numero che decide la fattibilità, e il lavoro di pianificazione del fornitore è la parte che rende vivibile il conteggio totale. Entrambe le letture dello stesso titolo sono corrette e non sono la stessa lettura.

Il confronto in quel post necessita di due etichette, non una.

L'inquadramento che ha fatto il giro questa volta era hardware locale contro hardware costoso: MiniCPM-V 4.7 35B-A3B come il modello che ti dà la stessa capacità senza la macchina, contro Qwen3.8-27B come il modello che era più intelligente ma richiedeva la macchina. La metà di tutto ciò relativa alle capacità deriva dalla model card di Qwen stessa, ed è dichiarata dal fornitore come tutto il resto in questa pagina. I numeri pubblicati di Qwen per Qwen3.8-27B includono 90,3 su LiveCodeBench v6, 89,2 su GPQA Diamond, 84,3 su OSWorld-Verified e 79,0 su QwenSWEBench, e la nostra voce di catalogo per esso li segnala come risultati agentici e di coding insolitamente forti per un modello dense da 27B. Che fosse "più intelligente di Opus 4.6" è un'affermazione del post social, e non ho davanti a me alcuna valutazione indipendente che lo risolva — quindi non intendo ripeterlo come un fatto.

La differenza strutturale è quella effettivamente verificabile: Qwen3.8-27B è dense, quindi i suoi 27 miliardi di parametri sono tutti attivi e la sua impronta di memoria e il suo costo computazionale sono lo stesso numero. MiniCPM-V 4.7 35B-A3B separa questi due numeri di circa un fattore nove. Questo è tutto l'argomento architetturale, ed è reale. Solo che non è la stessa cosa di un confronto benchmark, e il post che l'ha reso famoso ha mescolato le due cose.

Dove un router cambia la decisione e dove no

Due cose sono vere qui e meritano di essere tenute separate, perché puntano in direzioni opposte.

Il primo è che non forniamo MiniCPM-V 4.7. Non è nel nostro catalogo. Se lo vuoi, la strada è il tuo hardware — che è esattamente ciò per cui è pensata questa release, con pesi, quantizzazioni e guide di deployment on-device pubblicate insieme ad essa. Nulla di una API hosted ti aiuta a eseguire un modello su un telefono, e sarebbe fuorviante suggerire il contrario.

Il secondo è che il modello con cui questo viene confrontato non si trova in quella posizione. Qwen3.8-27B è disponibile tramite la nostra API, self-hosted sulla nostra infrastruttura, a 0,33 $ per milione di token di input e 2,40 $ per milione di token di output. Se la domanda che stai davvero ponendo è "sostituisco le mie chiamate a Qwen3.8-27B ospitate con un MiniCPM-V 4.7 distribuito localmente", la versione onesta della risposta è che dovresti eseguire l'esperimento prima di impegnarti: il dato di throughput on-device non è stato riprodotto, e il confronto delle capacità è la scheda della controparte stessa. È per questa situazione che esiste il failover — instrada una frazione del traffico su un nuovo percorso, tieni quello collaudato alle spalle e lascia che una settimana storta ti costi una frazione di un carico di lavoro anziché il carico di lavoro. Un modello con markup dello 0% mantiene anche l'aritmetica onesta: quando un fornitore cambia un prezzo, la cifra che paghi cambia lo stesso giorno, perché non c'è alcuno strato di margine tra il loro prezzo di listino e la tua fattura.

Quello che un router non può fare è far scomparire la questione locale-versus-ospitato. Quella la decidono il tuo hardware, i tuoi vincoli di privacy e se un download da 70 GB è accettabile — e il numero di parametri attivi, comunque lo si arrotondi, non cambia nessuna delle tre.

Cosa lo risolverebbe

Tre cose, in ordine decrescente di utilità. Una cifra sui parametri attivi pubblicata da OpenBMB, così che il numero che tutti ripetono smetta di essere l'aritmetica di una terza parte — compresa la mia, e la mia è riproducibile dagli header degli shard se non concordi con essa. Una misurazione indipendente dei 13 token al secondo su un telefono, con le impostazioni di quantizzazione dichiarate, perché un dato dipendente dallo schedule senza le sue impostazioni non è una specifica. E una valutazione reale che confronta MiniCPM-V 4.7 35B-A3B con Qwen3.8-27B sugli stessi compiti, dato che il confronto che ha reso notevole questo modello è attualmente il grafico di un fornitore contro la scheda di un altro fornitore.

Fino ad allora, il riassunto prudente è più ristretto del post: i pesi sono reali, la sparsità è reale, il download è di 70,43 GB, e per token il modello svolge un lavoro pari a un numero di parametri compreso tra 2,4 e 4 miliardi, a seconda di come si contano le parti che non si possono aggirare. Questo è un autentico risultato ingegneristico. Non è ancora un benchmark misurato su telefono, e non è una vittoria di benchmark su un 27B denso.

Fonti: parametri, numero di esperti, tipi di layer, lunghezza del contesto e dimensione del download sono stati letti direttamente da config.json e dagli header degli shard safetensors di openbmb/MiniCPM-V-4.7-35B-A3B il 13 ottobre 2026. La velocità sul dispositivo, il dato di memoria, i risultati dei benchmark e i numeri della valutazione di Qwen3.8-27B sono dichiarati dal fornitore e non riprodotti. Le affermazioni «3B parametri attivi» e «più intelligente di Opus 4.6» provengono da un post social di terze parti, non da nessuno dei due fornitori.

Niente di tutto ciò è ipotetico: i fallimenti documentati dell'IA e gli incidenti degli agenti in cui viene citato un numero come questo sono raccolti in l'Archivio degli incidenti IA di OrcaRouter, dove ogni voce riporta le proprie fonti, il livello di gravità, il grado di confidenza e il flag di contestazione.