Comment optimiser un modèle local avec Ollama ?

En réglant le Modelfile, l’échantillonnage, le contexte et les tests. Ollama rend les modèles locaux simples à lancer, mais ses réglages par défaut ne suffisent pas toujours pour coder, structurer des données ou automatiser un workflow fiable.

Pourquoi régler Ollama en local ?

Régler Ollama en local, ce n’est pas chercher un gain marginal pour le plaisir de tuner. C’est reprendre la main sur le comportement du modèle : ce qu’il voit, ce qu’il garde en contexte, le niveau de créativité autorisé, le format des réponses et les contraintes propres à votre usage.

Ollama est un outil léger qui permet de lancer et gérer des modèles de langage localement via une interface en ligne de commande. Concrètement, vous pouvez télécharger un modèle, l’exécuter sur votre machine, puis le personnaliser avec un fichier appelé Modelfile. La documentation officielle décrit cette logique de gestion des modèles et du Modelfile : https://ollama.com/library et https://github.com/ollama/ollama/blob/main/docs/modelfile.md.

L’exécution locale apporte quatre bénéfices très concrets :

• Confidentialité. Vos prompts, documents, logs ou extraits de base de données restent sur votre machine ou votre serveur, sans passage obligatoire par une API externe.
• Maîtrise des coûts. Vous ne payez pas chaque requête au token, c’est-à-dire à l’unité de texte traitée par le modèle. Le coût principal devient votre matériel.
• Fonctionnement hors-ligne. Une fois le modèle téléchargé, vous pouvez travailler sans connexion, utile en environnement contraint ou isolé.
• Gestion simple des modèles. La logique rappelle Docker : une image de base, une configuration, puis une exécution reproductible. L’analogie avec un Dockerfile est utile ici, car Docker documente ce principe de fichier décrivant une image exécutable : https://docs.docker.com/reference/dockerfile/.

Les réglages par défaut restent utiles, mais ils sont souvent pensés pour des conversations généralistes, prudentes et acceptables dans beaucoup de situations. Ce n’est pas toujours ce que vous voulez. Un assistant de code doit être précis et peu bavard. Une extraction structurée doit respecter un format strict. Un pipeline ETL, c’est-à-dire un processus qui extrait, transforme puis charge des données, a besoin de sorties stables. Un système multi-agents doit éviter les dérives entre agents.

Découvrez égalementClaude Agent SDK ou Pydantic AI lequel choisir ?

La bonne approche consiste donc à partir d’un modèle de base, encapsuler les consignes et paramètres dans un Modelfile, ajuster l’échantillonnage pour contrôler la créativité, adapter la taille du contexte aux données fournies, puis tester les résultats sur des cas réels. C’est cette progression qui permet de passer d’un modèle local “qui répond” à un modèle local réellement exploitable.

Comment créer un Modelfile utile ?

Un Modelfile utile évite de bricoler les mêmes réglages à chaque test. J’y vois surtout un fichier déclaratif : il décrit comment Ollama doit charger un modèle, quelles consignes appliquer par défaut et quels paramètres utiliser à l’exécution.

Le principe ressemble prudemment à un Dockerfile : on part d’une base, on ajoute une configuration, puis on crée une variante réutilisable. La comparaison s’arrête là. Un Modelfile ne fait pas de vrai fine-tuning, c’est-à-dire qu’il ne réentraîne pas les poids du modèle. Il encapsule une configuration reproductible autour d’un modèle existant, comme le précise la documentation officielle Ollama Modelfile sur GitHub.

Les trois directives les plus utiles sont simples à comprendre :

• FROM Définit le modèle source, par exemple llama3.1:8b.
• SYSTEM Définit les consignes système, c’est-à-dire les règles de comportement suivies par défaut.
• PARAMETER Définit les réglages d’inférence, comme la créativité, la taille du contexte ou la stratégie d’échantillonnage.

FROM llama3.1:8b

PARAMETER temperature 0.2
PARAMETER num_ctx 8192
PARAMETER min_p 0.05

SYSTEM """
Tu es un assistant technique stable.
Réponds de façon concise, vérifiable et structurée.
Explique les hypothèses lorsque l’information manque.
Ne donne pas de certitude sans source ou sans raisonnement explicite.
Privilégie les listes courtes, les exemples concrets et les commandes testables.
"""

La commande ollama create, documentée dans la documentation officielle Ollama CLI, crée ensuite une variante locale à partir de ce fichier. La commande ollama run lance cette variante comme n’importe quel autre modèle Ollama.

ollama create mon-assistant -f ./Modelfile
ollama run mon-assistant

Découvrez égalementComment rendre vos agents IA fiables et contrôlés ?

