MiniCPM-V 4.7-35B-A3B-DSpark: il Draft da 389M di OpenBMB arriva con una card che il suo modello base non ha mai ricevuto

MiniCPM-V-4.7-35B-A3B-DSpark è un modello draft da 389.223.169 parametri. Non risponde alle domande, non vede le immagini e, da solo, è inutile. Il suo unico compito è indovinare i prossimi quindici token, così che MiniCPM-V-4.7-35B-A3B possa verificare un intero blocco in un'unica passata in avanti invece di generare un token alla volta. Questa è la decodifica speculativa, e OpenBMB ha rilasciato un draft per il suo nuovo modello visione-linguaggio da 35B undici giorni fa senza dire pubblicamente una parola al riguardo.

Ciò che lo rende degno di una pagina non è la bozza. È la documentazione che lo accompagna. Il checkpoint DSpark ha una model card: una licenza, una tabella di specifiche, una ricetta di addestramento e una tabella delle lunghezze di accettazione per sette categorie di attività. Il suo modello genitore da 35 miliardi di parametri non aveva nulla di tutto ciò quando è apparso. Quindi, per la prima volta, ci sono numeri reali allegati a una release di MiniCPM-V 4.7 — e sono numeri relativi al modello genitore, misurati indirettamente, da un file da 0,78 GB la cui finalità dichiarata è renderlo più veloce.

Tutto ciò che segue separa ciò che è riportato sulla scheda da ciò che la scheda non stabilisce. I valori di accettazione sono di OpenBMB stesso e nessuno al di fuori del laboratorio li ha riprodotti. La tabella di benchmark del modello base non esiste ancora.

Che cos'è realmente il checkpoint DSpark

Il repository openbmb/MiniCPM-V-4.7-35B-A3B-DSparkrisale all'8 ottobre 2026. È un checkpoint in un unico file — model.safetensors, più un config.json e un README — sotto Apache-2.0, con tag per inglese e cinese. Una seconda bozza, openbmb/MiniCPM-V-4.7-1B-DSpark, è stata creata un secondo prima, quindi i due sono stati inviati all'hub nello stesso batch anziché essere scoperti uno alla volta.

Ogni draft si trova davanti a un solo target e solo a quello. La scheda lo dice chiaramente: questo checkpoint è "addestrato per l'accoppiamento esatto con MiniCPM-V-4.7-35B-A3B e il suo tokenizer". Il vocabolario è quello del modello padre, tutti i suoi 248.144 token, il che è un requisito più che un'ottimizzazione — un drafter i cui token non si mappano uno a uno su quelli del target non può proporre nulla che il target possa accettare. Lo stesso vincolo è il motivo per cui il draft gemello esiste separatamente invece di un unico drafter che serva la famiglia.

L'architettura non è una copia più piccola del genitore. È uno stack di attenzione a cinque livelli, larghezza nascosta di 2.048, 8 teste di query contro 2 teste key/value, una dimensione intermedia di 6.144 e RoPE con un theta di 10.000.000. Il architetture riporta Qwen3DSparkModel — lo stesso backbone della famiglia Qwen3 da cui proviene lo stack linguistico del genitore, ridotto a uno stub.

La parte interessante è come lo stub comunica con il target. Non legge il layer finale del target. Preleva stati nascosti da cinque layer intermedi — [3, 11, 19, 27, 35] dei 40 del parent — e li proietta attraverso un proiettore di tipo dspark. Attingere dal mezzo dello stack invece che dalla fine è deliberato: gli stati di metà rete sono più economici da allineare e trasportano informazioni che il layer finale ha già compresso nei logit del token successivo. La configurazione equipaggia anche una confidence head con una componente di Markov di rango 256, che è il meccanismo del paper DSpark per decidere quanto di un blocco proposto valga la pena verificare.

La tabella di accettazione è una scheda, non una misurazione.

Ecco tutti i dati numerici che OpenBMB ha pubblicato riguardo a quanto bene funziona questa coppia, espressi come token accettati per fase di verifica, con terminazione EOS naturale e max_new_tokens=8192:

