Gemma 4 mit vLLM betreiben: welches 4-Bit-Format funktioniert (W4A16 statt GGUF)

Sie möchten Gemma 4 produktiv mit vLLM betreiben und die passende GPU-Stufe wählen?

Die Seite zum Gemma Hosting zeigt, welche Gemma-4-Checkpoints wir auf welcher Stufe betreiben. Auf dem Managed GPU Server mit 24 GB VRAM ab 699 € netto im Monat läuft Gemma 4 12B als W4A16-Checkpoint, für Gemma 4 31B und 26B A4B ist die Stufe mit 96 GB VRAM vorgesehen.

Gemma Hosting ansehen · Managed GPU Server ansehen

Wer Gemma 4 mit 4 Bit betreiben will, findet bei Google mehrere offizielle Varianten. Die auffälligste ist die GGUF-Datei mit Q4_0, sie ist auch die kleinste. Für vLLM ist sie aber nicht gedacht: Google stellt die GGUF-Dateien für llama.cpp bereit und die compressed-tensors-Checkpoints mit W4A16 für vLLM (Google: QAT für Gemma 4). Dieser Artikel ordnet die Formate ein, zeigt Größen und GPU-Stufen und nennt die Stolperstellen beim Start. Modell- und Dateiangaben Stand Oktober 2026.

Inhaltsverzeichnis

• Das Problem: die falsche 4-Bit-Datei
• Die Formate im Überblick
• Welcher Checkpoint auf welcher Runtime
• Gemma 4 mit W4A16 in vLLM starten
• Warum GGUF in vLLM nicht der Standardweg ist
• Sonderfall Gemma 4 26B A4B
• Stolperstellen: Kontextlänge und Bildeingaben
• Lizenz: Apache 2.0 ab Gemma 4
• Unser Vorgehen bei WZ-IT
• Quellen

Das Problem: die falsche 4-Bit-Datei

Google hat im Juni 2026 Checkpoints mit Quantization-Aware Training (QAT) für Gemma 4 veröffentlicht. Beim QAT wird die Quantisierung bereits im Training simuliert, deshalb verliert das Modell bei 4 Bit weniger Qualität als bei nachträglicher Quantisierung (Google: QAT für Gemma 4).

Die QAT-Gewichte gibt es in mehreren Verpackungen. Laut Model Card sind das:

• GGUF (Q4_0) für E2B, E4B, 12B, 26B A4B und 31B, fertig für das llama.cpp-Ökosystem.
• Compressed Tensors (W4A16) für E2B, E4B, 12B und 31B, für die native Inferenz mit vLLM.
• Unquantisierte QAT-Checkpoints in halber Präzision, als Ausgangspunkt für eigene Konvertierungen.
• Mobile-Format für E2B und E4B.

Wer nach „Gemma 4 4-bit" sucht, landet häufig zuerst bei den GGUF-Repositories, weil sie die kleinsten Dateien haben und für 26B A4B die einzige fertig quantisierte Variante sind. In einem vLLM-Setup ist das der falsche Startpunkt.

Die Formate im Überblick

W4A16 bedeutet: 4-Bit-Gewichte (W4) und 16-Bit-Aktivierungen (A16). Die Gemma-4-Checkpoints nutzen ganzzahlige 4-Bit-Gewichte mit einer Gruppengröße von 32 im Format compressed-tensors, das vLLM nativ liest (vLLM-Rezept Gemma 4). Einbettungsmatrix und Vision-Encoder bleiben laut quantization_config in der config.json in 16 Bit.

GGUF ist das Containerformat von llama.cpp. Es ist auf Einzelplatz- und CPU/GPU-Mischbetrieb ausgelegt. Bei Gemma 4 liegt neben dem Sprachmodell eine eigene mmproj-Datei für die Bildverarbeitung.

Welche Rolle FP8, NVFP4, AWQ und GPTQ allgemein spielen, erklärt der Artikel LLM-Quantisierung.

Welcher Checkpoint auf welcher Runtime

Die Größen sind die Summe der Gewichtsdateien laut Hugging Face, in GB (10⁹ Byte). Sie enthalten noch keinen KV-Cache.

Der Managed GPU Server 24 hat eine NVIDIA RTX PRO 4000 Blackwell mit 24 GB, der Managed GPU Server 96 eine RTX PRO 6000 Blackwell mit 96 GB. Gemma 4 31B W4A16 steht in der Tabelle bei 96 GB, obwohl die Gewichte unter 24 GB liegen: vLLM belegt standardmäßig 92 Prozent des GPU-Speichers (Engine-Argumente), nach Gewichten, Aktivierungen und CUDA-Graphen bleibt auf 24 GB kaum Platz für den KV-Cache. Die vLLM-Rezeptseite nennt für das geladene Modell 19,8 GB, für Gemma 4 12B W4A16 8,3 GB (vLLM-Rezept Gemma 4). Wie sich Gewichte, Cache und Overhead addieren, zeigt GPU und VRAM für LLMs dimensionieren.

