Gemma AI Modelle im Überblick: Welches Gemma-Modell eignet sich für wen?

Googles Gemma AI hat sich in vier Generationen von einem reinen Text-Modell mit 8K-Kontext zu einer multimodalen Modellreihe entwickelt, die von 1.1 GB Mobile-INT4 bis zu einem 31B-Dense-Modell mit 256K-Kontext reicht. Mit Gemma 4 wechselt Google erstmals von den hauseigenen Gemma Terms of Use auf Apache 2.0, was die Familie für kommerzielle Projekte deutlich attraktiver macht. Seit dem 3. Juni 2026 ergänzt Gemma 4 12B Unified die Core-Linie als jüngste Variante. Dieser Überblick ordnet die Gemma-Modelle nach Architektur, Hardwarebedarf und Einsatzszenario ein und beantwortet die zentrale Frage: Welches Gemma-Modell passt zu welcher Hardware und welchem Use Case?

Vier Generationen Gemma AI im direkten Vergleich

Die Gemma-Familie umfasst aktuell vier Generationen, die sich in Kontextfenster, Modalitäten und Lizenz deutlich unterscheiden. Gemma 2 (Juni 2024) ist reines Text-Modell mit 8K-Kontext und drei Grössen. Gemma 3 (März 2025) bringt Multimodalität (Text und Bild), 128K-Kontext für die mittleren und grossen Varianten und unterstützt laut Modellkarte mehr als 140 Sprachen. Gemma 3n (Juni 2025) ist explizit für On-Device-Deployment konzipiert und nutzt eine verschachtelte MatFormer-Architektur, in der das E4B-Modell ein E2B-Submodell enthält. Gemma 4 (ab Anfang April 2026) ist die erste Generation mit Apache-2.0-Lizenz, fügt Audio als Eingabemodalität hinzu (bei E2B, E4B, 12B Unified) und erweitert das Kontextfenster für die grossen Varianten auf 256K. Die ersten Gemma-4-Weights (E2B, E4B, 31B, 26B A4B) wurden am 31. März 2026 gelistet; Googles öffentliche Ankündigung folgte am 2. April 2026. Am 16. April kam Multi-Token Prediction für diese vier Modelle dazu, und am 3. Juni 2026 folgte Gemma 4 12B Unified.

Der Lizenzwechsel auf Apache 2.0 ist die wichtigste Neuerung in Gemma 4

Gemma 2, Gemma 3 und Gemma 3n stehen unter den Google Gemma Terms of Use. Diese Lizenz erlaubt zwar kommerzielle Nutzung, ist aber keine OSI-anerkannte Open-Source-Lizenz. Korrekt ist deshalb die Formulierung "open-weight unter Gemma Terms of Use" und nicht "Open Source". Die Gemma Terms verlangen unter anderem, dass Downstream-Nutzer auf die Prohibited Use Policy verpflichtet werden, also eine sogenannte Flow-down-Klausel an alle weiter verteilenden Parteien. Für Produktteams, die Gemma-basierte Modelle in eigene Angebote integrieren, bedeutet das Vertragsarbeit auf jeder Ebene der Verteilung.

Mit Gemma 4 wechselt Google auf Apache 2.0. Das ist die erste Gemma-Generation unter einer permissiven Standard-Open-Source-Lizenz. Damit fallen die Flow-down-Pflichten der Gemma Terms weg, und Gemma 4 lässt sich unter denselben Bedingungen einsetzen wie andere Apache-2.0-Modelle. Für Teams, die Open-Weight-Modelle in regulierten oder lizenzsensitiven Umgebungen betreiben, ist dieser Schritt der wesentliche Unterschied zwischen Gemma 3 und Gemma 4. Ein vergleichbares Lizenz- und Architektur-Spektrum gibt es bei der Konkurrenz aus China, etwa bei den DeepSeek-Modellen mit ihren MoE-Architekturen und Open-Weight-Lizenzen.

Gemma 4: Fünf Varianten und ein MoE-Modell mit erklärungsbedürftiger Architektur

Gemma 4 umfasst fünf Varianten: zwei effektive Modelle (E2B, E4B), zwei Dense-Modelle (12B Unified, 31B) und ein MoE-Modell (26B A4B). Das sind nach Googles offizieller Modellkarte die fünf Core-Gemma-4-Grössen; grössere 70B- oder 100B-Klassen gibt es in dieser Core-Linie aktuell nicht. Die effektiven Modelle nutzen das gleiche Konzept wie Gemma 3n: Per-Layer Embeddings und eine verschachtelte Architektur sorgen dafür, dass die effektiv aktiven Parameter unter der Gesamtparameterzahl liegen. E2B lädt 5.1B Gewichte, nutzt aber rund 2.3B effektiv pro Token; E4B lädt 8B und nutzt 4.5B. Das macht beide Modelle für Mobile-Hardware und Geräte mit knappem RAM tauglich.

