MiniCPM-V 4.7 1B on an Everyday iPhone: What "Runs Beyond the Pro Max" Actually Means

MiniCPM-V 4.7 1B is a 1.55-billion-parameter vision-language model that OpenBMB uploaded to Hugging Face on October 6, 2026 and dated October 12 in its own release notes. It has a model card, eleven quantised siblings, an Ollama tag, and an on-device demo app. What it does not have is a version of the story that holds up when you price the hardware. The claim going around developer circles — that the model now runs in an OnDeviceLLM app on ordinary iPhones, not just on a 12GB Pro Max — is the part worth examining closely, because "runs on a phone" and "runs on your phone" are separated by about 3 GB of memory headroom that most iPhones do not have. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

Here is the state of play, with the seams showing. Everything below is either read directly from the weight files, from OpenBMB's own documentation, or from Apple's published specifications. Where a number comes from a developer's post rather than a reproducible artefact, this article says so.

What is actually known, and what is only claimed

The model is real and downloadable. The BF16 checkpoint is 1,554,476,272 parameters, which comes to roughly 3.1 GB on disk. The repository carries a full model card — a rarity in this family's recent history — naming a Q​wen3.5 text backbone, a SigLIP2 vision tower with 27 layers at 1152 hidden width, 980-pixel input tiles, a 262,144-token context window, and Apache 2.0 licensing. OpenBMB's own README entry dates the release to 2026-10-12; the Hugging Face repository was created 2026-10-06. The six-day gap is the upload-versus-announcement lag this family is known for, and it is the reason an October piece can still call a six-day-old repository a quiet ship.

What is not established by any artefact is the specific claim that the 1B runs in OnDeviceLLM on "everyday iPhones beyond the 12GB Pro Max." A developer post is the origin of that framing. The OnDeviceLLM project's public repository — which is a starter kit for offline chat and translation apps, not a shipping App Store product — has zero stars and was last pushed on July 27, 2026. It predates the MiniCPM-V 4.7 weights by ten weeks, so any support for this model in it is recent and undocumented. Treat "already running in OnDeviceLLM" as a report from someone who did it, not as a vendor-supported deployment path.

That distinction matters because the vendor's own on-device numbers are not about the 1B at all.

The 3 GB number belongs to the 35B, not the 1B

OpenBMB's headline claim — "13+ tokens/s with just 3 GB of memory on iPhone 17 Pro Max" — is attached to the 35B-A3B Mixture-of-Experts variant, running on the largest iPhone Apple sells. The technique behind it, Lookahead Expert Scheduling, keeps most expert weights on SSD and prefetches the ones the next layer is likely to need. It is an impressive piece of systems engineering and it is the reason the 35B name keeps appearing in phone-related coverage.

The 1B does not need any of that. It is a dense model that fits in memory outright. On paper that makes it the more democratic of the two, and it is why the "everyday iPhone" angle has legs. But the arithmetic is less friendly than the framing suggests:

• BF16 weights — 3.1 GB on disk, and roughly the same resident once loaded, before any KV cache or vision activations • Q8_0 GGUF — 1.08 GB of weights, plus a 0.90 GB vision projector at the 4× compression setting, or 1.11 GB at 16× • Q4_K_M GGUF — 0.67 GB of weights, with the same projector overhead • Vision projector — this is the part people forget; it does not shrink with the language-model quantisation, and it is charged once per loaded model • Context — up to 262,144 tokens on paper; each token of KV cache is extra memory the model card does not budget

A Q4 build with the 16× projector lands near 1.8 GB of weights. Add a working KV cache for a few thousand tokens of conversation and image placeholders, and you are asking an app for something in the 2.2–2.8 GB range. On a 12GB Pro Max that is comfortable. On an 8GB iPhone, where the operating system and every other resident app are already competing for the same pool, an app that asks for 2.5 GB is asking for a large fraction of what is left. iOS will grant it, or it will jetsam the app under pressure.

Why the RAM line on an iPhone is the real specification

Apple does not publish iPhone RAM in its marketing specifications, and it has never encouraged developers to treat the phone as a memory-addressable computer. That is the constraint the "beyond the 12GB Pro Max" claim runs into. The Pro Max tier has, for several generations, carried more memory than the standard models, and the gap between "the phone in the review video" and "the phone in a reader's pocket" is precisely the gap this model's on-device story depends on.

The honest version of the claim is narrower and still interesting: a 1B vision model that used to require a laptop or a flagship phone now fits inside the memory budget of a mid-range phone, if you use a 4-bit quantisation and accept a shorter context. That is a genuine step down in hardware class. It is not the same as "runs on every iPhone," and the difference is worth stating plainly because it decides whether a reader can ship the thing.

The model card does not settle it. It documents iOS, Android and HarmonyOS support, day-0 chip support from Rockchip, Houmo, Intel, AMD and Arm, and links to an edge deployment repository with apps and source. Nowhere does it list minimum device memory, a tested device matrix, or a per-device token rate for the 1B. The one device named in the 1B's own demo assets is an iPhone 17 Pro Max — the same device as the 35B headline.

What the model is actually good at, at 1B

The reason this is worth the memory arithmetic is that a 1B model doing document and screen understanding on a phone is a different product category from a chatbot. It means a receipt, a form, a menu, a label or a screenshot can be turned into structured text without a network round trip — no upload, no per-image cost, no latency floor set by a cell tower.