L’intérêt opérationnel est immédiat. Plus besoin de renvoyer temperature, num_ctx ou le même prompt système dans chaque appel API. Les requêtes héritent de la configuration. Une équipe peut aussi versionner plusieurs profils dans Git : assistant support, assistant code, assistant synthèse, assistant strict. Chaque variante devient comparable, testable et partageable.

Quels paramètres d’échantillonnage régler ?

Les paramètres d’échantillonnage pilotent une chose simple : le niveau de liberté laissé au modèle quand il génère sa réponse. À chaque token, c’est-à-dire une unité de texte souvent plus petite qu’un mot complet, le modèle calcule une distribution de probabilités sur les suites possibles. Il peut ensuite choisir le token le plus probable, ou piocher dans un ensemble plus large selon des règles comme temperature, top_k, top_p et min_p.

La temperature agit comme un réglage de hasard. Une valeur basse, par exemple 0.1 à 0.2, rend les réponses plus stables et prévisibles. C’est adapté au code, au calcul, à l’extraction structurée ou aux réponses qui doivent varier le moins possible. Une valeur plus haute, autour de 0.8 à 1.2, augmente la diversité, donc utile pour du brainstorming, de la rédaction créative ou des variantes de formulation.

PARAMETER temperature 0.1

Le paramètre top_k limite le choix aux K tokens les plus probables. Avec top_k 40, le modèle ignore tout ce qui est au-delà des 40 meilleures options à chaque étape. C’est une manière simple de réduire les sorties trop improbables.

PARAMETER top_k 40

Le paramètre top_p, aussi appelé nucleus sampling, conserve le plus petit groupe de tokens dont la probabilité cumulée atteint un seuil, par exemple 0.90. Cette méthode a été étudiée par Holtzman et al. dans The Curious Case of Neural Text Degeneration, qui montre pourquoi un décodage trop mécanique peut produire du texte répétitif ou dégradé. Le paramètre min_p élimine les tokens trop peu probables relativement au meilleur token, ce qui peut éviter certaines sorties erratiques sans enfermer complètement le modèle.

Découvrez égalementDifférence entre les agents IA on demand et IA worker

Les réglages doivent rester empiriques. La documentation officielle Ollama Modelfile liste ces paramètres, mais le bon compromis dépend du modèle, du prompt système et de vos données. Le plus fiable reste de tester sur un jeu de prompts représentatif.

Quelques réglages prudents servent de point de départ :

• Extraction JSON : Temperature 0.0 à 0.2, top_p bas ou modéré, avec validation stricte côté code.
• Assistant de code : Temperature 0.1 à 0.3, top_k autour de 20 à 40.
• Support client : Temperature 0.2 à 0.5, pour garder un ton naturel sans trop varier.
• Idéation marketing : Temperature 0.8 à 1.1, top_p autour de 0.90 à 0.95.

Comment adapter le contexte et le serveur ?

Un modèle local ne se règle pas dans le vide. Avant de modifier le prompt ou de changer de modèle, je vérifie si le problème vient du contexte disponible, du serveur ou simplement des limites de la machine.

num_ctx désigne la taille de la fenêtre de contexte, c’est-à-dire la quantité de texte que le modèle peut prendre en compte en une seule requête. Cette fenêtre inclut votre prompt, l’historique de conversation, les documents injectés et les tokens générés. Un token correspond grossièrement à un morceau de mot, pas forcément à un mot complet.

Augmenter num_ctx aide sur les documents longs, les bases de code ou les échanges multi-tours. Par exemple, dans un Modelfile Ollama, je peux tester :

FROM llama3.1:8b
PARAMETER num_ctx 8192

Ce réglage permet au modèle de “voir” plus d’informations, mais il a un coût. Plus le contexte est grand, plus la mémoire consommée augmente et plus les réponses peuvent ralentir. La latence désigne le temps entre votre demande et le début de la réponse, ou entre votre demande et la réponse complète selon la mesure choisie.

L’optimisation ne concerne donc pas seulement le Modelfile. Il faut regarder la mémoire disponible, le GPU si présent, la taille du modèle, le nombre de requêtes simultanées et la latence acceptable pour votre usage. Un modèle 70B avec un grand contexte n’a pas le même profil qu’un modèle 7B utilisé par une seule personne.

La méthode la plus fiable reste progressive :

• Commencer avec un modèle raisonnable pour votre machine.
• Mesurer la latence et la mémoire consommée sur des prompts réels.
• Augmenter num_ctx par paliers, par exemple 4096, puis 8192.
• Comparer la qualité des réponses, pas seulement la vitesse.
• Documenter les compromis retenus pour éviter les réglages “magiques”.

Avant un usage en production, je vérifie toujours la documentation officielle Ollama, car les paramètres serveur et les variables d’environnement évoluent selon les versions et les plateformes. Les références à consulter sont la documentation Modelfile, l’API et les paramètres d’exécution disponibles dans la version courante : https://github.com/ollama/ollama/blob/main/docs/modelfile.md et https://github.com/ollama/ollama/blob/main/docs/api.md.

