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

Google hat offizielle QAT-Checkpoints (Quantization-Aware Training) für die gesamte Gemma-4-Familie veröffentlicht – ein Schritt, der grundlegend verändert, wo diese Modelle eingesetzt werden können. Statt ein fertiges 16-Bit-Modell nachträglich zu komprimieren, was oft zu Qualitätseinbußen führt, simuliert QAT die Quantisierung bereits während des Trainings. Das Modell lernt, mit dem Präzisionsverlust umzugehen, sodass die finale 4-Bit-Variante nahezu die ursprüngliche Leistung beibehält, aber rund 72 Prozent weniger Speicher benötigt .

Das Paket umfasst fünf Parameter-Größen und führt ein neues, auf mobile Geräte zugeschnittenes Quantisierungsformat ein, das die Grenzen des Machbaren weiter verschiebt. Für alle, die große Modelle bisher wegen Hardware-Beschränkungen nur aus der Ferne beobachtet haben, ergeben sich sofort praktische Konsequenzen.

Warum QAT mehr bringt als herkömmliche Quantisierung

Bei der üblichen Post-Training-Quantisierung (PTQ) werden die Gewichte eines bereits trainierten Modells in eine niedrigere Genauigkeit umgewandelt – zum Beispiel von bfloat16 auf int4. Das Problem: Das Modell wurde nie darauf trainiert, mit dieser geringeren Präzision zu arbeiten, und die Qualität leidet oft spürbar .

QAT hingegen bindet die Quantisierungssimulation direkt in den Trainingsprozess ein. Das Modell "sieht" während der Vorwärts- und Rückwärtsdurchläufe bereits quantisierte Werte und entwickelt so eine Robustheit gegenüber der eingeschränkten Zahlendarstellung. Das Ergebnis ist ein Modell, das in 4-Bit-Form eine nahezu mit dem Original identische Leistung zeigt, statt nur eine abgeschwächte Version seiner selbst zu sein .

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 .

Modell	Architektur	Aktive Parameter	BF16-Speicher	QAT-4-Bit-Speicher	Passende Hardware
E2B	Dense + PLE	~2,3 Mrd. effektiv (5,1 Mrd. mit Embeddings)	~9,6 GB	~3,2 GB (Q4_0); 1 GB (mobiles Format)	Smartphones, Edge-Geräte, Browser
E4B	Dense + PLE	~4,5 Mrd. effektiv (8 Mrd. mit Embeddings)	~15 GB	~5 GB (Q4_0)	Mittelklasse-GPUs, mobile Geräte mit mehr RAM
12B	Dense, encoder-frei, multimodal	11,95 Mrd.	~24 GB	~7 GB (Q4_0)	8-GB-GPUs, Laptops mit dedizierter Grafik
26B A4B	Mixture of Experts	~3,8 Mrd. aktiv (26 Mrd. gesamt)	~48 GB	~15 GB (Q4_0)	12–16-GB-GPUs, High-End-Workstations
31B	Dense	30,7 Mrd.	~58 GB	~17–18 GB (Q4_0)	24-GB-GPUs (RTX 3090/4090), Setups mit viel VRAM

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 .