Gemma 4 mit W4A16 in vLLM starten

vLLM liest die Quantisierung aus der Konfiguration des Checkpoints. Ein --quantization-Flag ist für die W4A16-Checkpoints nicht nötig (vLLM-Rezept Gemma 4). Ein minimaler Start für Gemma 4 12B auf einer GPU mit 24 GB:

vllm serve google/gemma-4-12B-it-qat-w4a16-ct \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --limit-mm-per-prompt '{"image": 2, "audio": 0}'

• --max-model-len begrenzt den Kontext je Anfrage. Ohne den Wert gilt die maximale Länge aus der Modellkonfiguration (Engine-Argumente).
• --gpu-memory-utilization legt fest, welchen Anteil des GPU-Speichers vLLM für Gewichte und KV-Cache belegt. Das Rezept empfiehlt 0,85 bis 0,95.
• --limit-mm-per-prompt begrenzt Bilder und Audio je Anfrage. Audio auf 0 spart beim 12B-Modell den Speicher für den Audio-Embedder.

Für Funktionsaufrufe und den Thinking-Modus nennt das Rezept zusätzlich --enable-auto-tool-choice, --tool-call-parser gemma4 und --reasoning-parser gemma4. Gemma 4 31B W4A16 startet mit denselben Argumenten, dann auf einer GPU mit 96 GB. Die API ist OpenAI-kompatibel, Open WebUI oder andere Clients sprechen den Endpunkt /v1/chat/completions an. Wie vLLM grundsätzlich arbeitet, beschreibt Was ist vLLM?.

Warum GGUF in vLLM nicht der Standardweg ist

vLLM kann GGUF-Dateien laden, aber nicht gleichwertig zu den eigenen Formaten. Die GGUF-Seite der vLLM-Dokumentation hält drei Punkte fest:

• Die Unterstützung ist hochgradig experimentell und wenig optimiert und kann mit anderen Funktionen inkompatibel sein.
• Sie ist in das separate vllm-gguf-plugin ausgelagert, das zusätzlich installiert werden muss.
• Der Tokenizer soll aus dem Basismodell kommen, weil die Konvertierung aus GGUF langsam und instabil ist, besonders bei großem Vokabular. Gemma 4 hat ein Vokabular von 262.144 Token.

Hintergrund ist ein RFC im vLLM-Projekt, GGUF und bitsandbytes aus dem Kern zu lösen. Er schätzt den Anteil von GGUF an der Nutzung auf rund 0,1 Prozent und hält fest, dass GGUF-Modelle mit llama.cpp häufig schneller laufen. Das Plugin führt Gemma 4 zwar in seiner Liste getesteter Modelle, allerdings mit einer Q4_K_M-Quantisierung und BF16-Projektor, nicht mit Googles QAT-Q4_0-Datei.

Für einen produktiven vLLM-Server mit mehreren Nutzern bedeutet das: Der W4A16-Checkpoint nutzt die optimierten Kernel und den normalen Ladepfad von vLLM. Die GGUF-Datei gehört zu llama.cpp, Ollama oder LM Studio. Den Unterschied der beiden Engines zeigt vLLM vs. Ollama.

Sonderfall Gemma 4 26B A4B

Für das Mixture-of-Experts-Modell 26B A4B gibt es keinen W4A16-Checkpoint. Laut vLLM-Rezept verliert das Modell wegen seiner kleinen Expertendimension (128 Experten mit Zwischengröße 704) bei 4 Bit zu viel Qualität. Für vLLM bleiben zwei Wege:

• BF16 mit rund 51,6 GB Gewichten, auf einer GPU mit 96 GB.
• Online-Quantisierung beim Laden mit --quantization int8_per_channel_weight_only. Das Rezept nennt rund 47 Prozent Speicherersparnis bei vernachlässigbarem Qualitätsverlust; einen Checkpoint braucht es dafür nicht (vLLM: Online-Quantisierung).

Mit rund 27 GB Gewichten passt auch die INT8-Variante nicht auf 24 GB. Für 26B A4B bleibt die Stufe mit 96 GB der Ausgangspunkt. Pro Token arbeiten nur rund 3,8 Milliarden Parameter, das Modell antwortet deshalb schneller als 31B.

