Ollama — premier déploiement opérationnel

Introduction

Ollama s'est imposé comme le point d'entrée le plus rapide pour faire tourner un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire sur une machine que l'on contrôle. Son intérêt n'est pas de rivaliser avec un moteur d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire de production comme vLLM sur la performance brute, mais d'offrir un chemin très court entre « je veux tester un modèle » et « le modèle répond via une API ». Cette rapidité de mise en œuvre en fait un excellent outil de prototypage, de développement local, et — sous conditions strictes que nous détaillerons — un service de production pour des charges modestes.

Ce chapitre part du principe que vous disposez d'un serveur Linux (physique ou virtuel) avec un GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire ou, à défaut, suffisamment de RAM pour de l'inférence CPU. L'objectif est d'arriver à un déploiement stable, redémarré automatiquement, interrogeable via HTTP, et dont vous comprenez les limites avant de le mettre entre les mains d'autres équipes.

Ce chapitre est délibérément pratique. Les questions de choix de modèle, de dimensionnement matériel et de comparaison avec vLLM ont été ou seront traitées dans les chapitres voisins. Ici, l'enjeu est de savoir installer, exploiter et sécuriser correctement une instance Ollama.

Installation sur Linux

L'installation officielle d'Ollama passe par un script shell qui détecte l'architecture, télécharge le binaire adapté et configure un service systemd. Sur une distribution Debian/Ubuntu récente :

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

Ce script effectue plusieurs opérations qu'il est utile de connaître avant de l'exécuter sur un serveur d'entreprise :

1. il télécharge le binaire ollama dans /usr/local/bin ou /usr/bin selon la distribution ;
2. il crée un utilisateur système dédié ollama, sans shell de connexion, pour exécuter le service ;
3. il installe une unité systemd (ollama.service) et l'active au démarrage ;
4. il détecte la présence d'un GPU NVIDIA ou AMD et installe les composants nécessaires si les pilotes sont déjà présents.

Piper un curl directement vers sh avec des privilèges root est une pratique courante dans l'écosystème IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire, mais elle mérite un minimum de vigilance en contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire professionnel. Sur un serveur sensible, téléchargez le script, lisez-le, puis exécutez-le — ou passez par le paquet natif si votre distribution en propose un, ou par l'image Docker officielle qui isole davantage le processus.

Une alternative plus maîtrisable pour un déploiement d'entreprise est le conteneur officiel :

docker run -d --gpus=all \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  --name ollama \
  ollama/ollama

Notez le bind explicite sur 127.0.0.1 : nous y reviendrons dans la section sécurité, car c'est l'erreur de configuration la plus fréquente sur ce type de service.

Le service systemd

Que l'installation se fasse via le script ou manuellement, il est recommandé de faire tourner Ollama comme service systemd plutôt qu'en processus interactif. Cela garantit un redémarrage automatique en cas de crash ou de reboot du serveur, et une gestion homogène des logs via journalctl.

Commandes de base :

systemctl status ollama
systemctl restart ollama
systemctl enable ollama   # démarrage automatique au boot
journalctl -u ollama -f   # suivi des logs en direct

La configuration du service se pilote principalement par variables d'environnement, définies dans un fichier de surcharge systemd :

sudo systemctl edit ollama

Cela ouvre un fichier override.conf dans lequel on peut définir, par exemple :

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_MAX_LOADED_MODELS=2"

Par défaut, les modèles sont stockés dans ~/.ollama/models, ce qui pose problème si votre partition système est petite — un modèle de 30 milliards de paramètres quantifié pèse déjà 15 à 20 Go. Définir OLLAMA_MODELS vers un volume dédié dès l'installation évite une migration douloureuse plus tard.

Après toute modification, il faut recharger la configuration puis redémarrer le service :

sudo systemctl daemon-reload
sudo systemctl restart ollama

Récupérer et gérer des modèles

Ollama distribue les modèles via un registre au format proche de celui des images de conteneurs. La commande pull télécharge un modèle et ses métadonnées :

ollama pull llama3.1:8b
ollama pull mistral:7b-instruct
ollama pull qwen2.5:14b-instruct-q4_K_M

Le suffixe après les deux-points désigne le tag : taille de modèle, variante d'instruction, et niveau de quantification (q4_K_M, q8_0, etc.). La quantification réduit l'empreinte mémoire au prix d'une légère perte de précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire — un compromis central que nous approfondirons dans un chapitre dédié au dimensionnement.

Commandes de gestion courantes :

ollama list                 # modèles installés localement
ollama show llama3.1:8b     # métadonnées, paramètres, template
ollama rm mistral:7b-instruct
ollama ps                   # modèles actuellement chargés en mémoire

