Gemma

Why this family matters

Gemma is Google's open-weights line, distinct from the closed Gemini API family. The current generation (Gemma 4) brings a meaningful architectural change: alongside the dense 31B variant, the family now ships a 26B-A4B mixture-of-experts build (26B total parameters, ~4B active per token), plus efficiency-tuned e2b and e4b variants sized for edge and on-device deployment.

The structural pull onto Gemma is self-host fit. The 26B-A4B MoE costs and serves like a small model on capable hardware while landing at Quality Score 83.9 (#48 of 186 models we track), which is competitive with dense models 3 to 5 times its active-parameter footprint. The dense 31B at QS 88.6 is the family's quality ceiling; the e2b and e4b variants are the cost-efficiency frontier for constrained hardware.

Which variant to start with

Default to google-gemma-4-26b-a4b-it. At $0.06 input / $0.33 output per million on hosted routes (or proportional self-host cost) and Quality Score 83.9 with a 262K context window, it is the family's quality-per-active-param sweet spot. Pick this unless you have a specific reason not to.

When to deviate:

• Maximum quality within the family: use google-gemma-4-31b-it (QS 88.6, dense 31B). The score gap to 26B-A4B is modest (3 points of Quality Score), but for deployments that benefit from dense inference characteristics or where MoE serving is awkward, the dense variant is the cleaner option.
• Self-host on a single GPU: the choice depends on what you are optimising for. The 26B-A4B MoE has the active-param footprint of a 4B model but the full weights still need to fit in memory; plan for the full 26B parameter count when sizing GPU memory, not the active subset. The dense 31B is heavier on memory but simpler to serve. Below those, the e4b variant is the realistic single-GPU consumer-hardware target in the family.
• Edge or on-device: drop to google-gemma-4-e2b-it (QS 62.5, efficiency-tuned). Smallest Gemma 4 variant; fits CPU and small-footprint inference where round-trip latency rules out hosted APIs. Treat its score as directional, not comparative against the larger variants.
• You are migrating an existing Gemma 3 deployment: the Gemma 3 line is still in our index, but the 27B at QS 58.9 (and the smaller variants below it) lag the Gemma 4 generation by enough that the migration cost is almost certainly earned by the score uplift, particularly if the deployment is recent enough that fine-tunes or pinned weights are not the constraint.

Where the data is weak

We aggregate benchmark scores from multiple sources but coverage and naming across this family deserve a careful read. Specifically:

• Gemma 3 vs Gemma 4 is a generation gap, not a minor version bump. Gemma 4 31B at QS 88.6 vs Gemma 3 27B at QS 58.9 is a difference of nearly 30 Quality Score points on otherwise comparable parameter counts. Do not collapse "Gemma 27B" and "Gemma 31B" into one mental category; they are different generations.
• e2b and e4b efficiency variants have thinner benchmark coverage than the dense and MoE variants. Several benchmarks (LiveBench, AIME, SWE-Bench) carry numbers for 31B / 26B-A4B but not for the efficiency variants at last verification. Treat their listed scores as directional, particularly outside Quality Score and Arena ELO.
• Context windows on the e-variants are not declared in our index. Gemma 4 31B and 26B-A4B both ship at 262K; the e4b and e2b context fields are unset. That is a coverage gap, not evidence of a smaller window.
• Hosted-vs-self-host pricing. The pricing on this page is what hosted inference providers charge for Gemma, not the cost of self-hosting (which depends on your own hardware and utilisation). For an open-weights family, list price is the calibration anchor for cross-family comparison; the deployment cost question is on you.
• The Gemma 3n line. The 3n variants (e2b, e4b) appear alongside Gemma 3 in our index but are an efficiency-tuned derivative, not a drop-in for Gemma 3. Their scores are weaker than the larger Gemma 3 variants and substantially weaker than Gemma 4 e-variants; they exist for niche on-device use cases, not general workhorse deployment.

If you are making a procurement decision (or, more often for this family, a deployment-architecture decision), the variant table on this page is the load-bearing artifact. Cross-check the open-weights license terms against your use case before you commit; Gemma's licence is permissive but specific.

When to reach for which alternative

• Open-weights breadth across model sizes: the Qwen3 family ships dense models from 0.6B to 32B plus MoE variants, which gives a wider spread than Gemma's current lineup, particularly at the smaller end. Pick by which family's smallest deployable variant fits your hardware budget and licence requirements.
• Cheapest competent open-weights API: DeepSeek V4 Flash ($0.098 / $0.197 with QS 78.1 and 1M context) is the price anchor to beat at the chat workhorse tier. Gemma 4 26B-A4B competes on the open-weights story; DeepSeek wins on hosted-API quality-per-dollar at the chat tier.
• You need a closed Google option for the same workload: the Gemini 3 surface in our index covers Google's current closed line. Gemma is not a drop-in for Gemini in either direction; the licence and deployment story differ enough that the surfaces are best evaluated separately, not as a tier-ladder.

Sources worth reading

• Gemma model docs: authoritative variant identifiers, license terms, and intended use
• Gemma on Hugging Face: model cards, weights, and per-variant license information
• Google Gemma announcements: release notes for new generations