MiniCPM-V-4.7-1B-DSpark: un modello draft da 213M rilasciato senza alcun annuncio

MiniCPM-V-4.7-1B-DSpark è un checkpoint da 213.547.777 parametri che non è in grado di rispondere a una domanda. Non legge immagini, non sostiene una conversazione e, se utilizzato da solo, non produce nulla che valga la pena leggere. Il suo unico compito è stare davanti a un modello — MiniCPM-V-4.7-1B — e indovinare i successivi quindici token, in modo che un piccolo modello visione-linguaggio di classe smartphone possa verificarne un blocco in un singolo passaggio in avanti invece di generarli uno alla volta.

Il file è di 0,85 GB con licenza Apache-2.0 ed è apparso su Hugging Face alle 04:26 UTC dell'8 ottobre 2026, nello stesso batch della bozza per il modello gemello più grande 35B-A3B. Quattro giorni dopo, la scheda principale lo tratta ancora come una nota a piè di pagina: la bozza compare una sola volta, come riga nella tabella dei pesi e dietro un toggle compresso «Speculative decoding (DSpark)». Non esiste alcun post sul blog di OpenBMB al riguardo, né un report tecnico, né una voce nella documentazione GitHub del progetto stesso.

Quel silenzio è la parte interessante, per ciò che questo particolare file rende possibile. È il primo artefatto della famiglia MiniCPM-V 4.7 la cui affermazione centrale — che un modello vision da 1B funziona in modo accettabile su un telefono — può essere verificata da qualcuno al di fuori di OpenBMB. Tutto ciò che segue tiene separati due gruppi: ciò che è un file su disco che puoi aprire, e ciò che è un numero che il fornitore ha stampato accanto ad esso.

Cosa c'è effettivamente nel repository

Quattro file. Questo è tutto quanto: .gitattributes, README.md, config.json, e un singolo model.safetensors che contiene 854.204.052 byte di pesi BF16. Nel repository non c'è alcun tokenizer, perché non ce n'è bisogno — la draft prende in prestito quello del target, e il vocabolario nella sua configurazione è esattamente quello del parent, con 248.094 token. Un drafter i cui token non si mappano uno a uno su quelli del target non può proporre nulla che il target accetterebbe, quindi condividere il vocabolario è un requisito, non una comodità.

Hub API registra il repository come creato il 2026-10-08T04:26:19Z e modificato l'ultima volta il 2026-10-12T14:29:57Z, con tag per inglese e cinese, licenza Apache-2.0, con tre like e un download al momento in cui scrivo. L'ultimo numero è quello da tenere a mente. Un download, dopo quattro giorni, su un file abbastanza piccolo da poter essere scaricato con una connessione telefonica.

Il campo architecture legge Qwen3DSparkModel con un model_type di qwen3, il che è coerente anziché strano: la backbone linguistica di MiniCPM-V 4.7 discende dalla linea Qwen3, quindi uno stub a cinque livelli tagliato dalla stessa famiglia è ciò che ci si aspetterebbe. Ciò che non è una copia più piccola del genitore è come lo stub comunica con esso. La configurazione predispone un dflash_config con projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" e markov_rank: 256. Quella confidence head è la parte ripresa dal metodo DSpark: è il meccanismo per stimare quanto di un blocco proposto vale la pena verificare, che è proprio il motivo per cui la configurazione di serving espone un interruttore per disattivare la verifica adattiva.

La specifica, e perché ogni numero è presente

Lato bozza, dalla scheda e dalla configurazione, che concordano entrambi:

• Parametri della bozza — 213.547.777, tutti BF16, in un checkpoint in un singolo file da 0,85 GB

• Profondità della bozza — 5 livelli, tutti con full attention, dimensione nascosta 1.024, dimensione intermedia 3.584, attivazione SiLU

• Geometria dell'attenzione — 8 teste di query contro 2 teste chiave/valore, dimensione della testa 256, attenzione grouped-query

• Token per forward pass — 15, indicati nella configurazione come block_size: 15

• Intervallo di posizione — RoPE theta 10.000.000 con un embedding rotatorio a 256 dimensioni, e max_position_embeddings impostato a 262.144, in linea con la finestra da 256K del modello padre

