Best Ollama Vision Models by VRAM: 4GB to 192GB

The best Ollama vision model for most people is qwen3-vl:8b — a 6.1GB pull with a 256K-token context window that sits comfortably on a 12GB card. On 8GB, pull qwen3-vl:4b (3.3GB). On 24GB, qwen3.8:27b (18GB) is the newest flagship in the registry. And if your images are documents rather than photos, none of those is the right answer — pull glm-ocr (2.2GB) instead.

That last one is the pick most "best VLM" lists still miss, and the reason this page leads with a table rather than a ranking: the right Ollama vision model is a function of your VRAM and your input type, not a single winner. Every size, context window and pull count below reads from the ollama.com library pages in August 2026.

---

Which Ollama vision model fits your VRAM?

Find your VRAM, copy the pull command. The rule behind the table: budget the download size plus 1-2GB for the vision projector, image tokens and KV cache. The full memory math for every Ollama model — vision and text — lives in our Ollama RAM and VRAM requirements table.

Two edges worth calling out. At 24GB the 18GB qwen3.8 download is honest-but-planned: our Qwen3.8-27B VRAM breakdown puts the Q4_K_M weights at 17.11GB on disk and the mmproj-F16 vision projector at a further 0.93GB, which is exactly why the tier below it cannot run this model. And llama3.2-vision:11b (7.8GB) is a fair 12-16GB alternative if you want Meta's image reasoning specifically — but its image mode is English-only, per the Ollama model page. Spec detail on our Llama 3.2 11B Vision page.

For what else each tier can run beyond vision: 8GB VRAM picks, 12GB VRAM picks, 16GB VRAM picks.

---

Every Ollama vision tag that matters

Eleven tags, sorted by how recently Ollama updated them — because in this category that is the single most useful sort order. Figures read from the ollama.com library pages, August 2026.

Three things fall out of that sort.

The pull counts are a lagging indicator, not a ranking. llava has 14.7M downloads and has not been updated on Ollama in about two years. Most of those pulls came from 2023-2024 tutorials that all say ollama run llava somewhere, and the number keeps climbing on inertia.

Vision is no longer a separate model class. The most-pulled tag in Ollama's vision filter is gemma4 at 23.1M — a general-purpose family that happens to take images, with qwen3.5 (18.2M) and qwen3.6 (6.1M) close behind. If you already run one of those for text, you may not need a dedicated VLM at all; check whether your existing tag lists "Text, Image" as its input types before pulling a second model.

Context window separates the generations brutally. 2K on moondream and 4K on the larger llava tags is barely one detailed image plus a short conversation, while the 256K on qwen3-vl, qwen3.8 and minicpm-v4.6 swallows whole document batches.

If you are comparing this category with image generation (Stable Diffusion, Flux), that is a different toolchain entirely — our local image generation comparison covers that side. This page is about models that look at images: captioning, OCR, charts, screenshots, photos.

---

Which Ollama vision model is best for OCR and documents?

glm-ocr, and it is not close on size. It is a 0.9B multimodal OCR model built on the GLM-V encoder-decoder architecture, aimed specifically at text recognition, table recognition and figure recognition. Its Ollama model page claims first place overall on OmniDocBench V1.5 with a score of 94.62 — that is Z.ai's own reported number, not an independent evaluation, so treat the margin as directional. At a 2.2GB download it fits alongside a general-purpose model on a single 8GB card, which is the practical argument for it.

The runner-up is minicpm-v4.5: 8B params, a 6.1GB download, a 40K context window, and OpenBMB's reported 77.2 average on OpenCompass with leading OCRBench results. Again, the maker's own figures. It handles images up to 1.8 megapixels and supports 30+ languages, so it is the better pick when the documents are multilingual or when you need reasoning about the page rather than transcription of it.

Note what has changed here since most "best local VLM" articles were written: Ollama's MiniCPM tags are no longer stuck on 2.6. The registry now carries minicpm-v4.5 (8B) and minicpm-v4.6 (1B) as separate tags. The plain minicpm-v tag still resolves to version 2.6 with a 32K context window and 5.4M pulls, and it is still a capable document model, but it is a year behind its own family. Spec sheet on our MiniCPM-V model page.

Whichever you choose, the input is still an image. Ollama does not read PDF files — convert each page to a PNG first with pdftoppm or pymupdf, then pass the images.

---

Minimum Ollama version by model

This table exists because the single most common failure in this category is not VRAM — it is an Ollama install that is too old to pull the model at all. Minimum versions as stated on each model's Ollama page:

The error text is fixed and worth recognising: Error: pull model manifest: 412: The model you are attempting to pull requires a newer version of Ollama. — that exact string appears in ollama/ollama issue #8107. A related variant, 412: this model requires macOS, is what you get pulling an MLX-only tag on Linux or Windows. Neither is a network problem and neither is fixed by retrying; both mean update Ollama from ollama.com/download. The 0.32.x line was current as of August 2026.

