Gemma 3n E4B

Gemma 3n E4B is a multimodal member of Google’s Gemma 3n family, released June 26, 2025, built around a simple premise: a model’s usefulness is capped by whatever hardware it has to run on, so the architecture should be designed around a memory budget first and a parameter count second. E4B carries 8 billion raw parameters but, through two architectural techniques described below, runs with an accelerator memory footprint of roughly 3GB, comparable to a traditional 4-billion-parameter dense model. That gap between raw size and actual footprint is the entire cost story: it is what lets E4B be served at a fraction of typical API pricing, and what lets it run entirely on a phone or laptop GPU with no cloud inference bill at all.

Two Techniques Behind the Small Footprint

MatFormer (Matryoshka Transformer) is a nested transformer design, named after Matryoshka nesting dolls, in which a smaller, fully functional model is trained inside a larger one rather than as a separate model. Gemma 3n’s smaller sibling, E2B, is literally nested inside E4B: during training, the E2B sub-network is optimized simultaneously as a subset of E4B’s parameters, so E4B doesn’t just happen to be compressible, it is built from the ground up to contain a working smaller model. This also enables “Mix-n-Match”: developers can extract custom-sized sub-models between E2B and E4B by adjusting feed-forward network width and selectively skipping layers, without retraining.

Per-Layer Embeddings (PLE) attacks a different part of the memory budget. In a standard transformer, embedding tables sit in the same accelerator (GPU/TPU) memory as the core weights, even though embeddings don’t need the same fast, tightly-coupled access pattern that attention and feed-forward computation do. PLE moves those embedding parameters to CPU memory, generating and caching them separately, and streams them in as each layer runs. Only the core transformer weights need to occupy the constrained, expensive accelerator memory.

graph TD
    subgraph Raw["Raw Parameter Count"]
    A["E4B: 8B raw parameters"]
    end
    subgraph Runtime["What Actually Sits in Accelerator Memory"]
    B["~4B effective parameters"]
    C["Per-Layer Embeddings offloaded to CPU"]
    D["~3GB accelerator memory footprint"]
    end
    A -->|"MatFormer: nested E2B sub-model, nothing extra activated"| B
    A -->|"PLE: embeddings don't need GPU/TPU memory"| C
    B --> D
    C --> D

    classDef default fill:#ffffff,stroke:#4338CA,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef data    fill:#EEF0F7,stroke:#0D9488,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef process fill:#F7F8FC,stroke:#6366F1,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef output  fill:#4338CA,stroke:#4338CA,stroke-width:2px,color:#ffffff,rx:8px,ry:8px;
    class A default;
    class B,C process;
    class D output;

E2B vs. E4B

Mix-n-Match: Choosing Your Own Memory/Compute Trade-off

Because E2B is a genuine sub-network of E4B rather than a separately distilled model, a developer isn’t locked into exactly two sizes. Mix-n-Match lets you target any effective parameter count between the two by trimming feed-forward width and skipping layers, trading capability for a smaller, cheaper deployment.

Under the hood, Mix-n-Match works by choosing, per layer, between a small (8,192) or large (16,384) feed-forward network dimension and by selectively skipping some layers entirely. Google publishes a set of validated slicing configurations (google/gemma3n-slicing-configs on Hugging Face) and a “MatFormer Lab” Colab notebook that applies them, rather than requiring teams to search the space themselves:

# Extracting a ~3B-effective sub-model between E2B and E4B for a
# translation feature that needs to fit a tighter memory budget
# than E4B's 3GB but more capability than E2B's 2GB ceiling.
# (Illustrates the config format MatFormer Lab applies; run via
# the published Colab notebook, not a standalone pip command.)
slicing_config = {
    "target_effective_params": "3.0B",
    "ffn_dim_per_layer": "mixed",   # 8192 (small) or 16384 (large) per layer
    "layers_skipped": [18, 19, 22],  # selected via the published slicing configs
    "base_model": "google/gemma-3n-E4B",
}

Because E2B was trained as a genuine sub-network of E4B rather than distilled afterward, these intermediate slices inherit meaningfully consistent behavior even at configurations Google didn’t explicitly benchmark, which is what makes Mix-n-Match usable in production rather than just a research curiosity.

Multimodal Input, One Small Footprint

E4B accepts text, images, and audio through encoders designed for the same edge-first budget as the language backbone:

• Vision: a MobileNet-V5-300M encoder supporting 256x256, 512x512, and 768x768 resolutions, capable of processing up to 60 frames per second on a Google Pixel, fast enough for live camera input rather than just static image upload.
• Audio: a Universal Speech Model-based encoder handling automatic speech recognition and speech translation on clips up to 30 seconds.
• Text: trained across 140 languages for text, with multimodal understanding spanning 35 languages.

