GPU guide

Gemma 4 GPU requirements: sizes, VRAM and what to run it on

Gemma 4 in five sizes, E2B to 31B: parameters, file sizes, context window, Google's own memory table, KV cache and which GPU holds each on vLLM and Ollama.

Faiz Ahmed11 min read

Gemma 4 comes in five sizes, and the largest, the 31B, needs about 70 GB of GPU memory to load at full precision and about 17.5 GB at 4-bit, by Google's own table. The small sizes, E2B and E4B, are built for phones and laptops, and the 12B runs in 16 GB. A cloud GPU matters for the 26B A4B and the 31B: one 48 GB card runs either at 4-bit with a long context, and one 80 GB or 96 GB card runs them at full precision.

The five Gemma 4 sizes#

Gemma 4 is Google DeepMind's open model family, released on 2026-04-02 in four sizes and joined by the 12B on 2026-06-03. These are the figures on Google's model card, with the BF16 file size of each instruction-tuned repository on Hugging Face:

SizeParametersLayersContext windowInputBF16 weights
E2B2.3B effective, 5.1B with embeddings35128KText, image, audio10.25 GB
E4B4.5B effective, 8B with embeddings42128KText, image, audio15.99 GB
12B11.95B48256KText, image, audio23.92 GB
26B A4B25.2B total, 3.8B active30256KText, image51.61 GB
31B30.7B60256KText, image62.55 GB

The E in E2B and E4B stands for effective parameters: these two carry large per-layer embedding tables that are only looked up, so their files are bigger than the name suggests. The A in 26B A4B stands for active. It is a mixture-of-experts model that uses 8 of its 128 experts per token plus one shared expert, and Google's documentation is clear that "all 26 billion parameters must be loaded into memory", so size it as a 26B model. Every size also reads video as a sequence of frames, up to 60 seconds at one frame per second, and the three audio-capable sizes take up to 30 seconds of audio.

The context window is 128K tokens for E2B and E4B and 256K for the other three. The configs set it to 131,072 and 262,144 tokens.

Gemma 4 is released under the Apache 2.0 licence, which Google calls "commercially permissive" in its launch post. The Hugging Face repositories are tagged apache-2.0 and are not gated, so you need no token and no click-through to download them.

Memory to load each size#

Google publishes a memory table for Gemma 4 in its documentation. It covers loading the weights only, with 20% added, and Google notes that it does not include the context window:

SizeBF16 (16-bit)SFP8 (8-bit)Q4_0 (4-bit)
E2B11.4 GB5.7 GB2.9 GB
E4B17.9 GB8.9 GB4.5 GB
12B26.7 GB13.4 GB6.7 GB
26B A4B57.7 GB28.8 GB14.4 GB
31B69.9 GB34.9 GB17.5 GB

Those figures follow from the files. The 31B's BF16 weights are 62.55 GB, which is 58.25 GiB, and 58.25 x 1.2 is 69.9 (our calculation). The 8-bit column is half of that and the 4-bit column a quarter.

For 4-bit, Google ships its own quantization-aware-trained builds, which it says keep quality close to BF16. Two of the four QAT formats Google lists matter on a GPU server. The Q4_0 GGUF files run on llama.cpp and Ollama, and the w4a16 compressed-tensors files run on vLLM:

SizeQAT GGUF Q4_0QAT w4a16 for vLLM
E2B3.35 GB8.32 GB
E4B5.15 GB11.51 GB
12B6.98 GB10.26 GB
26B A4B14.44 GBNot published
31B17.65 GB23.27 GB

Each GGUF repository also holds a separate projector file for multimodal input, between 0.18 GB and 1.20 GB. The GGUF guide explains the format.

KV cache at long context#

Gemma 4 keeps its cache small with two kinds of layer. Most layers use a sliding window of 512 or 1,024 tokens, so their cache stops growing after the window. The rest are global layers that see the whole context, and in the 12B, 26B A4B and 31B those global layers use unified keys and values, which lets an engine store one tensor where other models store two.

Only the global layers grow with the context. For the 31B that is 10 layers x 4 KV heads x 512 x 2 bytes = 40,960 bytes per token when keys and values are stored once, and twice that if an engine stores them separately (our calculation, 16-bit cache):

