LM Studio ne fonctionne pas ? 7 erreurs, le message exact et la solution

Quand LM Studio plante, le message dit en général où chercher. Ce guide passe en revue les pannes les plus signalées dans son propre suivi de bugs, plus celles du serveur et de lms tirées de sa documentation : un modèle qui refuse de se charger, le garde-fou de mémoire, un contexte qui déborde, un modèle coincé sur le processeur, un moteur dépassé, un serveur injoignable et une commande lms introuvable.

Il existe un silence bien particulier : celui d’un modèle qu’on attendait avec impatience et qui répond par une erreur au lieu d’une phrase. Ça arrive à tout le monde. Bonne nouvelle, les erreurs de LM Studio sont plus précises qu’elles n’en ont l’air, et pour chacune, vous trouverez ci-dessous le texte exact qui s’affiche, son origine et la solution, pour la version stable actuelle, la 0.4.26 (publiée le 8 octobre 2026 et toujours la dernière version stable au 9 octobre 2026). Ce guide a été écrit sur la 0.4.25 ; les notes de version de la 0.4.26 ne signalent aucun changement dans ces messages, et ceux de lms sont identiques dans son code au 9 octobre 2026. L’installation, le démarrage du serveur et sa sécurisation sont dans notre guide d’installation de LM Studio ; cette page prend le relais là où il s’arrête.

LM StudioFiche logiciel→

« Failed to load the model » : lisez d’abord la vraie erreur

C’est le message le plus signalé dans le suivi de bugs de LM Studio, et il ressemble à ceci :

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

Le long nombre change d’une machine à l’autre, inutile donc de chercher le vôtre dans une liste. Ce qui compte, c’est qu’il s’agit d’un message générique, derrière lequel se cachent plusieurs causes possibles : mémoire insuffisante, pilote graphique, ou moteur trop ancien pour le modèle. Les parties suivantes les passent en revue une par une. La version 0.4.21 a amélioré les messages d’erreur de chargement des modèles llama.cpp, si bien que sur la 0.4.26, le texte obtenu est en général plus précis que dans les signalements plus anciens. Si vous êtes sur une version antérieure, la mise à jour est déjà la première étape.

Avant de changer le moindre réglage, regardez ce que dit le serveur. Depuis un terminal, cette commande affiche en continu le journal du serveur de LM Studio :

lms log stream --source server

Laissez-la tourner dans une deuxième fenêtre pendant que vous réessayez. Si lms est introuvable, passez d’abord par la dernière partie.

« Insufficient system resources » : le garde-fou de mémoire

LM Studio estime la mémoire dont un modèle a besoin avant de le charger et, si le chiffre dépasse sa limite de sécurité, il s’arrête. Exprès :

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.

Agaçant, oui, mais c’est la version polie d’un ordinateur figé. Le chiffre du message (22,92 Go dans cet exemple) correspond au modèle plus le contexte demandé, « under the current settings », autrement dit avec les réglages actuels. Vous avez donc trois portes de sortie : demander moins de contexte, choisir une version plus compressée ou un modèle plus petit, ou ajuster les garde-fous de chargement dans les réglages (Settings), comme le suggère le message lui-même. Ne prenez la troisième que si vous êtes sûr que la machine tiendra le coup.

Vous pouvez voir l’estimation sans rien charger :

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

La commande affiche Estimated GPU Memory et Estimated Total Memory, puis se termine par l’un de ces 2 verdicts : This model may be loaded based on your resource guardrails settings. ou This model will fail to load based on your resource guardrails settings. Si elle ajoute Confidence: LOW, prenez le chiffre comme un ordre de grandeur. Les options --context-length et --gpu sont prises en compte dans l’estimation, vous pouvez donc essayer plusieurs tailles jusqu’à ce que le verdict passe au vert. Le trouveur de modèle vous donne notre propre estimation avant même de télécharger le modèle.

« Context size has been exceeded », et ce qui tient dans 16 Go

Un modèle qui s’est bien chargé peut quand même s’arrêter en pleine conversation, avec ceci :

Context size has been exceeded.

Le contexte (la quantité de texte que le modèle garde sous les yeux) est fixé au chargement du modèle. Quand la conversation le dépasse et que le débordement du contexte est configuré pour s’arrêter à la limite, LM Studio s’arrête ; les deux autres options coupent le milieu de la conversation ou suppriment les messages les plus anciens. Sa propre documentation prévient qu’au-delà de la limite, le modèle se comporte de façon erratique. Pour y remédier, chargez le modèle avec plus de contexte :

lms load <model_key> --context-length 16384