OpenBMB's published 1B figures, all vendor-reported and none independently reproduced as of this writing, put OCRBench at 86.1, MathVista at 74.3, CharXiv Reasoning at 48.8, LongVideoBench at 53.4 and MotionBench at 54.55. The vendor's headline comparison is against Q​wen3.5 0.8B, which it says it beats on both overall score and inference efficiency, and against MiniCPM-V 4.6, which it says it improves on across core capabilities. Those are the vendor's own benchmarks, run by the vendor, and the model card presents them as charts rather than as a table with harness details.

Two architectural details matter more than the scores for anyone actually deploying this:

• Mixed 4×/16× visual token compression — the caller chooses per request whether an image becomes a detailed token sequence or a cheap one, so a receipt scan and a thumbnail can share a deployment • Intra-ViT early compression, borrowed from LLaVA-UHD v4 — visual tokens are cut inside the vision encoder rather than after it, which is what makes the 4× path affordable in the first place • Slicing — high-resolution images split into 448×448 tiles plus a low-resolution overview, with the slice count as a runtime parameter (the card recommends 36 for images, 1 for video) • Video sampling — max_num_frames defaults to 128, and stack_frames composites sub-frames into a grid, which is how a phone gets through a screen recording without holding every frame in memory

For the receipt use case the prompt mentions, the pipeline is: capture, downscale to something near 980 pixels on the long edge, run at 4× with a high slice count, and ask for structured output. The 4× path at 36 slices is the expensive setting; the 16× path is roughly a quarter of the tokens and is where the phone stays responsive. Whether 16× is enough to read a thermal receipt is a question only your own images can answer, and no published benchmark in the card reports OCR accuracy by downsample mode.

The gap between "demo" and "app"

Three things stand between a working demo and a shipping iOS app, and none of them are the model's weights.

The first is packaging. The model ships in Transformers, GGUF, AWQ, GPTQ and int4 formats. Only GGUF has a mature on-device runner on iOS — llama.cpp and its relatives — and only the GGUF repository carries the separate vision projector (mmproj) file that the multimodal path needs. If you start from the BF16 checkpoint expecting a single-file drop-in, you will discover the projector is a second artefact with its own size.

The second is thermal budget. A 1B model generating a few hundred tokens is a burst workload; a 1B model OCRing a 36-slice page is a sustained one. The vendor's demo GIF is a screen recording, not a thermal trace. No published figure in the card gives sustained tokens per second on any phone, which is the number that decides whether a scanning app feels instant on the third document or the thirtieth.

The third is the rest of your stack. On-device inference handles the image. It does not handle the part where you reconcile the extracted receipt against a ledger, escalate an ambiguous line to a larger model, or fall back when the phone is old enough that the app refuses to load the weights. That is the boundary where a router earns its place rather than replacing anything: OrcaRouter puts 200-plus hosted models behind one OpenAI-compatible endpoint at 0% markup, passing each provider's list price straight through, with automatic failover and a routing DSL for primary-and-fallback configurations. A phone-side extractor can hand its uncertain cases to a hosted vision model, and the same key carries both paths. MiniCPM-V 4.7 1B itself is not in that catalogue — it is a checkpoint you run yourself — so the router is the escalation path, not the way to call this model.

The quiet-release pattern, and why it keeps producing this confusion

MiniCPM-V 4.7 arrived without a launch event. The 35B-A3B repository appeared on October 6, 2026 with no model card at all — the card landed six days later alongside the dated release note. The 1B followed the same pattern: repository first, documentation second, community discovery throughout. In the gap, coverage fills in from whatever artefact exists, which is why early write-ups described a 35B MoE model and then had to be revised when the 1B and its card showed up.

This is not a criticism of OpenBMB's engineering. It is a description of how information about this model propagates, and it is the reason a claim like "runs on everyday iPhones" can travel faster than the memory figures that qualify it. The repository is the primary source. The card is the primary source. A developer's screenshot of an app working on their phone is a data point, not a specification.

What to do with this, concretely

If you have a Pro Max or an iPad. Download the Q8_0 GGUF and the 16× projector, run it through llama.cpp or Ollama, and test your own documents at both downsample settings. You will get a working local OCR and image-QA path within an afternoon, and the 1B is small enough that you can keep it resident alongside other apps.

If you have a standard iPhone. Start with Q4_K_M and the 16× projector, cap the slice count at something modest, and measure. The memory arithmetic says it should fit; the thermal and jetsam behaviour under sustained use is the part nobody has published. Test on the oldest device you intend to support, not the newest.

If you are building a product. Treat the on-device model as the fast path and a hosted model as the correctness path. The escalation is a routing decision, and building it in from day one is cheaper than retrofitting it after the first support ticket about a receipt the phone misread.

The claim that started this article — that a 1B multimodal model now runs on phones below the Pro Max tier — is plausible on the memory arithmetic and unproven on the published record. That is a normal state for a model this young, and it is a reason to test rather than to wait. The weights are Apache 2.0, the quantisations exist, and the only thing standing between you and an answer is an afternoon with your own hardware.

Bottom line: MiniCPM-V 4.7 1B is a real, documented, Apache-2.0 vision model that fits in roughly 1.8 GB at Q4 with its vision projector — small enough that mid-range phones are a credible target and not just the 12GB Pro Max. The vendor has not published a device matrix or a minimum-memory figure, and the "everyday iPhone" claim originates with a developer report rather than the model card. Test on your own device before you plan around it.