LM Studio funktioniert nicht? 7 Fehler, die genaue Meldung und die Lösung

Wenn LM Studio nicht mitspielt, verrät die Meldung meist, wo man suchen muss. Diese Anleitung behandelt die Fehler, die in seinem eigenen Bugtracker am häufigsten gemeldet werden, dazu die zum Server und zu lms aus seiner Dokumentation: ein Modell, das nicht lädt, die Speicher-Leitplanke, ein Kontext, der ausgeht, ein Modell, das auf der CPU festsitzt, eine veraltete Engine, ein Server, den niemand erreicht, und ein fehlender lms-Befehl.

Es gibt eine ganz besondere Stille: wenn ein Modell, auf das Sie sich gefreut haben, statt mit einem Satz mit einer Fehlermeldung antwortet. Das passiert jedem. Die gute Nachricht: Die Fehler von LM Studio sind genauer, als sie aussehen, und zu jedem finden Sie unten den genauen Wortlaut, den Grund und die Lösung, für die aktuelle stabile Version 0.4.26 (veröffentlicht am 8. Oktober 2026 und am 9. Oktober 2026 weiterhin die neueste stabile Version). Geschrieben wurde diese Anleitung an 0.4.25; die Versionshinweise zu 0.4.26 führen keine Änderung an diesen Meldungen auf, und die von lms stehen am 9. Oktober 2026 unverändert in seinem Code. Installation, Serverstart und Absicherung stehen in unserer Anleitung, um LM Studio einzurichten; diese Seite macht dort weiter, wo jene aufhört.

LM StudioProgramm-Datenblatt→

„Failed to load the model“: zuerst den echten Fehler lesen

Diese Meldung wird im Bugtracker von LM Studio am häufigsten gemeldet, und sie sieht so aus:

Failed to load the model
Error loading model.
(Exit code: 18446744072635812000). Unknown error. Try a different model and/or config.

Die lange Zahl ändert sich von Rechner zu Rechner, suchen Sie Ihre also nicht in einer Liste. Entscheidend ist: Das ist eine allgemeine Meldung, hinter der mehrere Ursachen stecken können – zu wenig Speicher, ein Grafiktreiber oder eine Engine, die für das Modell zu alt ist. Die Abschnitte unten nehmen sich jede davon vor. Version 0.4.21 hat die Fehlermeldungen von llama.cpp beim Laden von Modellen verbessert, unter 0.4.26 ist der Text also meist genauer als in älteren Berichten. Arbeiten Sie mit einer älteren Version, ist das Update schon Schritt eins.

Bevor Sie irgendeine Einstellung ändern, schauen Sie, was der Server sagt. Im Terminal streamt dieser Befehl die Server-Logs von LM Studio:

lms log stream --source server

Lassen Sie ihn in einem zweiten Fenster laufen, während Sie es erneut versuchen. Findet das System lms nicht, springen Sie zuerst zum letzten Abschnitt.

„Insufficient system resources“: die Speicher-Leitplanke

LM Studio schätzt vor dem Laden, wie viel Speicher ein Modell braucht, und liegt die Zahl über seiner Sicherheitsgrenze, hört es auf. Mit Absicht:

Error: Model loading was stopped due to insufficient system resources. Under the current settings, this model requires approximately 22.92 GB of memory, and continuing to load it would likely overload your system and cause it to freeze. If you think this is incorrect, you can adjust the model loading guardrails in settings.

Lästig, ja, aber das ist die höfliche Variante eines eingefrorenen Rechners. Die Zahl in der Meldung (hier 22,92 GB) ist die Schätzung für das Modell plus den Kontext, den Sie verlangt haben, „under the current settings“, also mit den aktuellen Einstellungen. Damit haben Sie drei Auswege: weniger Kontext verlangen, eine stärker komprimierte Fassung oder ein kleineres Modell nehmen, oder in den Einstellungen die Leitplanken für das Laden von Modellen (die „model loading guardrails“) anpassen, wie es die Meldung selbst vorschlägt. Den dritten Weg gehen Sie nur, wenn Sie sicher sind, dass der Rechner das verkraftet.

