Apple silicon · M1 through M4

Gemma 4 on Mac

Apple silicon is unusually good at this, for one structural reason: unified memory means your GPU can address far more than any consumer graphics card. Here's how to size it, how to raise the memory ceiling, and which format is actually faster - the answer surprised me.

Which Mac runs what Raise the memory ceiling MLX or GGUF? Real speeds

No CUDA, no drivers, no configuration - Metal is always available

whole setup

# Install
brew install ollama

# 6.7 GB - the sweet spot on a 16 GB Mac
ollama pull gemma4:12b

# Give it room; the default is 4,096
export OLLAMA_CONTEXT_LENGTH=32768

ollama run gemma4:12b

8 GBE2B / E4BQ4

16 GB12Bbest fit

32 GB+26B / 31BQ4

Why Macs punch above their weight

Unified memory changes the maths

This is the whole story, and it's why a mid-range MacBook can run models that need a very expensive graphics card on a PC.

🖥️

On a PC

Separate VRAM

The GPU has its own dedicated memory, and that's your hard ceiling. A 12 GB card runs models that fit in 12 GB - system RAM doesn't help, and spilling into it collapses performance. Going bigger means buying a bigger card.

🍎

On Apple silicon

One shared pool

CPU and GPU share the same memory. A 32 GB Mac can hold a model that would need a 32 GB graphics card - and there is no copying between host and device, because there's only one pool.

A 64 GB Mac Studio will comfortably run models that need multiple consumer GPUs on a PC, at a fraction of the power draw.

⚠️

The catch nobody mentions. That shared pool is shared with everything else - macOS, your browser, your editor. Unlike dedicated VRAM, the model is competing with your actual work. A model that "fits" in theory can push your system into memory pressure and swap, at which point everything including the model gets slower. Always leave real headroom rather than sizing to the maximum.

Sizing

Which model for your Mac

Based on the official 4-bit weight sizes, plus realistic headroom for macOS and the apps you actually have open.

Your Mac	Recommended	Weights	Also possible	Avoid
8 GB	`gemma4:e2b`	2.9 GB	E4B at 4.5 GB, with little else running	12B and above
16 GB	`gemma4:12b`	6.7 GB	E4B for more headroom	26B - see below
24 GB	`gemma4:12b` at Q8	13.4 GB	26B A4B at Q4, tight	31B
32 GB	`gemma4:26b`	14.4 GB	31B at Q4 (17.5 GB)	-
48 GB	`gemma4:31b`	17.5 GB	Higher-quality quants, long context	-
64 GB+	`gemma4:31b` at Q8	34.9 GB	Full BF16 at 128 GB	-

Q4_K_M community quants run slightly larger than the official Q4_0 figures shown here - budget roughly 10% more if you use them.

💡

The 16 GB advice you'll see elsewhere is usually wrong. Guides written before June 2026 recommend the 26B MoE for 16 GB Macs because it was the smallest capable option. At 14.4 GB of weights that leaves about 1.6 GB for macOS and everything else - it technically loads, then swaps miserably. Gemma 4 12B at 6.7 GB is the right answer for a 16 GB Mac, and it didn't exist when most of those guides were written. It also adds audio and video input, which the 26B doesn't have at all.

Power user

Raising the GPU memory ceiling

macOS caps how much unified memory the GPU may wire down. If a model won't load despite apparently fitting, this is usually why.

📏

What macOS allows by default

Roughly 75–78%

The kernel derives a GPU limit from installed memory - on one measured 32 GB M2 Max, Metal reported a ceiling of about 24.96 GB, or 78%. The exact proportion varies by machine, so measure yours rather than assuming a figure.

The sysctl default reads 0, which means "derive from installed memory" - not "unlimited".

🔧

Raising it

Temporary by design

# Raise the wired-memory ceiling, in MB
sudo sysctl iogpu.wired_limit_mb=28000

# Check the current value
sysctl iogpu.wired_limit_mb

