Hébergez Ollama sur un serveur LLM et prenez le contrôle sur la censure de l’IA

Mots-clés

Avant de plonger dans la configuration, voici les termes qui risquent le plus de dérouter les lecteurs dans ce guide. Ce glossaire rapide clarifie d’emblée le vocabulaire lié à Linux, GPU et aux modèles locaux.

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

Si vous avez déjà accompli la partie difficile — loué le serveur GPU, installé Ubuntu, appris à naviguer dans SSH et maintenu vos propres services en fonctionnement — il devient vite frustrant qu’une IA hébergée contrôle encore le dernier kilomètre. Elle peut refuser une demande parfaitement ordinaire, noyer la réponse sous des avertissements, changer de style de réponse sans prévenir, et faire transiter chaque prompt par la frontière de quelqu’un d’autre. Pour beaucoup d’utilisateurs techniques, c’est là la vraie frustration : pas seulement ce que dit le modèle, mais qui contrôle la couche de service lorsqu’il le dit.

Ce guide traite de résoudre ce problème avec des modèles ouverts et locaux, et non de contournements pour les API propriétaires. Vous auto-hébergerez Ollama sur un serveur GPU Ubuntu, exécuterez l’inférence localement, vérifierez que le chemin GPU est réel, et observerez ce qui change lorsque vous choisissez une famille de modèles différente. Une idée reçue à dissiper dès le début : auto-hébergé ne signifie pas automatiquement sans restriction. Cela signifie que vous contrôlez beaucoup plus de la pile — et que vous cessez de dépendre d’un chemin de service contrôlé par un fournisseur — mais le modèle que vous exécutez peut toujours porter 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 présentées ci-dessous sont des exemples représentatifs plutôt que des captures de benchmarks en direct. Utilisez-les comme modèle de réussite, non comme affirmation de performance.

À la fin, vous disposerez d’un service Ollama fonctionnel sur Ubuntu, d’une API locale vérifiée à 127.0.0.1:11434, de la preuve que l’inférence accélérée par GPU se produit réellement, et d’une comparaison fondée entre un modèle aligné grand public et une alternative moins restrictive. Ce tutoriel est rédigé pour des lecteurs à 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 présentation est ancrée dans une vraie machine Ubuntu mono-GPU, car les conseils vagues du type « devrait fonctionner sur la plupart des serveurs » sont la façon dont les guides d’auto-hébergement deviennent trompeurs. La machine de référence ici est la classe d’hôte réelle utilisée pour ce guide : le type de machine qu’un individu avancé, un laboratoire ou une petite équipe louerait réellement pour une inférence locale privée sans passer directement à un rack d’accélérateurs professionnels. Il sera question plus tard du comportement multi-GPU, car Ollama change dès qu’un modèle dépasse les capacités d’une seule carte, mais considérez cette partie comme un contexte prospectif plutôt que comme une preuve issue de ce serveur exact.

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

En pratique, il s’agit d’une configuration très solide pour les modèles de classe 8B du quotidien et encore utile pour les travaux locaux plus importants jusqu’au point où 16GB de VRAM devient la vraie contrainte. Un modèle comme llama3.1:8b à environ 4,9GB tient facilement sur cette carte. Un modèle comme gpt-oss:20b à environ 14GB est le type de test mono-GPU haut de gamme qui reste pertinent ici. Un modèle comme qwen3:30b à environ 19GB est mieux traité comme un point de référence pour ce qui change sur un hôte plus grand ou bi-GPU que comme un ajustement parfait pour cette machine exacte.

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

Cela explique également quelques choix que vous verrez plus tard : mistral est utilisé en premier car il constitue 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 tout de même plus tard, mais comme exemple théorique du type de modèle pouvant déclencher un placement multi-GPU sur un hôte plus grand plutôt que comme preuve en direct de ce serveur. Les attentes étant fixées, l’étape suivante consiste à valider l’hôte avant qu’Ollama n’y touche.

Effectuez ces vérifications préalables 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 encore Ollama, car une pile NVIDIA défectueuse fera ressembler chaque symptôme ultérieur à un échec d’application alors qu’il s’agit en réalité d’un échec de plateforme.

Effectuez d’abord la vérification du GPU :

❗Si Ubuntu indique que nvidia-smi est manquant, ne supposez pas que le serveur n’a pas de GPU. Un mode d’échec courant sur les machines 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 de pilote Nvidia sur Ubuntu ».

Un résultat correct sur cette classe de serveur devrait ressembler approximativement à ceci :

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

Ce que vous souhaitez confirmer est simple : le GPU installé est visible, il signale 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.

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

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

