Docker permet de démarrer Ollama sans installer son serveur directement dans votre système, mais le conteneur ne règle pas tout : les modèles occupent de l’espace et doivent survivre aux mises à jour, tandis que l’API ne devrait pas être exposée par inadvertance. Pour un usage sur votre PC, retenez trois réglages concrets : un volume nommé pour les données, une configuration adaptée au CPU ou au GPU, et une publication du port liée à l’interface locale.
Pourquoi mettre Ollama dans un conteneur ?
Docker sépare l’exécution du serveur Ollama de celle des autres logiciels de votre PC et rend son démarrage reproductible. Vous gardez une commande pour lancer le service, une autre pour télécharger ou exécuter un modèle, et vous pouvez remplacer le conteneur sans réinstaller Ollama sur l’hôte. Cela ne signifie pas que les modèles sont enfermés avec lui : leur emplacement doit être monté séparément pour que leurs fichiers persistent.
Pour distinguer ce déploiement des usages plus larges de l’intelligence artificielle, concentrez-vous sur trois questions pratiques : où sont stockés les modèles, quel matériel le conteneur peut employer, et depuis quelles machines l’API est joignable.
Que faut-il persister pour ne pas perdre les modèles ?
L’exemple CPU de la documentation Docker d’Ollama monte un volume nommé ollama dans /root/.ollama, puis publie le port 11434. Les modèles téléchargés et les données d’Ollama restent ainsi dans un stockage distinct de la couche modifiable du conteneur. Vous pouvez reprendre ce principe avec une commande locale :
docker run -d \
--name ollama \
-v ollama:/root/.ollama \
-p 127.0.0.1:11434:11434 \
ollama/ollama
Le volume ollama est créé s’il n’existe pas. Pour le premier essai, lancez un modèle dans le conteneur :
docker exec -it ollama ollama run llama3.2
La commande télécharge le modèle si nécessaire, puis ouvre la conversation dans le terminal. Dans une autre fenêtre, docker ps permet de vérifier que le conteneur tourne. Le stockage est indépendant de son cycle de vie : la documentation Docker indique qu’un volume conserve ses données même après la suppression du conteneur qui l’utilisait. Pour le retirer volontairement, utilisez l’outil Docker de gestion des volumes et contrôlez soigneusement la cible avant l’opération.
Un volume nommé est le choix simple lorsque Docker gère les fichiers. Un montage de dossier de l’hôte, aussi appelé bind mount, est plus indiqué si vous avez besoin de parcourir directement ces fichiers depuis le système. Selon la documentation Docker sur les volumes, les volumes sont gérés par Docker et peuvent être sauvegardés ou déplacés ; un dossier monté dépend, lui, du chemin présent sur l’hôte. Pour les modèles Ollama, ne choisissez pas un chemin au hasard : faites correspondre le répertoire de données utilisé dans le conteneur et le stockage que vous voulez conserver.
Le CPU suffit-il ou faut-il configurer le GPU ?
Le mode CPU est le point de départ le plus simple : la commande précédente ne demande aucun périphérique graphique particulier. Elle convient pour valider le réseau, la persistance et l’accès à l’API. La vitesse de génération dépend ensuite du modèle, de sa taille et des ressources disponibles. Tester le même modèle après le démarrage permet de mesurer votre configuration au lieu de présumer qu’un conteneur accélérera automatiquement l’inférence.
Pour un GPU NVIDIA sous Linux, Ollama demande le NVIDIA Container Toolkit ; sa documentation donne aussi la commande --gpus=all pour rendre les GPU disponibles au conteneur. Une fois le toolkit configuré pour Docker, adaptez la commande :
docker run -d \
--name ollama \
--gpus=all \
-v ollama:/root/.ollama \
-p 127.0.0.1:11434:11434 \
ollama/ollama
Le GPU doit être pris en charge par l’hôte et par l’environnement Docker : ajouter l’option ne remplace ni le pilote ni le runtime nécessaire. Pour une carte AMD, Ollama documente plutôt l’image ollama/ollama:rocm et l’accès aux périphériques /dev/kfd et /dev/dri. La même page décrit aussi une option Vulkan, qui requiert que les périphériques graphiques soient accessibles au conteneur. Ces configurations ne sont pas interchangeables : suivez celle correspondant à votre système, et commencez par confirmer que Docker voit la carte avant de chercher une erreur dans Ollama.
Sur macOS, le conteneur peut démarrer en CPU, mais la documentation FAQ d’Ollama précise que Docker Desktop ne fournit pas le passthrough GPU nécessaire à l’accélération GPU d’Ollama. Si votre priorité est d’exploiter le GPU Apple, le conteneur n’est donc pas le bon chemin pour cette accélération ; l’exécution d’Ollama hors Docker est à comparer. Pour poursuivre côté usage local, lancer un modèle Gemma avec Ollama est un cas distinct de cette configuration de conteneur.
Comment garder l’API accessible uniquement sur votre PC ?
Le port 11434 est celui publié par les exemples Ollama. La syntaxe Docker -p hôte:conteneur relie un port de l’hôte au port interne du conteneur. Si vous écrivez seulement -p 11434:11434, Docker publie par défaut sur toutes les adresses de l’hôte. La documentation Docker sur la publication des ports avertit que les ports publiés sont accessibles depuis l’extérieur de l’hôte, sauf restriction appropriée. Le préfixe 127.0.0.1: dans la commande limite l’écoute à l’interface de boucle locale : utilisez alors http://127.0.0.1:11434 depuis le PC qui héberge Docker.
Cette restriction est importante parce qu’une API locale n’est pas automatiquement protégée par un mot de passe. Pour une interface web ou une application dans un autre conteneur, placez les services sur un réseau Docker partagé et faites-les communiquer par leur nom de service, sans publier le port Ollama à tout le réseau. Si un autre appareil doit y accéder, décidez explicitement quelle interface doit recevoir les connexions, puis vérifiez le pare-feu et les règles du routeur. Ne confondez pas « local au conteneur », « accessible sur le PC » et « disponible sur Internet ».
Comment tester le résultat et diagnostiquer un échec ?
Commencez par vérifier l’état du service et son journal :
docker ps --filter name=ollama
docker logs ollama
Puis, depuis l’hôte, demandez la liste des modèles via l’API :
curl http://127.0.0.1:11434/api/tags
Une réponse valide confirme que le port local transmet les requêtes à Ollama ; une liste vide peut simplement signifier qu’aucun modèle n’a encore été téléchargé. Après avoir lancé un modèle, docker exec -it ollama ollama ps indique s’il est chargé et si le processeur d’inférence est le CPU, le GPU ou une combinaison des deux. Si l’API ne répond pas, vérifiez dans l’ordre que le conteneur est démarré, que son port est publié, puis que l’adresse demandée correspond au réglage local.
Si la carte graphique n’est pas utilisée, séparez le diagnostic en étapes : testez d’abord l’accès au GPU depuis Docker, contrôlez ensuite les options et périphériques transmis au conteneur, puis consultez ses journaux. Enfin, pour valider la persistance, arrêtez et recréez le conteneur en réutilisant exactement le même volume nommé, puis vérifiez la présence du modèle avec ollama list. Évitez de supprimer le volume pendant ce test : c’est précisément lui qui conserve les téléchargements.
Questions fréquentes
Les modèles Ollama sont-ils téléchargés à nouveau après chaque redémarrage ?
Non, pas si le répertoire de données du conteneur est monté dans un volume Docker persistant, comme dans l’exemple avec `ollama:/root/.ollama`. Arrêter puis recréer le conteneur ne supprime pas, à lui seul, le volume nommé. En revanche, supprimer explicitement ce volume efface les données qu’il contient : vérifiez le nom de la cible avant toute commande de nettoyage.
Puis-je accéder à Ollama depuis un autre appareil de la maison ?
Oui, mais cela demande de publier le port sur une adresse réseau accessible depuis cet appareil, plutôt que de le lier uniquement à `127.0.0.1`. Cette ouverture peut rendre l’API joignable au-delà du PC selon votre réseau et votre pare-feu. N’exposez pas le port sur Internet sans mettre en place une protection adaptée et comprendre les règles de routage de votre réseau.
Comment savoir si Ollama utilise vraiment la carte graphique ?
Après avoir lancé un modèle, exécutez `ollama ps` dans le conteneur avec `docker exec`. La colonne `PROCESSOR` indique la répartition entre CPU et GPU : elle peut signaler une utilisation complète de l’un ou de l’autre, ou un partage. Si le GPU n’apparaît pas, vérifiez d’abord que Docker sait lui-même accéder au matériel, puis examinez les journaux du conteneur.
