Ollama avancé : modèles quantifiés, Modelfile et fine-tuning local

Vous avez installé Ollama, lancé ollama run, discuté avec un modèle en local — et tout marche. Viennent alors les vraies questions : pourquoi un modèle de 7 milliards de paramètres engloutit-il 14 Go de mémoire ? Comment lui donner la voix de votre projet ? Et peut-on lui faire apprendre votre jargon métier sans louer un GPU dans le cloud ? Cet article reprend là où s’arrête le tutoriel d’installation : quantification, Modelfile et fine-tuning local — chaque commande vérifiée sur la documentation officielle.

Il prolonge le guide pilier Héberger ses LLM soi-même en 2026, où Ollama joue le rôle de point d’entrée. Ici, on transforme ce point d’entrée en véritable poste de travail IA.

La quantification, lue dans ses suffixes

Un modèle « brut » stocke chacun de ses poids en 16 bits (FP16). Un modèle de 7 milliards de paramètres pèse alors environ 14 Go, et il faut autant de mémoire pour le charger. La quantification abaisse cette précision — 8, 5, 4, parfois 2 bits — pour diviser la taille d’autant, au prix d’une perte de qualité que l’on cherche à garder marginale.

Ollama distribue ses modèles au format conteneur GGUF, et les variantes se lisent dans leur tag : un suffixe comme q8_0, q5_K_M ou q4_K_M. La lettre K désigne les k-quants, une stratégie à précision mixte : les couches sensibles (l’attention) conservent un peu plus de bits, les couches moins critiques (les blocs feed-forward) sont compressées plus fort. Le suffixe _M (medium) ou _S (small) règle le curseur entre taille et fidélité.

Voici les ordres de grandeur pour un modèle de 7 milliards de paramètres (les tailles réelles varient selon l’architecture) :

Le choix par défaut conseillé par Ollama est Q4_K_M : le meilleur rapport mémoire/qualité pour la majorité des usages. Montez en Q5_K_M ou Q8_0 si vous avez de la VRAM à revendre et visez la fidélité ; ne descendez en Q3 que si vous êtes vraiment à l’étroit.

Un point que les tableaux passent sous silence : la tolérance à la quantification dépend de la tâche. Pour de la conversation générale ou du résumé, un Q4_K_M est quasi indiscernable du modèle complet. Pour du code ou du raisonnement mathématique — où une seule erreur de token casse la sortie — la perte se ressent plus tôt, et un Q5_K_M ou Q6_K peut valoir son surcoût mémoire. Le bon réflexe : testez sur vos propres cas avant de trancher. Le bon niveau de quantification est celui qui passe vos tests, pas celui d’un benchmark générique.

Tirer un modèle déjà quantifié

Le plus simple : la bibliothèque Ollama propose déjà la plupart des modèles en plusieurs quantifications, sélectionnables par leur tag.

ollama pull qwen2.5:7b
ollama list
ollama show qwen2.5:7b

ollama list affiche les modèles présents et leur taille sur disque ; ollama show détaille l’architecture, la quantification et les paramètres par défaut. Pour voir ce qui occupe réellement la mémoire à un instant donné, et savoir si l’inférence tourne sur GPU ou CPU :

ollama ps

Côté familles, les valeurs sûres en auto-hébergement sont Llama (Meta), Mistral et Mixtral, Qwen (Alibaba), Gemma (Google), Phi (Microsoft) et DeepSeek. Pour le choix de taille en fonction de votre VRAM, le guide pilier détaille les paliers ; en pratique, un 7–8B en Q4_K_M tient confortablement sur une carte de 8 Go.

Pour caler la taille sur votre machine, une règle simple en Q4_K_M : un modèle 3B tient sur un GPU de 4 Go, voire en CPU sur une machine récente ; un 7–8B vise 8 Go de VRAM ; un 13–14B réclame 12 à 16 Go ; au-delà (30B et plus), prévoyez 24 Go ou un découpage multi-GPU — terrain où vLLM devient plus pertinent qu’Ollama. Le conseil pratique : commencez petit. Un 7B bien choisi couvre l’essentiel des besoins de développement, et vous ne montez en gamme que si la qualité l’exige vraiment.

Quantifier vous-même un modèle

Si vous partez d’un modèle en FP16 — le vôtre, ou un poids récupéré ailleurs — Ollama peut le quantifier au moment de la création. On écrit un Modelfile minimal pointant vers la source, puis :

ollama create mon-modele --quantize Q4_K_M -f Modelfile

Le Modelfile correspondant peut tenir en une ligne :

FROM ./qwen2.5-7b-instruct-fp16.gguf