---

Model notes: what each family is actually for

Qwen3.8-27B — the current flagship

Ollama's qwen3.8:27b tag is 18GB, q4_K_M, 256K context, text and image input. It is a dense 27B vision-language model from Alibaba Qwen, released August 2026 under Apache 2.0, with a hybrid Gated DeltaNet and Gated Attention layout and a native 262,144-token context that extends toward 1M with YaRN. The catch is that there is no small version: Qwen shipped the 27B, its FP8 twin, a 2.4T-A95B MoE and that MoE's FP8 twin, and nothing else — so either you clear roughly 17GB or you are not running Qwen3.8. Ollama's tag list is short (18GB default, 30GB q8_0, 32GB mxfp8, 56GB bf16); anything smaller means pulling a GGUF outside the registry. Full quant-by-quant memory table on our Qwen3.8-27B VRAM page.

Qwen3-VL — the family that scales

Released October 2025 (4B/8B on the 15th, 2B/32B on the 21st, per the Qwen GitHub repo), Qwen3-VL is still the answer to "give me one family that covers every card I own." Native 256K context expandable to 1M, OCR coverage expanded from 10 to 32 languages, and six sizes from a 1.9GB download to a 143GB one. Qwen publishes its benchmark comparisons as charts rather than tables, so there are no precise scores to quote here; the verifiable facts are the context window, the language coverage, and that its 5.4M Ollama pulls accumulated in under a year against competitors that had been sitting in the registry for two. Install walkthrough: Qwen3-VL local setup guide.

MiniCPM-V — the document family

MiniCPM-V 2.6, the version behind Ollama's 5.4M-pull minicpm-v tag, scores 65.2 average on OpenCompass across 8 benchmarks, and OpenBMB reports state-of-the-art OCRBench results — surpassing GPT-4o, GPT-4V and Gemini 1.5 Pro (their claims, from the official model card). The engineering behind it: a 1.8-megapixel image encodes into just 640 tokens, about 75% fewer than most VLMs, which is why an 8B model handles dense documents on modest VRAM. The family has moved on twice since — 4.5 (8B, 77.2 OpenCompass) and 4.6 (1B, built on SigLIP2-400M plus Qwen3.5-0.8B with mixed 4x/16x visual token compression) — and both now have their own Ollama tags.

GLM-OCR — the narrow specialist

0.9B params, 2.2GB, 128K context, 7M pulls, three tags (latest, q8_0 at 1.6GB, bf16). It does one job — turning document pages into structured text, tables and figures — and it is small enough that keeping it loaded costs almost nothing. If your pipeline is invoices, receipts, scanned reports or screenshots of text, this is the tag to reach for before any general VLM.

Llama 3.2 Vision — fine, with an asterisk

11B (7.8GB) and 90B (55GB) tags, 128K context, solid image reasoning — but image-plus-text works in English only, per the Ollama model page, even though text-only mode covers German, French, Italian, Portuguese, Hindi, Spanish and Thai. The family has not moved in about a year. The 90B tag is the main reason to care: at 55GB it is one of the few big open VLM options between the 21GB and 143GB Qwen tags. Spec breakdown on our Llama 3.2 11B Vision page.

Qwen2.5-VL — superseded by its own family

Still a competent line (3B/7B/32B/72B, 125K context, 4.5M pulls), and the 72B tag (49GB) is the largest Qwen vision option below the 143GB flagship. Its model page also advertises capabilities the newer tags describe less loudly: bounding-box and point-coordinate localisation, and structured output from invoices and forms. But at every size below 72B, qwen3-vl matches or beats it with a newer architecture and a longer context.

Moondream — the tag that time forgot

The moondream tag is a roughly two-year-old snapshot of a 1.8B model with a 2K context window. Ollama's own page for it carries the developers' warning that the model may "generate inaccurate statements, and struggle to understand intricate or nuanced instructions." The upstream project has kept moving and the moondream2 model card on Hugging Face self-reports far stronger document numbers than that snapshot implies — but those describe the current build, not what Ollama serves. If you want a sub-2GB VLM today, minicpm-v4.6 (1.6GB, 256K context, two months old) is the better pull; get moondream from the project directly if you specifically need it.

---

Still running llava? What to pull instead

If you searched "llava alternatives," here is the direct answer: replace llava:7b with qwen3-vl:4b. Smaller download (3.3GB vs 4.7GB), a 256K context window against 32K, OCR across 32 languages, and a 2025 architecture against LLaVA 1.6's — which Ollama last updated about two years ago.