Dans l’application, vous pouvez modifier les réglages de chargement au moment de charger un modèle et les enregistrer comme réglages par défaut de ce modèle, ou définir ces réglages par défaut dans My Models avec l’icône d’engrenage. Deux réglages font économiser de la mémoire ici : Flash Attention, qui réduit la consommation de mémoire, et la quantification des caches K et V (celle du cache V exige que Flash Attention soit activé). Encore une raison de rester à jour : la version 0.4.24 a corrigé la liste des modèles chargés, qui affichait une longueur de contexte erronée.

Mais le contexte en plus n’est pas gratuit. Il se paie en mémoire au chargement, et un grand saut vous renvoie tout droit vers le garde-fou. Et « plus », c’est combien ? Nous avons fait le calcul avec notre propre outil pour un Mac avec 16 Go de mémoire unifiée, qui en laisse 13,0 Gio au modèle, en compression Q4_K_M et avec le cache en pleine précision (f16) :

Mac avec M4 et 16 Go unifiésFiche matériel→

Modèle	4k	32k	64k	Plus grand contexte qui tient
Qwen3 8B	5,92 Gio	10,38 Gio	15,48 Gio ✗	49 152 tokens
Gemma 4 12B	7,68 Gio	8,65 Gio	9,75 Gio	161 792 tokens
gpt-oss-20b	11,60 Gio	12,78 Gio	14,13 Gio ✗	37 888 tokens

Mémoire totale nécessaire (fichier du modèle + cache KV + consommation propre du logiciel), et plus grand contexte qui reste dans les 13,0 Gio disponibles, cherché par pas de 1 024 tokens. Calcul de Local AI Scope du 6 octobre 2026 (la ligne Gemma 4 12B, du 15 octobre 2026) : tailles de fichier mesurées, cache KV calculé d’après l’architecture de chaque modèle, consommation propre estimée. ✗ = ne tient pas. C’est notre estimation ; lms load --estimate-only donne celle de LM Studio.

Sur une carte graphique avec 8 Go de VRAM (7,2 Gio libres pour le modèle), la place est bien plus réduite : Qwen3 8B tient jusqu’à 12 288 tokens, tandis que Gemma 4 12B et gpt-oss-20b ne tiennent même pas à 4k et finissent donc partagés avec le processeur. Ce qui nous amène au problème suivant.

Réponses lentes : le modèle est sur le processeur, ou le GPU manque à l’appel

Si les réponses sortent au compte-gouttes, un mot à la fois, pendant que les ventilateurs s’emballent, le modèle tourne probablement, en tout ou en partie, sur le processeur. Soit il ne tenait pas dans la mémoire graphique, soit le moteur n’a pas vu la carte du tout.

Commencez par demander le modèle entier sur le GPU au chargement :

lms load <model_key> --gpu max   # toutes les couches sur le GPU
lms load <model_key> --gpu 0.5   # la moitié
lms load <model_key> --gpu off   # aucune, processeur seul

Pour savoir à l’avance s’il tient, lancez lms load --estimate-only <model_key> --gpu max : la commande affiche la mémoire GPU qu’il faudrait pour ce chargement. Pour fixer une fois pour toutes la part de GPU d’un modèle, passez par l’icône d’engrenage dans My Models. Vérifiez ensuite ce que voit chaque moteur :

lms runtime survey

Cette commande recense le matériel accessible aux moteurs sélectionnés. Si votre carte n’apparaît pas dans la liste, essayez un autre moteur : LM Studio fournit des moteurs llama.cpp distincts selon le type de carte graphique (CUDA, Vulkan ou ROCm, par exemple, selon votre système), et vous passez de l’un à l’autre avec lms runtime select ou depuis la fenêtre des runtimes (⌘ Shift R sur Mac, Ctrl Shift R sous Windows et Linux). Avec une carte AMD, une mise à jour du pilote pouvait laisser LM Studio afficher 0 GPU. La version 0.4.17 a corrigé la non-détection des GPU AMD après une mise à jour du pilote, ainsi qu’un recensement du matériel avec un ancien moteur ROCm qui le laissait bloqué sans GPU. Si votre carte AMD n’apparaît toujours pas sur la 0.4.26, mettez à jour les moteurs avec lms runtime update et relancez le recensement, ou sélectionnez le moteur Vulkan.

Pour mémoire, LM Studio recommande au moins 4 Go de mémoire graphique dédiée et 16 Go de RAM sous Windows, et 16 Go sur Mac ; sur un Mac de 8 Go, il conseille de s’en tenir à des modèles plus petits et à des contextes modestes.

« No LM Runtime found », ou un modèle tout neuf qui refuse de se charger

LM Studio ne fait pas tourner les modèles lui-même. Il les confie à un moteur : llama.cpp pour les fichiers GGUF sur Mac, Windows et Linux, et MLX sur les Mac à puce Apple Silicon. Les moteurs se téléchargent et se mettent à jour séparément de l’application, ce qui explique deux messages courants. Le premier signifie qu’il n’existe aucun moteur pour ce format de fichier :