SizeGlobal layersPer token32,768 tokens131,072 tokens262,144 tokensSliding layers, per conversation
12B8 of 488 to 16 KiB0.25 to 0.5 GiB1 to 2 GiB2 to 4 GiB0.31 GiB
26B A4B5 of 3010 to 20 KiB0.3 to 0.6 GiB1.25 to 2.5 GiB2.5 to 5 GiB0.20 GiB
31B10 of 6040 to 80 KiB1.25 to 2.5 GiB5 to 10 GiB10 to 20 GiB0.78 GiB

E2B and E4B have seven global layers each and store at most 14 KiB and 28 KiB per token there, 1.75 GiB and 3.5 GiB at their full 131,072 tokens, and less in practice because they also share the cache across layers (our calculation, an upper bound). So a full 262,144-token conversation on the 31B costs between 10.8 and 20.8 GiB, and the low end applies only if the engine uses the unified layout. Check the GPU KV cache size line in vLLM's startup log for the real figure. The generic script in the KV cache guide overstates Gemma 4, because it reads the sliding-layer head settings.

Which QuantaCloud GPU holds which size#

The table shows the memory left for the cache after the weights. The budget is 92% of what each card reports in nvidia-smi, vLLM's default, in GiB (our calculation):

Size and precision48 GB card, 41.4 GiBA100 80 GB, 73.6 GiBRTX PRO 6000, 87.9 GiBH200 NVL, 129.2 GiB
E2B, BF16 (9.54 GiB)31.9 GiB64.1 GiB78.4 GiB119.6 GiB
E4B, BF16 (14.89 GiB)26.5 GiB58.7 GiB73.1 GiB114.3 GiB
12B, BF16 (22.28 GiB)19.1 GiB51.3 GiB65.7 GiB106.9 GiB
26B A4B, BF16 (48.07 GiB)Does not fit25.5 GiB39.9 GiB81.1 GiB
31B, BF16 (58.25 GiB)Does not fit15.3 GiB29.7 GiB70.9 GiB
31B, QAT w4a16 (21.67 GiB)19.7 GiB51.9 GiB66.3 GiB107.5 GiB

The 48 GB column covers the RTX A6000, RTX 6000 Ada, L40 and L40S with ECC on. These are upper bounds, before activations and CUDA graphs. Two 48 GB cards hold the BF16 31B as well, on size, with 24.5 GiB left across the pair, and the vLLM multi-GPU guide covers that setup.

Google's own sizing agrees with the 80 GB column: its launch post says the unquantized bfloat16 weights of the 26B and 31B "fit efficiently on a single 80GB NVIDIA H100 GPU". On an 80 GB A100 the 31B has 15.3 GiB left, enough for one 131,072-token conversation under either cache layout. The 96 GB RTX PRO 6000 leaves 29.7 GiB, which covers the full 256K context.

GPUMemoryFromAvailable now
RTX A600048 GB$0.48/GPU-hrYes
A100 PCIe 80GB80 GB$1.48/GPU-hrYes
RTX PRO 6000 Blackwell96 GB$2.16/GPU-hrYes
H200 NVL141 GB$3.43/GPU-hrYes

Prices checked 14 Nov 2026, 08:32 UTC

Laptop or cloud GPU#

The honest answer is that most of Gemma 4 does not need a rented GPU. E2B and E4B are made for phones and edge boards, and Google describes the 12B as "small enough to run locally with just 16GB of VRAM or unified memory". At 4-bit even the 31B is a 17.65 GB file, which a 24 GB consumer card holds with a short context.

A 48 GB card earns its price in four cases. The first is long context on the large sizes: Google's QAT 31B for vLLM leaves 19.7 GiB on a 48 GB card, where a 24 GB card has under 1 GiB left. The second is many users at once: the 12B at full precision leaves 19.1 GiB, enough for more than twenty conversations of 32,768 tokens (our calculation). The third is precision: the 12B, E4B and E2B run in BF16 on 48 GB, and the 26B A4B and 31B run in BF16 on an 80 GB or 96 GB card or on two 48 GB cards. The fourth is fine-tuning, which Google names as a purpose of the 31B, and the LoRA, QLoRA and full fine-tuning VRAM guide sizes that separately.

Run Gemma 4 with vLLM#

vLLM serves every Gemma 4 size. Its recipes give 0.19.1 as the minimum version for the 31B, E4B and E2B, 0.23.0 for the 12B and 0.25.0 for the 26B A4B. The setup is the one in the vLLM Docker guide: the Bare Metal template, the driver check that picks the image tag, and an API key in VLLM_API_KEY. On an A100 80 GB or an RTX PRO 6000:

