Gemma 4 lokal: Welches Modell passt zu welcher Hardware?

Gemma 4 gibt es in fünf Grössen, und die Auswahl entscheidet sich fast immer am verfügbaren Speicher. E2B und E4B laufen auf Edge-Geräten und Maschinen mit knappem RAM, 12B Unified ist die vernünftige Wahl für gängige lokale Systeme mit 12 bis 24 GB, und ab der 32-GB-Klasse werden 26B A4B und 31B interessant. Alle fünf Varianten stehen unter Apache 2.0. Wer eine bestehende Gemma-3- oder Gemma-3n-Installation betreibt, hat trotzdem einen Grund zu bleiben, und der hat wenig mit Benchmarkwerten zu tun.

Kurzfazit: Welche Gemma-4-Variante wofür

Unter rund 8 GB nutzbarem Speicher bleiben nur E2B und E4B. Zwischen 12 und 24 GB ist 12B Unified die Variante mit dem besten Verhältnis aus Fähigkeit, 256K-Kontextfenster und Speicherbedarf; sie ist ausserdem die grösste Gemma 4 mit Audio-Eingabe. Ab 32 GB lohnt sich 26B A4B, weil das MoE-Modell pro Token nur 3.8B Parameter aktiviert und deshalb spürbar schneller antwortet als ein Dense-Modell dieser Grösse. Gemma 4 31B liefert die stärksten offiziellen Werte der Familie und zahlt dafür mit dem höchsten Decode-Aufwand. Ältere Gemma-Generationen sind nur noch dann die richtige Wahl, wenn ein bestehender Fine-Tune, ein ausgeliefertes On-Device-Paket oder ein bereits geprüfter Deployment-Pfad daran hängt.

Für stärkere lokale Coding- und Agentenprofile ist Qwen der naheliegende Vergleich, während Llama vor allem dort relevant bleibt, wo bestehende Tools und breite Runtime-Kompatibilität zählen.

Die fünf Varianten und was sie technisch unterscheidet

Google listet Gemma 4 in fünf Grössen: E2B, E4B, 12B Unified, 26B A4B und 31B. Das "E" steht für effektive Parameter. E2B und E4B nutzen Per-Layer Embeddings, bei denen jede Decoder-Schicht eine eigene kleine Embedding-Tabelle pro Token erhält. Diese Tabellen sind gross, dienen aber nur schnellen Lookups, weshalb die effektive Parameterzahl deutlich unter der geladenen liegt. Das "A" in 26B A4B steht für aktive Parameter.

Der wichtigste Denkfehler bei dieser Tabelle betrifft 26B A4B. Aktive Parameter sind eine Eigenschaft der Rechenlast, keine Eigenschaft des Speichers. Wer das MoE-Modell laden will, braucht Platz für alle 25.2B Gewichte, auch wenn pro Token nur 3.8B davon rechnen. Der Gewinn liegt bei der Geschwindigkeit: Google beschreibt das Modell als annähernd so schnell wie ein 4B-Modell, obwohl es Speicher wie ein 25B-Modell belegt. Genau das macht es auf einer 32-GB-Maschine attraktiver als das Dense-31B.

Alle Gemma-4-Modelle nutzen ein hybrides Attention-Muster aus lokalem Sliding Window und globalen Layern, wobei die letzte Schicht immer global ist. Das Sliding-Window-Mass liegt bei 512 Tokens für E2B und E4B und bei 1024 Tokens für die drei grösseren Varianten. Für lange Kontexte teilen sich die globalen Layer Keys und Values und nutzen Proportional RoPE. Praktisch heisst das: Der KV-Cache wächst bei Gemma 4 langsamer als bei einem reinen Full-Attention-Modell derselben Grösse, aber er wächst.

Hardware: Was tatsächlich in den Speicher passt