Die Schätzung sehen Sie auch, ohne etwas zu laden:

lms load --estimate-only <model_key>
lms load --estimate-only <model_key> --context-length 8192 --gpu max

Der Befehl gibt Estimated GPU Memory und Estimated Total Memory aus und endet mit einem von 2 Urteilen: This model may be loaded based on your resource guardrails settings. oder This model will fail to load based on your resource guardrails settings. Steht zusätzlich Confidence: LOW da, nehmen Sie die Zahl als grobe Richtschnur. Die Optionen --context-length und --gpu fließen in die Schätzung ein, Sie können also Größen durchprobieren, bis das Urteil auf Grün springt. Der Modellfinder liefert Ihnen unsere eigene Schätzung, noch bevor Sie das Modell herunterladen.

„Context size has been exceeded“, und wie viel in 16 GB passt

Auch ein Modell, das problemlos geladen wurde, kann mitten im Gespräch damit aussteigen:

Context size has been exceeded.

Der Kontext (wie viel Text das Modell im Blick behält) wird beim Laden des Modells festgelegt. Wächst das Gespräch darüber hinaus und ist der Kontextüberlauf auf Anhalten an der Grenze eingestellt, hält LM Studio an; die beiden anderen Optionen schneiden stattdessen die Mitte des Gesprächs heraus oder verwerfen die ältesten Nachrichten. Die eigene Dokumentation warnt, dass sich das Modell jenseits der Grenze unberechenbar verhält. Die Lösung: das Modell mit mehr Kontext laden.

lms load <model_key> --context-length 16384

In der App können Sie die Ladeeinstellungen beim Laden eines Modells ändern und als Standard für dieses Modell speichern, oder diese Standards im Tab My Models über das Zahnrad festlegen. Zwei Einstellungen sparen hier Speicher: Flash Attention, das den Speicherverbrauch senkt, und die Quantisierung des K- und des V-Caches (die für den V-Cache setzt eingeschaltetes Flash Attention voraus). Noch ein Grund, auf dem neuesten Stand zu bleiben: Version 0.4.24 hat behoben, dass die Liste der geladenen Modelle eine falsche Kontextlänge anzeigte.

Nur: Mehr Kontext gibt es nicht umsonst. Er wird beim Laden in Speicher bezahlt, und ein großer Sprung führt Sie direkt zurück zur Leitplanke. Wie viel ist „mehr“? Wir haben es mit unserem eigenen Rechner für einen Mac mit 16 GB Unified Memory durchgerechnet, der davon dem Modell 13,0 GiB lässt, bei Q4_K_M-Kompression und mit dem Cache in voller Genauigkeit (f16):

Mac mit M4 und 16 GB Unified MemoryHardware-Datenblatt→

Modell	4k	32k	64k	Größter Kontext, der passt
Qwen3 8B	5,92 GiB	10,38 GiB	15,48 GiB ✗	49.152 Tokens
Gemma 4 12B	7,68 GiB	8,65 GiB	9,75 GiB	161.792 Tokens
gpt-oss-20b	11,60 GiB	12,78 GiB	14,13 GiB ✗	37.888 Tokens

Gesamter Speicherbedarf (Modelldatei + KV-Cache + Eigenbedarf des Programms) und der größte Kontext, der in die verfügbaren 13,0 GiB passt, gesucht in Schritten von 1.024 Tokens. Berechnet von Local AI Scope am 6. Oktober 2026 (die Zeile Gemma 4 12B am 15. Oktober 2026): Dateigrößen gemessen, KV-Cache aus der Architektur des jeweiligen Modells berechnet, Eigenbedarf geschätzt. ✗ = passt nicht. Das ist unsere Schätzung; lms load --estimate-only liefert die von LM Studio.

Auf einer Grafikkarte mit 8 GB VRAM (7,2 GiB frei für das Modell) wird es deutlich enger: Qwen3 8B passt bis 12.288 Tokens, Gemma 4 12B und gpt-oss-20b passen nicht einmal bei 4k und landen am Ende aufgeteilt mit dem Prozessor. Womit wir beim nächsten Problem wären.