Le FROM accepte un fichier GGUF, un répertoire de poids Safetensors, ou un modèle déjà présent dans Ollama. La valeur passée à --quantize est l’une des cibles supportées (Q4_K_M, Q5_K_M, Q8_0, etc.). En quelques secondes, vous obtenez une version allégée, prête à servir.

Le Modelfile : façonner le comportement

Le Modelfile est à Ollama ce que le Dockerfile est à Docker : une recette reproductible. Au-delà du FROM, il fixe le prompt système, les paramètres d’inférence et le gabarit de conversation.

FROM qwen2.5:7b

SYSTEM """Tu es l'assistant technique de SenTur. Tu réponds en français,
de façon concise, avec des exemples de code commentés quand c'est utile."""

PARAMETER temperature 0.4
PARAMETER num_ctx 8192
PARAMETER num_predict 1024
PARAMETER stop "<|im_end|>"

Les paramètres les plus utiles : temperature (créativité ; 0,2 à 0,5 pour du technique), num_ctx (taille de la fenêtre de contexte en tokens), num_predict (longueur maximale de réponse) et stop (séquences d’arrêt). On matérialise ensuite l’assistant :

ollama create sentur-assistant -f Modelfile
ollama run sentur-assistant

Vous disposez d’un modèle nommé, versionnable et partageable dans l’équipe — sans jamais toucher au modèle de base, qui reste réutilisable pour d’autres recettes.

Fine-tuning local : la chaîne réelle

Point important, souvent mal compris : Ollama n’entraîne pas. Il sert et personnalise des modèles, mais l’apprentissage proprement dit se fait avec des outils dédiés. Le pipeline de fine-tuning local typique tient en trois étapes.

1. Préparer un jeu de données au format instruction/réponse, généralement en JSONL :

{"instruction": "Explique le rôle d'un index dans PostgreSQL", "output": "Un index..."}
{"instruction": "Donne la commande pour lister les conteneurs Docker actifs", "output": "docker ps"}

2. Fine-tuner en LoRA ou QLoRA avec un framework comme Unsloth ou Axolotl. QLoRA permet d’entraîner un modèle 7B sur un seul GPU grand public : on ne met à jour qu’une poignée de matrices d’adaptation à faible rang, pas l’intégralité des poids — d’où une empreinte mémoire réduite et un entraînement abordable.

3. Importer l’adaptateur dans Ollama via la directive ADAPTER du Modelfile :

FROM llama3.1:8b
ADAPTER ./mon-adapter-lora

La directive ADAPTER applique un adaptateur LoRA (Safetensors) au modèle de base désigné par FROM. La documentation officielle supporte les adaptateurs Safetensors pour les architectures Llama (2, 3 et 3.1), Mistral (et Mixtral) et Gemma (1 et 2). Règle d’or : le modèle de base du Modelfile doit être exactement celui sur lequel l’adaptateur a été entraîné — sinon le comportement devient erratique.

Pour beaucoup d’équipes, le fine-tuning n’est même pas nécessaire : un bon prompt système combiné à du RAG (détaillé dans le pilier) couvre la grande majorité des besoins de personnalisation, sans GPU d’entraînement ni risque de surapprentissage. Réservez le fine-tuning à ce qui résiste vraiment au prompt : un ton très particulier, un format de sortie strict, un domaine de niche avec un vocabulaire propre.

Combien d’exemples faut-il ? Pour spécialiser un ton ou un format de sortie, quelques centaines d’exemples soigneusement rédigés suffisent souvent : la qualité prime largement sur la quantité. Un jeu trop petit et trop répétitif mène au surapprentissage — le modèle récite vos exemples au lieu de généraliser. Gardez toujours une poignée de cas de côté, jamais vus à l’entraînement, pour évaluer honnêtement le résultat.

Concurrence et exposition réseau

Par défaut, Ollama n’écoute qu’en local (127.0.0.1) et traite les requêtes d’un même modèle de façon limitée. Pour en faire un petit serveur d’équipe, quelques variables d’environnement comptent :

• OLLAMA_HOST=0.0.0.0 — écouter sur le réseau, et non plus seulement en local. À placer impérativement derrière un reverse-proxy et un pare-feu.
• OLLAMA_NUM_PARALLEL — nombre de requêtes traitées en parallèle par modèle (défaut : 4 ou 1 selon la mémoire disponible).
• OLLAMA_MAX_LOADED_MODELS — modèles chargés simultanément (défaut : 3 × le nombre de GPU, ou 3 en inférence CPU).
• OLLAMA_MAX_QUEUE — requêtes mises en file d’attente avant rejet quand le serveur est saturé (défaut : 512).

