Methodology

This page explains, in concrete terms, how the numbers on Gemma4All are produced — the hardware checker's verdicts, the memory tables in our guides, and the download sizes we quote. If you've ever wondered "where did that 6.7 GB come from?", this is the answer.

How we calculate memory requirements

Every model in our checker carries a minimum weight-loading footprint for each quantization level (BF16, SFP8, Q4_0), sourced from Google's official Gemma 4 documentation. That weight figure is the starting point, not the final answer — the checker then works out how much of your device's memory is actually usable, and whether the model fits comfortably or just barely.

Usable memoryis derived differently depending on the device, because the memory architectures aren't equivalent:

• Mac (unified memory): usable = total RAM − 5 GB. macOS and background processes reserve a chunk of the shared pool before your model ever loads, so we subtract a flat 5 GB overhead from the total.
• Dedicated GPU (VRAM): usable = total VRAM − 1 GB. A discrete GPU has its own memory pool separate from system RAM, and the driver plus display buffers claim a smaller, more predictable slice — so the overhead we subtract is smaller than on a Mac.
• CPU-only (system RAM): usable = total RAM ÷ 2. Running on CPU needs one copy of the weights plus roughly as much again in working memory for computation, so we budget half of total RAM as the practical ceiling.

Once we know usable memory, we walk the quantization levels from highest quality to lowest — BF16, then SFP8, then Q4_0 — and classify the fit into one of three verdicts:

• Comfortable:the model's weights fit within 80% of usable memory at that quant level, leaving headroom for the KV cache (context window) and normal multitasking.
• Tight:the weights fit within 100% of usable memory but exceed the 80% comfortable ceiling — it will load and run, but you won't have much room left for long conversations or other memory-hungry apps.
• Doesn't fit: even the smallest quant (Q4_0) exceeds usable memory.

The checker always recommends the best-qualityquant that clears the comfortable bar, rather than defaulting everyone to Q4_0 — if your hardware can comfortably run SFP8 or BF16, we'll say so.

Phones are handled as a special case, since mobile inference stacks (AI Edge Gallery, LiteRT) behave differently from desktop runtimes. Instead of the general usable-memory formula above, we check published int4 download sizes against fixed device-RAM thresholds: Gemma 4 E2B is comfortable at 8 GB of RAM and tight at 6 GB, while the larger E4B needs 12 GB to be comfortable and is tight at 8 GB. We use fixed thresholds here because mobile operating systems reserve memory far less predictably than desktop unified memory or VRAM.

Where our numbers come from

Every figure we publish traces back to one of a small number of source types:

• Official model documentation.The minimum weight-loading memory per quantization level (the numbers behind "comfortable / tight / doesn't fit") comes straight from Google's published Gemma 4 docs — we don't derive these ourselves.
• Published quantized file sizes. Actual download sizes for the official quantization-aware training (QAT) checkpoints come from the GGUF files Google shipped on Hugging Face and the corresponding Ollama model tags — these are measured file sizes, not calculations.
• Official QAT availability.Whether a model has a solid, full-quality official QAT checkpoint (as opposed to a community post-training quantization) is tracked per model, based on Google's own QAT release announcements.

What we estimate vs. what we measure

We think this distinction is the single biggest difference between Gemma4All and the AI-generated content mills that have flooded search results for "can I run [model]" queries. So here it is, plainly:

• Measured / sourced directly:minimum weight memory per quant level, QAT file sizes, context window lengths, and which models have official QAT checkpoints. These come from Google's documentation and published model files — we're reporting numbers, not guessing at them.
• Calculated from a stated formula: usable memory per device (the Mac/GPU/CPU rules above), and the comfortable/tight verdict thresholds (80% and 100% of usable memory). These are our own rules, applied consistently and shown above so you can check our work or disagree with the assumptions.
• Explicitly labeled estimates:anything about KV cache growth over a long conversation, tokens-per-second on a given card, or real-world VRAM use during inference is described in our guides as an estimate or a reported range, not a precise figure — because it depends on context length, runtime, and workload in ways a static table can't capture. Where we cite a specific tokens/sec or real-world VRAM number, we say where it came from (e.g. community reports) rather than presenting it as our own benchmark.

If a number on this site isn't labeled as an estimate, it's because it traces back to an official source or a formula documented above — not because we made it up and forgot to say so.

How we keep guides current

The Gemma ecosystem ships new variants, quantization formats, and tooling updates on roughly a monthly cadence. When a new model size, an official QAT checkpoint, or a significant runtime change lands, we revisit the affected guides and update the numbers rather than leaving them to go stale. Every article carries an updated date in addition to its original publish date — you can see it at the top of each guide — so you always know how recently the figures were checked against upstream sources.

Corrections policy

We get numbers wrong sometimes — a spec sheet changes, a source updates a figure, or we simply make a mistake. If you spot one, tell us through the contact pagewith the guide and the number in question. We check it against the source, and if it's wrong we correct it and update the guide's updateddate. Corrections are welcome and we don't treat them as an inconvenience — accuracy is the entire point of this site.

For more on who runs this site and why, see the About page.