Rédigé par Rédaction CyberSDF / 19 September 2026

llama.cpp « failed to load model » : le fichier GGUF n’est pas trouvé

Lancée depuis un autre répertoire que celui du modèle, la commande llama-cli -m modeles/Qwen3-4B-Q4_K_M.gguf s’arrête sur failed to load model. llama.cpp ne cherche aucun modèle de lui-même : le seul chemin lu est la valeur de -m, résolue depuis le répertoire courant du shell. Trois situations produisent ce message, et chacune s’annonce sur une ligne différente.

gguf_init_from_file: failed to open GGUF file 'modeles/Qwen3-4B-Q4_K_M.gguf' (No such file or directory)
llama_model_load: error loading model: llama_model_loader: failed to load model from modeles/Qwen3-4B-Q4_K_M.gguf
llama_model_load_from_file_impl: failed to load model

Ces trois lignes sont celles du dépôt ggml-org/llama.cpp, publication v0.4.1 du 14 septembre 2026. Elles proviennent de ggml/src/gguf.cpp, src/llama-model-loader.cpp et src/llama.cpp, la bibliothèque commune à llama-cli, llama-server et llama-bench.

La cause tient dans la première ligne, les deux suivantes ne font que remonter l’erreur

gguf_init_from_file ouvre le fichier et affiche le chemin reçu suivi du texte de l’erreur système : No such file or directory quand rien n’existe à cet emplacement, Permission denied quand le fichier est là mais illisible. Ce texte vient de strerror() et peut apparaître traduit si la locale du système est française. llama_model_loader lève ensuite une exception portant le même chemin, llama_model_load la reprend en la préfixant par error loading model:, et llama_model_load_from_file_impl enregistre l’échec global.

Une quatrième ligne, écrite par le programme appelant, répète le chemin. Sur la build b3400 de juillet 2024, elle s’écrivait main: error: unable to load model : c’est cette ligne que citent la plupart des rapports de bogue, alors que le diagnostic est plus haut.

Cause 1 : le chemin ne désigne aucun fichier

gguf_init_from_file: failed to open GGUF file 'modeles/Qwen3-4B-Q4_K_M.gguf' (No such file or directory)

Un chemin relatif est résolu depuis le répertoire où la commande est lancée, jamais depuis le dossier du binaire ni depuis l’emplacement réel du fichier .gguf. Un cd de trop suffit à casser une commande qui fonctionnait. Quatre vérifications, dans cet ordre.

1. Relevez le répertoire courant et l’existence du fichier.

   pwd
   ls -l modeles/Qwen3-4B-Q4_K_M.gguf
   

   Ce que vous devez voir : un chemin absolu, puis soit la ligne du fichier avec sa taille et sa date, soit ls: cannot access 'modeles/Qwen3-4B-Q4_K_M.gguf': No such file or directory, traduit si la locale française est active.

2. Cherchez le fichier par sa taille, ce qui élimine les fichiers minuscules.

   find "$HOME" -name '*.gguf' -size +500M 2>/dev/null
   

   Ce que vous devez voir : un ou plusieurs chemins absolus, par exemple /home/nadia/modeles/Qwen3-4B-Q4_K_M.gguf. Aucun résultat signifie que le fichier n’a jamais été téléchargé ou qu’il l’a été dans un autre compte.

3. Relancez avec ce chemin absolu, entre apostrophes s’il contient des espaces.

   llama-cli -m /home/nadia/modeles/Qwen3-4B-Q4_K_M.gguf
   

   Ce que vous devez voir : la ligne d’information llama_model_loader: loaded meta data with … key-value pairs and … tensors from /home/nadia/modeles/Qwen3-4B-Q4_K_M.gguf, puis la génération. Un tilde placé entre guillemets n’est pas développé par le shell : -m "~/modeles/Qwen3-4B-Q4_K_M.gguf" transmet le tilde littéral et retombe sur No such file or directory.

4. Vérifiez qu’aucune variable d’environnement n’impose un ancien chemin.

   echo "$LLAMA_ARG_MODEL"
   

   Ce que vous devez voir : une ligne vide, ou un chemin que vous reconnaissez. llama.cpp lit LLAMA_ARG_MODEL comme valeur de repli quand -m est absent : une variable exportée dans un .bashrc peut donc désigner un modèle supprimé depuis. Sans -m ni variable, llama-cli refuse de démarrer sur error: --model is required.