Sur Linux, où Ollama tourne en service systemd, on édite l’unité plutôt que d’exporter les variables à la main :

sudo systemctl edit ollama.service

…puis on ajoute sous la section [Service] :

Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_NUM_PARALLEL=4"

…et l’on recharge :

sudo systemctl daemon-reload
sudo systemctl restart ollama

Un piège mémoire à connaître : la RAM (ou la VRAM) consommée croît avec le produit OLLAMA_NUM_PARALLEL × taille de contexte. Doubler le nombre de requêtes parallèles ou la fenêtre num_ctx double d’autant le contexte à garder en mémoire. Sur une machine modeste, un OLLAMA_NUM_PARALLEL=2 stable vaut mieux qu’un réglage ambitieux qui force un déchargement vers le CPU et effondre le débit.

Côté intégration applicative, Ollama expose une API compatible OpenAI : vos clients existants fonctionnent en changeant uniquement l’URL de base.

curl http://localhost:11434/v1/chat/completions -d '{
  "model": "sentur-assistant",
  "messages": [{"role": "user", "content": "Résume ce log d'erreur"}]
}'

En Python, le SDK OpenAI pointe sur base_url="http://localhost:11434/v1" avec api_key="ollama" (la clé est ignorée mais requise par le SDK). De quoi brancher LiteLLM, OpenWebUI ou Continue.dev par-dessus — c’est précisément l’objet du reste de ce cluster.

Gérer l’espace disque et les versions

À force de tirer des modèles, le disque se remplit vite : comptez plusieurs gigaoctets par modèle. ollama list donne l’inventaire et les tailles ; ollama rm libère ce qui ne sert plus :

ollama rm qwen2.5:7b

Par défaut, Ollama range ses modèles dans le dossier de l’utilisateur. Si votre disque système est petit mais que vous disposez d’un second volume, redirigez le stockage avec la variable OLLAMA_MODELS (même mécanisme systemd que ci-dessus) :

Environment="OLLAMA_MODELS=/data/ollama/models"

Cela évite de saturer la partition racine et simplifie les sauvegardes : un seul dossier à archiver.

Pièges courants

• Le modèle ne tient pas en VRAM. Ollama décharge alors une partie des couches vers le CPU : ça fonctionne, mais le débit chute nettement. Symptôme typique : une réponse qui s’écrit lentement, mot à mot. Remèdes : descendre d’un cran de quantification (de Q5_K_M à Q4_K_M), choisir un modèle plus petit, ou ajouter de la VRAM.
• Adaptateur LoRA et modèle de base désaccordés. Un ADAPTER entraîné sur Llama 3.1 8B mais appliqué à un autre modèle via FROM produit des sorties incohérentes. Vérifiez systématiquement la correspondance exacte.
• Quantification trop agressive. En dessous de 4 bits, la dégradation devient perceptible : davantage d’hallucinations, moins de rigueur sur le code. Le Q4_K_M reste le plancher raisonnable pour un usage sérieux.
• Contexte surdimensionné. Un num_ctx de 32 000 tokens « au cas où » alourdit chaque requête en mémoire, même quand vos prompts font 500 tokens. Dimensionnez-le à votre usage réel.

Quand Ollama montre ses limites

Ollama est imbattable pour démarrer, prototyper et servir une petite équipe. Mais sa gestion de la concurrence reste modeste : passé une dizaine d’utilisateurs simultanés tapant sur le même modèle, le débit plafonne, car les requêtes finissent par se sérialiser. C’est le signal pour regarder vLLM, conçu pour le service haute performance sur GPU, avec batching continu et parallélisme de tenseurs. Le bon réflexe n’est pas de choisir l’un ou l’autre, mais de prototyper sur Ollama et de basculer la production exigeante sur vLLM.

En résumé

• La quantification (Q4_K_M par défaut) divise l’empreinte mémoire pour une perte de qualité contenue.
• ollama create --quantize quantifie vos propres modèles ; le Modelfile (FROM, SYSTEM, PARAMETER) en façonne le comportement.
• Le fine-tuning se fait hors d’Ollama (LoRA/QLoRA via Unsloth ou Axolotl), puis s’importe avec la directive ADAPTER.
• Quelques variables d’environnement transforment Ollama en serveur d’équipe ; au-delà, vLLM prend le relais.

Voir aussi

• Héberger ses LLM soi-même en 2026 : Ollama, vLLM, LiteLLM, OpenWebUI (guide pilier)
• vLLM : serveur d’inférence haute performance sur GPU
• Intégrer un LLM dans une application