Module 2 — Récupérer, lister et supprimer des modèles

L'installation du module 1 nous a laissés avec un service qui répond mais un dossier de modèles vide. Nous devons maintenant peupler ce dossier avec les bons modèles pour le cabinet, sans transformer le disque du secrétariat en cimetière de fichiers GGUF de 40 Go chacun. Ce module apprend à lire la bibliothèque Ollama, à choisir une étiquette qui a du sens, à télécharger, à inspecter, et surtout à faire le ménage.

Lire une étiquette de modèle

Une étiquette Ollama a la forme nom:variante. llama3.1:8b désigne Llama 3.1 dans sa taille 8 milliards de paramètres, quantifié par défaut. mistral:7b-instruct-q4_K_M désigne Mistral 7B en variante instruction, quantifié en Q4_K_M — nous verrons au module 6 ce que signifie précisément cette étiquette de quantification, mais il suffit ici de retenir qu'elle divise la taille en mémoire par un facteur trois à quatre par rapport aux poids d'origine, en échange d'une perte de qualité mesurable mais généralement acceptable pour un usage bureautique.

Sans variante explicite, ollama pull llama3.1 équivaut à llama3.1:latest, qui pointe aujourd'hui sur la 8B quantifiée en Q4_K_M — soit 4,7 Go. La règle du cabinet est de toujours écrire la variante en toutes lettres dans les scripts, parce que latest peut changer de cible d'un mois à l'autre et faire varier silencieusement les réponses données aux clients.

Télécharger : pull

ollama pull llama3.1:8b-instruct-q4_K_M
ollama pull mistral:7b-instruct-q4_K_M
ollama pull nomic-embed-text

pull télécharge le modèle par couches (comme Docker), les met en cache, et se contente de vérifier les sommes de contrôle si le modèle est déjà présent. Il est donc sans risque de le rejouer : une deuxième invocation d'un pull complet ne re-télécharge rien.

Pour le cabinet, nous récupérons trois modèles distincts et complémentaires. Un modèle d'instruction francophone pour les réponses aux clients (llama3.1:8b-instruct-q4_K_M, environ 4,7 Go). Un second modèle d'instruction pour comparer les sorties et détecter les hallucinations (mistral:7b-instruct-q4_K_M, 4,4 Go). Un modèle spécialisé dans les plongements, pas la génération (nomic-embed-text, 274 Mo) : c'est lui qui alimentera le système de questions-réponses local du module 9. Un modèle de plongement ne « discute » pas ; on le lancerait avec ollama run sans obtenir de conversation utile.

Le choix de la langue est le premier critère. qwen2.5:7b répond très bien en français mais brille surtout en chinois ; llama3.1:8b a été plus fortement post-entraîné sur des données multilingues incluant le français ; mistral:7b est un modèle français d'origine. Pour un cabinet francophone, tester les trois sur un petit lot de dix questions clients réelles est un investissement d'une heure qui évite six mois de mauvais choix.

Lister et inspecter : list, show

ollama list

La sortie tient sur quatre colonnes : NAME, ID, SIZE, MODIFIED. Elle permet en un coup d'œil de voir combien d'espace disque est occupé — le cabinet vise moins de 15 Go au total, pour laisser de la place à la sauvegarde chiffrée quotidienne.

Pour connaître les détails d'un modèle avant de s'engager, show révèle son gabarit de consigne, sa consigne système par défaut, ses paramètres et sa licence :

ollama show llama3.1:8b-instruct-q4_K_M
ollama show llama3.1:8b-instruct-q4_K_M --modelfile

La seconde forme sort le Modelfile effectif, que nous utiliserons au module 5 comme base pour créer une version dérivée « cabinet juridique » avec sa propre consigne système.

Libérer l'espace : rm

Sur le poste du secrétariat, nous avons pris le temps de comparer trois modèles avant de choisir. Une fois la décision faite, il faut supprimer les autres :

ollama rm qwen2.5:7b
ollama rm gemma2:9b

rm ne demande aucune confirmation — la suppression est immédiate et irréversible dans le cache Ollama. Le fichier reste évidemment téléchargeable à nouveau depuis la bibliothèque, mais c'est plusieurs gigaoctets qui repartent sur le réseau. Sur un poste partagé, il est prudent d'annoncer un ollama rm avant de le lancer, ou d'attendre la nuit.

Astuce peu documentée : ollama ps liste les modèles actuellement chargés en mémoire (pas simplement présents sur le disque). Sur un poste à 16 Go de RAM qui commence à ramer, c'est le premier réflexe — souvent un modèle est resté en mémoire à cause d'un OLLAMA_KEEP_ALIVE généreux.

Où sont réellement les fichiers ?

Ollama stocke ses modèles sous forme de couches (blobs) et de manifestes dans ~/.ollama/models/blobs/ et ~/.ollama/models/manifests/. Manipuler ces fichiers à la main est déconseillé : le format évolue et Ollama peut décider de « réparer » un cache incohérent en re-téléchargeant tout. Passer par pull, rm et la variable OLLAMA_MODELS du module 1 est la seule voie sûre.

L'espace disque disparaît vite

Un llama3.1:70b en Q4 pèse 40 Go. Trois variantes de test et le disque du poste secrétariat déborde — d'où l'importance de ollama list régulier et d'une décision explicite sur les modèles à conserver. Pour le cabinet, la règle interne est : deux modèles d'instruction maximum, un modèle de plongement, tout le reste part.

En résumé

• Une étiquette Ollama s'écrit nom:variante ; toujours nommer la variante explicitement, jamais latest en production.
• pull télécharge par couches et est rejouable sans coût ; le cabinet garde deux modèles d'instruction et un modèle de plongement.
• list donne l'espace disque, show révèle le Modelfile effectif, ps liste ce qui est chargé en mémoire.
• rm supprime sans confirmation ; sur un poste partagé, coordonner avant de libérer plusieurs gigaoctets.

Module suivant : ouvrir une session interactive avec un modèle et régler ses paramètres de génération.