llama.cpp ne fonctionne pas ? 8 erreurs, le message exact et la solution

Quand llama.cpp échoue, le journal désigne presque toujours le coupable : un port occupé (8080 ou 9931, selon la compilation), une version sans prise en charge du GPU, un modèle plus récent que votre version, un fichier qui n’est pas un GGUF, une mémoire qui s’épuise, un contexte trop grand, un modèle de conversation illisible ou une ancienne option CMake. Voici les 8, avec la solution.

llama.cpp est le moteur caché sous de nombreux programmes d’IA locale, et l’utiliser directement, c’est un peu soulever le capot : contrôle total, chaque option entre vos mains. Le revers de la médaille : quand quelque chose coince, personne ne vous traduit le message. Nous avons vérifié chaque message de cette page les 15 et 16 octobre 2026 dans le code de llama.cpp v0.7.0, la version stable du 15 octobre (compilation b11669), et dans celui de la compilation quotidienne b11658. Nous n’avons pas provoqué ces erreurs sur une machine aujourd’hui : elles viennent directement du code source, ligne par ligne. L’installation et le chargement du premier modèle sont traités dans notre guide d’installation de llama.cpp ; cette page reprend là où il s’arrête.

llama.cppFiche logiciel→

« couldn’t bind HTTP server socket » : le port est occupé (et de quel port s’agit-il ?)

Vous lancez le serveur et il s’arrête aussitôt avec :

… start: couldn't bind HTTP server socket, hostname: 127.0.0.1, port: 9931

Quelque chose d’autre écoute déjà sur cette adresse et ce port : une deuxième copie de llama.cpp oubliée dans un autre terminal, un programme qui utilise le même port, ou l’exécution précédente qui n’a pas fini de se fermer. La solution : arrêter l’autre processus, ou choisir un autre port avec --port 8081 (n’importe quel numéro libre fait l’affaire).

Et voici le rebondissement qui piège beaucoup de monde ce mois-ci. Le port par défaut a changé. Jusqu’à la v0.6.0, celle qu’installait Homebrew avant le 16 octobre 2026, le serveur écoute sur le 8080. Depuis la compilation quotidienne b11521 (9 octobre 2026), et dans la version stable v0.7.0 (15 octobre), il écoute par défaut sur le 9931. Si vous avez installé une compilation quotidienne ou la v0.7.0 (y compris avec brew install ou brew upgrade depuis le 16 octobre), le favori de votre navigateur et toute application pointant vers http://127.0.0.1:8080 frappent désormais à une porte vide, et rien dans l’erreur ne vous le dit. 2 façons d’en sortir : le lancer avec --port 8080 pour garder l’ancienne adresse, ou mettre vos applications à jour vers le 9931. Une fois le modèle chargé, le journal affiche une ligne du type listening on http://127.0.0.1:9931 : fiez-vous à cette ligne, pas à votre mémoire.

Sous Linux, ss -ltnp | grep 9931 (ou 8080) montre qui occupe le port ; sous macOS, lsof -i :9931 ; sous Windows, netstat -ano | findstr 9931.

« warning: no usable GPU found, --gpu-layers option will be ignored »

Vous avez demandé des couches sur la carte avec -ngl et llama.cpp répond :

warning: no usable GPU found, --gpu-layers option will be ignored
warning: one possible reason is that llama.cpp was compiled without GPU support
warning: consult docs/build.md for compilation instructions

Le message est honnête : la plupart du temps, vous utilisez une version pour processeur uniquement. llama.cpp publie un paquet différent par accélérateur : CPU, CUDA, Vulkan, ROCm, SYCL, OpenVINO sous Windows et Linux, et Metal sur les Mac Apple silicon. Si vous avez téléchargé le zip « cpu », la carte est invisible, par conception. Téléchargez le paquet qui correspond à votre carte (chez NVIDIA, celui de CUDA, accompagné du paquet cudart correspondant), ou recompilez avec la bonne option (voir la section CMake plus bas).

Quand la carte est détectée, le journal le dit très tôt, avec une ligne du type ggml_cuda_init: found 1 CUDA devices (Total VRAM: …). Pas de ligne de ce genre, et pas d’avertissement non plus ? Alors vous n’avez pas passé -ngl (sa valeur par défaut est auto) : l’avertissement n’a jamais eu l’occasion d’apparaître, et vous utilisez très probablement une version pour processeur uniquement. Lancez-le une fois avec -ngl all : si la compilation ne prend pas en charge le GPU, l’avertissement ci-dessus vous le dira.

2 cas où le bon paquet ne suffit toujours pas. Sur un Mac Intel, le binaire officiel est compilé sans Metal : il ne tourne donc que sur le processeur. Et sur une carte AMD, le paquet CUDA ne tourne que sur le processeur : il vous faut le paquet ROCm ou Vulkan.

