Déployer Ollama sur un poste de travail et dimensionner la mémoire

Déployer Ollama sur un poste de travail et dimensionner la mémoire

Ollama empaquette un moteur d’inférence (dérivé de llama.cpp), un registre de modèles et une API (Application Programming Interface) HTTP (HyperText Transfer Protocol) locale : trois commandes suffisent pour faire répondre un modèle de langage sur un poste. La difficulté est le dimensionnement : un modèle et une fenêtre de contexte qui tiennent en mémoire vidéo, puis un service qui n’écoute pas plus loin que prévu.

Explication de la marmotte

Avoir un assistant qui écrit et résume directement sur son ordinateur, c’est comme avoir un dictionnaire bavard rangé dans son bureau plutôt que d’appeler un inconnu à chaque question. Tout reste dans la pièce. En échange, il faut lui trouver une étagère assez grande, sinon il répond avec la lenteur d’un escargot fatigué.

→ Lire l’explication complète de la marmotte

Prérequis matériels et choix du modèle Ollama

Le compromis central : on échange de la qualité de réponse (taille du modèle, précision des poids) contre de la vitesse et de la longueur de contexte, dans une enveloppe mémoire fixe. La règle qui tranche : le plus gros modèle qui tient entièrement en VRAM (Video Random Access Memory, la mémoire du GPU, Graphics Processing Unit) avec le contexte voulu, pas le plus gros modèle qui démarre. Dès qu’une partie des couches déborde vers le CPU (Central Processing Unit), le débit chute souvent d’un facteur 3 à 10 : chaque jeton généré traverse toutes les couches, y compris les lentes.

L’estimation se fait en deux termes. Les poids d’abord : un modèle quantifié en Q4_K_M (environ 4,5 à 5 bits par poids) occupe à peu près 0,6 Go par milliard de paramètres, soit près de 5 Go pour un modèle de 8 milliards. Le cache KV (clés et valeurs d’attention mémorisées pour chaque jeton du contexte) ensuite : pour une architecture de type Llama 3.1 8B (32 couches, 8 têtes clé/valeur de dimension 128, en 16 bits), il coûte 128 Kio par jeton, donc 1 Gio pour 8 192 jetons et 4 Gio pour 32 768.

Mémoire GPU disponible	Choix recommandé (Q4_K_M)	Contexte réaliste
Aucun GPU, 16 Go de RAM (Random Access Memory)	3 à 4 milliards de paramètres	4 096 à 8 192
8 Go	7 à 8 milliards	8 192
12 à 16 Go	12 à 14 milliards	8 192 à 16 384
24 Go	27 à 32 milliards	8 192

Sans carte graphique, le poste sert à reformuler ou classer du texte, pas à assister du code en continu. Côté logiciel : Linux avec systemd, un pilote NVIDIA récent avec CUDA (Compute Unified Device Architecture) ou ROCm (Radeon Open Compute) pour AMD, et une version d’Ollama postérieure aux correctifs cités plus bas.

Installation, service systemd et réglages mémoire

Le script officiel crée un utilisateur système ollama et un service systemd ; les modèles vont sous /usr/share/ollama/.ollama/models. Les réglages passent par des variables d’environnement, dans une surcharge systemd (le fichier d’unité est écrasé à chaque mise à jour).

OLLAMA_CONTEXT_LENGTH fixe le contexte par défaut, dont la valeur implicite a changé selon les versions : la fixer évite qu’une mise à jour double en silence la consommation. OLLAMA_FLASH_ATTENTION=1 combiné à OLLAMA_KV_CACHE_TYPE=q8_0 divise environ par deux la taille du cache KV, au prix d’une perte de qualité rarement mesurable. OLLAMA_MAX_LOADED_MODELS=1 et OLLAMA_NUM_PARALLEL=1 empêchent un second modèle ou un second flux de venir voler la VRAM du premier ; chaque flux parallèle réserve son propre contexte.

