MiniCPM-V 4.7 får plats med en 35B-visionsmodell i 3 GB: reder ut påståendet om 100 tok/s

En modell med 35 miljarder parametrar får inte plats i tre gigabyte. MiniCPM-V 4.7 35B-A3B körs ändå i ungefär tre gigabyte, och båda påståendena är sanna – det är hela tricket, och anledningen till att siffrorna som cirkulerar om det här släppet är värda att sakta ner för. Modellen är OpenBMB:s första sparse mixture-of-experts-post i MiniCPM-V-serien: 35,2 miljarder lagrade parametrar, omkring 3 miljarder aktiva per token, Apache-2.0, vikter på Hugging Face. Den läser bilder, flerbildsuppsättningar och video, och svarar i text. Sedan 10 oktober körs den också i upstream llama.cpp, vilket är där de flesta stötte på den. Det följande skiljer på de tre siffror alla upprepar – 3 GB, 35B och siffran 100 tok/s – och visar vilka av dem som OpenBMB faktiskt publicerade. Fler än 200 värdbaserade modeller, en nyckel, leverantörens listpris vidarebefordrat med 0 % påslag. Se vad OrcaRouter dirigerar Checkpointen med öppna vikter ligger kvar på din hårdvara; den värdbaserade nödutgången är en enda endpoint. De dokumenterade AI-felen och agentincidenterna bakom släpp som detta samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omtvistade uppgifter.

Tre gigabyte, trettiofem miljarder parametrar och ingen motsägelse

Aritmetiken ser bara omöjlig ut om man antar att ”i minnet” betyder ”allt av det”. MiniCPM-V 4.7 35B-A3B håller cirka 3 miljarder parametrar residenta och strömmar in resten av experterna när routern ber om dem – modellkortets egen formulering är Lookahead Expert Scheduling, en routingprediktor över lager som förhämtar de experter nästa lager sannolikt behöver och överlappar den laddningen med beräkningar som redan pågår. Kortet är noga med att säga att prediktion bara driver förhämtning och schemaläggning; tokens följer fortfarande modellens verkliga routing, och en expert som prediktorn missade laddas och utvärderas som vilken annan som helst.

Den distinktionen har en mätbar konsekvens. GGUF-förrådet publicerar hela modellen i varje vanlig kvantisering, och ingen av dessa filer är tre gigabyte:

• Q4_K_M — 21,2 GB på disk.

• Q8_0 – 36,9 GB.

• F16 – 69,4 GB.

• Visionsprojektor — 0,9 GB vid 4x komprimering, 1,1 GB vid f16.

Så "3 GB" är en siffra för residentminne vid expert-strömning på en telefon, inte en nedladdningsstorlek och inte ett VRAM-krav för en stationär dator. Om du planerar en driftsättning är siffran som styr din disk och din första inläsning 21,2 GB vid Q4_K_M, och siffran som styr ditt stabila fotavtryck på en telefon är leverantörens ~3 GB. Båda finns med i släppet. De svarar på olika frågor, och merparten av bevakningen har klumpat ihop dem till en.

Varifrån 100 tok/s kommer, och varifrån det inte kommer

Här är delen där det är värt att vara krass. OpenBMB publicerar ingen siffra på 100 tok/s för MiniCPM-V 4.7. Siffran på modellkortet är 13+ tokens/s, på en iPhone 17 Pro Max, med ungefär 3 GB minne. Det är det enda påståendet om genomströmning på enheten som släppet gör, och det är mätt av leverantören på hårdvara som ingen utanför labbet har reproducerat.

Högre siffror finns visst, och de kommer från en annan artefakt. OpenBMB:s llama.cpp-omni-fork — förvaret som bär de på enheten lokala optimeringarna — publicerar sin egen tabell för 35B-A3B-målet, uppdelad efter vilka optimeringar som är aktiverade:

• iPhone 18 Pro Max, 12 GB — 3,38 tok/s i baslinje, 11,34 med Lookahead Expert Scheduling, 17,16 med mixad precision tillagd, 20,51 med DSpark-utkastningshuvudet också.

• iPad Pro 11 tum M4, 16 GB — 2,97 tok/s som baslinje, 9,81 med LES, 14,92 med blandad precision, 17,39 med DSpark.

Det är de högsta publicerade siffrorna för prestanda på enheten för den här modellen, och högst upp på skalan ligger 20,51 tok/s – en femtedel av 100. Klyftan spelar roll eftersom den förändrar vad modellen är till för. Vid 13 tok/s svarar en telefonapp på en fråga om ett foto på ett par sekunder. Vid 100 tok/s skulle du överväga den som en strömmande förstapassläsare för video. Det första är en riktig produkt. Det andra är inte vad som levererades, och den som budgeterar utifrån twittrets siffra kommer att bli besviken med en faktor fem.

En ärlig tolkning av påståendet om 100 tok/s är att det är en sammanpressning av tre separata fakta – 3 GB, körs lokalt, betydligt snabbare än förra generationen – till ett enda tal som ingen av källorna innehåller. Förbättringen från generation till generation är verklig och stor: 3,38 till 20,51 tok/s är en 6x förändring på samma typ av enhet, uppnådd genom att stapla tre tekniker snarare än genom en större chip.

Släppet var inte en dag, och datumen spelar roll

MiniCPM-V 4.7 dök upp på samma sätt som många släpp med öppna vikter gör nu: filer först, förklaring senare och ramverksstödet någonstans däremellan.

• 6 oktober, 17:40 UTC — 1B-modellen och dess AWQ-, GPTQ- och int4-varianter dyker upp på Hugging Face, samt GGUF-byggena kl. 18:05.