« unknown model architecture » : le modèle est plus récent que votre version

Le modèle se télécharge, puis le chargement s’arrête avec :

llama_model_load: error loading model: unknown model architecture: 'xxxx'

suivi de failed to load model. Le fichier GGUF indique à quelle famille appartient le modèle, et votre version ne connaît pas encore cette famille. Ce n’est pas un fichier abîmé : c’est une question de calendrier. llama.cpp ajoute la prise en charge de nouvelles familles presque chaque semaine, et un modèle sorti mardi dernier exige une version postérieure à mardi dernier.

La solution, c’est de mettre à jour. Avec environ 16 compilations publiées par jour en moyenne (481 sur les 30 jours jusqu’au 23 octobre 2026), « la dernière » est une cible mouvante, et ici c’est une bonne nouvelle : la version qui connaît votre modèle existe probablement déjà. Avec Homebrew, vous recevez le canal stable, qui peut avoir quelques semaines de retard sur les compilations quotidiennes ; si le modèle est tout récent, prenez une compilation quotidienne sur la page des versions ou via l’installateur. Si même la plus récente ne connaît pas le nom, le modèle n’est pas encore pris en charge : en attendant, choisissez une autre quantification d’une famille prise en charge.

« invalid magic characters … expected ‘GGUF’ » ou « failed to load model »

Celui-ci est bref :

gguf_init_from_reader: invalid magic characters: 'xxxx', expected 'GGUF'

Tout fichier GGUF commence par les 4 lettres GGUF. Si elles n’y sont pas, llama.cpp n’est pas en train de lire un GGUF. Les suspects habituels : vous l’avez dirigé vers un fichier .safetensors ou un dossier Hugging Face entier (llama.cpp ne charge que du GGUF), vous avez enregistré la page de téléchargement au lieu du fichier, ou le téléchargement s’est arrêté en route. Si vous obtenez plutôt failed to read magic, le fichier est vide ou introuvable.

Les messages génériques failed to load model from … et failed to load model '…' arrivent toujours avec une ligne plus précise juste au-dessus : c’est elle qu’il faut lire. Un chemin avec une faute de frappe est une cause fréquente.

Le moyen le plus simple d’éviter tout cela, c’est de laisser llama.cpp chercher le modèle lui-même : -hf user/model:Q4_K_M télécharge le GGUF depuis Hugging Face dans le cache partagé, avec le bon fichier, à chaque fois.

qwen3-8bFiche modèle→

« cudaMalloc failed: out of memory » ou « failed to allocate buffer for kv cache »

Sur une carte NVIDIA, le manque de mémoire ressemble à ceci :

ggml_backend_cuda_buffer_type_alloc_buffer: allocating … MiB on device 0: cudaMalloc failed: out of memory

et parfois, juste après le chargement du modèle :

failed to allocate buffer for kv cache

Sur un Mac, le même mur s’écrit failed to allocate Metal buffer of … bytes (out of memory). Le premier chiffre indique combien il a tenté de réserver ; la cause est l’une de ces 3. Les poids du modèle ne tiennent pas sur la carte (un 14B sur 8 Go, par exemple). Le cache du contexte ne tient pas (nous y revenons plus bas). Ou quelque chose d’autre occupe la carte : un jeu, un navigateur avec l’accélération matérielle, une autre copie de llama.cpp, Ollama en arrière-plan.

Les solutions, de la plus simple à la plus lourde : fermer les autres programmes ; réduire le contexte avec -c 8192 ; garder moins de couches sur la carte avec un -ngl plus petit (le reste part en RAM, plus lent mais fonctionnel) ; stocker le cache en 8 bits avec -ctk q8_0 -ctv q8_0 ; ou passer à une quantification plus petite du même modèle. Le trouveur de modèle vous dit à l’avance quel modèle et quelle quantification tiennent sur votre carte avec le contexte voulu.

« failed to fit params to free device memory » : le contexte par défaut est le maximum du modèle

C’est le problème qui n’a pas l’air d’en être un. llama.cpp démarre, répond, et pourtant quelque chose cloche : c’est plus lent que prévu, ou un long document revient avec request (… tokens) exceeds the available context size (… tokens), try increasing it. La cause, c’est le contexte par défaut. D’origine, llama.cpp charge le contexte complet avec lequel le modèle a été entraîné (-c 0 veut dire exactement cela), puis un mécanisme appelé --fit, activé par défaut, ajuste les choses à la mémoire libre : d’abord il réduit le contexte, jusqu’à un plancher de 4 096 tokens, puis il déplace des couches de la carte vers la RAM, en laissant toujours 1 024 Mio libres par périphérique. Chaque étape est journalisée au niveau trace : avec le journal par défaut, vous ne voyez pas pourquoi, seulement le résultat, dans une ligne du type n_ctx_seq (32768) < n_ctx_train (40960) -- the full capacity of the model will not be utilized. Si l’ajustement lui-même échoue, vous obtenez un avertissement :

