Google Gemma 4: kleines Modell mit starker Wirkung

Google Gemma 4 ist kein Modell, welches alle Benchmarks dominiert. Genau deshalb ist es interessant. Die Modelle positionieren sich in einem Bereich, der für viele Teams praktischer ist als das obere Ende der Modellgrößen: offene Gewichte, Apache-2.0-Lizenz, lokale oder kontrollierte Ausführung, starke Coding-Werte und Modellgrößen, die noch in realistischen Workstation- und Server-Szenarien denkbar sind.

Besonders die beiden größeren Varianten, Gemma 4 31B Dense und Gemma 4 26B A4B MoE, machen den Vergleich spannend. Das 31B-Modell ist der Qualitätsanker der Familie. Die 26B-A4B-Variante ist das Effizienzmodell: insgesamt 25,2 Milliarden Parameter, aber pro Token nur rund 3,8 Milliarden aktive Parameter. Die korrekte Schreibweise ist Gemma 4 26B A4B, nicht A4E. A4B steht für rund vier Milliarden aktive Parameter während der Inferenz.

Wenn Du OpenAI-Modelle, Claude, Qwen, GLM oder Kimi mit lokalen Open-Weight-LLMs vergleichst, reicht ein Blick auf Ranglisten nicht aus. Du brauchst ein Evaluationsraster aus Qualität, Latenz, Kosten, Datenflüssen, Lizenz, Betrieb und Sicherheit. Genau dort setzt der praktische Wert von Gemma 4 an. Eine strukturierte Vertiefung findest Du in unseren Themen zu KI Engineering & LLMs.

Was ist Google Gemma 4?

Gemma 4 wurde am 2. April 2026 als Modellfamilie mit offenen Gewichten veröffentlicht. Google bezeichnet sie als bislang leistungsfähigste Gemma-Generation. Die Familie umfasst vier Varianten: E2B, E4B, Gemma 4 26B A4B MoE und Gemma 4 31B Dense.

Wichtig ist die saubere Einordnung: Gemma 4 steht nach den veröffentlichten Lizenzangaben unter Apache 2.0 und ist damit kommerziell nutzbar. Das bedeutet aber nicht automatisch klassische Open-Source-Software im Sinne eines vollständig offenen Entwicklungsprozesses inklusive aller Trainingsdaten, Trainingspipeline und Reproduzierbarkeit. Open Weights heißt: Die Modellgewichte sind verfügbar und können unter den Lizenzbedingungen genutzt werden. Für Unternehmen ist diese Unterscheidung wichtig, weil Lizenzprüfung, Modellgovernance und technische Reproduzierbarkeit unterschiedliche Fragen sind.

Warum klein bei Gemma 4 relativ ist

31 Milliarden Parameter sind nicht winzig. Im Vergleich zu großen offenen und proprietären LLMs liegt Gemma 4 31B aber in einem kompakten Sweet Spot. Genau hier wird Leistung pro Parameter zum Leitmotiv. Ein Modell, das in vielen Aufgaben nah an deutlich größeren Systemen arbeitet, aber überschaubarer betrieben werden kann, ist für Teams oft wertvoller als ein Benchmark-Sieger, der nur mit deutlich größerer Infrastruktur sinnvoll läuft.

Google nennt für die Gemma-Familie mehr als 400 Millionen Downloads seit der ersten Generation. Für Gemma 4 nennt Google wenige Wochen nach der Veröffentlichung bereits mehr als 60 Millionen Downloads. Solche Zahlen sind kein Qualitätsbeweis, zeigen aber, dass die Familie in der Entwicklerpraxis schnell ausprobiert wird. Zusätzlich verweist Google für Gemma 4 31B und Gemma 4 26B A4B auf hohe Platzierungen unter offenen Modellen in Text-Leaderboards.

Die nüchterne Positionierung lautet deshalb: Gemma 4 ist nicht das stärkste Modell am Markt. Es ist aber eines der interessantesten Modelle, wenn Du hohe Qualität, offene Gewichte, lokale Nutzbarkeit, kommerziell nutzbare Lizenz und moderate Hardwareanforderungen kombinieren willst.

Die Gemma-4-Modellfamilie im Überblick

Die Modellfamilie teilt sich praktisch in zwei Klassen. E2B und E4B sind Edge-Modelle für schlankere lokale Szenarien mit bis zu 128K Kontext. Die größeren Varianten, 26B A4B MoE und 31B Dense, unterstützen bis zu 256K Kontext und zielen auf anspruchsvollere Assistenz-, Coding- und Agentenaufgaben.

