Comment rendre Ollama accessible depuis un autre poste ?

Par défaut, Ollama n'écoute que sur 127.0.0.1, port 11434. La variable OLLAMA_HOST change l'adresse d'écoute. La FAQ décrit aussi l'exposition derrière un proxy comme Nginx.

Ollama a-t-il une authentification intégrée ?

La FAQ d'Ollama ne décrit pas d'authentification pour un serveur local. Sa seule clé publique sert aux téléchargements privés et aux modèles cloud. Le contrôle d'accès se fait donc en amont : pare-feu, proxy, réseau privé.

Combien de requêtes simultanées Ollama traite-t-il ?

OLLAMA_NUM_PARALLEL vaut 1 par défaut d'après la FAQ. L'augmenter accroît la mémoire utilisée, proportionnelle au nombre de requêtes parallèles multiplié par la longueur de contexte.

Ollama sur un serveur : partager un LLM sur le réseau

Pour qu'une équipe partage un modèle, on installe Ollama sur un serveur équipé d'une carte graphique, on le fait démarrer comme un service, puis on l'ouvre au réseau interne, idéalement derrière un proxy qui contrôle l'accès. Par défaut, Ollama n'écoute que sur la machine elle-même : c'est un choix prudent, à ne changer qu'en connaissance de cause. Les réglages ci-dessous viennent de la documentation d'Ollama, lue le 15/11/2026.

Étape 1 : le service systemd

La documentation Linux décrit le démarrage automatique :

créer un utilisateur et un groupe ollama dédiés ;
écrire le fichier /etc/systemd/system/ollama.service, dont la ligne clé est ExecStart=/usr/bin/ollama serve ;
lancer :

sudo systemctl daemon-reload
sudo systemctl enable ollama
sudo systemctl start ollama

Le journal se lit avec journalctl -e -u ollama. Un utilisateur dédié limite ce que le service peut toucher sur la machine.

Variante : Docker

La page Docker donne trois commandes selon le matériel :

Matériel	Commande
Processeur seul	`docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama`
NVIDIA (avec NVIDIA Container Toolkit)	ajouter `--gpus=all`
AMD	`--device /dev/kfd --device /dev/dri` et l'image `ollama/ollama:rocm`

Un modèle se lance ensuite dans le conteneur : docker exec -it ollama ollama run llama3.2. Le volume nommé ollama est monté sur /root/.ollama, le dossier où Ollama range modèles et configuration. L'option -p 11434:11434 publie le port du conteneur sur l'hôte : traitez-la avec les mêmes précautions que l'étape suivante.

Étape 2 : ouvrir au réseau, ou pas

D'après la FAQ, Ollama écoute par défaut sur 127.0.0.1, port 11434, et la variable OLLAMA_HOST change cette adresse. Deux façons de faire :

Ouvrir directement en réglant OLLAMA_HOST sur l'adresse du serveur. Simple, mais tout poste qui atteint ce port peut alors s'adresser au serveur : la FAQ ne décrit aucune authentification pour un serveur local.
Laisser Ollama sur 127.0.0.1 et placer un proxy devant. La FAQ indique qu'Ollama peut être exposé par un proxy comme Nginx, qui transmet les requêtes vers http://localhost:11434. C'est le proxy qui porte alors le chiffrement TLS, l'authentification et la journalisation.

La seconde voie est la plus sûre pour une entreprise. Dans les deux cas, limitez le port au réseau interne par le pare-feu. Les risques d'un modèle accessible sans contrôle sont traités sur la page Fuite de données et IA du site consacré à la sécurité.

Étape 3 : régler pour plusieurs utilisateurs

Variable	Défaut d'après la FAQ	Effet
`OLLAMA_NUM_PARALLEL`	1 requête par modèle	au-delà, la mémoire augmente avec ce nombre multiplié par la longueur de contexte
`OLLAMA_MAX_LOADED_MODELS`	3 par carte graphique, ou 3 sur processeur	nombre de modèles chargés en même temps
`OLLAMA_KEEP_ALIVE`	5 minutes	délai avant déchargement d'un modèle inutilisé
`OLLAMA_CONTEXT_LENGTH`	selon la mémoire vidéo	fenêtre de contexte par défaut

Prenons une équipe de dix personnes qui interroge le même modèle par moments : garder le modèle chargé plus longtemps évite d'attendre son rechargement, et deux ou quatre requêtes parallèles évitent la file d'attente, si la mémoire vidéo le permet. Mesurez avec ollama ps après chaque changement. Quand les accès simultanés deviennent la règle, un moteur pensé pour le service à plusieurs comme vLLM est à étudier.

Étape 4 : couper ce qui sort

Modèles cloud. Ollama propose des modèles exécutés sur ses propres serveurs. Pour qu'aucune requête n'y parte par erreur, la FAQ décrit OLLAMA_NO_CLOUD=1, ou {"disable_ollama_cloud": true} dans ~/.ollama/server.json.
Téléchargements. Les modèles viennent d'Internet ; derrière un proxy d'entreprise, la FAQ précise qu'il peut falloir en configurer un. Vous pouvez aussi télécharger les modèles une fois, puis isoler le serveur.
Mises à jour. Sous Linux, elles se font en relançant le script d'installation : planifiez-les, testez-les.

La carte graphique du serveur

D'après la page sur les cartes graphiques, Ollama prend en charge les cartes NVIDIA de « compute capability » 5.0 ou plus (pilote 550 ou plus récent), les cartes AMD avec ROCm v7 sous Linux, et d'autres cartes par Vulkan. Pour dimensionner la mémoire, voir Quel matériel pour un LLM local.

Brancher les outils

Une fois le serveur en place, une interface de discussion comme Open WebUI s'y connecte, et vos programmes l'appellent par son interface (voir Appeler un LLM local depuis son code).