En voxelpagod, 10 % färre tokens och den enda mening som OpenBMB faktiskt står bakom

Den mest citerade meningen om MiniCPM-V 4.7 35B-A3B den här veckan finns inte i dess modellkort. Det är en tweet, publicerad den 13 oktober 2026, som lyder: "MiniCPM-V 4.7 35B-A3B använde inte bara färre tokens, utan producerade också en bättre voxel-pagod än Qwen 3.6 35B-A3." Demonstrationen som den pekar på är en video av två språkmodeller som var och en skriver koden för en japansk 3D-voxelpagod, renderad sida vid sida. Det är en genuint intressant artefakt – den visar en visions-språkmodell som återskapar en byggd struktur i tre dimensioner från en bildprompt, vilket är en svårare uppgift än att sätta bildtext på en. Men det är värt att skilja på vad den tweeten är och vad den inte är, eftersom tre olika påståenden har smälts samman till en rad, och de har tre olika nivåer av belägg. MiniCPM-V 4.7 35B-A3B är en riktig checkpoint från OpenBMB och den är ungefär en vecka gammal; Qwen3.6-35B-A3B är en nio månader gammal rival med öppna vikter, också Apache-2.0, också en gles mixture-of-experts i samma angivna storlek. Allt nedan handlar om vilka av effektivitetspåståendena kring dem som går att kontrollera, och vilka som är en JPEG-bild av ett diagram.

Tre påståenden klädda i en mening

Tweeten buntar ihop tre separerbara saker, och de förtjänar att separeras eftersom endast en av dem är dokumenterad.

• "Använde färre tokens" – detta är ett mätbart påstående om tokenförbrukning för en uppgift. Siffran som cirkulerar tillsammans med demot är 10 % färre tokens än Qwen3.6 35B-A3B. Den siffran kommer från tredjepartsskaparen som genomförde jämförelsen, inte från OpenBMB:s utvärdering, och det är ett enda promptpar, inte ett benchmark.

• "Producerade en bättre voxelpagod" — detta är en bedömning, gjord genom att titta på två renderade pagoder. Det finns ingen bedömningsmall, inget poängsättningsramverk och ingen oberoende part. Det är den typ av påstående som en människa gör på tre sekunder och som ett benchmark inte kan göra alls, eftersom "bättre pagod" inte har något facit.

• "Effektivitet plus kvalitet är det verkliga slagfältet" — den delen är en tes, och den råkar vara den som OpenBMB faktiskt argumenterar för i skrift, med siffror bifogade, i modellkortet. Det är bara inte meningen som spreds.

Detta spelar roll eftersom de två första påståendena är de minnesvärda och det tredje är det försvarbara. Om du överväger att lägga 70 GB nedladdning på en checkpoint, vill du ha det tredje.

Vad OpenBMB faktiskt skrev, och när

Tidslinjen först, eftersom den har komprimerats av återberättandet. Vikterna lades upp tyst: openbmb/MiniCPM-V-4.7-1B skapades den 6 oktober 2026 kl. 17:40 UTC, openbmb/MiniCPM-V-4.7-35B-A3B den 7 oktober kl. 07:07 UTC. Ingen av dem hade ett modellkort, en licensmärkning eller ett benchmark vid det tillfället – detta rapporterades här då, och det var ett märkligt läge för en uppladdning med 35 miljarder parametrar. Sex dagar senare, den 12 oktober 2026, checkade OpenBMB in dokumentationen i ett svep: modellkort, Apache-2.0-licens, utvärderingsdiagram, en omskriven README för repot som inleds med den nya serien, och ett tillkännagivande. Parametrarna ändrades inte den dagen. Förklaringen gjorde det.

Så den ärliga formuleringen är inte ”MiniCPM-V 4.7 35B-A3B lanserades den här veckan”. Den är ”MiniCPM-V 4.7 35B-A3B blev läsbar den här veckan”. Allt om den som nu går att citera laddades antingen upp den 6:e och 7:e men utan dokumentation, eller skrevs den 12:e och är ett leverantörspåstående.

Det påstående som modellkortet faktiskt gör

Här är meningen, ordagrant från kortet, och den är snävare än tweeten: i Instruct-läge uppnår 35B-A3B-varianten "en högre totalpoäng på kortare inferenstid än Qwen3.6 35B-A3B." Det är allt. Ingen tokenräkning, ingen marginal, ingen uppdelning per benchmark i löptext. Beviset bakom den är ett spridningsdiagram – genomsnittlig utvärderingspoäng på den vertikala axeln, inferenstid i sekunder på en logaritmisk skala på den horisontella axeln – där MiniCPM-V 4.7 35B-A3B ligger ovanför och till vänster om Qwen3.6-35B-A3B. Diagrammets egen fotnot definierar genomsnittet som medelvärdet av fem benchmarks: MMStar, MMMU-Pro, CharXiv reasoning, BLINK och MathVista. Cirklar betecknar Instruct-läge, romber betecknar Thinking-läge.

