{"id":66,"date":"2026-08-10T22:23:04","date_gmt":"2026-08-10T20:23:04","guid":{"rendered":"https:\/\/homelab.nvsd.ch\/?p=66"},"modified":"2026-08-15T16:40:19","modified_gmt":"2026-08-15T14:40:19","slug":"installer-une-ia-locale-avec-docker-ollama-et-open-webui-sur-fedora","status":"publish","type":"post","link":"https:\/\/homelab.nvsd.ch\/?p=66","title":{"rendered":"Installer une IA locale avec Docker, Ollama et Open WebUI sur Fedora"},"content":{"rendered":"\n

Retour d\u2019exp\u00e9rience : acc\u00e9l\u00e9ration NVIDIA, volumes SELinux, conflit du port 11434 et int\u00e9gration dans mon Homelab NVSD.<\/em><\/p>\n\n\n\n

\"Une<\/figure>\n\n\n\n

En bref<\/h2>\n\n\n\n

J\u2019ai install\u00e9 sur mon Acer Predator une stack d\u2019intelligence artificielle enti\u00e8rement locale compos\u00e9e de Docker<\/strong>, Ollama<\/strong> et Open WebUI<\/strong>. L\u2019inf\u00e9rence est acc\u00e9l\u00e9r\u00e9e par une NVIDIA GeForce GTX 1650 de 4 Go<\/strong>, tandis que les mod\u00e8les, les conversations et la configuration sont conserv\u00e9s sous \/srv\/homelab<\/code>.<\/p>\n\n\n\n

Cette installation m\u2019a permis de valider un assistant priv\u00e9 pour le code, Docker et le d\u00e9pannage technique. Elle m\u2019a aussi confront\u00e9 \u00e0 deux difficult\u00e9s tr\u00e8s concr\u00e8tes : les permissions SELinux<\/strong> sur Fedora et un conflit entre Ollama install\u00e9 sur l\u2019h\u00f4te et Ollama ex\u00e9cut\u00e9 dans Docker.<\/p>\n\n\n\n

\u00c9l\u00e9ment<\/th>Configuration retenue<\/th><\/tr><\/thead>
Machine<\/td>Acer Predator<\/td><\/tr>
Syst\u00e8me<\/td>Fedora Silverblue 44 avec KDE Plasma<\/td><\/tr>
GPU<\/td>NVIDIA GeForce GTX 1650 – 4 Go de VRAM<\/td><\/tr>
M\u00e9moire<\/td>Environ 15 Go de RAM<\/td><\/tr>
Conteneurs<\/td>ollama<\/code> et open-webui<\/code><\/td><\/tr>
Interface<\/td>http:\/\/localhost:3000<\/code><\/td><\/tr>
API Ollama<\/td>http:\/\/localhost:11434<\/code><\/td><\/tr>
Mod\u00e8les utilis\u00e9s<\/td>gemma3:4b<\/code> et qwen2.5-coder:7b<\/code><\/td><\/tr>
Donn\u00e9es locales<\/td>\/srv\/homelab\/stacks\/ai\/ollama\/data<\/code> et \/srv\/homelab\/stacks\/open-webui\/data<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n

Note de contexte<\/strong> – Cet article documente l\u2019\u00e9tat r\u00e9ellement valid\u00e9 sur ma machine en ao\u00fbt 2026. Les commandes restent \u00e0 adapter si les pilotes NVIDIA, Docker ou les chemins du Homelab sont diff\u00e9rents.<\/p>\n<\/blockquote>\n\n\n\n

Pourquoi int\u00e9grer une IA locale au Homelab ?<\/h2>\n\n\n\n

Mon projet NVSD Homelab s\u2019est construit autour d\u2019une s\u00e9paration simple :<\/p>\n\n\n\n

    \n
  • le poste Fedora<\/strong> sert au d\u00e9veloppement, aux essais et \u00e0 la validation locale ;<\/li>\n\n\n\n
  • le VPS Ubuntu chez Infomaniak<\/strong> h\u00e9berge les services publics et le site WordPress ;<\/li>\n\n\n\n
  • Docker fournit un format commun pour organiser, d\u00e9placer et maintenir les services.<\/li>\n<\/ul>\n\n\n\n

    L\u2019IA locale trouve naturellement sa place sur le poste Fedora. C\u2019est l\u00e0 que se trouve la carte graphique, et c\u2019est aussi l\u00e0 que je travaille sur mes fichiers Compose, mes applications web et le contenu du Homelab.<\/p>\n\n\n\n

    Mes objectifs \u00e9taient pr\u00e9cis :<\/p>\n\n\n\n

      \n
    • conserver les conversations et les requ\u00eates techniques sur ma machine ;<\/li>\n\n\n\n
    • disposer d\u2019un assistant m\u00eame sans service cloud ;<\/li>\n\n\n\n
    • utiliser la m\u00eame logique Docker que pour mes autres stacks ;<\/li>\n\n\n\n
    • exp\u00e9rimenter plusieurs mod\u00e8les sans modifier directement le syst\u00e8me ;<\/li>\n\n\n\n
    • connecter ensuite l\u2019IA \u00e0 mon environnement de d\u00e9veloppement.<\/li>\n<\/ul>\n\n\n\n

      L\u2019objectif n\u2019\u00e9tait pas de reproduire un grand service d\u2019IA en ligne. Avec 4 Go de VRAM, il fallait plut\u00f4t construire un syst\u00e8me raisonnable, sp\u00e9cialis\u00e9 et stable<\/strong>.<\/p>\n\n\n\n

      Architecture finale<\/h2>\n\n\n\n

      J\u2019ai choisi deux conteneurs s\u00e9par\u00e9s :<\/p>\n\n\n\n

        \n
      1. Ollama<\/strong> charge les mod\u00e8les et expose l\u2019API d\u2019inf\u00e9rence sur le port 11434<\/code>.<\/li>\n\n\n\n
      2. Open WebUI<\/strong> fournit l\u2019interface web sur le port 3000<\/code> et communique avec Ollama par le r\u00e9seau Docker ai<\/code>.<\/li>\n<\/ol>\n\n\n\n

        Le r\u00e9seau proxy<\/code> permet d\u2019int\u00e9grer Open WebUI \u00e0 Nginx Proxy Manager si je souhaite lui attribuer plus tard un nom local. L\u2019API Ollama n\u2019a pas besoin d\u2019\u00eatre expos\u00e9e publiquement.<\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        Deux services isol\u00e9s, un r\u00e9seau priv\u00e9 et des donn\u00e9es persistantes : la m\u00eame logique que pour les autres stacks du Homelab.<\/em><\/p>\n\n\n\n

        Composant<\/th>R\u00f4le<\/th>Persistance<\/th><\/tr><\/thead>
        Ollama<\/td>T\u00e9l\u00e9chargement et ex\u00e9cution des mod\u00e8les<\/td>\/root\/.ollama<\/code> dans le conteneur<\/td><\/tr>
        Open WebUI<\/td>Interface, comptes, conversations, fichiers et base locale<\/td>\/app\/backend\/data<\/code> dans le conteneur<\/td><\/tr>
        R\u00e9seau ai<\/code><\/td>Communication interne entre les deux services<\/td>R\u00e9seau Docker externe<\/td><\/tr>
        R\u00e9seau proxy<\/code><\/td>Acc\u00e8s \u00e9ventuel par Nginx Proxy Manager<\/td>R\u00e9seau Docker externe<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

        Cette s\u00e9paration rend les mises \u00e0 jour plus simples : je peux remplacer l\u2019image d\u2019Open WebUI sans toucher aux mod\u00e8les, ou red\u00e9marrer Ollama sans perdre mes conversations.<\/p>\n\n\n\n

        1. V\u00e9rifier Docker et la carte NVIDIA<\/h2>\n\n\n\n

        Avant de cr\u00e9er la stack, j\u2019ai v\u00e9rifi\u00e9 le fonctionnement du pilote sur l\u2019h\u00f4te :<\/p>\n\n\n\n

        nvidia-smi<\/code><\/pre>\n\n\n\n
        Dans mon cas, la GTX 1650 \u00e9tait d\u00e9tect\u00e9e avec le pilote NVIDIA 610.43.03<\/code>. J\u2019ai ensuite contr\u00f4l\u00e9 Docker et Compose :<\/p>\n\n\n\n
        docker version\ndocker compose version\ndocker info | sed -n '\/Runtimes\/p'<\/code><\/pre>\n\n\n\n
        Ollama a besoin du NVIDIA Container Toolkit<\/strong> pour acc\u00e9der au GPU depuis Docker. Apr\u00e8s installation du paquet, la configuration du runtime se fait ainsi :<\/p>\n\n\n\n
        sudo nvidia-ctk runtime configure --runtime=docker\nsudo systemctl restart docker<\/code><\/pre>\n\n\n\n
        Le test le plus utile consiste \u00e0 lancer nvidia-smi<\/code> dans un conteneur CUDA :<\/p>\n\n\n\n
        docker run --rm --gpus all \\\n  nvidia\/cuda:12.8.0-base-ubuntu22.04 \\\n  nvidia-smi<\/code><\/pre>\n\n\n\n
        Si la carte appara\u00eet ici, la base est saine. Si ce test \u00e9choue, il est inutile de chercher le probl\u00e8me dans Ollama : il faut d\u2019abord corriger le runtime NVIDIA.<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        La GTX 1650 n\u2019est pas une carte d\u00e9di\u00e9e \u00e0 l\u2019IA, mais elle suffit pour exp\u00e9rimenter avec des mod\u00e8les compacts.<\/em><\/p>\n\n\n\n
        2. Pr\u00e9parer l\u2019arborescence et les r\u00e9seaux<\/h2>\n\n\n\n
        J\u2019avais d\u00e9j\u00e0 d\u00e9plac\u00e9 les services du Homelab hors de mon dossier personnel, sous \/srv\/homelab<\/code>. Ce choix \u00e9vite de disperser les donn\u00e9es techniques dans \/home<\/code> et pr\u00e9pare l\u2019ajout de nouvelles stacks.<\/p>\n\n\n\n
        sudo mkdir -p \/srv\/homelab\/stacks\/ai\/ollama\/data\nsudo mkdir -p \/srv\/homelab\/stacks\/open-webui\/data\n\nsudo chown -R \"$(id -u):$(id -g)\" \\\n  \/srv\/homelab\/stacks\/ai\/ollama \\\n  \/srv\/homelab\/stacks\/open-webui<\/code><\/pre>\n\n\n\n
        Les deux projets utilisent un r\u00e9seau commun nomm\u00e9 ai<\/code>. Open WebUI rejoint \u00e9galement le r\u00e9seau proxy<\/code>, d\u00e9j\u00e0 utilis\u00e9 par Nginx Proxy Manager.<\/p>\n\n\n\n
        docker network inspect ai >\/dev\/null 2>&1 || docker network create ai\ndocker network inspect proxy >\/dev\/null 2>&1 || docker network create proxy<\/code><\/pre>\n\n\n\n
        L\u2019arborescence utile devient alors :<\/p>\n\n\n\n
        \/srv\/homelab\/stacks\/\n\u251c\u2500\u2500 ai\/\n\u2502   \u2514\u2500\u2500 ollama\/\n\u2502       \u251c\u2500\u2500 compose.yaml\n\u2502       \u2514\u2500\u2500 data\/\n\u2514\u2500\u2500 open-webui\/\n    \u251c\u2500\u2500 compose.yaml\n    \u2514\u2500\u2500 data\/<\/code><\/pre>\n\n\n\n
        3. D\u00e9ployer Ollama avec le GPU<\/h2>\n\n\n\n
        Le fichier \/srv\/homelab\/stacks\/ai\/ollama\/compose.yaml<\/code> contient le moteur d\u2019inf\u00e9rence :<\/p>\n\n\n\n
        services:\n  ollama:\n    image: ollama\/ollama:latest\n    container_name: ollama\n    restart: unless-stopped\n\n    ports:\n      - \"11434:11434\"\n\n    volumes:\n      - .\/data:\/root\/.ollama:Z\n\n    environment:\n      OLLAMA_KEEP_ALIVE: 24h\n      OLLAMA_MAX_LOADED_MODELS: 1\n      OLLAMA_MAX_QUEUE: 512\n      OLLAMA_NUM_PARALLEL: 1\n      OLLAMA_ORIGINS: \"*\"\n\n    deploy:\n      resources:\n        reservations:\n          devices:\n            - driver: nvidia\n              count: 1\n              capabilities: [gpu]\n\n    healthcheck:\n      test: [\"CMD-SHELL\", \"ollama list >\/dev\/null 2>&1 || exit 1\"]\n      interval: 30s\n      timeout: 10s\n      retries: 3\n      start_period: 30s\n\n    networks:\n      - ai\n\nnetworks:\n  ai:\n    external: true<\/code><\/pre>\n\n\n\n
        Les param\u00e8tres correspondent aux limites de ma machine :<\/p>\n\n\n\n
        Param\u00e8tre<\/th>Valeur<\/th>Pourquoi<\/th><\/tr><\/thead>
        OLLAMA_KEEP_ALIVE<\/code><\/td>24h<\/code><\/td>\u00c9vite de recharger constamment le mod\u00e8le pendant une session de travail<\/td><\/tr>
        OLLAMA_MAX_LOADED_MODELS<\/code><\/td>1<\/code><\/td>Emp\u00eache plusieurs mod\u00e8les de saturer les 4 Go de VRAM<\/td><\/tr>
        OLLAMA_NUM_PARALLEL<\/code><\/td>1<\/code><\/td>\u00c9vite plusieurs inf\u00e9rences simultan\u00e9es sur un GPU limit\u00e9<\/td><\/tr>
        count<\/code><\/td>1<\/code><\/td>R\u00e9serve une seule carte NVIDIA au conteneur<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Je lance ensuite la stack depuis Dockge ou directement en ligne de commande :<\/p>\n\n\n\n
        cd \/srv\/homelab\/stacks\/ai\/ollama\ndocker compose up -d\ndocker compose ps\ndocker compose logs --tail=100 ollama<\/code><\/pre>\n\n\n\n
        Puis je v\u00e9rifie que le conteneur voit r\u00e9ellement le GPU :<\/p>\n\n\n\n
        docker exec ollama nvidia-smi<\/code><\/pre>\n\n\n\n
        4. D\u00e9ployer Open WebUI<\/h2>\n\n\n\n
        Le fichier \/srv\/homelab\/stacks\/open-webui\/compose.yaml<\/code> contient l\u2019interface :<\/p>\n\n\n\n
        services:\n  open-webui:\n    image: ghcr.io\/open-webui\/open-webui:main\n    container_name: open-webui\n    restart: unless-stopped\n\n    ports:\n      - \"3000:8080\"\n\n    volumes:\n      - .\/data:\/app\/backend\/data:Z\n\n    environment:\n      OLLAMA_BASE_URL: http:\/\/ollama:11434\n      WEBUI_AUTH: \"True\"\n      REQUEST_TIMEOUT: \"120\"\n      ENABLE_UPDATES: \"False\"\n\n    networks:\n      - ai\n      - proxy\n\nnetworks:\n  ai:\n    external: true\n  proxy:\n    external: true<\/code><\/pre>\n\n\n\n
        Le nom ollama<\/code> est r\u00e9solu automatiquement sur le r\u00e9seau Docker ai<\/code>. Open WebUI ne doit donc pas utiliser localhost:11434<\/code> : depuis son conteneur, localhost<\/code> d\u00e9signerait Open WebUI lui-m\u00eame.<\/p>\n\n\n\n
        cd \/srv\/homelab\/stacks\/open-webui\ndocker compose up -d\ndocker compose ps\ndocker compose logs --tail=100 open-webui<\/code><\/pre>\n\n\n\n
        L\u2019interface est ensuite disponible \u00e0 l\u2019adresse :<\/p>\n\n\n\n
        http://localhost:3000<\/code><\/pre>\n\n\n\n
        Le premier compte cr\u00e9\u00e9 devient administrateur. Toutes les donn\u00e9es de l\u2019interface restent dans le dossier data<\/code>, notamment la base webui.db<\/code>, les fichiers t\u00e9l\u00e9vers\u00e9s et les donn\u00e9es utilis\u00e9es par les fonctions de recherche documentaire.<\/p>\n\n\n\n
        5. Le premier incident : deux Ollama pour un seul port<\/h2>\n\n\n\n
        La difficult\u00e9 la plus importante n\u2019est pas venue du GPU. Une ancienne installation d\u2019Ollama fonctionnait encore comme service systemd<\/code> sur Fedora, alors que je venais de d\u00e9marrer la version Docker.<\/p>\n\n\n\n
        Les sympt\u00f4mes \u00e9taient trompeurs :<\/p>\n\n\n\n
          \n
        • le port 11434<\/code> \u00e9tait d\u00e9j\u00e0 occup\u00e9 ;<\/li>\n\n\n\n
        • Open WebUI ne voyait pas les mod\u00e8les attendus ;<\/li>\n\n\n\n
        • les commandes lanc\u00e9es sur l\u2019h\u00f4te et dans le conteneur ne retournaient pas la m\u00eame liste ;<\/li>\n\n\n\n
        • un red\u00e9marrage du conteneur ne corrigeait pas le probl\u00e8me.<\/li>\n<\/ul>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          Un seul port, deux instances : le conflit entre le service h\u00f4te et le conteneur expliquait les incoh\u00e9rences.<\/em><\/p>\n\n\n\n
          J\u2019ai commenc\u00e9 par identifier pr\u00e9cis\u00e9ment le processus \u00e0 l\u2019\u00e9coute :<\/p>\n\n\n\n
          sudo ss -tlnp | grep ':11434'\nsystemctl status ollama --no-pager\ndocker ps --filter name=ollama<\/code><\/pre>\n\n\n\n
          Comme j\u2019avais d\u00e9cid\u00e9 de conserver uniquement la version Docker, j\u2019ai arr\u00eat\u00e9 et d\u00e9sactiv\u00e9 le service de l\u2019h\u00f4te :<\/p>\n\n\n\n
          sudo systemctl disable --now ollama<\/code><\/pre>\n\n\n\n
          J\u2019ai ensuite v\u00e9rifi\u00e9 que le port \u00e9tait libre, puis red\u00e9marr\u00e9 la stack :<\/p>\n\n\n\n
          sudo ss -tlnp | grep ':11434' || true\n\ncd \/srv\/homelab\/stacks\/ai\/ollama\ndocker compose up -d\n\ncurl -s http:\/\/localhost:11434\/api\/tags | jq -r '.models[].name'<\/code><\/pre>\n\n\n\n
          Cette r\u00e9solution a \u00e9galement clarifi\u00e9 l\u2019architecture : Ollama est d\u00e9sormais g\u00e9r\u00e9 par Docker, ses mod\u00e8les sont persist\u00e9s dans la stack et le service h\u00f4te ne doit plus red\u00e9marrer en parall\u00e8le.<\/strong><\/p>\n\n\n\n
          6. Le second incident : les volumes et SELinux<\/h2>\n\n\n\n
          Fedora active SELinux, ce qui prot\u00e8ge l\u2019h\u00f4te mais peut bloquer un conteneur qui tente d\u2019\u00e9crire dans un bind mount. Les sympt\u00f4mes prennent souvent la forme d\u2019un dossier illisible, d\u2019un fichier impossible \u00e0 cr\u00e9er ou d\u2019une erreur permission denied<\/code> malgr\u00e9 des permissions Unix qui semblent correctes.<\/p>\n\n\n\n
          La correction retenue est visible dans les deux fichiers Compose :<\/p>\n\n\n\n
          volumes:\n  - .\/data:\/root\/.ollama:Z<\/code><\/pre>\n\n\n\n
          et :<\/p>\n\n\n\n
          volumes:\n  - .\/data:\/app\/backend\/data:Z<\/code><\/pre>\n\n\n\n
          Le suffixe :Z<\/code> demande un \u00e9tiquetage SELinux priv\u00e9 pour le conteneur. Il convient aux donn\u00e9es propres \u00e0 un service. Le suffixe :z<\/code> sert plut\u00f4t lorsqu\u2019un m\u00eame dossier doit \u00eatre partag\u00e9 entre plusieurs conteneurs.<\/p>\n\n\n\n
          Pour contr\u00f4ler les labels :<\/p>\n\n\n\n
          ls -Zd \/srv\/homelab\/stacks\/ai\/ollama\/data\nls -Zd \/srv\/homelab\/stacks\/open-webui\/data<\/code><\/pre>\n\n\n\n
          Je limite volontairement le relabeling aux dossiers de donn\u00e9es de la stack. Il ne faut jamais appliquer :Z<\/code> \u00e0 un dossier syst\u00e8me large comme \/usr<\/code>, \/home<\/code> ou \/<\/code>.<\/p>\n\n\n\n
          7. T\u00e9l\u00e9charger des mod\u00e8les adapt\u00e9s \u00e0 4 Go de VRAM<\/h2>\n\n\n\n
          La GTX 1650 impose de rester r\u00e9aliste. Un mod\u00e8le peut \u00eatre stock\u00e9 sur disque sans tenir enti\u00e8rement dans la VRAM, mais l\u2019ex\u00e9cution devient plus lente si une partie du calcul est d\u00e9port\u00e9e vers la RAM et le processeur.<\/p>\n\n\n\n
          J\u2019ai conserv\u00e9 deux mod\u00e8les compl\u00e9mentaires :<\/p>\n\n\n\n
          docker exec -it ollama ollama pull gemma3:4b\ndocker exec -it ollama ollama pull qwen2.5-coder:7b\ndocker exec ollama ollama list<\/code><\/pre>\n\n\n\n
          Mod\u00e8le<\/th>Taille observ\u00e9e<\/th>Usage principal<\/th>Comportement sur la GTX 1650<\/th><\/tr><\/thead>
          gemma3:4b<\/code><\/td>Environ 3,3 Go<\/td>Questions g\u00e9n\u00e9rales et explications<\/td>Le plus confortable pour 4 Go de VRAM<\/td><\/tr>
          qwen2.5-coder:7b<\/code><\/td>Environ 4,7 Go<\/td>Docker, Python, HTML et assistance au code<\/td>Plus lourd, avec d\u00e9port partiel possible vers la RAM\/CPU<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          Le point important n\u2019est pas de collectionner les mod\u00e8les, mais d\u2019en choisir un ou deux adapt\u00e9s aux t\u00e2ches r\u00e9elles. OLLAMA_MAX_LOADED_MODELS=1<\/code> \u00e9vite qu\u2019ils restent charg\u00e9s simultan\u00e9ment.<\/p>\n\n\n\n
          8. Cr\u00e9er des profils sp\u00e9cialis\u00e9s dans Open WebUI<\/h2>\n\n\n\n
          J\u2019utilise Open WebUI comme une interface commune, puis j\u2019adapte le message syst\u00e8me au type de travail :<\/p>\n\n\n\n
          Profil<\/th>Usage<\/th><\/tr><\/thead>
          Docker Expert<\/td>Compose, Dockerfile, healthchecks et r\u00e9seaux<\/td><\/tr>
          Stack Architect<\/td>Architecture multi-conteneurs et persistance<\/td><\/tr>
          Frontend Specialist<\/td>HTML, CSS et JavaScript<\/td><\/tr>
          Troubleshooting<\/td>Analyse progressive d\u2019erreurs et de journaux<\/td><\/tr>
          Teacher Mode<\/td>Explications p\u00e9dagogiques et \u00e9tapes v\u00e9rifiables<\/td><\/tr>
          Universal<\/td>Questions techniques g\u00e9n\u00e9rales<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          Exemple de message syst\u00e8me pour les t\u00e2ches Docker :<\/p>\n\n\n\n
          Tu es un assistant sp\u00e9cialis\u00e9 dans Docker et les homelabs Linux.\n\nQuand tu proposes une solution :\n- commence par expliquer le diagnostic ;\n- fournis des commandes v\u00e9rifiables ;\n- pr\u00e9serve les volumes et les donn\u00e9es existantes ;\n- distingue les r\u00e9seaux internes des services expos\u00e9s ;\n- ajoute un healthcheck lorsque l\u2019image le permet ;\n- indique toujours comment v\u00e9rifier le r\u00e9sultat et revenir en arri\u00e8re.<\/code><\/pre>\n\n\n\n
          Cette sp\u00e9cialisation est plus utile qu\u2019un prompt tr\u00e8s long : elle fixe quelques r\u00e8gles coh\u00e9rentes avec la mani\u00e8re dont je maintiens le Homelab.<\/p>\n\n\n\n
          9. Connecter l\u2019IA locale \u00e0 Continue dans VS Code<\/h2>\n\n\n\n
          Une fois l\u2019API Ollama stabilis\u00e9e, j\u2019ai reli\u00e9 les mod\u00e8les locaux \u00e0 l\u2019extension Continue dans VS Code. qwen2.5-coder:7b<\/code> est utilis\u00e9 pour le code et l\u2019autocompl\u00e9tion, tandis que gemma3:4b<\/code> sert au dialogue technique plus g\u00e9n\u00e9ral.<\/p>\n\n\n\n
          Exemple de configuration config.yaml<\/code> :<\/p>\n\n\n\n
          name: NVSD Local AI\nversion: 1.0.0\nschema: v1\n\nmodels:\n  - name: Gemma 3 4B - Local\n    provider: ollama\n    model: gemma3:4b\n    apiBase: http:\/\/localhost:11434\n    roles:\n      - chat\n      - edit\n    defaultCompletionOptions:\n      contextLength: 4096\n\n  - name: Qwen 2.5 Coder 7B - Local\n    provider: ollama\n    model: qwen2.5-coder:7b\n    apiBase: http:\/\/localhost:11434\n    roles:\n      - autocomplete\n    defaultCompletionOptions:\n      contextLength: 2048<\/code><\/pre>\n\n\n\n
          Le contexte volontairement limit\u00e9 r\u00e9duit la consommation m\u00e9moire et am\u00e9liore la r\u00e9activit\u00e9 sur cette carte graphique. La valeur optimale d\u00e9pend toutefois de la taille des fichiers et du type de t\u00e2che.<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          L\u2019IA locale devient un outil du flux de d\u00e9veloppement, pas un service isol\u00e9 de plus.<\/em><\/p>\n\n\n\n
          10. V\u00e9rifier et surveiller la stack<\/h2>\n\n\n\n
          \u00c9tat des conteneurs<\/h3>\n\n\n\n
          docker ps --format 'table {{.Names}}\\t{{.Status}}\\t{{.Ports}}'<\/code><\/pre>\n\n\n\n
          Je dois retrouver au minimum :<\/p>\n\n\n\n
          ollama        Up ...        0.0.0.0:11434->11434\/tcp\nopen-webui    Up ...        0.0.0.0:3000->8080\/tcp<\/code><\/pre>\n\n\n\n
          Mod\u00e8les disponibles par l\u2019API<\/h3>\n\n\n\n
          curl -s http:\/\/localhost:11434\/api\/tags \\\n  | jq -r '.models[].name'<\/code><\/pre>\n\n\n\n
          Utilisation du GPU<\/h3>\n\n\n\n
          watch -n 2 \\\n  'nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu,temperature.gpu --format=csv'<\/code><\/pre>\n\n\n\n
          Consommation des conteneurs<\/h3>\n\n\n\n
          docker stats ollama open-webui<\/code><\/pre>\n\n\n\n
          Journaux<\/h3>\n\n\n\n
          docker logs --tail=100 -f ollama\ndocker logs --tail=100 -f open-webui<\/code><\/pre>\n\n\n\n
          Pendant mes essais, un mod\u00e8le charg\u00e9 utilisait presque toute la VRAM disponible, g\u00e9n\u00e9ralement autour de 3,8 \u00e0 4,0 Go<\/strong> selon le mod\u00e8le et le contexte. Le suivi avec nvidia-smi<\/code> permet de distinguer un vrai calcul GPU d\u2019une ex\u00e9cution presque enti\u00e8rement d\u00e9port\u00e9e sur le processeur.<\/p>\n\n\n\n
          R\u00e9sultats obtenus<\/h2>\n\n\n\n
          Apr\u00e8s correction des conflits et stabilisation des volumes :<\/p>\n\n\n\n
          V\u00e9rification<\/th>R\u00e9sultat observ\u00e9<\/th><\/tr><\/thead>
          GPU visible dans Docker<\/td>Oui, via docker exec ollama nvidia-smi<\/code><\/td><\/tr>
          Interface Open WebUI<\/td>Accessible sur http:\/\/localhost:3000<\/code><\/td><\/tr>
          API Ollama<\/td>Accessible sur http:\/\/localhost:11434<\/code><\/td><\/tr>
          Persistance<\/td>Mod\u00e8les et conversations conserv\u00e9s apr\u00e8s recr\u00e9ation des conteneurs<\/td><\/tr>
          D\u00e9bit indicatif<\/td>Environ 5 \u00e0 8 tokens\/s selon le mod\u00e8le, le contexte et le d\u00e9port CPU<\/td><\/tr>
          Latence \u00e0 chaud<\/td>Environ 0,5 \u00e0 2 secondes avant le d\u00e9but d\u2019une r\u00e9ponse simple<\/td><\/tr>
          Stabilit\u00e9<\/td>Aucun crash observ\u00e9 pendant la session de validation finale<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          Ces chiffres d\u00e9crivent mon mat\u00e9riel et mes tests. Ils ne constituent pas un benchmark universel : la quantification du mod\u00e8le, la longueur du contexte, le pilote et le partage GPU\/CPU changent fortement les performances.<\/p>\n\n\n\n
          Sauvegarder ce qui compte r\u00e9ellement<\/h2>\n\n\n\n
          Les mod\u00e8les Ollama sont volumineux, mais ils peuvent \u00eatre t\u00e9l\u00e9charg\u00e9s de nouveau. Les donn\u00e9es les plus importantes se trouvent dans Open WebUI : comptes, conversations, r\u00e9glages, fichiers et base locale.<\/p>\n\n\n\n
          Une sauvegarde minimale peut cibler le dossier Open WebUI :<\/p>\n\n\n\n
          sudo tar -czf \\\n  \"\/srv\/homelab\/backups\/open-webui-$(date +%F).tar.gz\" \\\n  -C \/srv\/homelab\/stacks\/open-webui \\\n  data<\/code><\/pre>\n\n\n\n
          Pour un arr\u00eat coh\u00e9rent avant une sauvegarde compl\u00e8te :<\/p>\n\n\n\n
          cd \/srv\/homelab\/stacks\/open-webui\ndocker compose stop\n\nsudo tar -czf \\\n  \"\/srv\/homelab\/backups\/ai-local-complete-$(date +%F).tar.gz\" \\\n  -C \/srv\/homelab\/stacks \\\n  ai\/ollama open-webui\n\ndocker compose start<\/code><\/pre>\n\n\n\n
          L\u2019archive compl\u00e8te inclut les mod\u00e8les et peut donc devenir tr\u00e8s volumineuse. Pour une sauvegarde distante fr\u00e9quente, je privil\u00e9gie Open WebUI et je conserve s\u00e9par\u00e9ment la liste des mod\u00e8les \u00e0 ret\u00e9l\u00e9charger.<\/p>\n\n\n\n
          Ce que cette installation m\u2019a appris<\/h2>\n\n\n\n
          Un petit GPU impose de choisir<\/h3>\n\n\n\n
          La GTX 1650 suffit pour apprendre, coder et tester, mais elle oblige \u00e0 limiter la taille du mod\u00e8le, le contexte et le parall\u00e9lisme. Cette contrainte a finalement am\u00e9lior\u00e9 la lisibilit\u00e9 de la stack.<\/p>\n\n\n\n
          Docker ne supprime pas les conflits avec l\u2019h\u00f4te<\/h3>\n\n\n\n
          Un conteneur peut \u00eatre parfaitement configur\u00e9 et rester inaccessible si un service local occupe d\u00e9j\u00e0 son port. Le diagnostic doit toujours commencer par l\u2019h\u00f4te : processus actifs, ports, volumes et permissions.<\/p>\n\n\n\n
          SELinux fait partie de l\u2019architecture Fedora<\/h3>\n\n\n\n
          Le d\u00e9sactiver aurait masqu\u00e9 le probl\u00e8me. L\u2019ajout cibl\u00e9 de :Z<\/code> aux bind mounts conserve la protection du syst\u00e8me tout en autorisant les conteneurs \u00e0 travailler dans leurs propres dossiers.<\/p>\n\n\n\n
          L\u2019IA locale compl\u00e8te le VPS au lieu de le remplacer<\/h3>\n\n\n\n
          Le poste Fedora fournit le GPU et l\u2019environnement de d\u00e9veloppement. Le VPS reste consacr\u00e9 aux services publics, au reverse proxy et au site WordPress. Cette s\u00e9paration \u00e9vite d\u2019exposer inutilement l\u2019API d\u2019inf\u00e9rence sur Internet.<\/p>\n\n\n\n
          Perspectives<\/h2>\n\n\n\n
          Cette premi\u00e8re stack constitue une base pour plusieurs \u00e9volutions d\u00e9j\u00e0 envisag\u00e9es dans le Homelab :<\/p>\n\n\n\n