Gemma 4 shipped five sizes at once: E2B, E4B, 12B Unified, 26B A4B, and 31B. The letters in those names are not version numbers — they mark three different architectural techniques, and which one you get directly determines whether a variant suits your machine. This post lays out the architectural differences, official benchmarks, real checkpoint sizes, and actual VRAM usage for all five, ending with a selection guide organized by GPU memory.
Every size figure is a real file byte count queried from the HuggingFace API, and every benchmark comes from the official model card. The VRAM section is measured on a laptop with an 8 GB GPU, and I mark clearly which numbers are measured and which are extrapolated.
What the letters actually mean
E = effective parameters
The E in E2B and E4B stands for “effective” parameters. Both models use PLE (Per-Layer Embeddings): instead of adding layers or width, each decoder layer gets its own small embedding table, so every token can look up a vector specific to that layer.
The key point is that these tables are used only for lookups — they never participate in matrix operations. That is why Google publishes two parameter counts: E2B is 2.3B effective / 5.1B with embeddings, and E4B is 4.5B effective / 8B with embeddings. Compute scales with the effective count; storage scales with the full one.
The practical consequence of this design gets very concrete in the “size trap” section below. It is simultaneously the reason the E-series can run on a phone and the reason its quantized checkpoints are absurdly large.
Unified = no separate encoders
The other Gemma 4 models push images and audio through a dedicated encoder before handing results to the language model. 12B Unified removes those encoders entirely: image patches and audio waveforms are projected straight into the LLM’s embedding space through lightweight linear layers, so every modality flows into a single decoder-only transformer.
Two benefits follow: lower multimodal latency, and the ability to fine-tune the whole model in one pass instead of staging around encoders. The tradeoff is losing whatever specialized capability a dedicated encoder brings — though judging by the benchmarks, its vision scores did not suffer for it.
This also explains why 12B’s multimodal projector file is so much smaller than the rest: other variants ship an mmproj of 0.9 to 1.1 GiB, while 12B’s is 0.17 GiB, because there is no separate encoder to load in the first place.
A4B = only 4B parameters active
26B A4B is this generation’s only MoE model: 25.2B total parameters, but only 3.8B active during inference. Each token routes to 8 of 128 experts, plus 1 shared expert.
In practice that means speed close to a 4B model with quality close to a 26B one. Google’s framing is that it runs much faster than the dense 31B, almost as fast as a 4B model. The cost is that VRAM must be budgeted for the full 25.2B — every expert has to sit resident on the card, because you cannot predict which ones the next token will route to.
Where did 27B and 32B go
People arriving from Gemma 3 often go looking for 27B — the previous generation’s flagship. Gemma 4 has no 27B, and no 32B either. The official repositories expose exactly five Gemma 4 size identifiers: e2b, e4b, 12b, 26b-a4b, and 31b.
Roughly speaking, the slot that 27B occupied has been split in two directions. For throughput there is 26B A4B — MoE, only 3.8B active, running like a 4B model. For maximum quality there is 31B, dense with 60 layers. The old 1B and 4B sizes were replaced by E2B and E4B, trading architecture complexity via PLE for better parameter efficiency.
So if you are hunting for “Gemma 4 27B”, either you are remembering the previous generation, or what you actually want is one of 26B A4B and 31B.
Architecture side by side
| Property | E2B | E4B | 12B Unified | 26B A4B | 31B |
|---|---|---|---|---|---|
| Total parameters | 2.3B effective 5.1B with embeddings |
4.5B effective 8B with embeddings |
11.95B | 25.2B total 3.8B active |
30.7B |
| Layers | 35 | 42 | 48 | 30 | 60 |
| Sliding window | 512 | 512 | 1024 | 1024 | 1024 |
| Context length | 128K | 128K | 256K | 256K | 256K |
| Vocabulary | 262K | 262K | 262K | 262K | 262K |
| Modalities | Text / image / audio | Text / image / audio | Text / image / audio | Text / image | Text / image |
| Vision encoder | ~150M | ~150M | None (Unified) | ~550M | ~550M |
| Audio encoder | ~300M | ~300M | None (Unified) | Not supported | Not supported |
Two rows deserve to be pulled out on their own.
Audio is supported only on E2B, E4B, and 12B. This gets overlooked constantly: if your use case involves speech transcription or speech translation, 26B and 31B are out regardless of how much VRAM you have. Put differently, “I want audio and I want maximum capability” tops out at 12B Unified, with nothing above it.
Sliding window 512 versus 1024. The E-series window is half the size, and on top of that some of its layers share the KV of the layer above outright. Together these make the E-series KV cache grow remarkably slowly. Measured, E4B going from 8K to 128K context added only about 1.1 GB of KV. A same-size model without those design choices would grow several times faster. In long-context workloads this is an underrated advantage.
Official benchmarks
These figures come from the official model card and cover instruction-tuned variants. The last column is the previous generation’s Gemma 3 27B with thinking disabled, for reference.
| Benchmark | 31B | 26B A4B | 12B Unified | E4B | E2B | Gemma 3 27B |
|---|---|---|---|---|---|---|
| MMLU Pro | 85.2% | 82.6% | 77.2% | 69.4% | 60.0% | 67.6% |
| AIME 2026 (no tools) | 89.2% | 88.3% | 77.5% | 42.5% | 37.5% | 20.8% |
| LiveCodeBench v6 | 80.0% | 77.1% | 72.0% | 52.0% | 44.0% | 29.1% |
| Codeforces ELO | 2150 | 1718 | 1659 | 940 | 633 | 110 |
| GPQA Diamond | 84.3% | 82.3% | 78.8% | 58.6% | 43.4% | 42.4% |
| Tau2 (avg of 3) | 76.9% | 68.2% | 69.0% | 42.2% | 24.5% | 16.2% |
| BigBench Extra Hard | 74.4% | 64.8% | 53.0% | 33.1% | 21.9% | 19.3% |
| MMMLU (multilingual) | 88.4% | 86.3% | 83.4% | 76.6% | 67.4% | 70.7% |
| MMMU Pro (vision) | 76.9% | 73.8% | 69.1% | 52.6% | 44.2% | 49.7% |
| MATH-Vision | 85.6% | 82.4% | 79.7% | 59.5% | 52.4% | 46.0% |
| MRCR v2 128K long context | 66.4% | 44.1% | 43.4% | 25.4% | 19.1% | 13.5% |
Where the cliffs are
Rereading that table for “which step drops hardest” is more useful than reading the absolute scores.
Reasoning tasks fall off a cliff between 12B and E4B. AIME drops from 77.5% to 42.5%, Codeforces ELO from 1659 to 940, BigBench Extra Hard from 53.0% to 33.1%. That is not a gradient, it is a wall. Multi-step reasoning requires holding a long chain consistent, and that capability depends on scale far more than knowledge retrieval does. So if your workload is solving math, writing non-trivial code, or running multi-step agents, the E-series is simply not a candidate — no matter how badly you want to save VRAM.
Knowledge and multilingual tasks slope far more gently. MMLU Pro goes 77.2% to 69.4%; MMMLU goes 83.4% to 76.6%. For translation, summarization, classification, and question rewriting, E4B is genuinely usable. I run E4B behind Immersive Translate for web page translation, and it is entirely adequate for daily reading of English material.
E4B beats the previous generation’s 27B across the board, but not by the same margin everywhere. AIME 42.5% vs 20.8% and Codeforces 940 vs 110 are enormous jumps. But MMLU Pro is 69.4% vs 67.6%, and MMMLU is actually 76.6% vs 70.7% — the lead in breadth of knowledge is nowhere near as dramatic as the lead in reasoning. A 4.5B-effective model outreasoning last generation’s 27B is mostly a training-method result, not an architectural one.
26B A4B is the best value tier. MMLU Pro 82.6% and AIME 88.3% put it within reach of 31B while inferring at roughly 4B speed. It falls behind meaningfully in only two places: long context (MRCR 44.1% vs 66.4%) and HLE (8.7% vs 19.5%). The first says MoE retrieval consistency over very long contexts still trails dense models; the second is a ceiling gap on extremely hard problems. Everyday workloads rarely touch either.
The size trap: parameter count does not give you VRAM
This is where variant selection most often goes wrong. My own first selection table was built by estimating “parameters × bit width”, and the entire table turned out to be wrong.
Here are the real total weight-file byte counts from the HuggingFace API, converted to GiB:
| Variant | bf16 | QAT W4A16 | q4_0 GGUF | mmproj |
|---|---|---|---|---|
| E2B | 9.54 | 7.75 | 3.12 | 0.92 |
| E4B | 14.89 | 10.72 | 4.80 | 0.92 |
| 12B Unified | 22.28 | 9.56 | 6.50 | 0.17 |
| 26B A4B | 48.07 | — | 13.45 | 1.11 |
| 31B | 58.25 | 21.67 | 16.44 | 1.12 |
Look hard at the QAT column. E4B in W4A16 is 10.72 GiB, while 12B Unified — three times the parameter count — is only 9.56 GiB. Pick by “fewer parameters must be smaller” and you land on a model that is both bigger and weaker.
The reason is stated plainly in the QAT checkpoint’s config:
{
"quantization_config": {
"config_groups": {
"group_0": {
"targets": ["Linear"]
}
}
}
}targets: ["Linear"] — only linear layers get quantized; embeddings stay untouched in bf16. For an ordinary model this barely matters, since embeddings are a small fraction of the whole. But the E-series PLE table alone is 2.8B parameters on E4B, and that entire block goes uncompressed, inflating the quantized checkpoint on its own.
GGUF q4_0 avoids this because it quantizes embeddings too, bringing E4B down to 4.80 GiB. This is precisely why small-VRAM machines should go GGUF plus llama.cpp rather than QAT weights plus vLLM.
Worth stating outright: vLLM is not “the better engine” — it is the engine for machines with VRAM to spare. Its strengths are batched throughput and concurrency scheduling, not footprint. For single-user self-hosting on a tight card, llama.cpp is the better fit.
GGUF file size is not VRAM usage either
There is one more layer. The E4B q4_0 file is 4.80 GiB, but only about 2.2 GiB actually lands in VRAM.
That is because llama.cpp keeps the PLE table and token embedding in system RAM. Together they come to:
PLE table = vocab 262144 × layers 42 × PLE dim 256 = 2.82B params
token embd = vocab 262144 × hidden 2560 = 0.67B params
3.49B params total, roughly 2.6 GiB inside the GGUFThe PLE table exists purely for lookups, so keeping it in RAM and reading on demand is entirely sensible — the GPU never needs it for matrix multiplication. But the consequence is that estimating VRAM from GGUF file size overshoots by 2.6 GB. On an 8 GB card, that is enough to wrongly conclude E4B will not run, when in practice it runs with room to spare.
Measured on a laptop with 8 GB of VRAM, running E4B q4_0 through llama.cpp’s Vulkan backend with KV cache quantized to q8_0:
| Context | Measured VRAM | Notes |
|---|---|---|
| 8K | 2.90 GiB | Text only, mmproj not loaded |
| 32K | 4.25 GiB | With mmproj |
| 64K | 4.54 GiB | With mmproj |
| 128K | 5.14 GiB | With mmproj, full context |
Full 128K context with image input still leaves nearly 3 GB of headroom on an 8 GB card, at 63 to 66 tok/s. The gap between that result and the intuition you form from “E4B quantized is 10.72 GiB” is exactly the problem this section is about.
Choosing by VRAM
Putting the numbers together gives the following tiers. These assume q4_0 GGUF with llama.cpp, KV quantized to q8_0, and headroom left for display output:
| VRAM | Pick | Why |
|---|---|---|
| 4 GB | E4B (context capped at 64K) | Once PLE is deducted, only 2.16 GiB of weights land on the card — it fits better than you would guess. Drop to E2B if you want more headroom. |
| 6 GB | E4B | Full 128K context. Fine for translation, summarization, everyday Q&A. Do not expect it to solve math. |
| 8 GB | E4B with image input | Measured at 5.14 GiB for full 128K context plus mmproj, leaving nearly 3 GB free, at 63–66 tok/s. |
| 12 GB | 12B Unified | 6.50 GiB of q4_0 weights, good for 32K of context. The top edge of the reasoning cliff, and the most capable variant with audio support. |
| 16 GB | 12B Unified (W4A16 viable) | Reaches 64K of context. 26B A4B only barely fits at this tier and forces context down to 8K, which is not a good trade. |
| 24 GB | 26B A4B | 13.45 GiB of q4_0 weights with full 128K context. This is where MoE’s throughput advantage genuinely pays off. |
| 32 GB | 31B | 16.44 GiB of q4_0 weights, good for 64K. Choose it when you want maximum reasoning and long-context consistency. |
| 48 GB+ | 31B W4A16 | No longer any need to lean on 4-bit for footprint, and context opens up past 128K. |
These are rough tiers. For your specific card, target context length, and concurrency, use the VRAM calculator — it encodes every size figure above, the PLE deduction, and the KV cache structure, with the formula calibrated against those four measured points.
Three practical details the benchmarks do not show
E2B and E4B cannot turn thinking off. The model card is explicit: for every model except E2B and E4B, disabling thinking still emits the tags but with an empty thought block. The E-series does not honor it. If you are wiring up something latency-sensitive that has no use for a reasoning trace — a translation integration, say — you have to handle it at the API layer by passing enable_thinking: false through chat_template_kwargs, rather than expecting the model to stop on its own.
Sliding-window models require flash attention. Without it, prompt processing collapses into single digits — I measured 39.6 tok/s of prompt processing once, and only adding --flash-attn on restored normal speed. This is not an optional optimization; it is mandatory.
llama.cpp’s --ctx-size is a total, divided by --parallel. The default parallel is 4, so --ctx-size 16384 gives each slot only 4096. For 16K per slot you have to write 65536, and KV cache is allocated for the full 65536 accordingly. That default has caught plenty of people out.
Summary
The five variants sort out fairly cleanly. E2B and E4B are the edge-device and small-VRAM options — capable at language tasks, with a hard ceiling on reasoning. 12B Unified is where reasoning takes off, and it is also the ceiling for audio support. 26B A4B trades MoE complexity for near-31B quality at near-4B speed, making it the best value on consumer GPUs. 31B retains an irreplaceable lead in long-context consistency and the hardest reasoning.
What trips people up is rarely the capability judgment — it is the size judgment. Parameter count does not give you VRAM, quantized checkpoint sizes often compare backwards from intuition, and GGUF file size is not VRAM usage. Each of those three gaps is enough to pick the wrong model on its own: the first convinces you small models always save memory, the second flips your choice between E4B and 12B, and the third tells you an 8 GB card cannot run E4B.
So query the real byte counts, then measure.
Further reading
- VRAM Calculator — enter your GPU memory and context length to get a per-variant breakdown of weights, KV cache, and overhead.
- Deploy a Local LLM, Part 1: Pick the Right Model and Engine for Your VRAM — the full sequence from
nvidia-smito a systemd service. - Self-Hosting a Gemma 4 Gateway: Pitfalls You Only Hit by Running It — a record of the problems that actually came up during deployment.