Paramètres Modelfile Ollama : guide complet pour créer des modèles personnalisés

Mise à jour du 2026-06-08 : vérifié avec la doc officielle Modelfile d’Ollama — il y a 7 instructions (FROM / PARAMETER / TEMPLATE / SYSTEM / ADAPTER / LICENSE / MESSAGE ; pas de REQUIRES). Lien d’introduction corrigé et lectures complémentaires de la même série ajoutées.

Dans l’article précédent, on a vu comment faire tourner un modèle. Mais un problème me poursuit : les réponses sont trop imprévisibles.

Concrètement : je pose une simple question de code à llama3.2, et parfois j’obtiens trois lignes concises, parfois un mémoire entier. Avec temperature à 0,8, le modèle se met à « improviser » ; à 0,1, il devient rigide, comme s’il récitait par cœur. Pire encore : à chaque conversation, il faut reconfigurer le system prompt — copier-coller jusqu’à en avoir marre.

Puis j’ai découvert le Modelfile d’Ollama. En clair : un « CV de personnalité » pour le modèle — une configuration, effet permanent. Cet article rassemble les pièges que j’ai rencontrés et mes retours d’expérience, avec des conseils sur 10 paramètres clés et 4 modèles prêts à l’emploi.

Si Ollama n’est pas encore installé, commencez par le guide de démarrage Ollama. Celui-ci est du contenu avancé : on suppose que vous maîtrisez déjà ollama run.

1. Qu’est-ce qu’un Modelfile, et pourquoi en avoir besoin

Le Modelfile, c’est le « plan de configuration » du modèle — un peu comme un Dockerfile. Vous indiquez à Ollama quel modèle servir de base, quels paramètres appliquer, quel system prompt utiliser, puis vous lui donnez un nom. Ensuite, chaque appel sous ce nom applique automatiquement toute la configuration.

En bref, il résout trois frustrations :

Frustration 1 : tout reconfigurer à chaque fois

Vous connaissez la routine : ouvrir le terminal, ollama run llama3.2, taper un system prompt. Le lendemain, on recommence. Le surlendemain aussi… Le Modelfile fige ces réglages une bonne fois pour toutes.

Frustration 2 : un style de sortie instable

Le même modèle produit des résultats très différents selon les paramètres. Un assistant code a besoin de stabilité ; l’écriture créative, de variété. Impossible de retenir à chaque fois « ah oui, temperature 0,3 pour cette tâche, 0,8 pour celle-là » — le Modelfile stocke vos presets.

Frustration 3 : gérer plusieurs variantes

Vous voulez un llama3.2 « revue de code », un « assistant rédaction » et un « sortie JSON ». Pas besoin de tripler les fichiers de modèle : trois variantes nommées via Modelfile suffisent, le même fichier de base en dessous.

Le flux de base en trois étapes :

# 1. Créer un fichier Modelfile
echo 'FROM llama3.2
SYSTEM "Vous êtes un expert en revue de code"' > Modelfile

# 2. Générer le nouveau modèle avec ollama create
ollama create my-coder -f Modelfile

# 3. Lancer directement
ollama run my-coder

C’est aussi simple que ça. Voyons maintenant ce qu’on peut écrire dans un Modelfile.

2. Structure du Modelfile et 7 instructions

La syntaxe est simple : commentaires avec #, instructions en majuscules. Par exemple :

# Ceci est un commentaire
FROM llama3.2
PARAMETER temperature 0.8
SYSTEM "Vous êtes un assistant amical"

Deux types de contenu : commentaires et instructions. Sept instructions au total — voici la vue d’ensemble :

Instruction	Rôle	Obligatoire ?	Quand l’utiliser
FROM	Spécifier le modèle de base	Oui	Dans chaque fichier
PARAMETER	Paramètres d’inférence	Non	Ajuster température, contexte, etc.
TEMPLATE	Modèle de prompt	Non	Format de dialogue personnalisé
SYSTEM	Message système	Non	Définir rôle et comportement
ADAPTER	Charger un adaptateur LoRA	Non	Lors du fine-tuning
LICENSE	Déclaration de licence	Non	Lors de la publication
MESSAGE	Historique prédéfini	Non	Exemples few-shot

