MiniCPM-V 4.7:s "3B aktiva parametrar" finns inte i modellkortet — jag mätte det utifrån vikterna

Den mest upprepade siffran om MiniCPM-V 4.7 35B-A3B finns inte tryckt någonstans i dess egen dokumentation. Påståendet – "endast 3B aktiva parametrar (!) – den körs till och med på en iPhone" – kommer från ett inlägg från tredje part den 13 oktober 2026, och leverantörens modellkort, förrådets README och lanseringsanteckningar anger överhuvudtaget ingen siffra för aktiva parametrar. Det är inte så mycket en kritik av påståendet som en lucka värd att täppa igen: checkpointen kodar sitt eget svar. Så, innan något annat här, hämtade jag safetensors-indexet och varje shard-header för openbmb/MiniCPM-V-4.7-35B-A3B och räknade. Som jämförelse är den andra modellen i samma inlägg – Qwen3.8-27B, släppt den 13 augusti 2026 – en dense 27B-modell och har ingen sådan tvetydighet att lösa: varje parameter är aktiv för varje token. Den intressanta frågan är om "3B aktiva" överlever kontakten med vikterna, och svaret är: den överlever, men bara om man definierar ordet "aktiv" på leverantörens sätt, och den ärliga siffran ligger närmare 4B när man räknar de delar man inte kan undvika att köra.

Liggaren, läst från själva kontrollpunkten

Indexfilen listar 40 språklager plus ett visionstorn och en projektor, 35 212 875 824 parametrar totalt i BF16 – 70,43 GB vikter att ladda ner. Det matchar "35B" i namnet. MoE-frågan är hur stor andel av det som berörs per token:

• Totalt lagrat — 35,21B parametrar, 70,43 GB i BF16. Varje expert ligger på disk oavsett om den används eller inte.

• Router-budget — 8 experter väljs per token, av 256, per MoE-lager. Konfigurerat i config.json som num_experts_per_tok: 8. Varje expert är liten: 3,15M parametrar.

• MoE-väg per lager — 8 experter (25,17M) + en delad expert (3,15M) + router-grinden (0,52M) ≈ 28,83M.

• Attention-väg per lager — arkitekturen är hybrid: 30 av de 40 lagren använder linjär attention (33,72M vardera), 10 använder full attention (27,26M vardera). Totalt ≈ 2,44B över alla 40 lager för attention plus MoE-aritmetik, upprepas per token.

• Plus det du inte kan hoppa över — token-inbäddningar 508,2 M, LM-huvud 508,2 M, visionstorn 522,3 M, projektor 30,7 M.

• De två försvarbara svaren – ~2,44B aktiva enbart på attention- och MoE-vägen; ~4,01B om man räknar med inbäddningar, utdatahuvud, visionstorn och projektor, vilket en visionsbegäran faktiskt aktiverar.

Så "3B active" är inte fel. Det är en avrundning av 2,44B uppåt, och det hamnar i gapet mellan de två siffrorna ovan. Det är bara inte en siffra som OpenBMB har publicerat, och det är inte samma sak som suffixet "A3B" — det suffixet är en del av modellens namn, och leverantörens egna material gör det aldrig till ett mätvärde.

Varför suffixet och numret inte är samma sak

Namnkonventioner i ekosystemet för öppna vikter antyder ett antal aktiva parametrar: en modell som heter 30B-A3B, eller 235B-A22B, talar om för dig att den aktiverar ungefär så många parametrar per token. Slutsatsen är vanligtvis tillförlitlig – men det är en konvention, inte ett kontrakt, och MiniCPM-V 4.7 är ett fall där inget i modellkortet, README-filen eller lanseringsinlägget omvandlar "A3B" till ett tal som du kan planera minnesanvändning utifrån. Tills någon räknar är suffixet en etikett.

Räkningen ovan är aritmetik, inte en slutledning från den beteckningen. Det är också anledningen till att siffrorna ~2,44B och ~4,01B skiljer sig: huruvida man räknar med inbäddningstabellen och utgångshuvudet är ett verkligt beslut, inte pedanteri. I en tät modell är inbäddningar en liten del av en budget på 27B. I en gles modell där beräkningsvägen per token bara är några miljarder parametrar är en inbäddningstabell på 508M och ett LM-huvud på 508M inte längre brus — tillsammans utgör de ungefär en femtedel av den aktiva vägen, och de lagras i full bredd medan experterna är kvantiserade.

En konsekvens som är värd att säga rakt ut: förhållandet mellan lagrade och aktiva parametrar här är ungefär 8,8 till 1 vid den snäva tolkningen. Det är hela anledningen till att en 35B-modell kan säljas in som en telefonmodell, och det är också anledningen till att den inte är det på det sätt som en tät 3B-modell är. Lagringsutrymmet krymper inte när routern ignorerar en expert.

