KI für alle: Wie Googles Gemma 4 QAT 31B-Modelle auf Consumer-GPUs und 1-GB-Smartphones bringt

Die offiziellen Checkpoints nutzen ein W4A16-Schema: 4-Bit-Integer-Gewichte mit 16-Bit-Aktivierungen, einer group_size von 32 und dem compressed-tensors-Format . Dies ist derselbe Ansatz, den Google für vLLM-basierte Inferenz dokumentiert, wo die Kombination aus niedrig-bitigen Gewichten und höher-präzisen Aktivierungen einen optimalen Kompromiss aus Speicherersparnis und Durchsatz bietet .

Die komplette Gemma-4-QAT-Modellpalette

Fünf Modellgrößen erhielten QAT-Checkpoints, plus passende Drafter-Modelle für spekulative Dekodierung. Jedes ist in mehreren Formaten verfügbar (mehr dazu unten), und der praktische Speicherbedarf verschiebt sich dramatisch zwischen BF16 und QAT 4-Bit .

Die Speicherangaben stammen aus Googles offizieller Modellübersicht und der Unsloth-Dokumentation, wobei die Q4_0-Zahlen das weit verbreitete GGUF-Quantisierungslevel darstellen . Die Größe von rund 1 GB für E2B im mobilen Format ist die Schlagzeilen-würdige Zahl – Google hat dafür eigens ein angepasstes Schema mit gezielten 2-Bit-Dekodierungsschichten und optimierten KV-Caches entwickelt . Für reine Textmodelle ohne Per-Layer Embeddings soll der Speicherbedarf sogar unter 1 GB fallen können .

Besondere Aufmerksamkeit verdient das 26B A4B-Modell. Es nutzt eine Mixture-of-Experts-Architektur, die pro Token nur etwa 3,8 Milliarden Parameter aktiviert, obwohl es insgesamt 26 Milliarden besitzt. Das bedeutet, es verhält sich rechenaufwandstechnisch eher wie ein 4B-Modell, liefert aber eine Qualität, die grob mit einem viel größeren dichten Modell vergleichbar ist . In 4-Bit-Form passt es auf GPUs mit 12–16 GB – genau die Hardware, die viele Entwickler bereits besitzen .

Bereitstellungsformate: Mit Bedacht wählen

Google hat die QAT-Checkpoints in vier verschiedenen Formen veröffentlicht, und die Wahl des Formats beeinflusst direkt die Qualität :

• Compressed-tensors (W4A16): Das offizielle Format für die Inferenz mit vLLM. Es nutzt 4-Bit-Integer-Gewichte und 16-Bit-Aktivierungen mit group_size=32. Dies ist die bevorzugte Route, wenn man innerhalb der von Google getesteten Qualitätssicherung bleiben möchte .
• GGUF / Q4_0: Das am weitesten verbreitete Format für llama.cpp, Ollama und ähnliche Ökosystem-Werkzeuge. Für alle fünf Modellgrößen der QAT-Veröffentlichung stehen einsatzbereite GGUF-Dateien zur Verfügung .
• Mobil-optimiertes Format: Ein maßgeschneidertes Schema, das eine Mischung verschiedener Quantisierungsbreiten nutzt und explizit für mobile Hardware entwickelt wurde. Nur für E2B und E4B verfügbar, erreicht E2B hiermit die genannte 1-GB-Marke .
• Unquantisierte QAT-Checkpoints: Halbpräzise Gewichte, extrahiert aus der QAT-Pipeline. Diese sind für Forscher und Entwickler gedacht, die ihre eigenen, benutzerdefinierten Quantisierungs- oder Kompilierungsabläufe anwenden möchten .