En pratique, 90 % du temps, FROM, PARAMETER et SYSTEM suffisent. Les autres, quand un besoin précis se présente.

Trois façons d’utiliser FROM

FROM est la seule instruction obligatoire. Trois syntaxes :

Syntaxe 1 : nom de modèle (la plus courante)

FROM llama3.2
FROM llama3.2:3b
FROM mistral:latest

Utilisez directement un nom de modèle supporté par Ollama. Après les deux-points, la version ; sans tag, c’est latest.

Syntaxe 2 : fichier GGUF local

FROM ./my-model.gguf

Si vous avez téléchargé un modèle au format GGUF ailleurs, pointez directement vers le fichier.

Syntaxe 3 : répertoire Safetensors

FROM ./my-safetensors-dir

Plus rare — généralement le format original téléchargé depuis Hugging Face.

Voilà pour la structure de base. Place au cœur de l’article : les paramètres PARAMETER.

3. Paramètres PARAMETER en détail

C’est la partie la plus concrète. J’ai rassemblé les pièges rencontrés en ajustant les paramètres — voici un tableau de configuration prêt à copier.

Liste complète :

Paramètre	Défaut	Type	À quoi ça sert	Comment régler
temperature	0.8	float	Contrôle l’aléatoire — plus haut = plus « libre »	Code 0,3, créatif 1,0
num_ctx	2048	int	Taille de la fenêtre de contexte	Documents longs : 4096-8192
top_k	40	int	Choisir parmi les K mots les plus probables	En général, ne pas toucher
top_p	0.9	float	Échantillonnage nucleus, contrôle la diversité	À combiner avec temperature
min_p	0.0	float	Filtre les mots à faible probabilité	Sortie de qualité : 0,05
seed	0	int	Graine aléatoire fixe, sortie reproductible	Tests : 42 ou valeur fixe
stop	aucun	string	Arrêter la génération à cette séquence	Plusieurs stop cumulables
num_predict	-1	int	Longueur max de sortie, -1 = illimité	Limiter : 100-500
repeat_penalty	1.1	float	Pénalise les répétitions	Texte long : 1,5
repeat_last_n	64	int	Détecte les répétitions sur les N derniers mots	Avec repeat_penalty

Détail sur les paramètres les plus importants.

temperature : créativité vs stabilité

Le plus intuitif. temperature élevée (ex. 1,0) : le modèle « se lâche », choisit des mots moins probables mais plus créatifs. temperature basse (ex. 0,1) : il reste conservateur, ne prend que les mots les plus probables — sortie plus stable.

J’ai testé llama3.2 à différentes valeurs sur la même question :

Question : Comment lire un fichier en Python ?

• temperature 0,1 : réponse de manuel, uniquement la réponse standard
• temperature 0,5 : quelques conseils pratiques en plus, ex. « attention à l’encodage »
• temperature 0,8 : plusieurs méthodes selon le contexte, parfois des exemples
• temperature 1,0 : réponses très variées, parfois hors sujet

Mon expérience :

• Code, Q&R technique : autour de 0,3, pour la stabilité
• Écriture créative, brainstorming : 0,8-1,0, pour la surprise
• Sortie JSON, format fixe : 0,1-0,2, pour la précision

num_ctx : fenêtre de contexte

Détermine combien de contenu le modèle peut « retenir ». 2048 tokens par défaut — environ 1500-2000 caractères chinois, ou l’équivalent en français.

Vous voulez qu’il lise un long article puis le résume ? 2048 peut être insuffisant. Il oublie soudain le début d’une longue conversation ? Probablement num_ctx trop petit.

Attention : augmenter num_ctx consomme plus de mémoire. En testant llama3.2, passer de 2048 à 8192 a plus que doublé l’occupation RAM. Avec 8 Go de mémoire, 4096 est un plafond raisonnable.

Mon expérience :

• Conversations courtes, Q&R simples : 2048 par défaut suffit
• Revue de code, discussions techniques : 4096 confortable
• Longs documents, écriture narrative : 8192 (si la mémoire le permet)

stop : séquences d’arrêt

Très utile — dites au modèle « arrête quand tu vois ça ».

Par exemple, pour une sortie JSON sans bavardage :

PARAMETER stop "\n\n"
PARAMETER stop "```"

