Comment vérifier si un LLM local utilise les bons fichiers de modèle et le bon chemin de stockage

Un LLM local peut répondre à une requête tout en utilisant un mauvais chemin de modèle. L'interface de l'application peut afficher le nom du modèle attendu, mais le runtime peut lire un cache ancien, un répertoire interne à Docker, un dossier de modèle par défaut ou un fichier qui a été téléchargé ailleurs.

La vérification la plus sûre n'est pas une seule commande. C'est une courte chaîne de preuves : comparez le dossier hôte, le montage du conteneur, la liste des modèles du runtime, les métadonnées du modèle, l'état actif en mémoire, les journaux et la croissance réelle du stockage. Lorsque ces couches concordent, vous pouvez être beaucoup plus confiant que le LLM utilise les bons fichiers de modèle et le bon chemin de stockage.

Le dossier que vous voyez n'est pas toujours le chemin utilisé par le runtime

La première erreur est de faire trop tôt confiance au chemin du gestionnaire de fichiers. Un dossier NAS peut contenir le modèle que vous avez téléchargé, mais cela ne prouve pas que le runtime LLM local peut le voir ou le charge depuis ce dossier.

Docker ajoute une couche supplémentaire. Un chemin hôte tel que /mnt/storage/ai/models peut être mappé à un chemin de conteneur tel que /root/.ollama, et le moteur de modèle ne voit que le chemin du conteneur. La documentation des montages bind de Docker explique que source est le chemin côté hôte et destination ou target est le chemin à l'intérieur du conteneur, donc les deux doivent être vérifiés ensemble via les montages bind Docker.

La question pratique du chemin est simple : ne demandez pas seulement où vous avez mis le modèle. Demandez quel chemin le runtime voit, et à quel dossier hôte ce chemin de conteneur correspond réellement.

Commencez par la liste des modèles du runtime

Avant de vérifier chaque dossier, demandez à la liste des modèles du runtime ce qu'elle connaît. Pour Ollama, commencez par :

ollama list

À l'intérieur d'un conteneur Docker, utilisez la même vérification d'exécution depuis l'intérieur de la limite du service :

docker exec -it ollama ollama list

Ce registre d'exécution confirme que le runtime a enregistré une étiquette de modèle, mais cela ne prouve pas entièrement que le chemin du fichier, la quantification ou l'emplacement de stockage sont corrects. La référence CLI d'Ollama liste ollama ps pour exécuter des modèles, tandis que la FAQ explique le répertoire de stockage des modèles et la variable d'environnement OLLAMA_MODELS dans ses instructions sur le répertoire de stockage des modèles.

Utilisez cette étape comme premier point de contrôle, pas comme réponse finale. Si le modèle attendu n’apparaît pas ici, l’application peut pointer vers un environnement d’exécution différent, le modèle peut ne pas avoir été importé, ou le répertoire modèle configuré peut ne pas être celui utilisé par le service.

Faites correspondre le chemin hôte au chemin conteneur

Pour les déploiements Docker, la question la plus importante est de savoir si le chemin hôte et le chemin conteneur correspondent réellement. Exécutez :

docker inspect <nom-du-conteneur>

Puis regardez la section Montages. La Source doit pointer vers le dossier de stockage NAS que vous aviez prévu d’utiliser, et la Destination doit pointer vers le répertoire du modèle utilisé à l’intérieur du conteneur. La commande inspect de Docker renvoie des informations d’objet bas niveau, ce qui fait de docker inspect Mounts une source de vérité plus fiable que la mémoire ou les captures d’écran.

Un bon montage Docker doit rendre la relation de stockage évidente :

Si le chemin source pointe vers la racine Docker, un chemin temporaire, un ancien dossier ou un petit volume système, le modèle peut encore fonctionner tout en remplissant le mauvais disque.

Vérifiez les fichiers modèles réels, pas seulement le nom du modèle

Un nom de modèle n’est pas la même chose qu’un fichier modèle vérifié. Le même nom peut pointer vers différentes étiquettes, formats, niveaux de quantification, adaptateurs ou blobs mis en cache selon l’environnement d’exécution.

Pour Ollama, inspectez les métadonnées du modèle avec :

ollama show <nom-du-modèle> --modelfile

À l’intérieur de Docker, exécutez la même vérification Modelfile via le conteneur :

docker exec -it ollama ollama show <nom-du-modèle> --modelfile

Les métadonnées du fichier Modelfile Ollama sont importantes ici. La documentation Modelfile d’Ollama explique que ollama show --modelfile peut révéler la configuration du modèle, y compris la source FROM derrière le modèle. Pour les fichiers .gguf téléchargés manuellement, la documentation de quantification de llama.cpp montre GGUF et des formats tels que Q4_K_M, donc les métadonnées du fichier modèle GGUF font partie de la vérification, pas seulement de l’optimisation des performances.