• 7 oktober, 07:07 UTC — 35B-A3B-repositoriet publiceras. Fortfarande inget modellkort.

• 8 oktober — DSpark-huvuden för spekulativ avkodning för båda storlekarna, samt en FP8-version av 35B.

• 10 oktober, 18:42 UTC — llama.cpp integrerar modellstöd.

• 12 oktober — OpenBMB checkar in modellkortet, deklarerar Apache-2.0 och tillkännager släppet som en dokumenterad produkt.

15 oktober — DSpark-huvudena är länkade från huvudkortet, med GGUF-utkast för båda målen.

Den ordningen förklarar en hel del förvirring i den sekundära rapporteringen. Den som stötte på modellen via llama.cpp under andra veckan i oktober körde en utgåva som officiellt ännu inte fanns, utan licensmärkning och utan benchmarkdiagram, och deras genomströmningstal speglar ramverkets egna kvantiseringsval snarare än något som OpenBMB hade benchmarkat.

llama.cpp-stöd: sammanfogat, och inte helt färdigt

Den uppströms pull request som lade till MiniCPM-V 4.7 är ovanligt tydlig med vad som ändrades, och svaret är: nästan ingenting arkitektoniskt. Modellen är nästan identisk med MiniCPM-V 4.6; skillnaden är 3D RoPE, en position med tre värden per token – tid, rad, kolumn – i stället för det enda skalära värdet som de flesta visionsspråkmodeller använder. Stödet bygger vidare på den befintliga 4.6-kodvägen för att hantera den extra dimensionen. PR:en noterade också modellen som "kommande" när den öppnades den 25 september, vilket är en rimlig antydan om hur tidigt vikterna var i omlopp.

Det kvarstående problemet är värt att känna till innan du bygger en grounding-funktion på det. Sedan den sammanslagningen tilldelar upstream llama.cpp bildmarkörstokens fel positioner i MiniCPM-V 4.7-prompter: själva bildtokens hamnar korrekt, men <slice>, </slice> och markörerna för radslut numreras som vanlig text i stället för att ges sina rutors hörnkoordinater, vilket referensimplementationen get_rope_index gör. Det synliga symptomet är att returnerade koordinater systematiskt ligger lågt när du frågar var något finns i en bild. En rättning med ett enhetstest finns som en öppen pull request daterad 14 oktober, och den är fortfarande öppen den 20 oktober. Om din arbetsbelastning är "beskriv det här" kommer du inte att märka det. Om den är "ge mig bounding boxen" kommer du att göra det, och du bör antingen vänta på sammanslagningen eller använda forken som har den korrigerade vägen.

En sak till överlever fram- och tillbakaresan: för 1B-modellen är visionsprojektorn den större nedladdningen. Q4_K_M-vikterna är 672 MB; f16-projektorn är 1,11 GB. Den minsta användbara 1B-driftsättningen är därför cirka 1,8 GB filer, varav större delen är ögon snarare än språk – en detalj som gör att förväntningen att ”1B betyder 1 GB” inte stämmer.

Vad som ska köras, och på vad

Om målet är att prova det den här veckan är den mest friktionsfria vägen llama.cpp eller Ollama mot GGUF-förråden, och att peka den multimodala klienten mot motsvarande mmproj-fil. På en GPU med 24 GB lämnar Q4_K_M på 21,2 GB väldigt lite utrymme för kontext – ett fönster på 8K token plus bildplattor får inte plats bekvämt, så planera för Q4_K_S eller en mindre kvantisering om du också vill ha en lång prompt. På en Mac med 32 GB eller mer är Q8_0 användbart och är det närmaste man kommer referensbeteendet. På en telefon är det bara leverantörens egna appar och llama.cpp-omni-forken som har expert-schemaläggningsarbetet; vanlig llama.cpp ger dig korrekthet, inte 20 tok/s.

Det är först på andra sidan det lokala anropet som ett routningslager gör verklig nytta här. En 3B-aktiv modell i en telefon är utmärkt på vardagsfallen – läs av det här kvittot, ser den här hyllan påfylld ut, vad står det på den här skylten – och den kommer ibland att stöta på en sida som den inte kan slutföra. OrcaRouter placerar över 200 hostade modeller bakom en enda nyckel, för vidare varje leverantörs listpris med 0 % påslag så att en leverantörs prisändring gäller samma dag, och växlar över automatiskt när en uppströmstjänst försämras. Mönstret som fungerar är lokalt först med en hostad nödutgång, inte enbart lokalt. Checkpointen med öppna vikter förblir din att hosta; routern hanterar allt som telefonen lämnar över.

MiniCPM-V 4.7 tillhandahålls inte av OrcaRouter, och vi kommer inte att antyda något annat. Det är en checkpoint som du kör.

Vad skulle avgöra de tre siffrorna

En oberoende mätning av 35B-modellen på en namngiven telefon, med appen och kvantiseringen angivna, skulle avgöra frågan om genomströmning – inklusive huruvida 20,51 tok/s överlever någon annans stoppur. En publicerad definition av siffran 3 GB – resident set, toppallokering eller något annat – skulle avgöra minnesfrågan. Och en tabell per benchmark med verkliga resultat, i stället för de fem länkade diagrammen som modellkortet för närvarande levereras med, skulle göra det möjligt att kontrollera påståendet ”bättre än Qwen3.6 35B-A3B på kortare tid” mot den viktning som OpenBMB valde. Inget av detta finns ännu. Innan dess är den korrekta meningen den tråkiga: en 35B gles modell som körs på en telefon med rapporterade drygt 13 token per sekund på cirka 3 GB, med en nedladdning på 21 GB och en sammanslagen ramverkssökväg som fortfarande har en öppen koordinatbugg.