Le modèle s’arrête à deux retours à la ligne ou au symbole de bloc de code — sortie plus propre.

Plusieurs stop peuvent se cumuler — beaucoup l’ignorent.

repeat_penalty : éviter les redondances

Les modèles ont un défaut : répéter la même phrase. repeat_penalty pénalise les répétitions.

La valeur par défaut 1,1 me semble insuffisante pour les longs textes. Je monte généralement à 1,3-1,5 — ça réduit efficacement les « comme mentionné précédemment », « en conclusion », etc.

Tableau comparatif par scénario

Quatre configurations courantes, prêtes à copier :

Scénario	temperature	num_ctx	Autres paramètres
Assistant code	0.3	4096	stop ”```”, seed 42 (reproductibilité)
Écriture créative	1.0	2048	top_p 0.95, repeat_penalty 1.5
Q&R technique	0.5	4096	min_p 0.05 (filtrer mots de faible qualité)
Sortie JSON	0.1	2048	stop “\n\n”, stop ”```”

Vous devriez avoir une bonne idée de chaque paramètre. Place à la pratique : quatre Modelfiles prêts à l’emploi.

4. Cas pratiques : 4 Modelfiles complets

La théorie est faite — voici le code. Ces quatre modèles ont été testés ; copiez-collez et lancez.

Cas 1 : Jeu de rôle — assistant Zhu Bajie

Un petit modèle amusant que j’ai créé, imitant le style de Zhu Bajie (Le Cochon du Voyage en Occident) :

# Modelfile assistant Zhu Bajie
FROM llama3.2

SYSTEM """Vous êtes Zhu Bajie du Voyage en Occident. Parlez avec humour et simplicité.
En répondant :
- Plaignez-vous parfois que le maître bavarde trop
- Soyez enthousiaste quand on parle de nourriture
- Dites « moi, le Cochon » pour vous désigner
- Face aux difficultés, dites « autant se séparer »"""

PARAMETER temperature 0.8
PARAMETER num_ctx 2048

Pourquoi cette configuration :

temperature à 0,8 donne plus de « personnalité » à Zhu Bajie, sans rigidité. Le SYSTEM précise les règles — enthousiasme pour la nourriture, « moi, le Cochon » — ces détails rendent le personnage vivant.

Utilisation :

ollama create pig-bajie -f Modelfile
ollama run pig-bajie

Essayez : « Comment bien apprendre la programmation ? » et observez la réponse.

Cas 2 : Assistant pro — revue de code Python

Ma configuration quotidienne pour la revue de code :

# Modelfile assistant revue de code Python
FROM llama3.2:3b

SYSTEM """Vous êtes un développeur Python senior. Lors de la revue de code, vérifiez :
1. Sécurité des types — erreurs de type potentielles
2. Gestion des exceptions — cas limites couverts
3. Goulots d'étranglement — boucles ou calculs redondants
4. Risques de sécurité — exposition de données sensibles

Format de réponse :
Problème → Impact → Suggestion → Exemple de code"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER seed 42

Pourquoi cette configuration :

temperature 0,3 pour une sortie stable — la revue de code n’a pas besoin de « créativité ». num_ctx 8192 car les fichiers de code peuvent être longs. seed 42 pour la reproductibilité — même question, mêmes conseils, pratique pour comparer.

En pratique : j’envoie quelques centaines de lignes de Python, et le modèle produit un rapport structuré « Problème → Impact → Suggestion → Exemple ».

Cas 3 : Sortie structurée — format JSON

Pour alimenter d’autres programmes, le JSON est le plus pratique :

# Modelfile assistant sortie JSON
FROM llama3.2

SYSTEM """Votre sortie doit être du JSON valide.
Format du résultat d'analyse :
{"result": "contenu de l'analyse", "confidence": 0-100, "tags": ["tag1", "tag2"]}

