Best Local Vision Model for Mac (2026), by RAM Tier

The picks by RAM tier

A vision model needs more memory than its weights. The image encoder ships as a separate projector file — the mmproj — that loads beside the language model, so the table counts both, at 4-bit unless noted. Each speed is the index’s figure for the named Mac, with its provenance mark.

File sizes are from the Hugging Face repos linked in each section (decimal GB, checked 18 October 2026). Leave a few gigabytes for the context window and macOS on top.

8 GB: Gemma 4 E4B, or E2B for headroom

Gemma 4 E4B is the safest pick for 8 GB. Google’s card lists image and audio input, a 128K window and an MMMU Pro score of 52.6%, under Apache 2.0. The ggml-org Q4_0 file is 4.59 GB and its Q8_0 projector 0.56 GB, about 5.2 GB together. That runs on an 8 GB Mac with other apps closed, and the index estimates estimated~23 tok/s on an M1 MacBook Air.

If memory is tighter than that, Gemma 4 E2B needs about 3.4 GB with its projector (estimated~44 tok/s on the same Air). Ollama’s own gemma4:e4b and gemma4:e2b downloads are larger (from 6.6 and 4.6 GB), so on 8 GB the plain GGUF files in llama.cpp or LM Studio leave more room.

Ternary Bonsai 2 9B is the outlier: Prism ML’s ternary rebuild of Qwen3.5-9B, Apache 2.0, with a 0.62 GB projector. Its card says upstream llama.cpp runs only the Q2_0 file (2.56 GB); the PQ2_0 and PTQ1_0 packs need Prism’s fork. The only published speed is Prism’s: sourced76.5 tok/s on an M5 Pro MacBook Pro (PQ2_0, tg128, from its whitepaper). Ternary decoding is limited by its kernels rather than by bandwidth, so the index does not stretch that figure to an 8 GB Mac. Prism has published no vision scores for the ternary build.

16 GB: Gemma 4 12B

Gemma 4 12B is the dense middle of Google’s family: text, image and audio input, a 256K window, Apache 2.0. Its Q4_0 GGUF is 7.22 GB and its projector only 0.16 GB, which leaves a 16 GB Mac room for long documents; Ollama’s gemma4:12b is 7.7–8.0 GB. The index’s figure for a 32 GB Mac mini M6 is community19 tok/s, and it estimates estimated~17 tok/s for the 16 GB M6, whose binned memory runs at 153 GB/s instead of 170.

Ternary Bonsai 2 27B is the alternative for anyone on Ollama 0.40.6 or later (bonsai-2:27b, 8.3 GB, image input) or mlx-vlm 0.7.8. It packs Qwen3.8-27B, the index’s strongest dense model, into 7.21 GB (PQ2_0) plus a 0.63 GB projector. PrismML reports its 5.95 GB PTQ1_0 pack keeps 98% of the base model’s average on its 14-benchmark suite. The drop is largest on agentic coding (SWE-bench Verified 60.8 against 80.6, mini-swe-agent, vendor-run) and on vision: MMMU-Pro 75.49 against 81.73 and OCR Bench v2 56.88 against 60.99 (vendor-reported). The model card is blunt about runtimes: stock llama.cpp will not run these files. Prism’s published speeds are sourced28.1 tok/s on an M5 Pro and sourced46.8 tok/s on an M5 Max (tg128).

24–32 GB: MiniCPM-V 4.7 35B-A3B

MiniCPM-V 4.7 35B-A3B is OpenBMB’s first mixture-of-experts vision model: Apache 2.0, with single-image, multi-image and video input. Only about 3B parameters are active per token, so it decodes like a small model. Community oMLX runs measured community100.2 tok/s on an M5 Max (MXFP4) and community48.2 tok/s on an M4 Pro (5-bit, multi-token prediction off), and the index estimates estimated~37 tok/s on a Mac mini M6.

In OpenBMB’s own comparison it leads the other vision models a 24–32 GB Mac can hold on documents, OCR and charts:

