Funktioniert DiffusionGemma mit llama.cpp? Der aktuelle Status

Die kurze Antwort: Standard llama.cpp kann DiffusionGemma nicht ausführen. Die Unterstützung existiert in Pull Request #24423, der zum Zeitpunkt dieses Artikels noch nicht gemergt ist. Dieser PR fügt eine neue, spezielle Binärdatei namens llama-diffusion-cli hinzu — wenn du llama-cli mit einem DiffusionGemma-GGUF ausführst, schlägt es mit folgendem Fehler fehl: error loading model: unknown model architecture: 'diffusion-gemma'.

Warum DiffusionGemma eine eigene Binärdatei braucht

DiffusionGemma ist kein umbenannter Gemma-4-Checkpoint. Es verwendet diskrete Text-Diffusion: Statt Token für Token von links nach rechts zu erzeugen, beginnt es mit einem vollständig maskierten 256-Token-Canvas und verfeinert den gesamten Block durch paralleles Denoising. Dies erfordert bidirektionale Attention während der Generierung, benutzerdefiniertes Sampling-Verhalten bei jedem Denoising-Schritt und einen grundlegend anderen Modell-Runner — all das existiert nicht im standardmäßigen llama.cpp-Autoregress-Pfad.

PR #24423 implementiert dies als separate Binärdatei (llama-diffusion-cli) statt das bestehende llama-cli zu patchen. Bis dieser PR in main gemergt wird, wird kein offizielles llama.cpp-Release es enthalten.

Was ist PR #24423 und wie verwendet man ihn

PR #24423 wurde von danielhanchen (dem Unsloth-Gründer) verfasst und fügt die diffusion-gemma-Architektur zur llama.cpp-Codebasis hinzu. Der PR ist seit DiffusionGemmas Launch am 10. Juni 2026 aktiv, und Community-Mitglieder haben inoffizielle Prebuilds für Linux/WSL2 CUDA und Windows CPU veröffentlicht, während der PR aussteht.

Um selbst aus dem PR-Branch zu bauen:

# llama.cpp klonen
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# PR-Branch holen und auschecken
git fetch origin pull/24423/head:diffusion-gemma-pr
git checkout diffusion-gemma-pr

# Bauen (CUDA-Beispiel)
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Die neue Binärdatei liegt hier:
./build/bin/llama-diffusion-cli

Für reine CPU-Builds das -DGGML_CUDA=ON-Flag weglassen.

Ein Modell ausführen

Ein vertrauenswürdiges DiffusionGemma-GGUF herunterladen (Unsloth veröffentlicht die meistgenutzten unter unsloth/diffusiongemma-26B-A4B-it-GGUF auf Hugging Face), dann:

./build/bin/llama-diffusion-cli \
  -m ./diffusiongemma-26B-A4B-it-Q4_K_M.gguf \
  -p "Erkläre den Unterschied zwischen Diffusion und autoregressiver Textgenerierung." \
  --diffusion-steps 128

Der Parameter --diffusion-steps steuert, wie viele Denoising-Durchläufe das Modell ausführt. Mehr Schritte = höhere Qualität, langsamere Generierung. Mit 128 beginnen und anpassen.

Speicherbedarf

Das Modell basiert auf der Gemma 4 26B A4B MoE-Architektur, daher sind die Speicheranforderungen identisch:

• Q4_K_M: etwa 14,4–18 GB (Unsloths Praxismessung: 18 GB)
• Q8: etwa 28 GB
• BF16: etwa 52–58 GB

Das Modell aktiviert trotz 26B geladener Gesamtparameter nur ~3,8B Parameter pro Forward Pass.

Geschwindigkeit: Was die Zahlen wirklich bedeuten

Google behauptet bis zu 4-fache Generierungsgeschwindigkeit gegenüber Standard-Gemma 4 und über 1.000 Token pro Sekunde auf einer H100. Diese Zahlen stimmen auf der beschriebenen Hardware. Was sie nicht sagen:

