MiniCPM-V-4.7-1B-DSpark: En draftmodell på 213M som släppts utan tillkännagivande

MiniCPM-V-4.7-1B-DSpark är en checkpoint med 213 547 777 parametrar som inte kan svara på en fråga. Den läser inte bilder, den för inte en konversation, och när den används på egen hand producerar den inget som är värt att läsa. Dess enda uppgift är att sitta framför en modell — MiniCPM-V-4.7-1B — och gissa de nästa femton token så att en liten vision-språkmodell i telefonklass kan verifiera ett block av dem i en enda framåtpassning i stället för att generera dem en i taget.

Filen är 0,85 GB under Apache-2.0 och dök upp på Hugging Face kl. 04:26 UTC den 8 oktober 2026, i samma batch som draftmodellen för det större syskonet 35B-A3B. Fyra dagar senare behandlar föräldramodellkortet det fortfarande som en fotnot: draftmodellen visas en gång, som en rad i vikttabellen och bakom en ihopfälld växlingsknapp för "Spekulativ avkodning (DSpark)". Det finns inget blogginlägg från OpenBMB om den, ingen teknisk rapport och ingen post i projektets egen GitHub-dokumentation.

Den tystnaden är det intressanta, för vad just den här filen gör möjligt. Det är den första artefakten i MiniCPM-V 4.7-familjen vars centrala påstående – att en 1B-visionsmodell fungerar acceptabelt i en telefon – kan kontrolleras av någon utanför OpenBMB. Allt nedan håller två högar åtskilda: vad som är en fil på disken som du kan öppna, och vad som är ett nummer som leverantören tryckte bredvid den.

Vad finns egentligen i arkivet?

Fyra filer. Det är allt: .gitattributes, README.md, config.json, och en enda model.safetensors som innehåller 854 204 052 byte BF16-vikter. Det finns ingen tokenizer i repot, eftersom det inte behöver finnas någon – utkastmodellen lånar målmodellens, och vokabulären i dess konfiguration är exakt förälderns 248 094 token. En utkastmodell vars tokens inte mappar ett-till-ett mot målmodellens kan inte föreslå något som målmodellen skulle acceptera, så att dela vokabulär är ett krav snarare än en bekvämlighet.

Hub-API:et anger att repositoryt skapades 2026-10-08T04:26:19Z och senast ändrades 2026-10-12T14:29:57Z, taggat för engelska och kinesiska, licensierat under Apache-2.0, med tre gillningar och en nedladdning när detta skrivs. Det sista numret är det man ska hålla fast vid. En nedladdning, fyra dagar in, på en fil som är så pass liten att den kan hämtas över en telefonuppkoppling.

Arkitekturfältet anger Qwen3DSparkModel med en model_type på qwen3, vilket är logiskt snarare än märkligt: MiniCPM-V 4.7:s språkryggrad härstammar från Qwen3-linjen, så en femlagersstubbe skuren från samma familj är vad man skulle förvänta sig. Det som inte är en mindre kopia av föräldern är hur stubben kommunicerar med den. Konfigurationen bestyckar en dflash_config med projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" och markov_rank: 256. Det konfidenshuvudet är den del som hämtats från DSpark-metoden: det är maskineriet för att uppskatta hur mycket av ett föreslaget block som är värt att verifiera, vilket är hela anledningen till att serveringskonfigurationen exponerar en växel för att stänga av adaptiv verifiering.

Specifikationen, och varför varje nummer finns där

På Draft-sidan, utifrån kortet och konfigurationen, vilka båda stämmer överens:

• Draft-parametrar — 213 547 777, alla BF16, i en checkpoint i en enda fil på 0,85 GB

• Draftdjup — 5 lager, alla med full attention, dold storlek 1 024, mellanstorlek 3 584, SiLU-aktivering

• Attention-geometri — 8 query-huvuden mot 2 key/value-huvuden, dimension per huvud 256, grupperad query-attention

• Tokens per framåtpass — 15, anges i konfigurationen som block_size: 15

• Positionsintervall — RoPE theta 10 000 000 med en 256-dimensionell roterande inbäddning, och max_position_embeddings satt till 262 144, vilket matchar förälderns 256K-fönster

