Auto-héberger Ollama sur un serveur LLM et prendre le contrôle de la censure de l’IA

Mots-clés

Avant de commencer la configuration, voici les termes les plus susceptibles de confondre les lecteurs dans ce guide. Ce glossaire rapide garde la vocabulaire Linux, GPU et modèle local clair dès le départ.

Pourquoi l’auto-hébergement d’un LLM en vaut la peine

Si vous avez déjà fait la partie difficile — loué un serveur GPU, installé Ubuntu, appris à naviguer SSH, et maintenu vos propres services en fonctionnement — cela devient frustrant rapidement quand une IA hébergée contrôle toujours le dernier kilomètre. Elle peut refuser une demande tout à fait ordinaire, enterrer la réponse sous des avertissements, changer le style de réponse sans préavis, et garder chaque prompt circulant à travers les limites de quelqu’un d’autre. Pour beaucoup d’utilisateurs techniques, c’est la vraie frustration : non seulement ce que dit le modèle, mais qui contrôle la couche de service quand il le dit.

Ce guide parle de corriger cela avec des modèles ouverts et locaux, pas de trucs de contournement pour les API propriétaires. Vous allez auto-héberger Ollama sur un serveur GPU Ubuntu, exécuter l’inférence localement, vérifier que le chemin GPU est réel, et voir ce qui change quand vous choisissez une famille de modèles différente. Une idée fausse à clarifier dès le départ : auto-hébergé ne signifie pas automatiquement sans restriction. Cela signifie que vous contrôlez beaucoup plus de la pile — et vous arrêtez de dépendre d’un chemin de service contrôlé par un fournisseur — mais le modèle que vous exécutez peut toujours avoir son propre comportement d’alignement.

📝 Remarque : Les commandes de ce guide sont validées par rapport à la documentation Ollama actuelle, mais les sorties de terminal affichées ci-dessous sont des exemples représentatifs plutôt que des captures de benchmark en direct. Utilisez-les comme modèle de succès, pas comme affirmation de performance.

À la fin, vous aurez un service Ollama fonctionnant sur Ubuntu, une API locale vérifiée à 127.0.0.1:11434, la preuve que l’inférence GPU est réellement en cours, et une comparaison fondée entre un modèle aligné grand public et une alternative moins restreinte. Ce tutoriel est écrit pour les lecteurs qui sont à l’aise avec SSH, Ubuntu, sudo, et systemd, mais qui n’ont pas besoin d’expérience préalable avec Ollama.

Le serveur GPU Ubuntu exact utilisé pour ce guide

Cette procédure pas à pas s’appuie sur une véritable machine Ubuntu à GPU unique, car les conseils vagues du type « devrait fonctionner sur la plupart des serveurs » sont la raison pour laquelle les guides d’auto-hébergement deviennent trompeurs. La boîte de référence ici est la classe réelle d’hôte utilisée pour ce guide : le type de machine qu’un individu avancé, un laboratoire ou une petite équipe louerait réellement lorsqu’il souhaite une inférence locale privée sans passer directement à un rack d’accélérateurs d’entreprise. Il discutera toujours du comportement multi-GPU plus tard, car Ollama change une fois qu’un modèle dépasse une carte, mais traitez cette partie comme un contexte tourné vers l’avenir plutôt que comme une preuve de ce serveur exact.

Serveur GPU — Ryzen 9 3950X + RTX 4070 Ti Super

En pratique, c’est une configuration très puissante pour les modèles de classe 8B au quotidien et toujours utile pour les travaux locaux plus importants jusqu’au point où 16GB de VRAM devient la véritable contrainte. Un modèle comme llama3.1:8b d’environ 4.9GB s’adapte facilement sur cette carte. Un modèle comme gpt-oss:20b d’environ 14GB est le type de test GPU unique haut de gamme qui a toujours du sens ici. Un modèle comme qwen3:30b d’environ 19GB est mieux traité comme un point de référence pour ce qui change sur un hôte plus grand ou dual-GPU que comme un ajustement propre pour cette machine exacte.

