La majorité des développeurs qui utilisent un LLM passent par une API cloud. C'est pratique, mais ça veut dire que chaque requête sort de votre infrastructure, que vous payez au token, et que vos données transitent sur des serveurs tiers. Pour beaucoup de cas d'usage - prototypage, données sensibles, code propriétaire, coût d'inférence qui monte - ce n'est pas ce que vous voulez.
Ollama règle ce problème avec une approche d'une simplicité surprenante : un binaire, une commande, un modèle qui tourne localement avec une API REST compatible OpenAI. Le projet a atteint 175 000 étoiles GitHub et 52 millions de téléchargements mensuels au premier trimestre 2026, ce qui en fait le standard de fait pour l'inférence LLM locale. La version stable est la v0.30.11, publiée le 25 juin 2026.
Ce guide couvre l'installation, le choix du bon modèle selon votre matériel, les commandes essentielles, comment brancher Ollama sur vos outils, et les pièges documentés officiellement que les tutos habituels ne mentionnent pas.
Ce qu'Ollama fait concrètement (et ce que ça remplace)
Avant Ollama, faire tourner un LLM en local supposait de compiler llama.cpp, de gérer ses dépendances, de convertir les poids au format GGUF, et d'écrire un serveur HTTP si on voulait une API. Ce n'était pas impossible, mais ça prenait plusieurs heures, ça demandait des connaissances CUDA/ROCm, et ça recassait à chaque mise à jour.
Ollama empaquette tout ça : le runtime d'inférence (basé sur llama.cpp et d'autres backends selon la plateforme), un gestionnaire de modèles qui télécharge et versionne les GGUF automatiquement, et un serveur HTTP qui expose une API REST sur le port 11434. L'accélération GPU se configure seule selon ce qu'Ollama détecte : NVIDIA via CUDA, AMD via ROCm, Apple Silicon via Metal. Sur CPU seul, ça tourne aussi, avec des performances moindres.
Le projet est écrit en Go (66 % du code, 26 % C), publié sous licence MIT. La bibliothèque de modèles officiels compte 4 500 entrées, et Ollama lit aussi directement les modèles GGUF hébergés sur HuggingFace (135 000 fichiers disponibles) via la syntaxe ollama run hf.co/author/model-name.
Ce qui rend Ollama particulièrement utile pour les projets : l'API REST expose http://localhost:11434/v1/chat/completions avec le même format JSON qu'OpenAI. Si vous avez un outil configuré pour GPT-4, vous pouvez le rediriger vers Ollama en changeant une ligne. Ça inclut LangChain, LlamaIndex, n8n, Open WebUI, et la plupart des frameworks d'agents du marché.
Ce que votre machine peut faire tourner : RAM, GPU, et les calculs réels
Le premier réflexe avant d'installer Ollama est de vérifier que son matériel suffit. Trois chiffres à retenir : un modèle à 7 milliards de paramètres nécessite environ 8 GB de RAM (ou de VRAM sur GPU dédié), un 13B réclame 16 GB, un 70B exige 64 GB. Ces seuils correspondent à la quantisation 4-bit par défaut qu'Ollama applique automatiquement pour réduire l'empreinte mémoire.
La taille réelle des fichiers est un peu différente : Llama 3.1 8B occupe 4,9 GB sur le disque une fois téléchargé, Mistral 7B prend 4,4 GB, DeepSeek R1 7B 4,7 GB. Un modèle compact comme Qwen 2.5 0.5B ne fait que 398 MB. La règle pratique : prévoir environ 1,5 fois la taille du fichier en RAM disponible pour charger confortablement un GGUF quantisé Q4.
Sur les GPU NVIDIA, Ollama requiert une compute capability 5.0 minimum et le driver 550 (570+ pour les architectures 5.0 à 6.2). Concrètement, ça couvre toutes les GTX 1050 et supérieur, et toutes les RTX. La taille du contexte est aussi conditionnée par la VRAM : moins de 24 GB de VRAM donne 4 096 tokens de contexte par défaut, 24 à 48 GB passe à 32 000 tokens, et au-delà de 48 GB le contexte monte à 256 000 tokens.
Sur Apple Silicon, la RAM est partagée entre le CPU et le GPU. Un MacBook Pro M3 Pro avec 36 GB peut faire tourner Llama 3.1 8B très confortablement et un modèle 34B quantisé à 4-bit. Ollama active automatiquement le backend MLX sur ces machines, ce qui offre les meilleures performances tokens/seconde du marché grand public en 2026 selon les benchmarks publiés. Point de vigilance : la RAM disponible pour Ollama est la RAM totale moins ce que le système et les applications ouvertes consomment. Sur 16 GB, Safari et les autres apps peuvent déjà en prendre 5 à 6 GB au repos.
Pour AMD, ROCm v7 est requis sur Linux (HIP7 sur Windows). Les séries RX 5700 et supérieur sont supportées sous Linux ; sur Windows, le support se limite aux RX 6800 et aux séries 7000.
Sans GPU, Ollama tourne sur CPU. Attendez-vous à 3 à 8 tokens par seconde sur un modèle 7B avec un processeur moderne, contre 30 à 80 tokens/s sur GPU dédié. Pour un usage ponctuel ou du prototypage, c'est viable. Pour un workflow automatisé qui traite des volumes, le CPU seul ne suffit pas.
Installation et premier modèle : cinq minutes sur n'importe quelle plateforme
Sur macOS et Linux, une commande suffit :
curl -fsSL https://ollama.com/install.sh | shLe script détecte le GPU, installe les dépendances et démarre le service. Sur Windows depuis PowerShell :
irm https://ollama.com/install.ps1 | iexPour Docker, l'image officielle expose le port 11434 avec persistance des modèles :
docker run -d \
-v ollama:/root/.ollama \
-p 11434:11434 \
--name ollama \
ollama/ollamaPour GPU NVIDIA, ajouter --gpus=all. Pour AMD, ajouter --device /dev/kfd --device /dev/dri et utiliser l'image ollama/ollama:rocm. Note importante : sur macOS, le GPU passthrough n'est pas disponible dans Docker, donc Ollama tourne sur CPU dans ce contexte.
Une fois installé, téléchargez et lancez un premier modèle :
ollama run llama3.2Cette commande télécharge Llama 3.2 3B (environ 2 GB), le charge en mémoire, et ouvre un prompt interactif dans le terminal. Pour des machines avec moins de 8 GB disponibles, llama3.2:1b (800 MB) ou qwen2.5:0.5b (398 MB) sont plus légers. Pour une machine correcte, llama3.1:8b (4,9 GB) est le point de départ recommandé pour la qualité.
Pour vérifier que l'API est disponible :
curl http://localhost:11434/api/tagsLa bibliothèque de modèles : top 5 et comment lire les stats de pulls
La bibliothèque Ollama affiche les statistiques de téléchargement en temps réel. Les volumes donnent une indication sérieuse des choix qui ont fait leurs preuves en production : Llama 3.1 dépasse 116 millions de pulls, DeepSeek R1 est à 88 millions, nomic-embed-text (le modèle d'embedding le plus utilisé pour le RAG) à 76 millions, Mistral 7B à 30 millions. Ce ne sont pas des téléchargements marketing, ce sont des activations dans des projets réels.
Pour la plupart des tâches générales (rédaction, résumé, Q&A), Llama 3.1 8B ou Llama 3.2 3B couvrent 80 % des besoins sur des machines grand public. Pour le code, Qwen 2.5 Coder (17 millions de pulls) et DeepSeek R1 sont les références de 2026. Pour l'embedding et le RAG, nomic-embed-text ne pèse que 274 MB et se branche directement sur n'importe quel vector store.
La quantisation se spécifie via le tag. Par défaut Ollama utilise Q4_K_M. Si vous avez la mémoire disponible, Q8_0 améliore la précision sans sacrifier trop de performances :
ollama pull llama3.1:8b-instruct-q8_0Les commandes de gestion courantes :
ollama list: modèles téléchargés localementollama show llama3.2: paramètres, taille, template du modèleollama ps: modèles chargés en mémoire avec leur allocation GPU/CPUollama stop llama3.2: décharger un modèle de la mémoire sans l'effacerollama rm llama3.2: supprimer un modèle du disque
Les modèles sont stockés dans ~/.ollama/models sur macOS et Linux, C:\Users\USERNAME\.ollama\models sur Windows. Comptez de 400 MB pour les plus petits à 240 GB pour les très grands modèles.
L'API REST compatible OpenAI : brancher vos outils sans réécrire une ligne
Une fois le serveur lancé, l'endpoint de chat est disponible :
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "llama3.2",
"messages": [
{"role": "user", "content": "Explique ce que fait kubectl get pods"}
]
}'En Python, avec le client OpenAI sans changer de bibliothèque :
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama" # syntaxiquement requis, ignoré par le serveur
)
response = client.chat.completions.create(
model="llama3.2",
messages=[{"role": "user", "content": "Bonjour"}]
)
print(response.choices[0].message.content)La réponse API inclut des métriques de performance utiles pour le monitoring : eval_count (tokens générés) et eval_duration (en nanosecondes) permettent de calculer le débit réel en tokens par seconde avec eval_count / eval_duration * 10^9.
Si vous avez déjà mis en place un gateway LLM compatible OpenAI pour router vos requêtes entre providers, Ollama s'y branche comme un endpoint OpenAI standard. Pour les embeddings RAG, le endpoint dédié est /api/embed :
curl http://localhost:11434/api/embed -d '{
"model": "nomic-embed-text",
"input": "Votre texte à vectoriser"
}'C'est la brique de base pour un RAG souverain en local : les embeddings se génèrent localement, le vector store tourne sur votre infrastructure, aucune donnée ne sort. Ollama supporte aussi le function calling (tool use) et les structured outputs (JSON schema), ce qui couvre la grande majorité des besoins d'un agent IA.
Pour exposer Ollama sur le réseau local (accès depuis un autre poste), une seule variable :
OLLAMA_HOST=0.0.0.0:11434 ollama serveLes limites à connaître avant de déployer en production
Ollama est excellent pour le développement et les environnements avec un ou quelques utilisateurs simultanés. Il montre ses limites dès qu'on essaie d'en faire un service à fort trafic.
Par défaut, Ollama charge un seul modèle actif à la fois. La variable OLLAMA_NUM_PARALLEL contrôle les requêtes parallèles par modèle (valeur par défaut : 1). Augmenter ce chiffre multiplie proportionnellement la RAM de contexte allouée. La file d'attente maximale est de 512 requêtes (OLLAMA_MAX_QUEUE) : au-delà, le serveur retourne une erreur 503. Le nombre maximum de modèles chargés simultanément est de 3 fois le nombre de GPU par défaut (OLLAMA_MAX_LOADED_MODELS).
Le "cold start" est le problème structurel de l'inférence locale : le premier token d'une nouvelle session sort après 2 à 15 secondes, le temps que les poids soient chargés depuis le disque vers la VRAM. Après la première requête, Ollama garde le modèle chaud en mémoire pendant 5 minutes (keep_alive configurable). Pour les webhooks qui reçoivent des requêtes épisodiques, il est utile de faire un "warmup" en envoyant une requête vide au démarrage :
curl http://localhost:11434/api/generate -d '{"model": "llama3.2"}'Sur Apple Silicon, la RAM est partagée : ce qui n'est pas libre quand Ollama démarre, il ne peut pas l'utiliser. Si les performances tombent à 2 à 3 tokens par seconde, c'est généralement du swap qui s'active parce que la RAM disponible est insuffisante.
Deux variables peuvent améliorer significativement les performances sur les grandes sessions : OLLAMA_FLASH_ATTENTION=1 active Flash Attention (réduit la RAM du KV cache), et OLLAMA_KV_CACHE_TYPE=q8_0 quantise le cache KV pour diviser son empreinte mémoire par deux, avec une perte de qualité négligeable.
Pour les déploiements multi-utilisateurs, placer un reverse proxy (nginx, Caddy) devant plusieurs instances Ollama sur des machines différentes reste la solution la plus simple. Pour les très gros modèles (70B, 405B) ou les charges importantes, Ollama propose un service cloud : Free avec quotas journaliers, Pro à 20 $/mois, Max à 100 $/mois pour les usages de production.
Si vous cherchez à structurer une architecture IA plus complète pour une équipe, notre article sur l'infrastructure IA en entreprise couvre les choix d'orchestration, de monitoring et de mise à l'échelle. Et si le sujet des coûts vous intéresse, l'analyse FinOps IA pour maîtriser les coûts LLM compare en détail les modèles économiques local vs cloud.
FAQ Ollama
Ollama fonctionne-t-il sans connexion internet une fois installé ?
Oui, complètement. Une fois les modèles téléchargés, Ollama tourne en mode 100 % hors ligne. La connexion n'est nécessaire que pour le téléchargement initial et les mises à jour. Pour les environnements air-gapped, vous pouvez copier manuellement les fichiers GGUF dans le dossier de stockage, ou utiliser la variable OLLAMA_NO_CLOUD=1 pour désactiver toutes les fonctionnalités réseau au démarrage.
Comment Ollama choisit-il entre GPU et CPU pour faire tourner un modèle ?
Ollama tente d'abord de charger le modèle entièrement en VRAM. Si la VRAM est insuffisante, il répartit le modèle entre GPU et RAM système (split CPU/GPU visible dans ollama ps). En split, les performances se dégradent sensiblement par rapport à un chargement 100 % GPU. Si aucun GPU compatible n'est détecté, Ollama bascule entièrement sur CPU.
Peut-on faire tourner plusieurs modèles simultanément ?
Oui, via la variable OLLAMA_MAX_LOADED_MODELS. Par défaut, Ollama maintient jusqu'à 3 modèles en mémoire par GPU. Chaque modèle en mémoire consomme sa part de VRAM ou RAM. Sur 32 GB de RAM, tenir deux modèles 7B simultanément est confortable. Attention : OLLAMA_NUM_PARALLEL (requêtes parallèles par modèle) multiplie la RAM de contexte allouée, ce qui peut surprendre si on augmente les deux variables en même temps.
Ollama est-il adapté pour traiter des données confidentielles ?
C'est précisément son avantage sur ce point. Aucune donnée n'est transmise vers l'extérieur une fois les modèles téléchargés. Toute l'inférence se fait sur votre infrastructure. Pour les données relevant du RGPD, des données de santé ou du code propriétaire, l'inférence locale supprime le risque de transfert hors UE et élimine la nécessité de contrats de sous-traitance avec un hébergeur cloud.
Comment mettre à jour Ollama sur Linux ?
L'installeur Linux ne configure pas d'auto-update. Pour mettre à jour, relancer le script d'installation : curl -fsSL https://ollama.com/install.sh | sh. Avant une mise à jour majeure, supprimer les anciennes librairies avec sudo rm -rf /usr/lib/ollama pour éviter les conflits.
