Gemma 4 31B Guide: Apache 2.0, 256K Context, One Big GPU

Previous Gemma releases came with a catch that mattered more than any benchmark: Google's own Gemma licence, with a use policy attached. Gemma 4 dropped it. The family shipped on 2 April 2026 under Apache 2.0, and the 31B instruction-tuned model is the largest and strongest member of it.

That makes this a different kind of model guide. The question is not whether Gemma 4 31B beats the frontier — it does not, and Google does not claim it does. The question is whether a dense 31B model you are free to fine-tune, ship and resell is good enough for your workload, and what it takes to run it.

What Google actually shipped

Gemma 4 launched with four sizes, and a fifth arrived later. According to Google's model card:

• E2B and E4B — small models for phones and edge devices, 128K context, with audio input.
• 12B — a later addition, 256K context, also with audio.
• 26B A4B — a mixture-of-experts model, 25.2B total with 3.8B active per token, 256K context.
• 31B — dense, 30.7B parameters across 60 layers, 256K context.

The 31B takes text and images and returns text. Video is handled as a sequence of frames rather than as a native stream; the model card caps that at 60 seconds at one frame per second. There is no audio input on the 31B, which surprises people who assume the biggest model gets every modality. If you need speech in, the smaller models are the ones that have it.

Two features matter for application work. Function calling is supported natively, and there is a configurable thinking mode: put the <|think|> token at the start of the system prompt and the model emits a reasoning block before its answer; remove it and it does not. Google notes that the 31B still emits an empty thought block when thinking is off, so make sure your parser tolerates one.

The numbers, and what to make of them

Google's model card reports these scores for the 31B instruction-tuned model:

• MMLU Pro — 85.2%
• GPQA Diamond — 84.3%
• AIME 2026 (no tools) — 89.2%
• LiveCodeBench v6 — 80.0%, with a Codeforces Elo of 2150
• Tau2 (average of three runs) — 76.9%
• MMMU Pro — 76.9%, MATH-Vision — 85.6%
• MRCR v2, 8-needle at 128K — 66.4%
• Humanity's Last Exam — 19.5% without tools, 26.5% with search

Read these as vendor numbers on vendor settings. The pattern is still informative: strong on knowledge, maths and competitive coding, respectable on vision, and clearly weaker on the hardest open-ended reasoning, where Humanity's Last Exam sits near 20%. The MRCR result is the one to note if you plan to lean on the 256K window — two-thirds on an 8-needle retrieval test at 128K says the window is usable but not lossless. Vendor-claimed vs independent benchmarks covers how far to discount a launch table.

31B dense or 26B MoE

The closest alternative is its own sibling. On Google's card the 26B A4B trails the 31B by a few points almost everywhere: 82.6 against 85.2 on MMLU Pro, 77.1 against 80.0 on LiveCodeBench v6, 82.3 against 84.3 on GPQA Diamond. The one wide gap is Tau2, the agentic tool-use benchmark, at 68.2 against 76.9.

The trade is compute. The MoE activates 3.8B parameters per token; the 31B activates all 30.7B. Memory needs are in the same range because the MoE still has to hold every expert, but per-token compute differs by roughly eight times, which shows up as throughput and latency on the same card. Dense vs mixture-of-experts explains why the two numbers diverge.

A simple rule: pick the 31B when the work is multi-step tool use or when the extra few points on hard tasks are worth paying for in latency. Pick the 26B A4B for high-throughput, latency-sensitive work where a small drop in quality is acceptable. The Gemma 4 26B A4B guide covers that side.

What it takes to run yourself

Google's model card gives no memory figures, so do the arithmetic. 30.7B parameters at 16-bit precision is roughly 61 GB of weights before any KV cache. That fits on a single 80 GB card with room for a moderate context, not for the full 256K under concurrency.

Quantisation changes the picture. At 8-bit the weights are around 31 GB; at 4-bit, roughly 16 to 18 GB depending on format. That puts a quantised 31B within reach of a 24 GB consumer card for short contexts, with the usual quality cost. Which open model fits your GPU walks through the KV-cache side, which is what actually limits long context on small cards.

If a local build misbehaves while the hosted model does not, compare the two on the same prompt before blaming the model. A wrong chat template, or a parser that chokes on the empty thought block, produces failures that look like poor quality.

Hosted access and the free variant

Google serves gemma-4-31b-it through AI Studio and the Gemini API, and third-party hosts serve it too. On OpenRouter it was listed at $0.20 per million input tokens and $0.40 per million output at the time of writing, with a 262,144-token context. There is also a :free variant — the same weights on a rate-limited endpoint, useful for trying the model and unsuitable for anything with a latency or uptime requirement.

Output caps vary by host, so check the provider's listing rather than assuming one figure. Since the weights are open, also check what precision a host serves; a cheap endpoint may be running a quantised build.

How to decide

1. Confirm the licence fits. Apache 2.0 is permissive, but check any fine-tuning data you add carries compatible terms. Licence terms vary a lot across the open-weight field, so compare before you commit.
2. Run twenty real tasks through the hosted 31B with thinking on and off. Record pass rate and output tokens; thinking costs tokens on every call.
3. Run the same tasks through the 26B A4B. If the gap on your work is small, the MoE's throughput usually wins.
4. Only then test the quantisation you would actually deploy. Quality loss from a 4-bit build is workload-specific and is the number most likely to surprise you.