ModelsGemmagemma-4-31B-it-Ultra
providergoogle /

gemma-4-31B-it-Ultra

94.5 DZD in 266 DZD out/ 1M tokens

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.

PublicJSONVideoStreamingApache-2.0
gemma-4-31B-it-Ultra
Capabilities
ToolsVisionReasoning (optional)Structured output
ArchitectureTransformer
Context Window131K

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.

Explore DEVUP Code

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.

InputSupported 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.

BenchmarkScoreWhat it measures
AIME 202689.2%Competition mathematics, no tools
LiveCodeBench v680.0%Code generation on recent problems
GPQA Diamond84.3%Graduate-level science
MMMU Pro76.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 IDgoogle/gemma-4-31B-it-Ultra
Parameters30.7B dense
Vision encoder~550M parameters
Context window131,072 tokens
Max output32,768 tokens
InputText, image, video
OutputText
Audio inputNot supported
AttentionInterleaved local sliding-window and full global; final layer always global
Positional encodingProportional RoPE
ReasoningConfigurable thinking mode
Languages140+
LicenceApache 2.0
Released2 April 2026
DeveloperGoogle 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

CapabilityValue
input_typestext, image, video
output_typestext
audio_inputNot supported
context_window131072
max_output_tokens32768
image_aspect_ratioVariable
image_resolutionVariable
reasoningConfigurable thinking mode
streamingSupported
tool_callingNative function calling
structured_outputJSON output — without schema enforcement
system_promptNative system role support
requires_promptYes — 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

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

JAVASCRIPT
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

BASH
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.

PYTHON
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.

PYTHON
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.

ModelTypeContextAudio
E2BDense, edge128K✅
E4BDense, edge128K✅
12BUnified, encoder-free256K✅
26B A4BMoE256K❌
31BDense256K❌

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.