Der Geschwindigkeitsvorteil ist bedingt. Die parallele Generierung von DiffusionGemma verändert das Rechenprofil von speicherbandbreitenbegrenzt (was autoregressive Modelle sind) zu rechenbegrenzt (was Diffusionsmodelle sind). Auf High-End-NVIDIA-GPUs mit viel Rechenleistung — RTX 3090, 4090, A100, H100 — spielt das zugunsten von DiffusionGemma. Auf Low-End-GPUs (RTX 3060, 4060) und Apple Silicon kann der Vorteil verschwinden. Überprüfe deinen Hardware-Benchmark, bevor du die Headline-Zahlen erwartest.

Die Qualität ist geringer. Google stellt explizit fest, dass DiffusionGemmas Ausgabequalität unter Standard-Gemma 4 liegt. Das ist keine vorübergehende Einschränkung — es ist der fundamentale Speed-Quality-Kompromiss des Diffusionsansatzes.

Runtime-Vergleichstabelle

Runtime	DiffusionGemma-Status (Juni 2026)
llama.cpp (main)	Nicht unterstützt. unknown model architecture: 'diffusion-gemma'
llama.cpp (PR #24423)	Unterstützt via llama-diffusion-cli. Muss aus PR-Branch gebaut werden.
Unsloth Studio	Unterstützt ab v0.1.463-beta / 2026.6.6. Einfachster lokaler Weg.
Ollama	Nicht unterstützt. Issue #16664 offen.
LM Studio	Nicht unterstützt. Gebündelte Runtime enthält PR #24423 nicht.
vLLM	Vollständig unterstützt seit 10. Juni 2026. Bester Serving-Weg.
HF Transformers	Unterstützt via offizielles Google-Release.

Welchen Weg verwenden

Wenn du eine lokale GUI mit minimalem Aufwand möchtest: Nutze Unsloth Studio. Es unterstützt DiffusionGemma nativ seit dem Release vom 12. Juni und behandelt die Inferenzparameter automatisch.

Wenn du mit der Kommandozeile vertraut bist: Aus PR #24423 bauen und llama-diffusion-cli direkt verwenden. Das gibt dir die meiste Kontrolle über Diffusionsparameter.

Wenn du eine Python-Umgebung nutzt: HuggingFace Transformers mit den offiziellen google/diffusiongemma-26B-A4B-it-Gewichten verwenden.

Wenn du mehrere Nutzer bedienen musst: vLLM hat native Unterstützung als erste Inference-Engine, die DiffusionGemma vollständig integriert.

Wenn du Ollama oder Standard-LM-Studio nutzt: Warten. Beide hängen am gleichen zugrundeliegenden PR und es gibt keinen Workaround ohne Custom-Binaries.

FAQ

Kann ich einfach llama.cpp auf die neueste Version aktualisieren, um DiffusionGemma zu nutzen?
Nein. PR #24423 ist nicht in main gemergt. Ein Update aus dem offiziellen Repository fügt keine diffusion-gemma-Architekturunterstützung hinzu.

Gibt es eine fertige llama-diffusion-cli-Binärdatei zum Herunterladen?
Inoffizielle Community-Prebuilds gibt es für Linux/WSL2 CUDA (sm_86, RTX 30-Serie) und Windows CPU. Auf GitHub nach „llama-diffusion-cli-prebuilt" suchen. Das sind keine offiziellen Anthropic- oder ggml-org-Releases.

Produziert DiffusionGemma bessere Ausgaben als normales Gemma 4?
Nein. Google sagt explizit, die Ausgabequalität liegt unter Standard-Gemma 4. Der Vorteil ist Geschwindigkeit, besonders für Code-Infilling und Inline-Editing-Workflows, bei denen ein Qualitätskompromiss akzeptabel ist.

Warum schlägt Ollama fehl, obwohl es llama.cpp verwendet?
Ollama bündelt seine eigene llama.cpp-Version, die hinter upstream zurückliegt. Selbst wenn du Ollama aktualisierst, enthält die gebündelte Runtime PR #24423 nicht.

Verwandte Guides:

• Funktioniert DiffusionGemma in LM Studio?
• Unbekannte Modellarchitektur gemma4 in llama.cpp beheben
• Gemma 4 A4B vs. E4B: Welches Modell verwenden