• Lager som tryckts — [3, 7, 11, 15, 19], av förälderns 24 (num_target_layers: 24)

• Vokabulär — 248 094, knutet till målmodellens tokeniserare, med en dedikerad masktoken vid 248 076 för det halvautoregressiva utkaststeget

Två av dessa rader förtjänar mer än en flyktig blick. Den första är tap-lagren. Draftmodellen läser inte förälderns sista lager; den läser dolda tillstånd från fem lager utspridda genom förälderns djup och projicerar dem genom en dspark-projektor. Tillstånd i mitten av nätverket är billigare att aligna mot och bär fortfarande information som det sista lagret redan har kollapsat till logits för nästa token. Den andra är huvuddimensionen på 256 mot en dold storlek på 1 024. Det är ett avsiktligt brett huvud i en smal modell, och konfigurationen växlar tie_word_embeddings: false — embeddingsmatrisen hålls separat i stället för att delas med utprojektionen, så parameterantalet inkluderar båda.

Sammantaget är det en draftmodell på ungefär en femtedel av målmodellens storlek, i en helt annan form. Som jämförelse har 35B-A3B-syskonets draftmodell 389 223 169 parametrar och använder lager [3, 11, 19, 27, 35] av 40. Två draftmodeller, en per målmodell, eftersom en draftmodell bara är giltig för den vokabulär och mellanliggande representation som den tränades mot.

Acceptanstabellen är ett modellkort, inte en mätning.

Här är allt numeriskt som OpenBMB publicerade om hur väl detta par presterar, uttryckt som accepterade tokens per verifieringssteg, mätt med naturlig EOS-avslutning och max_new_tokens=8192:

• Vision, MMMU — 3,452 accepterade tokens per steg

• Vision, MathVista — 4.333

• Vision, CharXiv-resonemang (validering) — 4,452

• Vision, OCRBench — 4.752

• Text, matematik — 5.891

• Text, kod — 5 347

• Text, allmän — 3.370

Spridningen sträcker sig från 5,891 ned till 3,370, en faktor på omkring 1,75 mellan den lättaste kategorin och den svåraste. Den ordningen är inte förvånande på ett sätt som säger något om siffrorna: matematik är den mest regelbundna yta en språkmodell producerar, allmän text den minst regelbundna, och en drafters framgångsfrekvens följer förutsägbarheten i målets utdata snarare än dess kvalitet.

Tre förbehåll hör hemma i den tabellen, och kortet tar inte självmant upp något av dem.

Det är självrapporterat, och det finns exakt en nedladdning för repositoriet. Ingen utanför OpenBMB har tagit fram ett acceptansnummer för den här checkpointen som någon annan kan titta på. Siffrorna är leverantörens, uppmätta i leverantörens testramverk, på leverantörens uppgiftsuppsättning.

Acceptanslängd är en egenskap hos paret, inte hos modellen. En målmodell som upprepar sig själv ger sin utkastmodell en enkel vinst, så ett högre tal här är inte bevis för att MiniCPM-V 4.7-1B är bra på något. Det är bevis för hur förutsägbar dess utdata är, vilket är en annan fråga med ett annat svar.

Och det är ingen snabbhetsvinst. En drafter som föreslår 15 tokens och får 3,4 av dem verifierade flyttar fortfarande fram flera tokens per framåtpassning i målmodellen, men att verifiera ett block på 15 tokens kostar mer än att generera en token, och varje avvisat förslag betalas för och kastas. Att omvandla en acceptanslängd till ett värde i väggklockstid kräver verifieringskostnaden, batchstorleken och hårdvaran, och kortet uppger inget av detta. Det enda serveringsrecept som det faktiskt tillhandahåller ställer in --max-num-seqs 1, vilket är en konfiguration trimmad för att fungera snarare än en trimmad för att vara snabb.

Jämförd med syskonet blir tabellen mer användbar. 35B-A3B-utkastmodellen får 7,387 på kod och 5,098 på MMMU; denna 1B-utkastmodell får 5,347 och 3,452. Mindre mål med mindre utkastmodeller accepterar markant färre tokens per steg, vilket är en sådan familjeöverskridande detalj som ett enda kort inte kan visa men två kort kan.

Träning, och detaljen som förklarar hela designen

