Funktioniert DiffusionGemma in LM Studio? Aktueller Status (Juni 2026)

Nein, DiffusionGemma funktioniert derzeit nicht in LM Studio. Das ist kein Konfigurationsproblem und kein Datei-Problem. LM Studios gebündelte Runtimes — sowohl die llama.cpp-Engine als auch die MLX-Engine für Apple Silicon — unterstützen die diffusion-gemma-Architektur nicht. Zwei bestätigte Bug-Reports auf GitHub verfolgen dies.

Was tatsächlich passiert, wenn du es versuchst

Auf Apple Silicon (MLX-Pfad)

Wenn du versuchst, DiffusionGemma über LM Studios MLX-Engine (Version 1.8.5) zu laden, erscheint:

Failed to load model.
Error when loading model: ValueError: Model type diffusion_gemma not supported.
Error: No module named 'mlx_vlm.speculative.drafters.diffusion_gemma'

Das liegt daran, dass LM Studio mlx-vlm 0.4.5 (ein April-2026-Dev-Build) bündelt. DiffusionGemma benötigt mlx-vlm 0.6.3 oder neuer. Das lässt sich nicht durch das Aktualisieren der LM-Studio-Engines innerhalb der App beheben — die gebündelte Library-Version ist was sie ist, bis LM Studio ein Update liefert.

Verfolgt in: lmstudio-bug-tracker #2037

Auf Windows / Linux (llama.cpp-Pfad)

LM Studios llama.cpp-Engine (Metal llama.cpp v2.21.0 o.ä.) schlägt fehl mit:

error loading model: unknown model architecture: 'diffusion-gemma'

Das liegt daran, dass DiffusionGemma-Unterstützung in llama.cpp in PR #24423 liegt, der nicht gemergt ist. LM Studio bündelt eine veröffentlichte Version von llama.cpp, enthält den PR also nicht.

Verfolgt in: lmstudio-ai/lms #583

Wann wird LM Studio DiffusionGemma unterstützen?

LM-Studio-Unterstützung hängt davon ab, dass zwei Dinge upstream gemergt werden:

1. PR #24423 wird in llama.cpp main gemergt (für den llama.cpp-Pfad)
2. mlx-vlm 0.6.3+ wird gebündelt (für den Apple-MLX-Pfad)

Beides ist noch nicht passiert. LM Studio müsste danach noch ein Release herausbringen. Realistisch sind das Wochen, keine Tage.

Was jetzt wirklich funktioniert

Runtime	DiffusionGemma-Unterstützung	Hinweis
Unsloth Studio	Ja	Einfachster lokaler Weg. Läuft auf macOS/Windows/Linux. Unterstützt seit 12. Juni 2026 (v0.1.463-beta).
vLLM	Ja	Bestes Serving. Native Unterstützung seit 10. Juni 2026. Erfordert Linux + NVIDIA GPU.
HF Transformers	Ja	Nur Python. Offizielle Google-Gewichte unter google/diffusiongemma-26B-A4B-it.
llama.cpp (PR #24423)	Ja	Nur CLI. Muss aus dem PR-Branch gebaut werden. Nutzt llama-diffusion-cli, nicht llama-cli.
LM Studio	Nein	Sowohl MLX- als auch llama.cpp-Engine schlagen fehl.
Ollama	Nein	Issue #16664 offen.

Empfohlener Weg je nach Nutzertyp

Desktop-GUI gewünscht: Unsloth Studio ist derzeit die einzige funktionierende lokale GUI. Nach der Installation DiffusionGemma im Modell-Browser suchen.

Apple-Silicon-Nutzer: Unsloth Studio unterstützt macOS. Der MLX-Pfad in LM Studio funktioniert noch nicht.

Kommandozeilenerfahren: llama.cpp aus PR #24423 bauen und llama-diffusion-cli direkt verwenden. Gibt die meiste Kontrolle über Diffusionsschritte und andere Parameter.

Python-Entwickler, der schnell experimentieren will: HuggingFace Transformers mit den offiziellen google/diffusiongemma-26B-A4B-it-Gewichten.

Muss DiffusionGemma für mehrere Nutzer bereitstellen: vLLM hat native Unterstützung und veröffentlichte Benchmarks.

Ollama-Nutzer: Warten. Kein Workaround ohne Custom-Binaries.

Vor dem Einsatz von DiffusionGemma: Was zu wissen ist

DiffusionGemma hat echte Geschwindigkeitsvorteile in der richtigen Umgebung. Auf NVIDIA RTX 3090/4090 und High-End-Karten kann die Generierung bei niedrigem Concurrency mehrfach schneller sein als Standard-Gemma-4. Auf Low-End-NVIDIA-Karten (3060, 4060) und Apple Silicon taucht der Vorteil möglicherweise gar nicht auf. Das Modell verschiebt die Inferenz von speicherbandbreitengebunden (wo Apple Silicon glänzt) zu rechengebunden (wo dedizierte High-End-NVIDIA-GPUs glänzen).

Wichtiger: Google stellt explizit fest, dass DiffusionGemmas Ausgabequalität unter Standard-Gemma 4 liegt. Das ist keine vorübergehende Einschränkung. Der Speed-Quality-Kompromiss ist ein grundlegendes Merkmal des Diffusionsansatzes. Wer maximale Qualität braucht, ist mit Standard-Gemma 4 besser bedient.

DiffusionGemma eignet sich besonders für:

• Code Infilling (Code in der Mitte bestehender Dateien einfügen)
• Inline-Editing mit Vor-/Nach-Kontext
• Interaktive lokale Anwendungen, wo Latenz wichtig ist und etwas Qualitätsabzug akzeptabel ist

Weniger geeignet für:

• Aufgaben mit hohen Faktualitätsanforderungen
• Komplexes mehrstufiges Reasoning, wo Präzision akkumuliert
• Szenarien, in denen Ausgaben kritisch mit Standard-Gemma-4 verglichen werden

FAQ

Behebt ein LM-Studio-Update das Problem?
Nicht bis LM Studio ein Release mit mlx-vlm 0.6.3+ (für Apple) oder einer neuen llama.cpp mit PR #24423 (für andere) liefert. Kein aktuelles Release macht das.

Kann ich LM Studio auf eine benutzerdefinierte Runtime zeigen?
LM Studio unterstützt derzeit kein Austauschen einer benutzerdefinierten llama.cpp-Binärdatei. Die gebündelte Runtime ist das, was man bekommt.

Funktioniert Standard-Gemma 4 in LM Studio noch?
Ja. Die gemma4-Architektur ist in aktuellen LM-Studio-Releases unterstützt. Die Einschränkung gilt spezifisch für diffusion-gemma.

Wie lange wird es dauern, bis das behoben ist?
Schwer vorherzusagen. Es hängt von PR #24423 in llama.cpp, einem LM-Studio-Update mit der neuen llama.cpp-Version und dem MLX-Team ab, das mlx-vlm aktualisiert. Realistisch Wochen eher als Tage.

Verwandte Guides:

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