Enfin, vérifiez l’espace disque disponible 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 dépassez les petits tests, une bibliothèque de 20B à 30B peut rapidement consommer des dizaines de gigaoctets, donc avoir 100GB+ libres est le bon état d’esprit avant un vrai travail avec des modèles locaux.

Si ces vérifications réussissent, vous avez éliminé les principales inconnues d’infrastructure : les GPU sont présents, la base du pilote est saine, Ubuntu est confirmé, et le disque a de la place pour de vraies récupérations de modèles. C’est le moment où l’installation d’Ollama devient une prochaine étape propre plutôt qu’une conjecture.

Corriger le problème de pilote Nvidia sur Ubuntu

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

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.

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

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

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

Installer Ollama et confirmer que le service est en bonne santé

La méthode Ubuntu prise en charge est le programme d’installation officiel d’Ollama, et non un flux de tarball personnalisé ni un détour par Docker. C’est important car ce guide vise à obtenir un service local fiable avec des paramètres par défaut prévisibles, une intégration systemd et un comportement de propriété sain sous Linux.

Exécutez le programme d’installation exactement tel que documenté :

Sur un système en bon état, le script installe le binaire, crée l’utilisateur de service ollama, ajoute les appartenances aux groupes appropriées lorsque disponibles, écrit l’unité systemd et démarre le service lié à 127.0.0.1:11434.

Une fois le script terminé, validez le service plutôt que de supposer son succès :

Vous recherchez trois éléments ici : le fichier d’unité est présent, le service est activé au démarrage, et Active: active (running) confirme que le serveur est effectivement opérationnel.

Commencez par établir le compte utilisateur de service Linux de manière concrète, et pensez seulement ensuite à la façon dont et à l’endroit où le stockage des modèles sera géré.

Cette seule ligne explique beaucoup de comportements futurs. Les modèles sous 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 panne.

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

⚠️ Avertissement : Ollama ne requiert pas d’authentification sur l’API locale par défaut. C’est acceptable lorsqu’il est lié à 127.0.0.1, mais il 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, consultez d’abord les journaux plutôt que de réinstaller aveuglément :

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 des pilotes ou les problèmes de liaison. Une fois que le service est opérationnel sur localhost, la prochaine chose à comprendre est le comportement du placement GPU lors de l’exécution.

Comment Ollama utilise réellement un ou plusieurs GPU

Même si le serveur utilisé pour ce guide ne dispose que d’un seul GPU, le comportement multi-GPU vaut tout de même la peine d’être compris car de nombreux utilisateurs peuvent se trouver sur des machines plus grandes ou envisager une expansion ultérieure. Beaucoup de confusion avec deux GPU commence par une mauvaise attente : « J’ai deux cartes, donc les deux devraient s’allumer en permanence. » Ce n’est pas ainsi que fonctionne Ollama. La règle pratique est bien plus simple : si un modèle tient sur un GPU, Ollama le gardera généralement sur un seul GPU. Il ne se répartit 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 souhaitez observer les performances GPU :

ollama ps vous indique comment le modèle chargé est traité. 100% GPU signifie que le modèle est entièrement résidant en 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 a débordé en dehors du chemin GPU. watch -n 1 nvidia-smi complète cela en affichant l’utilisation de la VRAM en temps réel par carte pendant que le modèle est chargé.

La façon la plus rapide de garder ces rôles distincts est la suivante :

📝 Remarque : CUDA_VISIBLE_DEVICES est un contrôle de visibilité, pas un interrupteur « utiliser les deux GPU ». Si vous devez jamais contraindre l’accès GPU, préférez les UUID de nvidia-smi -L aux identifiants 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 gigantesque pour prouver que le serveur fonctionne. Vous avez besoin d’un succès rapide et honnête. mistral est un bon premier choix car il est petit, rapide à télécharger et facile à charger, même si llama3.1:8b sera la base de référence ultérieure pour la comparaison de comportement.

Commencez par récupérer le modèle :

Exécutez maintenant un petit prompt afin que la machine fasse quelque chose d’utile, et non juste administratif. La réponse peut prendre quelques secondes.

Pour prouver qu’il s’agit d’une inférence accélérée par GPU plutôt que d’un repli sur CPU, vérifiez l’état d’exécution :

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

mistral est la bonne première preuve car il vous donne une réponse rapide sans transformer la validation de la configuration en une longue attente. Par la suite, llama3.1:8b devient plus utile car il constitue une base alignée plus solide pour comparer le comportement des modèles.

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

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 augmentant à l’emplacement prévu, vous avez la première preuve significative que la pile locale fonctionne.

Prouvez que c’est un serveur, pas juste un wrapper CLI

