Gemma 4 im Test

Mit dem Release der lang erwarteten Gemma 4 Modellfamilie von Google erreicht die lokale KI-Ausführung ein neues Level. Während das gewaltige 31B Dense-Modell theoretisch die Spitzenposition beansprucht, zeigt die Praxis, dass die ressourcenschonende 26B MoE-Variante in realen Szenarien oft brilliert. Selbst die kleinen Modelle auf einem iPhone, und mit Maid unter Android, erzielen beeindruckende Ergebnisse.

Architektur und Modellvarianten

Die Gemma 4 Familie staffelt sich in vier markante Größen. Den Einstieg bilden die Modelle E2B (2,3 Milliarden effektive Parameter) und E4B (4,5 Milliarden effektive Parameter), die beide mit einem enormen Kontextfenster von 128K Token glänzen. Für anspruchsvollere Setups rücken jedoch die Schwergewichte in den Fokus. Hier steht das klassische, dichte 31-Milliarden-Parameter-Modell (Dense) mit einem 256K Kontextfenster einer hochinteressanten Architektur gegenüber. Bei der 26B Variante handelt es sich um ein Mixture of Experts (MoE) Modell. Obwohl es insgesamt 26 Milliarden Parameter besitzt, werden bei jeder Inferenz dynamisch nur 4 Milliarden Parameter aktiviert. Dies spart massiv Rechenleistung im Arbeitsspeicher und ermöglicht extrem schnelle Antwortzeiten bei gleichbleibend hoher logischer Präzision.

Lokales Setup vs Cloud-Inferenz

Für die Evaluierung wurde das 26B MoE Modell lokal auf einem dedizierten System mit einer 8-Bit-Quantisierung (Q8 GGUF) ausgeführt. Dabei wurde das Kontextfenster auf stabile 65.000 Token limitiert, was für flüssige Inferenzraten jenseits der 22 Tokens pro Sekunde (TPS) sorgte.

Beim 31B Dense Modell zeigte sich die lokale Quantisierung jedoch als problematisch. Versuche mit Q4_K_M- und Q8-Quantisierungen produzierten unerwartete Sonderzeichen oder wechselten abrupt die Sprache - ein klassisches Phänomen von noch nicht vollständig optimierten Konvertierungen kurz nach einem Release.

Agentisches Coding Browser OS und Spiele

Um die strukturelle Integrität des generierten Codes zu prüfen, wurde initial ein minimalistisches Browser-Betriebssystem angefordert. Das lokale 26B MoE Modell lieferte prompt eine funktionale HTML- und JavaScript-Oberfläche inklusive Startmenü. Mit etwas negativem Feedback korrigierte sich das Modell selbstständig und implementierte transluzente Hover-Effekte sowie eine funktionierende Theme-Engine zur Änderung der Fensterfarben. Das 31B Modell in der Cloud generierte zwar einen ähnlichen Ansatz, konnte aber optisch und logisch nicht signifikant mehr überzeugen.

Wirklich beeindruckend wurde es beim Generieren einer 3D-U-Bahn-Station. Das 26B Modell nutzte prozedurale Texturgenerierung, um eine ansehnliche Szene im Browser zu erschaffen.

Durch einen spontanen Folge-Prompt wurde diese statische Szene in einen rudimentären First-Person-Shooter verwandelt. Plötzlich gab es eine WASD-Steuerung sowie sichtbare Rückstoß-Animationen der Waffe auf dem Bildschirm.

Ein darauffolgender Test zur Erstellung eines 3D-Flugsimulators offenbarte kleine Unterschiede: Das 26B Modell benötigte einen kurzen Hinweis auf einen Variablenfehler ("Quaternion-Typo") über die Developer Console, bevor es sauber kompilierte und die Steuerung freigab. Das 31B Modell lieferte hier aus dem Stand eine visuell ansprechendere Version inklusive feindlicher Flugzeuge und sichtbarer Leuchtspurmunition - vergaß bei der reinen Optik aber eine funktionierende Trefferlogik im Code.

Multimodale Fähigkeiten Webdesign aus Wireframes

Die visuelle Auffassungsgabe wurde getestet, indem ein handgezeichnetes Wireframe-Mockup an die Modelle übergeben wurde. Die Aufgabe bestand darin, eine vollständige, professionelle Webseite für einen Machine-Learning-Ingenieur zu generieren.

Das 26B MoE Modell dekonstruierte das Gekritzel perfekt und baute eine optisch beeindruckende, moderne Webseite. Das absolute Highlight war eine integrierte, interaktive Simulation via JavaScript, bei der ein "Forward-Pass" durch ein neuronales Netz per Knopfdruck grafisch animiert wurde - inklusive variierender Konfidenzwerte der Inferenz.

Beim 31B Dense Modell hingegen kam es zu humorvollen Halluzinationen. Aus dem notierten Namen "Stevie Lapis" wurde im generierten Code spontan "Levi Lapis". Die Benutzeroberfläche wirkte klobig und die eingebettete "Sentiment Engine" funktionierte zwar, glich optisch aber einem Relikt aus dem frühen Web 2.0. In diesem multimodalen Härtetest ging der Punkt ganz klar an die performante, lokale MoE-Lösung.

Hardware Erkennung und Textverständnis

In einem praxisnahen Hardware-Test wurde ein Schaltplan vorgelegt. Dieser enthielt einen Arduino Uno, einen klassischen 28BYJ-48 Schrittmotor samt passendem ULN2003 Treiberboard und zwei simple Schallsensoren. Während das 26B Modell die kleinen Sensoren anfangs komplett übersah, identifizierte das 31B Modell diese zwar im ersten Anlauf, betitelte sie aber fälschlicherweise als aktive Buzzer. Bei der exakten Benennung des generisch gezeichneten Schrittmotors weigerten sich beide Modelle beharrlich und völlig zurecht, blind eine exakte Modellnummer zu erraten.

Ein anschließender kreativer Schreibtest mit einem leicht unheimlichen KI-Bild verdeutlichte das hervorragende "Alignment" der Systeme. Das 26B Modell verfasste basierend auf der Bildstimmung zunächst das Grundgerüst für einen düsteren Psychothriller. Konfrontiert mit der fiktiven Kritik, die Interpretation sei hochgradig beleidigend, entschuldigte sich das Modell wortreich, um direkt danach fehlerfrei ein tiefgründiges, zeitgenössisches Beziehungsdrama völlig ohne toxische Elemente zu entwerfen.

Fazit

Obwohl das dichte 31-Milliarden-Parameter-Modell eine beachtliche theoretische Leistung bietet, erweist sich die Gemma 4 26B MoE-Variante als unangefochtener Sieger für den Alltag. Mit nur 4 Milliarden aktiven Parametern ist es ressourcenschonend, rasend schnell auf lokaler Hardware ausführbar und besticht durch herausragende multimodale Fähigkeiten. Für technikbegeisterte Anwender, die komplexe Automatisierungen oder Skripte generieren wollen, stellt diese Architektur aktuell den absoluten Sweetspot dar.