gemma-4-26B-A4B-it

Gemma 4 26B A4B

Twenty-six billion parameters. Roughly four active per token. Apache 2.0.

The sparse member of the Gemma 4 family, positioned for consumer GPUs and workstations rather than servers or phones.

What A4B Means, and Why It Is the Headline

The name encodes the architecture. 26B total, A4B active — a Mixture-of-Experts model where only a fraction of the weights work on any given token.

Google's own framing is direct: this is an excellent choice for fast inference compared to the dense 31B model in the same family, precisely because it activates fewer parameters.

That comparison is the useful one. The 31B sibling is dense — every parameter runs on every token. This model holds comparable capacity and pays a small fraction of the compute per token, which is the difference between a model you run on a workstation and one you run on a server.

Attention That Ends Where It Should

The architectural detail worth understanding, because it explains the model's long-context behaviour.

Gemma 4 interleaves local sliding-window attention with full global attention, and Google states one constraint explicitly: the final layer is always global.

Local attention is cheap — each token sees a window around it, and cost stays flat as input grows. Global attention is expensive and exact. Alternating them gives you most of the speed of a lightweight model with the reach of a heavy one.

Fixing the last layer as global is the part that matters. Whatever the model produces, the final computation before it answers has seen the whole input rather than a window of it. A model that ends on a local layer answers from a neighbourhood; this one answers from everything.

Two further memory optimisations on the global layers:

Unified Keys and Values — the two are shared rather than stored separately, cutting the cache footprint on exactly the layers that would otherwise dominate it.

Proportional RoPE (p-RoPE) — positional encoding scaled for long contexts.

Thinking Is a Channel, Not a Tag

Most reasoning models mark their thinking with a tag in the output stream, or return it in a separate response field. Gemma 4 puts it in the chat template structure itself:

<bos><|turn>system {system_prompt}<turn|>
<|turn>user {prompt}<turn|>
<|turn>model <|channel>thought <channel|>

<|channel>thought is part of the turn format. The model's reasoning occupies a named channel within its own turn rather than being interleaved with the answer and separated afterwards.

Google describes reasoning as built-in across every model in the family, with configurable thinking modes — deliberation is a setting rather than a fixed behaviour.

The practical effect through an API is the same as any reasoning model: reasoning arrives separately from the answer, and should stay separate. The structural difference matters if you are self-hosting or building a custom serving layer, where you construct the template yourself.

Images: Variable Aspect Ratio and Resolution

Unusual enough to call out.

Most vision models fix an input size and resize everything to it — square, or a small set of preset dimensions. A wide screenshot gets letterboxed or squashed; a tall document gets downscaled until the text disappears.

Gemma 4 supports variable aspect ratio and resolution across every model in the family. A 16:9 screenshot stays 16:9. A tall page stays tall. No preprocessing decision has to be made on your side, and no detail is lost to a resize you did not choose.

⚠️ Audio and Video Are Not on This Model

Worth reading carefully, because the family description is easy to misread.

Gemma 4 is described as handling text, image, video, and audio. Video and audio are native to E2B, E4B, and 12B only. This model — and the 31B — process text and image.

The larger models in this family have a narrower input surface than the smaller ones. That inverts the usual assumption, and it is the single most likely source of a wrong model choice here.

If your workload needs audio or video, the answer is a smaller model in the same family, not a larger one.

Specifications

Context window is not stated in the sources consulted. Confirm it from the model configuration rather than assuming a figure from a sibling model.

Capabilities

The Family, and Where This Sits In It

Five sizes, spanning phones to servers.

The E in E2B and E4B stands for effective parameters, not a size in the usual sense.

This model is the only MoE in the lineup, which is why it appears alongside the 31B in deployment targets despite carrying less active compute.

Drafter Models and Speculative Decoding

A detail that matters if you self-host and is invisible through an API.

Google publishes drafter models alongside the main checkpoints — tiny companion models used for speculative decoding, where a small model proposes tokens and the large one verifies them in batches.

The drafters are genuinely small: a multi-token-prediction drafter under 300 MB, and a separate variant under 500 MB, against roughly 15 GB for the quantised main model. Adding one costs almost nothing in memory and can substantially raise throughput.

Quantisation-aware training checkpoints are also published in several formats — unquantised QAT weights, ready-to-run GGUF, compressed tensors for vLLM, and a mobile schema for the smaller family members. QAT preserves quality close to full precision while dramatically reducing what it takes to load the model.

Using Gemma 4 26B A4B on DEVUP AI

Base URL: https://api.devupai.com/v1 · Model ID: google/gemma-4-26B-A4B-it

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-26B-A4B-it",
    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-26B-A4B-it",
    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-26B-A4B-it",
    "messages": [
      { "role": "user", "content": "Hello world!" }
    ],
    "max_tokens": 1024
  }'

Reading the Reasoning

Because reasoning occupies its own channel in the template, it 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 two apart in both directions. Merging reasoning into the answer breaks structured-output parsing and puts a working draft in front of readers who asked for a conclusion.

Variants Worth Distinguishing

Several repositories carry near-identical names, and they are not interchangeable.

-it — instruction-tuned. This model. The one you call.

Without -it — the base model. Pre-trained only, for further training rather than direct use.

-assistant — a separate published variant with its own repository.

-qat-q4_0-* — quantisation-aware-training checkpoints in various formats, for self-hosted deployment at reduced memory.

-DFlash — a drafter model for speculative decoding, published under a separate organisation.

Through an API this distinction is handled for you. If you are downloading weights, reading the exact suffix is the difference between an instruction-following model and a base checkpoint that will not follow instructions at all.

Where It Fits

The sparse choice in the family. Capacity closer to the 31B, compute per token closer to a much smaller model. If you were choosing between the two on a workstation, this is the one that leaves headroom.

Text and image work — document understanding, screenshot reading, chart analysis, visual question answering, with the variable-resolution support removing the usual preprocessing compromise.

Reasoning and agentic workflows, which Google names as design targets alongside coding and multimodal understanding.

Self-hosted deployment, where Apache 2.0, published QAT checkpoints, and drafter models make it unusually well-equipped compared to most open releases.

Not for audio or video. Those live on the smaller models in this family.

Practical Notes

Check the modality table before choosing by size. The larger models here read less than the smaller ones.

Send images at their native aspect ratio. The model handles it, and resizing beforehand discards detail for no reason.

Keep reasoning content in its own field in both directions.

Confirm the context window against your serving configuration.

If you self-host, pair the model with a drafter — the memory cost is negligible against the throughput gain.

Read the repository suffix carefully when downloading weights.

Limitations

No audio or video input. Available on E2B, E4B, and 12B in the same family, not here.

Text output only. It reads images; it does not generate them.

Context window is undocumented in the sources consulted. Verify before designing around a figure.

MoE sparsity is a compute trade, not a memory one. All 26 billion parameters must be loaded even though roughly four billion run per token — the saving is in speed, not in VRAM.

A base variant exists with an almost identical name. Downloading the wrong one gets you a model that does not follow instructions.

Open weights do not mean unrestricted use. Apache 2.0 is permissive; read it against your deployment rather than assuming.

Reasoning traces are working notes. Treat the answer as the output and the trace as debugging material.