Cette distinction est importante car le point de cet article n’est pas de forcer le plus grand nombre possible dans un titre. Il s’agit de montrer à quoi ressemble un serveur LLM auto-hébergé sensé lorsque vous souhaitez la confidentialité, le contrôle local et suffisamment de mémoire GPU pour exécuter des modèles utiles sans compromis constant. Cette classe de matériel est l’endroit où l’inférence auto-hébergée devient réaliste, pas théorique.

Cela explique également quelques choix que vous verrez plus tard : mistral est utilisé en premier car il fournit une preuve rapide et sans friction que la pile fonctionne, tandis que la comparaison de comportement reste dans la classe 8B où cette machine est à l’aise. qwen3:30b apparaît toujours plus tard, mais comme un exemple théorique du type de modèle qui peut déclencher un placement multi-GPU sur un hôte plus grand plutôt que comme une preuve en direct de ce serveur. Avec les attentes définies, l’étape suivante consiste à valider l’hôte avant qu’Ollama ne le touche.

Exécutez Ces Vérifications Préalables à l’Installation Avant de Toucher à Ollama

Commencez par nvidia-smi. Si cette commande est manquante ou échoue, arrêtez-vous là et corrigez d’abord le pilote NVIDIA. N’installez pas Ollama pour le moment, car une pile NVIDIA cassée rendra chaque symptôme ultérieur ressemblant à une défaillance d’application alors qu’il s’agit réellement d’une défaillance de plateforme.

Exécutez d’abord la vérification du GPU :

nvidia-smi

❗Si Ubuntu dit que nvidia-smi est manquant, ne supposez pas que le serveur n’a pas de GPU. Un mode de défaillance courant sur les boîtes Ubuntu louées est que la carte est présente mais toujours liée à nouveau au lieu du pilote NVIDIA. Consultez d’abord la section « Corriger le Problème du Pilote Nvidia sur Ubuntu ».

Un résultat sain sur cette classe de serveur devrait ressembler à peu près à ceci :

Une fois que nvidia-smi fonctionne et que le GPU est visible, continuez avec les vérifications ci-dessous.

Ce que vous voulez confirmer est simple : le GPU installé est visible, il rapporte environ 16GB de VRAM sur cet hôte, et le pilote est chargé correctement. Si vous êtes sur un serveur multi-GPU, la même commande devrait lister chaque carte.

nvidia-smi -L

❗ Important : La documentation actuelle du support GPU d’Ollama utilise le pilote NVIDIA 531+ comme véritable plancher pour l’inférence NVIDIA prise en charge. Traitez 531+ comme l’exigence pour ce guide, même si vous avez vu d’anciennes notes communautaires citant des versions antérieures.

Confirmez maintenant que l’hôte est vraiment l’environnement Ubuntu que ce guide suppose :

lsb_release -a

Enfin, vérifiez l’espace disque libre avant de commencer à télécharger des modèles. L’installation elle-même est petite ; les modèles ne le sont pas. Une fois que vous allez au-delà de petits tests, une bibliothèque de 20B-30B peut consommer des dizaines de gigaoctets rapidement, donc 100GB+ libre est la bonne mentalité avant un travail sérieux avec des modèles locaux.

df -h /

Si ces vérifications réussissent, vous avez éliminé les principales inconnues d’infrastructure : les GPU sont présents, la ligne de base du pilote est saine, Ubuntu est confirmé, et le disque a de la place pour les téléchargements de modèles réels. C’est le point où l’installation d’Ollama devient une étape suivante claire au lieu d’une supposition.

Corriger le Problème du Pilote Nvidia sur Ubuntu

Suivez les étapes ci-dessous pour corriger les problèmes avec la commande « nvidia-smi ».

lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

Si cette sortie affiche une carte NVIDIA et une ligne telle que Kernel driver in use: nouveau, installez le package de pilote Ubuntu recommandé au lieu d’installer nvidia-utils seul.

Installez le package ubuntu-drivers-common (nécessaire pour la gestion des pilotes) et les en-têtes du noyau pour votre noyau actuellement en cours d’exécution.

apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)