Der praktische Unterschied ist klar: E2B und E4B sind die naheliegende Wahl, wenn Speicher, Latenz oder Offline-Fähigkeit entscheidend sind. 26B A4B ist spannend, wenn Du mehr Qualität möchtest, aber Inferenzkosten drücken willst. 31B Dense ist die bessere Wahl, wenn Stabilität, komplexe Aufgaben und tiefe Analyse wichtiger sind als maximale Effizienz.

Gemma 4 31B Dense vs. Gemma 4 26B A4B MoE

Bei einem Dense-Modell sind während der Inferenz alle Modellparameter aktiv. Gemma 4 31B Dense hat laut Modellangaben 30,7 Milliarden Gesamtparameter und aktiviert diese vollständig. Das begünstigt robuste Qualität, verursacht aber mehr Rechenaufwand pro Token.

Gemma 4 26B A4B folgt dagegen einer Mixture-of-Experts-Architektur. Das Modell hat laut Modellangaben 25,2 Milliarden Gesamtparameter, aktiviert pro Token aber nur rund 3,8 Milliarden Parameter. Der Router entscheidet, welche Experten genutzt werden. Das ist der Kern des Effizienzversprechens: Viele Gewichte sind vorhanden, aber nicht alle werden für jeden Token gerechnet.

Die von Google genannten Benchmarks stützen diese Einordnung. Gemma 4 31B erreicht demnach 85,2 Prozent MMLU Pro, 89,2 Prozent AIME 2026 ohne Tools, 80,0 Prozent LiveCodeBench v6, Codeforces Elo 2150 und 66,4 Prozent MRCR v2, 8 Needle, 128K. Gemma 4 26B A4B liegt bei mehreren Werten nahe daran, etwa mit 82,6 Prozent MMLU Pro, 88,3 Prozent AIME 2026 ohne Tools und 77,1 Prozent LiveCodeBench v6. Deutlicher wird der Abstand bei Codeforces, HLE, Tau2 und Long-Context-Tests.

Das Praxisfazit ist einfach: Nutze 26B A4B, wenn Du schnelle lokale Assistenz und gute Qualität auf effizienterer Hardware willst. Gewichte 31B stärker, wenn schwierige Programmieraufgaben, lange Dokumente, agentische Abläufe oder verlässliche strukturierte Ausgaben im Vordergrund stehen.

Coding-Fähigkeiten: Wo Gemma 4 praktisch interessant wird

Die Coding-Werte sind einer der stärksten Gründe, sich Gemma 4 genauer anzusehen. Laut Google erreicht Gemma 4 31B 80,0 Prozent LiveCodeBench v6 und Codeforces Elo 2150. Gemma 4 26B A4B kommt auf 77,1 Prozent LiveCodeBench v6 und Codeforces Elo 1718. Beide Modelle sind damit für Entwicklungsaufgaben relevant, der Abstand bei anspruchsvollen Competitive-Programming- und Agenten-Szenarien ist aber sichtbar.

Typische Einsatzfälle sind lokale Codeanalyse, Refactoring-Ideen, Testvorschläge, Dokumentation, API-Skizzen, Migrationshilfen und IDE-nahe Assistenten. Besonders nützlich ist die strukturierte JSON-Ausgabe, wenn Du Ergebnisse maschinell weiterverarbeiten willst, etwa für Review-Pipelines, Ticket-Vorschläge oder statische Analyse-Workflows.

{
  "task": "code_review",
  "language": "csharp",
  "findings": [
    {"type": "test_gap", "severity": "medium"},
    {"type": "refactoring", "severity": "low"}
  ]
}

Trotzdem gilt: KI-Unterstützung ersetzt keine Engineering-Disziplin. Clean-Code-Prinzipien, Tests, Reviews, Architekturentscheidungen und nachvollziehbare Build-Pipelines bleiben notwendig. Gerade wenn Du KI für Refactoring, Testgenerierung oder Dokumentation nutzt, solltest Du die Ergebnisse in Deinen Qualitätsprozess integrieren. Für .NET-Teams bietet das Seminar Clean Code für .NET Entwickler passenden fachlichen Kontext.

Grenzen entstehen häufig nicht nur im Modell, sondern im Stack: Tool Calling, Prompt-Templates, Laufzeitumgebung, Kontextaufbau, Sampling-Parameter und Quantisierung musst Du mit Deinen eigenen Aufgaben testen. Ein Modell kann im Benchmark stark sein und in Deinem Tool-Workflow trotzdem an Formatdetails scheitern.

Gemma 4 Quantisierung: Warum Q4, Q5 und Q8 über die Praxis entscheiden

Quantisierung reduziert Speicher- und Rechenbedarf, indem Gewichte mit geringerer numerischer Genauigkeit gespeichert und verarbeitet werden. Das macht lokale Inferenz praktikabler, kann aber je nach Stufe Qualität kosten. Für Gemma 4 ist Quantisierung deshalb nicht nur ein technisches Detail, sondern oft der Unterschied zwischen Demo und nutzbarem Workflow.