OLLAMA_KEEP_ALIVE (5 minutes par défaut) règle la durée de maintien en mémoire après la dernière requête : courte sur un poste partagé, -1 sur un poste dédié.

Exemple reproductible : déploiement et mesure de débit

Les commandes ci-dessous visent un poste Linux avec un GPU de 8 Go. Le script d’installation est téléchargé puis lu avant exécution : le réflexe curl | sh sur un poste d’entreprise relève davantage de la foi que de l’ingénierie.

# 1. Télécharger, relire, puis exécuter le script d'installation officiel
curl -fsSL https://ollama.com/install.sh -o install-ollama.sh
less install-ollama.sh
sh install-ollama.sh

# 2. Surcharger la configuration du service (écoute locale, mémoire bornée)
sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf >/dev/null <<'EOF'
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"
EOF
sudo systemctl daemon-reload && sudo systemctl restart ollama

# 3. Télécharger un modèle de 8 milliards de paramètres quantifié en 4 bits
ollama pull llama3.1:8b

# 4. Mesurer le débit via l'API (durées renvoyées en nanosecondes)
curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Explique le principe du chiffrement enveloppe en cinq phrases.",
  "stream": false
}' | jq '{
  chargement_s: (.load_duration / 1e9),
  lecture_prompt_jetons_s: (.prompt_eval_count / (.prompt_eval_duration / 1e9)),
  generation_jetons_s: (.eval_count / (.eval_duration / 1e9))
}'

# 5. Vérifier la répartition GPU/CPU du modèle chargé (colonne PROCESSOR)
ollama ps

ollama ps doit afficher 100% GPU ; 25%/75% CPU/GPU signale un débordement, à corriger en réduisant le contexte ou la taille du modèle avant toute autre optimisation. En génération, 20 jetons par seconde se lisent confortablement ; sous 5, l’outil sera abandonné en une semaine. La première requête inclut le chargement : ne retenir que la seconde mesure.

Surface d’attaque d’Ollama sur un poste

L’API d’Ollama n’a aucune authentification. Quiconque joint le port 11434 peut générer, télécharger un modèle de plusieurs dizaines de gigaoctets (remplissage disque) ou en supprimer un via /api/delete. Passer OLLAMA_HOST à 0.0.0.0 « pour qu’un collègue teste » publie donc un service d’administration anonyme sur le réseau local. Un accès distant passe par un proxy inverse qui authentifie, port filtré au pare-feu du poste.

La CVE (Common Vulnerabilities and Exposures) 2024-28224 permettait, par rebinding DNS (Domain Name System), à une page web d’atteindre l’API locale (corrigé en 0.1.29) ; CVE-2024-37032, dite « Probllama », exploitait une traversée de chemin dans /api/pull jusqu’à l’exécution de code (corrigée en 0.1.34). Écouter sur 127.0.0.1 ne protège donc pas de tout, et OLLAMA_ORIGINS doit rester restrictif.

Le modèle est lui-même une entrée non fiable : le fichier GGUF (format de poids de llama.cpp) est analysé par du code C++, et un dépôt communautaire tiré via hf.co/... n’offre aucune garantie de provenance. Épingler les modèles par empreinte (ollama list) et tenir une liste blanche.

Ce qu’Ollama ne garantit pas et conditions d’exploitation

Ollama garantit que le prompt ne quitte pas le poste, rien de plus. Il ne cloisonne pas les utilisateurs d’une même machine, ne chiffre pas les modèles au repos et conserve l’historique des sessions interactives dans ~/.ollama/history, non chiffré : un secret collé dans ollama run y reste. La qualité des réponses, elle, ne dépend que du modèle ; un 8B quantifié invente avec aplomb, et le contrôle doit venir d’une relecture humaine ou d’une évaluation outillée, comme le décrit la page sur l’observabilité des modèles de langage en production.