Påståendet om iPhone är ett separat påstående med en separat bevisbas

Allt konkret om prestanda på enheten i den här utgåvan är tillverkarens egna uppgifter och har inte reproducerats. Den specifika siffran är 13+ tokens per sekund vid omkring 3 GB minne på en iPhone 17 Pro Max, med samma checkpoint demonstrerad på en iPad M4. OpenBMB tillskriver det tre tekniker som arbetar tillsammans – Lookahead Expert Scheduling, som förutser routning mellan lager och förhämtar experter, finmaskig lagervis kvantisering och DSpark spekulativ sampling – och beskriver resultatet som den första MoE-modellen med öppen källkod som körs smidigt på enheten utan att förlora kapacitet. Det finns ingen oberoende mätning av den genomströmningen i offentligt tillgängligt material, ingen reproduktion av tredje part och ingen publicerad redogörelse för vilken kvantisering siffran 3 GB förutsätter.

Detta spelar roll av en specifik anledning: 3 GB är talet som avgör om påståendet är intressant för dig, och det är det tal som vi vet minst om. En 35B-MoE vars expertvikter mestadels ligger på flashlagring är inte en 3 GB-modell, det är en modell vars residenta arbetsmängd råkar rymmas i 3 GB när routningsprediktioner, prefetch och en kvantiserad expertcache alla gör sitt jobb. Det är exakt de förhållanden under vilka benchmark-genomströmning och verklig genomströmning divergerar – den första prompten värmer cachen, och beteendet som ger dig 13 tokens per sekund i en demo är ett schema, inte en egenskap hos vikterna.

Betrakta de 13 tokens per sekund som ett påstående om en teknik, inte om checkpointen. Checkpointen är det du kan verifiera i dag: 35,21B lagrade, 8 av 256 experter routade per token, ~2,44B till ~4,01B aktiva beroende på vad man räknar, Apache-2.0, day-0-kvantiseringar i GGUF, AWQ, GPTQ, int4 och FP8, samt en leverantörslista över stödda chips som inkluderar Rockchip, Houmo, Intel, AMD och Arm.

Vad det aktiva antalet avgör och inte avgör

Ett antal aktiva parametrar är en beräkningsproxy. Det talar om hur mycket matrismultiplikation som sker per token, vilket motsvarar hur snabbt en GPU-bunden avkodning körs. Det säger inte hur mycket minne du behöver för att hålla modellen, vilket styrs av totalen – 70,43 GB BF16-vikter, eller ungefär en fjärdedel av det vid 4-bit, innan du räknar in en KV-cache. För en modell med 256K-kontext är den cachen inte heller ett avrundningsfel.

• Avkodningshastighet — styrs av aktiva parametrar (~2,44B–4,01B här). Det är vad påståendet om 13 tokens/s handlar om.

• Resident minne — bestäms av det totala antalet parametrar (35,21B lagrade), och minskas sedan av kvantisering och av vilken expertuppsättning som än förblir resident.

• Lagring och laddning — styrs av hela 70,43 GB vid BF16. Gles routning minskar inte nedladdningen.

• Bandbredd, inte flops – på en telefon är den avgörande begränsningen att få experter genom en minnesbuss, vilket är anledningen till att schemaläggningstekniken finns och till att enbart ett antal aktiva inte förutsäger något om mobillatens.

Den praktiska konsekvensen: om du har en GPU med tillräckligt minne för att hålla de kvantiserade vikterna är antalet aktiva det som avgör din genomströmning, och ”3B active” är en bra sak. Om du är anledningen till att frasen ”körs på en iPhone” dyker upp i ett inlägg är det totala antalet det tal som avgör genomförbarheten, och leverantörens schemaläggningsarbete är den del som gör det totala antalet levbart. Båda tolkningarna av samma rubrik är korrekta, och de är inte samma tolkning.

Jämförelsen i det inlägget behöver två etiketter, inte en.

Den inramning som fick det här att cirkulera var lokal kontra dyr hårdvara: MiniCPM-V 4.7 35B-A3B som modellen som ger dig samma kapacitet utan riggen, mot Qwen3.8-27B som modellen som var smartare men behövde riggen. Kapacitetsdelen av det kommer från Qwens eget modellkort, och den är leverantörsrapporterad precis som allt annat på den här sidan. Qwens publicerade siffror för Qwen3.8-27B inkluderar 90,3 på LiveCodeBench v6, 89,2 på GPQA Diamond, 84,3 på OSWorld-Verified och 79,0 på QwenSWEBench, och vår egen katalogpost för den noterar dessa som ovanligt starka agentiska och kodningsrelaterade resultat för en tät 27B-modell. Huruvida den var "smartare än Opus 4.6" är ett påstående från inlägget i sociala medier, och jag har ingen oberoende utvärdering framför mig som avgör det — så jag kommer inte att upprepa det som ett faktum.

