Contents

Running Gemma 3 Locally: Google's Small Model on Consumer Hardware

A capable open-weights model that fits on the GPU you already own

Contents

Every few months a new open-weights model lands and the homelab forums fill with breathless claims that this one finally dethrones the cloud. Most of the time it’s hype. Gemma 3, which Google released on 12 March 2025, is one of the rare cases where the claims are roughly fair — not because it beats the frontier models, but because it’s the first small model I’ve run that I actually leave switched on.

The interesting trick Gemma 3 pulls is the size ladder: it comes in 1B, 4B, 12B, and 27B parameter variants, all sharing the same architecture, so you can pick whichever one your hardware tolerates without learning a new prompting style. The 4B fits comfortably on an 8 GB card. The 12B is the sweet spot for a 16 GB GPU. The 27B wants 24 GB or some patience. And from the 4B up, they’re natively multimodal — you can feed them an image, which the previous Gemma generation couldn’t do. The 1B is text-only and carries a 32k context window; the 4B, 12B, and 27B each stretch to 128k tokens, which is enormous for models this size and the feature I ended up using most.

If you’ve never run a local model before, this is a gentler on-ramp than most — the whole point of the size ladder is that you don’t have to commit to hardware first. Start on whatever GPU you own. If you’re weighing which card to even buy for this, the trade-offs I hit adding a desktop GPU to a small box in eGPU via OCuLink map directly onto the 8 GB / 16 GB / 24 GB tiers above.

Getting it running with Ollama

Advertisement

There are fancier ways to serve a model, but for “I just want it answering on my LAN,” nothing beats Ollama. It handles the GGUF download, quantisation selection, and an OpenAI-compatible API in one binary.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
$ curl -fsSL https://ollama.com/install.sh | sh
$ ollama pull gemma3:12b
pulling manifest
pulling 4a7c... 100% ▕████████████▏ 8.1 GB
verifying sha256 digest
success

$ ollama run gemma3:12b "Explain ZFS scrub vs resilver in two sentences."
A scrub reads every block in the pool and verifies it against its
checksum, repairing silent corruption while all disks are healthy.
A resilver rebuilds data onto a replacement disk after a failure,
reconstructing only the missing copies from redundancy.

The default gemma3:12b tag pulls a 4-bit quantised build (Q4_K_M), which is what makes it fit. If you want the unquantised weights for maximum fidelity and have the VRAM, gemma3:12b-it-fp16 exists, but honestly the quality gap at Q4 is small enough that I never bother.

Quantisation, and what it actually costs you

This is the part nobody explains properly. “Quantisation” means storing the model’s weights at lower precision — 4 bits instead of 16 — so the model fits in a fraction of the memory. The naive assumption is that you’re throwing away three-quarters of the model’s intelligence. You aren’t. The Q4_K_M scheme keeps the most sensitive layers at higher precision and squeezes the rest, and the measurable quality loss on most tasks is a couple of percent. What you lose is mostly at the margins: it’s slightly more likely to fumble a tricky reasoning chain or hallucinate a citation.

You can watch the memory pressure directly while it runs:

1
2
3
$ ollama ps
NAME          ID            SIZE     PROCESSOR    UNTIL
gemma3:12b    a9f8c2e1      9.8 GB   100% GPU     4 minutes from now

If you see “CPU” or a split there, the model spilled out of VRAM and you’ll get a brutal slowdown — drop to the next size down or a tighter quant.

Choosing your variant, honestly

Advertisement

The temptation is to pull the biggest model your card will hold and stop thinking. Resist it. The right variant depends on the job, not just the VRAM.

The 4B is genuinely useful for the narrow, high-volume tasks — classification, extraction, short summaries, routing. It’s fast enough to sit in a loop processing a queue, and its wobbliness on multi-step reasoning doesn’t matter if you’re never asking it to reason. On an 8 GB card it leaves headroom for a decent context window.

The 12B is my default and the one I’d recommend to most people. It’s the point where the model stops feeling like a toy — it holds a thread through a few reasoning steps, drafts prose that needs light editing rather than a rewrite, and handles the 128k context without complaint on a 16 GB card. The jump in quality from 4B to 12B is far larger than the jump from 12B to 27B, which is the usual shape of these ladders.

The 27B is worth it only if you have the 24 GB card and specifically need the extra fidelity — better long-form coherence, fewer fumbled edge cases. On a 16 GB card you’d be spilling into system RAM and paying a brutal speed penalty for a modest quality gain, which is rarely the trade you want.

Throughput scales roughly as you’d expect. On a mid-range 16 GB card the 12B generates comfortably faster than you can read, tens of tokens a second, which is all that matters for interactive use. Batch work is where model size bites: halving the size can double your throughput, so for a queue of thousands of short classifications the 4B often wins on total wall-clock time even though it’s “worse.”

Wiring it into things