• Livelli tap — [3, 7, 11, 15, 19], sui 24 del genitore (num_target_layers: 24)

• Vocabolario — 248.094, legato al tokenizer del target, con un token di mascheramento dedicato a 248.076 per il passo di drafting semi-autoregressivo

Due di quelle righe meritano più di un'occhiata. La prima sono i layer di tap. La bozza non legge il layer finale del parent; legge gli hidden state da cinque layer sparsi nella profondità del parent e li proietta attraverso un dspark projector. Gli stati a metà rete sono più economici da allineare e portano ancora informazioni che l'ultimo layer ha già compresso nei logit del token successivo. La seconda è la dimensione della head di 256 rispetto a una hidden size di 1.024. Si tratta di una head volutamente ampia su un modello stretto, e la config attiva tie_word_embeddings: false — la matrice di embedding è mantenuta separata invece che condivisa con la proiezione di output, quindi il conteggio dei parametri le include entrambe.

Il succo è un drafter grande all'incirca un quinto della dimensione del target, in una forma del tutto diversa. Per confronto, la bozza del gemello 35B-A3B è di 389.223.169 parametri che attingono ai layer [3, 11, 19, 27, 35] di 40. Due bozze, una per target, perché una bozza è valida solo per il vocabolario e la rappresentazione intermedia su cui è stata addestrata.

La tabella di accettazione è una scheda del modello, non una misurazione

Ecco tutti i dati numerici pubblicati da OpenBMB sulle prestazioni di questa coppia, espressi in token accettati per passo di verifica, misurati con terminazione EOS naturale e max_new_tokens=8192:

• Vision, MMMU — 3,452 token accettati per passo

• Vision, MathVista — 4.333

• Vision, ragionamento CharXiv (validazione) — 4.452

• Visione, OCRBench — 4.752

• Testo, matematica — 5.891

• Testo, codice — 5.347

• Testo, generale — 3.370

La forbice va da 5,891 a 3,370, un fattore di circa 1,75 tra la categoria più facile e quella più difficile. Quell'ordine non sorprende, e in un certo senso dice qualcosa sui numeri: la matematica è la superficie più regolare che un modello linguistico produca, il testo generico è la meno regolare, e il tasso di successo di un drafter segue la prevedibilità dell'output del target più che la qualità di quest'ultimo.

Tre avvertenze dovrebbero figurare su quella tabella, e la scheda non ne riporta spontaneamente nessuna.

È autodichiarato, e c'è esattamente un download relativo al repository. Nessuno al di fuori di OpenBMB ha prodotto un numero di accettazione per questo checkpoint che chiunque altro possa consultare. Le cifre sono del fornitore, misurate nell'harness del fornitore, sul set di attività del fornitore.

La lunghezza di accettazione è una proprietà della coppia, non del modello. Un target che si ripete offre al suo drafter una facile vittoria, quindi un numero più alto qui non è prova che MiniCPM-V 4.7-1B sia bravo in qualcosa. È una prova di quanto sia prevedibile il suo output, che è una domanda diversa con una risposta diversa.

E non è un'accelerazione. Un drafter che propone 15 token e ne vede verificati 3,4 continua comunque a far avanzare diversi token per ogni forward pass del target, ma verificare un blocco di 15 token costa più che generare un singolo token, e ogni proposta rifiutata viene pagata e poi scartata. Convertire una lunghezza di accettazione in un valore di tempo effettivo richiede il costo di verifica, la dimensione del batch e l'hardware, nessuno dei quali è fornito dalla scheda. L'unica ricetta di serving che invece fornisce imposta --max-num-seqs 1, che è una configurazione tarata per funzionare piuttosto che per essere veloce.

Confrontata con la sua controparte, la tabella diventa più utile. Il modello draft 35B-A3B registra 7,387 su code e 5,098 su MMMU; questo modello draft da 1B registra 5,347 e 3,452. Modelli target più piccoli con modelli draft più piccoli accettano un numero nettamente inferiore di token per passo, che è il tipo di dettaglio tra famiglie che una singola scheda non può mostrare e che due schede possono.

Formazione, e il dettaglio che spiega l'intero design

