Google called it one launch. It's not.

Gemma 4 is four completely different models with different architectures, different hardware requirements, and different use cases — packaged under one name that makes it sound like a single thing. If you read the announcement and walked away confused about what to actually download, that's not on you. That's the naming.

I've been building with local AI for a while — I recently built a RAG system using Llama 3.2 running locally via Ollama, and the hardware reality of running LLMs on a regular laptop is something I've dealt with firsthand. So let me break this down practically, not theoretically.

---

First: What "E" and "A" Actually Mean

The naming convention is doing a lot of work here and Google doesn't explain it upfront.

E2B and E4B — the "E" stands for effective parameters. These are not 2B and 4B parameter models in the traditional sense. They use Per-Layer Embeddings (PLE) to pack more capability into fewer parameters. Think of it as parameter efficiency — more intelligence per byte than the raw number suggests.

26B A4B — the "A" stands for active parameters. This is a Mixture-of-Experts (MoE) model with 26B total parameters, but during inference, only a 4B subset activates per token — making it run almost as fast as a 4B-parameter model. You get the quality of a large model at the speed of a small one.

31B Dense — no tricks. Every token touches all 31 billion parameters. Slower, heavier, but the most predictable behavior.

---

The Four Models, Plainly

E2B — For the Edge

Google's own tests show Gemma 4 E2B running on a Raspberry Pi 5 at around 7.6 tokens per second — slow but functional for edge agent workflows.

If you're building something that needs to run on a phone, a microcontroller, or offline hardware with no GPU — this is your only option in the family. It supports audio natively, which the larger models don't. Context window tops out at 128K.

Who it's for: IoT projects, on-device apps, offline deployments, Raspberry Pi builds.
Who it's NOT for: Anyone who wants quality answers on a regular laptop.

---

E4B — The Practical Daily Driver

E4B runs comfortably on any modern laptop — Mac, Windows, Linux — and delivers surprisingly good quality for its size.

This is the model most developers should start with. It handles image input, audio, and text. It's fast enough for interactive use and doesn't require a dedicated GPU. Context window is 128K.

Who it's for: Developers on regular laptops, multimodal projects that need audio, quick prototyping.
Who it's NOT for: Tasks requiring deep reasoning or complex long-document analysis.

---

26B A4B — The Hidden Best Value

This one is the most interesting in the lineup and the least talked about.

The 26B A4B achieves roughly 97% of the dense 31B model's quality while activating only 3.8B parameters per token — about 8x less compute per inference step. On the LMArena leaderboard it scores 1441 Elo versus 1452 for the 31B — a gap that's invisible in most real-world tasks.

If you have a machine with 16GB+ RAM and a decent GPU, or Apple Silicon, this is arguably the best model in the whole lineup. You get near-31B quality at a fraction of the compute cost. Context window extends to 256K here.

Who it's for: Developers with a decent machine who want maximum quality-per-compute, agentic workflows, long-document tasks.
Who it's NOT for: Low-spec machines, anyone without at least 16GB RAM.

---

31B Dense — Maximum Quality, Maximum Cost

The 31B model currently ranks as the #3 open model in the world on the Arena AI text leaderboard. Every token touches all 31 billion parameters. No shortcuts.

It's slower than the 26B A4B for inference, but it's the better candidate if you want to fine-tune — dense architecture means cleaner gradient flow during training. Context window is 256K and it actually works: the 31B went from 13.5% to 66.4% on multi-needle retrieval tests, meaning the model can actually find and reason over information buried deep in a long document.

Who it's for: Server deployments, fine-tuning projects, maximum quality use cases, cloud inference.
Who it's NOT for: Anyone running locally without a workstation-grade GPU.

---

The Hardware Reality Nobody Talks About

Here's my honest take as someone who's actually tried running LLMs locally on consumer hardware:

A few weeks ago I built a job market Q&A system using Llama 3.2 running locally via Ollama. The setup worked — but every response took 10-15 seconds on my CPU, and I spent more time watching a blinking cursor than actually using the thing.
I stuck with local anyway, not because it was convenient, but because the alternative was sending job description data and user queries to an external API I don't control. For a portfolio project that's fine. For anything with real user data, that tradeoff stops being theoretical.
And that's the honest hardware reality nobody talks about: the gap between "this model CAN run on your laptop" and "this model runs well on your laptop" is real and wide.
E2B and E4B are the only Gemma 4 models most people can realistically run locally without a dedicated GPU. The 26B A4B and 31B are cloud or workstation territory for most developers.

That experience is what made Gemma 4's range genuinely interesting to me — not the benchmarks, but the fact that someone with a decent laptop can now run a near-31B quality model locally without a GPU, or fall back to the 31B on OpenRouter's free tier without sacrificing open-weight guarantees. The hardware ceiling is still real.

---

Quick Decision Guide

---

Final Thought

Gemma 4 is genuinely impressive — not because any single model is revolutionary, but because the family covers the full deployment spectrum from a Raspberry Pi to a workstation under one open license. That's rare.

But "Gemma 4" is not one thing. Pick the right model for your hardware, your use case, and your deployment target. The name is marketing. The specs are what matter.