This resets to 0 on every reboot. That's a feature - a launch daemon that sets it permanently removes headroom on every startup whether or not you're running a model.

🚨

Increase it gradually, and leave real headroom. A sensible method: start about a gigabyte above Metal's recommended maximum working set and raise it in one-gigabyte steps until your model loads. A reasonable ceiling is spending no more than about half your reserve - installed memory minus Metal's recommendation. On a 32 GB machine that put 28,000 at roughly the far edge of sensible, leaving around 4.6 GB for everything else.

This matters because a wired-memory shortfall on Apple silicon is a kernel-level fault. You don't get a tidy out-of-memory error - you get a stalled machine.

Correction

MLX or GGUF?

The conventional answer is "MLX, obviously - it's Apple's own framework." For Gemma 4 specifically, the measurements say otherwise.

Task · Gemma 4 26B	GGUF	MLX fp16	Winner
Creative writing	56.1 t/s	52.7 t/s	GGUF, +6%
Eight-turn agent conversation	41.7 t/s	38.4 t/s	GGUF, +9%

🔬

Why, and how much to read into it. The gap is attributed to quantisation quality: llama.cpp's K-quant scheme reportedly delivers substantially better perplexity than the uniform 4-bit approach MLX currently uses. But treat this as Gemma-4-specific rather than universal - the evidence is drawn from Gemma 4 and MoE architectures, MLX has known optimisation headroom (fixing bf16-to-fp16 conversion is said to recover 40–70% of prefill speed), and an optimised MLX runtime has reportedly reached 71 t/s on an M3 Max. The picture may well flip.

Practical advice

Start with GGUF through Ollama or LM Studio - it's simpler, better quantised for Gemma 4 today, and currently a touch faster. It's also the format with official Google QAT checkpoints, which beat community quants at the same bit depth.

When MLX is still worth it

If you're writing Python against the model rather than chatting with it, MLX is a pleasant native framework with good fine-tuning support. And the margin here is single-digit percent - not a reason to rewrite anything that already works.

Setup

Four ways to run it

# Homebrew, or download the .dmg from ollama.com
brew install ollama

# The .dmg build additionally includes the MLX runner, if you
# want to try both formats - see the comparison above.

ollama --version              # expect 0.22.0 or newer
ollama pull gemma4:12b        # 6.7 GB, good for 16 GB Macs

# Give it context - the default of 4,096 wastes the model
export OLLAMA_CONTEXT_LENGTH=32768

# Keep it resident so the first token isn't slow every time
export OLLAMA_KEEP_ALIVE=-1

ollama run gemma4:12b

# LM Studio - no terminal required
#   1. Download from lmstudio.ai and install
#   2. Search "gemma 4" in the model browser
#   3. Pick a size - it estimates memory and warns if it won't fit
#   4. In load settings, raise the context length from the default

# LM Studio supports both GGUF and MLX builds on Apple silicon,
# so it's the easiest way to compare the two yourself.

# It can also serve an OpenAI-compatible API:
#   lms server start --port 1234

# Apple's own framework - nice if you're writing Python
pip install mlx-lm

mlx_lm.generate \
  --model mlx-community/gemma-4-12b-it-4bit \
  --prompt "Summarise this meeting transcript." \
  --max-tokens 1024

# Ollama also exposes MLX builds directly:
ollama pull gemma4:12b-mlx
ollama pull gemma4:31b-mlx

# Maximum control. --jinja is mandatory or tool calls break.
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

# Pull Google's official QAT build straight from Hugging Face
./build/bin/llama-server \
  -hf google/gemma-4-12B-it-qat-q4_0-gguf \
  --port 8080 \
  -c 32768 \
  -ngl 99 \
  --jinja

# -ngl 99 offloads all layers to the GPU. On Apple silicon this
# is what engages Metal; without it you're on CPU.

Performance

What to expect by chip

Community-reported figures at 4-bit. Treat them as a range rather than a specification - speed varies with quantisation, context length and what else you have open.