Die folgende Matrix rechnet die offiziellen Parameterzahlen in Speicherbedarf um: zwei Byte pro Gewicht für BF16 und etwa 0.55 Byte pro Gewicht für gängige 4-Bit-Quantisierungen im GGUF-Ökosystem. Enthalten sind nur die Gewichte, nicht KV-Cache, Aktivierungen und Runtime-Overhead. Wer das volle 128K- oder 256K-Fenster nutzt, muss die Werte als Untergrenze lesen.

Zwei Randbedingungen verschieben diese Zahlen in der Praxis. Erstens ist Unified Memory bei Apple Silicon ein gemeinsames Budget für System, Anwendungen und Modell und verhält sich damit anders als diskreter GPU-Speicher. Auf einem Mac mini mit 16 GB stehen für ein Modell realistisch mehrere Gigabyte weniger zur Verfügung als die nominale Kapazität suggeriert. Zweitens verhalten sich E2B und E4B beim Laden anders als eine simple Multiplikation vermuten lässt, weil Runtimes die Per-Layer-Embedding-Tabellen unterschiedlich behandeln und teilweise auslagern. Wer diese beiden Varianten auf Mobilgeräten einsetzt, sollte den realen Verbrauch messen statt ihn zu berechnen.

Für die Wahl des Quantisierungsformats gilt die übliche Regel: 4-Bit-Formate wie Q4_K_M sind der Standardweg auf Consumer-Hardware, 8-Bit-Varianten kosten rund die doppelte Menge Speicher und werden erst ab der 32-GB-Klasse für die grossen Modelle realistisch. Wer die Formatlogik dahinter braucht, findet sie im Backbone-Artikel zu GGUF.

Ollama als Serving-Pfad und als Entscheidungsfaktor

Ollama führt Gemma 4 in der offiziellen Modell-Library. Die Tags decken alle fünf Grössen ab, von gemma4:e2b und gemma4:e4b über gemma4:12b und gemma4:26b bis gemma4:31b; zusätzlich existiert gemma4:31b-cloud als gehosteter Pfad. Ollama sortiert die Familie dabei genauso, wie es die Hardwarefrage nahelegt: E2B und E4B als Edge-Modelle, 12B, 26B und 31B als Workstation-Modelle.

Der praktische Vorteil ist die Chat-Template-Logik. Gemma 4 steuert seinen Reasoning-Modus über ein Think-Token am Anfang des System-Prompts, und die Modelle geben ihre internen Gedanken in einem eigenen Channel aus. Bei allen Varianten ausser E2B und E4B erzeugt das Modell diese Tags auch dann, wenn Thinking deaktiviert ist, dann eben mit leerem Gedankenblock. Wer selbst gegen die Rohausgabe parst, muss diesen Fall abfangen. Ollama, Transformers und llama.cpp nehmen einem das laut Modellkarte ab, was die einfachste Begründung dafür ist, den bequemen Weg zu nehmen.

Der Preis dieses Wegs ist Kontrollverlust an zwei Stellen. Die Ollama-Modellseite beschreibt Gemma 4 nur mit Text- und Bild-Eingabe; die Audio-Fähigkeit von E2B, E4B und 12B taucht dort nicht auf. Wer lokale Spracherkennung oder Sprachübersetzung mit Gemma 4 plant, muss die Modalitätsunterstützung im konkreten Runtime prüfen, bevor er die Variante festlegt. Und das ausgelieferte Kontextfenster legt der Server fest: Ein Modell mit 256K nominalem Fenster belegt nur dann entsprechend viel Speicher, wenn dieses Fenster auch geöffnet wird. Für Server-Deployments mit mehreren parallelen Anfragen bleibt vLLM der präzisere Pfad, weil sich dort Kontextlänge und Speicherreservierung explizit setzen lassen.

Lizenz: Apache 2.0 gegen die alten Gemma Terms

