MiniCPM-V 4.7: OpenBMB ha caricato un modello visione-linguaggio 35B-A3B senza model card, senza licenza e senza benchmark

MiniCPM-V 4.7 è apparso su Hugging Face la sera del 6 ottobre 2026 come repository openbmb/MiniCPM-V-4.7-35B-A3B — ed è una delle cose più strane che la serie MiniCPM abbia mai rilasciato, perché quasi nulla è stato rilasciato insieme ad esso. Non c'è una model card. Non c'è un README. Non c'è una licenza dichiarata. Non ci sono tabelle di benchmark, né un post di lancio, né un report tecnico, e nessuna voce nella stessa documentazione GitHub di OpenBMB, che ancora questa settimana continua a definire MiniCPM-V 4.6 "il modello più recente ed efficiente della serie MiniCPM-V". Ciò che esiste sono 16 shard di pesi bfloat16, 70,4 GB di essi, che descrivono un modello visione-linguaggio mixture-of-experts da 35,2 miliardi di parametri con una finestra di contesto da 256K e un design di attenzione ibrida insolitamente aggressivo. Questo basta per dire quello che il modello è. Non basta ancora per dire in cosa è bravo, e questo articolo tiene rigorosamente separate queste due cose.

Cosa è effettivamente arrivato, byte per byte

Il repository è stato creato alle 18:36 UTC del 6 ottobre 2026 e il suo ultimo commit è avvenuto dodici minuti dopo, alle 18:48 UTC. Nel frattempo, chi ha effettuato il caricamento ha eseguito il push dei file dei pesi e della configurazione necessaria a un loader di Transformers, poi si è fermato. L'elenco completo dei file è lungo diciotto voci:

• Pesi — sedici safetensors shard denominati model-00001-of-00016 fino a model-00016-of-00016, con il file indice model.safetensors.index.json che riporta una dimensione totale dei tensori di 70.425.751.648 byte.

• Numero di parametri — l'API di Hugging Face legge 35.212.875.824 parametri, tutti in BF16. Nota che questo è il totale conteggio, che per un MoE sparso non è il numero di parametri attivi su un dato token.

• Configurazione — config.json (2.984 byte), generation_config.json (186 byte), preprocessor_config.json, processor_config.json.

• Tokenizer — tokenizer.json (20 MB), tokenizer_config.json, e chat_template.jinja (7.250 byte).

• Mancante — README.md. Una richiesta diretta del file raw restituisce HTTP 404. Su Hugging Face un README mancante significa nessuna model card, il che significa nessun campo di licenza, il che significa che il repository non riporta affatto alcun license: tag.

Il repository ha tre like, zero download e una scheda di discussione vuota. Un caricamento della community di un checkpoint da 70 GB di solito attira commenti nel giro di ore — domande sulle quantizzazioni, sul serving, su quale sia la licenza. Questo no, il che è coerente con il fatto che sia stato notato da una manciata di persone che seguono openbmb come organizzazione anziché essere annunciato a qualcuno.

L'architettura, letta direttamente da config.json

Poiché non c'è una card da parafrasare, il file di configurazione è la fonte primaria, ed è insolitamente informativo. La classe è MiniCPMV4_7ForConditionalGeneration, il tipo di modello è minicpmv4_7, ed è stato salvato da Transformers 5.2.0 — tutti elementi che indicano che si tratta di un checkpoint di prima parte di OpenBMB nella linea principale MiniCPM-V, non di un fine-tune della community che ne porta il nome.

• Backbone linguistico — model_type: qwen3_5_moe_text. Un MoE sparso derivato da Qwen3.5, la prima volta che la linea MiniCPM-V ha utilizzato uno stack di testo Qwen-MoE anziché le varianti Qwen dense di piccole dimensioni che alimentavano MiniCPM-V 4.5 e 4.6.

• Sparsità — 256 esperti, 8 selezionati per token, con una dimensione intermedia dell'esperto di 512 e un esperto condiviso della stessa dimensione. Un checkpoint totale da 35B su un pattern di routing 8-su-256 attiva una piccola frazione di esso per ogni forward pass, che è tutto il senso del nome A3B: i pesi sono grandi, il calcolo no.

• Profondità e larghezza — 40 strati nascosti, dimensione nascosta 2048, 16 teste di attenzione con 2 teste chiave/valore e una dimensione della testa di 256.

• Attenzione ibrida — l'array layer_types è lungo 40 voci e alterna tre linear_attention layer per ogni full_attention layer con cadenza fissa di 4. Dieci dei quaranta layer adottano l'attenzione convenzionale; gli altri trenta usano un percorso lineare in stile Mamba con un kernel di convoluzione di 4. Questa è la scelta progettuale più determinante del file, ed è la stessa direzione in cui si è mosso il settore nel suo complesso nel corso del 2026.