Receptet består av fyra rader: två miljoner träningssekvenser, sex epoker, AdamW och ett kombinerat mål av korsentropi, en L1-term och en konfidensförlust. Raden som spelar roll är den om varifrån träningsdatan kom — svaren genererades av MiniCPM-V-4.7-1B själv, från en blandning av bild- och textprompter.

Det är självdistillation, och det sätter golvet för vad en utkastmodell som denna kostar att bygga. Man kan inte träna en sådan utan att först köra målmodellen i stor skala, över båda modaliteterna, vilket innebär att den 0,85 GB stora artefakten du kan ladda ner är den billiga restprodukten av en dyr process. Det förklarar också varför utkastmodellen paras ett-till-ett i stället för att delas: beteendet den imiterar är den här modellens beteende, och en annan målmodells utdata skulle träna en annan utkastmodell.

Metodens egen artikel, arXiv 2607.05147, är inte OpenBMB:s. Det är en artikel med 33 författare som skickades in den 6 juli 2026 och beskriver DSpark som ett ramverk för spekulativ avkodning som kombinerar en parallell stomme med en lättviktsmodul för sekventiell bearbetning och schemalägger verifieringslängden utifrån skattade prefixöverlevnadssannolikheter. Den rapporterar driftsättning i ett DeepSeek-V4-betjäningssystem, använder en produktionsbaslinje som kallas MTP-1 och hävdar 60 till 85 procent snabbare generering per användare vid matchad genomströmning. Dessa påståenden tillhör artikeln och den driftsättningen. Inget publicerat kopplar dem till ett femlagers 213M-utkast på en 1B-visionsmodell, och acceptanstabellen ovan är den enda brygga någon har erbjudit.

Varför den här filen har större betydelse än vad storleken antyder

Huvudpåståendet för MiniCPM-V 4.7-familjen gäller on-device. 1B-kortet levereras med ett diagram över prestanda kontra inferenstid, ett övergripande prestandadiagram för 1B instruct-bygget, en oredigerad skärminspelning som fångats på en iPhone 17 Pro Max och en kvalitativ mening som säger att 1B-varianten avsevärt överträffar Qwen3.5 0.8B både vad gäller övergripande poäng och inferenseffektivitet. Det listar också en kvantiseringsfamilj – int4, AWQ, GPTQ, GGUF, samt FP8-stöd – och hårdvarumål för dag 0 som omfattar iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD och Arm.

Vart och ett av dessa är ett leverantörspåstående utan någon extern siffra kopplad till sig, och ett av dem är internt stökigt: korttexten kallar det en 1B-modell medan Hub-sidofältet rapporterar en modellstorlek på 2B parametrar. DSpark-checkpointen är av ett annat slag än allt detta. Den är 0,85 GB, Apache-2.0, och den levereras med ett serveringskommando – vilket innebär att en utomstående part med ett konsumentgrafikkort kan köra den i veckan och ta fram familjens första externt uppmätta siffra. Inte en benchmarkpoäng, utan något nästan lika användbart: en reproducerad acceptanslängd.

Om någon matchar 3,45 på MMMU och 3,37 på allmän text är kortet trovärdigt och berättelsen om körning på enheten har sin första externa datapunkt. Om acceptansen blir betydligt lägre mättes tabellen under förhållanden som det publicerade receptet inte reproducerar, och diagrammet över prestanda per inferenstid ärver det tvivlet. Endera resultatet är värt mer än ännu ett leverantörsdiagram, och detta är den enda delen av familjen där det är billigt att få ett.

Att köra det, och vad det kostar att prova

Kortet levererar ett recept och det är ett vllm serve-anrop, inte en handviftning. Det laddar målet openbmb/MiniCPM-V-4.7-1B, serverar det under namnet MiniCPM-V-4.7-1B, ställer in --max-model-len 40960 och --max-num-batched-tokens 40960, låser --attention-backend FLASH_ATTN och --mm-encoder-attn-backend FLASH_ATTN, skickar en multimodal processor-kwarg med {"downsample_mode": "4x"}, litar på multimodala kwargs per begäran och pekar en spekulativ konfiguration mot DSpark-checkpointen med "method": "dspark", "num_speculative_tokens": 15 och adaptiv verifiering avstängd. Standard-kwargs för chattmallen lämnar tänkandet inaktiverat.