Analysez votre système et listez les pilotes propriétaires disponibles (par exemple, les pilotes GPU NVIDIA) qui peuvent être installés.

ubuntu-drivers devices

Ensuite, installez le package de pilote recommandé. Dans notre cas, c’était : nvidia-driver-595-open :

apt install -y nvidia-driver-595-open
reboot

Après le redémarrage, réexécutez :

nvidia-smi
nvidia-smi -L

Installer Ollama et Confirmer que le Service est Sain

Le chemin Ubuntu supporté est l’installateur officiel Ollama, pas un flux tarball personnalisé et pas un détour Docker. Cela importe parce que ce guide concerne l’obtention d’un service local fiable avec des paramètres par défaut prévisibles, l’intégration systemd et un comportement de propriété sensé sur Linux.

Exécutez l’installateur exactement comme documenté :

curl -fsSL https://ollama.com/install.sh | sh

Sur un système sain, le script installe le binaire, crée l’utilisateur du service ollama, ajoute les bonnes appartenances de groupe si disponibles, écrit l’unité systemd et démarre le service lié à 127.0.0.1:11434.

Une fois le script terminé, validez le service au lieu de supposer le succès :

sudo systemctl status ollama --no-pager

Vous cherchez trois choses ici : le fichier d’unité est présent, le service est activé au démarrage, et Active: active (running) confirme que le serveur est réellement en cours d’exécution.

D’abord, établissez le compte utilisateur du service Linux de manière concrète, et seulement après pensez à comment et où le stockage du modèle sera géré.

getent passwd ollama

Cette seule ligne explique beaucoup de comportements futurs. Les modèles sur Linux vivent sous la propriété du service, et si vous les déplacez ultérieurement vers un autre disque sans corriger les permissions pour l’utilisateur ollama, vous créez votre propre cassure.

Une dernière vérification ferme la boucle sur la liaison par défaut :

ss -tlnp | grep 11434

⚠️ Avertissement : Ollama ne nécessite pas d’authentification sur l’API locale par défaut. C’est correct quand il est lié à 127.0.0.1, mais ce n’est pas sûr d’exposer le port 11434 directement à Internet comme s’il s’agissait d’un service public renforcé.

Si le service ne démarre pas correctement, allez d’abord aux journaux au lieu de réinstaller aveuglément :

journalctl -u ollama -n 100 --no-pager

C’est le moyen le plus rapide de détecter les problèmes de permissions, les erreurs de démarrage, les problèmes de détection de pilotes ou les problèmes de liaison. Une fois que le service est sain sur localhost, la prochaine chose à comprendre est comment le placement GPU se comporte à l’exécution.

Comment Ollama utilise réellement un ou plusieurs GPU

Même si le serveur utilisé pour ce guide n’a qu’un GPU, il vaut quand même la peine de comprendre le comportement multi-GPU car de nombreux utilisateurs peuvent avoir des machines plus grandes ou vouloir s’étendre plus tard. Beaucoup de confusion avec deux GPU commence par une mauvaise attente : « J’ai deux cartes, donc les deux devraient s’allumer tout le temps. » Ce n’est pas ainsi qu’Ollama fonctionne. La règle pratique est beaucoup plus simple : si un modèle tient sur un GPU, Ollama le gardera généralement sur un GPU. Il ne se propage sur plusieurs GPU que lorsque le modèle ne tient pas confortablement sur une seule carte.

Utilisez ces deux vérifications ensemble chaque fois que vous voulez voir les performances du GPU :

ollama ps

watch -n 1 nvidia-smi

ollama ps vous indique comment le modèle chargé est traité. 100% GPU signifie que le modèle réside entièrement dans la mémoire GPU. 100% CPU signifie que l’accélération GPU n’est pas utilisée. Un état mixte vous indique qu’une partie de la charge de travail ou de la résidence s’est déversée en dehors du chemin GPU. watch -n 1 nvidia-smi complète cela en affichant l’utilisation en direct de la VRAM par carte pendant que le modèle est chargé.

Le moyen le plus rapide de garder ces rôles droits est celui-ci :