Bei Gemma 4 26B A4B handelt es sich um ein Mixture-of-Experts-Modell. Pro Token sind nur 3.8B Parameter aktiv, aber alle 25.2B Gewichte müssen im Speicher liegen. Das ist ein häufiges Missverständnis bei MoE-Modellen: Vier Milliarden aktive Parameter bedeuten nicht vier Gigabyte RAM. Wer ein 26B-A4B-Modell laden will, braucht den Speicher für die gesamten 25.2B Gewichte, plus Overhead für Aktivierungen und KV-Cache. Die offizielle Modellkarte beziffert den BF16-Speicherbedarf für Gemma 4 26B A4B auf 57.7 GB, was klar zeigt: Die Aktivierungseffizienz eines MoE-Modells reduziert nicht den Speicherbedarf, sondern nur die Rechenlast pro Token.

Die Hybrid-Attention-Architektur von Gemma 4 nutzt eine Mischung aus lokalen und globalen Attention-Layern. Das Sliding-Window-Mass liegt bei 512 Tokens für E2B/E4B und bei 1024 Tokens für 12B Unified, 26B A4B und 31B. Die Kontextfenster reichen von 128K (E2B, E4B) bis 256K (12B Unified, 26B A4B, 31B). Gemma 4 nutzt ein 262K-Token-Vokabular. Gemma 4 12B Unified unterscheidet sich durch eine encoderfreie Architektur: Bild- und Audio-Eingaben werden direkt in den LLM-Embedding-Raum projiziert. Für E2B, E4B, 26B A4B und 31B nennt Google ausserdem Multi-Token Prediction als Beschleunigungs-Update; für die Hardware-Auswahl bleibt aber der Speicherbedarf der geladenen Gewichte und des KV-Caches entscheidend.

Gemma 3n: Der Mobile-Ableger mit verschachtelter Architektur

Gemma 3n ist explizit für On-Device-Deployment konzipiert. Die E4B-Variante enthält ein verschachteltes E2B-Submodell, sodass sich Qualität und Latenz zur Laufzeit umschalten lassen, ohne ein zweites Modell laden zu müssen. Die Architektur kombiniert MatFormer, AltUp, LAuReL, Per-Layer Embeddings und Activation Sparsity. Das Modell ist offline-fähig, multimodal (Text, Bild, Video, Audio) und über die Google AI Edge Gallery verfügbar.

Wichtig für die Auswahl: Gemma 3n steht unter den Gemma Terms of Use, nicht unter Apache 2.0. Wer eine permissive Lizenz für Mobile-Deployment braucht, sollte stattdessen Gemma 4 E2B oder E4B im Mobile-INT4-Format verwenden, das die offizielle Modellkarte mit 1.1 GB bzw. 2.5 GB Speicherbedarf angibt.

Hardware-Matrix: Welches Gemma-Modell läuft auf welcher Maschine?

Die folgende Hardware-Matrix kombiniert die offiziellen Gemma-4-Speicherangaben aus der Modellkarte mit parameterbasierten Schätzungen für Gemma 2 und Gemma 3. Die offiziellen Gemma-4-Zahlen enthalten 20% Laufzeit-Overhead, aber keinen Kontextfenster-Overhead. Bei langen Kontexten wächst der KV-Cache linear mit der Sequenzlänge, was den tatsächlichen Speicherbedarf auf langen Eingaben deutlich erhöhen kann. Schätzungen für Gemma 2 und Gemma 3 basieren auf Parameteranzahl mal Bytes pro Gewicht und sind nicht hardware-getestet. RTX 5090 und DGX Spark werden hier als aktuelle obere lokale Hardware-Klassen mitgeführt; bei kleinen Gemma-Varianten sind sie technisch möglich, aber praktisch überdimensioniert.

Ein wichtiger Hinweis zu Apple Silicon: Der Unified Memory eines Mac mini ist kein diskretes GPU-VRAM. Das Betriebssystem und andere Anwendungen belegen einen Teil des Speichers, und das verfügbare Budget für ein Modell liegt typischerweise mehrere Gigabyte unter der nominalen Speicherkapazität. Praktische Erfahrungen zur lokalen Inferenz auf Apple Silicon stehen im Artikel zu Ollama auf dem Mac mini.