Les journaux vous indiquent quel chemin a réellement été chargé

Lorsque l'interface utilisateur et les chemins de fichiers ne concordent pas, les journaux sont souvent la preuve la plus claire. Ils peuvent montrer les chemins de démarrage, les lectures échouées, les erreurs de permission, les fichiers manquants, les téléchargements de modèles et le comportement de repli.

Pour Docker, utilisez cette vérification des journaux du conteneur :

docker logs <nom-du-conteneur>

La documentation sur la journalisation Docker explique que les journaux du conteneur exposent généralement la sortie du processus du conteneur depuis STDOUT et STDERR, tandis que la page de dépannage d'Ollama note que les journaux d'Ollama conteneurisé peuvent être consultés avec docker logs.

Cherchez des indices de chemin tels que OLLAMA_MODELS, des messages de téléchargement de modèle, des erreurs de chargement échoué, des erreurs de permission ou des répertoires qui ne correspondent pas à votre dossier de stockage prévu. Si les journaux mentionnent un répertoire différent de celui que vous avez mappé, faites confiance aux journaux et corrigez le chemin.

Confirmer que le modèle est actif en mémoire

La vérification suivante est l’état du modèle actif. Un modèle peut être installé ou enregistré mais pas actuellement chargé. Après avoir envoyé une invite courte, exécutez immédiatement :

ollama ps

À l'intérieur de Docker, exécutez la même vérification du modèle actif dans le conteneur :

docker exec -it ollama ollama ps

Quoi ollama ps Peut prouver

ollama ps montre quels modèles sont actuellement chargés. La FAQ d'Ollama explique que la colonne Processor peut indiquer si un modèle est chargé sur CPU, GPU, ou réparti entre CPU et GPU, ce qui aide à confirmer l'état d'exécution actif plutôt que simplement la bibliothèque de modèles.

Ceci est utile lorsque vous devez savoir si le modèle attendu est actif maintenant, s'il reste en mémoire et s'il utilise le chemin processeur prévu. C'est particulièrement utile après avoir changé de modèle, modifié des tags ou testé le comportement GPU / CPU.

Ce qu'il ne peut pas prouver

ollama ps ne prouve pas à lui seul le mappage du dossier hôte. Il peut montrer qu'un modèle est actif, mais vous avez toujours besoin de docker inspect, des métadonnées du modèle, des journaux et des vérifications de croissance du stockage pour prouver qu'il provient du chemin prévu.

Cela ne prouve pas non plus qu'un fichier de modèle personnalisé possède la quantification ou la source exacte que vous attendiez. Pour cela, utilisez les vérifications des métadonnées, l'inspection du fichier modèle et la vérification au niveau du fichier.

Signes d'alerte que le chemin du modèle est incorrect

Un chemin de modèle incorrect laisse généralement des symptômes avant de devenir évident. Le signe le plus courant est une croissance inexpliquée du disque sur le lecteur de démarrage, la racine Docker ou un volume de données d'application que vous n'aviez pas l'intention d'utiliser.

Surveillez ces signaux de décalage de chemin :

• L’application affiche le modèle, mais votre dossier de modèle prévu ne s’agrandit pas.
• docker inspect montre un chemin Source différent de votre dossier de stockage NAS.
• Le modèle se télécharge à nouveau alors que vous pensiez qu’il était déjà présent.
• Les journaux mentionnent un répertoire de modèle par défaut au lieu de votre chemin personnalisé.
• ollama list montre une étiquette ou une taille différente de ce que vous attendiez.
• ollama show --modelfile pointe vers une base ou un blob différent de ce qui est attendu.
• ollama ps montre un modèle actif inattendu après une invite.
• Le disque de démarrage perd de l’espace après chaque téléchargement de modèle.

Si deux couches de vérification divergent, simplifiez le test. Arrêtez le conteneur, vérifiez le montage, redémarrez le service, téléchargez un petit modèle connu, et vérifiez quel répertoire s’agrandit.

Un ordre de vérification plus propre pour le stockage local LLM

Utilisez un ordre de vérification fixe au lieu de vérifier des dossiers aléatoires. Cela évite de confondre les chemins hôtes, chemins de conteneur, chemins d’application et chemins runtime.

