LM Studio Qwen3.5 lädt nicht: 'unknown model architecture: qwen35' beheben

Was bedeutet 'unknown model architecture: qwen35'?

Beim Öffnen einer GGUF-Datei liest LM Studio zunächst Metadaten wie general.architecture. Bei dichten Qwen3.5-GGUFs kann dort qwen35 stehen. Kennt der ausgewählte llama.cpp-Motor diesen Schlüssel nicht, stoppt das Laden, bevor das Modell normal initialisiert wird.

'Failed to load model' ist nur die allgemeine Überschrift. Entscheidend ist die technische Zeile mit 'unknown model architecture'. 'Unknown' bedeutet nicht automatisch, dass die GGUF beschädigt ist, sondern dass der Runtime keinen passenden Loader für diese Architektur besitzt.

Der Fehler kann unter Windows oder Linux und mit verschiedenen GPUs auftreten, weil er häufig vor der eigentlichen GPU-Speicherbelegung entsteht.

Failed to load model
error loading model: error loading model architecture: unknown model architecture: 'qwen35'

Was sind qwen35 und qwen35moe?

Der interne Architektur-Schlüssel einer GGUF muss nicht exakt dem Produktnamen entsprechen. Dichte Qwen3.5-Dateien können qwen35 verwenden; Mixture-of-Experts-Varianten können qwen35moe verwenden.

Qwen3.5-27B kann daher qwen35 melden, während Qwen3.5-35B-A3B als MoE-Variante qwen35moe verwenden kann. In beiden Fällen deutet 'unknown architecture' zuerst auf Runtime-Kompatibilität.

Aktueller llama.cpp-Quellcode enthält Qwen3.5-Architekturkonstanten; ein älteres gepacktes Runtime kann trotzdem noch scheitern.

Warum dies nicht primär ein RAM- oder VRAM-Fehler ist

Speicherfehler entstehen, nachdem der Runtime die Architektur erkannt hat und Gewichte, KV-Cache oder Compute-Buffer reserviert. Dann erscheinen eher 'out of memory', 'failed to allocate' oder CUDA-Allocation-Fehler.

Auch ein PC mit viel RAM/VRAM kann qwen35 nicht laden, wenn der Runtime zu alt ist. Nach einem Update kann anschließend ein echter OOM auftreten; das ist ein zweiter, separater Fehler.

LM-Studio-Version und llama.cpp-Runtime sind getrennte Ebenen

Die Desktop-App stellt Oberfläche, Katalog, Chat und Server bereit. GGUF-Inferenz läuft über ein llama.cpp Runtime Extension Pack. Nur die App oder nur den Runtime zu aktualisieren kann deshalb unvollständig sein.

Laut offizieller Dokumentation öffnet Ctrl + Shift + R unter Windows/Linux die Runtime-Verwaltung. Alternativ gibt es lms runtime in der CLI. Am 15. August 2026 ist LM Studio 0.4.21 stabil; der Changelog nennt llama.cpp 2.28.1+.

Wenn nur 1.x-Motoren erscheinen, zuerst LM Studio aktualisieren, Runtime-Katalog aktualisieren und dann den aktiven GGUF-Motor prüfen.

Schritt-für-Schritt-Lösung unter Windows

Eine 10-30+ GB große GGUF sofort neu herunterzuladen ist bei einem Architekturfehler meist unnötig. Derselbe Download mit demselben alten Runtime führt oft zum selben Ergebnis.

Änderungen einzeln durchführen und nach wichtigen Schritten neu laden. Ändert sich die Fehlermeldung, muss die neue Meldung separat diagnostiziert werden.

Warum v1.104.2 als 'Latest Version Installed' erscheinen kann

'Latest' kann lediglich das neueste Paket bedeuten, das die aktuelle App bzw. der aktuelle Kanal kennt. Eine ältere LM-Studio-Version kann daher v1.104.2 als aktuell markieren, obwohl moderne 2.x-Motoren existieren.

Der Screenshot zeigt Vulkan, CUDA, CPU und CUDA 12 jeweils mit v1.104.2. Zwischen diesen alten Builds zu wechseln bringt qwen35-Unterstützung nicht automatisch. App aktualisieren, Katalog neu laden und aktuellen 2.x-Motor auswählen.

Nach der Installation zusätzlich kontrollieren, ob GGUF tatsächlich auf den neuen Motor zeigt.

CUDA 12, CUDA, Vulkan oder CPU: welcher Runtime passt?

Bei NVIDIA ist ein aktueller CUDA-basierter llama.cpp-Motor meist die erste Wahl. CUDA 12 passt zu kompatiblen Treibern und Karten. Für diesen Fehler ist vor allem entscheidend, dass der Motor neu genug für Qwen3.5 ist.

Vulkan bietet breite Unterstützung für AMD/Intel und kann auch zur Diagnose dienen. Ein kleiner Qwen3.5-Test auf CPU hilft, GPU-Abhängigkeiten auszuschließen.

Zuerst stabil laden, erst danach Geschwindigkeit optimieren.

Ist 'unknown model architecture: qwen35moe' derselbe Fehlertyp?

Ja. qwen35moe betrifft Qwen3.5-MoE-Varianten wie 35B-A3B. Im offiziellen LM-Studio-Bugtracker gibt es entsprechende Meldungen.

MoE beeinflusst später Speicher und Performance, aber 'unknown architecture' entsteht vorher. Erst Runtime-Kompatibilität herstellen.

Failed to load model
error loading model: error loading model architecture: unknown model architecture: 'qwen35moe'

Alles aktualisiert, Fehler bleibt: zweite Prüfebene

