Gemma 4 on Mac: Variants, Modalities and Memory Planning

As of August 15, 2026. Gemma 4 is an open model family from Google DeepMind with five sizes: E2B, E4B, 12B, 26B A4B and 31B. The largest variant does not fit every Mac. Unified memory, context, image/audio input and the number of applications running in parallel determine the fit.

Candidates by unified memory

Mac	First candidate	Why
8 GB	gemma4:e2b	7.2 GB package, but very little room for context and apps
16 GB	gemma4:e4b or gemma4:12b	Q4 can start, but keep context controlled, close large apps and expect little headroom
24 GB	gemma4:12b	more headroom than 26B; suitable local starting point
32 GB	gemma4:26b with bounded context	18 GB package, MoE with 3.8B active parameters
48 GB+	gemma4:31b or 26b	20 GB or 18 GB package, more room for context

Ollama package size and actual memory use are not the same. KV cache, runtime, images, macOS and background applications add to the working set.

Current Ollama tags

When checked on August 15, 2026, Ollama listed these local tags among others:

Tag	Package size	Context	Input
gemma4:e2b	7.2 GB	128K	text, image
gemma4:e4b	9.6 GB	128K	text, image
gemma4:12b	7.6 GB	256K	text, image
gemma4:26b	18 GB	256K	text, image
gemma4:31b	20 GB	256K	text, image
gemma4:e2b-mlx	6.5 GB	128K	text, image
gemma4:e4b-mlx	8.8 GB	128K	text, image
gemma4:12b-mlx	7.7 GB	256K	text, image
gemma4:26b-mlx	18 GB	256K	text, image
gemma4:31b-mlx	19 GB	256K	text, image

The current Ollama list shows the MLX tags with text and image input; audio is not listed in those tag details. Check the exact client before building an audio workflow around a specific backend.

Install and start Gemma 4

# lighter starting point
ollama pull gemma4:e4b
ollama run gemma4:e4b

# 12B: a larger variant at a moderate package size
ollama pull gemma4:12b
ollama run gemma4:12b

For larger Macs:

ollama pull gemma4:26b
ollama run gemma4:26b

ollama pull gemma4:31b
ollama run gemma4:31b

An image can be passed through the Ollama app or a compatible client together with a question. The model does not make every frontend multimodal automatically; the client must support image input.

What Google documents about the variants

The current Google model card lists five sizes. The launch post gives a four-size overview and mentions native audio input for E2B and E4B; the current model card is therefore the source for the additional 12B detail.

Google’s model card describes:

• E2B and E4B as small models with 128K context;
• 12B and 31B as dense variants with 256K context;
• 26B A4B as an MoE model with 25.2B total and 3.8B active parameters;
• text and image processing across the family;
• native audio support on E2B, E4B and 12B;
• configurable thinking modes and native function-calling support.

The audio statement comes from Google. A model supporting audio does not automatically mean that the Ollama tag or your client accepts an audio file. Verify that connection separately.

Memory limits for 12B, 26B and 31B

gemma4:26b may start on a 24 GB Mac, but an 18 GB package leaves little room for the operating system, runtime and context. For a cautious local starting point, gemma4:12b is therefore the more defensible choice.

On 32 GB, 26B fits better with bounded context. 31B dense is listed at 20 GB and needs more free resources. Actual usability depends on context, image resolution, parallel applications and runtime.

Inspect the allocation after starting:

ollama ps

If Ollama offloads part of the model to the CPU or macOS reports memory pressure, reduce context and close applications. A large model with a short context can be more useful than the same model at a nominal maximum context that constantly swaps or offloads.

Use thinking mode deliberately

Gemma 4 supports configurable thinking modes. More internal reasoning can help with mathematics, planning and complex coding, but it increases response time and token use. For short questions, a shorter mode is often a better user experience.

Thinking is not a quality guarantee. The relevant question is whether the extra compute reduces errors in your workflow. When comparing variants locally, keep mode, context and tasks consistent.

Gemma 4 versus Qwen3.6

Both families provide local Mac tags and multimodal variants. A blanket rule such as “Qwen for coding, Gemma for images” is too coarse. Compare:

• exact model tag and package size;
• image and audio support in the client;
• context and KV cache;
• license and data path;
• performance on your own task set.

Vendor benchmarks are useful signals, but they are not directly comparable without the same runtime, prompts and evaluation method. For a head-to-head comparison of both families, see the Gemma 4 vs. Qwen3.6 comparison, and the Gemma 4 12B article for the compact 12B rundown.

Test Gemma 4 on your Mac

A reproducible local comparison should record:

1. Mac model and unified memory;
2. macOS and Ollama versions;
3. tag and backend, including MLX or QAT;
4. context and image resolution;
5. response time and tokens per second;
6. CPU/GPU split from ollama ps;
7. memory pressure during a realistic task.

Practical choice

The five model sizes cover several local Mac memory tiers. E2B/E4B are the small options; 12B can be tested in Q4 on 16 GB with controlled context and has more headroom at 24 GB; 26B A4B fits a planned 32 GB setup and 31B needs more headroom.

Start with the smallest tag that meets the task. Increase model size or context one variable at a time and check ollama ps after each change. This bases the choice on the tested tag and the Mac’s memory limit.

Sources

• Google Gemma 4 Model Card — sizes, modalities, context, architecture and benchmarks.
• Google: Gemma 4 — positioning and license.
• Ollama: Gemma 4 — current tags, package sizes and context values.