1. Confirmez le dossier de stockage hôte prévu.
2. Vérifiez l’espace libre sur le disque système et le disque du modèle.
3. Exécutez docker inspect <nom-du-conteneur> et vérifiez Source / Destination.
4. Vérifiez la liste des modèles du runtime avec ollama list.
5. Téléchargez ou importez un petit modèle connu.
6. Exécutez du -sh <dossier-du-modèle> avant et après le téléchargement.
7. Inspectez les métadonnées avec ollama show <nom-du-modèle> --modelfile.
8. Envoyez une invite courte.
9. Exécutez ollama ps pour confirmer le modèle actif.
10. Lisez les journaux du conteneur ou du service pour des indices sur le chemin, le téléchargement ou les permissions.

Une vérification de stockage propre doit se terminer avec toutes les couches pointant vers le même endroit : le dossier du modèle s’agrandit sur le disque attendu, le point de montage du conteneur pointe vers ce dossier, le runtime liste le modèle, les métadonnées correspondent au fichier attendu, les journaux ne montrent aucune erreur de chemin, et le modèle actif est celui que vous venez de tester.

Ce que la recherche AI de ZimaOS montre sur les chemins de modèles visibles

Une fonctionnalité AI locale contrôlée devrait rendre son chemin du modèle, l’état du téléchargement, l’utilisation des ressources et les journaux suffisamment visibles pour vérification. Sinon, les utilisateurs restent dans l’incertitude quant à savoir si le service AI utilise réellement les fichiers modèles attendus.

ZimaOS-AI est un exemple utile. Le guide ZimaSpace pour la recherche AI explique que le module AI utilise un LLM local pour extraire des caractéristiques des images, audio et vidéo pour la recherche ZimaOS. La même note indique que les fichiers modèles sont stockés dans /media/ZimaOS-HD/AppData/.models, et si AppData a été migré, l’utilisation réelle du stockage suit l’emplacement migré d’AppData.

Le guide décrit également des vérifications opérationnelles telles que les téléchargements automatiques de modèles, les intervalles d’extraction de fonctionnalités, l’historique des appels, les contrôles du trafic réseau et journalctl -xef -u zimaos-ai pour le dépannage. Ce sont exactement les types de signaux dont une charge de travail IA locale a besoin : chemin visible, comportement de téléchargement visible, journaux visibles et état d’exécution visible.

Pour une configuration de cloud privé telle que ZimaCube 2, voici la leçon principale : l’IA locale ne doit pas être une boîte noire. Que la charge de travail soit la recherche, le chat, les embeddings ou l’analyse média, le chemin du modèle et l’état d’exécution doivent être faciles à vérifier.

FAQ

Comment savoir où Ollama stocke les fichiers de modèle ?

Vérifiez le répertoire de modèle par défaut d’Ollama pour votre système d’exploitation, puis vérifiez si OLLAMA_MODELS l’a modifié. Sur Docker, inspectez également le montage du conteneur pour savoir quel dossier hôte correspond au répertoire de modèle d’exécution.

Comment vérifier si Docker utilise le bon dossier de modèle ?

Exécutez docker inspect <nom-du-conteneur> et examinez la section Mounts. La Source doit être le chemin de stockage NAS que vous avez prévu, et la Destination doit être le répertoire de modèle utilisé à l’intérieur du conteneur.

Que sont manifests et blobs dans un répertoire de modèle Ollama ?

Dans un répertoire de modèle de style Ollama, les manifests décrivent les métadonnées et références du modèle, tandis que les blobs contiennent les fichiers volumineux du modèle. Si le dossier blobs grossit après avoir téléchargé un modèle, c’est un signe fort que ce répertoire est utilisé pour le stockage des modèles.

Comment savoir quel modèle est actuellement chargé ?

Envoyez une invite courte, puis exécutez ollama ps. Cela affiche le modèle actuellement chargé et l'état du processeur, ce qui aide à confirmer si le modèle attendu est actif sur le CPU, le GPU ou une répartition CPU / GPU.

Pourquoi l'application affiche-t-elle le modèle alors que le chemin du fichier semble toujours incorrect ?

L'application peut lire un registre d'exécution, un modèle mis en cache, un chemin interne Docker ou un répertoire de modèle différent de celui que vous vérifiez dans le gestionnaire de fichiers. Vérifiez la liste d'exécution, le montage Docker, les métadonnées, les journaux et la croissance réelle du stockage avant de faire confiance à l'interface utilisateur.

Une vérification locale du chemin LLM est complète uniquement lorsque le chemin de stockage hôte, la destination du conteneur, la liste des modèles en cours d'exécution, les métadonnées du modèle, l'état de la mémoire active, les journaux et la croissance du disque sont tous cohérents. Si une couche pointe ailleurs, corrigez le chemin avant de télécharger plus de modèles ou de connecter plus d'applications.