Gemma's Version History: 1, 2 and 3

Three generations of Gemma share a name, a tokenizer lineage and a chat format, and disagree about almost everything else that appears in your code. This is the timeline arranged by what breaks.

Gemma 1, February 2024

Google announced Gemma on 21 February 2024, at 2B and 7B, in base and instruction-tuned form. It established the properties the family still carries: a decoder-only transformer, a SentencePiece vocabulary inherited from Gemini at 256K entries, an 8,192-token context, and the start-of-turn chat format with no system role. It also established the licence, the Gemma Terms of Use, which has governed every release since.

A 1.1 refresh followed in April 2024, retuning the instruction-tuned checkpoints without changing the architecture. It is a different set of weights under the same shape, which is exactly the situation that makes revision pinning worth the small effort.

The release was also a policy statement as much as a technical one: Google publishing open weights derived from the same research line as its closed frontier models, under a licence that permits commercial use. That framing explains a good deal of what follows in the timeline, including why the licence has restrictions and why the family has consistently optimised for what people can actually run.

Gemma 1 also set the naming convention the rest of the family follows, and it is worth reading correctly because it encodes real differences. A repository name carries the generation, the size, and a suffix: -it for instruction-tuned, nothing for the base model. Base and instruction-tuned checkpoints share a tokenizer and an architecture and behave completely differently, because only the tuned ones were trained on the chat format. Roughly every question in this cluster about templates, stop tokens and system prompts is a question about an -it checkpoint.

The variant family

Through 2024 Google shipped derivatives that share the Gemma name and not the Gemma shape, and confusing one for a generation is a common mistake when reading old issue threads.

• CodeGemma — code-specialised, with fill-in-the-middle support and its own sentinel tokens. The chat format is not the general Gemma one.
• PaliGemma — a vision-language model pairing a SigLIP encoder with Gemma, and the ancestor of Gemma 3’s multimodality. Its prompt format is task-prefix based, not conversational.
• RecurrentGemma — built on a different architecture with a fixed-size state rather than a growing KV cache, aimed at long sequences on small memory.
• ShieldGemma — safety classifiers rather than chat models. They score content; they are not general assistants.

Gemma 2, June 2024

Gemma 2 arrived on 27 June 2024 at 9B and 27B, with a 2B following at the end of July. The context window stayed at 8,192 and the vocabulary stayed at 256K, so token counts and prompt budgets transferred unchanged from Gemma 1. What changed was internal.

• Alternating local and global attention, with a 4,096-token sliding window on the local layers. This is the change with the widest blast radius for anyone implementing inference, and it has its own page.
• Logit soft-capping in attention and on the output logits, which several fast attention kernels did not support at release.
• A larger top size. 27B was a meaningful step up from 7B, and it was chosen to fit a single high-memory accelerator rather than to hit a round number.
• Knowledge distillation for the smaller sizes, trained against a larger teacher rather than from scratch on tokens alone, which is much of why Gemma 2 2B punched above its size.
• Grouped-query attention and both pre- and post-normalisation, details that matter to anyone porting the architecture and to nobody calling an API.

Gemma 3, March 2025

Gemma 3 shipped on 12 March 2025 at 1B, 4B, 12B and 27B, and it is the generation that breaks the most assumptions.

• Context went to 128K on 4B and above, and 32K on the 1B. The interleaving ratio changed to five local layers per global one, with a higher RoPE base on the global layers.
• Vision arrived on 4B and above through a shared SigLIP encoder, with a fixed per-image token cost and adaptive cropping. The 1B remains text-only. See the image-input page.
• The vocabulary changed to 262,144 entries from a newer Gemini tokenizer, with better non-English coverage. Any token count measured on Gemma 2 is an estimate on Gemma 3, not a fact.
• The template stopped refusing system messages. It accepts the role and folds it into the first user turn, which removes an exception without changing what the model sees.
• Official quantisation-aware-training checkpoints followed shortly after release, aimed at running the larger sizes on single consumer GPUs at materially less quality loss than post-training quantisation.

Google also introduced Gemma 3n during 2025, targeted at on-device use with a different architecture again. It is a sibling line rather than a successor generation, and its properties should not be assumed from Gemma 3’s.

The through-line across all three generations is worth naming, because it predicts what the next one will do. Every Gemma release has spent its innovation budget on getting more capability out of a fixed serving cost rather than on raising the ceiling: distillation into the small sizes, attention interleaving to shrink the cache, quantisation-aware checkpoints so the large sizes fit on one consumer card. The family is not competing on being the biggest thing available. It is competing on what you can run on hardware you already have, and every architectural decision in the timeline above reads more sensibly through that lens.

What does not carry between generations

If you are moving code from one Gemma generation to another, these are the assumptions to re-check, in rough order of how quietly they fail:

1. Token counts. The Gemma 3 vocabulary differs, so cost and context-pressure estimates need remeasuring against the new tokenizer.
2. Context budgets. Code with 8,192 hard-coded works on Gemma 3 and wastes almost all of it.
3. System-message handling. A fold you wrote for Gemma 2 is harmless on Gemma 3 but now duplicates what the template does. Do it once, not twice.
4. Modality assumptions. Gemma 3 1B has no vision tower, so “Gemma 3 does images” is false for one of the four sizes.
5. Inference implementations. Attention pattern, RoPE configuration and soft-capping all changed at least once. A serving stack that predates a generation will load it, or appear to.

What does carry across all three is short and worth stating so you know where you can be lazy. The turn format is unchanged: the same <start_of_turn> marker, the same user and model role words, the same <end_of_turn> terminator. A parser or a stop-token configuration written for Gemma 1 still works on Gemma 3. The licence is unchanged in kind, and so are the naming conventions. Everything numeric, and everything about modality, is generation-specific.

The most reliable way to work with a family that moves like this is to stop treating “Gemma” as the unit. The unit is a checkpoint at a revision: it has a window, a vocabulary, a modality and a template, and every one of those is readable from the files you downloaded. Code that asks the checkpoint survives a generation change; code that hard-codes a number from an article does not.

There is one more reason to keep the timeline straight, and it is about the internet rather than the models. Because the generations share a name, search results and forum answers about Gemma are an undated mixture of three different sets of facts, and the older ones rank well. An answer stating flatly that Gemma has an 8,192-token window and no vision was correct when it was written and is wrong now for most of the family. Check the date on anything you read about this family, including this page, and prefer the checkpoint to the prose.