# Voice-memo triage app: transcribe and classify a customer
# voicemail without ever sending the audio to a paid API
from transformers import pipeline

pipe = pipeline(
    "image-text-to-text",  # Gemma 3n's multimodal pipeline also accepts audio
    model="google/gemma-3n-e4b-it",
    device="cuda",
)

result = pipe([
    {"role": "user", "content": [
        {"type": "audio", "audio": "voicemail.wav"},
        {"type": "text", "text": "Transcribe this and say if it's urgent."},
    ]}
])
print(result[0]["generated_text"])

Why It’s One of the Cheapest Models to Run

The memory-footprint reduction shows up as savings in two completely different deployment paths.

Hosted API pricing. Across hosted providers, Gemma 3n E4B has priced at a median of roughly $0.06 per million input tokens and $0.12 per million output tokens, well under half the median for comparable open-weight non-reasoning models (around $0.15 input / $0.32 output). For a workload that would otherwise burn through a mid-sized model’s token budget, that difference compounds fast:

# Rough monthly cost comparison for a support-summarization
# job processing 500M input tokens and 100M output tokens
gemma_3n_e4b = 500 * 0.06 + 100 * 0.12          # = $42.00
median_comparable_model = 500 * 0.15 + 100 * 0.32  # = $107.00
print(f"Savings: ${median_comparable_model - gemma_3n_e4b:.2f}/month")
# Savings: $65.00/month, at the same request volume

Self-hosted, on-device inference. The more radical cost lever is that E4B’s ~3GB footprint fits on a single consumer GPU, a laptop, or a modern phone via the Google AI Edge SDK. Once deployed, there is no per-token API charge at all, the entire idea behind Gemma 4’s later edge variants and the wider push toward on-device inference: for privacy-sensitive or high-volume applications (voice memo transcription, on-device chat, offline translation), moving inference off a metered API and onto hardware the user already owns turns a variable, scaling cost into a fixed, one-time one.

Where the Cost Story Actually Pays Off

The cheapest deployment path depends on the workload’s shape, not just its size:

The common thread is that E4B’s ~3GB footprint is small enough to make “run it yourself” a realistic option in cases where a larger model would force a team into a hosted API by default, simply because nothing else would fit on the target hardware.

Benchmark Performance: Strong on Chat Quality, Weaker on Hard Reasoning

Google’s own developer blog reported that E4B reached an LMArena score over 1300, the first model under 10 billion parameters to cross that mark, in the human-preference-style chatbot arena benchmark. That’s a genuinely notable result for a model this small. It’s worth pairing with a more sober data point, though: on Artificial Analysis’s Intelligence Index, a benchmark suite weighted toward harder reasoning and knowledge tasks rather than conversational preference, E4B scores well below the median for comparable open-weight models. The honest read is that E4B is very good at sounding helpful and natural for its size (which is most of what a support bot, a voice assistant, or a summarizer actually needs), while heavier reasoning, multi-step math, and knowledge-dense tasks are not where its budget was spent. This is also why, as of 2026, Artificial Analysis lists Gemma 3n E4B as deprecated in favor of Gemma 4’s newer E4B variant, which inherits the same effective-parameter naming and edge-first philosophy on a stronger base model.

Licensing

Gemma 3n ships under Google’s Gemma Terms of Use rather than a standard open-source license like Apache 2.0 or MIT: weights are freely downloadable (gated behind accepting the terms on Hugging Face or Kaggle) and commercial use is permitted, but subject to Google’s usage restrictions and prohibited-use policy, which is a meaningfully different legal posture than a fully permissive license even though the weights themselves are open.

What’s New (2025-2026)

Gemma 3n previewed in May 2025 and reached full release on June 26, 2025, with Hugging Face, Ollama, llama.cpp, MLX, and Google AI Edge all shipping support at launch. Through 2026, the model’s role shifted from “frontier small model” to “cheap, well-supported edge workhorse”: Google’s own roadmap moved capability leadership to Gemma 4, whose E4B variant reuses the MatFormer and PLE techniques 3n pioneered on a newer base, while Gemma 3n E4B remains widely deployed anywhere the deciding factor is a 3GB memory ceiling and near-zero inference cost rather than state-of-the-art reasoning, on phones, laptops, and cost-constrained backend services alike.

# A support-ticket triage tool that needs to run on a
# customer's laptop with no cloud API bill per request

ollama pull gemma3n:e4b
ollama run gemma3n:e4b "Classify this ticket: 'checkout button does nothing'"

# ~3GB of accelerator memory, no per-token API charge after
# the one-time download; same weights power the Google AI
# Edge SDK on Android for the identical trade-off on-phone.