Die Gemma-4-Werte stammen aus der offiziellen Modellkarte; alle Gemma-2- und Gemma-3-Angaben sind Schätzungen auf Basis von Parameteranzahl mal Bytes pro Gewicht. Kontext-Overhead ist nicht enthalten. Bei voller Ausnutzung des 128K- oder 256K-Kontextfensters kann der KV-Cache zusätzliche Gigabyte verbrauchen. Wer das maximale Kontextfenster nutzt, sollte die Werte als Mindestbedarf lesen, nicht als Obergrenze.

Quantisierung und Runtimes: Was im Gemma-Ökosystem läuft

Gemma-Modelle werden von allen relevanten lokalen Inference-Stacks unterstützt. Im llama.cpp-Ökosystem liegt das GGUF-Format vor, mit Metal-Backend für Apple Silicon und CUDA für NVIDIA-GPUs. MLX bietet einen Apple-Silicon-optimierten Pfad. Ollama und LM Studio sind komfortable Wrapper um llama.cpp und GGUF, die ohne tiefes Setup auskommen. Für Server-Deployments ist Gemma 4 nach Angaben der Modellkarte vLLM-kompatibel, und Hugging Face Transformers dient als BF16/FP16-Referenz-Implementierung.

Bei den Quantisierungsformaten ergeben sich vier praxisrelevante Optionen. BF16 (oder FP16) liefert die volle Modellqualität bei höchstem Speicherbedarf und eignet sich nur für gut ausgestattete Hardware. SFP8 ist eine Gemma-4-spezifische Quantisierung, die Google selbst in der Modellkarte nennt; sie halbiert den BF16-Speicherbedarf annähernd. Q4_0 und Q4_K_M sind die verbreiteten Consumer-Quantisierungen im llama.cpp-Ökosystem, wobei Q4_K_M in der Praxis das häufigere Format ist und einen geringfügig höheren Speicherbedarf hat als Q4_0. Für Mobile-Deployment gibt es ein INT4-Format speziell für Gemma 4 E2B und E4B mit 1.1 GB bzw. 2.5 GB Speicherbedarf.

Bei der Modellbeschaffung über Hugging Face ist zu beachten, dass die Gemma-Modelle unter huggingface.co/google gated sind. Vor dem Download muss die Lizenz bestätigt werden. Das gilt unabhängig davon, ob das jeweilige Modell unter Gemma Terms (Gemma 2, 3, 3n) oder unter Apache 2.0 (Gemma 4) steht.

Selbstreportierte Benchmark-Zahlen aus den Modellkarten

Google hat in der Modellkarte zu Gemma 4 eigene Benchmark-Auswertungen publiziert. Diese sind als selbstreportierte Werte einzuordnen, nicht als unabhängige Verifikation. Auf MMLU-Pro erreicht Gemma 4 31B 85.2%, das 26B-A4B-MoE-Modell 82.6% und Gemma 4 12B Unified 77.2%; die effektiven Modelle E4B und E2B liegen bei 69.4% bzw. 60.0%. Auf GPQA Diamond, das physikalisch-naturwissenschaftliches Reasoning testet, erreicht Gemma 4 31B 84.3%, 26B A4B 82.3% und 12B Unified 78.8%. Im Vergleich dazu liegt die Gemma-3-27B-Instruct-Variante laut Modellkarte bei 42.4% auf GPQA Diamond und 67.5% auf MMLU-Pro. Auf der Mathematik-Olympiade AIME 2026 reportiert Google für Gemma 4 31B 89.2%, für 26B A4B 88.3% und für 12B Unified 77.5%.

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

Die Sprünge von Gemma 3 auf Gemma 4 sind deutlich, aber der direkte Generationenvergleich über Benchmark-Zahlen ist methodisch fragil. MMLU als Benchmark hat dokumentierte Probleme mit Datenkontamination und Sättigung bei den jeweils stärksten Modellen.

Empfehlung nach Zielgruppe

Für Entwickler mit Mac mini 16 GB Unified Memory sind Gemma 4 E2B oder E4B im Q4-Format der natürliche Einstiegspunkt. Gemma 4 12B Unified ist in Q4_0 nur bei kurzem Kontext und mit wenig Reserve vertretbar; für komfortablen Betrieb empfiehlt sich der Mac mini 24 GB. Auf 24 GB lässt sich 12B Unified auch bei moderaten Kontexten betreiben, und Gemma 4 26B A4B in Q4_0 wird möglich, allerdings mit knappem Puffer bei langen Eingaben. Gemma 3 oder Gemma 2 27B in Q4 sind ebenfalls eine Option, wenn die Apache-2.0-Lizenz nicht zwingend erforderlich ist.

