Nœud Ollama Model n8nConfigurer Ollama Model dans n8n.

Tant que ce sélecteur est vide, rien ne se passe. Il désigne le modèle qui produira la complétion, et ce choix décide de tout le reste : qualité de la réponse, vitesse, mémoire immobilisée pendant le chargement.

• Model : le modèle qui génère la complétion. La doc officielle du nœud cite Llama2, Llama2 13B, Llama2 70B et Llama2 Uncensored ; pour télécharger des modèles, passe par l'Ollama Models Library.

Les modèles de raisonnement gardent un brouillon avant de répondre. Cet interrupteur décide si ce brouillon reste à part du résultat, et il ne veut rien dire sur un modèle qui ne gère pas le mode.

• Enable Thinking : active (par défaut) le mode réflexion sur les modèles compatibles. Activé, le raisonnement est séparé de la sortie ; désactivé, le modèle produit directement le contenu.

Le hasard a une molette, la voici. Le même prompt lancé deux fois peut revenir formulé autrement, et l'écart entre ces deux réponses tient exactement à ce nombre.

• Sampling Temperature : contrôle le caractère aléatoire du texte généré. Une valeur basse rend la sortie plus ciblée et déterministe, une valeur haute la rend plus variée et plus aléatoire.

À chaque étape, le modèle classe tout son vocabulaire puis pioche en haut du classement. Un token, c'est un fragment de texte, à peu près un mot ou un morceau de mot. Ce réglage dit jusqu'où le tirage a le droit de descendre.

• Top K : limite le nombre de tokens les plus probables considérés à chaque étape. Une valeur plus haute augmente la diversité mais peut réduire la cohérence. -1 désactive le réglage.

Ici, on ne compte plus les candidats mais la probabilité. Le tirage ajoute des tokens au panier jusqu'à ce que leur probabilité cumulée dépasse le seuil fixé, puis s'arrête.

• Top P : choisit dans le plus petit ensemble de tokens dont la probabilité cumulée dépasse top_p. Aide à produire un texte plus naturel en réduisant les répétitions.

La répétition s'installe quand le même token gagne le classement encore et encore. Cette pénalité pèse contre les tokens à proportion du nombre de fois où ils ont déjà servi dans la réponse en cours.

• Frequency Penalty : ajuste la pénalité appliquée aux tokens déjà apparus dans le texte généré. Des valeurs plus hautes découragent la répétition.

Charger un modèle local en mémoire coûte des secondes bien réelles. Ce champ dit combien de temps Ollama doit l'y garder après l'appel, pour que la prochaine exécution démarre à chaud.

• Keep Alive : durée de maintien du modèle chargé en mémoire après usage. Utile pour les modèles fréquemment sollicités. Format 1h30m pour une heure et trente minutes.

Les petites cartes graphiques étouffent sur les gros modèles. Activer ce mode échange de la vitesse contre de la place, et c'est souvent ce qui sépare une chaîne qui tourne d'une chaîne qui plante sur la machine dont tu disposes.

• Low VRAM Mode : active le mode faible VRAM, qui réduit l'usage mémoire au prix d'une génération plus lente. Utile pour les GPU à mémoire limitée.

Une machine à plusieurs cartes graphiques doit savoir laquelle mène le calcul. Laissé tranquille, ce champ ne fait rien ; sur un serveur multi-cartes, il décide où la charge tombe.

• Main GPU ID : identifiant du GPU utilisé pour le calcul principal. À ne changer que si plusieurs GPU sont présents.

Avant de générer quoi que ce soit, le modèle doit lire le prompt, et il le lit par lots. Élargir le lot accélère cette phase de lecture, au prix de la mémoire.

• Context Batch Size : définit la taille de lot pour le traitement du prompt. Des lots plus grands peuvent accélérer la génération mais augmentent l'usage mémoire.

Le contexte est un budget. Tout ce que le modèle a le droit de regarder pour écrire le token suivant, le prompt comme ce qu'il a déjà produit, doit tenir dans ce nombre.

• Context Length : nombre maximal de tokens utilisés comme contexte pour générer le token suivant. Des valeurs basses réduisent la mémoire, des valeurs hautes donnent plus de contexte au modèle.

Répartir le travail sur plusieurs cartes se demande explicitement, ici. Ce champ compte les cartes, là où Main GPU ID désigne celle qui commande.

• Number of GPUs : nombre de GPU utilisés pour le traitement parallèle. -1 active la détection automatique.

Une réponse peut s'emballer. Ce plafond arrête le modèle en vol, ce qui protège à la fois la durée d'exécution du workflow et le nœud d'après, qui attend un champ de taille raisonnable.

• Max Tokens to Generate : nombre maximal de tokens générés. -1 supprime la limite ; prudence avec une valeur élevée, qui peut produire des sorties très longues.

Une partie du travail retombe toujours sur le processeur, et sur une machine sans carte graphique exploitable, la totalité. Ce champ dit combien de threads Ollama peut réclamer.

• Number of CPU Threads : nombre de threads CPU utilisés pour le traitement. 0 active la détection automatique.

Les sauts de ligne sont des tokens comme les autres, et un modèle qui les cherche produit des réponses hachées. Cet interrupteur le pousse dans l'autre sens.

• Penalize Newlines : rend le modèle moins enclin à produire des caractères de saut de ligne, ce qui encourage des séquences de texte continues plus longues.

Présence et fréquence se ressemblent mais ne comptent pas la même chose. Celle-ci retient seulement qu'un token est apparu, pas combien de fois, et pousse le modèle vers du vocabulaire encore vierge.

• Presence Penalty : ajuste la pénalité des tokens selon leur présence dans le texte déjà généré. Les valeurs positives pénalisent les tokens déjà apparus et encouragent la diversité.

Un troisième garde-fou anti-répétition s'ajoute aux deux autres, et c'est le plus direct : un facteur unique appliqué aux tokens qui reviennent.

• Repetition Penalty : ajuste le facteur de pénalité des tokens répétés. Des valeurs plus hautes découragent plus fortement la répétition. 1.0 désactive la pénalité.

Un système sous pression déplacera le modèle chargé vers le disque, et l'appel suivant rampe. Le verrouillage l'épingle en mémoire pour que ça n'arrive pas.

• Use Memory Locking : verrouille le modèle en mémoire pour empêcher le swap. Peut améliorer les performances, mais exige assez de mémoire disponible.

La façon dont les poids sont lus sur le disque est elle aussi un choix. Le memory mapping laisse le système les charger au fil des besoins plutôt que de tout monter en RAM d'un coup.

• Use Memory Mapping : utilise le memory mapping pour charger le modèle. Réduit l'usage mémoire mais peut affecter les performances. Recommandé activé.

Parfois, les poids ne sont pas le sujet. Charger le seul vocabulaire les saute entièrement : c'est rapide, et ça ne produit aucune vraie complétion.

• Load Vocabulary Only : charge uniquement le vocabulaire du modèle, sans les poids. Utile pour tester rapidement la tokenisation.

La forme de la réponse de l'API se choisit, et ça compte dès que le nœud suivant attend des données structurées plutôt qu'un texte à décortiquer.

• Output Format : format de la réponse de l'API, au choix default (Default) ou json (JSON).