Stolperstellen: Kontextlänge und Bildeingaben

Kontextlänge. Gemma 4 12B, 26B A4B und 31B unterstützen bis zu 256K Token, die config.json von 31B nennt 262.144 Token. Ohne --max-model-len übernimmt vLLM diesen Wert und muss Cache für mindestens eine Sequenz dieser Länge bereitstellen. Auf knappen GPUs bricht der Start dann ab. Ein fester Wert wie 32768 passt für Chat und Dokumentenfragen. Alternativ wählt --max-model-len auto die größte Länge, die in den Speicher passt (Engine-Argumente).

Gemma 4 entlastet den KV-Cache durch hybride Attention. Bei 31B nutzen laut config.json nur 10 von 60 Layern globale Attention, die übrigen 50 ein gleitendes Fenster von 1.024 Token. Der Cache wächst damit langsamer als bei einem Modell mit voller Attention in jedem Layer, aber er wächst weiter mit Kontext und Zahl gleichzeitiger Sitzungen. Ein FP8-KV-Cache mit --kv-cache-dtype fp8 halbiert ihn zusätzlich; die Genauigkeit gehört vor dem Produktivbetrieb geprüft.

Bildeingaben. Alle drei Modelle nehmen Text und Bilder entgegen, 12B zusätzlich Audio. Jedes Bild belegt je nach Budget 70, 140, 280, 560 oder 1.120 Token Kontext; Standard sind 280, einstellbar mit --mm-processor-kwargs '{"max_soft_tokens": 560}' (vLLM-Rezept Gemma 4). Für OCR und kleine Schrift sind höhere Budgets sinnvoll, sie verbrauchen aber entsprechend Kontext. Ohne Begrenzung erlaubt vLLM bis zu 999 Eingaben je Modalität und Anfrage. Wer nur Text verarbeitet, setzt --language-model-only; vLLM überspringt dann die multimodale Speicherreservierung.

Bei der GGUF-Variante sind die Bildfähigkeiten in die separate mmproj-Datei ausgelagert. Wer nur die Sprachmodell-Datei lädt, hat kein Bildverständnis.

Lizenz: Apache 2.0 ab Gemma 4

Gemma 4 steht unter der Apache License 2.0, auch die QAT-Checkpoints. Für Gemma 3 und ältere Versionen gelten weiterhin die Gemma Terms of Use mit einer eigenen Prohibited Use Policy. Wer von Gemma 3 auf Gemma 4 wechselt, sollte die Lizenzprüfung deshalb aktualisieren. Einen Vergleich der Lizenzen offener Modelle bietet LLM-Lizenzen für kommerzielle Nutzung.

Unser Vorgehen bei WZ-IT

Auf unseren Managed GPU Servern betreiben wir Gemma 4 mit vLLM. Wir wählen dafür den Checkpoint, den Google für vLLM vorsieht, und legen Kontextlänge, Zahl gleichzeitiger Sitzungen und Bildbudget nach Ihrem Anwendungsfall fest:

1. Modell und Format wählen: Gemma 4 12B W4A16 auf 24 GB, Gemma 4 31B (BF16 oder W4A16) oder 26B A4B auf 96 GB.
2. Speicher prüfen: Gewichte, KV-Cache bei der gewünschten Kontextlänge und Overhead gegen die GPU rechnen; der verfügbare Cache steht im vLLM-Startlog.
3. Mit eigenen Beispielen testen: Antworten auf Deutsch, Dokumente und Bilder aus Ihrem Alltag, bevor das Modell produktiv geht.

Welche Gemma-4-Modelle wir auf welcher Stufe einsetzen, zeigt die Seite zum Gemma Hosting. Einen Vergleich der Betriebswege bietet die Seite zum LLM-Hosting.

Weiterführend: Welches LLM selbst hosten? ordnet Gemma neben anderen offenen Modellen ein, Multi-GPU-Inferenz ohne NVLink beschreibt den Schritt auf mehrere GPUs.

Quellen

• Google: Quantization-Aware Training für Gemma 4
• Hugging Face: Model Card gemma-4-31B-it-qat-w4a16-ct
• Hugging Face: Model Card gemma-4-31B-it-qat-q4_0-gguf
• vLLM-Rezept: Gemma 4 Usage Guide
• vLLM-Dokumentation: GGUF
• vLLM-Dokumentation: Engine-Argumente
• vLLM-Dokumentation: Unterstützte Modelle
• vllm-gguf-plugin auf GitHub
• Google: Gemma 4 License (Apache 2.0)