Auf einem Mac mini 32 GB Unified Memory ist Gemma 4 26B A4B die interessanteste Option. Das MoE-Modell bietet die Reasoning-Qualität einer 25B-Klasse bei reduzierter Rechenlast pro Token. Gemma 4 31B in Q4_0 ist ebenfalls sinnvoll, mit ausreichend Puffer für mittlere Kontextlängen.

Auf NVIDIA-Consumer-GPUs mit 12 GB VRAM (RTX 3060, RTX 4070, RTX 4070 Super) sind Gemma 4 E2B und E4B die unkomplizierte Wahl. Gemma 4 12B Unified in Q4_0 läuft mit kurzen Kontexten, wird aber bei langen Eingaben am VRAM-Limit operieren. Die 26B-A4B- und 31B-Varianten passen nicht in 12 GB. Für die schnellere RTX 4070 gilt dieselbe VRAM-Grenze wie für die RTX 3060, lediglich die Speicherbandbreite ist höher.

Auf einer RTX 4090 24 GB ist Gemma 4 26B A4B in Q4_0 die starke Option. Auch Gemma 4 31B in Q4_0 ist sinnvoll, mit Puffer für kurze bis mittlere Kontexte. Eine RTX 5090 mit 32 GB VRAM verschiebt diese Grenze nach oben: 31B und 26B A4B bleiben Q4/SFP8-Kandidaten, laufen aber mit mehr Kontextreserve als auf 24-GB-Karten. Gemma 4 12B Unified läuft auf beiden Karten komfortabel, auch in SFP8 mit 13.4 GB.

DGX Spark beziehungsweise GB10-Systeme mit rund 128 GB Unified Memory liegen eine Klasse darüber. Dort passen alle Core-Gemma-4-Varianten lokal in den Speicher, inklusive 26B A4B und 31B mit deutlich mehr Reserve für längere Kontexte. Das macht Spark nicht automatisch zu einer Datacenter-GPU wie H100 oder B200, aber für lokale Gemma-Experimente ist es die komfortabelste Klasse in dieser Übersicht. Wer Server- oder Workstation-Hardware mit grösserem VRAM-Budget plant, findet im Praxisbericht zur DGX Spark eine Einordnung lokaler KI-Hardware jenseits der Consumer-Klasse.

Für Mobile- und Edge-Deployment ist Gemma 3n E2B oder E4B die etablierte Wahl, allerdings unter den Gemma Terms. Wer eine permissive Lizenz braucht, sollte stattdessen auf Gemma 4 E2B im Mobile-INT4-Format mit 1.1 GB Speicherbedarf wechseln; das Modell ist über die Google AI Edge Gallery verfügbar.

Für compliance-sensitive Projekte gibt es nur eine klare Empfehlung: Gemma 4 unter Apache 2.0. Die Gemma Terms of Use der älteren Generationen sind kommerziell nutzbar, aber die Flow-down-Klausel der Prohibited Use Policy macht die Vertragsarbeit aufwendiger. Wer Open-Weight-Modelle in Produkten verteilt, sollte das einkalkulieren.

Was die Gemma-Familie 2026 leistet und was nicht

Gemma ist die vollständigste Open-Weight-Modellfamilie von Google: vier Generationen, Modelle von 270M bis 31B, Modalitäten bis Audio, Kontextfenster bis 256K und mit Gemma 4 endlich eine permissive Lizenz. Die MoE-Variante 26B A4B bietet ein attraktives Profil für 32-GB-Hardware, sofern Anwender das Speicher-Modell von MoE-Architekturen verstehen: aktive Parameter sind eine Rechen-Eigenschaft, kein Speicher-Vorteil. Die effektiven Modelle E2B und E4B leisten echte Edge-Tauglichkeit, mit 1.1 GB Mobile-INT4 als Untergrenze.

Was die offiziellen Zahlen nicht zeigen: Wie sich die Modelle in realer Last unter konkretem Stack verhalten, wie sich der KV-Cache bei voller Kontextlängenausnutzung entwickelt und wie verlässlich die selbstreportierten Benchmark-Werte unter unabhängiger Reproduktion sind. Wer Gemma in Produktion bringt, sollte eigene Messungen anlegen, statt sich auf Leaderboards zu verlassen.