Because Ollama speaks the OpenAI API, anything that talks to OpenAI talks to Gemma with a base-URL swap. That’s the whole appeal. Here’s a minimal Python call that runs entirely on your own metal:

1
2
3
4
5
6
7
8
9
from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="gemma3:12b",
    messages=[{"role": "user", "content": "Draft a one-line cron comment for a nightly borg backup."}],
)
print(resp.choices[0].message.content)

The same endpoint plugs into Open WebUI for a ChatGPT-style front end, into Home Assistant’s conversation agent, or into editor plugins. I run a 12B instance behind my reverse proxy and point a handful of tools at it. The 128k context window — large for a model this size — means it’ll happily chew through a long config file or a meeting transcript without truncating.

One of the best uses I’ve found is as the reasoning engine behind a private search stack — the exact setup in self-hosted AI search with Perplexica and a local model. Gemma 3 12B is comfortably capable enough to summarise and synthesise fetched search results, and because it never leaves your LAN, your queries don’t either. If you want to teach it a narrow domain rather than just prompt it, the base weights are also a reasonable starting point for LoRA fine-tuning on consumer hardware — the same size ladder that makes it easy to serve makes it easy to adapt.

Troubleshooting the common snags

Most of what goes wrong running Gemma 3 locally is memory, and it announces itself the same way each time.

It’s crawlingly slow. Check ollama ps. If the PROCESSOR column shows anything other than 100% GPU, part of the model spilled into system RAM and is running on CPU, which is an order of magnitude slower. Drop to a smaller variant (12B to 4B) or a tighter quantisation, or close whatever else is holding VRAM — a desktop compositor and a browser can easily eat a gigabyte you needed.

It refuses to load at all with a CUDA out-of-memory error. The card doesn’t have room for the model plus its context. Context isn’t free: a 128k-token window reserves a lot of KV-cache memory. If you don’t need the full window, cap it — set num_ctx lower via a Modelfile or the API — and a model that wouldn’t load at 128k loads happily at 8k.

Vision input does nothing or errors. You’re on the 1B, which is text-only. Multimodal starts at the 4B. Pull gemma3:4b or larger and pass the image through Ollama’s multimodal API, not as a text description.

Responses are truncated mid-sentence. That’s the output token limit, not the context window — raise num_predict. It’s a separate setting and an easy one to conflate with context length.

Tool-calling behaves erratically. Known limitation, not a config error. See the next section.

Where it disappoints

Let’s be honest about the ceiling. Gemma 3 is not going to refactor a large codebase or reason through a genuinely hard problem the way the big hosted models do. The 4B variant in particular is fine for summarising and classifying but wobbly on anything requiring multi-step logic. Tool-calling support exists but is finicky compared to purpose-built agentic models. And the multimodal vision is competent, not spectacular — good enough to describe a photo, not good enough to read a dense scanned document reliably.

It’s also worth saying the licence is Google’s own Gemma terms, not a clean Apache or MIT, so read it if you’re shipping a commercial product on top. The terms are permissive in practice — commercial use is allowed — but they carry a use policy Google can update, which is a different risk profile from a plain open-source licence. For a homelab it’s irrelevant; for a product it’s a lawyer’s five minutes well spent.

One more honest caveat that catches people: a local model has no live knowledge. Gemma 3’s training cut-off means it doesn’t know about anything that happened after it was built, and unlike a hosted assistant it can’t browse. If you need current information, you have to feed it — retrieval, a search layer, pasted context — rather than expecting it to know. That’s not a Gemma failing; it’s true of every local model. But it’s the gap that most surprises people arriving from the hosted tools, where the retrieval is hidden inside the product. Run the model bare and the seams show, which is exactly why pairing it with a search layer turns it from a clever party trick into something you’d actually rely on.

The verdict

For local, private, “good enough” inference, Gemma 3 at 12B is the model I’d hand someone setting up their first homelab AI box. It’s small enough to fit real hardware, multimodal, fast, and the quality is genuinely useful for summarising, drafting, classifying, and answering. If your benchmark is the frontier cloud models, you’ll be disappointed — that’s not the game here. But if your benchmark is “useful AI that never sends my data anywhere,” this is the easiest recommendation I’ve made all year.

Who is it for, plainly? The tinkerer who wants a private assistant on hardware they already own, the developer who wants an OpenAI-compatible endpoint without a metered bill, and anyone building a tool where the data genuinely can’t leave the building. It is not for someone who needs frontier-grade reasoning or a drop-in ChatGPT replacement — reach for the cloud there and don’t pretend otherwise. But for the large middle ground of ordinary, private, everyday inference, Gemma 3 is the first small model I’ve stopped switching off, and that’s the whole review in one sentence.

Advertisement
Advertisement
Smarc
Written by Smarc

Founder and editor of vo.rs. A lifelong tinkerer who self-hosts far more than is sensible, hardens Linux boxes for fun, and prods the latest AI tools to see what they can really do. The how-to guides here are the notes Smarc wishes had existed the first time round.