MiniCPM-V: Phone-Class Vision AI for 6-8GB VRAM (and Why the Default Tag Is a Trap)

The version trap: minicpm-v is not the latest MiniCPM-V

The Ollama model called minicpm-v — 5.4M pulls, one of the most-downloaded vision models in the entire library — was last updated over a year ago and serves MiniCPM-V 2.6, released in 2024. OpenBMB never updated that listing. When 4.5 and 4.6 arrived, they were published as separate models: minicpm-v4.5 (22.6K pulls as of August 2026) and minicpm-v4.6 (added to the official Ollama library around June 2026; 29.3K pulls and already ahead of 4.5).

The practical consequence: almost everyone who typed ollama run minicpm-v this year got a model two generations behind — 65.2 on OpenCompass versus 77.0 for v4.5, per OpenBMB's own numbers. That is not a subtle difference. v2.6 was pitched against GPT-4o mini and Claude 3.5 Sonnet; v4.5 is pitched against GPT-4o-latest and Qwen2.5-VL 72B.

This page uses the versionless URL deliberately: OpenBMB ships roughly two versions a year, and the advice here is organized so the matrix below stays useful when v5 lands. The project itself is one of the larger open-vision efforts around — about 26K GitHub stars on OpenBMB/MiniCPM-V as of August 2026.

Version matrix

Three versions matter in August 2026: v2.6 (legacy default), v4.5 (quality pick), v4.6 (efficiency pick). Everything below is from OpenBMB's model cards and the Ollama library listings.

Sources: OpenBMB model cards and changelog; Ollama library, August 2026.

The interesting design choice in 4.6: instead of scaling up, OpenBMB scaled down — a 1B-class model with mixed 4x/16x visual-token compression that they say cuts visual-encoding FLOPs by more than half and delivers ~1.5x the token throughput of its own Qwen3.5-0.8B base. It is a different tool than 4.5, not a replacement: think "good-enough vision everywhere" versus "best vision an 8GB card can hold." OpenBMB also maintains a MiniCPM-o omni sibling that adds speech in and out; it is not in the Ollama library.

VRAM requirements

Plan for 8GB of VRAM to run the 8B versions comfortably. On 6GB, drop to a smaller quant or accept partial CPU offload. v4.6 fits nearly anywhere. The sizing rule: start from the download size and add roughly 1-1.5GB for the vision projector and the KV cache. minicpm-v4.5 ships as a 6.1GB download, so budget about 7-7.5GB resident at a normal context length — which is why an 8GB card is the comfortable floor and a 6GB card is not. Check the real number for your own setup with ollama ps, which prints resident size and whether the model landed 100% on GPU.

Ollama's minicpm-v4.5 ships two tags (latest and 8b, both 6.1GB) — no quant ladder. If you want to pick your own quant, OpenBMB publishes the full GGUF set on Hugging Face (openbmb/MiniCPM-V-4_5-gguf); file sizes below are from that repo:

File sizes: openbmb/MiniCPM-V-4_5-gguf on Hugging Face. Card recommendations are our guidance.

If you are right on the 6GB line — a GTX 1660, RTX 2060, or laptop 3060 — the 8B models nearly fill the card at Q4. Take v4.6 instead and keep headroom, or check what else runs well on 6GB VRAM. On Apple Silicon, unified memory makes this easier: a 16GB M-series Mac has room for v4.5 at ~7GB resident alongside the OS, and 18GB or more leaves space to keep a text model loaded at the same time.

Ollama setup

One gotcha first: 4.5 and 4.6 require a current Ollama build. An older runtime will pull the classic minicpm-v without complaint and then refuse minicpm-v4.6 outright, telling you to download the latest version. The newer SigLIP2/Qwen3-era architectures need runtime support older binaries do not have, so the registry declines rather than handing over a file the runner cannot open. Update first, then it is two commands — Ollama handles the vision projector automatically, no separate CLIP download:

# Quality pick (8GB+ VRAM):
ollama run minicpm-v4.5 "What's in this image? ./invoice.png"

# Efficiency pick (anything, even CPU):
ollama run minicpm-v4.6 "Transcribe the text in ./receipt.jpg"

Want a specific quant? The Ollama listing only carries the default, but you can run OpenBMB's GGUF builds straight from Hugging Face using Ollama's standard hf.co/ syntax:

ollama run hf.co/openbmb/MiniCPM-V-4_5-gguf:Q4_K_M

Via the API (for scripts and apps)

curl http://localhost:11434/api/chat -d '{
  "model": "minicpm-v4.5",
  "messages": [{
    "role": "user",
    "content": "Extract every line item and total from this receipt as JSON.",
    "images": ["<base64-encoded image>"]
  }]
}'

Real uses for this class of model: receipt and invoice extraction, screenshot-to-text for documentation, alt-text generation, photo-library sorting — the jobs covered in our local AI vision tasks guide. A model this light also suits always-on camera analysis; see the Frigate + Ollama AI cameras setup.