Un prompt en ligne de commande, c’est bien, mais la raison d’auto-héberger Ollama n’est pas uniquement 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 de prompts à travers la frontière API de quelqu’un d’autre. La preuve la plus rapide est une requête HTTP propre vers le point de terminaison natif d’Ollama.

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

Une réponse réussie devrait revenir en JSON et ressembler approximativement à 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 vérification du succès est simple : la requête HTTP fonctionne localement, du 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 « un 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 souhaitez une compatibilité avec des logiciels qui attendent une forme de requête de style OpenAI, Ollama expose également des points de terminaison /v1 localement :

📝 Remarque : Cette étiquette « compatible OpenAI » est facile à mal interpréter. Elle ne signifie pas que vous parlez à OpenAI, et elle 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 les SDK construits autour du modèle d’API OpenAI. L’URL de base reste http://localhost:11434/v1/, et toute clé API fictive sur laquelle certaines bibliothèques clientes insistent peut être ignorée pour une utilisation locale d’Ollama.

D’où viennent vraiment les restrictions des modèles

C’est la partie qui est généralement réduite à une vague idée de « censure », mais techniquement il y a trois couches différentes impliquées : la couche de service du fournisseur, l’alignement et le réglage d’instruction du modèle, et le comportement du prompt/d’exécution que vous contrôlez vous-même. L’auto-hébergement modifie certaines de ces couches de façon spectaculaire. Il ne les efface pas toutes.

Une façon simple de le visualiser est la suivante :

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 frontière réseau et de journalisation devient la vôtre
– L’entraînement et l’alignement propres du modèle accompagnent toujours le modèle

Une fois les couches séparées, les étapes de configuration précédentes deviennent bien plus significatives :

Vous pouvez y penser comme à une production théâtrale. L’auto-hébergement change la scène, l’éclairage, les microphones et les notes du metteur en scène. Il ne réentraîne pas l’acteur. Si un modèle a été ajusté pour répondre prudemment, hésiter souvent ou refuser certains types de formulations, 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 frontière API, et vous n’acheminez plus les prompts locaux via une couche de modération appartenant à un fournisseur. Il s’agit d’un vrai changement en matière de confidentialité et de contrôle. Ce qu’elle n’a pas prouvé, c’est que chaque modèle local se comportera de la même façon ou que chaque refus futur aura été causé par un fournisseur cloud.

C’est là qu’intervient le choix du modèle. Si vous souhaitez l’effet pratique de moins d’avertissements, de réponses plus directes ou d’un comportement moins axé sur le refus, vous n’y parvenez pas en disant « auto-hébergé » plus fort. Vous y parvenez en choisissant une famille de modèles ou un fine-tune différent — et en comprenant les compromis qui l’accompagnent.

Choisir un modèle local moins restrictif

Si vous voulez un test équitable, comparez des modèles qui occupent approximativement la même classe de taille. C’est pourquoi ce guide utilise llama3.1:8b comme base alignée grand public et dolphin3 comme modèle de comparaison moins restrictif. Ils font tous les deux environ 4,9GB, ce qui rend la différence de comportement plus facile à interpréter sans changer trop drastiquement l’empreinte matérielle.

Récupérez les modèles de comparaison localement :

Voici le cadrage pratique pour les trois noms que vous verrez le plus souvent 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 ». Cela peut modifier la franchise, la densité des avertissements et la volonté de suivre la formulation de l’utilisateur, mais cela 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 limites du matériel impliqué. Il y a donc deux choses à tester conceptuellement : d’abord, à quoi ressemble un comportement mono-GPU propre 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 bi-GPU. Les deux comptent, mais seul le premier constitue 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 grand pour être intéressant tout en restant pertinent sur une carte 16GB.

Après le chargement du modèle, confirmez l’état d’exécution :

C’est la preuve pratique que vous souhaitez sur cette machine. Elle montre que les modèles plus petits tiennent facilement et qu’un modèle local plus grand mais réaliste peut pousser une carte 16GB près de son enveloppe utilisable sans nécessiter 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 pouvant démontrer le placement multi-GPU. Le flux de travail est le même — surveiller nvidia-smi, exécuter le modèle, inspecter ollama ps — mais le but n’est pas de faire s’allumer les deux cartes pour le principe. Le but est de confirmer qu’Ollama ne répartit un modèle sur plusieurs GPU que lorsque le modèle ne tient plus proprement sur un seul.

Considérations sur le contournement de la censure

Pour la comparaison de comportement, gardez les conditions contrôlées afin de tester davantage le modèle que le caractère aléatoire. Utilisez le même point de terminaison, le même prompt, stream: false, une température basse et une graine fixe :

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 le caractère aléatoire pour rendre les différences de ton et de conformité plus faciles à observer.