Den strukturella skillnaden är den som faktiskt går att kontrollera: Qwen3.8-27B är dense, så alla dess 27B parametrar är aktiva och dess minnesavtryck och dess beräkningskostnad är samma siffra. MiniCPM-V 4.7 35B-A3B skiljer dessa två siffror åt med ungefär en faktor nio. Det är hela det arkitektoniska argumentet, och det är verkligt. Det är bara inte samma sak som en benchmarkjämförelse, och inlägget som gjorde det känt blandade samman de två.

Där en router ändrar beslutet, och där den inte gör det

Två saker är sanna här och värda att skilja åt, eftersom de pekar i motsatta riktningar.

Det första är att vi inte tillhandahåller MiniCPM-V 4.7. Den finns inte i vår katalog. Om du vill ha den är vägen din egen hårdvara — vilket är precis vad släppet är utformat för, med vikter, kvantiseringar och guider för distribution på enheten publicerade tillsammans med det. Inget med ett hostat API hjälper dig att köra en modell på en telefon, och det vore vilseledande att antyda något annat.

Det andra är att modellen som denna mäts mot inte är i den positionen. Qwen3.8-27B finns tillgänglig via vårt API, självhostad på vår egen infrastruktur, för $0,33 per miljon indatatoken och $2,40 per miljon utdatatoken. Om frågan du egentligen ställer är ”ska jag ersätta mina hostade Qwen3.8-27B-anrop med en lokalt driftsatt MiniCPM-V 4.7”, så är den ärliga versionen av svaret att du bör köra experimentet innan du bestämmer dig: genomströmningssiffran på enheten är inte reproducerad, och förmågejämförelsen är motpartens eget kort. Det är situationen som failover är till för – dirigera en del av trafiken till en ny väg, behåll den beprövade bakom den och låt en dålig vecka kosta dig en bråkdel av en arbetsbelastning i stället för hela arbetsbelastningen. En modell med 0 % påslag håller också kalkylen ärlig: när en leverantör ändrar ett pris ändras beloppet du betalar samma dag, eftersom det finns ingen marginal mellan deras listpris och din faktura.

Vad en router inte kan göra är att få frågan om lokalt kontra hostat att försvinna. Den avgörs av din hårdvara, dina integritetsbegränsningar och om en nedladdning på 70 GB är acceptabel — och antalet aktiva parametrar, hur man än avrundar det, förändrar inte någon av de tre.

Vad skulle avgöra det?

Tre saker, i fallande ordning efter användbarhet. En siffra för aktiva parametrar publicerad av OpenBMB, så att siffran som alla upprepar slutar vara en tredje parts aritmetik – min inräknad, och min är reproducerbar från shard-huvudena om du inte håller med om den. En oberoende mätning av de 13 token per sekund på en telefon, med kvantiseringsinställningarna angivna, eftersom en schemaberoende siffra utan sina inställningar inte är en specifikation. Och en riktig utvärdering som jämför MiniCPM-V 4.7 35B-A3B mot Qwen3.8-27B på samma uppgifter, eftersom jämförelsen som gjorde den här modellen uppmärksammad för närvarande är en leverantörs diagram mot en annan leverantörs modellkort.

Fram till dess är den säkra sammanfattningen snävare än inlägget: vikterna är verkliga, glesheten är verklig, nedladdningen är 70,43 GB, och per token utför modellen någonstans mellan 2,4 och 4 miljarder parametrars arbete beroende på hur man räknar de delar man inte kan routa runt. Det är ett äkta ingenjörsresultat. Det är ännu inte ett uppmätt telefonbenchmark, och det är inte en benchmarkvinst över en tät 27B.

Källa: parametrar, antal experter, lagertyper, kontextlängd och nedladdningsstorlek lästes direkt från config.json och safetensors-shard-headers för openbmb/MiniCPM-V-4.7-35B-A3B den 13 oktober 2026. Hastighet på enheten, minnessiffra, benchmarkresultat och utvärderingssiffrorna för Qwen3.8-27B är leverantörsrapporterade och inte reproducerade. Påståendena "3B aktiva parametrar" och "smartare än Opus 4.6" härrör från ett inlägg i sociala medier från tredje part, inte från någon av leverantörerna.

Inget av detta är hypotetiskt: de dokumenterade AI-misslyckandena och agentincidenterna som ett nummer som detta citeras i samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, tillförlitlighetsbetyg och omstridd-flagga.