En exploitation : suivre journalctl -u ollama, mettre à jour le binaire au rythme d’un navigateur, versionner les Modelfile et la surcharge systemd ; les modèles se retéléchargent, à condition d’avoir noté leur empreinte. La page embeddings traite l’étape suivante (base documentaire locale) ; la rubrique IA situe l’ensemble.

🐝 Ce qui arrive si on s’en passe

Sans modèle exécuté localement, chaque requête adressée à un assistant de langage part vers un service tiers : le texte du prompt, ainsi que les extraits de code, journaux ou documents collés pour donner du contexte, quittent le poste. Ils sont alors traités sur une infrastructure dont la politique de conservation et de réutilisation relève du fournisseur, non de l’administrateur du poste. Le trafic sortant vers ces API se confond avec la navigation HTTPS ordinaire, ce qui ne permet pas de savoir quel contenu a été transmis. Aucune journalisation locale ne permet ensuite de reconstituer quelles données ont été exposées. L’outil dépend enfin de la connectivité et de la disponibilité du service : hors réseau, ou lors d’une interruption côté fournisseur, il cesse simplement de répondre.

🦫 Explication de la marmotte 🍫

Un modèle de langage est un gros fichier de nombres, appelés poids, qui sert à deviner le mot suivant d’un texte. Ollama est un programme qui charge ce fichier et répond aux questions posées sur l’ordinateur lui-même, sans rien envoyer sur Internet.

Pour répondre vite, le fichier doit tenir dans la mémoire de la carte graphique. Deux choses y prennent de la place : le modèle, qui grossit avec son nombre de poids, et la mémoire de la conversation en cours, qui grossit avec la longueur du texte à garder en tête. On choisit donc un modèle compressé, dont les poids sont arrondis pour prendre moins de place, et une longueur de conversation raisonnable. Si l’ensemble dépasse, une partie passe sur le processeur principal et les réponses deviennent plusieurs fois plus lentes.

On installe le programme, on règle ces limites, on télécharge un modèle, puis on mesure le nombre de mots produits par seconde.

Le programme accepte toutes les demandes qui lui arrivent, sans mot de passe. Il doit donc écouter uniquement l’ordinateur lui-même, être mis à jour contre ses failles et ne charger que des modèles de source connue. Enfin, il ne vérifie jamais si ses réponses sont vraies : une personne doit les relire.

À lire aussi

• Backend Foundry Local expliqué et comparé à LM StudioCe que recouvre le backend Foundry (Microsoft Foundry et Foundry Local), comment fonctionne son moteur d'inférence local, sa surface d'attaque, et ce qui le sépare de LM Studio.
• Comment fonctionne l'inférence d'un modèle de langagePréremplissage, décodage, cache de clés et valeurs, batching et surface d'attaque d'un serveur d'inférence, avec les compromis de latence et de débit à trancher avant la mise en production.
• Fenêtre de contexte et mémoire d’un LLM localChoisir, dimensionner et exploiter la fenêtre de contexte d’un LLM local sans sacrifier inutilement la performance, la sécurité ou la continuité des conversations.
• Calculer le coût d’un LLM local à grande échelleMéthode de dimensionnement et d’optimisation économique d’un déploiement local de modèles de langage à grande échelle.

Pages voisines

La citent

• Backend Foundry Local expliqué et comparé à LM Studio
• LM Studio utilité, éditeur et limites sur poste de travail
• Comment fonctionne l'inférence d'un modèle de langage
• Différence entre IA et LLM : un champ entier, un type de modèle
• Gardien IA pour LLM, fonctionnement, exemples et choix de produit

Déployer Ollama sur un poste de travail et dimensionner la mémoire

Elle cite

• Comparer GGUF GPTQ et AWQ pour LLM local
• Dimensionner GPU et RAM pour un LLM local
• Comment observer un LLM en production
• Embeddings : vecteurs, recherche sémantique et RAG
• Les poids d'un modèle sont un artefact logiciel