Sur un serveur partagé par plusieurs équipes, il n'est pas rare de se retrouver avec huit à dix modèles installés « au cas où ». du -sh $OLLAMA_MODELS donne rapidement une idée de la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire. Une règle simple : ne conserver que les modèles réellement utilisés en production ou en évaluation active, et documenter qui a demandé quoi.

Le Modelfile : personnaliser un modèle

Le Modelfile est le mécanisme d'Ollama pour créer une variante personnalisée d'un modèle de base, en figeant un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système, des paramètres par défaut, ou un template de conversation. La syntaxe rappelle volontairement un Dockerfile :

FROM llama3.1:8b

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER top_p 0.9

SYSTEM """
Tu es un assistant technique interne pour l'équipe support.
Réponds de façon concise, en français, et cite les procédures internes
quand elles existent. Si tu ne sais pas, dis-le explicitement.
"""

On construit ensuite le modèle personnalisé avec :

ollama create support-assistant -f ./Modelfile

Ce modèle devient alors interrogeable comme n'importe quel autre, sous le nom support-assistant. C'est le mécanisme recommandé pour figer un comportement (ton, langue, périmètre de réponse) sans avoir à répéter le prompt système à chaque appel côté client — et sans confondre ce mécanisme avec un fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire, qui modifie réellement les poids du modèle.

Le Modelfile ne modifie pas les paramètres internes du modèle : il enveloppe un modèle existant avec des réglages et un prompt système par défaut. Pour une adaptation plus profonde (vocabulaire métier très spécifique, format de sortie strict appris par l'exemple), il faudra un fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire ou du RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire, traités dans d'autres chapitres de cette formation.

Les paramètres d'inférence essentiels

Deux paramètres méritent une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière car ils conditionnent directement la qualité perçue des réponses et la faisabilité technique de certains cas d'usage.

temperature contrôle le degré d'aléatoire dans le choix du prochain tokentokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire. Une valeur proche de 0 rend le modèle quasi déterministe et factuel, utile pour de l'extraction d'information ou de la classification. Une valeur plus élevée (0.7 à 1.0) favorise la diversité, pertinente pour de la génération créative. En contexte professionnel — support client, documentation, extraction — une temperature basse (0.1 à 0.4) est presque toujours le bon choix par défaut.

num_ctx définit la taille de la fenêtre de contexte, c'est-à-dire le nombre de tokens que le modèle peut « voir » simultanément (prompt système + historique + question). Ollama utilise par défaut une valeur modeste (souvent 2048 ou 4096 selon le modèle), nettement inférieure à la capacité réelle du modèle, pour économiser la mémoire. Augmenter num_ctx consomme davantage de VRAM ou de RAM de façon quasi linéaire.

Doubler num_ctx sur un modèle de 8 milliards de paramètres peut ajouter plusieurs centaines de mégaoctets à plusieurs gigaoctets de VRAM utilisée, selon le modèle et la quantification. Sur une carte à mémoire limitée, une fenêtre de contexte trop généreuse est une cause fréquente de bascule silencieuse vers le CPU, avec un effondrement des performances qui ressemble à tort à un bug applicatif.

L'API HTTP

Une fois le service actif, Ollama expose une API REST locale, par défaut sur le portportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire 11434. Les deux endpoints les plus utilisés sont /api/generate pour une complétion simple et /api/chat pour un échange conversationnel avec historique de messages.

Appel minimal avec curl :

curl http://127.0.0.1:11434/api/chat -d '{
  "model": "support-assistant",
  "messages": [
    {"role": "user", "content": "Résume la procédure de reset mot de passe."}
  ],
  "stream": false
}'

La réponse est un objet JSON contenant le message généré, ainsi que des statistiques utiles (nombre de tokens, durée d'évaluation, débit).

En Python, l'intégration se fait sans dépendance particulière, via requests :

import requests

response = requests.post(
    "http://127.0.0.1:11434/api/chat",
    json={
        "model": "support-assistant",
        "messages": [{"role": "user", "content": "Explique le fonctionnement du VPN interne."}],
        "stream": False,
        "options": {"temperature": 0.3, "num_ctx": 8192},
    },
    timeout=60,
)
response.raise_for_status()
print(response.json()["message"]["content"])

La bibliothèque officielle ollama (installable via pip install ollama) propose une interface plus idiomatique, mais l'appel HTTP brut reste la meilleure façon de comprendre ce qui se passe réellement sous le capot, notamment pour du diagnostic.

Limites d'Ollama en environnement d'entreprise

Ollama a été conçu d'abord pour un usage individuel ou de petite équipe, et cela transparaît dans certaines limites structurelles.

Concurrence limitée. OLLAMA_NUM_PARALLEL définit le nombre de requêtes traitées en parallèle par modèle chargé, mais ce parallélisme reste rudimentaire comparé à un moteur d'inférence spécialisé. Sous forte charge concurrente (plusieurs dizaines d'utilisateurs simultanés), les temps de réponse se dégradent nettement plus vite qu'avec vLLM, qui implémente du batching continu et une gestion fine de la mémoire (PagedAttention). Nous détaillerons ce contraste dans le chapitre consacré à vLLM.

