Gemma 4 QAT reduziert E2B auf 1GB: Die Mathematik der On-Device-KI hat sich verändert

Die Frage, die jeder Platform-Verantwortliche mit einer Mobile- oder Desktop-KI-Roadmap diese Woche seinem CFO stellen sollte, lautet: Macht die Ausgabenposition für gehostete Inference im Budget des nächsten Jahres noch Sinn? Google DeepMind hat soeben Quantization-Aware Training-Checkpoints für die Gemma 4-Familie veröffentlicht, und die entscheidende Zahl – ein Speicherbedarf von 1GB für das E2B-Edge-Modell – ist genau die Art von Kennzahl, die Architektur-Meetings verändert. Für Teams, die vor sechs Monaten On-Device-Deployment mit Verweis auf RAM-Limits bei Mid-Range-Hardware abgelehnt haben, ist die technische Ausrede nun hinfällig.

Was passiert ist

Am 5. Juni 2026 kündigten Olivier Lacombe und Omar Sanseviero von Google DeepMind einen neuen Satz Gemma 4-Checkpoints an, die mit Quantization-Aware Training optimiert wurden, wie blog.google berichtete. Das erfolgt etwa zwei Monate nach der ursprünglichen Gemma 4-Veröffentlichung und ist das dritte bedeutende Update in diesem Zeitraum. Google hat zunächst Multi-Token Prediction zur Beschleunigung der Inference hinzugefügt, dann ein paar Tage zuvor ein 12B-Modell veröffentlicht, um die Lücke zwischen dem E4B und der 26B Mixture-of-Experts-Variante zu schließen. Das QAT-Release vervollständigt einen klaren Produktbogen: Modell veröffentlichen, beschleunigen, die Größenstaffel auffüllen und dann den Speicherbedarf drastisch senken.

Das Release umfasst zwei unterschiedliche Quantisierungspfade. Erstens erhält das weit verbreitete Q4_0-Format QAT-Checkpoints für die gesamte Modellreihe – das Format, das die meisten Desktop-Anwender von llama.cpp kennen. Zweitens, und aus Plattform-Perspektive interessanter, hat Google ein neuartiges Quantisierungsschema speziell für mobile Anwendungsfälle entwickelt und auf die Edge-Modelle E2B und E4B angewendet. Das zentrale Ergebnis: Gemma 4 E2B benötigt nun nur noch 1GB Speicher, und die rein textbasierte Konfiguration ohne Per-Layer Embeddings kommt sogar unter 1GB.

Die Verteilung ist bewusst breit angelegt. Gewichte sind auf Hugging Face verfügbar, mit GGUF-Formaten für llama.cpp, komprimierten Tensoren für vLLM und unkomprimierten Checkpoints für Teams, die in andere Q4_0-kompatible Zielformate konvertieren möchten. Desktop-Runner erhalten sofort Unterstützung für llama.cpp, Ollama und LM Studio. Edge erhält Googles LiteRT-LM-Runtime. Web erhält Transformers.js. Apple Silicon erhält MLX. Größere Modelle erhalten SGLang und vLLM. MTP-QAT-Checkpoints sind ebenfalls verfügbar, sodass Teams nicht zwischen dem Geschwindigkeitsvorteil und der Komprimierung wählen müssen, und Fine-Tuning wird über Hugging Face Transformers und Unsloth unterstützt.

Technische Grundlagen

QAT selbst ist nicht neu. Das Grundprinzip: Quantisierung wird während des Trainings simuliert, damit sich die Modellgewichte an den Präzisionsverlust anpassen – anstatt nach dem Training komprimiert zu werden und zu hoffen, dass die Qualität erhalten bleibt. Standard-Post-Training Quantization, der vorherrschende Ansatz in den meisten Open-Weights-Workflows heute, behandelt Komprimierung als abschließenden Schritt. Googles Aussage ist, dass QAT eine höhere Gesamtqualität als PTQ-Baselines liefert, was mit dem übereinstimmt, was die breitere Forschungsgemeinschaft seit zwei Jahren beobachtet. Der interessante Teil ist nicht QAT im Allgemeinen, sondern was sie für das mobile Schema entwickelt haben.