La ricetta è lunga quattro righe: due milioni di sequenze di addestramento, sei epoche, AdamW e un obiettivo combinato di entropia incrociata, un termine L1 e una perdita di confidenza. La riga che conta è quella su da dove provenivano i dati di addestramento — le risposte sono state generate da MiniCPM-V-4.7-1B stesso, da un mix di prompt visivi e testuali.

Questa è auto-distillazione, e stabilisce il limite inferiore di quanto costa costruire un drafter come questo. Non puoi addestrarne uno senza prima eseguire il modello target su larga scala, in entrambe le modalità, il che significa che l'artefatto da 0,85 GB che puoi scaricare è il residuo a basso costo di un processo costoso. Spiega anche perché il drafter è abbinato uno a uno anziché condiviso: il comportamento che sta imitando è il comportamento di questo modello, e gli output di un target diverso addestrerebbero un drafter diverso.

Il paper del metodo stesso, arXiv 2607.05147, non è di OpenBMB. È un paper con 33 autori, inviato il 6 luglio 2026, che descrive DSpark come un framework di speculative decoding che abbina una backbone parallela a un modulo sequenziale leggero e pianifica la lunghezza di verifica in base alle probabilità stimate di sopravvivenza del prefisso. Riporta l'implementazione all'interno di un sistema di serving DeepSeek-V4, adotta una baseline di produzione chiamata MTP-1 e sostiene che la generazione per utente è dal 60 all'85 per cento più veloce a parità di throughput. Quelle affermazioni appartengono al paper e a quell'implementazione. Nulla di pubblicato le collega a un draft a cinque livelli, da 213M, su un modello di visione da 1B, e la tabella di accettazione sopra è l'unico ponte che qualcuno abbia offerto.

Perché questo file conta più di quanto la sua dimensione suggerisca

L'affermazione di punta della famiglia MiniCPM-V 4.7 riguarda l'elaborazione on-device. La scheda del modello 1B include un grafico prestazioni/tempo di inferenza, un grafico delle prestazioni complessive per la build instruct da 1B, una registrazione dello schermo non modificata catturata su un iPhone 17 Pro Max e una frase qualitativa che afferma che la variante 1B supera sostanzialmente Qwen3.5 0.8B sia nel punteggio complessivo sia nell'efficienza di inferenza. Elenca inoltre una famiglia di quantizzazione — int4, AWQ, GPTQ, GGUF, più il supporto FP8 — e target hardware day-0 che spaziano tra iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD e Arm.

Ognuno di questi è un'affermazione di un fornitore senza alcun numero esterno allegato, e uno di essi è internamente disordinato: il testo della scheda lo chiama modello 1B mentre la barra laterale dell'Hub riporta una dimensione del modello di 2B parametri. Il checkpoint DSpark è di natura diversa da tutto ciò. È 0,85 GB, Apache-2.0, e viene fornito con un comando di serving — il che significa che un soggetto esterno con una GPU consumer può eseguirlo questa settimana e produrre la prima cifra misurata esternamente della famiglia. Non un punteggio di benchmark, ma qualcosa di quasi altrettanto utile: una lunghezza di accettazione riprodotta.

Se qualcuno replica 3,45 su MMMU e 3,37 su testo generico, la scheda è credibile e il discorso on-device ha il suo primo punto dati esterno. Se l'accettazione risulta sostanzialmente inferiore, la tabella è stata misurata in condizioni che la ricetta pubblicata non riproduce, e il grafico prestazioni/tempo di inferenza eredita quel dubbio. Qualunque dei due risultati vale più di un altro grafico di fornitore, e questa è l'unica parte della famiglia in cui ottenerne uno costa poco.

Eseguirlo, e quanto costa provare

La card fornisce una sola ricetta ed è un'invocazione di vllm serve, non un gesto vago. Carica il target openbmb/MiniCPM-V-4.7-1B, lo serve con il nome MiniCPM-V-4.7-1B, imposta --max-model-len 40960 e --max-num-batched-tokens 40960, fissa --attention-backend FLASH_ATTN e --mm-encoder-attn-backend FLASH_ATTN, passa un kwarg del processore multimodale {"downsample_mode": "4x"}, considera affidabili i kwargs multimodali per richiesta e punta una configurazione speculativa al checkpoint DSpark con "method": "dspark", "num_speculative_tokens": 15 e la verifica adattiva disattivata. I kwargs predefiniti del chat-template lasciano il thinking disabilitato.