Det är ett verkligt och specifikt påstående om en tvådimensionell avvägning, och det är det starkaste i släppet. Det är också värt att notera vad diagrammet inte kan säga dig: det finns inga numeriska etiketter på de plottade punkterna, så du kan inte läsa av en poäng eller en tid, bara en riktning. Riktningen, så som den är ritad, gynnar MiniCPM på båda axlarna samtidigt.

Och det mättes av leverantören. Modellkortets utvärderingssiffror har raden "Resultaten kommer från offentliga rapporter och vår lokala utvärdering med officiella checkpoints." Lokal utvärdering betyder OpenBMB:s hårdvara, OpenBMB:s testramverk, OpenBMB:s lägesval. Det är en normal sak för ett modellkort att göra och en onormal sak att tvätta till fakta. Ingen oberoende part har kört dessa två checkpoints mot ett gemensamt testramverk. Ingen resultattavla har indexerat något av resultaten. I skrivande stund har påståendet exakt en källa, och källan säljer modellen.

Varifrån token-effektiviteten ska komma

Effektivitetsargumentet vilar inte på benchmarkdiagrammet. Det vilar på tre ingenjörsmässiga val, och de är värda att förstå eftersom de avgör om vinsten överförs till din hårdvara eller inte.

• Lookahead Expert Scheduling (LES) – den främsta tekniken. En gles mixture-of-experts-modell lagrar långt fler parametrar än den aktiverar per token, och på en enhet som inte kan hålla varje expert i minnet växlas vikterna in och ut och avkodningen stannar. LES använder routningsprediktion över lager för att förladda experter som sannolikt behövs av nästa lager, och prioriterar beräkning för experter som den verkliga routern faktiskt valde och som råkar vara redan inladdade. OpenBMB är noga med att påpeka att prediktionen endast styr förhämtning och schemaläggning; modellens routning på tokennivå är oförändrad, och experter som prediktorn missade laddas fortfarande in och utvärderas. Kortet hävdar en 5× snabbhetsökning på verkliga enheter tack vare detta, utan förlust av förmåga.

• Finmaskig lagervis kvantisering – krymper expertvikternas fotavtryck och minnestrafiken, vilket är den andra halvan av att få ett inläsningsmönster på enheten att passa.

• DSpark spekulativ sampling – en parad draftmodellväg, publicerad separat som openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, och integrerad tillsammans med arbetet med schemaläggning och kvantisering.

Tillsammans ger dessa släppets paradnummer: över 13 tokens per sekund med cirka 3 GB minne på en iPhone 17 Pro Max. Det är en leverantörssiffra, på leverantörens hårdvara, med leverantörens programvara – en app som OpenBMB har skrivit. Det är den typen av påstående som antingen är hela produkten eller ingenting alls, och för närvarande finns det inget sätt för någon utanför företaget att kontrollera det, eftersom att återskapa det kräver den stack på enheten som telefondemot kör.

Tokeneffektivitet är verklig, men här är det en matris, inte en skalär.

Det finns en detalj i den här utgåvan som har plattats ut i varje sammanfattning av den, och det är den som faktiskt styr tokenekonomin.

• MiniCPM-V 4.7 35B-A3B stöder blandad 4x- och 16x-komprimering av visuella token, valbar per begäran. Inställningen 16x slår samman visuella token för snabbhet; 4x behåller fyra gånger så många, för detaljrikedom. Kortets standardvärde är 16x, och parametern måste skickas till både chattmallen och generate-anropet, annars stämmer inte antalet platshållare överens med visionskodaren.

• Tillverkarens egen jämförelsetabell för vision-språk anger den komprimeringsinställning som används för varje modells rad. I den tabellen ligger raden för MiniCPM-V 4.7 35B-A3B på 4x — den detaljbevarande inställningen, dvs. den dyra — och raden för Qwen3.6 35B-A3B ligger på 16x. En rad för 31B Gemma 4 listas på 9x; de två 27B Qwen-raderna på 4x.

• En fotnot anger tydligt att MiniCPM-V 4.7 stöder endera inställningen, medan de övriga modellerna i tabellen endast stöder ett fast kompressionsförhållande.

Läser man det tillsammans förändras bilden. Om MiniCPM-raden hämtar sina vision-language-poäng vid den tokenkrävande inställningen medan Qwen-raden hämtar sina poäng vid den tokensnåla inställningen, då jämför de två kolumnerna olika mängder visuell detalj, och berättelsen om effektivitet är inte "samma indata, färre tokens" – den är "justerbara indata, och här är kolumnen som vinner på kvalitet". Det är ett mer intressant och mer ärligt påstående än tweetens, och OpenBMB publicerade det i en fotnot i stället för att inleda med det.

Det betyder också att det tal du faktiskt bryr dig om – tokens per enhet visuell detalj – inte alls går att utläsa ur den här tabellen. Det kräver att båda modellerna körs med samma inställning, vilket ingen har publicerat.

