gemma-4-31B-it-Ultra
Gemma 4 31B is the largest dense model in Google DeepMind's open family, and its defining quality is how little it spends to think. Running a full intelligence evaluation consumed roughly 39 million output tokens — a fraction of what comparably-scoring reasoning models needed, because it reaches its conclusion rather than circling it. A 131,072-token context window takes entire codebases or large image sets in one prompt, with a vision encoder that accepts variable aspect ratios rather than forcing everything square. Thinking is configurable, function calling is native, and it runs on a workstation under Apache 2.0.

Use gemma-4-31B-it-Ultra in VS Code, Cursor and Antigravity
DEVUP Code, the DEVUP AI extension, is free to install. Requests are paid from your DEVUP balance.
Gemma 4 31B Instruct
The largest dense model in the Gemma 4 family. 131,072-token context, native vision, Apache 2.0 — and unusually economical with its own reasoning.
It Thinks Efficiently
The number that distinguishes this model is not an accuracy score.
Running a full independent intelligence evaluation, this model consumed roughly 39 million output tokens. Reasoning models at a comparable intelligence level consumed two to four times as many for similar or marginally higher scores.
Why that matters more than a benchmark point. Reasoning models pay for their capability in output tokens, and the trace shares your budget with the answer. A model that reaches a conclusion in 39 million tokens where another needs 167 million is not marginally cheaper — it is a different cost structure for the same job.
On a production workload, that compounds. Every request. Every agent step. Every retry.
The generational jump is the other headline. Against the previous generation's flagship at a comparable size, this model gains twenty-nine points on the same intelligence index — one of the larger single-generation improvements in the open-weight field.
Built to Read
The design brief shows in what the model accepts.
A 131,072-token context window takes an entire codebase, a document set, or a large collection of images in a single prompt. Google position this tier at consumer GPUs and workstations rather than servers — server-class context on hardware you can put under a desk.
Vision is a first-class input. A vision encoder of roughly 550 million parameters handles variable aspect ratio and resolution — a 16:9 screenshot stays 16:9, a tall document stays tall. No preprocessing decision on your side, no detail lost to a resize you did not choose.
What that enables, in Google's framing: parsing UI screens, comprehending complex charts, and multilingual OCR and handwriting recognition. Text and images interleave freely in one prompt.
⚠️ What the Multimodal Claim Covers
Read carefully, because the family description invites a wrong assumption.
| Input | Supported here |
|---|---|
| Text | ✅ |
| Image | ✅ — variable aspect ratio and resolution |
| Video | ✅ |
| Audio | ❌ — native on E2B, E4B, and 12B only |
Audio does not work on this model. It is native to the three smaller models in the family — which means the largest model in the lineup has a narrower input surface than the smallest.
If your workload needs audio, the answer is a smaller Gemma 4, not a larger one. The 12B in particular is built as a unified model handling text, audio, image, and video without separate encoders.
Attention That Always Ends Global
The architectural choice behind the long-context behaviour.
Gemma 4 interleaves local sliding-window attention with full global attention, and Google state one constraint explicitly: the final layer is always global.
Local attention is cheap — each token sees a window, and cost stays flat as input grows. Global attention is expensive and exact. Alternating them buys most of the speed of a small model with the reach of a large one.
Fixing the last layer as global is what makes it trustworthy. Whatever the model produces, the final computation before it answers has seen the entire input rather than a neighbourhood of it.
Two memory optimisations on the global layers, which are where cache cost would otherwise concentrate:
Unified Keys and Values — shared rather than stored separately.
Proportional RoPE (p-RoPE) — positional encoding scaled for long contexts.
And multi-token prediction is available, reported to deliver 1.4× to 2.2× faster inference without accuracy loss.
Benchmark Results
As published by providers hosting this model.
| Benchmark | Score | What it measures |
|---|---|---|
| AIME 2026 | 89.2% | Competition mathematics, no tools |
| LiveCodeBench v6 | 80.0% | Code generation on recent problems |
| GPQA Diamond | 84.3% | Graduate-level science |
| MMMU Pro | 76.9% | Multimodal reasoning across disciplines |
Read these against the token-efficiency figure. AIME at 89.2% and GPQA at 84.3% are results you would expect from a considerably larger model — reached by a dense 31-billion-parameter model that spends less getting there than most.
MMMU Pro at 76.9% is the number that justifies the vision investment. It measures reasoning across images and text together rather than reading an image and answering separately, which is exactly the workload the variable-resolution encoder exists for.
AIME was measured without tools — the harder condition, meaning the mathematics result reflects the model rather than a calculator it was allowed to call.
Specifications
| Model ID | google/gemma-4-31B-it-Ultra |
| Parameters | 30.7B dense |
| Vision encoder | ~550M parameters |
| Context window | 131,072 tokens |
| Max output | 32,768 tokens |
| Input | Text, image, video |
| Output | Text |
| Audio input | Not supported |
| Attention | Interleaved local sliding-window and full global; final layer always global |
| Positional encoding | Proportional RoPE |
| Reasoning | Configurable thinking mode |
| Languages | 140+ |
| Licence | Apache 2.0 |
| Released | 2 April 2026 |
| Developer | Google DeepMind |
The licence changed with this generation. The previous generation shipped under Google's own Gemma Terms of Use; Gemma 4 is Apache 2.0 — permissive, standard, and one less legal question for a commercial deployment.
Quantisation varies by host. FP8, INT8, and NVFP4 builds all exist, and a suffix on a model identifier frequently encodes which.
Capabilities
| Capability | Value |
|---|---|
input_types | text, image, video |
output_types | text |
audio_input | Not supported |
context_window | 131072 |
max_output_tokens | 32768 |
image_aspect_ratio | Variable |
image_resolution | Variable |
reasoning | Configurable thinking mode |
streaming | Supported |
tool_calling | Native function calling |
structured_output | JSON output — without schema enforcement |
system_prompt | Native system role support |
requires_prompt | Yes — text prompt required, media optional |
JSON Without Schema Enforcement
A precise limitation worth knowing before you build an extraction pipeline.
The model accepts response_format for JSON output. It does not enforce a JSON schema.
You get JSON. You do not get a guarantee that the JSON matches a structure you specified — no required fields, no type checking, no enum constraints applied at generation time.
What that means in practice: describe the shape in the prompt, validate what comes back, and raise rather than defaulting on a parse failure. On an extraction pipeline running at volume, a silently empty object is a wrong answer wearing the costume of no answer.
Native System Prompt Support
New in Gemma 4, and worth noting because earlier generations lacked it.
The system role is supported natively rather than emulated by prefixing instructions to a user message. Instructions go where they belong, they persist across turns without being restated, and they are separable from the conversation for logging and review.
If you are migrating a prompt that folded system instructions into the first user message — a common workaround on earlier Gemma models — move them.
Using Gemma 4 31B on DEVUP AI
Base URL: https://api.devupai.com/v1 · Model ID: google/gemma-4-31B-it-Ultra
Python
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEVUP_API_KEY"],
base_url="https://api.devupai.com/v1",
)
response = client.chat.completions.create(
model="google/gemma-4-31B-it-Ultra",
messages=[
{"role": "user", "content": "Hello world!"}
],
max_tokens=1024,
)
print(response.choices[0].message.content)Node.js
import DevupAI from "devupai";
const client = new DevupAI({
apiKey: process.env.DEVUP_API_KEY,
});
async function main() {
const response = await client.chat.completions.create({
model: "google/gemma-4-31B-it-Ultra",
messages: [{ role: "user", content: "Hello world!" }],
max_tokens: 1024,
});
console.log(response.choices[0].message.content);
}
main();cURL
curl -X POST "https://api.devupai.com/v1/chat/completions" \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "google/gemma-4-31B-it-Ultra",
"messages": [
{ "role": "user", "content": "Hello world!" }
],
"max_tokens": 1024
}'Measuring the Efficiency Yourself
The token-efficiency claim is about a benchmark suite. Your workload is not a benchmark suite, and the same measurement takes a few minutes.
def measure(prompt: str) -> tuple[str, int, int]:
"""Return the answer with prompt and completion token counts."""
response = client.chat.completions.create(
model="google/gemma-4-31B-it-Ultra",
messages=[{"role": "user", "content": prompt}],
max_tokens=32768,
)
usage = response.usage
return response.choices[0].message.content, usage.prompt_tokens, usage.completion_tokens
total_out = 0
for prompt in your_real_prompts:
answer, tokens_in, tokens_out = measure(prompt)
total_out += tokens_out
print(f"{tokens_out:>6,} out · correct={check(answer)}")
print(f"\ntotal: {total_out:,} output tokens across {len(your_real_prompts)} prompts")Compare output tokens at equal accuracy, not accuracy alone. Two models that both solve your task can differ several-fold in what they spend doing it, and that difference is invisible in any leaderboard position.
Working With Images
Two habits that matter specifically on a model with variable-resolution support.
Send images at their native dimensions. Resizing to a square before upload is a workaround for models that require it, and this one does not — the resize discards detail the encoder would have used. Pipelines carried over from other models frequently keep the resize out of habit.
Interleave text and images freely. The model was built for prompts that mix them rather than for one image followed by one question. A sequence of screenshots with commentary between them is a shape it handles natively.
For OCR and handwriting, resolution is the variable that decides success. A page sent at full size reads; the same page downscaled does not, and no prompt recovers characters the encoder never received.
Reading the Reasoning
Thinking mode is configurable rather than always on. When enabled, reasoning arrives separately from the answer.
message = response.choices[0].message
trace = getattr(message, "reasoning_content", None)
if trace:
logger.debug("reasoning: %d characters", len(trace))
print(message.content)Keep the fields apart in both directions. Merging reasoning into the answer breaks structured-output parsing and puts a working draft in front of readers expecting a conclusion.
Reasoning tokens count toward your output budget. With a 32,768-token ceiling and thinking enabled on a hard problem, a budget sized for the answer alone will truncate the model mid-thought — though this model reaches its conclusion faster than most, which makes that ceiling less binding here than elsewhere.
The Family
Five sizes, and the modality table matters more than the parameter count.
| Model | Type | Context | Audio |
|---|---|---|---|
| E2B | Dense, edge | 128K | ✅ |
| E4B | Dense, edge | 128K | ✅ |
| 12B | Unified, encoder-free | 256K | ✅ |
| 26B A4B | MoE | 256K | ❌ |
| 31B | Dense | 256K | ❌ |
The 12B is the interesting one to know about. It is built as a unified model — text, audio, image, and video without separate encoders — which makes it the smallest complete multimodal option in the family and the one to reach for when audio is required.
The 26B A4B is the sparse alternative at this tier: comparable capacity, a fraction of the compute per token, on the same hardware class.
Variants and Suffixes
Repository and model names in this family carry meaningful suffixes, and reading them wrong gets you the wrong model.
-it — instruction-tuned. The one you call.
No suffix — the pre-trained base. It does not follow instructions.
-qat-* — quantisation-aware-training checkpoints for self-hosted deployment.
Provider-specific suffixes are hosting conventions rather than Google identifiers, usually encoding a quantisation or a serving tier. They are not part of the official model name and vary between platforms.
Where It Fits
Whole-codebase and whole-corpus work. 131,072 tokens takes a repository or a document set without a retrieval layer in front of it.
High-volume reasoning, where token efficiency is the cost lever rather than a benchmark footnote.
Screenshot and UI analysis — parsing interfaces, reading dashboards, comprehending charts, with variable resolution removing the usual preprocessing compromise.
OCR and handwriting recognition, across languages.
Agentic workflows, with native function calling and a 131,072-token window to hold accumulated state.
Mathematics and science, where the benchmark results land hardest.
Multilingual work across 140+ languages.
Self-hosted deployment, where Apache 2.0 and published quantisation checkpoints make it unusually well-equipped.
Not for audio. That lives on the smaller models in this family.
Practical Notes
Measure output tokens at equal accuracy when comparing models. That is where this one differs most.
Send images at native aspect ratio and resolution.
Use the system role natively rather than prefixing instructions to a user message.
Validate JSON output yourself — schema enforcement is not applied.
Budget output tokens for reasoning plus answer when thinking is enabled.
Check the modality table before choosing by size. Audio lives on the smaller models.
Enable MTP where your serving stack supports it.
Verify long-context behaviour on your own data before relying on the far end of 131,072 tokens.
Limitations
No audio input. Native on E2B, E4B, and 12B in the same family, absent here.
32,768-token output ceiling — a quarter of the context window, and shared with reasoning when thinking is enabled.
JSON output without schema enforcement. Validate what comes back.
Text output only. It reads images and video; it does not generate them.
A 31-billion-parameter dense model. Frontier-adjacent for its size and not frontier scale — the token efficiency is what it trades on, not peak capability.
Benchmark figures are provider-reported. Treat them as approximate and measure your own cases.
A base variant exists with a nearly identical name. Downloading the wrong one gets a model that does not follow instructions.
Quantisation varies by host. The same model at INT8, FP8, or NVFP4 does not behave identically at the margins.
Apache 2.0 is permissive, not unconditional. Read it against a commercial deployment.