❯ ai · Running

IA locale avec Ollama + Open WebUI (décommissionné) Running Local AI with Ollama + Open WebUI (decommissioned)

Archive d'une stack IA auto-hébergée sur Kubernetes — Ollama pour l'inférence LLM sur ARM64, Open WebUI comme interface de chat. Décommissionnée le 2026-05-10. Historical record of a self-hosted AI stack on Kubernetes — Ollama for LLM inference on ARM64, Open WebUI as the chat interface. Decommissioned on 2026-05-10.

· 11 min de lecture 11 min read ·
k3s-clusteraillmollamaarchived
🇬🇧 Read this article in English

Mise à jour 2026-05-10 — Stack décommissionnée. L’app ArgoCD ai (Ollama + Open WebUI) a été retirée du cluster. Raison : 3 replicas Longhorn × 25 Gi (20 Gi modèles + 5 Gi config) saturaient le stockage distribué et restaient degraded en permanence — le cluster n’a que 3 workers Pi dont un en USB 32 Gi, incapable d’héberger une replica de 20 Gi. Les modèles étant re-téléchargeables, la suppression a été acceptée comme moindre mal. Le reste de l’article est conservé comme retour d’expérience.

Motivation : l’IA sans dépendance cloud

Les LLMs accessibles via API cloud (OpenAI, Anthropic, Google) sont puissants mais posent des questions de confidentialité et de coût. Pour un homelab, avoir un modèle qui tourne localement offre :

  • Confidentialité totale : aucune donnée ne quitte le réseau local
  • Disponibilité offline : fonctionne sans internet
  • Expérimentation libre : tester des modèles, des prompts, des configurations sans compteur de tokens

Le revers : les Raspberry Pi ne sont pas des GPU. L’inférence est lente. Un modèle 7B paramètres met 30-60 secondes pour générer une réponse sur RPi 5 en mode CPU-only. Acceptable pour l’expérimentation, pas pour un assistant en temps réel.

Ollama sur ARM64

Ollama est un runtime d’inférence LLM qui gère automatiquement le téléchargement des modèles, la quantization, et l’exposition d’une API compatible OpenAI. Il supporte ARM64 nativement.

Déploiement Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
  namespace: ai
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    spec:
      containers:
      - name: ollama
        image: ollama/ollama:latest
        ports:
        - containerPort: 11434
        resources:
          requests:
            memory: 2Gi
          limits:
            memory: 10Gi    # Les modèles sont chargés en RAM
        volumeMounts:
        - name: ollama-data
          mountPath: /root/.ollama
      nodeSelector:
        node-type: worker    # Uniquement sur les workers 16GB

strategy: Recreate : Ollama charge les modèles en mémoire. Deux instances simultanées causeraient des conflits sur le volume de données. Recreate garantit qu’une seule instance tourne à la fois.

10 Gi de memory limit : les modèles 7B en quantization Q4 occupent ~4 Go en RAM ; gemma4:e2b (7.2 Go sur disque) en consomme davantage une fois chargé. La limite haute évite un OOM kill pendant l’inférence d’un long contexte.

Modèles utilisés

# Pré-pull des modèles via Job Kubernetes
kubectl exec -n ai deployment/ollama -- ollama pull gemma4:e2b
kubectl exec -n ai deployment/ollama -- ollama pull llama3.2:1b
kubectl exec -n ai deployment/ollama -- ollama pull nomic-embed-text  # Pour RAG

gemma4:e2b (7.2 Go) est le modèle principal — Google Gemma 4 en quantization 2-bit, bon équilibre entre qualité et empreinte mémoire sur RPi 5. llama3.2:1b (1.3 Go) est utilisé pour les tâches légères nécessitant une faible latence. nomic-embed-text est un modèle d’embeddings léger, utilisé pour la fonctionnalité RAG d’Open WebUI.

Open WebUI

Open WebUI est une interface web type ChatGPT, conçue pour fonctionner avec Ollama (et d’autres backends compatibles OpenAI). Elle supporte les conversations, les documents, les images, et le RAG.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: open-webui
  namespace: ai
spec:
  template:
    spec:
      containers:
      - name: open-webui
        image: ghcr.io/open-webui/open-webui:main
        env:
        - name: OLLAMA_BASE_URL
          value: http://ollama.ai.svc.cluster.local:11434
        - name: WEBUI_AUTH
          value: "true"
        resources:
          requests:
            memory: 512Mi
          limits:
            memory: 2Gi

RAG : éviter les téléchargements HuggingFace

Par défaut, Open WebUI télécharge des modèles d’embeddings depuis HuggingFace pour le RAG. Sur un RPi avec peu de RAM et une connexion résidentielle, ces téléchargements (~500 Mo) causent des timeouts et des OOM kills.

Solution : configurer Open WebUI pour utiliser Ollama comme backend d’embeddings, en pointant vers nomic-embed-text qui est déjà présent localement.

env:
- name: RAG_EMBEDDING_ENGINE
  value: ollama
- name: RAG_OLLAMA_BASE_URL
  value: http://ollama.ai.svc.cluster.local:11434
- name: RAG_EMBEDDING_MODEL
  value: nomic-embed-text

Ce changement élimine les téléchargements HuggingFace au démarrage et réduit significativement la consommation mémoire d’Open WebUI.

Stockage et persistance

Deux PVCs sont nécessaires :

# PVC pour les modèles Ollama (~20 Go minimum pour plusieurs modèles)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ollama-data
  namespace: ai
spec:
  storageClassName: standard-storage
  resources:
    requests:
      storage: 20Gi

Les modèles LLM sont stockés dans standard-storage (1 réplique) — ils sont téléchargeables depuis Ollama Registry et ne sont pas des données irremplaçables.

Les données Open WebUI (conversations, utilisateurs) utilisent critical-storage (2 répliques).

Performance en pratique

Sur RPi 5 (ARM Cortex-A76, 16 GB RAM) :

ModèleTailleTokens/secLatence 1er token
llama3.2:1b1.3 GB~15 t/s~2s
gemma4:e2b7.2 GB~4 t/s~12s
nomic-embed-text274 MBn/a (embeddings)~0.5s

Ces performances sont suffisantes pour des usages de résumé, génération de code simple, et exploration — pas pour un assistant interactif fluide.

Leçons apprises

Choisir la quantization Q4 : les modèles en Q8 ou FP16 sont trop lourds pour les RPi. Q4 offre un bon compromis qualité/mémoire.

Recreate plutôt que RollingUpdate : lors d’une mise à jour d’Ollama, le pod ancien doit être terminé avant que le nouveau démarre, sinon les deux instances tentent d’accéder aux mêmes fichiers de modèles — corruption garantie.

Patience : le premier démarrage après un pull de modèle peut prendre plusieurs minutes. Les liveness probes doivent avoir un initialDelaySeconds généreux (120s minimum) pour éviter des redémarrages prématurés.

k3s-clusteraillmollamaarchived