Nicht nur installierte, sondern die tatsächlich aktive Engine prüfen. Mehrere Versionen können parallel vorhanden sein. Modell entladen, LM Studio neu starten und mit dem neuen Motor erneut laden.

Danach ein kleines Qwen3.5 aus einer vertrauenswürdigen Quelle testen. Funktioniert 2B/4B, aber ein einzelnes Drittanbieter-GGUF nicht, ist die Datei bzw. deren Build genauer zu prüfen.

Server-Logs zeigen, welche Architektur gelesen und welcher Runtime verwendet wird.

Beeinflussen Q4_K_M, Q5, Q6 oder Q8 diesen Fehler?

Quantisierung verändert Dateigröße, Speicherbedarf und Qualität, ergänzt aber keinen fehlenden Architektur-Loader. Wenn qwen35 unbekannt ist, behebt Q4 statt Q8 den Grundfehler nicht.

Sobald die Architektur erkannt wird, wird Quantisierung für RAM/VRAM relevant. KV-Cache, Context, Projektor und Runtime-Buffer benötigen zusätzlichen Speicher.

Ein kleines Qwen3.5 eignet sich gut, um die Runtime-Kompatibilität getrennt vom Speicherbedarf zu testen.

qwen35 behoben, jetzt Out of Memory: Context Length

Die offizielle Qwen3.5-27B-Karte nennt 262.144 Token Standardkontext und empfiehlt bei OOM, das Context Window zu reduzieren. Langer Kontext kann den KV-Cache stark vergrößern.

Lokal zunächst mit 8K oder 16K stabil testen und nur bei Bedarf erhöhen. GPU-Offload, Quantisierung und Context gemeinsam an RAM/VRAM anpassen.

Ein OOM nach dem Verschwinden von qwen35 ist ein anderer Fehler und kann zeigen, dass der Runtime das Modell nun erkennt.

Text funktioniert, Bild-Input nicht: mmproj/Projektor

Das ist eine andere Fehlerstufe. Qwen3.5 kann multimodal sein, bei GGUF kann dafür jedoch eine passende mmproj/Projector-Datei nötig sein. llama.cpp-Fehlerberichte zeigen die separate Meldung 'image input is not supported'.

Wenn Textchat funktioniert, war das Architektur-Laden erfolgreich. Prüfen, ob der Model-Build einen Projektor mitliefert und ob LM Studio ihn korrekt zuordnet.

Textbetrieb kann auch dann funktionieren, wenn der Vision-Projektor fehlt.

'Failed to load model': technische Zeile richtig lesen

Die Überschrift ist nur ein Sammelfehler. Die nächste technische Zeile unterscheidet Runtime-, Speicher-, Datei-, GPU- und Vision-Probleme.

Für Details Developer Logs oder lms log stream --source server nutzen und nach dem exakten Fehlertext suchen.

Runtime und Logs per CLI prüfen

Mit lms runtime ls, lms runtime update und lms runtime select lassen sich installierte und ausgewählte Runtimes kontrollieren.

lms log stream --source server zeigt Lade-Logs; lms ls listet Modelle auf der Platte und lms ps geladene Modelle im Speicher.

Private Pfade oder Zugangsdaten vor dem Teilen von Logs entfernen.

lms runtime ls
lms runtime update
lms runtime select

lms ls
lms ps
lms log stream --source server

Welche Qwen3.5-Größe wählen?

LM Studio listet unter anderem 2B, 4B, 9B, 27B und 35B-A3B. Kleine Modelle sind ideal für Kompatibilitätstests; große Modelle benötigen deutlich mehr Ressourcen.

Nach einem Runtime-Update zuerst ein kleines Qwen3.5 laden. Funktioniert es, anschließend 27B oder 35B-A3B testen und Kapazitätsprobleme getrennt lösen.

Für Coding, Mehrsprachigkeit, Tools und Dokumente zählen zusätzlich Quantisierung, Context und Prompt-Format.

Performance nach erfolgreichem Laden optimieren

Immer mit gleichem Modell, Quantisierung, Context und Prompt vergleichen. GPU-Offload erhöhen, aber genügend VRAM für KV-Cache und Buffer frei lassen.

Unnötig große Context Windows vermeiden. Bei Benchmarks App-Version, Runtime, GPU, GGUF-Datei und Quantisierung notieren, weil sich Qwen3.5-Leistung zwischen llama.cpp-Versionen ändern kann.

Neben tokens/s auch Time-to-first-token und Prompt-Verarbeitung messen.

Wann GGUF wirklich neu herunterladen?

Nur qwen35/qwen35moe ist meist kein Grund für einen neuen Download, da die Metadaten bereits gelesen werden konnten.

Neu herunterladen bei falscher Dateigröße, abgebrochenem Transfer, unexpected EOF, fehlenden Tensor-/Header-Daten oder Checksum-Abweichung. Bei gesplitteten GGUFs müssen alle Shards vorhanden sein.

Öffnet dieselbe Datei in einer anderen aktuellen llama.cpp-Anwendung, spricht das für eine grundsätzlich lesbare Datei.

Saubere Neuinstallation nur als letzter Schritt

Vorher Modellverzeichnis notieren und Dateien behalten. Oft reicht es, alte Runtimes zu entfernen und einen aktuellen Runtime neu zu installieren.

Bei kompletter Neuinstallation Chatverlauf, Einstellungen und Modellpfade sichern. Danach zuerst ein kleines Qwen3.5 testen.

Für einen Bugreport LM-Studio-Version, OS, GPU, Runtime-Version, exakten GGUF-Namen und Server-Logs angeben.