Langsame Antworten: Das Modell läuft auf der CPU, oder die GPU fehlt

Tröpfeln die Antworten Wort für Wort heraus, während die Lüfter Anlauf für den Abflug nehmen, läuft das Modell vermutlich ganz oder teilweise auf dem Prozessor. Entweder passte es nicht in den Grafikspeicher, oder die Engine hat die Karte gar nicht gesehen.

Verlangen Sie zuerst beim Laden das ganze Modell auf der GPU:

lms load <model_key> --gpu max   # alle Schichten auf die GPU
lms load <model_key> --gpu 0.5   # die Hälfte davon
lms load <model_key> --gpu off   # keine, nur CPU

Ob es passt, sehen Sie vorher mit lms load --estimate-only <model_key> --gpu max: Der Befehl gibt den GPU-Speicher aus, den dieses Laden bräuchte. Um den GPU-Anteil für ein Modell ein für alle Mal festzulegen, nehmen Sie das Zahnrad in My Models. Prüfen Sie dann, was jede Engine sieht:

lms runtime survey

Der Befehl erfasst die Hardware, die den ausgewählten Engines zur Verfügung steht. Fehlt Ihre Karte in der Liste, probieren Sie eine andere Engine: LM Studio liefert getrennte llama.cpp-Engines für verschiedene Arten von Grafikkarten (etwa CUDA, Vulkan oder ROCm, je nach System), und Sie wechseln mit lms runtime select oder im Runtimes-Fenster zwischen ihnen (⌘ Shift R auf dem Mac, Ctrl Shift R unter Windows und Linux). Mit einer AMD-Karte konnte ein Treiber-Update dazu führen, dass LM Studio 0 GPUs anzeigte. Version 0.4.17 hat behoben, dass AMD-GPUs nach Treiber-Updates nicht erkannt wurden und dass eine Hardware-Erfassung mit einer alten ROCm-Engine ohne GPUs hängen blieb. Taucht Ihre AMD-Karte unter 0.4.26 immer noch nicht auf, aktualisieren Sie die Engines mit lms runtime update und starten die Erfassung erneut, oder wählen Sie die Vulkan-Engine.

Zur Orientierung: LM Studio empfiehlt unter Windows mindestens 4 GB dedizierten Grafikspeicher und 16 GB RAM, auf dem Mac 16 GB; auf einem Mac mit 8 GB rät es zu kleineren Modellen und bescheidenen Kontextgrößen.

„No LM Runtime found“, oder ein brandneues Modell, das nicht lädt

LM Studio führt Modelle nicht selbst aus: Es reicht sie an eine Engine weiter, llama.cpp für GGUF-Dateien auf Mac, Windows und Linux, und MLX auf Macs mit Apple Silicon. Die Engines werden getrennt von der App heruntergeladen und aktualisiert. Das erklärt zwei häufige Meldungen. Die erste heißt, dass es für dieses Dateiformat keine Engine gibt:

No LM Runtime found for model format 'gguf'!

Die zweite taucht auf, wenn ein Modell neuer ist als Ihre Engine. Ein GGUF-Modell lädt dann einfach nicht, ein MLX-Modell sagt womöglich so etwas wie:

Error when loading model: ValueError: Model type gemma4 not supported.

Die Engine kennt diese Architektur schlicht noch nicht. Engines haben eigene Versionsanforderungen: LM Studio 0.4.22 etwa vermerkt, dass seine neuen Assistant-Drafter die llama.cpp-Engine in Version 2.29.1 oder neuer brauchen. Die Lösung ist in beiden Fällen, die Engine zu installieren oder zu aktualisieren, im Runtimes-Fenster (⌘/Ctrl Shift R) oder im Terminal:

lms runtime ls       # installierte Engines
lms runtime update   # die installierten aktualisieren
lms runtime get      # eine herunterladen
lms runtime select   # die aktive auswählen