Tabellen, med förbehållen bifogade

Kortet levereras med två leverantörstabeller, en för vision–språk och en för språk, båda i Instruct-läge, båda mot ett startfält som omfattar två Qwen-modeller i 35B-A3B-klassen, en 31B Gemma och två 27B-Qwen. Siffrorna nedan är avlästa från leverantörens egen PNG-graf, och förbehållet är strukturellt: siffrorna finns endast som pixlar i den grafen, inte som en tabell, så det som följer har extraherats genom maskinläsning, och små transkriptionsfel är möjliga.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 mot Qwen3.6 35B-A3B på 90,40. En skillnad på 0,8 punkter, i leverantörens egen testkörning.

• OmniDocBench v1.6 — ungefär 98,2 för MiniCPM mot ungefär 93,3 för Qwen-modellen, vilket är den största enskilda skillnaden i tabellen och den som skulle spela störst roll om den reproducerades, eftersom dokumentparsning är där token-budgetar vanligtvis görs av med.

• MMMU – ungefär 80,2 mot 80,0, ett dött lopp på den upplösning en diagrambild har.

• MMMU-Pro — ungefär 69,7 mot 67,7, i en rad där en 27B Qwen ligger högre än båda.

• Språktabell – samma form, med de mer slående cellerna för instruktionsföljning och kod. IFBench listas omkring 47,7 mot 35,3, och LiveCodeBench-v6 omkring 97,0 mot 54,3. De två är tillräckligt stora för att de bör behandlas som de minst trovärdiga cellerna i släppet tills någon annan kör dem: en spridning på 43 punkter i ett kodbenchmark mellan två öppna MoE-modeller av liknande storlek, mätt av en av de två parterna, är ett påstående som behöver ett andra mätinstrument.

Leverantörsrapporterat, leverantörstestat, oreproducerat. Det är allt. Om dessa siffror håller under en oberoende testrigg, är påståendet om Pareto-fronten korrekt och pagodvideon är en fotnot. Om de inte gör det, är pagodvideon allt som finns.

Vad adoptionssiffrorna säger, vilket inte säger något om kvaliteten

Ett tal i den här jämförelsen ifrågasätts inte av någon, och det är inte ett riktmärke. Nedladdningsräknaren på Hugging Face, avläst den 13 oktober 2026, visar 630 för openbmb/MiniCPM-V-4.7-35B-A3Bmot ungefär 3,6 miljoner förQwen/Qwen3.6-35B-A3B— ett repositorium skapat den 15 april 2026 och som därför ligger ungefär nio månader längre fram på adoptionskurvan. Den klyftan mäter tid, inte förtjänst, och det är anledningen till att effektivitetsfrågan överhuvudtaget ställs i den här riktningen: nykomlingen måste argumentera per token just för att den inte har haft nio månader på sig att vara standardvalet.

Det finns också en liten intern motsägelse i listningen som är värd att flagga. Repositoriet bär taggen "On-Device Model" som ärvts från resten av familjen, och en sparse MoE med 35,2 miljarder parametrar i 70,4 GB BF16-vikter är inte on-device i någon bemärkelse som en nedladdare skulle känna igen. On-device-berättelsen är verklig, men den går via kvantisering och expertströmning ovanpå checkpointen, inte via checkpointen. Budgetera mot den kvantiserade byggversionen och appen, inte mot taggen.

Vad man kan göra åt det den här veckan

Den praktiska ståndpunkten är snäv och tydlig. Om du vill få effektivitetsanspråket verifierat finns det inget att verifiera ännu – det är en enda leverantörs diagram, och den enda siffran med en siffra per uppgift kopplad till sig (10 % färre tokens, en pagod) kommer från en tredje parts enda demo. Om du vill köra modellen är vikterna Apache-2.0, arkitekturen är dokumenterad, och nedskalningsinställningen är din att välja, vilket är en genuin och underskattad hävstång: 16x när genomströmning spelar roll, 4x när diagrammet visar dig ett dokument.

Den ena halvan av den här jämförelsen kan nås via ett hostat API idag och den andra kan inte det, och det är värt att vara precis om vilken som är vilken. qwen/qwen3.6-35b-a3bär en hostad modell på OrcaRouter – den finns i katalogen bakom en enda nyckel, till Qwens eget listpris utan något påslag, som skickar vidare till vilken leverantör som än är frisk i stället för till en som du har pinnat. MiniCPM-V 4.7 hostas inte av oss; det är en checkpoint med öppna vikter som du serverar själv. Den asymmetrin är det användbara här. Du kan lägga in Qwen-sidan av den här jämförelsen i en baslinje i eftermiddag, köra OpenBMB:s testramverk på dina egna data mot den, och låta leverantörens diagram vara hypotesen snarare än svaret.

Vilket, med tanke på att hela argumentet handlar om effektivitet på din hårdvara, är det enda mätvärde som någonsin skulle kunna avgöra saken.