Installer une IA locale avec Docker, Ollama et Open WebUI sur Fedora

Retour d’expérience : accélération NVIDIA, volumes SELinux, conflit du port 11434 et intégration dans mon Homelab NVSD.

En bref

J’ai installé sur mon Acer Predator une stack d’intelligence artificielle entièrement locale composée de Docker, Ollama et Open WebUI. L’inférence est accélérée par une NVIDIA GeForce GTX 1650 de 4 Go, tandis que les modèles, les conversations et la configuration sont conservés sous /srv/homelab.

Cette installation m’a permis de valider un assistant privé pour le code, Docker et le dépannage technique. Elle m’a aussi confronté à deux difficultés très concrètes : les permissions SELinux sur Fedora et un conflit entre Ollama installé sur l’hôte et Ollama exécuté dans Docker.

Élément	Configuration retenue
Machine	Acer Predator
Système	Fedora Silverblue 44 avec KDE Plasma
GPU	NVIDIA GeForce GTX 1650 – 4 Go de VRAM
Mémoire	Environ 15 Go de RAM
Conteneurs	ollama et open-webui
Interface	http://localhost:3000
API Ollama	http://localhost:11434
Modèles utilisés	gemma3:4b et qwen2.5-coder:7b
Données locales	/srv/homelab/stacks/ai/ollama/data et /srv/homelab/stacks/open-webui/data

Note de contexte – Cet article documente l’état réellement validé sur ma machine en août 2026. Les commandes restent à adapter si les pilotes NVIDIA, Docker ou les chemins du Homelab sont différents.

Pourquoi intégrer une IA locale au Homelab ?

Mon projet NVSD Homelab s’est construit autour d’une séparation simple :

• le poste Fedora sert au développement, aux essais et à la validation locale ;
• le VPS Ubuntu chez Infomaniak héberge les services publics et le site WordPress ;
• Docker fournit un format commun pour organiser, déplacer et maintenir les services.

L’IA locale trouve naturellement sa place sur le poste Fedora. C’est là que se trouve la carte graphique, et c’est aussi là que je travaille sur mes fichiers Compose, mes applications web et le contenu du Homelab.

Mes objectifs étaient précis :

• conserver les conversations et les requêtes techniques sur ma machine ;
• disposer d’un assistant même sans service cloud ;
• utiliser la même logique Docker que pour mes autres stacks ;
• expérimenter plusieurs modèles sans modifier directement le système ;
• connecter ensuite l’IA à mon environnement de développement.

L’objectif n’était pas de reproduire un grand service d’IA en ligne. Avec 4 Go de VRAM, il fallait plutôt construire un système raisonnable, spécialisé et stable.

Architecture finale

J’ai choisi deux conteneurs séparés :

1. Ollama charge les modèles et expose l’API d’inférence sur le port 11434.
2. Open WebUI fournit l’interface web sur le port 3000 et communique avec Ollama par le réseau Docker ai.

Le réseau proxy permet d’intégrer Open WebUI à Nginx Proxy Manager si je souhaite lui attribuer plus tard un nom local. L’API Ollama n’a pas besoin d’être exposée publiquement.

Deux services isolés, un réseau privé et des données persistantes : la même logique que pour les autres stacks du Homelab.

Composant	Rôle	Persistance
Ollama	Téléchargement et exécution des modèles	/root/.ollama dans le conteneur
Open WebUI	Interface, comptes, conversations, fichiers et base locale	/app/backend/data dans le conteneur
Réseau ai	Communication interne entre les deux services	Réseau Docker externe
Réseau proxy	Accès éventuel par Nginx Proxy Manager	Réseau Docker externe

Cette séparation rend les mises à jour plus simples : je peux remplacer l’image d’Open WebUI sans toucher aux modèles, ou redémarrer Ollama sans perdre mes conversations.

1. Vérifier Docker et la carte NVIDIA

Avant de créer la stack, j’ai vérifié le fonctionnement du pilote sur l’hôte :

nvidia-smi

Dans mon cas, la GTX 1650 était détectée avec le pilote NVIDIA 610.43.03. J’ai ensuite contrôlé Docker et Compose :

docker version
docker compose version
docker info | sed -n '/Runtimes/p'