Vier Design-Entscheidungen sind relevant. Statische Aktivierungen werden während des Trainings vorberechnet statt zur Laufzeit berechnet, was bedeutet, dass der Mobile-Chip keine Rechenzyklen mehr damit verbringt, zur Inference-Zeit Datenskalierung durchzuführen. Channel-wise Quantisierung ist strukturiert, um dem Layout zu entsprechen, das Mobile-Acceleratoren erwarten, und vermeidet damit die langsamen Software-Fallbacks, die quantisierte Inference auf Smartphones historisch eher zu einem Benchmarking-Experiment als zu einer Produktionsrealität gemacht haben. Gezielte 2-Bit-Quantisierung wird nur auf die Token-Generierungsteile des Modells angewendet, während die zentralen Reasoning-Schichten auf höherer Präzision bleiben. Das ist die Design-Entscheidung, die den Qualitätsanspruch untermauert: Man kann bei der Komprimierung jener Netzwerkteile rigoros vorgehen, die keine kritische Last tragen.

Die vierte Entscheidung ist der tatsächliche Ursprung der 1GB-Zahl. Die Komprimierung konzentriert sich auf die Vokabelliste (Embeddings) und den KV-Cache, also den Kurzzeitspecher des Modells während der Generierung. Embeddings und KV-Cache dominieren tendenziell den aktiven Speicherbedarf bei kleinen Modellen, daher verwandelt ein gezielter Angriff darauf eine „läuft auf einem High-End-Smartphone"-Geschichte in eine „läuft auf dem durchschnittlichen Android-Gerät"-Geschichte. Mit der Option, Audio- und Vision-Encoder bei Nichtbedarf zu entfernen, liegt das rein textbasierte E2B komfortabel unter einem Gigabyte.

Ein Detail, das Engineering-Leads beachten sollten: Die MTP-QAT-Checkpoints bewahren den Multi-Token Prediction-Geschwindigkeitsvorteil auch nach der Quantisierung. Das ist bedeutsam, weil in den meisten Quantisierungs-Pipelines Inference-Beschleunigungstricks und Kompressionstricks in Konflikt geraten. Google hat beides ausgeliefert.

Wer unter Druck gerät

Die am stärksten exponierte Gruppe sind Hosted-Inference-Anbieter, die Small-Model-API-Zugang für Anwendungsfälle verkaufen, die eigentlich keine Cloud-Scale-Modelle benötigen. Wenn Ihr Produkt einen gehosteten 7B- oder 8B-Endpunkt für Klassifizierung, Zusammenfassung, Intent-Parsing oder On-Device-Assistent-Features aufruft, ist ein 1GB Gemma 4 E2B, das lokal auf dem Gerät des Nutzers läuft, eine direkte Bedrohung für die Unit-Economics. Die CFO-Frage liegt auf der Hand: Ab welcher Zahl monatlich aktiver Nutzer wird per-Token-Inference teurer als ein einmaliger Download? Bei Consumer-Apps mit Millionen von MAUs hat sich diese Rechnung für gehostete kleine Modelle bereits vor einiger Zeit verschoben, und dieses Release erhöht den Druck weiter.

Der General Counsel bei einem regulierten Fintech- oder iGaming-Unternehmen sollte diese Woche dem Head of Platform eine andere Frage stellen: Welche unserer aktuellen KI-Features, die PII oder KYC-Daten berühren, könnten wir auf On-Device verlagern, und was bedeutet das für unsere Data-Residency-Position? On-Device Inference ist die sauberste regulatorische Geschichte, die es gibt, weil die Daten das Gerät nie verlassen. Ein 1GB-Modell, das auf dem durchschnittlichen Nutzergerät läuft, macht diese Position für Produkt-Teams verfügbar, die bisher argumentieren mussten, es sei technisch nicht machbar.