1. Un premier prompt sûr est : « L’auto-hébergement d’un LLM signifie-t-il que l’utilisateur contrôle entièrement le comportement du modèle ? Répondez en 4 points. Soyez direct et évitez les préambules. » Une réponse représentative de llama3.1:8b tend à ressembler à 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 au même prompt semble 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. Un deuxième prompt utile est : « Rédigez un argumentaire percutant en cinq phrases expliquant pourquoi une équipe soucieuse de sa confidentialité pourrait rejeter l’IA gérée par un fournisseur. Pas d’introduction ni de conclusion. » llama3.1:8b se conforme généralement, mais avec un ton corporatif plus mesuré. dolphin3 suit plus facilement le niveau de franchise demandé. C’est le type de différence que vous recherchez ici : pas une sortie dramatiquement incontrôlée, mais des changements de franchise, de formulation et de densité d’avertissements.
3. La troisième catégorie de prompts pour la validation peut être la suivante : demandez 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 conventionnel. En pratique, les deux modèles répondent, mais dolphin3 tend à rester plus proche du ton non moralisateur demandé, avec des réponses directes.

Le schéma ressemble à ceci :

Ainsi, voici les conclusions honnêtes :

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

Vous contrôlez maintenant la pile, pas seulement le prompt

La frustration du début de ce guide n’était jamais uniquement liée au refus d’une requête par un modèle. C’était le fait que la couche de service, la couche de politique et la frontière de confidentialité se trouvaient ailleurs. Après cette configuration, cette partie a changé. Votre serveur d’inférence s’exécute sur votre machine Ubuntu, la frontière API locale est la vôtre, le menu des modèles est le vôtre, et vos paramètres par défaut de prompt/d’exécution sont à vous pour être ajustés.

Ce qui requiert encore du jugement est la partie qu’aucun programme d’installation ne peut résoudre pour vous : choisir des modèles qui correspondent à votre cas d’utilisation, les orienter avec des paramètres par défaut sains, et exposer l’accès de manière sécurisée si vous allez au-delà de localhost. C’est la vraie 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 souhaitez la meilleure prochaine étape, commencez par créer un Modelfile personnalisé — ou par mettre un accès distant sécurisé devant l’API locale lorsque 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 des modèles ne sont plus abstraites. La prochaine étape n’est pas « installer plus de choses aveuglément ». C’est d’ajuster les parties de la pile qui vous appartiennent maintenant.

Personnaliser le comportement du modèle avec un Modelfile

Un Modelfile est la façon la plus propre de modifier les paramètres de prompt locaux par défaut sans toucher aux poids du modèle lui-même. Commencez par inspecter la définition actuelle du modèle afin de comprendre ce que vous étendez :

Créez ensuite une variation locale simple :

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 :

❗ Important : Un Modelfile modifie le comportement de prompt 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 sur localhost est un bon paramètre par défaut, mais ce n’est pas la fin de l’histoire en matière de sécurité. Vérifiez d’abord l’adresse d’écoute actuelle :

Si l’objectif est de garder Ollama uniquement en local, fixez ce comportement explicitement avec une substitution systemd :

Ajoutez ce qui suit :

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

Puis rechargez et redémarrez le service :

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

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 : Considérez l’exposition publique comme un projet de renforcement distinct. Ollama en lui-même est un serveur d’inférence local, pas une passerelle API publique prête pour la production avec authentification intégrée, limitation de débit et paramètres par défaut orientés vers Internet.

Modèles recommandés pour ce matériel

Une fois que l’installation de base fonctionne, l’amélioration la plus rentable est de choisir des modèles qui s’adaptent réellement bien à cette machine plutôt que de courir après le titre le plus impressionnant. Pour le serveur mono-4070 Ti SUPER utilisé ici, le menu pratique ressemble à ceci :

Démarrage automatique et maintenance

Après la partie amusante vient la partie qui maintient un serveur LLM local utilisable un mois plus tard. Confirmez le comportement au démarrage, maintenez le service à jour, surveillez les journaux et sachez comment décharger les grands modèles lorsque vous avez besoin de récupérer de la VRAM.

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

Et si le stockage des modèles doit être déplacé vers un disque plus grand, préparez le répertoire pour l’utilisateur de service avant de rediriger Ollama :

Définissez ensuite OLLAMA_MODELS via systemctl edit ollama. Ce détail de propriété 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 consiste généralement à faire correspondre le symptôme à la bonne couche plutôt que d’essayer des boucles de réinstallation aléatoires. Utilisez ce tableau comme première approche :

Si vous ne retenez qu’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 comptent tout autant que la fenêtre de prompt.