• Codifica posizionale — RoPE con un theta di 10,000,000 e partial_rotary_factor: 0.25, il che significa che solo un quarto delle dimensioni di ciascuna testa viene ruotato. Il RoPE multimodale è abilitato con mrope_interleaved: true, una suddivisione delle sezioni di [11, 11, 10], e mrope_mode: canvas.

• Contesto — max_position_embeddings: 262144, e il model_max_length del tokenizer concorda. 256K token.

• Predizione multi-token — mtp_num_hidden_layers: 1, una singola testa di decodifica speculativa, lo stesso trucco adottato da MiniCPM-V 4.6.

• Torre di visione — minicpmv4_7_vision, dimensione nascosta 1152, 27 livelli, attivazioni GELU-tanh, dimensione patch 14 con un image_size di 980, e un insert_layer_id di 6, che è il punto in cui gli embedding visivi vengono inseriti nello stack linguistico. La forma della torre è vicina a quella di MiniCPM-V 4.6, quindi il lato visione è un'evoluzione più che una ricostruzione.

• Compressione visiva — downsample_mode: "16x" e max_slice_nums: 9 nel processore di immagini. MiniCPM-V 4.6 ha introdotto uno schema di compressione dei token commutabile 4x/16x; la configurazione 4.7 indica l'impostazione 16x come predefinita, con lo slicer che consente fino a nove sotto-immagini per input ad alta risoluzione.

• Vocabolario — 248.144 token, con <|image_pad|> all'id 248.056 e <|video_pad|> a 248.057. Il video è un input di prima classe, esattamente come lo è stato da MiniCPM-V 4.5.

• Un curioso residuo — la configurazione del tokenizer dichiara ancora <|audio_start|>, <|audio_end|> e <|audio_pad|>. Questo significa quasi certamente che il vocabolario è condiviso con il ramo omni MiniCPM-o, piuttosto che MiniCPM-V 4.7 parli audio. Interpretarlo come una funzionalità audio sarebbe un errore che la configurazione da sola non può escludere.

Ciò che la famiglia ci dice che questo repository non dice

La generazione 4.6 è il punto di riferimento, e il contrasto è la storia. MiniCPM-V 4.6 è stato rilasciato l'11 maggio 2026 come modello da 1,3 miliardi di parametri, costruito su un encoder visivo SigLIP2-400M e un modello linguistico Qwen3.5-0.8B, con licenza Apache-2.0, e con una presentazione esplicita: ottiene 13 sull'Artificial Analysis Intelligence Index — un dato dichiarato dal fornitore — pur usando drasticamente meno token rispetto a modelli piccoli comparabili, e funziona su iOS, Android e HarmonyOS con il codice di adattamento per l'edge reso open source. La sua intera identità era "piccolo, efficiente, on-device".

MiniCPM-V 4.7 è 1.3B moltiplicato per circa 27. Il nome 35B-A3B lo colloca nella classe occupata dai flagship sparsi, non dai telefoni. Che OpenBMB lo intenda come compagno lato server della linea edge, come insegnante per un futuro modello piccolo o come test del tetto di capacità non è dichiarato da nessuna parte, e il repository non contiene alcun indizio in un senso o nell'altro.

Ciò che è davvero nuovo, e degno di essere segnalato a chiunque segua la serie, è la backbone Qwen-MoE insieme al rapporto 3:1 tra attenzione lineare e attenzione completa. Entrambi rappresentano una rottura rispetto al passato. Tutto ciò che OpenBMB pubblica sulla famiglia è ancora incentrato sulla versione 4.6, quindi questo checkpoint è in anticipo rispetto alla propria documentazione.

Ciò che non è ancora conoscibile — e perché quell'elenco è importante

Vale la pena essere schietti sulla dimensione del buco qui, perché con un checkpoint da 70 GB la tentazione è di riempirlo con inferenze plausibili.

• Nessuna licenza. Non è una formalità. MiniCPM-V 4.6 è Apache-2.0, e la comunità si aspetta questo da questa linea. Un repo senza licenza: tag è, per impostazione predefinita, soggetto a tutti i diritti riservati nella maggior parte delle giurisdizioni — non puoi costruirci sopra in sicurezza finché il tag non compare. Quel singolo file mancante è l'assenza più significativa nel repository.

• Nessun benchmark, né riportato dal fornitore né di altro tipo. Non c'è un solo numero su cui discutere. Chiunque oggi citi un punteggio MMMU o OCRBench per MiniCPM-V 4.7 sta citando qualcosa che non esiste nella fonte.

• Nessuna valutazione indipendente. Artificial Analysis e tracker simili indicizzano i modelli per nome; un checkpoint senza card e senza annuncio in genere resta non misurato per un po'.