Comment tester sans se tromper ?

Un réglage Ollama ne se valide pas à l’intuition après deux conversations réussies. Je préfère tester plusieurs configurations sur les mêmes prompts, avec des critères visibles, car un modèle peut sembler meilleur en discussion libre et devenir inutilisable dès qu’on lui demande un JSON strict, du code fiable ou une réponse courte.

Le plus simple consiste à créer un petit jeu de tests représentatif de vos usages réels. Il doit contenir quelques prompts de code, une extraction JSON, un résumé de document, des questions pièges, des consignes de format strict et des cas métier que vous rencontrez vraiment.

La méthode tient en quelques étapes :

• Définir un modèle de base, par exemple llama3.1 ou mistral selon votre machine.
• Créer deux ou trois variantes avec un Modelfile.
• Changer un seul paramètre à la fois, comme temperature, top_p ou num_ctx.
• Exécuter exactement les mêmes prompts via l’API Ollama ou la CLI.
• Noter les résultats avec les mêmes critères pour chaque variante.

Cette approche ressemble à un test A/B interne : une version A, une version B, les mêmes entrées, puis une comparaison factuelle. La documentation officielle Ollama décrit l’exécution de requêtes via l’API, notamment avec les endpoints de génération et de chat : https://github.com/ollama/ollama/blob/main/docs/api.md. Les guides d’évaluation des LLM, comme ceux d’OpenAI sur les evals, vont dans le même sens : mesurer sur des cas représentatifs plutôt que juger au ressenti : https://platform.openai.com/docs/guides/evals.

Pour les workflows automatisés, la prévisibilité compte souvent plus que la créativité. Une réponse élégante mais mal structurée peut casser une étape n8n, un ETL, c’est-à-dire un pipeline d’extraction, transformation et chargement de données, ou une API, l’interface utilisée par deux logiciels pour communiquer.

Avant mise en production, je vérifie systématiquement :

• Modelfile versionné.
• Paramètres documentés.
• Prompts de test rejouables.
• Format de sortie validé.
• Limites matérielles connues.
• Surveillance prévue sur les erreurs, la latence et les sorties invalides.

Votre modèle Ollama est-il vraiment prêt à travailler ?

Optimiser Ollama, ce n’est pas chercher le réglage magique. C’est construire une configuration claire, réutilisable et testable. Le Modelfile donne une base propre. La température, top-k, top-p et min_p permettent d’ajuster le niveau de liberté du modèle. Le contexte et l’environnement serveur évitent les mauvaises surprises de performance. Les tests, eux, séparent les impressions des résultats mesurables. Je retiens une règle simple : pour un usage business, un modèle local doit être stable avant d’être impressionnant. Le bénéfice pour vous : des réponses plus fiables, mieux cadrées et plus faciles à intégrer dans vos automatisations.

FAQ

• À quoi sert Ollama pour un modèle de langage local ?
  Ollama sert à télécharger, lancer et gérer des modèles de langage directement sur votre machine ou votre serveur. L’intérêt principal est de garder plus de contrôle sur les données, les coûts, les versions de modèles et les réglages d’exécution.
• Quelle est la différence entre un Modelfile et un fine-tuning ?
  Un Modelfile configure un modèle existant avec des directives et des paramètres, mais il ne réentraîne pas le modèle. Le fine-tuning modifie les poids du modèle avec de nouvelles données d’entraînement. Le Modelfile est donc plus simple, plus rapide et plus adapté pour créer des variantes réutilisables.
• Quelle température choisir avec Ollama ?
  Pour du code, du JSON, du raisonnement ou de l’extraction structurée, une température basse comme 0.1 ou 0.2 est souvent préférable. Pour de l’idéation ou de la rédaction créative, une valeur plus élevée comme 0.8 peut produire davantage de variété. Le bon réglage dépend toujours du test réel.
• Top-k, top-p et min_p servent-ils à la même chose ?
  Ils agissent tous sur le choix des prochains tokens, mais pas de la même manière. Top-k limite le choix aux K tokens les plus probables. Top-p garde un groupe de tokens selon une probabilité cumulée. Min_p filtre les tokens trop faibles par rapport au token le plus probable. Leur objectif commun est de réduire les sorties incohérentes.
• Faut-il augmenter num_ctx systématiquement ?
  Non. Un contexte plus grand peut aider sur des documents longs ou des échanges complexes, mais il consomme plus de mémoire et peut ralentir le modèle. Il faut l’augmenter seulement si vos tests montrent que le modèle manque d’informations importantes dans le contexte.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les processus business et le SEO/GEO. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer, automatiser ou industrialiser vos usages IA avec des bases propres, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

• Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

• Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
• Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
• Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.