The last two rows cut the other way. On ScreenSpot — finding the right button in a screenshot — Qwen3.8-27B and Qwen3.6-35B-A3B both beat it, and Qwen3.8-27B also leads MathVision. For a computer-use agent, Qwen3.8-27B is the better eye. It is dense, though, so it is much slower: community9 tok/s on a Mac mini M6 and estimated~15 tok/s on an M5 Pro, against MiniCPM-V’s estimated~59 tok/s on the same M5 Pro. Its Q4_K_M is 18.97 GB plus a 0.63 GB projector.

Gemma 4 26B-A4B is the light, fast option: 14.62 GB at Q4_0 plus a 0.81 GB projector, image input, and community48 tok/s on a 32 GB Mac mini M6. OpenBMB’s chart does not include it. For text and coding picks at this tier, see the 24–32 GB guide.

48–64 GB: the same models, at 8-bit

No image-capable model in the catalog that needs 32–64 GB ranks above MiniCPM-V 4.7 on the LLMCheck Score, so the extra memory is better spent on precision. MiniCPM-V 4.7 at Q8_0 is 36.9 GB plus its projector, and Qwen3.8-27B at Q8_0 is 28.6 GB. Eight-bit reads about twice the bytes per token, so expect roughly half the 4-bit speed: one community run measured Qwen3.8-27B at community17.9 tok/s on an M5 Max at 8-bit, where the index’s 4-bit estimate is estimated~29 tok/s.

96–128 GB: Nemotron 3.5 Super VL

NVIDIA released Nemotron 3.5 Super VL 120B-A12B on 15 October under OpenMDW-1.1: a 120B hybrid Mamba-Transformer mixture of experts with 12B active, text, image and video input, and a 1M-token window. lmstudio-community’s Q4_K_M is 70.1 GB plus a 1.73 GB projector, so it needs a 96 GB Mac and is comfortable on 128 GB.

The index’s only run is community-measured: community30.6 tok/s on a 128 GB M5 Max at NVFP4 in mlx-vlm with multi-token prediction off. With MTP on, the same run reached 57.1 tok/s, a different workload that the index does not list. Both come from the pull request that added the model, mlx-vlm #2528, merged on 16 October. It is on the main branch but not yet in a tagged release; the latest, 0.7.8, shipped on 13 October. NVIDIA’s card lists OCRBench v2 (English) 68.12, CharXiv reasoning 80.82 and MathVision 78.16 on its own harness, so those numbers don’t line up cell for cell with OpenBMB’s table.