📝 Note : CUDA_VISIBLE_DEVICES est un contrôle de visibilité, pas un commutateur « utiliser les deux GPU ». Si vous limitez jamais l’accès au GPU, préférez les UUID de nvidia-smi -L aux ID numériques car l’ordre des GPU peut varier entre les environnements et les redémarrages.

Exécutez votre premier modèle local et vérifiez l’inférence GPU

À ce stade, vous n’avez pas besoin d’un modèle géant pour prouver que le serveur fonctionne. Vous avez besoin d’une réussite rapide et honnête. mistral est un bon premier pull car il est petit, rapide à télécharger et facile à charger, même si llama3.1:8b sera la ligne de base ultérieure pour la comparaison des comportements.

Commencez par extraire le modèle :

ollama pull mistral

Maintenant, exécutez une petite invite à travers celui-ci pour que la machine fasse quelque chose d’utile, pas seulement administratif. La réponse peut prendre quelques secondes.

ollama run mistral "In one sentence, explain why people self-host LLMs."

Pour prouver qu’il s’agit d’une inférence soutenue par GPU plutôt qu’une solution de secours CPU, vérifiez l’état d’exécution :

ollama ps

Et pour voir ce qui se trouve déjà sur le disque, listez l’inventaire local :

ollama list

mistral est le bon premier test car il vous donne une réponse rapide sans transformer la validation de configuration en une longue attente. Plus tard, llama3.1:8b devient plus utile car il est une ligne de base alignée plus forte pour comparer le comportement des modèles.

Enfin, vérifiez où l’installation Linux stocke les modèles :

sudo du -sh /usr/share/ollama/.ollama/models

Ce chemin — /usr/share/ollama/.ollama/models — est le magasin de modèles Linux standard documenté par Ollama.

Une fois que vous voyez une réponse réussie, 100% GPU dans ollama ps, et l’utilisation du disque augmente à l’emplacement attendu, vous avez la première preuve significative que la pile locale fonctionne.

Prouver que c’est un serveur, pas seulement un wrapper CLI

Une invite de commande est agréable, mais la raison d’auto-héberger Ollama n’est pas seulement de discuter dans un terminal. C’est d’exécuter un serveur d’inférence local que d’autres outils, scripts et applications peuvent appeler sans envoyer des invites via la limite API de quelqu’un d’autre. La preuve la plus rapide est une seule requête HTTP propre au point de terminaison Ollama natif.

Envoyez une demande de génération locale avec le streaming désactivé pour que la première réponse soit facile à inspecter :

curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'

Une réponse réussie devrait revenir en JSON et ressembler à peu près à ceci :

{
  "model": "mistral",
  "created_at": "2026-05-13T12:45:12.000000Z",
  "response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
  "done": true,
  "done_reason": "stop",
  "total_duration": 812345678,
  "load_duration": 12345678,
  "prompt_eval_count": 14,
  "eval_count": 12
}

La liste de contrôle de succès est simple : la requête HTTP fonctionne localement, un JSON valide revient, done: true est présent, et la réponse du modèle est dans response. C’est le moment où Ollama cesse d’être « une CLI qui télécharge des modèles » et devient une infrastructure que vous pouvez réellement intégrer dans des outils locaux et de l’automatisation.

Si vous voulez la compatibilité avec les logiciels qui s’attendent à une forme de requête de style OpenAI, Ollama expose également les points de terminaison /v1 localement :

curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'

📝 Note : Ce label « compatible avec OpenAI » est facile à mal interpréter. Cela ne signifie pas que vous parlez à OpenAI, et cela ne change pas le fait que le serveur est toujours local. Cela signifie seulement que la forme de la requête est suffisamment familière pour les outils et SDK construits autour du modèle API OpenAI. L’URL de base reste http://localhost:11434/v1/, et toute clé API d’espace réservé que certaines bibliothèques clientes insistent pour avoir peut être ignorée pour l’utilisation locale d’Ollama.

D’où viennent réellement les restrictions des modèles

