MiniCPM-V 4.7-35B-A3B-DSpark: OpenBMB:s 389M-draftmodell landar med ett modellkort som dess basmodell aldrig fick

MiniCPM-V-4.7-35B-A3B-DSpark är en draftmodell med 389 223 169 parametrar. Den svarar inte på frågor, den ser inte bilder, och på egen hand är den oanvändbar. Dess enda uppgift är att gissa de kommande femton tokens så att MiniCPM-V-4.7-35B-A3B kan verifiera ett helt block i en enda framåtpassning i stället för att generera en token i taget. Det är spekulativ avkodning, och OpenBMB släppte för elva dagar sedan en draft för sin nya 35B vision-språkmodell utan att säga ett ord om det offentligt.

Det som gör den värd en artikel är inte draftmodellen. Det är pappersarbetet som följde med den. DSpark-checkpointen har ett modellkort: en licens, en specifikationstabell, ett träningsrecept och en tabell över acceptanslängder för sju uppgiftskategorier. Dess 35 miljarder parametrar stora föräldramodell hade inget av det när den dök upp. Så för första gången finns det faktiska siffror kopplade till ett släpp av MiniCPM-V 4.7 – och det är siffror om föräldramodellen, uppmätta indirekt, av en fil på 0,78 GB vars angivna syfte är att göra den snabbare.

Allt nedan skiljer mellan vad som står på kortet och vad kortet inte fastställer. Acceptanssiffrorna är OpenBMB:s egna och ingen utanför labbet har reproducerat dem. Basmodellens benchmarktabell finns fortfarande inte.

Vad DSpark-checkpointen egentligen är

Repositoriet openbmb/MiniCPM-V-4.7-35B-A3B-DSpark dateras till den 8 oktober 2026. Det är en kontrollpunkt i en enda fil – model.safetensors, plus en config.json och en README – under Apache-2.0, taggad för engelska och kinesiska. Ett andra utkast, openbmb/MiniCPM-V-4.7-1B-DSpark, skapades en sekund tidigare, så de två pushades till hubben i samma batch snarare än att upptäckas en i taget.

Varje draftmodell sitter framför en målmodell och endast den målmodellen. Kortet säger det rakt ut: denna checkpoint är "tränad för exakt parkoppling med MiniCPM-V-4.7-35B-A3B och dess tokenizer." Vokabulären är föräldramodellens, alla 248 144 tokens av den, vilket är ett krav snarare än en optimering — en draftmodell vars tokens inte mappar ett-till-ett mot målmodellens kan inte föreslå något som målmodellen skulle kunna acceptera. Samma begränsning är anledningen till att syskon-draftmodellen existerar separat i stället för att en enda draftmodell betjänar familjen.

Arkitekturen är inte en mindre kopia av föräldramodellen. Den är en femlagers attentionstack, 2 048 i dold bredd, 8 query-huvuden mot 2 key/value-huvuden, en intermediär storlek på 6 144 och RoPE med en theta på 10 000 000. Fältet architectures visar Qwen3DSparkModel — samma Qwen3-familjens backbone som föräldramodellens språkstack kommer från, nedskuren till en stubbe.

Det intressanta är hur stubben talar med målet. Den läser inte målets sista lager. Den plockar upp dolda tillstånd från fem mellanlager – [3, 11, 19, 27, 35] av förälderns 40 – och projicerar dem genom en projektor av dspark-typ. Att hämta från mitten av stacken i stället för slutet är avsiktligt: tillstånd i mitten av nätverket är billigare att anpassa till och bär information som det sista lagret redan har komprimerat till logits för nästa token. Konfigurationen förser också ett konfidenshuvud med en Markov-komponent av rang 256, vilket är maskineriet från DSpark-artikeln för att avgöra hur mycket av ett föreslaget block som är värt att verifiera.

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

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

• Vision, MMMU — 5,098 accepterade tokens per steg.