One trap: in llama.cpp on a Mac, skip the NVFP4 GGUF. Metal has no NVFP4 matrix-multiply kernel, so those layers fall back to the CPU on every token (llama.cpp issue #30610). Use Q4_K_M. The Nemotron 3.5 on a Mac post covers the setup in detail.

Three alternatives fit the same Macs:

• Qwen3.8-Flash-Next takes images and video natively. It needs the 128 GB tier (4-bit MLX is 112 GB) and runs at community44 tok/s on an M5 Max. It scores higher on the LLMCheck index than Super VL (66 against 61) on the strength of its language and coding. Its Qwen Community licence requires a separate commercial licence for model-as-a-service and ‘AI Work Assistant’ products.
• Qwen 3.5 122B-A10B is the Apache 2.0 choice: image and video input, about 65 GB at 4-bit, community43 tok/s on an M5 Max.
• Mistral Medium 3.5 is a dense 128B with image input: 74.9 GB at Q4_K_M plus a 5.4 GB projector. It is slow. Apple’s MLX benchmark measured sourced7.70 tok/s on an M5 Ultra and sourced4.95 tok/s on an M3 Ultra at FP8, and the index estimates estimated~7 tok/s on an M5 Max at 4-bit. Its modified MIT licence voids the grant for companies above $20M in monthly revenue.

192–512 GB: MiMo-V2.6-Flash and Muse Spark Open

MiMo-V2.6-Flash (Xiaomi, MIT) is #1 on the LLMCheck leaderboard, and it takes text, image, video and audio. Its 4-bit MLX builds are about 172 GB, so it starts at a 192 GB Mac Studio. Two community runs measured community59 tok/s on a 256 GB M3 Ultra (4-bit, MTP off), and the index estimates estimated~79 tok/s on an M5 Ultra. The index holds no independent vision comparison for it.

Muse Spark Open (Meta, 816B-A42B, Muse Model License) also takes text, image, video and audio. llama.cpp supports its text, image and audio input (PR #30616, build b11671 and later), whose author tested it on an M3 Ultra; video input is not listed. ggml-org’s Q2_K is 304.1 GB plus a 2.2 GB Q8_0 projector. Hugging Face’s launch post reports sourced18 tok/s at Q2_K in llama.cpp and sourced21 tok/s at oQ3e in MLX on a 512 GB M3 Ultra. The 1T-parameter Kimi K2.5, K2.6 and K2.7 Code also take images, but each needs 417 GB or more. For the full Mac setup, see Muse Spark Open on a Mac; for everything else that fits, the 512 GB table.

Setup: llama.cpp, MLX and Ollama

llama.cpp. A vision model is two files: the language model and its projector. With -hf, llama.cpp downloads both; with local files, pass the projector with --mmproj, as its multimodal docs describe. MiniCPM-V 4.7 needs build b11551 or later, the first to include PR #29416 (10 October).

# Gemma 4 12B: model and projector in one step
llama-server -hf ggml-org/gemma-4-12B-it-GGUF:Q4_0

# MiniCPM-V 4.7 from local files (openbmb/MiniCPM-V-4.7-35B-A3B-gguf)
llama-server -m MiniCPM-V-4_7-35B-A3B-Q4_K_M.gguf --mmproj mmproj-model-f16.gguf

Then attach images in the server’s web UI, or send them to its OpenAI-compatible /v1/chat/completions endpoint.

MLX. mlx-vlm added MiniCPM-V 4.7 in version 0.7.8 (13 October):

pip install -U mlx-vlm
mlx_vlm.generate --model mlx-community/MiniCPM-V-4.7-35B-A3B-mxfp4 \
  --max-tokens 400 --prompt "Extract this table as Markdown." --image invoice.png

That MXFP4 build is 22.5 GB, so it wants a 32 GB Mac. For Nemotron 3.5 Super VL, install mlx-vlm from its main branch (pip install -U git+https://github.com/Blaizzy/mlx-vlm.git) until a release includes PR #2528.

Ollama. OpenBMB publishes its own namespace; Gemma 4 is in the main library:

ollama run openbmb/minicpm-v4.7      # 35b-a3b, Q4_K_M, 22 GB
ollama run gemma4:12b                 # 7.7–8.0 GB

At the Ollama prompt, include the image’s file path in your message and Ollama attaches the image.

Known issues

• MiniCPM-V box coordinates in llama.cpp. Upstream llama.cpp numbers MiniCPM-V 4.7’s image-marker tokens like plain text. That shifts the layout the model sees, so coordinates it returns come out too low. The fix, PR #30510, was still open on 18 October; its author’s 18-question box test went from 3 hits on master to 15 with the patch. It matters when you ask for boxes or click targets, and apps that bundle llama.cpp inherit it until they update.
• Ternary Bonsai needs Prism’s fork for its PQ2_0 and PTQ1_0 packs. Upstream llama.cpp rejects both; from b11556 it runs only the Q2_0 packing (the 9B’s Q2_0 file, and the 27B’s in PrismML’s -dev repo), which Ollama 0.40.6+ also uses.
• NVFP4 GGUFs on Metal fall back to the CPU, as above. Prefer Q4_K_M in llama.cpp, or an MLX build.
• Nemotron 3.5 Super VL in MLX is on mlx-vlm’s main branch only, as of 18 October.

How these picks were made

The LLMCheck Score rates language capability, speed, memory and licence. It has no vision component. So these picks start from the catalog’s image-capable models and keep those whose model card confirms image input and that run on a Mac. Each RAM tier is then ranked on the vendors’ published vision scores, the index’s speed figures and the licence. Memory figures are file sizes from the linked Hugging Face repos. Every speed carries its provenance: a filled square is a published figure, a hollow circle is one person’s run, and a hollow diamond is the index’s bandwidth estimate. LLMCheck runs no tests of its own.

Frequently Asked Questions