Un fichier présent mais illisible produit la même première ligne terminée par (Permission denied) : un GGUF téléchargé avec sudo puis déplacé dans un dossier personnel, ou copié sur un disque monté avec des droits restreints, échoue pour le compte courant. Les droits se lisent avec ls -l, et la correction est décrite dans permissions et utilisateurs.

Cause 2 : « invalid magic characters » désigne un fichier qui n’est pas un GGUF

gguf_init_from_reader: invalid magic characters: 'vers', expected 'GGUF'
gguf_init_from_reader: invalid magic characters: 'ggml', expected 'GGUF'
gguf_init_from_reader: invalid magic characters: '
Le lecteur compare les quatre premiers octets du fichier à la chaîne GGUF et affiche ceux qu'il a trouvés. Le cas vers vient d'un dépôt Hugging Face cloné sans git-lfs : à la place des poids, le disque contient un fichier texte de moins de 1024 octets qui commence par version https://git-lfs.github.com/spec/v1, conformément à la spécification Git LFS. Le cas ggml est un ancien modèle au format GGML, celui des fichiers .bin de 2023 dont les quatre premiers octets valent 0x67676d6c (constante GGML_FILE_MAGIC, toujours définie dans ggml/include/ggml.h), un format que llama.cpp ne lit plus. Le cas <!do est une page HTML enregistrée sous l'extension .gguf : erreur 404, page d'authentification ou archive .zip jamais extraite.
Deux contrôles suffisent à trancher.
head -c 4 modele.gguf | od -c
stat -c '%s %n' modele.gguf
sha256sum modele.gguf

Ce que vous devez voir : 0000000   G   G   U   F pour la première commande, une taille en octets cohérente avec la fiche du modèle pour la deuxième, une empreinte comparable à celle publiée par l'auteur pour la troisième. Une taille de quelques kilooctets désigne un pointeur Git LFS, une taille inférieure à 4 octets un téléchargement interrompu. Comparer les empreintes à l'œil est une source d'erreur : un vérificateur de checksum fait la comparaison sans recopie.
Cause 3 : le GGUF est valide mais le binaire ne sait pas le décoder
gguf_init_from_reader: this GGUF file is version 4 but this software only supports up to version 3
gguf_init_from_reader: GGUFv1 is no longer supported, please use a more up-to-date version
llama_model_load: error loading model: unknown model architecture: 'qwen3'

GGUF_VERSION vaut 3 dans ggml/include/gguf.h : la bibliothèque accepte les fichiers en version 2 ou 3, refuse tout ce qui est plus récent, et rejette aussi la version 1 en la déclarant obsolète. Une version lue à zéro donne bad GGUF version: 0, signe d'un fichier vide ou tronqué. Le troisième message signale une architecture absente du binaire, cas typique d'une famille de modèles publiée après sa compilation.
Les paquets des distributions ne protègent pas de ce décalage : le paquet llama.cpp correspond aux builds b5882+dfsg-2 dans Ubuntu 25.10 et b8681+dfsg-1 dans Ubuntu 26.04, alors que les builds nocturnes du dépôt atteignent b11046 le 18 septembre 2026. La correction est du côté du binaire : recompiler depuis le dépôt, où cmake -B build puis cmake --build build --config Release déposent les exécutables dans build/bin, ou passer par un dépôt APT plus récent. Sur une machine big-endian, un fichier écrit sur x86 déclenche un autre contrôle encore : failed to load model: this GGUF file version 805306368 is extremely large, is there a mismatch between the host and model endianness?
Le dossier models/ du dépôt ne contient que des fichiers de vocabulaire
Le répertoire models/ livré avec llama.cpp n'abrite aucun modèle utilisable : uniquement des fichiers de test de tokenizer, ggml-vocab-qwen2.gguf, ggml-vocab-llama-bpe.gguf, ggml-vocab-gemma-4.gguf et une vingtaine d'autres. Aucun binaire n'explore ce dossier, et aucun modèle de plusieurs gigaoctets n'y est distribué. Y déposer un .gguf ne change rien au comportement : seul le chemin passé à -m est ouvert.
Un modèle découpé ne se charge que par son premier morceau
illegal split file idx: 1 (file: modele-00002-of-00002.gguf), model must be loaded with the first split