• Vision, MathVista — 6,126.

• Syn, CharXiv-resonemang (validering) — 5.479.

• Vision, OCRBench — 5.407.

• Text, matematik — 6 687.

• Text, kod — 7 387.

• Text, Allmänt — 3.501.

Tre saker om den tabellen är värda att säga högt. För det första är den självrapporterad. Ingen utanför OpenBMB har kört denna checkpoint och publicerat en siffra, och med en nedladdning registrerad i repot har ingen utanför OpenBMB kört den överhuvudtaget. För det andra är acceptanslängden en egenskap hos paret, inte hos modellen – den mäter hur förutsägbar MiniCPM-V-4.7-35B-A3B:s utdata är, inte hur bra den utdatan är. En målmodell som upprepar sig ger en draftmodell en enkel vinst. För det tredje är spridningen själva poängen: 7,387 på kod mot 3,501 på allmän text är en faktor två mellan den bästa och sämsta kategorin, och att kod är enklast speglar kodens lågentropiska, starkt repetitiva yta mer än någon styrka hos modellerna.

Det finns också en rent aritmetisk tolkning som kortet lämnar implicit. En drafter som föreslår 15 tokens och får 5 till 7 accepterade flyttar fortfarande flera tokens per framåtpass för målet, så taket här är en stor genomströmningsvinst – men det är inte det naiva "5× snabbare"-påståendet, eftersom att verifiera ett block med 15 tokens kostar mer än att generera en token, och de avvisade förslagen betalas för och kastas bort. Det gapet är precis vad DSpark-artikeln handlar om, och det är därför konfigurationen exponerar en växel för att stänga av adaptiv verifiering.

Vad utkastet oavsiktligt säger oss om basmodellen

MiniCPM-V 4.7 betecknade sin utgivning som tyst släppt – vikter, inget lanseringsinlägg. Det har nu förändrats, på ett litet men verkligt sätt. Föräldrarepot på openbmb/MiniCPM-V-4.7-35B-A3B skapades den 7 oktober 2026. Den 12 oktober hade det ett fullständigt modellkort med en README, en releasesida i Hugging Face-stil, en lista med påståenden, ett avsnitt om körning på enhet och en vikttabell. Repot har sedan dess fått en kvantiseringsfamilj – FP8-, int4-, AWQ-, GPTQ- och GGUF-byggen, var och en i sitt eget repo, alla uppdaterade i oktober – och 27 gillningar mot 166 nedladdningar.

Så den korrekta bilden är en tvåstegslansering, inte en tyst sådan. Vikterna landade den 6 och 7 oktober. Utkast-checkpoints följde den 8 oktober. Dokumentationen, kvantiseringarna och berättelsen om körning på enheten kom den 12 oktober. OpenBMB har fortfarande inte publicerat ett blogginlägg eller en teknisk rapport för familjen, och det finns fortfarande ingen benchmarktabell på modellkortet för föräldramodellen — prestandapåståendena ligger inuti länkade diagrambilder i stället för som text som en läsare kan citera.

Det påstående som faktiskt förekommer i texten är huvudpåståendet: med Lookahead Expert Scheduling, lagervis kvantisering och "DSpark-integration för spekulativ sampling" beskrivs 35B-A3B-modellen som den första MoE-modellen med öppen källkod som körs smidigt på enheten, med 13+ tokens per sekund på en iPhone 17 Pro Max. Den siffran är leverantörsrapporterad, inte reproducerad och utan närmare precisering – inget kvantiseringsformat, ingen build, ingen prompt, ingen mätmetod. DSpark-checkpointen är en av de tre tekniker som påståendet vilar på, vilket gör den till den enda av de tre som du kan ladda ner och granska. Det är också den vars bevis utgörs av en enda oläst benchmark-rad per uppgift.

Kör det, om du vill.

