Gemma is the open model line from Google DeepMind, built from the same research as Gemini but released as downloadable weights you run yourself. Gemma 4 ships under Apache 2.0 in sizes that fit a phone, a Raspberry Pi, or a single consumer GPU.
Used this tool? Rate it
Used this tool? Rate it
Gemma is the open model family published by Google DeepMind. On its own product hub the line is introduced as "Gemma / Our most capable open models", and it sits in a navigation column labelled Open models, deliberately separated from Gemini, Veo and Imagen — the proprietary lines you reach through an API rather than download. That placement is the single most important fact about this entry, because it defines what you actually get: not an account and a usage meter, but model weights you fetch, host and operate yourself.
It is worth being precise about the naming, because this is where most confusion starts. Google DeepMind is a research organisation. Gemini is its flagship proprietary model family, served through Google's own products and APIs. Gemma is the open sibling — built, in the words of the Gemma 4 page, as "Our most intelligent open models, built from Gemini 3 research and technology to maximize intelligence-per-parameter". The three names are routinely conflated by directory sites and news aggregators, but they describe different things: an organisation, a hosted model, and a downloadable one. This page is about the third.
The design intent behind Gemma follows directly from that openness. Google's stated goal is portability rather than raw leaderboard supremacy: "Our most advanced open models help developers create AI applications that run wherever users need them — from cloud servers to laptops and even phones." Everything else about the family — the unusual spread of parameter sizes, the mixture-of-experts variants, the per-layer embedding tricks in the small models — is downstream of that sentence. Gemma is engineered so that the same model family can be deployed on a Jetson Nano and on a rack of accelerators without switching vendors or rewriting an application.
There is a second consequence of openness that matters practically. Because the weights are distributed rather than served, there is no BeautyPlus-style signup flow, no seat count, and no per-token invoice from Google for running the model. What replaces those things is a licence, a hardware bill, and an operational burden that you own. Understanding where each of those falls is most of the work of evaluating Gemma, and it is the substance of the sections below.
Google also frames Gemma as an instrument of responsible deployment rather than a raw research artefact. The one-line positioning attached to the Open models column reads "Build responsible AI applications at scale", and the family ships with dedicated safety-classifier variants alongside the general-purpose models. Whether that framing holds up in practice depends heavily on what you build around the model — a point the official documentation makes bluntly, and which the Limitations section revisits.
The hardest part of adopting Gemma is not installation; it is picking the right rung on the ladder. The sizes are not interchangeable, and the deciding factor is usually the hardware you already have rather than a benchmark table.
The edge tier (E2B, E4B). Google positions these explicitly for constrained devices: "Audio and vision support for real-time edge processing. They can run completely offline with near-zero latency on edge devices like phones, Raspberry Pi, and Jetson Nano." Offline operation is the headline property. If your requirement is that inference must work with no network — in a vehicle, a clinic, a factory floor, a rural classroom — this tier is the reason to look at Gemma at all. In exchange you accept a shorter context window and materially weaker performance on hard reasoning and long-document retrieval.
The workstation tier (12B, 26B A4B, 31B). These target consumer graphics cards rather than datacentre accelerators. Google's framing is that they deliver "Advanced reasoning for IDEs, coding assistants, and agentic workflows. These models are optimized for consumer GPUs — giving students, researchers, and developers the ability to turn workstations into local-first AI servers." The 26B A4B is the interesting middle option: it carries 25.2B total parameters but activates roughly 3.8B at inference, so it behaves closer to a small model in speed while retaining more capacity. The 31B dense model, at 30.7B parameters with a 256K window, is the top of the range.
The previous generation still matters. Gemma 3 has not disappeared. It remains available in 270M, 1B, 4B, 12B and 27B sizes with a 128K-token window, and Google's own description — "Gemma 3's 128K-token context window lets your applications process and understand vast amounts of information, enabling more sophisticated AI features" — still describes a serviceable model. The 270M size in particular has no Gemma 4 equivalent, so for extremely small footprints the older generation is sometimes the only option. Crucially, the licences differ between generations, which the next section covers.
A practical selection heuristic: start from your deployment target, not from a leaderboard. If it must run offline on a handheld device, you are in the edge tier and should validate quality against your actual tasks early. If you have a single modern consumer GPU and want a local coding or agent assistant, start at 12B and move up only if quality demands it. If you need speech input, restrict yourself to E2B, E4B or 12B. If you need maximum quality and have the hardware, the 31B dense model is the ceiling of the family.
This is the section worth reading twice, because the single most commonly repeated statement about Gemma — "Gemma is Apache 2.0 licensed" — is only true of the current generation.
Gemma 4 did move to a genuinely standard open-source licence. Google's open source blog states it plainly: "Gemma 4 models are the first in the Gemmaverse to be released under the OSI-approved Apache 2.0 license." The official model card confirms it in machine-readable form, with the front matter field reading simply "license: apache-2.0". For Gemma 4, then, you are working with an OSI-approved permissive licence with the redistribution and commercial-use properties developers expect from it.
Earlier generations are a different matter. Repository metadata on Hugging Face's official Google organisation shows the split clearly: Gemma 4 repositories carry the apache-2.0 tag, while gemma-2, gemma-3n and gemma-7b repositories are still tagged with Google's custom "gemma" licence. A third-party version history records the same transition, noting that Google released Gemma 4 "under the free and open-source Apache 2.0 license" while the earlier generations were distributed under source-available Gemma Terms of Use.
The practical consequence is concrete. If your compliance process approved "Gemma" as an Apache 2.0 dependency and your engineers then pulled a Gemma 3 or Gemma 2 checkpoint — perfectly reasonable, since those are still current, maintained and sometimes the better fit — the licence governing your deployment is not the one your process approved. Check the licence field of the specific repository you are downloading, every time, rather than relying on family-level statements including this one.
On adoption scale, Google reports that "Since first launch, the community has downloaded Gemma models over 400 million times and built a vibrant universe of over 100,000 inspiring variants, known in the community as the Gemmaverse." Those are vendor-reported figures without independent audit; they are useful as a signal that the ecosystem is not abandoned, and should not be read as a quality measure.
Distribution is deliberately spread across the tooling developers already use rather than funnelled through a Google property. The official hub lists platforms and integrations spanning Kaggle, Hugging Face, Keras, Ollama, PyTorch, Gemma.cpp, JAX, Google AI Edge, Google Cloud, Android, LM Studio and Unsloth.
For weights specifically, the Gemma 4 page separates download destinations from training and deployment routes, pointing downloads at Hugging Face, Ollama, Kaggle, LM Studio and Docker. In practice this means the fastest path depends entirely on your existing stack rather than on any Gemma-specific tooling:
Support is community- and documentation-shaped rather than contractual. The official hub points to "Official documentation, quickstarts, and guides to build applications with Gemma" and directs questions to a developer forum. There is no SLA, no support ticket queue and no account manager attached to downloading an open model — a trade-off that is obvious in principle but occasionally surprising in production.
Google publishes a benchmark table comparing Gemma 4 against its predecessor, and the generational jump on reasoning-heavy tasks is large. On AIME 2026 mathematics without tool use, the 31B model is reported at 89.2% against 20.8% for Gemma 3 27B. Other published figures on the Gemma 4 page cover arena ratings, competitive coding and graduate-level QA.
Two cautions apply to every number in that table. First, these are vendor-reported results, produced by the party with an interest in the outcome; they are a reasonable starting hypothesis, not an independent finding. Second, headline averages hide the size-dependent cliffs that matter most in deployment. Long-context retrieval is the clearest example: on the MRCR v2 eight-needle 128K retrieval measure, the model card reports 66.4% for the largest model with each smaller size dropping steeply below it. A model advertised as supporting a long window does not necessarily use that window reliably, and the gap between the top and bottom of the ladder on this measure is far wider than the gap on general knowledge benchmarks.
Independent commentary raises a related structural concern: analysis of the Gemma 4 technical report notes that it "credits data composition for the gain, then describes its training data in two sentences." Because the corpus is not described in detail, external parties cannot independently assess benchmark contamination or verify domain coverage. That does not invalidate the reported numbers, but it does mean the only benchmark that fully settles the question for your use case is one you run yourself, on your own held-out data.
Gemma suits developers, researchers and technical teams who want control over deployment more than they want convenience. If you are comfortable provisioning hardware, selecting a serving stack and owning the operational surface, the family gives you an unusually broad size ladder from one vendor with consistent tooling.
It suits organisations with hard constraints that hosted APIs cannot satisfy — offline operation, data residency, code confidentiality, or unit economics at volume that make per-token pricing untenable. In those cases the operational burden is not a drawback but the price of a requirement you cannot otherwise meet.
It suits people who intend to modify the model. Fine-tuning, quantising, distilling or embedding a model in a device image all require weights. If your plan involves any of those verbs, an open model is not one option among several; it is the only category that qualifies.
It is a poor fit for non-technical users who want to open a browser tab and get a result. There is no consumer product here. The AI Studio trial aside, using Gemma means engineering work. Anyone whose need is "chat with an AI assistant" is better served by a hosted product, quite possibly Gemini, and would find this entry an unnecessary detour.
It is also a questionable fit for teams that need contractual support guarantees. Documentation and a developer forum are the support model. If your procurement process requires a vendor with an SLA and an escalation path, an open model download does not provide one, regardless of how large the vendor behind it is.
Google's own documentation is unusually direct about the model's boundaries, and those self-reported limits are more useful than most third-party criticism because they are attributable.
It is not a knowledge base. The model card states that models "generate responses based on information they learned from their training datasets, but they are not knowledge bases. They may generate incorrect or outdated factual statements." Treat factual output as requiring verification, not as retrieval.
Training data has a cutoff. The documented pre-training cutoff is January 2025, covering web documents, code, mathematics, images and audio. Anything after that date is outside the model's knowledge, so time-sensitive applications need external retrieval regardless of model size.
Open-ended tasks are harder than well-specified ones. As the model card puts it, models "perform well on tasks that can be framed with clear prompts and instructions. Open-ended or highly complex tasks might be challenging." Prompt structure does real work here.
Capability is not uniform across the ladder. This deserves emphasis because it is the most common practical disappointment. Audio input exists only on E2B, E4B and 12B. Long-context retrieval degrades sharply on smaller models. A capability demonstrated on the 31B model should never be assumed to transfer to E2B.
Professional advice is out of scope. Google's own footer guidance is explicit: "Don't rely on LLMs for medical, legal, financial, or other professional advice. Any content regarding those topics is provided for informational purposes only and is not a substitute for advice from a qualified professional." The existence of MedGemma does not change this; a domain-tuned model is still not a clinician.
Training data transparency is limited. As noted above, independent analysis criticises the brevity of the training data description. You cannot fully audit what went into the model.
You inherit the operational burden. No hosted endpoint means you own uptime, scaling, security patching, GPU capacity planning and cost. For small teams this is frequently underestimated at the point of the decision.
The privacy posture of an open model is structurally different from that of a hosted service, and the difference cuts both ways.
On the upside, self-hosting means inference data need not leave your infrastructure at all. There is no vendor-side prompt logging to negotiate, because there is no vendor-side inference. For confidential workloads this is the strongest argument the whole category has.
On the training side, Google reports filtering work on the pre-training corpus: "As part of making Gemma pre-trained models safe and reliable, automated techniques were used to filter out certain personal information and other sensitive data from training sets", with CSAM filtering applied at multiple stages. This is a vendor statement about process, not an independent audit, and should be read as such.
The critical point for anyone deploying Gemma is that Google explicitly assigns downstream safety responsibility to you. The model card lists privacy violation as an identified risk and states that "Developers are encouraged to adhere to privacy regulations with privacy-preserving techniques." On content safety it is equally direct: "Developers are encouraged to exercise caution and implement appropriate content safety safeguards based on their specific product policies and application use cases."
That allocation is not a formality. With a hosted API, the provider's moderation layer sits between your users and the raw model whether you want it or not. When you download weights, that layer does not come with them. Guardrails, abuse monitoring, logging policy, age gating and regulatory compliance become artefacts you build. ShieldGemma 2 exists to help with part of this, but wiring it in is your work.
On the infrastructure side, Google states that "Gemma 4 models undergo the same rigorous infrastructure security protocols as our proprietary models", positioning the family as a trustworthy base for enterprise and sovereign deployments. That claim concerns how the models are produced and released, not how you subsequently operate them.
The honest comparison set for Gemma is other open-weight families rather than hosted assistants, because the decision to self-host comes first and the choice of which model to host comes second.
Against Gemini, the comparison is really a question about deployment model rather than quality. Gemini is served, managed and continuously updated by Google; Gemma is downloaded, self-operated and version-pinned by you. If you have no constraint forcing self-hosting, the hosted route is less work. If you do have such a constraint, Gemini cannot satisfy it at any price.
Against other open-weight families — the Llama, Qwen and Mistral lines being the usual comparators — Gemma's differentiators are the unusual breadth of its size ladder, particularly at the small end, the Apache 2.0 licence on the current generation, and the depth of official domain variants. Competitors move quickly, though, and any claim about which model leads on quality has a short shelf life. Evaluate on your own tasks at the moment of decision rather than trusting a general ranking, including this description.
Against running nothing locally at all, the calculus is straightforward: hosted APIs win on time-to-first-result and lose on data control, offline capability and marginal cost at scale. Gemma is worth the operational cost when at least one of those three factors is a hard requirement rather than a preference.
Within the family itself, the most underrated alternative is the previous generation. Gemma 3 offers a 270M size that Gemma 4 does not, and for very constrained deployments that can be decisive — provided you account for the different licence terms discussed above.
The weights are free to download, and there is no per-token charge from Google for running them, because you supply the compute. Gemma 4 is released under the OSI-approved Apache 2.0 licence. The real costs are hardware, electricity or cloud instance time, and the engineering effort of operating a model yourself. "Free" here means "no licence fee", not "no cost".
For Gemma 4, the Apache 2.0 licence permits commercial use, modification and redistribution under its standard terms. For earlier generations, verify separately: Gemma 2, Gemma 3n and other older repositories are still tagged with Google's custom gemma licence rather than Apache 2.0, and those custom terms carry use restrictions Apache 2.0 does not. Always check the licence field of the exact repository you download.
Gemini is Google's proprietary model family, accessed as a hosted service. Gemma is the open family whose weights you download and run yourself, built from related research — the Gemma 4 page describes it as built from Gemini 3 research and technology. Same lineage, opposite distribution models. Google DeepMind, meanwhile, is the research organisation that publishes both.
It depends entirely on the size you choose. E2B and E4B are built for phones and small boards including Raspberry Pi and Jetson Nano, and can run fully offline. The 12B, 26B A4B and 31B models target consumer GPUs. The 26B A4B is a mixture-of-experts design that activates roughly 3.8B of its 25.2B parameters at inference, so it runs faster than its total size suggests — often the best capacity-per-VRAM trade in the family.
Up to 256K tokens on the workstation tier, with the edge models carrying a smaller 128K window. Be aware that supporting a window and using it reliably are different things: on the model card's long-context retrieval measure, the largest model reaches 66.4% while smaller sizes fall away sharply. Test retrieval behaviour at your actual context length before designing around it.
Image and video understanding are available across the Gemma 4 line, and interleaved multimodal input is supported. Audio is the exception: the official model card restricts automatic speech recognition and speech-to-translated-text to E2B, E4B and 12B. If speech input is a requirement, the two largest models are not options.
Google states support for 140 languages and frames the goal as understanding cultural context rather than performing literal translation. As with any broad multilingual claim, quality varies considerably across that range, so validate performance in your specific target languages instead of assuming uniformity.
If you self-host, inference data need not leave your infrastructure, which is the strongest privacy property of the open-weight approach. But Google assigns downstream responsibility to you explicitly, encouraging developers to adhere to privacy regulations using privacy-preserving techniques. Data protection compliance, logging policy and content safeguards are yours to design and implement.
Yes — fine tuning is one of the five capabilities Google lists for the family, and the official distribution page routes to training tooling including Unsloth, Keras, JAX and GKE. The resulting model stays under your control, which is a principal reason teams choose open weights over a hosted API.
Gemma 4 is stronger on reasoning benchmarks and carries the more permissive Apache 2.0 licence, so it is the default choice. Gemma 3 remains relevant in two situations: when you need the 270M size, which has no Gemma 4 counterpart, and when existing tooling is already pinned to it. If you do choose Gemma 3, remember that its licence terms differ from Gemma 4's and must be reviewed independently.