failed to fit params to free device memory: …

Le remède : décider vous-même du contexte au lieu de laisser --fit décider à votre place. Choisissez le contexte dont votre tâche a besoin (8 192 tokens suffisent largement pour discuter ; les longs documents en demandent plus), écrivez-le avec -c et, si vous en voulez davantage sur la même carte, ajoutez -ctk q8_0 -ctv q8_0, qui divise le cache presque par 2. Notre guide d’installation de llama.cpp et la page de la RTX 3060 utilisent le même calculateur.

PC avec RTX 3060 12 GoFiche matériel→

« chat template parsing error » : le modèle de conversation ne se laisse pas lire

Le modèle se charge, mais le serveur s’arrête avant de commencer à écouter, et le journal indique :

… init: chat template parsing error: …
please consider disabling jinja via --no-jinja, or use a custom chat template via --chat-template
for example: --no-jinja --chat-template chatml

Juste après vient exiting due to model loading error. Chaque modèle apporte sa propre recette pour transformer une conversation en texte, et llama.cpp la lit avec son moteur Jinja, désormais activé par défaut (l’ancienne option --jinja n’est plus nécessaire). Certains fichiers GGUF embarquent des modèles de conversation avec des constructions qu’il ne sait pas encore lire. Le message vous donne les 2 sorties : --no-jinja revient aux modèles intégrés, et --chat-template chatml (ou un autre nom intégré) en impose un. Si le même modèle fonctionne dans une version plus récente, mettez plutôt à jour : la prise en charge des modèles de conversation progresse presque aussi vite que celle des modèles eux-mêmes.

Des réponses qui ressemblent à du charabia, qui répètent les noms des rôles ou qui ne s’arrêtent jamais relèvent du même problème, simplement sans erreur : essayez d’abord un GGUF du dépôt officiel du modèle.

Pour voir ce que le modèle reçoit vraiment, le serveur peut vous le montrer lui-même. Dans cette vidéo, un développeur ouvre l’interface web intégrée du serveur, active le journal détaillé et lit le prompt exact que reçoit le modèle, une fois le modèle de conversation appliqué :

CMake : « LLAMA_CUBLAS is deprecated, use GGML_CUDA instead »

Si vous compilez llama.cpp vous-même avec une vieille recette, CMake s’arrête dès la première étape :

LLAMA_CUBLAS is deprecated, use GGML_CUDA instead

Celle-ci est une erreur bloquante : la compilation ne va pas plus loin. Les options GPU sont passées du préfixe LLAMA_ à GGML_ il y a longtemps, et les anciennes commandes de compilation utilisent encore les anciens noms. La commande moderne pour NVIDIA est cmake -B build -DGGML_CUDA=ON, puis cmake --build build --config Release. Les autres anciens noms (LLAMA_CUDA, LLAMA_METAL, LLAMA_NATIVE, LLAMA_SYCL…) fonctionnent encore pour l’instant, avec un avertissement du type LLAMA_CUDA is deprecated, use GGML_CUDA instead ; changez-les avant qu’ils ne cessent de fonctionner à leur tour.

Tant que vous y êtes : les anciennes versions appelaient aussi les programmes main et server. Ces noms ont disparu. Le paquet actuel contient llama, avec llama serve et llama cli, et fournit toujours llama-server et llama-cli séparément. Si un script échoue avec « command not found », ce n’est généralement que ça.

Et si votre problème n’est pas ici

3 habitudes règlent l’essentiel du reste. Notez le numéro de compilation avant de demander de l’aide à qui que ce soit : beaucoup de réponses en dépendent. Repartez du plus petit modèle que vous avez avec -c 4096 : si cela fonctionne, le problème vient de la mémoire, pas de llama.cpp. Et essayez le même GGUF dans un programme qui le fait tourner avec llama.cpp, comme Ollama ou LM Studio : s’il y fonctionne, comparez les options. Notre comparatif llama.cpp vs Ollama liste les réglages qu’Ollama choisit pour vous, comme le contexte et le nombre de requêtes simultanées. Nos guides quand Ollama ne fonctionne pas et quand vLLM ne fonctionne pas couvrent leurs propres erreurs.

Si vous préférez repartir d’une installation propre, dans cette vidéo un autre développeur fait tourner llama.cpp dans Docker (avec une image pour le CPU et une autre pour les cartes NVIDIA), du premier fichier GGUF jusqu’au serveur et à son interface web. Elle a été enregistrée avec le port 8080 et les options de l’époque : si une commande y diffère de cette page, suivez la page.