
Gemma 4 12B Coder: Lokale Code-Generierung wird zum Default
TL;DR: „Gemma 4 12B Coder ist die spezialisierte Coding-Variante des Gemma-4-Stacks. GGUF-Format, ~8 GB VRAM/RAM, optimiert für Reasoning & Code-Generierung. Damit wird lokale Coding-AI auf jedem halbwegs aktuellen Laptop praktikabel – nicht nur auf Mini-PCs mit 128 GB Unified Memory."
— Till FreitagIn 30 Sekunden
Nach dem Gemma 4 26B MoE-Release im April hat Google nachgelegt: Der Gemma 4 12B Coder ist die explizit für Code-Tasks trainierte Variante des Stacks. Kleiner. Spezialisierter. Und vor allem: läuft auf normaler Consumer-Hardware, nicht erst auf einem 128-GB-Unified-Memory-Mini-PC.
Das ist die Variante, die lokale Coding-Agents endgültig aus der Nische holt.
Was ist neu
| Aspekt | Gemma 4 26B MoE | Gemma 4 12B Coder |
|---|---|---|
| Architektur | MoE, generalistisch | Dense, Code-spezialisiert |
| Parameter | 26B (sparse aktiv) | 12B (dense) |
| Format | mehrere | GGUF (llama.cpp-nativ) |
| Min. RAM/VRAM | 14–16 GB | ~8 GB (Q4_K_M) |
| Trainingsfokus | Allzweck-Reasoning | Code, Reasoning, Thinking |
| Zielhardware | Mini-PC / Workstation | Standard-Laptop |
| Hugging Face | google/gemma-4-26b | google/gemma-4-12B |
Warum 12B dense statt MoE?
MoE ist großartig für Generalisten – aber für Coding willst du dichte Aktivierung über das gesamte Modell, weil Code-Reasoning sehr lange, kohärente Ketten erfordert. Der 12B Coder ist genau dafür gebaut: jede Schicht trägt zu jedem Token bei. Das macht ihn auf Code-Benchmarks robuster als ein vergleichbar großer MoE-Slice.
GGUF: Warum das Format wichtig ist
GGUF (GPT-Generated Unified Format) ist das De-facto-Format für lokale Inference. Es heißt: plug-and-play in llama.cpp, Ollama, LM Studio, Jan und OpenClaw – ohne Custom-Loader, ohne Python-Stack. Modell laden, Endpoint öffnen, fertig.
Hardware-Anforderungen (real)
Was du tatsächlich brauchst, um Gemma 4 12B Coder produktiv zu fahren:
| Setup | Quantisierung | Speed (geschätzt) | Tauglich für |
|---|---|---|---|
| MacBook Air M3 (16 GB) | Q4_K_M | 25–35 t/s | Tab-Completion, kleine Refactors |
| MacBook Pro M4 (24 GB) | Q5_K_M | 40–55 t/s | Agentenflows, mittlere Diffs |
| RTX 4070 (12 GB VRAM) | Q4_K_M | 60–80 t/s | Full IDE-Backend |
| RTX 4090 (24 GB) | Q6_K | 100+ t/s | Multi-Session, Team-Setup |
| NucBox EVO-X2 (128 GB) | Q8_0 | 90+ t/s | Coder + 26B parallel |
Der Punkt: Du brauchst kein Spezial-Setup mehr. Ein normaler Developer-Laptop reicht.
Was sich für die Praxis verändert
1. Cursor / Claude Code lokal ersetzbar
Die typische Vibe-Coding-Schleife – Tab-Completion, Inline-Edits, kleine Agent-Tasks – ist genau das Profil, für das der 12B Coder gebaut wurde. Latency unter 50ms, keine API-Kosten, keine Rate-Limits. Für 80% der täglichen Coding-Interaktionen reicht das.
Was du weiterhin in der Cloud lässt: große architektonische Diffs, mehrstufige Repo-weite Refactors, frontier-level Reasoning. Dafür bleibt Claude Opus 4.5 oder GPT-5 die richtige Wahl.
2. OpenClaw bekommt ein passendes Default-Modell
Für OpenClaw war der 26B MoE das "wow"-Modell – aber zu groß für die meisten User. Der 12B Coder ist das Default-Modell, das auf jedem Entry-Setup läuft. Erst dadurch wird Local-First-Coding wirklich massenkompatibel.
3. Der Break-Even rutscht weiter
Mit dem 26B MoE haben wir gezeigt: Cloud-vs-Lokal kippt bei hohem Volumen. Mit dem 12B Coder kippt es bei jedem Volumen, sobald du einen halbwegs aktuellen Laptop hast – die Hardware ist eh schon da.
Setup in 5 Minuten
# 1. Ollama installieren (falls noch nicht)
curl -fsSL https://ollama.com/install.sh | sh
# 2. Modell ziehen
ollama pull gemma-4-12b-coder:q4_k_m
# 3. Lokalen OpenAI-kompatiblen Endpoint starten
ollama serve
# 4. In Cursor / Continue / OpenClaw als Custom Endpoint einbinden:
# http://localhost:11434/v1Das war's. Keine API-Keys, keine Cloud-Auth, keine TOS-Diskussion mit Legal.
Wo der 12B Coder an Grenzen stößt
Ehrlich bleiben:
- Sehr lange Repo-Kontexte (>100K Tokens): Hier glänzt das 26B-Modell mit 256K Kontext besser
- Cross-Sprache-Reasoning (z.B. TypeScript ↔ Rust ↔ SQL in einem Flow): Frontier-Cloud-Modelle führen noch
- Novel Algorithm Design: GPT-5 / Claude Opus 4.5 sind stärker bei kreativem Reasoning
- Sehr seltene Sprachen / DSLs: Trainingsdaten-Coverage variiert
Für alltägliches Coding-Volumen – Komponenten bauen, Tests schreiben, Bugs jagen, Migrationen ausführen – ist der 12B Coder ein No-Brainer.
Einordnung im Gemma-4-Stack
Der Stack besteht jetzt aus drei klaren Rollen:
- Gemma 4 2B — Edge / Mobile / Function Calling
- Gemma 4 12B Coder — Lokales Developer-Backend (dieser Artikel)
- Gemma 4 26B MoE — Generalistisches Workhorse-Modell (Deep-Dive)
Wer Coding macht, lädt 12B. Wer alles andere macht, lädt 26B. Wer beides parallel braucht und genug RAM hat, lädt beide.
Fazit
Der Gemma 4 12B Coder ist nicht die Schlagzeile – die hat das 26B MoE-Modell im April geholt. Aber er ist die Variante, die lokales Coding endgültig zum Default macht, weil sie auf der Hardware läuft, die Developer eh schon haben.
Drei Takeaways:
- Lokale Coding-Agents brauchen kein Spezial-Setup mehr – ein M3/M4-MacBook oder eine RTX 4070 reicht
- GGUF macht den Stack plug-and-play – Ollama, llama.cpp, LM Studio, OpenClaw funktionieren direkt
- Cloud-Coding bleibt für Frontier-Tasks – aber 80% des Alltags wandern lokal
Der Hype um Gemma 4 ist real. Und mit der 12B-Coder-Variante wird er endlich auch im Alltag erreichbar.
→ Gemma 4: Frontier-Intelligenz auf dem Laptop → Open-Source-LLM-Vergleich 2026 → Projekt KNUT: Lokale KI-Infrastruktur → Token Economics: Das neue Öl → OpenClaw Pricing Shock