C’est la partie qui est généralement aplatie en une seule idée vague de « censure », mais techniquement il y a trois couches différentes impliquées : la couche de service du fournisseur, l’alignement du modèle et le réglage des instructions, et le comportement du prompt/runtime que vous contrôlez vous-même. L’auto-hébergement change certaines de ces couches de manière drastique. Il ne les efface pas toutes.

Un moyen simple de le visualiser est celui-ci :

Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response

Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response

Résultats :
– La couche de service contrôlée par le fournisseur disparaît du chemin local
– La limite du réseau local et de la journalisation devient la vôtre
– L’entraînement et l’alignement propres du modèle viennent toujours avec le modèle

Une fois que vous séparez les couches, les étapes de configuration antérieures deviennent beaucoup plus significatives :

Vous pouvez le voir comme une production théâtrale. L’auto-hébergement change la scène, l’éclairage, les microphones et les notes du réalisateur. Il ne réentraîne pas l’acteur. Si un modèle a été réglé pour répondre avec prudence, se couvrir souvent ou refuser certains types de formulation, l’exécuter localement n’annulera pas magiquement cet entraînement.

Ce que votre configuration actuelle a déjà prouvé est plus étroit, mais toujours important : vous contrôlez le processus serveur, vous contrôlez la limite de l’API, et vous ne routez plus les invites locales via une couche de modération appartenant à un fournisseur. C’est un vrai changement en matière de confidentialité et de contrôle. Ce qu’il n’a pas prouvé, c’est que chaque modèle local se comportera de la même manière ou que chaque refus à l’avenir a été causé par un fournisseur de cloud.

C’est là que le choix du modèle intervient. Si vous voulez l’effet pratique de moins de clauses de non-responsabilité, de réponses plus directes ou d’un comportement moins lourd en refus, vous n’y arrivez pas en disant « auto-hébergé » plus fort. Vous y arrivez en choisissant une famille de modèles ou un fine-tune différent — et en comprenant les compromis qui en découlent.

Choisir un modèle local moins restreint

Si vous voulez un test équitable, comparez des modèles qui occupent à peu près la même classe de taille. C’est pourquoi ce guide utilise llama3.1:8b comme référence alignée mainstream et dolphin3 comme modèle de comparaison moins restreint. Ils font tous les deux environ 4.9GB, ce qui rend la différence de comportement plus facile à interpréter sans non plus modifier l’empreinte matérielle de manière trop drastique.

Tirez les modèles de comparaison localement :

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

Voici le cadre pratique pour les trois noms que vous êtes le plus susceptible de voir dans cette partie de l’écosystème Ollama :

⚠️ Avertissement : Un fine-tune différent n’est pas « le même modèle avec la censure supprimée ». Il peut modifier la directivité, la densité des avertissements et la volonté de suivre le cadrage de l’utilisateur, mais il peut aussi modifier le ton, la factualité, la cohérence et la personnalité générale.

Performance GPU

Avant d’exécuter les modèles souhaités, il est d’abord essentiel de comprendre les possibilités et les limitations du matériel impliqué. Il y a donc deux choses à tester conceptuellement : d’abord, à quoi ressemble le comportement propre d’un seul GPU sur le matériel réel utilisé pour ce guide ; ensuite, ce qui change si vous exécutez ultérieurement la même pile sur un hôte à deux GPU. Les deux sont importants, mais seul le premier est une preuve en direct de cette machine exacte.

Sur ce serveur, le meilleur test d’exécution haut de gamme est gpt-oss:20b. Il est suffisamment volumineux pour être intéressant tout en ayant du sens sur une carte 16GB.

ollama pull gpt-oss:20b

ollama stop mistral

ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

Une fois le modèle chargé, confirmez l’état d’exécution :

ollama ps

C’est la preuve pratique que vous voulez sur cette machine. Elle montre que les modèles plus petits s’adaptent facilement et qu’un modèle local plus volumineux mais toujours réaliste peut pousser une carte 16GB près de son enveloppe utilisable sans avoir besoin de plusieurs GPU.