Due dettagli in quella riga meritano di essere letti due volte. --max-num-seqs 1 significa che la configurazione pubblicata serve una sequenza alla volta, quindi la ricetta descrive una configurazione di latenza a stream singolo, non una configurazione di throughput. E la modalità di downsampling visivo 4x è la più economica delle due pubblicizzate dalla card principale — la stessa card offre uno schema misto 4x/16x che baratta il dettaglio con la velocità, e la ricetta sceglie il lato di questo compromesso che favorisce la velocità.

Il quadro hardware è l'opposto del marketing della famiglia. Il target 1B è di circa 2 GB in BF16 più una KV cache, e il draft aggiunge 0,85 GB in più, quindi questo è un lavoro per singola GPU — scheda consumer, o una workstation con memoria unificata sufficiente — piuttosto che un lavoro per smartphone. Il percorso on-device nella documentazione del parent passa attraverso build quantizzate e framework che non sono in questa ricetta, e il checkpoint DSpark come pubblicato è un artefatto BF16 lato server.

Questo lascia un divario che la maggior parte dei team incontrerà: la versione interessante di MiniCPM-V 4.7-1B è quella on-device, e la versione che puoi eseguire oggi senza possedere la toolchain del telefono è quella lato server. Se ciò di cui hai effettivamente bisogno è un'inferenza multimodale di piccole dimensioni adesso, l'equivalente ospitato più vicino è un modello diverso — Qwen3 VL 8B Instruct è su OrcaRouter a $0,18 per milione di token in input e $0,70 per milione in output, con una finestra di contesto di 128K e input testuali, immagini e video, nessun peso locale e nessuna ricetta di serving da mantenere funzionante. MiniCPM-V 4.7 non è un modello ospitato su OrcaRouter e questo articolo non fingerà il contrario; la formulazione onesta è che si tratta di due modi per svolgere un unico compito, e solo uno dei due è misurabile dal catalogo questo pomeriggio.

È nel caso dei modelli non ancora dimostrati che qualcosa come DSpark si guadagna il suo posto, e quella è una questione di routing più che di modello. Un drafter che nessuno ha riprodotto è esattamente il tipo di componente che vuoi dietro un endpoint da cui puoi fare fallback. Eseguire oltre 200 modelli dietro un'unica chiave, con i prezzi di listino dei provider passati con markup 0%, con failover automatico quando una route si degrada, significa che un esperimento di serving andato storto ti costa un nuovo tentativo invece di un'interruzione del servizio — e poiché nulla è maggiorato, una variazione di prezzo del fornitore su qualsiasi modello del catalogo è attiva lo stesso giorno invece che al ciclo di fatturazione successivo.

Cosa renderebbe questo verificabile?

Mancano tre cose, e solo una di esse richiede OpenBMB.

Il fornitore non ha annunciato nulla. Il repository ha una model card, una licenza e una ricetta di addestramento, ma nessun post sul blog, nessun report tecnico e nessuna riga nella documentazione GitHub del progetto — che, alla prima settimana della famiglia, descriveva ancora la generazione precedente come quella attuale. Quattro giorni dopo l'arrivo del checkpoint, la card del modello genitore 1B lo collega come riga di tabella e nulla più.

Nessuno ha riprodotto i dati di accettazione, e il numero di download è uno. È il divario più economico da colmare e quello che conta di più, perché è l'unico punto in cui una misurazione esterna potrebbe spostare davvero la storia della famiglia.

E la questione della qualità è del tutto non affrontata. Non esiste alcun punteggio MMMU, alcun risultato OCRBench, alcun dato di comprensione dei documenti e alcun valore di grounding per MiniCPM-V 4.7-1B da nessuna parte nel rilascio — la tabella di accettazione è una tabella relativa alla decodifica, e leggere una lunghezza di accettazione elevata come segnale di qualità è esattamente l'errore che quei numeri invitano a commettere.

Quindi: un artefatto reale, una licenza permissiva, un comando di serving che funziona e una prova davvero nuova su un modello che non ne aveva alcuna. Il prossimo file che vale la pena aggiornare è ancora la model card del modello genitore.