Kortet innehåller ett recept, och det är ett vLLM-kommando, inte en handviftning. Det betjänar målet vid tensor-parallell storlek 2 med en maximal modellängd på 40 960, FLASH_ATTN på både språk- och multimodalencoderns attention-backends, ett visuellt nedsamplingsläge på 4x, enable_thinking satt till false, och den spekulativa konfigurationen riktad mot DSpark-checkpointen med 15 spekulativa token och adaptiv verifiering avstängd. Två detaljer i den raden är värda att lägga märke till i sig: --max-num-seqs 1 betyder att den publicerade konfigurationen betjänar en sekvens i taget, och --disable-custom-all-reduce med all-reduce-fusionspasset avstängt betyder att detta är en konfiguration som har trimmats för att fungera snarare än för att vara maximalt snabb. Betrakta receptet som en startpunkt som OpenBMB fick att köra, inte som ett påstående om genomströmning.

Hårdvaruramen är det verkliga hindret. Målet är ungefär 70 GB BF16-vikter före KV-cache, och draften lägger till ungefär 0,78 GB ovanpå. Två acceleratorer är det angivna minimumet, vilket placerar detta långt utanför den telefon som familjens marknadsföring lutar sig mot — en distribution på enheten för en 35B-A3B-modell innebär aggressiv kvantisering och offloading, vilket är vad arbetet med LES och lagervis kvantisering är till för, och inget av dem finns i vLLM-receptet ovan.

Den asymmetrin är det praktiska beslutet för de flesta team. Att servera MiniCPM-V 4.7 kräver två GPU:er som du äger; att anropa en jämförbar hostad multimodal MoE kostar inget i förskott. Qwen3.6 35B A3B är den närmaste direkta jämförelsen — samma 35B-totala, 3B-aktiva form, samma 262K-kontext, bild- och videoinmatning — och den serveras via OrcaRouter från $0,248 per miljon indatatoken och $1,485 per miljon utdatatoken beroende på leverantörsvägen, med automatisk failover om en av dessa vägar försämras. MiniCPM-V 4.7 är inte en hostad modell på OrcaRouter och den här artikeln kommer inte att låtsas något annat; den ärliga formuleringen är att de två är alternativ vid en beslutspunkt, och den hostade är den du kan mäta i eftermiddag.

Vad skulle göra detta kontrollerbart?

DSpark-checkpointen är Apache-2.0, den är under en gigabyte och den levereras med ett serveringskommando som någon med två GPU:er skulle kunna klistra in i en terminal redan idag. Den kombinationen gör den till den billigaste vägen till en oberoende siffra på MiniCPM-V 4.7 – inte en benchmarkpoäng, utan något nästan lika användbart: en reproducerad acceptanslängd. Om en utomstående part matchar 5,1 på MMMU och 3,5 på allmän text är kortet trovärdigt och familjens effektivitetshistoria får sin första externa datapunkt. Om acceptansen blir väsentligt lägre mättes den publicerade tabellen under förhållanden som receptet inte reproducerar, och påståendet om 13 tokens per sekund ärver det tvivlet.

Det som fortfarande saknas är det som ett modellkort normalt är till för. Det finns inget MMMU-poäng, inget OCRBench-poäng, inget resultat för dokumentförståelse, ingen grounding-siffra och ingen latenssiffra för MiniCPM-V 4.7 självt – inget som svarar på om den här modellen är bra. Draftmodellens tabell kan inte ersätta det, och att läsa en hög acceptanslängd som en kvalitetssignal är precis det misstag som siffrorna inbjuder till. En ChatGPT-formad prediktion är lätt för en draftmodell och säger ingenting om huruvida prediktionen var korrekt.

Så: en riktig artefakt, en riktig licens, ett genuint nytt publicerat belägg om en modell som inte hade något – och ett utvärderingsgap som är precis lika brett som det var den 7 oktober. Nästa fil att uppdatera är fortfarande förälderns modellkort.