Gemma 4 steht vollständig unter Apache 2.0. Gemma 2, Gemma 3 und Gemma 3n stehen unter den Google Gemma Terms of Use. Diese erlauben kommerzielle Nutzung, verpflichten aber weiterverteilende Parteien auf die Prohibited Use Policy. Die operative Folge betrifft nur einen Fall: Wer Modellgewichte oder daraus abgeleitete Modelle an Dritte weitergibt, muss diese Klausel bei den älteren Generationen vertraglich weiterreichen und bei Gemma 4 nicht mehr. Wer das Modell ausschliesslich selbst betreibt und nur Ausgaben ausliefert, spürt den Unterschied im Alltag kaum. Für alle Varianten gilt weiterhin, dass die Repositories unter huggingface.co/google gated sind und eine Lizenzbestätigung vor dem Download verlangen.

Wann ältere Generationen noch tragen

Googles eigene Zahlen zeigen einen deutlichen Generationensprung. Auf MMLU Pro liegt Gemma 4 31B bei 85.2 Prozent, 26B A4B bei 82.6 Prozent und 12B Unified bei 77.2 Prozent, während Gemma 3 27B ohne Thinking mit 67.6 Prozent angegeben ist. Auffälliger für lokale Anwendungen ist der Long-Context-Test MRCR v2 (8 needle, 128K): 66.4 Prozent für 31B gegen 13.5 Prozent für Gemma 3 27B. Wer lange Dokumente lokal verarbeitet, gewinnt beim Umstieg mehr als die reinen Wissensbenchmarks nahelegen.

Externer Benchmark, nicht AISyndicate-eigene Messung. Die Werte sind nur eingeschränkt vergleichbar, weil Runtime, Quantisierung und Hardware variieren.

Trotzdem bleiben zwei Fälle für ältere Generationen bestehen. Der erste ist ein bestehender Fine-Tune auf Gemma 2 oder Gemma 3, dessen Neuaufbau auf Gemma 4 Trainingsdaten, Evaluation und Freigabe erneut kostet. Der zweite ist eine bereits ausgelieferte On-Device-Pipeline auf Gemma 3n, bei der ein Modellwechsel Update-Verteilung, Gerätetests und Freigabe erneut auslöst. In beiden Fällen entscheidet der Migrationsaufwand, und die Lizenzfrage kommt erst dazu, wenn die Gewichte das eigene Haus verlassen. Ohne solche Bindung gibt es kein technisches Argument mehr für die alten Generationen.

Empfehlung nach Nutzerprofil

Wer Gemma lokal auf einem Notebook oder einem kleinen Mac testet und dabei Audio oder Bild verarbeiten will, startet mit E4B in Q4 und wechselt auf 12B Unified, sobald 16 GB verfügbar sind. Wer eine einzelne Consumer-GPU der 12-GB-Klasse betreibt, hat mit 12B Unified in Q4 die stärkste Variante, die zuverlässig hineinpasst, und sollte das Kontextfenster bewusst begrenzen statt es auf das Maximum zu stellen.

Wer eine Workstation mit 32 GB oder mehr betreibt und Antwortzeiten interaktiv halten will, nimmt 26B A4B. Wer maximale Qualität pro Anfrage braucht und längere Wartezeiten akzeptiert, nimmt 31B. Für Teams, die Gemma-basierte Modelle weitergeben oder in ein Produkt einbetten, ist Gemma 4 wegen Apache 2.0 der einzige Kandidat, der die Vertragsarbeit auf jeder Verteilungsstufe erspart. Und wer noch nicht weiss, ob Gemma überhaupt die passende Familie ist, sollte den Vergleich mit den lokal relevanten Llama-Varianten führen, bevor er einen Stack darauf aufbaut.

Ein Punkt bleibt offen, und er lässt sich nicht aus Modellkarten beantworten: wie sich diese Modelle unter realer Last mit voll geöffnetem Kontextfenster verhalten. Speicherangaben für Gewichte sind der einfache Teil der Rechnung. Der KV-Cache entscheidet, ob eine Maschine im Alltag trägt.