Si vous exécutez ultérieurement Ollama sur un hôte à deux GPU, un modèle tel que qwen3:30b devient le type de charge de travail qui peut démontrer le placement multi-GPU. Le flux de travail est le même — regardez nvidia-smi, exécutez le modèle, inspectez ollama ps — mais l’objectif n’est pas de faire briller les deux cartes pour son propre compte. L’objectif est de confirmer qu’Ollama ne répartit un modèle sur plusieurs GPU que lorsque le modèle ne s’adapte plus correctement sur un seul.

Considérations sur le contournement de la censure

Pour la comparaison comportementale, maintenez les conditions contrôlées afin de tester le modèle plutôt que l’aléatoire. Utilisez le même endpoint, la même invite, stream: false, une température basse et une graine fixe :

curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'

Répétez ensuite la même requête avec “model”: “dolphin3”. Une graine fixe n’élimine pas toute variance, mais elle réduit suffisamment l’aléatoire pour que les différences de ton et de conformité soient plus faciles à voir.

1. Une première invite sûre est : « L’auto-hébergement d’un LLM signifie-t-il que l’utilisateur contrôle pleinement le comportement du modèle ? Répondez en 4 points. Soyez direct et ignorez les préambules. » Une réponse représentative de llama3.1:8b tend à sonner comme ceci :

   - Self-hosting gives you more control over deployment, privacy, and availability.
   - It does not automatically remove the model's built-in alignment behavior.
   - The model may still refuse or soften some responses depending on its training.
   - Full control comes from combining self-hosting with careful model selection and configuration.

   Une réponse représentative de dolphin3 à la même invite sonne souvent plus épurée :

   - You control the machine, the network boundary, and the serving layer.
   - You do not erase the model's training history just by running it locally.
   - Vendor-side policy can disappear, but model-side alignment can still remain.
   - Real control comes from choosing a model whose behavior matches your use case.

2. Une deuxième invite utile est : « Écrivez un argument percutant en cinq phrases expliquant pourquoi une équipe sensible à la confidentialité pourrait rejeter une IA gérée par un fournisseur. Pas d’introduction et pas de conclusion. » llama3.1:8b se conforme généralement, mais sur un ton corporatif plus mesuré. dolphin3 suit plus volontiers la netteté demandée. C’est le type de différence que vous recherchez ici : pas une sortie dramatiquement sans loi, mais des changements en directivité, cadrage et densité de clauses de non-responsabilité.
3. La troisième catégorie d’invite pour la validation peut être la suivante : demander cinq raisons factuelles pour lesquelles un écrivain pourrait préférer un modèle local pour un travail créatif inhabituel, de niche ou non-dominant. En pratique, les deux modèles répondent, mais dolphin3 tend à rester plus proche du ton non-moralisateur demandé et des réponses directes.

Le motif ressemble à ceci :

Et ainsi, voici les conclusions honnêtes :

1. Le choix du modèle local change significativement le comportement de sortie.
2. Les différents modèles varient en directivité et densité de clauses de non-responsabilité.
3. L’auto-hébergement supprime une couche de service contrôlée par le fournisseur.

Vous contrôlez maintenant la pile, pas seulement l’invite

La frustration du début de ce guide ne portait jamais uniquement sur un modèle refusant une demande. C’était le fait que la couche de service, la couche de politique et la limite de confidentialité se trouvaient ailleurs. Après cette configuration, cela a changé. Votre serveur d’inférence s’exécute sur votre machine Ubuntu, la limite API locale est la vôtre, le menu des modèles est le vôtre, et vos paramètres par défaut d’invite/runtime sont les vôtres à ajuster.

Ce qui nécessite encore du jugement est la partie qu’aucun installateur ne peut résoudre pour vous : choisir des modèles qui correspondent à votre cas d’usage, les diriger avec des paramètres par défaut sensés, et exposer l’accès de manière sécurisée si vous allez au-delà de localhost. C’est la véritable forme du contrôle de l’auto-hébergement. Pas une liberté magique de toute restriction, mais la propriété de la pile qui décide comment, où et avec quel modèle l’inférence se produit. Si vous voulez la meilleure étape suivante, commencez par créer un Modelfile personnalisé — ou en mettant un accès à distance sécurisé devant l’API locale quand vous êtes prêt.