Terminal
docker run -d --name vllm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  "vllm/vllm-openai:$VLLM_TAG" \
  google/gemma-4-31B-it \
  --max-model-len 32768 \
  --reasoning-parser gemma4 \
  --api-key "$VLLM_API_KEY"

On a 48 GB card, change the model to google/gemma-4-31B-it-qat-w4a16-ct, Google's 4-bit build for vLLM. The 26B A4B takes the same command with google/gemma-4-26B-A4B-it on an 80 GB card, and since Google publishes no vLLM 4-bit build of it, run it through Ollama on a 48 GB card. vLLM's recipe lists the H100 as verified for the 31B. The A100, the RTX PRO 6000 and the 48 GB cards are not on that list, so on them the fit is on size only: read the first startup log closely. --max-model-len 32768 is the value in vLLM's own example, and you can raise it as far as the table above allows. --reasoning-parser gemma4 returns the model's thinking separately when you switch thinking on. For tool calling, the recipe adds --enable-auto-tool-choice --tool-call-parser gemma4 and a chat template file from the vLLM repository. Add --language-model-only when you only send text. Stopping the instance deletes its disk, so each launch downloads the weights again.

Launch an A100 80 GB for Gemma 4 31B

Gemma 4 on Ollama#

The Ollama library carries all five sizes under gemma4. The library shows a size range for the short tags and one size for each explicit tag:

SizeShort tagq4_K_MQATq8_0bf16
E2Bgemma4:e2b, 4.6 to 7.5 GB4.6 GB4.3 GB6.0 GB10 GB
E4Bgemma4:e4b, 6.6 to 9.5 GB6.6 GB6.1 GB9.0 GB16 GB
12Bgemma4:12b, 7.7 to 8.0 GB8.0 GB7.2 GB13 GB24 GB
26B A4Bgemma4:26b, 16 to 19 GB18 GB16 GB28 GB52 GB
31Bgemma4:31b, 19 to 20 GB20 GB19 GB34 GB63 GB

gemma4:latest is the E4B, so pull gemma4:31b by name if you want the large model. The explicit tags spell out the size and the quantization, for example gemma4:31b-it-q8_0, gemma4:31b-it-qat and gemma4:26b-a4b-it-q8_0. Skip gemma4:cloud and gemma4:31b-cloud, which run on Ollama's servers and never download to your GPU. Ollama lists text and image as the inputs for every tag.

Every 4-bit and 8-bit tag fits one 48 GB card. Ollama picks its default context from the GPU's memory, and Ollama context length shows how to set it. The Open WebUI + Ollama template gives you a chat interface with no terminal work, and Open WebUI with Ollama covers it step by step.

Launch Open WebUI + Ollama on an RTX A6000

Gemma 4 hardware FAQ#

What are the Gemma 4 sizes?

Five: E2B, E4B, 12B, 26B A4B and 31B. E2B and E4B have 2.3B and 4.5B effective parameters, the 12B has 11.95B, the 26B A4B has 25.2B with 3.8B active, and the 31B has 30.7B.

What is the Gemma 4 context window?

128K tokens for E2B and E4B, and 256K tokens for the 12B, 26B A4B and 31B.

How much VRAM does Gemma 4 31B need?

Google's table gives 69.9 GB at BF16, 34.9 GB at 8-bit and 17.5 GB at 4-bit to load the weights. Add the cache for your context: between 10.8 and 20.8 GiB for one full 256K conversation, and far less for shorter ones (our calculation).

Can I run Gemma 4 on a laptop?

Yes for E2B, E4B and the 12B, which Google says runs in 16 GB. The 26B A4B and 31B take 14.4 GB and 17.5 GB to load at 4-bit by Google's table, and an 80 GB GPU at full precision.

Is Gemma 4 free for commercial use?

Yes. Gemma 4 is under the Apache 2.0 licence.


The rule I follow for Gemma 4 is to match the precision to the card. On 48 GB, run Google's QAT build of the 31B or the 12B at full precision. On 80 GB or 96 GB, run the 31B or the 26B A4B in BF16 and spend what is left on context. The LLM VRAM calculator checks other models against every GPU configuration, and how much VRAM you need covers the general rule.

Launch an RTX A6000

Keep building

Choose your next step.