Mid-Market-KI-Infrastruktur-Startups befinden sich in der unangenehmsten Position. Die Unternehmen, die „Wir hosten Ihr fine-getuntes kleines Modell" verkaufen, werden von oben durch Hyperscaler-Inference-Preise und von unten durch echte On-Device-Optionen in die Zange genommen. Ihr Pitch-Deck braucht eine Überarbeitung. Unterdessen wird der Markt für Mobile-Engineering-Fachkräfte interessant. Teams, die zwei Jahre lang auf serverseitige LLM-Aufrufe gesetzt haben, benötigen nun Engineers, die Quantisierungsformate, accelerator-spezifische Runtimes und den Unterschied zwischen LiteRT-LM und MLX wirklich verstehen. Dieser Talentpool ist dünn, und der Einstellungsmarkt wird das in den nächsten zwei Quartalen entsprechend einpreisen.

Playbook für KI-Entwicklung

Für Platform-Verantwortliche, die in den nächsten 90 Tagen Architekturentscheidungen im sechs- bis achtstelligen Bereich treffen, gehören drei Maßnahmen auf die Agenda dieser Woche. Erstens: Führen Sie die Unit-Economics-Analyse für Ihre drei wichtigsten KI-gestützten Features durch, unter der Annahme von On-Device Inference für das 80. Perzentil der Nutzergeräte. Wenn der Break-even-Punkt innerhalb von 18 Monaten erreichbar ist, ist die gehostete API eine Refactoring-Zielposition, kein dauerhaftes Element. Vergleichen Sie Ihre Zahlen mit veröffentlichten Tarifen von Gemini oder konkurrierenden APIs, um den Abstand konkret zu machen.

Zweitens: Prüfen Sie, welche Ihrer Features wirklich ein Frontier-Modell benötigen und welche GPT-4-Niveau-Fähigkeiten für Aufgaben nutzen, die ein quantisiertes E2B bewältigen könnte. Klassifizierung, strukturierte Extraktion, Kurzform-Generierung und Routing sind die offensichtlichen Kandidaten. Die ehrliche Antwort für die meisten Produktoberflächen ist, dass 30 bis 60 Prozent der LLM-Aufrufe überdimensioniert sind und Sie Frontier-Modell-Preise für Aufgaben zahlen, die ein 1GB-Modell problemlos bewältigt.

Drittens: Bringen Sie einen hybriden Deployment-Proof-of-Concept mit LiteRT-LM oder Transformers.js auf den Plattformen zum Laufen, auf die Sie tatsächlich ausliefern. Lassen Sie das nicht zu einem sechsmonatigen Forschungsprojekt werden. Die Tooling-Reife ist inzwischen so weit, dass ein erfahrener Mobile Engineer innerhalb von zwei Wochen eine funktionierende Demo haben sollte. Der strategische Wert liegt nicht in der Demo selbst, sondern in dem Datenpunkt, den Sie zur nächsten Verhandlung mit Ihrem Hosted-Inference-Anbieter mitbringen. Die Verhandlungsposition verschiebt sich in dem Moment, in dem Sie glaubwürdig abwandern können.

Wichtigste Erkenntnisse

• Gemma 4 E2B mit 1GB macht On-Device Inference auf durchschnittlicher Consumer-Hardware möglich – nicht nur auf Flagship-Smartphones.
• QAT plus gezielte 2-Bit-Quantisierung bei Token-Generierungsschichten bewahrt die Reasoning-Qualität und greift gleichzeitig die speicherdominierenden Modellteile an.
• Das Geschäft mit gehosteten Small-Model-APIs steht vor echtem Preisdruck, da die lokale Alternative wirklich nutzbar wird.
• Regulierte Branchen erhalten eine sauberere Data-Residency-Geschichte, wenn Inference auf das Gerät verlagert wird – etwas, das der General Counsel bereits modellieren sollte.
• Mobile-KI-Engineering-Fachkräfte (Quantisierungsformate, Accelerator-Runtimes, LiteRT-LM, MLX) werden bald zum Einstellungsengpass. Teams, die ihre KI-Roadmap evaluieren, sollten sich jetzt fragen, ob ihre aktuellen Lieferantenverträge eine Ausstiegsklausel haben, die mit dem Tempo dieser Veränderung Schritt hält.