Que faire après la configuration de base

À ce stade, la promesse fondamentale est tenue. Le serveur fonctionne, l’API fonctionne, le chemin GPU est réel, et les différences de comportement du modèle ne sont plus abstraites. Le prochain mouvement n’est pas « installer plus de choses à l’aveugle ». Il s’agit d’affiner les parties de la pile qui vous appartiennent maintenant.

Personnaliser le comportement du modèle avec un Modelfile

Un Modelfile est le moyen le plus propre de modifier les paramètres par défaut d’invite locale sans toucher aux poids du modèle lui-même. Commencez par inspecter la définition actuelle du modèle pour comprendre ce que vous étendez :

ollama show --modelfile dolphin3

Ensuite, créez une simple variation locale :

FROM dolphin3

SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server. 
Prefer short, practical answers and avoid padded disclaimers.

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

Construisez-la sous un nouveau nom de modèle et testez-la :

ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."

❗ Important : Un Modelfile modifie le comportement d’invite et d’exécution, pas l’historique d’entraînement du modèle. Il peut orienter le ton et les paramètres par défaut, mais il ne réentraîne pas le modèle sous-jacent.

Sécuriser la configuration

La liaison localhost est un bon paramètre par défaut, mais ce n’est pas la fin de l’histoire de sécurité. Revérifiez d’abord l’adresse d’écoute actuelle :

ss -tlnp | grep 11434

Si l’objectif est de garder Ollama local uniquement, épinglez ce comportement explicitement avec un remplacement systemd :

sudo systemctl edit ollama

Ajoutez ce qui suit :

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Ensuite, rechargez et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart ollama

Si vous avez besoin d’un accès distant plus tard, ne publiez pas 11434 directement. Mettez plutôt un proxy inverse avec TLS et authentification devant :

server {
    listen 443 ssl http2;
    server_name llm.example.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

⚠️ Avertissement : Traitez l’exposition publique comme un projet de durcissement distinct. Ollama en soi est un serveur d’inférence local, pas une passerelle API prête pour la production avec authentification intégrée, limitation de débit et paramètres par défaut accessibles sur Internet.

Modèles recommandés pour ce matériel

Une fois que l’installation de base fonctionne, l’amélioration de plus grande valeur est de choisir des modèles qui s’adaptent réellement bien à cette machine au lieu de poursuivre les plus grands titres. Pour le serveur single-4070 Ti SUPER utilisé ici, le menu pratique ressemble à ceci :

Démarrage automatique et maintenance

Après la partie amusante vient la partie qui garde un serveur LLM local utilisable un mois à partir de maintenant. Confirmez le comportement au démarrage, maintenez le service à jour, surveillez les journaux et sachez comment décharger les grands modèles quand vous avez besoin de la VRAM.

sudo systemctl is-enabled ollama

sudo systemctl enable --now ollama

curl -fsSL https://ollama.com/install.sh | sh

journalctl -u ollama -n 100 --no-pager

Pour les opérations quotidiennes de modèle, voici les commandes que vous utiliserez le plus souvent :

ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/models

Et si le stockage de modèles doit se déplacer vers un disque plus grand, préparez le répertoire pour l’utilisateur du service avant de réorienter Ollama :

sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-models

Ensuite, définissez OLLAMA_MODELS via systemctl edit ollama. Ce détail de propriété unique est ce qui empêche une migration de stockage de se transformer en problème de permissions.

Référence de dépannage

Quand quelque chose se casse, le chemin le plus rapide est généralement de faire correspondre le symptôme à la bonne couche au lieu d’essayer des boucles de réinstallation aléatoires. Utilisez ce tableau comme première passe :

Si vous ne vous souvenez que d’une seule règle opérationnelle de cette section, que ce soit celle-ci : traitez Ollama comme un vrai service, pas comme un utilitaire CLI jetable. Les journaux, la propriété, les adresses de liaison et les chemins de stockage sont tout aussi importants que la fenêtre d’invite.