Zwei Voraussetzungen, die Sie bei der Gelegenheit prüfen sollten: MLX gibt es nur auf Macs mit Apple Silicon, ein MLX-Modell lädt also unter Windows oder Linux nicht; und auf einem Windows-PC mit x64 verlangt LM Studio einen Prozessor mit dem Befehlssatz AVX2.

Der Server startet nicht auf Port 1234, oder andere Geräte erreichen ihn nicht

lms server start startet den Server und prüft dann 5-mal, ob er antwortet. Tut er das nie, bekommen Sie:

Failed to verify the server is running. Please try to use another port.

Die Meldung selbst zeigt auf den Port: Vielleicht belegt ihn schon etwas anderes. Standard ist 1234, aber ohne --port nimmt LM Studio den zuletzt benutzten Port. Deshalb beweist „gestern ging’s doch noch“ hier gar nichts. Prüfen Sie den Status und versuchen Sie einen anderen Port:

lms server status
lms server start --port 1235

lms server status antwortet mit The server is running on port 1234. oder The server is not running. Unter Linux zeigt sudo ss -ltnp | grep 1234, welcher Prozess den Port belegt.

Auf Ihrem Rechner läuft alles, aber vom Laptop daneben aus nicht? Das ist so gewollt: Der Server lauscht auf 127.0.0.1, also kann nur Ihr eigener Rechner mit ihm sprechen. Um ihn für Ihr Netzwerk zu öffnen, schalten Sie in der App „Serve on Local Network“ ein, oder:

lms server start --bind 0.0.0.0

Der Befehl warnt Sie, und er meint es ernst: Server will accept connections from the network. Only use this if you know what you are doing! LM Studio empfiehlt, die Authentifizierung einzuschalten, sobald der Server auf etwas anderem als 127.0.0.1 lauscht; wie Sie API-Tokens anlegen, zeigt die Einrichtungsanleitung. Richten Sie lms mit --host auf einen anderen Rechner und niemand antwortet, sagt es Ihnen das: The server does not appear to be running at <host>:<port>.

„lms“ nicht gefunden, und das Linux-AppImage, das sich nicht öffnet

lms kommt mit der App, aber es gibt einen Haken: Sie müssen LM Studio mindestens einmal gestartet haben, bevor Sie es benutzen können. Kennt Ihr Terminal den Befehl danach immer noch nicht, nehmen Sie ihn in den Pfad auf und öffnen ein neues Terminalfenster:

# macOS oder Linux
~/.lmstudio/bin/lms bootstrap

# Windows, in der PowerShell
cmd /c %USERPROFILE%/.lmstudio/bin/lms.exe bootstrap

Läuft lms, meldet aber Failed to start or connect to local LM Studio API server., konnte es LM Studio nicht wecken: Öffnen Sie die App, oder starten Sie den Hintergrunddienst mit lms daemon up, wenn Sie LM Studio ohne sein Fenster nutzen.

Unter Linux gilt: Öffnet sich das AppImage überhaupt nicht, prüfen Sie vor allem anderen Ihre Version. Version 0.4.22 hat den Start des AppImage auf Systemen ohne FUSE 2 und auf Systemen ohne verfügbare Chromium-Sandbox repariert, das Aufwecken von AppImage-Installationen durch lms behoben und die Updates in der App für AppImage- und .deb-Installationen eingeschaltet. LM Studio verlangt Ubuntu 20.04 oder neuer und sagt, dass Versionen nach 22 nicht gut getestet sind.

Meldungen, Befehle und Standardwerte aus der Dokumentation und dem Changelog von LM Studio, dem Quellcode seiner Kommandozeile lms und den Meldungen in seinem Bugtracker, gelesen am 6. Oktober 2026 für Version 0.4.25 und am 9. Oktober 2026 mit dem Changelog zu 0.4.26 und dem Code von lms erneut abgeglichen.

Nutzen Sie auch Ollama? Dort sind die Fehler andere, und die Lösungen auch: Ollama funktioniert nicht? 9 Fehler, die genaue Meldung und die Lösung. Und was LM Studio verschickt, während all das läuft, steht in seinem Steckbrief: LM Studio: was es nach Hause sendet und ob es prüfbar ist.