Les GGUF trop volumineux pour un seul fichier sont publiés en tranches nommées modele-00001-of-00002.gguf, modele-00002-of-00002.gguf. Passer la seconde à -m produit la ligne ci-dessus : le chargeur lit le nombre de tranches dans les métadonnées et exige l'index 0 avant de reconstituer la liste. Donnez-lui modele-00001-of-00002.gguf. Si une tranche voisine manque, l'erreur devient failed to load GGUF split from modele-00003-of-00004.gguf.
« -hf » range le modèle dans le cache Hugging Face, pas dans le dossier courant
L'option -hf, alias --hf-repo, attend un dépôt au format utilisateur/nom suivi d'une quantification facultative dont la valeur par défaut est Q4_K_M : llama-cli -hf ggml-org/Qwen3.5-0.8B-GGUF. Le fichier n'arrive pas à côté du binaire mais dans le cache du hub Hugging Face, sous models--ggml-org--Qwen3.5-0.8B-GGUF/snapshots/. llama.cpp choisit ce dossier dans cet ordre : LLAMA_CACHE, puis HF_HUB_CACHE, puis HUGGINGFACE_HUB_CACHE, puis HF_HOME suivi de /hub, puis XDG_CACHE_HOME suivi de /huggingface/hub, et à défaut $HOME/.cache/huggingface/hub.
Lancé avec sudo, le même programme lit le HOME de root et un cache vide : il retélécharge le modèle, ou échoue si le réseau est coupé. -cl, alias --cache-list, liste les dépôts déjà en cache, et --offline interdit tout accès réseau. Le choix du dépôt et de la quantification se discute dans choisir une IA locale, rattaché à la rubrique IA.
Questions fréquentes sur failed to load model
Pourquoi llama.cpp écrit-il « failed to load model » au lieu de « fichier introuvable » ?
Parce que la dernière ligne est émise par la fonction de chargement du modèle, qui rapporte un échec global, tandis que le détail n'est écrit qu'une fois, plus haut, par la fonction qui ouvre le fichier. La ligne à lire reste failed to open GGUF file '…' (No such file or directory) : elle contient le chemin tel qu'il a été reçu, sans interprétation.
Faut-il déposer le .gguf dans le dossier models/ de llama.cpp ?
Non. Ce dossier ne contient que des fichiers de vocabulaire ggml-vocab-*.gguf, et aucun binaire ne l'explore. Le modèle peut rester n'importe où sur le disque, à condition de fournir son chemin à -m, de préférence absolu pour ne pas dépendre du répertoire courant.
Comment vérifier qu'un GGUF téléchargé est complet ?
Comparer la taille annoncée par l'auteur avec celle du fichier local, contrôler les quatre premiers octets avec head -c 4 modele.gguf | od -c, puis comparer l'empreinte sha256 avec celle publiée. Un pointeur Git LFS tient en moins de 1024 octets et commence par version https://git-lfs.github.com/spec/v1.
llama-server affiche-t-il le même message que llama-cli ?
Les trois lignes de la bibliothèque sont identiques, le serveur chargeant le modèle par le même code. Sa ligne propre diffère, du type failed to load model, '', et il s'arrête sans rendre la main. Depuis le 7 août 2026, llama-cli démarre un serveur interne avant d'afficher son interface : un échec y ressort aussi en the server exited before becoming ready, les binaires récents exposant en plus une commande unique llama avec les sous-commandes cli et serve.
Le même fichier fonctionne sur un poste et échoue sur l'autre, pourquoi ?
Les deux binaires ne datent pas de la même semaine. Une architecture prise en charge par une build nocturne b11046 échoue sur un paquet figé comme llama.cpp 5882+dfsg-2 d'Ubuntu 25.10, avec unknown model architecture. La version embarquée se lit avec llama-cli --version, et une compilation locale remet les deux côtés au même niveau.
cmake -B build
cmake --build build --config Release