Gemma 4 on a 16 GB Mac: the E4B matches the 12B at 42% less RAM and 3× the speed
Google’s Gemma-4 E4B matches the full 12B’s math and factual accuracy on an M3 while using 42% less memory and running 3× faster — so on a 16 GB Mac, the E4B is the model to run. One caveat on why, added after a sharp comment thread: this is a size effect, not a quantization-aware-training one. When I ran the 12B’s own QAT build (below), it was marginally bigger and slower than the non-QAT 12B — so QAT isn’t buying the win here; the E4B is just a strong small model.
The E4B and the 12B post the same math+factual score (13/13) — but the E4B does it in 6.6 GB instead of 11.4 and at 3× the decode speed. The smaller model matches the bigger one’s accuracy at 42% less memory — a size win on a memory-bound Mac.
The numbers, all on the same 16 GB MacBook Air, all under a 2048-token load (peak RAM measured in an isolated process so it’s real, not a cumulative-batch artifact):
| Model | RAM (under load) | tok/s | Math | Factual |
|---|---|---|---|---|
| Gemma-4-12B (4-bit, non-QAT) | 11.37 GB | 2.7 | 8/8 | 5/5 |
| Gemma-4-12B (4-bit, QAT) | 12.19 GB | 2.3 | 7/8 | 5/5 |
| Gemma-4-E4B QAT | 6.62 GB | 8.2 | 8/8 | 5/5 |
| Gemma-4-E2B QAT | 4.02 GB | 15.9 | 7/8 | 5/5 |
The second row is the apples-to-apples control a reader asked for, and it’s the important one: QAT at the same 12B size doesn’t shrink or speed the model up — it’s marginally heavier (12.19 vs 11.37 GB), a touch slower, and the same quality within a single task. So quantization-aware training isn’t what wins here; the E4B’s advantage is its size. Compared the right way — QAT vs QAT — the E4B simply beats the 12B on every axis: 45% less memory, ~3.5× the speed, equal scores. (The original version of this post compared the E4B-QAT against the non-QAT 12B and credited QAT for the gap; that conflated size and method. The practical takeaway — run the E4B — is unchanged and, apples-to-apples, stronger.)
E4B is the headline: identical math (8/8) and factual (5/5) scores to the 12B, but it fits in 6.6 GB instead of 11.4 — the difference between “this is the only thing my Mac is doing” and “I can keep my editor, browser, and a model open at once.” It also decodes at 8.2 tok/s versus 2.7, which is the line between readable and waiting.
E2B is the speed play: 15.9 tok/s and a 4 GB footprint, giving up exactly one math question. On a 16 GB machine where memory is the binding constraint, that’s a genuinely different operating point.
One honest caveat: I’m reporting coding as N/A, not as a score. Gemma-4 emits its reasoning in a <|channel|>thought format that my code-extractor can’t parse — it writes correct logic, describes the call in prose, and splits candidate blocks across the trace. The number you’d get is a function of how hard the extractor tries, not of the model’s ability, so reporting one would be dishonest. (This is the same class of self-inflicted benchmark bug I wrote about last week — the fix was to stop trusting the extractor, not to tune it.) Math and factual checks read the answer text directly and are trustworthy.
The upshot for 16 GB users: skip the 12B. The E4B gives you the same answers, leaves you 5 GB of headroom, and runs three times faster.