LLaVA earned its 14.7M pulls honestly; it was the model that made local vision real. But its larger tags (13b, 34b) carry a 4K context window — one detailed image plus a short conversation and you are out — and OCR was never its strength. There is no VRAM tier at which a LLaVA tag is the best available pick today. The one defensible reason to keep it installed is reproducing an old pipeline built against its output format.

---

How do you run a vision model in Ollama?

Install is the same as any Ollama model; passing an image is just a file path in the prompt.

ollama pull qwen3-vl:8b        # 6.1GB; use qwen3-vl:4b on 8GB cards
ollama run qwen3-vl:8b "What's in this image? ./photo.png"

The CLI detects the path and confirms with an Added image line before answering. For scripts, the REST API takes base64-encoded images in an images array, per Ollama's API documentation:

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3-vl:8b",
  "prompt": "Describe this image.",
  "images": ["<base64-encoded image>"],
  "stream": false
}'

If the pull fails before it downloads anything, check the version table above — a 412 is a runtime problem, not a network one.

From here the practical applications write themselves; a favourite is security cameras that describe what they see, via Frigate plus Ollama.

---

Why do small vision models describe instead of read?

Below roughly 4B parameters, "vision" in practice means captioning, not transcription — and the clearest reason is arithmetic, not vibes.

OpenBMB publishes the number that makes this concrete: MiniCPM-V encodes a 1.8-megapixel image into 640 tokens, which they describe as about 75% fewer than most VLMs. Take that as a generous floor for how much context one high-resolution image costs. Now look at moondream's 2K context window, or the 4K on llava:13b. One dense image can consume a quarter to a third of the entire window before the model has written a word, and a full page of transcribed text — several hundred words — has to fit in what is left along with your prompt. A 256K window has no such problem; a 2K window structurally cannot do document transcription, regardless of how good the vision encoder is.

The vendors say the quiet part themselves. Ollama's moondream page carries the developers' own caution that the model may "generate inaccurate statements, and struggle to understand intricate or nuanced instructions." And the existence of glm-ocr — a 0.9B model built and benchmarked only for documents, claiming the top OmniDocBench V1.5 score — is the strongest available evidence that general-purpose VLMs at small sizes are not the tool for reading text. If they were, nobody would ship a dedicated 0.9B OCR model.

The practical rule: if a number on the image matters, do not use a sub-4B general VLM to read it. Use glm-ocr or minicpm-v4.5 for text, qwen3-vl:8b or larger for reasoning about a scene, and reserve the tiny tags for high-frequency captioning on edge hardware where speed is the whole point.

---

Honest limitations

Local VLMs in 2026 are genuinely good at describing, decent at reading, and still unreliable at precise extraction. Know these before building on them:

• Every headline benchmark on this page is vendor-reported. OmniDocBench 94.62, OpenCompass 77.2 and 65.2, the OCRBench claims — all come from the model makers' own cards. There is no independent local-hardware evaluation behind them and you should not treat the margins between models as precise.
• Ollama tags lag upstream, unevenly. The plain minicpm-v tag still serves 2.6 while 4.5 and 4.6 have their own tags; moondream serves a snapshot far behind the current project build. The tag name tells you the family, not the freshness.
• No native video in the image API. Ollama's image input takes stills; video means extracting frames yourself first. Some newer families document video input upstream, but that is not what the /api/generate images array does.
• Counting and spatial precision remain weak spots across open VLMs — "how many people are in this photo" answers deserve suspicion at every model size.
• VRAM math has overhead beyond the download. The vision projector alone is 0.93GB for Qwen3.8-27B, and image tokens eat context. A model that "fits" with 200MB to spare will crawl or fall back to CPU once a large image lands.

None of this argues for a cloud API. It argues for matching the model to the job: a 3.3GB qwen3-vl:4b covering most everyday image understanding, free, offline, on hardware you already own, is the actual story here.

---

Sources

• Ollama model library — pull tags, download sizes, context windows, pull counts and minimum-version notes for gemma4, qwen3.8, qwen3-vl, glm-ocr, minicpm-v / v4.5 / v4.6, llama3.2-vision, qwen2.5vl, llava and moondream (read August 2026)
• ollama/ollama issue #8107 — the verbatim pull model manifest: 412 upgrade-required error text
• Qwen3-VL GitHub repository — release dates, context window, OCR language coverage
• MiniCPM-V 2.6 model card and MiniCPM-V 4.5 model card — OpenCompass scores, 640-token image encoding, OCRBench claims (OpenBMB's own numbers)
• moondream2 model card — current-revision self-reports, which describe the upstream build rather than the Ollama snapshot
• Ollama API documentation — base64 image input format
• Our Qwen3.8-27B quant and VRAM breakdown — GGUF file sizes and the 0.93GB vision-projector figure, sourced from Unsloth's published builds

---

FAQ