13 min de lecture 22 août 2026

Installer Ollama avec Docker : CPU, GPU, volumes et vérifications API

Un parcours pratique pour exécuter Ollama dans Docker sans perdre les modèles ni confondre le réseau de l'hôte avec celui du conteneur.

Équipe éditoriale d'Odysseus AI Wiki
Équipe éditoriale d'Odysseus AI Wiki
Documentation technique et vérification indépendantes
Illustration conceptuelle d'un modèle Ollama dans un conteneur Docker avec CPU, GPU, stockage et hôte local
Docker ajoute une frontière autour du runtime Ollama ; le stockage, le calcul et le réseau doivent rester des choix explicites.

Réponse courte: Oui, Ollama peut fonctionner dans Docker. Le réglage le plus fiable utilise un volume nommé pour /root/.ollama, ne publie le port que si nécessaire et choisit un parcours CPU ou GPU adapté à l'hôte. Vérifiez le conteneur, /api/tags et une petite requête de modèle avant de connecter une autre application.

Dans ce tutoriel

La recherche installer Ollama avec Docker recouvre généralement trois décisions : où stocker les modèles, comment le conteneur rejoint l'hôte ou un autre service, et s'il faut utiliser le CPU ou un GPU disponible. Commencez par le chemin minimal. Lancez l'image officielle avec un volume nommé, vérifiez l'API locale, puis ajoutez les options GPU ou une seconde application seulement lorsque le conteneur de base fonctionne.

Ce que change Ollama dans Docker

Ollama ressemble normalement à un service local : une commande lance le runtime, les modèles sont stockés sur la machine et les clients utilisent le port 11434. Docker place ce service dans un conteneur avec son propre système de fichiers, ses processus, son réseau et son cycle de vie. Le déploiement devient reproductible, mais un modèle resté dans la couche inscriptible du conteneur peut disparaître quand le conteneur est supprimé.

Un docker run fonctionnel n'est donc pas toute la configuration. Décidez si Docker sera le seul runtime Ollama, si une application de l'hôte ou un autre conteneur l'appellera et si les téléchargements doivent survivre à une mise à jour. Gardez ces limites visibles avant d'ajouter OpenCode, un hôte MCP, une interface web ou un client distant.

Le cycle de vie du conteneur n'est pas le stockage des modèles

Vous pouvez remplacer le conteneur sans perdre les modèles lorsque /root/.ollama est monté hors de la couche inscriptible. Utilisez pour cela un volume nommé ou un bind mount choisi consciemment.

Choisir le parcours CPU, NVIDIA GPU ou AMD GPU

Commencez par le CPU lorsque vous vérifiez le réseau, les volumes ou une nouvelle machine. Ce parcours comporte moins de dépendances et fournit une base propre pour comparer le temps de chargement et la vitesse de réponse. Une fois l'API fonctionnelle, passez à la commande d'accélérateur documentée pour votre hôte plutôt que de copier des options Docker provenant d'une autre configuration.

Les conteneurs NVIDIA dépendent généralement d'un pilote hôte fonctionnel et du NVIDIA Container Toolkit. Les déploiements AMD peuvent utiliser un autre tag d'image et un autre mappage de périphériques ; la compatibilité dépend du système, du runtime et de la documentation Ollama actuelle. Considérez le GPU comme une optimisation : endpoint, volume et contrôles de santé doivent rester identiques.

Vérifier Docker
docker version
Vérifier un GPU NVIDIA de l'hôte
docker run --rm --gpus=all nvidia/cuda:12.0.0-base-ubuntu22.04 nvidia-smi
Parcours À utiliser quand Vérification importante
CPU Vous voulez la base la plus simple ou aucun accélérateur compatible Vérifier l'API et une petite réponse avant le réglage des performances
NVIDIA GPU Le pilote hôte et NVIDIA Container Toolkit fonctionnent déjà Vérifier que Docker voit le GPU avant de charger un gros modèle
AMD GPU L'hôte et l'image Ollama prennent en charge le parcours ROCm requis Suivre les exigences actuelles d'image et de périphériques
Hôte et conteneur Un autre service appelle Ollama sur un réseau Docker Utiliser le nom du service dans le réseau, pas la boucle locale de l'hôte

Créer un stockage persistant pour les modèles

Un volume nommé est le choix par défaut le plus simple pour Ollama dans Docker : Docker gère l'emplacement et le conteneur peut être remplacé sans copier les modèles manuellement. L'image officielle conserve les données Ollama sous /root/.ollama ; montez donc toujours le volume à cet endroit. Ne créez pas un second volume lors d'une mise à jour si vous souhaitez garder la même bibliothèque.