Machine	Tokens/sec	Comfortable with
M4 Max · 128 GB	40–50	31B at Q4, with room to spare
M3 / M4 Pro · 36 GB	20–35	26B A4B or 31B at Q4
M2 / M3 Pro · 24 GB	15–25	12B at Q8, or 26B at Q4 tightly
M2 / M3 · 16 GB	14–20	12B at Q4
M1 · 8–16 GB	8–22	E2B and E4B; 12B on 16 GB

📖

Anything above roughly 15 tokens/sec is faster than you read. Which means a mid-range Mac running the 12B is genuinely comfortable for interactive use - the constraint you'll actually notice is time-to-first-token on long prompts, not generation speed. Keeping the model resident with OLLAMA_KEEP_ALIVE=-1 removes the reload penalty between questions.

Mac-specific

Things that only bite on a Mac

Symptom	Cause	Fix
Whole machine stalls when loading	Wired-memory shortfall - a kernel-level fault, not a clean error	Lower `iogpu.wired_limit_mb` or use a smaller model
Model "fits" but everything crawls	Unified memory shared with macOS and apps; you're swapping	Leave real headroom - check memory pressure in Activity Monitor
Fans spin up, speed drops over time	Thermal throttling, pronounced in the fanless MacBook Air	Expected. Shorter sessions, or a smaller model on an Air
Won't load despite enough free RAM	GPU wired limit is below the model size	Raise it with the sysctl above, in gradual steps
Slow first token every question	Model unloaded between requests	`OLLAMA_KEEP_ALIVE=-1`
Raw `<unused24>` tokens in output	Chat template not applied on llama.cpp	Add `--jinja`

FAQ

Common questions

Which model should I run on a 16 GB Mac?

Gemma 4 12B at 4-bit - 6.7 GB of weights, leaving comfortable room for macOS and your apps. It also accepts audio and video, which the larger models don't.

Ignore older guides recommending the 26B for 16 GB machines. At 14.4 GB it leaves about 1.6 GB for everything else; it loads and then swaps. Those guides predate the 12B's June 2026 release.

Do I need to install CUDA or drivers?

No. Metal is built into macOS and always available - one of the genuine advantages of running this on a Mac. There's no driver to update, no toolkit to match versions with, and no equivalent of the "GPU silently not being used" problem that plagues NVIDIA setups.

Is an Intel Mac usable?

Only just, and only for the smallest models. Without unified memory and Apple's GPU you're on CPU inference with a discrete or integrated GPU that these runtimes don't target well. E2B will run. Anything larger will be slow enough to be frustrating. Everything on this page assumes Apple silicon.

MacBook Air or MacBook Pro?

Both work; the difference is sustained load. The Air is fanless, so it throttles during long generation sessions - fine for occasional questions, less so for extended work. The Pro holds its speed. If you're choosing hardware specifically for this, memory capacity matters far more than the chip tier.

Is MLX faster than GGUF?

For Gemma 4 right now, no - GGUF measures around 6–9% faster in community testing, attributed to llama.cpp's better K-quant scheme. That's counterintuitive given MLX is Apple's own framework, and it may not hold: the finding looks Gemma-specific, and MLX has known optimisation headroom. The margin is small enough that neither choice is a mistake.

Should I raise the GPU memory limit?

Only if a model won't load despite apparently fitting. It's a real lever for squeezing a larger model onto a given Mac, but the failure mode is a kernel-level stall rather than a clean error. Raise it gradually, leave headroom, and let it reset on reboot rather than making it permanent.

Can I run the 31B on a MacBook?

At 4-bit it needs 17.5 GB of weights, so realistically you want 32 GB or more - which means a higher-spec MacBook Pro. It runs well on a 36 GB M3 or M4 Pro at 20–35 tokens/sec. On a Mac Studio with 64 GB or more it's genuinely comfortable, including at higher-quality quantisation.

Your Mac is better at this than you think.

Unified memory means it runs models that would need a very expensive graphics card on a PC.

Get the weights Full install guide Try it in the browser