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 restaientdegradeden 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èle | Taille | Tokens/sec | Latence 1er token |
|---|---|---|---|
| llama3.2:1b | 1.3 GB | ~15 t/s | ~2s |
| gemma4:e2b | 7.2 GB | ~4 t/s | ~12s |
| nomic-embed-text | 274 MB | n/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.