Ollama a besoin du NVIDIA Container Toolkit pour accéder au GPU depuis Docker. Après installation du paquet, la configuration du runtime se fait ainsi :

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Le test le plus utile consiste à lancer nvidia-smi dans un conteneur CUDA :

docker run --rm --gpus all \
  nvidia/cuda:12.8.0-base-ubuntu22.04 \
  nvidia-smi

Si la carte apparaît ici, la base est saine. Si ce test échoue, il est inutile de chercher le problème dans Ollama : il faut d’abord corriger le runtime NVIDIA.

La GTX 1650 n’est pas une carte dédiée à l’IA, mais elle suffit pour expérimenter avec des modèles compacts.

2. Préparer l’arborescence et les réseaux

J’avais déjà déplacé les services du Homelab hors de mon dossier personnel, sous /srv/homelab. Ce choix évite de disperser les données techniques dans /home et prépare l’ajout de nouvelles stacks.

sudo mkdir -p /srv/homelab/stacks/ai/ollama/data
sudo mkdir -p /srv/homelab/stacks/open-webui/data

sudo chown -R "$(id -u):$(id -g)" \
  /srv/homelab/stacks/ai/ollama \
  /srv/homelab/stacks/open-webui

Les deux projets utilisent un réseau commun nommé ai. Open WebUI rejoint également le réseau proxy, déjà utilisé par Nginx Proxy Manager.

docker network inspect ai >/dev/null 2>&1 || docker network create ai
docker network inspect proxy >/dev/null 2>&1 || docker network create proxy

L’arborescence utile devient alors :

/srv/homelab/stacks/
├── ai/
│   └── ollama/
│       ├── compose.yaml
│       └── data/
└── open-webui/
    ├── compose.yaml
    └── data/

3. Déployer Ollama avec le GPU

