Gemma 3n vs Gemma 4: Which On-Device Model Wins in 2026?

Gemma 3n was Google's first genuinely mobile-first open model: it put text, image, and audio understanding on a phone with a memory footprint of a few gigabytes. Then Gemma 4 shipped an E2B and an E4B of its own, and the obvious question became unavoidable — is Gemma 3n still the on-device model, or did Gemma 4's E-series quietly replace it?

This page answers that. Everything below is checked against Google's own Gemma docs, the Gemma 4 model card, the Gemma 4 technical report, and the LiteRT-LM deployment pages, as of August 2026.

If you only want the full-size Gemma 4 vs Gemma 3 comparison without the on-device angle, read Gemma 4 vs Gemma 3: what changed and should you switch instead. This page is about the small, edge-focused tier.

What is Gemma 3n, and why did Google build it?

Gemma 3n is a mobile-first variant of the Gemma 3 generation, released in E2B and E4B sizes on 26 June 2025 according to Google's Gemma release timeline. Its design goal was not benchmark leadership — it was running multimodal inference on a phone without a server.

Three architectural choices make that possible, per Google's Gemma 3n developer guide:

• Per-Layer Embeddings (PLE). A large share of the checkpoint is embedding tables, one per decoder layer. Those can be loaded and computed on the CPU rather than held in accelerator memory, so only roughly 2B (E2B) or 4B (E4B) core transformer weights need to sit in VRAM.
• MatFormer. A "Matryoshka" nested transformer — the E4B model literally contains a fully functional E2B inside it, optimised simultaneously during training. You can run the big one, extract the small one, or use Mix-n-Match via MatFormer Lab to slice custom sizes in between by adjusting feed-forward hidden dimensions and skipping layers.
• KV cache sharing. Google reports a 2× prefill improvement, which matters for streaming audio and video where time-to-first-token is the whole user experience.

On modality, Gemma 3n handles text, images, and audio. The vision encoder is MobileNet-V5-300M, running 256×256 / 512×512 / 768×768 inputs at up to 60 frames per second on a Pixel — Google cites a 13× speedup with quantization and a 4× smaller memory footprint than the SoViT encoder used in Gemma 3. The audio encoder is a Universal Speech Model derivative producing one token per 160 ms of audio (about 6 tokens/second), with clips up to 30 seconds in the shipped implementation.

Context window: 32K tokens. Knowledge cutoff: June 2024. Training corpus: roughly 11 trillion tokens across 140+ languages. E4B was the first sub-10B model to pass 1300 on LMArena.

What does the "E" in E2B and E4B actually mean?

This is the single most misread thing about the whole tier, and it trips people up in both generations.

"E" stands for effective parameters, not total parameters. An E4B model does not have 4 billion weights on disk. It has roughly 8 billion — but because per-layer embeddings are looked up rather than multiplied through the network, the working set that has to live in fast memory behaves like a 4B model.

So there are two numbers you need, and they answer different questions:

• Total parameters determine your download and storage size.
• Effective parameters determine your runtime memory and compute cost.

Gemma 4's figures come from the official Gemma 4 model card, which quotes E2B as "2.3B effective, 5.1B including embeddings" and E4B as "4.5B effective, 8B including embeddings". The practical consequence: if you budget disk by the effective number you will run out of space, and if you budget RAM by the total number you will over-provision by roughly 2×.

Gemma 3n vs Gemma 4's E-series: what actually changed?

The Gemma 4 technical report is explicit that the E-series inherits Gemma 3n's core idea — it describes E2B and E4B as using "per-layer embeddings as in Gemma 3n". What changed around that idea is substantial.

Two things deserve emphasis.

The audio stack got smaller and better. Gemma 4's encoder is 305M parameters — a 55% reduction from the previous generation's 680M — and it moved from 160 ms frames to 40 ms frames, which is what makes transcription feel responsive rather than chunky. Google's own head-to-head numbers against Gemma 3n: a 12% (E2B) / 10% (E4B) relative improvement on translation and 17% (E2B) / 12% (E4B) on transcription, alongside a 78% cut in on-disk audio-encoder footprint, from 390 MB to 87 MB after quantization. Shrinking the encoder while improving both tasks is the rare kind of upgrade with no trade-off to weigh.