• Vision, MMMU — 5.098 token accettati per step.

• Visione, MathVista — 6.126.

• Visione, ragionamento CharXiv (validazione) — 5.479.

• Vision, OCRBench — 5.407.

• Testo, Matematica — 6.687.

• Testo, Codice — 7.387.

• Testo, Generale — 3.501.

Tre cose su quella tabella meritano di essere dette apertamente. Primo, i dati sono auto-dichiarati. Nessuno al di fuori di OpenBMB ha eseguito questo checkpoint e pubblicato un numero, e con un solo download registrato sul repository, nessuno al di fuori di OpenBMB lo ha eseguito affatto. Secondo, la lunghezza di accettazione è una proprietà della coppia, non del modello — misura quanto è prevedibile l'output di MiniCPM-V-4.7-35B-A3B, non quanto sia buono quell'output. Un target che si ripete regala al drafter una vittoria facile. Terzo, la variabilità è il punto: 7,387 sul codice contro 3,501 sul testo generale è un fattore due tra la categoria migliore e quella peggiore, e il fatto che il codice sia il più facile riflette la superficie a bassa entropia e altamente ripetitiva del codice più che un qualsiasi punto di forza dei modelli.

C'è anche una lettura di pura aritmetica che la scheda lascia implicita. Un drafter che propone 15 token e ne vede accettati da 5 a 7 continua comunque a spostare diversi token per ogni forward pass del target, quindi il tetto massimo qui è un grande guadagno di throughput — ma non è la rivendicazione ingenua del "5 volte più veloce", perché verificare un blocco di 15 token costa più che generare un singolo token, e le proposte rifiutate vengono pagate e gettate via. Quel divario è esattamente l'argomento del paper DSpark, ed è il motivo per cui la configurazione espone un interruttore per disattivare la verifica adattiva.

Cosa ci dice accidentalmente la bozza sul modello base

MiniCPM-V 4.7 ha etichettato il suo rilascio come avvenuto in sordina — pesi, nessun post di lancio. Ora però questo è cambiato, in modo piccolo ma reale. Il repository principale su openbmb/MiniCPM-V-4.7-35B-A3B è stato creato il 7 ottobre 2026. Entro il 12 ottobre conteneva una scheda modello completa con un README, una pagina di rilascio in stile Hugging Face, un elenco di dichiarazioni, una sezione on-device e una tabella dei pesi. Da allora il repository ha sviluppato una famiglia di quantizzazione — build FP8, int4, AWQ, GPTQ e GGUF, ciascuna su un proprio repo, tutte toccate il 12 ottobre — e 27 like contro 166 download.

Quindi il quadro accurato è un rilascio in due fasi, non un rilascio silenzioso. I pesi sono arrivati il 6 e 7 ottobre. I checkpoint bozza sono seguiti l'8 ottobre. La documentazione, le quantizzazioni e il supporto on-device sono arrivati entro il 12 ottobre. OpenBMB non ha ancora pubblicato un post sul blog né un rapporto tecnico per la famiglia, e non c'è ancora una tabella di benchmark sulla scheda principale — le dichiarazioni sulle prestazioni si trovano dentro immagini di grafici collegate anziché come testo che un lettore possa citare.

L'affermazione che compare effettivamente nel testo è quella principale: con Lookahead Expert Scheduling, la quantizzazione layer-wise e "DSpark speculative sampling integration", il modello 35B-A3B viene descritto come il primo modello MoE open source a funzionare senza problemi sul dispositivo, a 13 o più token al secondo su un iPhone 17 Pro Max. Quel dato è dichiarato dal fornitore, non riprodotto e non qualificato — nessun formato di quantizzazione, nessuna build, nessun prompt, nessun metodo di misurazione. Il checkpoint DSpark è una delle tre tecniche su cui si basa quell'affermazione, il che lo rende l'unico dei tre che puoi scaricare e ispezionare. È anche quello la cui evidenza è una singola riga di benchmark non letta per attività.

Eseguirlo, se vuoi