Der wichtigste Vorbehalt der gesamten Veröffentlichung betrifft die naive Formatkonvertierung. Werden QAT-Gewichte ohne entsprechende Sorgfalt direkt in Q4_0 konvertiert, kann die Genauigkeit drastisch einbrechen. Laut der Unsloth-Dokumentation erreicht eine naive Q4_0-Konvertierung des 26B-QAT-Modells lediglich etwa 70,2 % Top-1-Genauigkeit . Unsloths eigene "Dynamic"-Methode steigert dies auf 85,6 % – eine Verbesserung um 15,4 Prozentpunkte. Dies unterstreicht, dass die Formatwahl und die Konvertierungsmethode entscheidend dafür sind, die von QAT versprochene Qualität auch tatsächlich zu erhalten .

Für die meisten Anwender sind die offiziellen Compressed-Tensors- oder GGUF-Checkpoints der sicherste Ausgangspunkt.

Welche Hardware kann diese Modelle tatsächlich ausführen?

QAT reduziert nicht nur den Speicherbedarf – es gestaltet die Hardware-Landschaft für lokale KI-Inferenz völlig neu. Modelle, die bisher Rechenzentrums-GPUs erforderten, können nun auf Consumer-Hardware und sogar Smartphones laufen.

Smartphones und Edge-Geräte: E2B ist für den mobilen Einsatz konzipiert. Googles LiteRT-LM-Framework kann E2B mit 2-Bit- und 4-Bit-Quantisierung unter 1,5 GB RAM ausführen, und Googles eigene App "AI Edge Gallery" im Play Store erlaubt es Nutzern, E2B oder E4B direkt auf dem Gerät auszuwählen und auszuführen . Beide Modelle unterstützen Text-, Bild- und Audioeingaben – Echtzeit-Sprachübersetzung, visuelle Frage-Antwort-Systeme und On-Device-Assistenten werden ohne Cloud-Anbindung denkbar .

8-GB-GPUs: Der Sweet Spot für QAT. E2B (~3,2 GB), E4B (~5 GB) und das 12B-Modell (~7 GB) passen in Q4_0-Quantisierung bequem in 8 GB VRAM . Ein Mittelklasse-Laptop mit einer mobilen RTX 4060 oder eine ältere Desktop-RTX 2070 können nun ein multimodales Modell mit einem 256K-Kontextfenster ausführen – etwas, das mit 16-Bit-Präzision 24 GB oder mehr erfordert hätte.

12–16-GB-GPUs: Das 26B A4B MoE-Modell landet hier bei etwa 15 GB im Q4_0-Format und passt auf Karten wie die RTX 3080, 4070 Ti oder 4080 . Seine MoE-Architektur sorgt zudem für eine geringere Inferenzlatenz als ein dichtes Modell ähnlicher Größe, da pro Token nur ein Bruchteil der Parameter aktiviert wird .

20–24-GB-GPUs: Das dichte 31B-Modell benötigt in Q4_0-Quantisierung etwa 17–18 GB und ist damit in Reichweite von Besitzern einer RTX 3090 oder 4090, mit etwas Spielraum für KV-Cache und Batch-Größe . Bei voller 16-Bit-Präzision verschlingt dieses Modell fast 60 GB – für Consumer-GPUs völlig unerreichbar. QAT macht das größte Gemma-4-Modell auf einer einzelnen High-End-Consumer-Karte wirklich praktikabel.

Wichtiger Realitätscheck: Die hier genannten Zahlen beschreiben den Speicherbedarf für die Modellgewichte, nicht den gesamten VRAM-Verbrauch. Laufzeit-Overhead – insbesondere der KV-Cache für große Kontextfenster – kann noch einmal Gigabytes obendrauf packen. Das 31B-Modell mit einem 256K-Kontext wird deutlich mehr Speicher verbrauchen als die reine Gewichtsgröße, und Community-Berichte deuten darauf hin, dass kontextintensive Workloads den Bedarf in den unteren 20-GB-Bereich treiben können . Planen Sie immer zusätzlichen Puffer über den reinen Q4_0-Gewichtsbedarf hinaus ein.