• Nessuna ricetta di servizio. Che i pesi rilasciati funzionino così come sono in vLLM, SGLang o llama.cpp non è stato testato da nessuno al di fuori di OpenBMB. I percorsi di codice personalizzati (MiniCPMV4_7ForConditionalGeneration, MiniCPMV4_7Processor, MiniCPMV4_7ImageProcessor, MiniCPMV4_7VideoProcessor) richiedono tutti trust_remote_code, e la combinazione di MoE e attenzione lineare non è una forma per cui ogni motore di inferenza abbia un kernel.

• Nessuna quantizzazione. MiniCPM-V 4.6 ha rilasciato varianti GGUF, AWQ, GPTQ e BNB, e ha raggiunto la libreria di Ollama a giugno 2026. Non ne esistono per 4.7. Per un modello da 35B questa è la differenza tra un laptop e un cluster.

• Nessuna relazione con 4.6 dichiarata. OpenBMB potrebbe stare sostituendo la linea edge, estendendola o testando qualcosa di ortogonale. Il repository non lo dice, e nemmeno il README di GitHub, che al suo commit dell'8 settembre 2026 elenca ancora 4.6 come release corrente.

Esiste anche una lettura plausibile ma non confermata della cronologia: l'intervallo di dodici minuti tra la creazione del repo e l'ultimo commit, l'assenza di una card e l'assenza di qualsiasi post sono ciò che un checkpoint sembra quando viene preparato per un lancio anziché dopo che è avvenuto. Si tratta di un'ipotesi sull'intenzione, non di un fatto relativo all'artefatto, e va trattata come tale.

Come lo eseguiresti effettivamente, quando c'è qualcosa da eseguire

Qui nulla è ancora citabile come percorso supportato, ma la configurazione vincola le opzioni. Un checkpoint BF16 da 35B parametri richiede circa 70 GB di memoria dell'acceleratore prima della KV cache, quindi il deployment hobbistico su singola GPU è escluso finché non arrivano le quantizzazioni. Il contesto da 256K e il rapporto di attenzione lineare 3:1 fanno sì che la KV cache cresca molto più lentamente di un transformer convenzionale della stessa profondità, ed è proprio per questo che quell'architettura vale la complessità: il lavoro multimodale a contesto lungo è il campo in cui il design si ripaga da sé. Quando compare una scheda, le prime cose da controllare sono la licenza, se è pubblicata una ricetta ufficiale per vLLM o SGLang e se il downsample predefinito 16x può essere scambiato con l'impostazione 4x che 4.6 ha esposto.

Per i team che vogliono valutare un modello come questo nel momento in cui diventa utilizzabile, il problema pratico non sono i pesi, ma l'infrastruttura che li circonda. Un modello che risiede sulla tua GPU ha comunque bisogno di tutto ciò che gli sta attorno — un router che mette oltre 200 modelli ospitati dietro un'unica chiave, al prezzo di listino di ciascun provider senza alcun nostro sovrapprezzo applicato, e che esegue automaticamente il failover quando un provider peggiora. È a questo che serve OrcaRouter, e vale la pena dire chiaramente che MiniCPM-V 4.7 stesso non è un modello ospitato: è un checkpoint con pesi aperti che servi tu stesso. Il router qui conta come l'altra metà dell'architettura — il modello di frontiera a cui la tua macchina 4.7 passa i casi difficili, raggiungibile tramite lo stesso client che hai già scritto.

Lo stato delle cose, e l'unico file da aggiornare

MiniCPM-V 4.7 esiste. I suoi pesi sono scaricabili oggi, il conteggio dei pesi è esatto, e le scelte progettuali dell'epoca di addestramento — MoE sparso, attenzione lineare 3:1, contesto 256K, compressione visiva 16x — sono tutte leggibili dal file di configurazione. Ciò che non esiste è una qualsiasi dichiarazione di OpenBMB su cosa faccia il modello, quanto costi eseguirlo nella pratica o cosa ti sia consentito farne. Per un laboratorio il cui ultimo modello di visione era una release edge da 1,3B Apache-2.0 con una tabella comparativa completa, questa è una lacuna stridente, e l'atteggiamento sensato è osservare il repository invece del dibattito. L'unico file da continuare a ricaricare è README.md: nel momento in cui apparirà, conterrà la licenza, i benchmark e probabilmente la spiegazione di cosa ci faccia un MiniCPM-V da 35B in una serie costruita su modelli piccoli.

Fino ad allora, il riassunto onesto è quello noioso. Questo è un checkpoint reale di un laboratorio reale, caricato in silenzio, e la domanda interessante — vale qualcosa — non ha una risposta pubblicata.

OrcaRouter raggiunge più di 200 modelli ospitati tramite un'unica chiave, con il prezzo di listino di ciascun provider passato direttamente a ricarico 0% e failover automatico tra provider. prezzo di listino del provider passato a ricarico 0% MiniCPM-V 4.7 non è tra questi: è un checkpoint open-weights che servi tu stesso, e il router è ciò che si trova dall'altra parte del passaggio di consegne.