MatFormer nesting did not carry over. The Gemma 4 technical report describes the E-series as a standard decoder-only transformer (pre-norm, post-norm, RMSNorm, QKNorm; 4-to-1 local-to-global attention for E2B, 5-to-1 for E4B). It carries per-layer embeddings forward but does not describe a nested sub-model. The Gemma 4 model card does not mention MatFormer at all. In practice Google folded the sizing decision into the two named tiers: you pick E2B or E4B rather than slicing your own point on a curve.

Are the benchmarks actually comparable?

Mostly not, and it's worth being straight about that. Google re-cut its evaluation suite between generations: Gemma 3n's card reports MMLU and LiveCodeBench v5, while Gemma 4's reports MMLU Pro and LiveCodeBench v6. Those are different tests and cannot be diffed.

GPQA Diamond is the one measured identically in both cards, and the gap there is not subtle: Gemma 3n E4B scores 23.7%, Gemma 4 E4B scores 58.6%. For reference, Gemma 4 E4B's other instruction-tuned scores are MMLU Pro 69.4%, LiveCodeBench v6 52.0%, AIME 2026 (no tools) 42.5%, Codeforces Elo 940, and MMMU Pro vision 52.6%. E2B lands at MMLU Pro 60.0%, GPQA Diamond 43.4%, LiveCodeBench v6 44.0%.

Note that Gemma 4 E2B outscores Gemma 3n E4B on GPQA Diamond (43.4% vs 23.7%) at roughly half the effective size. That is the practical headline: the smaller model of the new generation beats the larger model of the old one on the one test they share.

Gemma 3n E4B vs Gemma 4 E4B — which should you run?

Run Gemma 4 E4B. It is the same total parameter count, on the same effective-parameter architecture, with 4× the context, a materially better audio pipeline, seven months more training data, and a decisive win on the only like-for-like benchmark. There is no dimension on which Gemma 3n E4B is straightforwardly better as a model.

The same logic applies one tier down: if you were considering Gemma 3n E2B for a tight memory budget, Gemma 4 E2B is the replacement, and Google's edge team reports it running in under 1.5 GB of memory on some devices using 2-bit and 4-bit weights with memory-mapped per-layer embeddings.

There is also no "Gemma 4n" to wait for. The E2B/E4B tier is the 3n successor — the naming convention moved into the main family rather than staying a separate branch.

Where does Gemma 3n still win?

Three genuine cases, and it's worth naming them honestly rather than pretending the answer is always "upgrade".

1. You already shipped a fine-tune. A LoRA or full fine-tune on Gemma 3n E4B does not transfer to Gemma 4 E4B. If your adapter is in production and performing, the cost of re-running your training pipeline plus re-validating outputs is a real number. Migrate on your own schedule, not Google's.
2. You need a custom size between 2B and 4B. MatFormer Mix-n-Match is a Gemma 3n capability with no Gemma 4 equivalent. If you are targeting a specific device with an awkward memory ceiling and you have measured that E2B is too weak and E4B does not fit, slicing a custom submodel via MatFormer Lab is a lever only 3n gives you.
3. Disk is your hard constraint and you are on Ollama. Ollama's default builds are gemma3n:e2b at 5.6 GB and gemma3n:e4b at 7.5 GB, against gemma4:e2b at 7.2 GB and gemma4:e4b at 9.6 GB. That gap is mostly quantization and context-length defaults rather than architecture — if you can use LiteRT-LM instead, Google publishes Gemma 4 E2B at 2.58 GB and E4B at 3.65 GB, smaller than any 3n build. Compare quant-for-quant before concluding 3n is the lighter option.

What is not on that list: quality, multimodality, context, or audio. Gemma 4's E-series wins all four.

Is Gemma 3n deprecated, or still supported?