Le fichier /srv/homelab/stacks/ai/ollama/compose.yaml contient le moteur d’inférence :

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped

    ports:
      - "11434:11434"

    volumes:
      - ./data:/root/.ollama:Z

    environment:
      OLLAMA_KEEP_ALIVE: 24h
      OLLAMA_MAX_LOADED_MODELS: 1
      OLLAMA_MAX_QUEUE: 512
      OLLAMA_NUM_PARALLEL: 1
      OLLAMA_ORIGINS: "*"

    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

    healthcheck:
      test: ["CMD-SHELL", "ollama list >/dev/null 2>&1 || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

    networks:
      - ai

networks:
  ai:
    external: true

Les paramètres correspondent aux limites de ma machine :

Paramètre	Valeur	Pourquoi
OLLAMA_KEEP_ALIVE	24h	Évite de recharger constamment le modèle pendant une session de travail
OLLAMA_MAX_LOADED_MODELS	1	Empêche plusieurs modèles de saturer les 4 Go de VRAM
OLLAMA_NUM_PARALLEL	1	Évite plusieurs inférences simultanées sur un GPU limité
count	1	Réserve une seule carte NVIDIA au conteneur

Je lance ensuite la stack depuis Dockge ou directement en ligne de commande :

cd /srv/homelab/stacks/ai/ollama
docker compose up -d
docker compose ps
docker compose logs --tail=100 ollama

Puis je vérifie que le conteneur voit réellement le GPU :

docker exec ollama nvidia-smi

4. Déployer Open WebUI

Le fichier /srv/homelab/stacks/open-webui/compose.yaml contient l’interface :

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped

    ports:
      - "3000:8080"

    volumes:
      - ./data:/app/backend/data:Z

    environment:
      OLLAMA_BASE_URL: http://ollama:11434
      WEBUI_AUTH: "True"
      REQUEST_TIMEOUT: "120"
      ENABLE_UPDATES: "False"

    networks:
      - ai
      - proxy

networks:
  ai:
    external: true
  proxy:
    external: true

Le nom ollama est résolu automatiquement sur le réseau Docker ai. Open WebUI ne doit donc pas utiliser localhost:11434 : depuis son conteneur, localhost désignerait Open WebUI lui-même.

cd /srv/homelab/stacks/open-webui
docker compose up -d
docker compose ps
docker compose logs --tail=100 open-webui

L’interface est ensuite disponible à l’adresse :

http://localhost:3000

Le premier compte créé devient administrateur. Toutes les données de l’interface restent dans le dossier data, notamment la base webui.db, les fichiers téléversés et les données utilisées par les fonctions de recherche documentaire.

5. Le premier incident : deux Ollama pour un seul port

La difficulté la plus importante n’est pas venue du GPU. Une ancienne installation d’Ollama fonctionnait encore comme service systemd sur Fedora, alors que je venais de démarrer la version Docker.

Les symptômes étaient trompeurs :

• le port 11434 était déjà occupé ;
• Open WebUI ne voyait pas les modèles attendus ;
• les commandes lancées sur l’hôte et dans le conteneur ne retournaient pas la même liste ;
• un redémarrage du conteneur ne corrigeait pas le problème.

Un seul port, deux instances : le conflit entre le service hôte et le conteneur expliquait les incohérences.

J’ai commencé par identifier précisément le processus à l’écoute :

sudo ss -tlnp | grep ':11434'
systemctl status ollama --no-pager
docker ps --filter name=ollama

Comme j’avais décidé de conserver uniquement la version Docker, j’ai arrêté et désactivé le service de l’hôte :

sudo systemctl disable --now ollama

J’ai ensuite vérifié que le port était libre, puis redémarré la stack :

sudo ss -tlnp | grep ':11434' || true

cd /srv/homelab/stacks/ai/ollama
docker compose up -d

curl -s http://localhost:11434/api/tags | jq -r '.models[].name'

Cette résolution a également clarifié l’architecture : Ollama est désormais géré par Docker, ses modèles sont persistés dans la stack et le service hôte ne doit plus redémarrer en parallèle.

6. Le second incident : les volumes et SELinux

Fedora active SELinux, ce qui protège l’hôte mais peut bloquer un conteneur qui tente d’écrire dans un bind mount. Les symptômes prennent souvent la forme d’un dossier illisible, d’un fichier impossible à créer ou d’une erreur permission denied malgré des permissions Unix qui semblent correctes.

La correction retenue est visible dans les deux fichiers Compose :

volumes:
  - ./data:/root/.ollama:Z

et :

volumes:
  - ./data:/app/backend/data:Z

Le suffixe :Z demande un étiquetage SELinux privé pour le conteneur. Il convient aux données propres à un service. Le suffixe :z sert plutôt lorsqu’un même dossier doit être partagé entre plusieurs conteneurs.

Pour contrôler les labels :

ls -Zd /srv/homelab/stacks/ai/ollama/data
ls -Zd /srv/homelab/stacks/open-webui/data

Je limite volontairement le relabeling aux dossiers de données de la stack. Il ne faut jamais appliquer :Z à un dossier système large comme /usr, /home ou /.

7. Télécharger des modèles adaptés à 4 Go de VRAM

La GTX 1650 impose de rester réaliste. Un modèle peut être stocké sur disque sans tenir entièrement dans la VRAM, mais l’exécution devient plus lente si une partie du calcul est déportée vers la RAM et le processeur.

J’ai conservé deux modèles complémentaires :

docker exec -it ollama ollama pull gemma3:4b
docker exec -it ollama ollama pull qwen2.5-coder:7b
docker exec ollama ollama list

Modèle	Taille observée	Usage principal	Comportement sur la GTX 1650
gemma3:4b	Environ 3,3 Go	Questions générales et explications	Le plus confortable pour 4 Go de VRAM
qwen2.5-coder:7b	Environ 4,7 Go	Docker, Python, HTML et assistance au code	Plus lourd, avec déport partiel possible vers la RAM/CPU

Le point important n’est pas de collectionner les modèles, mais d’en choisir un ou deux adaptés aux tâches réelles. OLLAMA_MAX_LOADED_MODELS=1 évite qu’ils restent chargés simultanément.

8. Créer des profils spécialisés dans Open WebUI

J’utilise Open WebUI comme une interface commune, puis j’adapte le message système au type de travail :

Profil	Usage
Docker Expert	Compose, Dockerfile, healthchecks et réseaux
Stack Architect	Architecture multi-conteneurs et persistance
Frontend Specialist	HTML, CSS et JavaScript
Troubleshooting	Analyse progressive d’erreurs et de journaux
Teacher Mode	Explications pédagogiques et étapes vérifiables
Universal	Questions techniques générales

Exemple de message système pour les tâches Docker :

Tu es un assistant spécialisé dans Docker et les homelabs Linux.

Quand tu proposes une solution :
- commence par expliquer le diagnostic ;
- fournis des commandes vérifiables ;
- préserve les volumes et les données existantes ;
- distingue les réseaux internes des services exposés ;
- ajoute un healthcheck lorsque l’image le permet ;
- indique toujours comment vérifier le résultat et revenir en arrière.

Cette spécialisation est plus utile qu’un prompt très long : elle fixe quelques règles cohérentes avec la manière dont je maintiens le Homelab.

9. Connecter l’IA locale à Continue dans VS Code

Une fois l’API Ollama stabilisée, j’ai relié les modèles locaux à l’extension Continue dans VS Code. qwen2.5-coder:7b est utilisé pour le code et l’autocomplétion, tandis que gemma3:4b sert au dialogue technique plus général.

Exemple de configuration config.yaml :

name: NVSD Local AI
version: 1.0.0
schema: v1

models:
  - name: Gemma 3 4B - Local
    provider: ollama
    model: gemma3:4b
    apiBase: http://localhost:11434
    roles:
      - chat
      - edit
    defaultCompletionOptions:
      contextLength: 4096

  - name: Qwen 2.5 Coder 7B - Local
    provider: ollama
    model: qwen2.5-coder:7b
    apiBase: http://localhost:11434
    roles:
      - autocomplete
    defaultCompletionOptions:
      contextLength: 2048

Le contexte volontairement limité réduit la consommation mémoire et améliore la réactivité sur cette carte graphique. La valeur optimale dépend toutefois de la taille des fichiers et du type de tâche.

L’IA locale devient un outil du flux de développement, pas un service isolé de plus.

10. Vérifier et surveiller la stack

État des conteneurs

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Je dois retrouver au minimum :

ollama        Up ...        0.0.0.0:11434->11434/tcp
open-webui    Up ...        0.0.0.0:3000->8080/tcp

Modèles disponibles par l’API

curl -s http://localhost:11434/api/tags \
  | jq -r '.models[].name'

Utilisation du GPU

watch -n 2 \
  'nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu,temperature.gpu --format=csv'

Consommation des conteneurs

docker stats ollama open-webui

Journaux

docker logs --tail=100 -f ollama
docker logs --tail=100 -f open-webui

Pendant mes essais, un modèle chargé utilisait presque toute la VRAM disponible, généralement autour de 3,8 à 4,0 Go selon le modèle et le contexte. Le suivi avec nvidia-smi permet de distinguer un vrai calcul GPU d’une exécution presque entièrement déportée sur le processeur.

Résultats obtenus

Après correction des conflits et stabilisation des volumes :

Vérification	Résultat observé
GPU visible dans Docker	Oui, via docker exec ollama nvidia-smi
Interface Open WebUI	Accessible sur http://localhost:3000
API Ollama	Accessible sur http://localhost:11434
Persistance	Modèles et conversations conservés après recréation des conteneurs
Débit indicatif	Environ 5 à 8 tokens/s selon le modèle, le contexte et le déport CPU
Latence à chaud	Environ 0,5 à 2 secondes avant le début d’une réponse simple
Stabilité	Aucun crash observé pendant la session de validation finale

Ces chiffres décrivent mon matériel et mes tests. Ils ne constituent pas un benchmark universel : la quantification du modèle, la longueur du contexte, le pilote et le partage GPU/CPU changent fortement les performances.

Sauvegarder ce qui compte réellement

Les modèles Ollama sont volumineux, mais ils peuvent être téléchargés de nouveau. Les données les plus importantes se trouvent dans Open WebUI : comptes, conversations, réglages, fichiers et base locale.

Une sauvegarde minimale peut cibler le dossier Open WebUI :

sudo tar -czf \
  "/srv/homelab/backups/open-webui-$(date +%F).tar.gz" \
  -C /srv/homelab/stacks/open-webui \
  data

Pour un arrêt cohérent avant une sauvegarde complète :

cd /srv/homelab/stacks/open-webui
docker compose stop

sudo tar -czf \
  "/srv/homelab/backups/ai-local-complete-$(date +%F).tar.gz" \
  -C /srv/homelab/stacks \
  ai/ollama open-webui

docker compose start

L’archive complète inclut les modèles et peut donc devenir très volumineuse. Pour une sauvegarde distante fréquente, je privilégie Open WebUI et je conserve séparément la liste des modèles à retélécharger.

Ce que cette installation m’a appris

Un petit GPU impose de choisir

La GTX 1650 suffit pour apprendre, coder et tester, mais elle oblige à limiter la taille du modèle, le contexte et le parallélisme. Cette contrainte a finalement amélioré la lisibilité de la stack.

Docker ne supprime pas les conflits avec l’hôte

Un conteneur peut être parfaitement configuré et rester inaccessible si un service local occupe déjà son port. Le diagnostic doit toujours commencer par l’hôte : processus actifs, ports, volumes et permissions.

SELinux fait partie de l’architecture Fedora

Le désactiver aurait masqué le problème. L’ajout ciblé de :Z aux bind mounts conserve la protection du système tout en autorisant les conteneurs à travailler dans leurs propres dossiers.

L’IA locale complète le VPS au lieu de le remplacer

Le poste Fedora fournit le GPU et l’environnement de développement. Le VPS reste consacré aux services publics, au reverse proxy et au site WordPress. Cette séparation évite d’exposer inutilement l’API d’inférence sur Internet.

Perspectives

Cette première stack constitue une base pour plusieurs évolutions déjà envisagées dans le Homelab :

• sauvegarder automatiquement les conversations importantes ;
• affiner les profils Open WebUI pour Docker, WordPress et le développement web ;
• tester des modèles plus petits pour une autocomplétion plus rapide ;
• relier l’interface à un nom local derrière Nginx Proxy Manager ;
• réutiliser Ollama dans un futur assistant vocal privé, avec transcription et synthèse vocale ;
• documenter les performances de plusieurs modèles sur la même GTX 1650.

Conclusion

Cette installation a transformé l’Acer Predator en véritable nœud IA du Homelab. Ollama fournit une API locale simple, Open WebUI rend les modèles agréables à utiliser et Docker maintient l’ensemble cohérent avec mes autres services.

Le résultat le plus intéressant n’est pas seulement d’exécuter un LLM sans cloud. C’est d’avoir intégré l’IA à une architecture que je comprends, que je peux sauvegarder et que je suis capable de dépanner.

Avec une GTX 1650 de 4 Go, il faut accepter les limites. Mais pour générer du code, analyser une erreur Docker, préparer un fichier Compose ou expliquer un concept technique, cette stack locale remplit déjà son rôle.

---

Questions fréquentes

Peut-on utiliser cette stack sans GPU ?

Oui. Ollama peut fonctionner sur CPU, mais les réponses seront nettement plus lentes. Il suffit de retirer la réservation NVIDIA du fichier Compose.

Peut-on installer plusieurs modèles avec seulement 4 Go de VRAM ?

Oui. Le stockage des modèles dépend du disque, pas de la VRAM. En revanche, je ne charge qu’un seul modèle à la fois grâce à OLLAMA_MAX_LOADED_MODELS=1.

Pourquoi Open WebUI utilise-t-il http://ollama:11434 ?

Parce que les deux conteneurs partagent le réseau Docker ai. Le nom du conteneur devient un nom DNS interne. localhost ne fonctionnerait pas depuis Open WebUI pour joindre Ollama.

Où sont enregistrées les conversations ?

Elles sont persistées dans /srv/homelab/stacks/open-webui/data, avec la base webui.db et les autres données de l’interface.

Pourquoi ne pas installer Ollama directement sur Fedora ?

C’est possible, mais j’ai choisi Docker pour conserver la même méthode de gestion que pour le reste du Homelab. Le point essentiel est de ne pas laisser l’instance hôte et l’instance Docker actives simultanément sur le port 11434.

Sources officielles

• Installer Docker Engine sur Fedora
• Accès GPU avec Docker Compose
• Installer NVIDIA Container Toolkit
• Exécuter Ollama avec Docker
• Guide de démarrage Open WebUI
• Bind mounts Docker et labels SELinux
• Configurer Ollama dans Continue

---

Article rédigé à la première personne à partir de l’installation et des tests réalisés dans le Homelab NVSD.
Dernière mise à jour : 10 août 2026.