Nœud Ollama Chat Model n8nConfigurer Ollama Chat Model dans n8n.

Cette liste désigne le modèle qui génère la complétion. C'est le seul réglage à remplir systématiquement, et il doit correspondre à un modèle déjà téléchargé sur la machine Ollama ; la bibliothèque de modèles Ollama recense ce qui est disponible.

• Model : requis. La doc du nœud cite Llama2, Llama2 13B, Llama2 70B et Llama2 Uncensored parmi les choix.

Certains modèles raisonnent étape par étape avant de répondre. Avec le mode réflexion activé, ce qui est le réglage par défaut, ce raisonnement reste séparé de la sortie. Désactivé, le modèle écrit directement son contenu. Ça ne change rien sur les modèles qui ne gèrent pas la fonction.

• Enable Thinking : une case activée par défaut, qui isole le raisonnement du modèle de ce que reçoit le workflow.

Le hasard dans le texte généré, c'est ce nombre qui le pilote. Les valeurs basses donnent une sortie plus concentrée et déterministe. Les valeurs hautes la rendent plus variée et plus aléatoire, avec le risque d'invention qui va avec.

• Sampling Temperature : un nombre, bas pour des réponses reproductibles, haut pour des réponses variées.

À chaque étape, le modèle classe des tokens candidats, les fragments de mots avec lesquels il construit son texte. Top K limite combien des plus probables restent en lice. Une valeur haute augmente la diversité mais peut réduire la cohérence. À -1, la limite disparaît.

• Top K : un nombre, qui limite les tokens de vocabulaire les plus probables retenus à chaque étape.

Ici, pas de comptage de tokens mais une probabilité cumulée : le modèle choisit dans le plus petit ensemble de tokens dont la probabilité additionnée dépasse le seuil. Effet documenté, un texte plus naturel avec moins de répétitions.

• Top P : un nombre, une valeur basse écarte les options les moins probables.

Les tokens déjà apparus dans le texte généré sont pénalisés, et cette valeur dit à quel point. Plus elle monte, moins le modèle se répète. La pénalité suit la fréquence : plus une formule revient, plus le modèle s'en éloigne.

• Frequency Penalty : un nombre, qui ajuste la pénalité des tokens déjà présents dans la sortie.

Une fois la génération terminée, Ollama peut garder le modèle en mémoire au lieu de le décharger. Ce champ dit combien de temps, sous forme de durée comme 1h30m pour une heure et trente minutes. Utile pour les modèles sollicités souvent.

• Keep Alive : une chaîne de durée au format 1h30m, qui fixe le maintien en mémoire après usage.

Mémoire graphique serrée ? Cet interrupteur réduit la consommation mémoire au prix d'une génération plus lente. Il vise les GPU à mémoire limitée, et c'est un vrai arbitrage, pas une optimisation gratuite.

• Low VRAM Mode : une case qui échange de la vitesse de génération contre moins de mémoire utilisée.

Sur une machine à plusieurs cartes graphiques, il faut désigner celle qui porte le calcul principal. Ce champ prend cet identifiant de GPU. Avec une seule carte, il n'y a rien à décider, et la doc conseille de n'y toucher qu'en présence de plusieurs GPU.

• Main GPU ID : un nombre, l'identifiant du GPU utilisé pour le calcul principal.

Le traitement du prompt se fait par lots, et ce réglage en fixe la taille. Des lots plus grands peuvent accélérer la génération, mais ils consomment plus de mémoire. C'est le levier de débit, sans effet sur la qualité de la sortie.

• Context Batch Size : un nombre, la taille de lot utilisée pour traiter le prompt.

La fenêtre de contexte, c'est la quantité de texte que le modèle garde sous les yeux pour produire le token suivant. Ce nombre la plafonne. Une valeur basse réduit la mémoire consommée, une valeur haute donne plus de matière au modèle.

• Context Length : le nombre maximal de tokens servant de contexte pour générer le token suivant.

Le traitement en parallèle sur plusieurs cartes se règle ici : la valeur indique combien de GPU Ollama doit utiliser. Laissée à -1, elle déclenche la détection automatique, ce qui reste le réglage sain sur une machine que tu maîtrises.

• Number of GPUs : un nombre, -1 signifiant détection automatique.

La longueur de la réponse trouve son plafond dans ce champ. À -1, plus aucune limite, mais la doc met en garde contre les valeurs élevées, qui mènent à des sorties très longues et aux temps d'exécution qui vont avec.

• Max Tokens to Generate : le nombre maximal de tokens produits, -1 retirant la limite.

Le traitement côté processeur utilise autant de threads que cette valeur l'autorise. À 0, Ollama détecte lui-même le nombre. Utile à toucher quand la machine ne fait pas que servir des modèles.

• Number of CPU Threads : un nombre, 0 déclenchant la détection automatique.

Les retours à la ligne sont des tokens comme les autres. Activé, ce réglage rend leur génération moins probable, ce qui pousse le modèle vers des séquences de texte continues plutôt que vers des lignes hachées.

• Penalize Newlines : une case qui rend les caractères de saut de ligne moins probables dans la sortie.

Le critère n'est plus la fréquence mais la simple présence : un token est pénalisé dès qu'il est apparu dans le texte produit. Les valeurs positives poussent le modèle vers du contenu neuf et encouragent la diversité.

• Presence Penalty : un nombre, les valeurs positives pénalisant les tokens déjà apparus.

Un modèle coincé en boucle, qui répète la même proposition sans s'arrêter, c'est le problème que ce facteur traite. Plus la valeur monte, plus la répétition est découragée. À 1.0, la pénalité de répétition est désactivée.

• Repetition Penalty : un nombre, qui ajuste le facteur de pénalité des tokens répétés, 1.0 le désactivant.

Le swap, quand le système déplace des pages de mémoire vers le disque, plombe les temps de réponse. Verrouiller le modèle en mémoire l'empêche et peut améliorer les performances, mais il faut assez de mémoire libre pour tout tenir.

• Use Memory Locking : une case qui épingle le modèle en mémoire pour éviter le swap.

Charger le fichier du modèle par projection mémoire peut réduire la mémoire utilisée, avec un impact possible sur les performances. La doc recommande de garder l'option active : c'est un réglage qu'on désactive volontairement, pas par défaut.

• Use Memory Mapping : une case pour le chargement du modèle par projection mémoire, recommandée activée.

Seul le vocabulaire du modèle est chargé, sans les poids. Aucune vraie génération derrière, et c'est justement l'intérêt : tester la tokenisation devient rapide.

• Load Vocabulary Only : une case qui charge le vocabulaire et laisse les poids de côté.

Les nœuds suivants veulent rarement de la prose. Ce sélecteur fixe le format de la réponse de l'API, pour qu'elle arrive dans une forme exploitable par la suite du workflow.

• Output Format : deux choix, default (Default) et json (JSON).