Typische lokale Inferenzpfade sind Ollama, GGUF und llama.cpp. Ergänzend sind MLX für Apple-Silicon-Umgebungen und vLLM für serverseitige Inferenz relevante Laufzeitumgebungen. Google beschreibt für Ollama und llama.cpp den Einsatz quantisierter GGUF-Modelle, um den Ressourcenbedarf zu senken.

Ollama listet für Gemma 4 unter anderem gemma4:e2b mit 7,2 GB, gemma4:e4b mit 9,6 GB, gemma4:26b mit 18 GB und gemma4:31b mit 20 GB. Diese Größen sind nützlich zur Orientierung, aber nicht identisch mit dem vollständigen RAM- oder VRAM-Bedarf zur Laufzeit. Neben den Gewichten brauchst Du Speicher für Runtime, temporäre Daten, Batch-Verarbeitung und vor allem den KV-Cache.

Der KV-Cache wird bei 256K Kontext schnell zum Engpass. Lange Kontexte klingen attraktiv, aber jedes zusätzliche Token erhöht die Speicherlast. Bei MoE kommt hinzu: Auch wenn pro Token nur rund 3,8 Milliarden Parameter aktiv sind, müssen Gewichte, Routing, Cache und Runtime-Pipeline sinnvoll in Deine Hardware passen. Gemma 4 26B A4B ist effizienter als ein Dense-Modell ähnlicher Gesamtgröße, aber nicht magisch klein.

Multi-Token Prediction: Warum Gemma 4 nach der Veröffentlichung spannender wurde

Am 5. Mai 2026 hat Google nach eigenen Angaben Multi-Token-Prediction-Drafters für Gemma 4 vorgestellt. Die Idee dahinter ist Speculative Decoding: Ein kleiner Drafting-Mechanismus schlägt mehrere Tokens vor, das Hauptmodell prüft sie anschließend. Werden die Vorschläge akzeptiert, kann die Ausgabe schneller erzeugt werden.

Google nennt eine bis zu dreifache Beschleunigung ohne Verschlechterung von Antwortqualität oder Reasoning-Logik. Für die Praxis ist das relevant, weil bei lokalen Assistenten, Coding-Agenten und RAG-Systemen nicht nur die Modellqualität zählt. Reaktionszeit entscheidet darüber, ob ein System im Arbeitsfluss bleibt oder als langsam empfunden wird.

Gerade bei längeren Antworten, Codegenerierung und interaktiven Dialogen kann Inferenzgeschwindigkeit den Unterschied machen. Multi-Token Prediction ändert nicht automatisch die Hardwareanforderungen, verbessert aber die wahrgenommene Nutzbarkeit, wenn Runtime und Modellvariante sauber zusammenspielen.

Was Benchmarks, Artificial Analysis und Community-Tests sagen

Bei Gemma 4 solltest Du drei Ebenen trennen: offizielle Benchmarks, externe Vergleichsdaten und Community-Erfahrungen. Offizielle Werte sind wichtig, aber sie spiegeln definierte Testsets. Externe Plattformen schaffen Vergleichbarkeit, haben aber eigene Metriken. Community-Posts zeigen reale Eindrücke, sind aber anekdotisch und nicht repräsentativ.

Google nennt für die Modellkarte Benchmarks wie MMLU Pro, AIME 2026, LiveCodeBench, Codeforces, GPQA Diamond, Tau2, HLE, MMMU Pro und MRCR v2. Die Tendenz ist konsistent: 31B Dense ist insgesamt stabiler und stärker, 26B A4B liegt bei mehreren Standardwerten nah dran, verliert aber bei anspruchsvolleren Reasoning-, Tool- und Long-Context-Aufgaben deutlicher.

Artificial Analysis bewertet Gemma 4 31B Reasoning mit einem Intelligence Index von 39 und nennt etwa 35 bis 36 Output-Tokens pro Sekunde. Gemma 4 26B A4B Reasoning erreicht dort einen Intelligence Index von 31. Diese Werte beziehen sich auf die Reasoning-Varianten und sind kein Ersatz für eigene Tests, geben aber eine hilfreiche externe Einordnung.

Im Sub-32B-Vergleich liegt Qwen3.5 27B Reasoning laut Artificial Analysis mit einem Intelligence Index von 42 vor Gemma 4 31B Reasoning mit 39, erzeugt in der Auswertung aber deutlich mehr Output-Tokens. Das ist ein wichtiger Hinweis: Ein höherer Intelligenzwert kann mit mehr Tokenaufwand einhergehen. Für Produktivsysteme zählen deshalb nicht nur die Antwortqualität, sondern auch Tokenbudget, Latenz und Steuerbarkeit.