Två detaljer i den raden är värda att läsa två gånger. --max-num-seqs 1 betyder att den publicerade inställningen betjänar en sekvens i taget, så receptet beskriver en konfiguration för latens i en enda ström, inte en konfiguration för genomströmning. Och 4x visuellt nedsamplingsläge är det billigare av de två som föräldrakortet annonserar — samma kort erbjuder ett blandat 4x/16x-schema som offrar detaljer för hastighet, och receptet väljer den sida av det bytet som gynnar hastighet.

Hårdvaruenveloppet är raka motsatsen till familjens marknadsföring. 1B-målet är ungefär 2 GB i BF16 plus en KV-cache, och draftmodellen lägger till 0,85 GB ovanpå, så detta är ett jobb för en enda GPU – ett konsumentkort, eller en arbetsstation med tillräckligt med enhetligt minne – snarare än ett telefonjobb. Vägen för körning på enheten i föräldramodellens dokumentation går via kvantiserade byggen och ramverk som inte finns i detta recept, och DSpark-checkpointen i publicerat skick är en BF16-artefakt på serversidan.

Det lämnar ett gap som de flesta team kommer att stöta på: den intressanta versionen av MiniCPM-V 4.7-1B är den som körs på enheten, och den version du kan köra i dag utan att äga telefonens verktygskedja är en serverbaserad sådan. Om det du faktiskt behöver är liten multimodal inferens nu, är den närmaste hosting-baserade motsvarigheten en annan modell – Qwen3 VL 8B Instruct finns på OrcaRouter för 0,18 USD per miljon indatatoken och 0,70 USD per miljon utdatatoken, med ett kontextfönster på 128K och indata i form av text, bild och video, inga lokala vikter och inget serveringsrecept att hålla i gång. MiniCPM-V 4.7 är inte en hosting-baserad modell på OrcaRouter och den här artikeln tänker inte låtsas något annat; den ärliga formuleringen är att det här är två sätt att utföra ett och samma jobb, och bara ett av dem går att mäta utifrån katalogen i eftermiddag.

Där något som DSpark gör nytta är i fallet med obeprövade modeller, och det är en routingfråga snarare än en modellfråga. En drafter som ingen har reproducerat är precis den typ av komponent du vill ha bakom en slutpunkt som du kan falla tillbaka från. Att köra 200+ modeller bakom en enda nyckel, leverantörers listpriser som förs vidare med 0 % påslag, med automatisk failover när en rutt försämras, innebär att ett serving-experiment som går fel kostar dig ett nytt försök i stället för ett avbrott — och eftersom inget är påslaget blir en leverantörsprisändring på vilken modell som helst i katalogen aktiv samma dag i stället för vid nästa faktureringscykel.

Vad skulle göra detta kontrollerbart?

Tre saker saknas, och bara en av dem kräver OpenBMB.

Leverantören har inte tillkännagivit något. Repositoriet har ett modellkort, en licens och ett träningsrecept, men inget blogginlägg, ingen teknisk rapport och inte en rad i projektets GitHub-dokumentation – som under familjens första vecka fortfarande beskrev den föregående generationen som den nuvarande. Fyra dagar efter att checkpointen landade länkar förälderkortet för 1B till den som en tabellrad och inget mer.

Ingen har reproducerat acceptanssiffrorna, och antalet nedladdningar är ett. Det är det billigaste gapet att täppa igen och det som betyder mest, eftersom det är den enda platsen där en utomstående mätning på ett meningsfullt sätt skulle kunna förändra familjens berättelse.

Och kvalitetsfrågan är helt orörd. Det finns ingen MMMU-poäng, inget OCRBench-resultat, ingen siffra för dokumentförståelse och ingen grounding-siffra för MiniCPM-V 4.7-1B någonstans i släppet – acceptanstabellen är en tabell om avkodning, och att läsa en hög acceptanslängd som en kvalitetssignal är precis det misstag som dessa siffror inbjuder till.

Så: en riktig artefakt, en tillåtande licens, ett serveringskommando som fungerar och ett genuint nytt bevis om en modell som inte hade något. Nästa fil som är värd att uppdatera är fortfarande förälderns modellkort.