MiniCPM-V 4.7 1B på en vanlig iPhone: Vad "går längre än Pro Max" faktiskt innebär

MiniCPM-V 4.7 1B är en bildspråkmodell med 1,55 miljarder parametrar som OpenBMB laddade upp till Hugging Face den 6 oktober 2026 och som enligt de egna versionsanteckningarna är daterad till den 12 oktober. Den har ett modellkort, elva kvantiserade syskonmodeller, en Ollama-tagg och en demoapp för lokal körning. Det den inte har är en version av historien som håller när man räknar på hårdvarukostnaden. Påståendet som cirkulerar i utvecklarkretsar – att modellen nu körs i en OnDeviceLLM-app på vanliga iPhones, inte bara på en 12 GB Pro Max – är den del som är värd att granska noggrant, eftersom "körs på en telefon" och "körs på din telefon" skiljs åt av ungefär 3 GB minnesutrymme som de flesta iPhones inte har. De dokumenterade AI-felen och agentincidenterna bakom släpp som detta samlas i the OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omstridd status.

Här är läget, med sömmarna synliga. Allt nedan är antingen läst direkt från viktfilerna, från OpenBMB:s egen dokumentation eller från Apples publicerade specifikationer. Där en siffra kommer från ett inlägg från en utvecklare snarare än från en reproducerbar artefakt säger den här artikeln det.

Vad är faktiskt känt, och vad är bara påstått?

Modellen är verklig och nedladdningsbar. BF16-kontrollpunkten har 1 554 476 272 parametrar, vilket motsvarar ungefär 3,1 GB på disk. Repositoriet innehåller ett fullständigt modellkort – en sällsynthet i den här familjens senaste historia – som anger en Qwen3.5-textryggrad, ett SigLIP2-visionstorn med 27 lager vid 1152 dold bredd, 980-pixlars indatarutor, ett kontextfönster på 262 144 token och Apache 2.0-licens. OpenBMB:s egen README-post daterar utgivningen till 2026-10-12; Hugging Face-repositoriet skapades 2026-10-06. Gapet på sex dagar är fördröjningen mellan uppladdning och tillkännagivande som den här familjen är känd för, och det är anledningen till att en oktoberartikel fortfarande kan kalla ett sex dagar gammalt repositorium för en tyst lansering.

Vad som inte styrks av någon artefakt är det specifika påståendet att 1B-modellen körs i OnDeviceLLM på "vanliga iPhones bortom 12GB Pro Max". Ett inlägg från en utvecklare är ursprunget till den formuleringen. OnDeviceLLM-projektets offentliga arkiv – som är ett startpaket för offlinechatt- och översättningsappar, inte en lanserad App Store-produkt – har noll stjärnor och senast pushades den 27 juli 2026. Det föregår MiniCPM-V 4.7-vikterna med tio veckor, så allt stöd för den här modellen i det är nytt och odokumenterat. Betrakta "redan körs i OnDeviceLLM" som en rapport från någon som har gjort det, inte som en leverantörsstödd driftsättningsväg.

Den åtskillnaden spelar roll eftersom leverantörens egna siffror för körning på enheten inte alls handlar om 1B.

Siffran 3 GB tillhör 35B, inte 1B.

OpenBMB:s huvudpåstående – "13+ tokens/s med bara 3 GB minne på iPhone 17 Pro Max" – är kopplat till 35B-A3B Mixture-of-Experts-varianten, som körs på den största iPhone som Apple säljer. Tekniken bakom, Lookahead Expert Scheduling, håller de flesta expertvikterna på SSD och förhämtar de som nästa lager sannolikt behöver. Det är ett imponerande stycke systemteknik, och det är anledningen till att namnet 35B fortsätter att dyka upp i telefonrelaterad rapportering.

1B-modellen behöver inte något av det. Det är en dense-modell som ryms i minnet direkt. På papperet gör det den till den mer demokratiska av de två, och det är därför vinkeln med en "everyday iPhone" har bärkraft. Men aritmetiken är mindre vänlig än inramningen antyder:

• BF16-vikter — 3,1 GB på disk, och ungefär lika mycket resident minne när de väl är laddade, innan någon KV-cache eller några visionsaktiveringar • Q8_0 GGUF — 1,08 GB vikter, plus en visionsprojektor på 0,90 GB vid 4× komprimeringsinställning, eller 1,11 GB vid 16× • Q4_K_M GGUF — 0,67 GB vikter, med samma projektoroverhead • Visionsprojektor — det här är delen folk glömmer; den krymper inte med språkmodellens kvantisering, och den räknas en gång per laddad modell • Kontext — upp till 262 144 token på papperet; varje token i KV-cachen är extra minne som modellkortet inte budgeterar för