No LM Runtime found for model format 'gguf'!

Le second apparaît quand un modèle est plus récent que votre moteur. Un modèle GGUF refuse simplement de se charger, et un modèle MLX peut afficher quelque chose comme :

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

Le moteur n’a tout bonnement jamais croisé cette architecture. Les moteurs ont d’ailleurs leurs propres exigences de version : LM Studio 0.4.22, par exemple, précise que ses nouveaux « assistant drafters » exigent la version 2.29.1 ou plus récente du moteur llama.cpp. Dans les deux cas, la solution consiste à installer ou à mettre à jour le moteur, depuis la fenêtre des runtimes (⌘/Ctrl Shift R) ou depuis le terminal :

lms runtime ls       # moteurs installés
lms runtime update   # mettre à jour ceux qui sont installés
lms runtime get      # en télécharger un
lms runtime select   # choisir le moteur actif

Deux prérequis à vérifier au passage. MLX n’existe que sur les Mac à puce Apple Silicon, donc un modèle MLX ne se chargera pas sous Windows ou Linux ; et sur un PC Windows x64, LM Studio exige un processeur doté du jeu d’instructions AVX2.

Le serveur ne démarre pas sur le port 1234, ou les autres appareils ne l’atteignent pas

lms server start démarre le serveur, puis vérifie 5 fois qu’il répond. S’il ne répond jamais, vous obtenez :

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

Le message lui-même désigne le port, qu’autre chose occupe peut-être. Par défaut, c’est le 1234, mais si vous ne passez pas --port, LM Studio reprend le dernier port utilisé. Voilà pourquoi, ici, « ça marchait hier » ne prouve rien du tout. Vérifiez l’état du serveur et essayez un autre port :

lms server status
lms server start --port 1235

lms server status répond The server is running on port 1234. ou The server is not running. Sous Linux, sudo ss -ltnp | grep 1234 indique quel processus occupe le port.

Ça marche sur votre machine, mais pas depuis le portable d’à côté ? C’est voulu : le serveur écoute sur 127.0.0.1, si bien que seul votre ordinateur peut lui parler. Pour l’ouvrir à votre réseau, activez « Serve on Local Network » dans l’application, ou bien :

lms server start --bind 0.0.0.0

La commande vous prévient, et elle ne plaisante pas : Server will accept connections from the network. Only use this if you know what you are doing! LM Studio recommande d’activer l’authentification dès que le serveur écoute sur autre chose que 127.0.0.1 ; le guide d’installation explique comment créer des jetons d’API. Si vous pointez lms vers une autre machine avec --host et que rien ne répond, il vous le dit en ces termes : The server does not appear to be running at <host>:<port>.

« lms » introuvable, et l’AppImage Linux qui refuse de s’ouvrir

lms est livré avec l’application, mais il y a un piège : il faut avoir lancé LM Studio au moins une fois avant de pouvoir l’utiliser. Si votre terminal ne connaît toujours pas la commande après cela, ajoutez-la à votre PATH et ouvrez une nouvelle fenêtre de terminal :

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

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

Si lms se lance mais affiche Failed to start or connect to local LM Studio API server., c’est qu’il n’a pas réussi à réveiller LM Studio. Ouvrez l’application, ou démarrez le service d’arrière-plan avec lms daemon up si vous utilisez LM Studio sans sa fenêtre.

Sous Linux, si l’AppImage ne s’ouvre pas du tout, vérifiez votre version avant toute chose. La version 0.4.22 a corrigé le démarrage de l’AppImage sur les systèmes sans FUSE 2 et sur ceux où le bac à sable (sandbox) de Chromium n’est pas disponible, a corrigé le réveil des installations AppImage par lms, et a activé les mises à jour depuis l’application pour les installations AppImage et .deb. LM Studio demande Ubuntu 20.04 ou plus récent, et précise que les versions au-delà de la 22 sont peu testées.

Messages, commandes et valeurs par défaut tirés de la documentation et des notes de version de LM Studio, du code source de sa ligne de commande lms et des messages signalés dans son suivi de bugs, lus le 6 octobre 2026 pour la version 0.4.25, puis revérifiés avec les notes de version de la 0.4.26 et le code de lms le 9 octobre 2026.

Vous utilisez aussi Ollama ? Ses erreurs sont différentes, et ses solutions aussi : Ollama ne fonctionne pas ? 9 erreurs, le message exact et la solution. Et pour savoir ce que LM Studio envoie pendant que tout cela fonctionne, voyez sa fiche, LM Studio : ce qu’il envoie et si vous pouvez l’auditer.