Ne produisez rien d'autre. N'ajoutez pas de marqueurs de bloc de code."""

PARAMETER temperature 0.1
PARAMETER num_ctx 2048
PARAMETER stop "\n\n"
PARAMETER stop "```"

MESSAGE user Analysez les risques de sécurité de ce code
MESSAGE assistant {"result": "Risque d'injection SQL, entrée utilisateur non filtrée", "confidence": 85, "tags": ["sécurité", "SQL"]}

Pourquoi cette configuration :

temperature 0,1 pour une sortie maximalement stable — le JSON n’admet aucune déviation. Les stop filtrent retours à la ligne et symboles de bloc de code. MESSAGE fournit un exemple few-shot : « la sortie doit ressembler à ça ».

Je l’utilise dans des flux automatisés : logs d’erreur → analyse structurée → traitement automatique.

Cas 4 : Long contexte — résumé de document

Pour les longs articles, la fenêtre de contexte doit être suffisante :

# Modelfile assistant résumé de document
FROM llama3.2

SYSTEM """Vous êtes un expert en résumé de documents. Exigences de sortie :
- Pas plus de 5 points clés
- Chaque point en 50 mots maximum
- Extraire d'abord les idées centrales, puis les détails
- Produire la sortie en français"""

PARAMETER temperature 0.5
PARAMETER num_ctx 8192
PARAMETER num_predict 300

Pourquoi cette configuration :

temperature 0,5 — un résumé doit être stable, sans devenir une énumération mécanique (trop bas = chronologie plate). num_ctx 8192 pour les longs documents. num_predict 300 limite la longueur — un résumé ne doit pas dépasser l’original.

Je l’utilise sur des articles techniques : 3000 mots en entrée, 5 points de 50 mots en sortie — bien plus efficace à lire.

En bref

Ces quatre modèles couvrent les besoins courants. Modifiez le SYSTEM ou les paramètres selon vos besoins — après changement, relancez ollama create, le coût de débogage est faible.

5. TEMPLATE et MESSAGE — niveau avancé

Les exemples précédents n’utilisaient pas TEMPLATE — c’est une fonction « avancée », utile quand vous voulez un contrôle fin du format de dialogue.

Syntaxe Go template de TEMPLATE

Ollama utilise la syntaxe template de Go, avec trois variables clés :

• {{ .System }} — contenu de votre SYSTEM
• {{ .Prompt }} — entrée utilisateur
• {{ .Response }} — sortie du modèle (pour définir le format)

Exemple simple :

FROM llama3.2

TEMPLATE """{{ .System }}

Question de l'utilisateur : {{ .Prompt }}