Ett Q4-bygge med 16×-projektorn landar nära 1,8 GB i modellvikter. Lägg till en fungerande KV-cache för några tusen token konversation och bildplatshållare, och du begär något i intervallet 2,2–2,8 GB av en app. På en 12 GB Pro Max är det bekvämt. På en 8 GB iPhone, där operativsystemet och alla andra appar som ligger i minnet redan konkurrerar om samma pool, begär en app som vill ha 2,5 GB en stor andel av det som återstår. iOS beviljar det, eller så terminerar det appen med jetsam under press.

Varför RAM-raden på en iPhone är den riktiga specifikationen

Apple publicerar inte iPhone-RAM i sina marknadsföringsspecifikationer, och företaget har aldrig uppmuntrat utvecklare att behandla telefonen som en minnesadresserbar dator. Det är den begränsning som påståendet "bortom 12GB Pro Max" stöter på. Pro Max-nivån har i flera generationer haft mer minne än standardmodellerna, och gapet mellan "telefonen i recensionsvideon" och "telefonen i en läsares ficka" är precis det gap som den här modellens berättelse om bearbetning på enheten hänger på.

Den ärliga versionen av påståendet är snävare och fortfarande intressant: en 1B-visionmodell som tidigare krävde en bärbar dator eller en flaggskeppstelefon får nu plats inom minnesbudgeten för en mellanklassmobil, om du använder 4-bitars kvantisering och accepterar en kortare kontext. Det är ett verkligt steg ned i hårdvaruklass. Det är inte samma sak som "körs på varje iPhone", och skillnaden är värd att sägas rakt ut eftersom den avgör om en läsare kan släppa produkten.

Modellkortet avgör det inte. Det dokumenterar stöd för iOS, Android och HarmonyOS, chipstöd från dag 0 från Rockchip, Houmo, Intel, AMD och Arm, och länkar till ett edge-distributionsrepo med appar och källkod. Ingenstans listar det minsta enhetsminne, en testad enhetsmatris eller en tokenhastighet per enhet för 1B. Den enda enhet som namnges i 1B:s egna demotillgångar är en iPhone 17 Pro Max – samma enhet som 35B-rubriken.

Vad modellen faktiskt är bra på, vid 1B

Anledningen till att detta är värt minnesberäkningen är att en 1B-modell som utför dokument- och skärmförståelse i en telefon är en annan produktkategori än en chattbot. Det innebär att ett kvitto, ett formulär, en meny, en etikett eller en skärmbild kan omvandlas till strukturerad text utan en nätverksrundtur – ingen uppladdning, ingen kostnad per bild, inget latensgolv som sätts av en mobilmast.

OpenBMB:s publicerade 1B-siffror, samtliga rapporterade av leverantören och ingen av dem oberoende reproducerad vid tidpunkten för detta, anger OCRBench till 86,1, MathVista till 74,3, CharXiv Reasoning till 48,8, LongVideoBench till 53,4 och MotionBench till 54,55. Leverantörens huvudjämförelse är mot Q​wen3.5 0.8B, som den uppger sig slå både på totalpoäng och inferenseffektivitet, och mot MiniCPM-V 4.6, som den uppger sig förbättra inom centrala förmågor. Det är leverantörens egna riktmärken, körda av leverantören, och modellkortet presenterar dem som diagram snarare än som en tabell med information om testramverket.

Två arkitektoniska detaljer spelar större roll än poängen för alla som faktiskt driftsätter detta:

• Blandad 4×/16× visuell tokenkomprimering – anroparen väljer per begäran om en bild ska bli en detaljerad tokensekvens eller en billig, så en kvittoskanning och en miniatyrbild kan dela distribution • Tidig komprimering i ViT, lånad från LLaVA-UHD v4 – visuella token skärs ned inuti visionskodaren i stället för efter den, vilket är det som gör 4×-vägen överkomlig från början • Uppdelning – högupplösta bilder delas upp i 448×448-plattor plus en översiktsbild med låg upplösning, där antalet delar är en körtidsparameter (kortet rekommenderar 36 för bilder, 1 för video) • Videosampling — max_num_frames är som standard 128, och stack_frames sammanfogar delbildrutor till ett rutnät, vilket är hur en telefon klarar en skärminspelning utan att hålla varje bildruta i minnet

För kvittofallet som prompten nämner är pipelinen: fånga, skala ned till ungefär 980 pixlar på långsidan, kör i 4× med högt antal skivor och be om strukturerad utdata. 4×-vägen med 36 skivor är den dyra inställningen; 16×-vägen använder ungefär en fjärdedel av tokenarna och är där telefonen förblir responsiv. Huruvida 16× räcker för att läsa ett termiskt kvitto är en fråga som bara dina egna bilder kan svara på, och ingen publicerad benchmark i kortet rapporterar OCR-noggrannhet per nedskalningsläge.

Klyftan mellan "demo" och "app"

Tre saker står mellan en fungerande demo och en iOS-app som är redo att släppas, och ingen av dem är modellens vikter.

