जेमा 4 26B A4B

The sparse member of the Gemma 4 family, focused on latency: it activates fewer than 4B of its 26B parameters per token to deliver exceptionally fast tokens per second. It keeps the multimodal text-and-image input and 256K context of its dense sibling, and Google likewise reports it outcompeting models twenty times its size. The cheapest vision-capable Gemma here.

This is the sparse member of the Gemma 4 family, and its whole design is a trade of stored parameters for spent ones. Google says it activates only 3.8 billion of its total parameters on each token, which is what produces the tokens-per-second it was built for, while the weights that sit idle still contribute the knowledge the model was trained with. The name carries the arithmetic: 26B total, roughly 4B active.

Like the rest of Gemma 4 it is published under the Apache 2.0 licence, so the weights can be downloaded, inspected, fine-tuned and shipped in a commercial product with no gate in front of them. Google sized this member to run and fine-tune on hardware people actually have - a single 80GB accelerator unquantized, consumer GPUs quantized - so the choice between running it yourself and calling it here is a real one, decided by whether the data has to stay on your machine.

The reason to take the sparse model seriously is how little it gives up. Against the dense 31B, Google reports 82.6% against 85.2% on the multilingual MMMLU, 73.8% against 76.9% on MMMU Pro, 88.3% against 89.2% on AIME 2026, 77.1% against 80.0% on LiveCodeBench v6, 82.3% against 84.3% on GPQA Diamond, and 85.5% against 86.4% on the retail split of tau2-bench. A few points across the board, for a model activating roughly an eighth as many parameters per token.

It inherits the family's build features rather than a reduced set: function calling, structured JSON output and native system instructions for agent work, native image and video input at variable resolutions with optical character recognition and chart reading, training across more than 140 languages, and a 256K context window.

What it is not is the top of its own family. The dense 31B is ahead on every row Google published, and the gap widens on the hardest ones, so the sparse model is the choice when throughput or cost per token decides the workload rather than the last few points of quality. Audio input, as with the 31B, belongs to the two edge sizes.