Un bind mount est utile si vous devez contrôler l'espace disque sur un lecteur précis ou sauvegarder un dossier connu de l'hôte. Il ajoute cependant des questions de chemins et de permissions. Pour un premier déploiement, le volume nommé est généralement plus facile à expliquer et plus difficile à casser.

Un volume n'est pas une sauvegarde

Un volume protège les modèles contre le remplacement du conteneur, mais ne crée pas automatiquement une seconde copie. Sauvegardez ou reconstruisez le volume volontairement si la bibliothèque compte.

Schéma conceptuel montrant des clients hôtes reliés à un conteneur Ollama Docker, un volume persistant et un réseau externe séparé
Le chemin applicatif, la frontière du conteneur, le volume persistant et le réseau sortant sont des décisions distinctes.
Créer un volume nommé
docker volume create ollama-data
Démarrer le conteneur CPU avec stockage persistant
docker run -d --name ollama -p 11434:11434 -v ollama-data:/root/.ollama ollama/ollama
Télécharger un modèle dans le conteneur
docker exec -it ollama ollama pull <model-name>

Démarrer le conteneur et vérifier l'API

Après l'obtention de l'identifiant du conteneur, vérifiez son état avant de télécharger un gros modèle. docker ps montre si le processus tourne encore et docker logs peut révéler un problème de port, de permission ou de runtime. Interrogez ensuite /api/tags depuis l'hôte. Une réponse réussie prouve que l'endpoint HTTP est joignable, pas que chaque modèle est chargé ou que chaque client est autorisé.

Utilisez une petite requête de modèle comme deuxième contrôle. Vous séparez ainsi un listener HTTP sain d'un chemin de modèle fonctionnel. Si l'API répond mais que la requête du modèle échoue, vérifiez le nom du modèle, l'espace disque, la mémoire et les logs avant de modifier le réseau.

  1. Vérifier le processus

    Confirmez que le conteneur est Up et que le port publié est bien celui prévu.

  2. Vérifier l'endpoint

    Demandez /api/tags depuis la machine qui publie le port 11434 et notez le code d'état.

  3. Vérifier un modèle

    Téléchargez un petit modèle et envoyez une requête sans risque avant de connecter un éditeur ou un agent.

Vérifier l'état du conteneur
docker ps --filter name=ollama
Lire les logs récents
docker logs ollama --tail 100
Vérifier l'API locale
curl http://127.0.0.1:11434/api/tags
Lister les modèles dans le conteneur
docker exec -it ollama ollama list

Connecter les applications sans confondre localhost

La bonne URL Ollama dépend de l'emplacement du client. Une application de bureau sur le même hôte peut généralement appeler http://127.0.0.1:11434 lorsque Docker publie le port. Un autre conteneur du même réseau Docker doit appeler le service Ollama par son nom Compose et son port, par exemple http://ollama:11434. Dans un conteneur, 127.0.0.1 désigne ce conteneur et non automatiquement l'hôte Windows, macOS ou Linux.

Pour un client distant, utilisez une adresse protégée et une règle de pare-feu explicite. Ne publiez pas le port 11434 sur Internet simplement pour faire fonctionner une application de test. Documentez la route, l'authentification ou le réseau privé et le service de modèles exact que le client peut atteindre.

Emplacement du client Endpoint courant Erreur fréquente
Bureau sur l'hôte http://127.0.0.1:11434 Utiliser un nom de service Docker depuis l'application hôte
Autre service Compose http://ollama:11434 Utiliser localhost, qui revient au conteneur appelant
Autre machine Adresse privée et filtrée de l'hôte Publier une API sans authentification sur une interface publique
Odysseus ou un éditeur Endpoint indiqué par les réglages du fournisseur Modifier l'endpoint avant que le test API de base réussisse

Protéger modèles, contexte et exposition

Docker ne rend pas automatiquement un service Ollama privé. Un port publié peut être lié à toutes les interfaces selon la commande et les valeurs par défaut de l'hôte. Pour un test réservé à l'hôte, préférez une liaison loopback comme -p 127.0.0.1:11434:11434. Si un service Compose doit utiliser l'API en interne, gardez-le sur un réseau privé et ne publiez pas de port hôte inutile.

La longueur de contexte, la concurrence et la mémoire GPU changent la consommation RAM ou VRAM du conteneur. Augmentez une seule variable à la fois et observez docker stats, la mémoire de l'hôte et le comportement des réponses. Gardez les secrets hors des images, de l'historique shell, des captures et des fichiers Compose versionnés ; un endpoint local et un outil de recherche externe n'ont pas la même frontière de confidentialité.