Det första är paketeringen. Modellen levereras i formaten Transformers, GGUF, AWQ, GPTQ och int4. Endast GGUF har en mogen runner för körning på enheten i iOS – llama.cpp och dess släktingar – och endast GGUF-förvaret innehåller den separata filen för visningsprojektorn (mmproj) som den multimodala vägen behöver. Om du utgår från BF16-checkpointen och förväntar dig en enda fil att bara lägga in, kommer du att upptäcka att projektorn är en andra artefakt med sin egen storlek.

Den andra är termisk budget. En 1B-modell som genererar några hundra tokens är en burst-arbetsbelastning; en 1B-modell som OCR:ar en sida med 36 skivor är en uthållig sådan. Leverantörens demo-GIF är en skärminspelning, inte en termisk mätkurva. Ingen publicerad siffra i kortet anger uthålliga tokens per sekund på någon telefon, och det är den siffra som avgör om en skanningsapp känns omedelbar vid det tredje dokumentet eller det trettionde.

Den tredje är resten av din stack. Inferens på enheten hanterar bilden. Den hanterar inte delen där du stämmer av det extraherade kvittot mot ett huvudregister, eskalerar en tvetydig rad till en större modell, eller faller tillbaka när telefonen är så gammal att appen vägrar ladda vikterna. Det är gränsen där en router förtjänar sin plats i stället för att ersätta något: OrcaRouter sätter fler än 200 värdbaserade modeller bakom en enda OpenAI-kompatibel slutpunkt med 0 % påslag, som skickar varje leverantörs listpris rakt igenom, med automatisk failover och ett routing-DSL för primär- och reservkonfigurationer. En extraktor på telefonsidan kan lämna sina osäkra fall till en värdbaserad visionsmodell, och samma nyckel bär båda vägarna. MiniCPM-V 4.7 1B finns inte själv i den katalogen – det är en checkpoint du kör själv – så routern är eskaleringsvägen, inte sättet att anropa den här modellen.

Mönstret med tyst lansering, och varför det fortsätter att ge upphov till den här förvirringen

MiniCPM-V 4.7 anlände utan något lanseringsevenemang. 35B-A3B-repositoriet dök upp den 6 oktober 2026 helt utan modellkort – kortet kom sex dagar senare tillsammans med den daterade versionsnoten. 1B följde samma mönster: repository först, dokumentation sedan, upptäckt av communityn under hela förloppet. Under mellanperioden fylls rapporteringen på utifrån vilken artefakt som än finns, vilket är anledningen till att tidiga artiklar beskrev en 35B MoE-modell och sedan måste revideras när 1B och dess kort dök upp.

Detta är inte en kritik av OpenBMB:s ingenjörsarbete. Det är en beskrivning av hur information om den här modellen sprids, och det är anledningen till att ett påstående som ”körs på vanliga iPhones” kan färdas snabbare än de minnessiffror som nyanserar det. Repositoriet är den primära källan. Modellkortet är den primära källan. En utvecklares skärmbild av en app som fungerar på dennes telefon är en datapunkt, inte en specifikation.

Vad ska man göra med det här, konkret?

Om du har en Pro Max eller en iPad.Ladda ner Q8_0 GGUF och 16×-projektorn, kör den via llama.cpp eller Ollama och testa dina egna dokument med båda nedskalningsinställningarna. Du får en fungerande lokal OCR- och bild-QA-väg inom en eftermiddag, och 1B är tillräckligt litet för att du ska kunna hålla det resident vid sidan av andra appar.

Om du har en vanlig iPhone. Börja med Q4_K_M och 16×-projektorn, begränsa antalet slices till något blygsamt och mät. Minnesaritmetiken säger att det borde passa; värme- och jetsam-beteendet vid ihållande användning är den del som ingen har publicerat. Testa på den äldsta enhet du avser att stödja, inte den nyaste.

Om du bygger en produkt. Betrakta modellen på enheten som den snabba vägen och en hostad modell som korrekthetsvägen. Eskaleringen är ett routingbeslut, och att bygga in den från dag ett är billigare än att eftermontera den efter det första supportärendet om ett kvitto som telefonen läste fel.

Påståendet som inledde den här artikeln – att en multimodell med 1B parametrar nu körs på telefoner under Pro Max-nivån – är rimligt utifrån minnesaritmetiken och obevisat i det publicerade materialet. Det är ett normalt tillstånd för en så ung modell, och det är ett skäl att testa snarare än att vänta. Vikterna är Apache 2.0, kvantiseringarna finns, och det enda som står mellan dig och ett svar är en eftermiddag med din egen hårdvara.

Kort sagt: MiniCPM-V 4.7 1B är en verklig, dokumenterad visionsmodell under Apache-2.0 som i Q4-format tar ungefär 1,8 GB inklusive sin visuella projektor – tillräckligt liten för att mellanklassmobiler ska vara ett trovärdigt mål och inte bara 12 GB Pro Max. Leverantören har inte publicerat någon enhetsmatris eller någon siffra för minsta minne, och påståendet om "vardags-iPhone" kommer från en utvecklarrapport snarare än från modellkortet. Testa på din egen enhet innan du planerar utifrån det.