How fast will it be on your hardware?

You can bound this arithmetically without running anything. Token generation is memory-bandwidth bound — the machine reads roughly the whole model once per token — so the ceiling is your memory bandwidth divided by the model size. We have not benchmarked this model, so what follows is calculation rather than measurement, and it is an upper bound: attention, the vision encoder pass and framework overhead all take a cut, and real output lands well below the ceiling.

throughput ceiling (tok/s) = memory bandwidth (GB/s) / model size (GB)

minicpm-v4.5 = 6.1 GB   ·   minicpm-v4.6 = 1.6 GB

Bandwidth figures from NVIDIA and Apple specification pages; model sizes from the Ollama library. Ceilings are division, not benchmarks. The v4.6 column in particular is optimistic — at 1.6GB the model stops being bandwidth-bound and becomes overhead-bound, so treat those figures as "fast enough that the number stops mattering".

For the number that actually applies to you, run it and read the eval rate:

ollama run minicpm-v4.5 --verbose "Describe this image: ./receipt.jpg"
ollama ps   # resident size, and whether it is 100% GPU

The practical shape of it: on any modern discrete GPU an 8B-class vision model reads a document image and emits structured JSON in single-digit seconds, and the interesting constraint is accuracy on fine print rather than speed. That is the honest pitch for this family — local document extraction at zero API cost, with nothing leaving the machine.

Benchmarks

v4.5's headline number is a 77.0 OpenCompass average across 8 benchmarks — which OpenBMB says beats GPT-4o-latest, Gemini-2.0 Pro, and Qwen2.5-VL 72B — from a model that fits on an 8GB card. These are the vendor's published figures, so read them the way you read any model card: directionally real, best-case framing. We have not reproduced them independently.

Two claims worth pausing on. First, "beats Qwen2.5-VL 72B" is an aggregate-average claim — a 72B model will still win plenty of individual hard cases, especially dense charts and long documents. Second, the video numbers come from OpenBMB's own inference stack with the 96x compression pipeline, which you cannot reproduce through Ollama (see limitations). Even discounting both, the 11.8-point OpenCompass jump over v2.6 (65.2 → 77.0) is the gap that matters: v2.6 is what most of those 5.4M pulls actually installed, and v4.5 is a straight upgrade at the same VRAM cost.

MiniCPM-V vs Qwen3-VL

Pick MiniCPM-V 4.5 for the best single-model result on one 8GB card; pick Qwen3-VL when you want a family that scales with your hardware. This is the comparison most people are actually making in 2026, and it is closer than the pull counts suggest — the two overlap more than the branding implies, since MiniCPM-V literally uses Qwen LLMs as its language backbone.

• •Capability ceiling: Qwen's larger vision variants win outright. MiniCPM-V's counter is efficiency — OpenBMB reports 4.5 (8.7B) beating the previous-generation Qwen2.5-VL 72B on the OpenCompass average.
• •Footprint: nothing in the Qwen vision lineup touches minicpm-v4.6's 1.6GB with a 256K context window.
• •Ecosystem: Qwen has broader tooling and sizes, so your prompts survive a hardware upgrade; MiniCPM-V has the only first-party iOS/Android/HarmonyOS deployment story.

We cover the other side in depth — our Qwen 3 VL local setup guide walks through qwen3-vl:7b, the direct size-class rival to minicpm-v4.5. If you have the VRAM for either, run both on your actual documents for an afternoon; on OCR-heavy work the differences are smaller than the benchmark deltas imply. Against older options, 4.5 makes Qwen2-VL 7B and Llama 3.2 11B Vision hard to recommend for new installs — same VRAM class, older results.

Honest limitations

• !The video capability mostly does not survive Ollama. Ollama's API passes still images, so the 96x-compression, 10FPS pipeline behind the Video-MME score needs the inference paths OpenBMB documents in its repo. Through Ollama, multi-frame work is manual: extract frames with ffmpeg and send several stills per request.
• !Needs a current Ollama for 4.5/4.6. Older runtimes refuse the pull entirely rather than failing at load time. Home servers running a pinned Ollama version need an upgrade first.
• !Fine print on low-contrast backgrounds is the weak spot. Small text against busy or dark backgrounds is where OCR in this size class degrades first, and improving it is one of the things OpenBMB says it targeted in the 4.x line. Budget a verification pass when extracting from dashboard screenshots or dark-mode UIs.
• !Benchmark claims are vendor-published. "Beats GPT-4o-latest" is OpenBMB's claim on one benchmark suite, not a general-capability statement. On open-ended visual reasoning, frontier hosted models remain clearly ahead.
• !The naming will bite again. Roughly two releases a year, each under a new Ollama name, while the 5.4M-pull default stays frozen. Whatever tutorial you follow, check which tag it pulls. (Also odd: flagship 4.5 carries the family's shortest context at 40K, while tiny 4.6 gets 256K.)

Frequently asked questions