Support multi-GPU partiel. Ollama sait répartir un modèle trop volumineux pour tenir sur un seul GPU (tensor splitting), mais il ne fait pas de répartition de charge intelligente entre plusieurs GPU pour servir plusieurs requêtes en parallèle de façon optimale. Sur un serveur à quatre GPU, on obtient rarement un gain proportionnel au nombre de cartes.

Absence de gestion fine des files d'attente. Il n'existe pas de mécanisme natif de priorisation de requêtes, de quotas par utilisateur, ni de mise en file d'attente sophistiquée. Ces besoins doivent être couverts en amont, par une couche applicative ou un reverse proxy.

Au-delà d'une poignée d'utilisateurs simultanés actifs ou d'exigences de latence strictes en production, il devient pertinent d'évaluer un moteur comme vLLM ou TGI. Ollama reste pertinent pour du prototypage, des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire internes à faible trafic, ou de l'inférence sur poste de travail.

Sécuriser le bind réseau

Par défaut, selon la méthode d'installation, Ollama peut écouter sur 0.0.0.0, c'est-à-dire sur toutes les interfaces réseau de la machine — y compris celles exposées sur un réseau d'entreprise ou, pire, sur Internet. L'API ne dispose d'aucune authentification native dans les versions courantes : quiconque atteint le port 11434 peut interroger le modèle, lister les modèles installés, voire en supprimer.

Un grand nombre d'instances Ollama accessibles publiquement sur Internet ont été recensées par des scans automatisés, résultat direct d'un bind sur 0.0.0.0 sans pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire ni proxy. Ce n'est pas un scénario théorique : c'est l'erreur de configuration la plus documentée sur ce type de service.

Deux principes simples réduisent drastiquement ce risque :

1. Lier le service à 127.0.0.1 tant qu'aucun accès distant n'est nécessaire, via OLLAMA_HOST=127.0.0.1:11434.
2. Passer par un reverse proxy (nginx, Caddy, Traefik) dès qu'un accès réseau est requis, en ajoutant à ce niveau l'authentification, le TLSTLSRéseauxProtocole cryptographique assurant confidentialité et intégrité des communications applicatives (notamment HTTPS).Voir dans le glossaire et, si besoin, une limitation de débit.

Exemple minimal de configuration nginx en frontal, avec authentification basique :

location /ollama/ {
    auth_basic "Accès restreint";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:11434/;
    proxy_set_header Host $host;
}

Cette configuration reste un plancher, pas un objectif : en production, on préférera une authentification par jeton applicatif (côté service consommateur) plutôt qu'un simple couple identifiant/mot de passe partagé, et un pare-feu qui restreint de toute façon les origines autorisées.

Checklist avant mise en service

• Le service tourne sous systemd, avec enable activé pour survivre à un reboot.
• OLLAMA_HOST est explicitement défini sur 127.0.0.1 ou sur une interface interne contrôlée par pare-feu.
• OLLAMA_MODELS pointe vers un volume disposant de suffisamment d'espace disque.
• Un reverse proxy avec authentification est en place si un accès réseau est nécessaire.
• Les paramètres temperature et num_ctx ont été fixés dans un Modelfile plutôt que laissés aux valeurs par défaut à chaque appel client.
• La volumétrie attendue (utilisateurs simultanés, longueur de contexte) a été confrontée aux limites de concurrence d'Ollama.

Ce qu'il faut retenir

Ollama réussit à rendre triviale une opération qui, il y a quelques années encore, demandait une expertise significative en infrastructure GPU. Ce chapitre a couvert l'installation, l'exploitation quotidienne via systemd, la personnalisation par Modelfile, et l'intégration applicative via l'API HTTP. Le point le plus critique à retenir reste la sécurisation réseau : un service sans authentification native ne doit jamais être exposé tel quel. Le chapitre suivant aborde le dimensionnement matériel et les critères de choix entre plusieurs familles de modèles.