Qualitätserhaltung und praktische Grenzen

QATs Kernversprechen ist nahezu originale Leistung bei drastisch reduziertem Speicherverbrauch – und die Benchmarks bestätigen dies weitgehend. Googles eigene Dokumentation spricht von "nahezu ursprünglicher" Leistung bei etwa 72 % Speicherreduktion, und Community-Benchmarks deuten auf einen Qualitätsverlust im Bereich von 3–5 % für Q4-Quantisierung im Vergleich zu BF16 hin .

Aber der Teufel steckt im Detail. Der naive Konvertierungs-Hinweis – 70,2 % Top-1-Genauigkeit beim 26B-Modell gegenüber 85,6 % nach Unsloths dynamischer Optimierung – zeigt, dass die erzielte Qualität stark davon abhängt, wie die QAT-Gewichte konvertiert und eingesetzt werden . Einfach einen QAT-Checkpoint zu nehmen und ihn ohne QAT-sensible Behandlung durch einen Standard-GGUF-Konverter zu jagen, führt möglicherweise nicht zur erwarteten Qualität.

Für den produktiven Einsatz ist der sicherste Ansatz, die offiziellen QAT-Checkpoints direkt im Compressed-Tensors-Format (für vLLM) oder die offiziellen GGUF-Dateien von Hugging Face zu verwenden . Wer benutzerdefinierte Quantisierung jenseits des von Google bereitgestellten Umfangs benötigt, sollte Zeit für Benchmarking einplanen – QAT-Gewichte reagieren empfindlicher auf die Konvertierungsmethode als standardmäßig nachträglich quantisierte Gewichte.

Was diese Veröffentlichung ermöglicht

Auf praktischer Ebene ändert diese Veröffentlichung die Standardantwort auf die Frage: "Kann ich dieses Modell lokal ausführen?" Zum ersten Mal liefert eine große Open-Weights-Modellfamilie QAT-Checkpoints nicht als nachträglichen Einfall, sondern als Bürger erster Klasse. Die Implikationen erstrecken sich über mehrere Anwendungsbereiche:

Datenschutzkritische Anwendungen: Medizinische, juristische und persönliche Assistenzanwendungen, die bisher eine Cloud-API erforderten, können nun vollständig auf dem Gerät – Laptop oder Smartphone – ausgeführt werden, wobei QAT genug Qualität bewahrt, um lokale Inferenz wirklich nützlich zu machen .

Offline- und Edge-Bereitstellung: Feldforschung, Katastrophenhilfe und industrielle Umgebungen ohne zuverlässige Konnektivität können leistungsfähige multimodale Modelle auf Standardhardware einsetzen. E2Bs Audiounterstützung in Kombination mit der 1-GB-Mobilquantisierung macht Echtzeit-Sprachübersetzung auf einem Mittelklasse-Smartphone zur praktischen Realität .

Entwicklerwerkzeuge und IDEs: Die 12B- und 26B-Modelle passen auf die Hardware, die Entwickler bereits besitzen, und ermöglichen Code-Vervollständigung, Refactoring und Dokumentationserstellung, die lokal – ohne Latenz- oder Kostenbeschränkungen – läuft. Google positioniert die quantisierten Versionen ausdrücklich für "IDEs, Coding-Assistenten und agentische Workflows" .

Experimente und Fine-Tuning: Kleinere Forschungsteams und unabhängige Entwickler, die sich keine A100- oder H100-Cluster leisten können, können nun mit Modellen im Bereich von 12B–31B auf Consumer-Hardware arbeiten, was die Einstiegshürde für Modellanpassungen und domänenspezifisches Fine-Tuning drastisch senkt.

Google hat die Checkpoints unter derselben Apache-2.0-Lizenz wie die Basis-Gemma-4-Modelle veröffentlicht. Sie sind ab sofort auf Hugging Face für alle fünf Modellgrößen verfügbar .