Größere offene Modelle wie Kimi K2.6 und GLM-5.1 gehören im Open-Weight-Spitzenfeld zu den stärkeren Vergleichspunkten, sind aber kein identischer Hardware- und Einsatzklassenvergleich. Proprietäre API-Modelle wie Claude oder OpenAI ChatGPT bieten wiederum andere Stärken, verschieben aber Datenflüsse, Kostenmodell und Betriebsverantwortung. Genau deshalb ist Gemma 4 besonders interessant für Teams, die lokale oder kontrollierte Bereitstellung ernsthaft prüfen.

Community-Stimmen aus Reddit und ähnlichen Kanälen solltest Du ausdrücklich als Erfahrungsberichte lesen. Wiederkehrend wird Gemma 4 31B als stabiler beschrieben. Gemma 4 26B A4B gilt häufig als schneller, aber teils anfälliger bei Tool-Calling- und Formatfragen. Einzelne positive Produktionsberichte sind interessant, aber nicht repräsentativ, zumal manche Tests über API und nicht lokal durchgeführt wurden.

Gemma 4 im Open-Weight-Vergleich

Ein fairer Open-Weight-LLM-Vergleich vermeidet die Aussage, Gemma 4 schlage alles. Das tut es nicht. Die Stärke liegt im Sweet Spot aus Größe, Qualität, Lizenz und lokaler Nutzbarkeit. Für viele Unternehmen ist genau dieser Sweet Spot wichtiger als ein Spitzenplatz in einer globalen Rangliste.

Die relevanten Entscheidungsfragen lauten: Welche Aufgaben muss das Modell lösen? Wie lang sind typische Kontexte? Müssen Daten das eigene Netzwerk verlassen? Welche Latenz ist akzeptabel? Wie stabil ist JSON-Ausgabe? Funktioniert Tool Calling im eigenen Framework? Wer überwacht Kosten, Logs, Fehler und Modellversionen? Wie wird ein Modellwechsel getestet?

Für RAG- und Wissensmanagement-Szenarien kommt eine weitere Ebene hinzu: Das LLM ist nur ein Teil des Systems. Embeddings, Chunking, Vektorsuche, Metadaten, Re-Ranking, Prompting, Evaluation und Zugriffsschutz entscheiden oft stärker über die Ergebnisqualität als der Wechsel zwischen zwei ähnlich starken Modellen. Wenn Du Gemma 4 mit Retrieval, Embeddings und lokaler Wissenssystem-Architektur kombinieren willst, liefert Vektordatenbanken in KI-Architekturen einen passenden technischen Einstieg.

Auch Sicherheit gehört früh in die Architektur. Lokal betriebene LLMs reduzieren bestimmte Datenflussrisiken, lösen aber nicht automatisch Prompt Injection, Rechteprüfung, Logging, Modellmissbrauch oder Datenabfluss über Antworten. Für Unternehmensbetrieb brauchst Du Guardrails, Rollenmodelle, Monitoring und nachvollziehbare Freigabeprozesse. Vertiefend passt dazu Defensive KI für abgesicherte IT-Infrastrukturen.

Für wen lohnt sich Gemma 4?

Praxischeck: So evaluierst Du Gemma 4 sinnvoll

Der beste Benchmark ist Dein eigener Workload. Baue ein kleines, reproduzierbares Testset aus realen Aufgaben: Codeanalyse, JSON-Ausgabe, lange Dokumente, Tool Calls, RAG-Fragen, Fehlertoleranz und unerwünschte Eingaben. Vergleiche 26B A4B und 31B nicht nur nach Antwortqualität, sondern auch nach Latenz, Speicherbedarf, Abbruchraten, Formatfehlern und Kosten.

• Teste Q4, Q5 oder Q6 gegen Q8 oder BF16, statt Quantisierung nur nach Dateigröße zu wählen.
• Prüfe lange Kontexte mit realistischen Dokumenten, nicht nur mit kurzen Prompts.
• Validiere JSON-Ausgaben maschinell, damit Formatfehler sichtbar werden.
• Miss Tool-Calling-Erfolg separat von normaler Chatqualität.
• Dokumentiere Modellversion, Runtime, Prompt-Template, Sampling-Parameter und Hardware.
• Vergleiche Open-Weight-Modelle mit API-Modellen nur entlang konkreter Anforderungen.

Wenn Du so vorgehst, wird die Entscheidung deutlich klarer: 26B A4B ist oft die bessere Wahl für schnelle Assistenz und Prototypen. 31B Dense lohnt sich, wenn die Aufgabe empfindlicher auf Reasoning-Fehler, Tool-Fehler oder Formatabweichungen reagiert.