Contrôle Pourquoi Valeur plus sûre
Liaison du port Détermine quelles interfaces atteignent l'API Lier à loopback pour un test local
Chemin du volume Détermine si les modèles survivent au remplacement Utiliser un volume nommé documenté
Contexte et concurrence Peuvent multiplier la mémoire par requête Commencer bas et mesurer avant d'augmenter
Outils externes Peuvent envoyer prompts ou contenu hors de l'hôte Vérifier le fournisseur et limiter les permissions

Dépanner les échecs de santé, GPU, volume et API

Quand un déploiement Ollama Docker échoue, modifiez une seule couche à la fois. Vérifiez d'abord Docker, puis la durée de vie du conteneur Ollama, ensuite le volume, l'API, le modèle et enfin l'application cliente. Remplacer toute la commande après chaque erreur empêche de voir la frontière réellement défaillante.

Les problèmes GPU viennent souvent du runtime de l'hôte plutôt que de l'API Ollama. Un conteneur peut répondre à /api/tags tout en utilisant le CPU si le GPU n'a pas été transmis, si le pilote est incompatible ou si l'image ne correspond pas à l'hôte. Si un modèle disparaît après recréation, comparez docker inspect et la destination /root/.ollama avant de le télécharger à nouveau.

Supprimer le conteneur ne supprime pas le volume

La dernière commande ne retire que le conteneur. N'exécutez pas docker volume rm ollama-data avant d'avoir confirmé que les modèles ne sont plus nécessaires ou qu'ils sont sauvegardés.

Illustration conceptuelle de dépannage Ollama Docker avec parcours CPU et GPU, volume persistant, signal de santé et protection réseau
Diagnostiquez dans cet ordre : runtime, calcul, stockage, endpoint et exposition.
Inspecter les mounts et ports
docker inspect ollama
Observer les ressources
docker stats ollama
Arrêter et supprimer seulement le conteneur
docker stop ollama && docker rm ollama
Symptôme Frontière probable Contrôle suivant
Le conteneur s'arrête immédiatement Image, commande, permissions ou runtime Lire docker logs ollama et le code de sortie
Connexion API refusée Liaison du port ou santé du processus Vérifier docker ps, ports publiés et /api/tags
Modèle disparu Volume incorrect ou absent Comparer les mounts de docker inspect et /root/.ollama
Le flag GPU échoue Pilote hôte ou runtime du conteneur Lancer le plus petit test GPU du fournisseur
L'hôte fonctionne mais pas le client conteneurisé Namespace réseau Remplacer localhost par le nom du service Compose
Les requêtes consomment trop de mémoire Contexte, concurrence ou taille du modèle Réduire un réglage et observer les métriques

Questions fréquentes sur Ollama dans Docker

Oui. Le parcours officiel démarre le service dans un conteneur. Les points essentiels sont l'image, le volume /root/.ollama, le runtime CPU ou accéléré et l'endpoint utilisé par le client.

Créez un volume nommé, démarrez l'image officielle avec le port 11434 et montez le volume vers /root/.ollama. Vérifiez docker ps et /api/tags avant de télécharger un modèle. Pour le GPU, utilisez la documentation officielle actuelle.

Vous pouvez concevoir une stratégie de stockage partagée, mais deux runtimes ne devraient pas écrire sans coordination dans le même dossier. Un propriétaire clair, une sauvegarde et une migration documentée réduisent les problèmes de verrouillage et de permissions.

Utilisez le CPU comme base pour valider l'installation. NVIDIA ou AMD conviennent lorsque pilote, runtime, image et périphériques sont compatibles ensemble. Le parcours GPU doit conserver le même volume et les mêmes contrôles API.

Les clients utilisent des namespaces réseau différents. L'hôte peut utiliser 127.0.0.1:11434 si le port est publié ; un service Compose doit généralement utiliser http://ollama:11434.

Utilisez la variable d'environnement et la configuration documentées pour votre version d'Ollama, puis recréez le conteneur avec le même volume. Augmentez progressivement et surveillez la mémoire.

Ne le supposez pas. Vérifiez l'adresse de liaison et le pare-feu. Pour un usage local, liez le port à loopback ; pour les services internes, utilisez un réseau Docker privé et évitez un port public inutile.

Références officielles

  1. Documentation Docker d'Ollama - Images de conteneur et indications officielles
  2. Documentation de l'API Ollama - Référence officielle des endpoints et requêtes
  3. GPU avec Docker Compose - Réservation GPU et configuration Compose officielles

Ressources IA locale associées

Dernière mise à jour : 22 août 2026

Retour à l'accueil