Not formally deprecated — but clearly superseded. Here is the evidence in both directions, so you can judge the risk yourself.

Still alive: the Gemma 3n model overview is live with no end-of-life banner, the weights remain published on Hugging Face and Kaggle, and Ollama still serves the gemma3n tags. Nothing you have deployed is going to stop working — open weights you have downloaded are yours regardless of what Google's roadmap does.

Superseded in practice: Google's Gemma model overview now frames Gemma 4 as the current family and lists the 2B/4B tier as the one "built for ultra-mobile, edge, and browser deployment", with Gemma 3n filed under legacy core variants rather than presented as a recommendation. Google's LiteRT-LM model page — the flagship on-device runtime — lists Gemma 4 E2B and E4B and does not list Gemma 3n at all. And the Gemma 4 technical report benchmarks its audio stack directly against Gemma 3n's, which is what a vendor does when framing a replacement.

Separately, Google began retiring older Gemma models from the hosted Gemini API in April 2026, narrowing the served lineup to the Gemma 4 family. That affects API access only; local execution of any Gemma generation is unaffected.

Practical read: treat Gemma 3n as stable-but-frozen. Fine for something already shipped, wrong choice for something you are starting today.

How do the full-size Gemma 3 and Gemma 4 models compare?

Useful context if you are deciding whether the on-device tier is even the right tier. Gemma 4 spans four shapes, per the model card:

The 31B dense model is the quality ceiling: MMLU Pro 85.2%, GPQA Diamond 84.3%, Codeforces Elo 2150, MMMU Pro vision 76.9%. The 26B A4B mixture-of-experts is the throughput option — 25.2B total parameters but only 3.8B active per token, so it reasons closer to a mid-size dense model at a fraction of the compute. The 12B Unified variant landed later, on 3 June 2026.

Gemma 3's full-size lineup (1B through 27B, March 2025) is the generation being replaced across the board. If you're weighing that specific upgrade rather than the on-device one, the Gemma 4 vs Gemma 3 comparison covers it properly, and the Gemma 4 complete guide goes deeper on every variant.

How do you actually run these on-device?

Four paths, in rough order of how production-ready they are for a shipped app:

• Google AI Edge Gallery — a Play Store / iOS app that lets you download and run Gemma 4 E2B or E4B fully on-device. Best for evaluating quality on a real handset before you write any integration code.
• LiteRT-LM — Google's cross-device runtime, and the path Google itself points at for shipping. It currently supports E2B and E4B, with larger models listed as coming. Model artefacts are 2.58 GB (E2B) and 3.65 GB (E4B). Google publishes prefill/decode figures across Android, iOS, Linux, macOS, Windows, and Raspberry Pi 5 — E2B on Android GPU hits 3,808 tokens/s prefill and 52 tokens/s decode; on a Raspberry Pi 5 CPU it drops to 133 prefill and 7.6 decode; on a Qualcomm Dragonwing IQ8 NPU it reaches 3,700 prefill and 31 decode.
• Android AICore — system-level access on supported Android devices, so multiple apps share one model instance instead of each shipping their own copy.
• Ollama or llama.cpp — the right choice on a laptop or desktop, not a phone. ollama pull gemma4:e4b gets you the 9.6 GB build with the full 128K context.

The MediaPipe LLM Inference API also runs Gemma models on Android and iOS and is still documented, but LiteRT-LM is where Google's current edge investment is going. Start there for anything new.

How much memory do you actually need?

Google does not publish a single minimum-RAM table, so use the artefact sizes as your floor and add KV cache on top:

The Gemma 3n figures of 2 GB and 3 GB come from Google's own developer guide and refer to the accelerator working set that per-layer embeddings make possible — not the download. Gemma 4's sub-1.5 GB claim for E2B is specifically at 2-bit and 4-bit quantization with memory-mapped embeddings, so treat it as a best case, not a default. One more lever worth knowing: Gemma 4's E-series supports dynamic context length, so if your app never needs 128K you can cap it and reclaim the KV cache budget.

Which one should you pick?

A decision rule you can apply in about thirty seconds:

• Starting something new on a phone or edge device → Gemma 4 E4B if the device has room for a 3.65 GB artefact, Gemma 4 E2B if it does not.
• Already running Gemma 3n in production and it works → keep it, plan the migration for your next model refresh, and re-benchmark before you commit. The upgrade is worth doing; it is not worth doing this week.
• You need a size between E2B and E4B → Gemma 3n plus MatFormer Mix-n-Match is your only option in this family.
• Audio or real-time transcription is the core feature → Gemma 4, without hesitation. The 40 ms frames and the smaller, more accurate encoder are the whole reason to move.
• Not actually constrained to a device → skip this tier entirely. Gemma 4 12B, 26B A4B, or 31B will serve you better on a laptop or a single GPU.

If you are evaluating where Gemma sits against Qwen, Llama, and the rest of the open-weight field before committing, our open-source LLM landscape guide maps the current options, and the self-hosting guide covers the deployment side. If you need engineers who have shipped on-device inference before, Codersera's remote developers work on exactly this kind of edge-ML integration.

FAQ

What is Gemma 3n?

Gemma 3n is Google's mobile-first variant of the Gemma 3 generation, released in June 2025 in E2B and E4B sizes. It runs text, image, and audio inference on phones and laptops using Per-Layer Embeddings and a MatFormer nested architecture, with a 32K context window and support for 140+ languages. It was the first sub-10B model to score above 1300 on LMArena.

What does E4B mean?

The "E" stands for effective parameters, not total. Gemma 4 E4B has 8 billion parameters on disk but only 4.5 billion effective, because per-layer embeddings are looked up rather than pushed through the network. Budget storage by the total count and runtime memory by the effective count — using the wrong one in either direction will cost you.

Is Gemma 3n still worth using in 2026?

Only in specific cases. It is not formally deprecated — the docs are live and the weights are still on Hugging Face and Ollama — but Google's on-device runtime LiteRT-LM lists only Gemma 4 E2B and E4B, and the Gemma docs now present Gemma 4 as the recommended family. Keep 3n for an existing fine-tune or for MatFormer custom slicing; otherwise start on Gemma 4.

Gemma 3n E4B vs Gemma 4 E4B — which is better?

Gemma 4 E4B, clearly. Same 8B total parameters, but four times the context (128K vs 32K), a 55% smaller audio encoder with better transcription and translation, a January 2025 knowledge cutoff instead of June 2024, and 58.6% vs 23.7% on GPQA Diamond — the one benchmark both model cards measure identically.

Is there a Gemma 4n?

No, and there is unlikely to be one. Google folded the on-device tier into the main family rather than branching it: Gemma 4 E2B and E4B are the direct successors to Gemma 3n E2B and E4B. The "n" suffix was a one-generation naming choice, and the Gemma 4 technical report confirms the E-series carries per-layer embeddings forward "as in Gemma 3n".

How much RAM does Gemma 3n need?

Google states Gemma 3n runs with as little as 2 GB for E2B and 3 GB for E4B, because per-layer embeddings keep most of the checkpoint out of accelerator memory. That figure is the working set, not the download — Ollama's builds are 5.6 GB and 7.5 GB respectively. Add KV cache for your target context on top of either number.

Can Gemma 3n run on a phone?

Yes — that was its entire design goal, and both E2B and E4B ship quantized builds intended for handsets. For a new project, though, Gemma 4 E2B is the better phone target: Google reports it running in under 1.5 GB of memory at 2-bit and 4-bit quantization, with a LiteRT-LM artefact of 2.58 GB, and it outscores Gemma 3n E4B on GPQA Diamond at half the effective size.

Does Gemma 4 E4B handle audio as well as Gemma 3n?

Better. Gemma 4's audio encoder is 305M parameters against Gemma 3n's 680M, processes 40 ms frames instead of 160 ms, and quantizes down to 87 MB from 390 MB. Google reports a 12% relative improvement on translation and 17% on transcription for E2B against the previous generation, so this is the rare upgrade that is smaller and more accurate at once.