Réponse : {{ .Response }}"""

SYSTEM "Vous êtes un expert technique"

Ce TEMPLATE définit la structure : SYSTEM, puis question, puis réponse.

Honnêtement, la plupart du temps, le template par défaut d’Ollama suffit. Quand le modifier ?

Scénario 1 : intégration avec d’autres outils

Vous connectez Ollama à un système de chat avec un format d’entrée spécifique. TEMPLATE sert à l’adaptation.

Scénario 2 : format de dialogue particulier

Vous voulez un « préfixe » sur chaque message — [AI] ou [USER] — TEMPLATE le permet.

MESSAGE : historique prédéfini

MESSAGE sert à « montrer des exemples au modèle ». L’exemple JSON ci-dessus l’utilisait :

MESSAGE user Analysez les risques de sécurité de ce code
MESSAGE assistant {"result": "Risque d'injection SQL", "confidence": 85}

Cela indique au modèle : « quand l’utilisateur pose ce type de question, répondez ainsi » — le principe du few-shot learning.

Vous pouvez prédéfinir plusieurs tours :

MESSAGE user Bonjour
MESSAGE assistant Bonjour, comment puis-je vous aider ?
MESSAGE user Quel temps fait-il ?
MESSAGE assistant Je n'ai pas la météo en temps réel, consultez une application météo.

Au démarrage, le modèle « retient » ces échanges ; les nouvelles conversations suivent ce style.

Consulter le Modelfile d’un modèle

Pour voir comment un modèle est configuré :

ollama show --modelfile llama3.2

La sortie est longue — toute la configuration par défaut. Copiez, modifiez, créez votre version personnalisée.

Commande très utile : quand un modèle partagé fonctionne bien, ollama show exporte son Modelfile — excellent moyen d’apprendre la configuration des autres.

6. Problèmes courants et pièges à éviter

Régler les paramètres, c’est inévitablement marcher sur des mines. Voici les cas typiques rencontrés — pour vous éviter les mêmes écueils.

Problème 1 : temperature trop basse, sortie comme une récitation

Certains pensent que plus bas = mieux — sortie stable, non ? Moi aussi au début, j’avais mis 0,05 sur mon assistant code.

Résultat : le modèle répondait comme s’il récitait des réponses types, sans aucune flexibilité. « Comment lire un fichier en Python ? » — trois méthodes, chacune au format manuel, sans conseil pratique.

Ma leçon : temperature n’est pas « plus bas = mieux ». 0,3 suffit pour la revue de code ; en dessous de 0,2, ça devient rigide. Pour du JSON précis, oui, il faut bas — pas pour le quotidien.

Problème 2 : num_ctx trop grand, saturation mémoire

Un jour, j’ai monté num_ctx à 16384 — pour traiter des documents très longs. Quelques minutes plus tard, le système swapait frénétiquement, la machine était bloquée.

16 Go de RAM seulement. llama3.2:3b occupe environ 2 Go ; de 2048 à 16384, la consommation dépasse 8 Go. Plus les autres programmes…

Leçon : num_ctx ne se monte pas indéfiniment. Selon votre mémoire :

• 8 Go : num_ctx max 4096
• 16 Go : num_ctx jusqu’à 8192
• 32 Go et plus : on peut tenter 16384

Problème 3 : confondre SYSTEM et MESSAGE

Deux rôles distincts, souvent mélangés :

• SYSTEM : définition permanente du rôle, active à chaque conversation
• MESSAGE : historique prédéfini, équivalent d’exemples few-shot

Exemple : modèle « expert revue de code » — SYSTEM pour le rôle, MESSAGE pour quelques Q&R types.

Beaucoup n’écrivent que SYSTEM, sans MESSAGE : le modèle « sait » qu’il est expert, mais pas comment répondre concrètement. Quelques MESSAGE améliorent nettement la qualité.

Problème 4 : mettre à jour après création

Modèle créé via Modelfile, besoin de changer la config ?

Simple — relancez ollama create avec le même nom :

# Première création
ollama create my-coder -f Modelfile

# Modifier la config ? Éditez le Modelfile, puis relancez
ollama create my-coder -f Modelfile

Ollama écrase directement le modèle du même nom, sans suppression. Pour garder l’original, changez de nom :

ollama create my-coder-v2 -f Modelfile

Problème 5 : reproduire le Modelfile de quelqu’un d’autre

Un modèle partagé fonctionne bien, vous voulez comprendre sa configuration :

# Télécharger le modèle
ollama pull someone-elses-model

# Exporter son Modelfile
ollama show --modelfile someone-elses-model > learned-modelfile

# Consulter, apprendre, modifier
cat learned-modelfile

Je l’utilise souvent — j’ai appris pas mal d’astuces de réglage via les modèles de la communauté.

À lire aussi

• Démarrer avec Ollama : lancer des LLM locaux rapidement
• API Ollama en pratique : appels compatibles OpenAI
• Quantification GGUF d’Ollama : le guide complet

Conclusion

En résumé, la logique du Modelfile tient en une phrase : figer la configuration pour éviter les réglages manuels à chaque fois.

Trois actions immédiates :

1. Créer un modèle de jeu de rôle

Essayez le modèle Zhu Bajie, ou remplacez par un personnage que vous aimez (Doraemon, Iron Man…). Quelques tours de dialogue pour sentir l’effet de temperature sur le style.

2. Comparer les sorties à paramètres différents

Même question avec temperature 0,3 et 0,8 — observez la différence. Je l’ai fait de nombreuses fois, à chaque fois une découverte.

3. Choisir un scénario que vous utilisez souvent

Revue de code, résumé de document, écriture créative — adaptez un modèle ci-dessus à vos besoins. Après quelques itérations, vous aurez un modèle personnalisé.

Le prochain article portera sur l’intégration API Ollama — connecter le modèle local à vos programmes via l’interface compatible OpenAI. Une fois le Modelfile configuré, les appels API sont plus stables : plus besoin de passer les paramètres dans le code, utilisez directement le modèle personnalisé.

Des questions ? Laissez un commentaire — les pièges que j’ai rencontrés pourront peut-être vous en éviter quelques-uns.