La scheda include una sola ricetta ed è un comando vLLM, non un gesto vago. Serve il target con tensor-parallel size 2, una lunghezza massima del modello di 40.960, FLASH_ATTN su entrambi i backend di attenzione del linguaggio e dell'encoder multimodale, una modalità di downsampling visivo 4x, enable_thinking impostato su false, e la configurazione speculativa puntata al checkpoint DSpark con 15 token speculativi e la verifica adattiva disattivata. Due dettagli in quella riga meritano di essere notati di per sé: --max-num-seqs 1 significa che la configurazione pubblicata serve una sequenza alla volta, e --disable-custom-all-reduce con il pass di fusione all-reduce disattivato significa che questa è una configurazione che è stata messa a punto per funzionare, non per essere massimamente veloce. Considera la ricetta come un punto di partenza che OpenBMB è riuscita a mettere in funzione, non come un'affermazione sul throughput.

Il limite hardware è la vera barriera. L'obiettivo è di circa 70 GB di pesi BF16 prima della KV cache, e il draft aggiunge circa 0,78 GB in più. Due acceleratori sono il minimo dichiarato, il che lo colloca ben al di fuori del telefono su cui fa leva il marketing della famiglia — un deployment on-device per un modello 35B-A3B implica quantizzazione aggressiva e offloading, ed è proprio a questo che servono il lavoro su LES e sulla quantizzazione layer-wise, e nessuno dei due è nella ricetta vLLM di cui sopra.

Quell'asimmetria è la decisione pratica per la maggior parte dei team. Servire MiniCPM-V 4.7 costa due GPU di tua proprietà; chiamare un MoE multimodale ospitato comparabile non costa nulla in anticipo. Qwen3.6 35B A3B è il confronto diretto più vicino — stessa configurazione da 35B totali e 3B attivi, stesso contesto da 262K, input di immagini e video — ed è servito tramite OrcaRouter a partire da $0,248 per milione di token di input e $1,485 per milione di token di output a seconda della rotta del provider, con failover automatico se una di quelle rotte si degrada. MiniCPM-V 4.7 non è un modello ospitato su OrcaRouter e questo articolo non fingerà il contrario; la formulazione onesta è che i due sono alternative a un punto decisionale, e quello ospitato è quello che puoi misurare questo pomeriggio.

Cosa renderebbe questo verificabile?

Il checkpoint DSpark è Apache-2.0, pesa meno di un gigabyte e viene fornito con un comando di serving che qualcuno con due GPU potrebbe incollare in un terminale oggi stesso. Questa combinazione lo rende la via più economica verso un numero indipendente su MiniCPM-V 4.7 — non un punteggio di benchmark, ma qualcosa di quasi altrettanto utile: una lunghezza di accettazione riprodotta. Se una parte esterna eguaglia 5,1 su MMMU e 3,5 su testo generico, la card è credibile e la storia di efficienza della famiglia guadagna il suo primo punto dati esterno. Se l'accettazione risulta sostanzialmente inferiore, la tabella pubblicata è stata misurata in condizioni che la ricetta non riproduce, e l'affermazione di 13 token al secondo eredita quel dubbio.

Ciò che manca ancora è la cosa per cui normalmente serve una model card. Non c'è alcun punteggio MMMU, nessun punteggio OCRBench, nessun risultato di comprensione dei documenti, nessun valore di grounding e nessun dato di latenza per MiniCPM-V 4.7 stesso — nulla che risponda alla domanda se questo modello sia buono. La tabella del modello draft non può sostituire ciò, e leggere un'elevata lunghezza di accettazione come segnale di qualità è esattamente l'errore che i numeri invitano a commettere. Una predizione a forma di ChatGPT è facile per un drafter e non dice nulla sul fatto che la predizione fosse corretta.

Quindi: un vero artefatto, una vera licenza, un elemento di evidenza pubblicata davvero nuovo su un modello che non ne aveva alcuna — e un divario di valutazione ampio esattamente quanto lo era il 7 ottobre. Il prossimo file da aggiornare è ancora la scheda del modello del genitore.