Repository navigation
Guide Ollama Pratique
Fichier : Guide-Ollama-Pratique.md · Dossier : wiki (racine) Branche : master (wiki) · Auteur : hprzeta · MAJ : 2026-08-02
🧭 Rôle de cette page. Référence pratique et évolutive pour l'usage d'Ollama dans le projet (Objectif 2 — BrainVault). Contrairement à
Guide-RAG-BrainVault-Debutant.md(pédagogie RAG), cette page est opérationnelle : commandes, config matérielle, pièges rencontrés, benchmarks réels. Enrichie au fil des sessions de test.
Ollama tourne comme service systemd sur zeta-lab (PC1) :
# État du service
systemctl status ollama --no-pager
# Lancer manuellement si le service est down
ollama serve &
# Lister les modèles installés
ollama list
⚠️ Le service systemd peut s'arrêter proprement (status=0/SUCCESS) après un usage manuel (ex. libération RAM avant reset de quota) — ce n'est pas un crash, il faut juste le relancer avecollama serve &avant tout test RAG.
| Paramètre | Valeur | Note |
|---|---|---|
| GPU | NVIDIA GeForce GTX 960M | Maxwell, compute capability 5.0 |
| VRAM totale | 4.0 GiB | ~3.4 GiB disponible (reste réservé système/affichage) |
| Driver | CUDA 12.2 | détection automatique au démarrage (inference compute) |
OLLAMA_MODELS |
/mnt/data/models_ia/ollama/ |
ne jamais migrer (cold storage, 651 Go) |
OLLAMA_HOST |
http://127.0.0.1:11434 |
API locale uniquement, pas exposée sur le LAN |
OLLAMA_KEEP_ALIVE |
30m (override systemd, 25/07/2026) |
modèle déchargé après 30 min d'inactivité — allongé depuis le défaut 5m0s suite à l'upgrade RAM 8→16 Go (STACK.md) : plus de marge mémoire système, moins de rechargements pendant une session de test enchaînant plusieurs questions |
| Contexte par défaut | 4096 tokens | calculé automatiquement selon la VRAM dispo (vram-based default context) |
💡 Le GPU accélère réellement l'inférence. Les estimations initiales (1-3 min/réponse) supposaient du CPU pur ; avec la GTX 960M détectée en CUDA, la génération devrait être nettement plus rapide — à mesurer et consigner ci-dessous (§5).
| Modèle | Taille disque | Usage prévu |
|---|---|---|
mathstral:latest |
4.1 GB | Spécialisé maths — génération RAG principale |
deepseek-coder:6.7b |
3.8 GB | Assistance code |
phi3:mini |
2.2 GB | Modèle léger, tests rapides |
qwen3:4b |
2.5 GB | Alternative générale |
ollama list # lister
ollama pull mathstral # (re)télécharger si absent
ollama show mathstral # détails (paramètres, quantization, contexte)Deux façons de surveiller Ollama en train de tourner :
A. htop — filtrer sur le process
htop
# puis F4, taper "ollama", EntréeRepère le process ollama runner (PID différent de ollama serve) qui monte en CPU/RAM
pendant la génération.
B. nvidia-smi — vérifier l'usage GPU réel
watch -n 1 nvidia-smiPendant la génération mathstral, la VRAM utilisée et le GPU-Util % doivent grimper —
confirme que l'inférence passe bien par CUDA et pas par un fallback CPU silencieux.
C. rag_monitor.py — côté vault, pas côté Ollama
python scripts/rag_monitor.py --watch 5Utile pendant une ingestion ; pour un simple test question/réponse, peu de mouvement côté disque — complémentaire à A/B, pas un remplacement.
| Date | Modèle | Question / tâche | Contexte (chunks) | Temps génération | GPU util. observé | Note |
|---|---|---|---|---|---|---|
| 25/07/2026 | mathstral | Q1 SEUIL_1NEWTON | 8 chunks (RAG, --k 8) |
117.0 s (cold — chargement modèle après déchargement) | ~99-100 % · VRAM 3,76/4 Go · RAM 4,4/15,5 Go · swap ~0 | ✅ réponse correcte 20000 + formule biais, citée [Etape-1-Calcul-des-zéros-non-triviaux.md], aucune hallucination — 4ᵉ tentative de la session (voir §5.1) |
| 25/07/2026 | mathstral | Q2 IP cluster | 8 chunks (RAG, --k 8) |
152.5 s (warm — modèle déjà chargé, dans la fenêtre OLLAMA_KEEP_ALIVE) |
~100 % (pics) · VRAM 3,75-3,88 Go · RAM 4,4/15,5 Go · swap ~0 | ✅ 4/4 IP correctes (.24/.52/.22/.54), citations cohérentes, aucune hallucination |
📝 À chaque session de test, ajouter une ligne : date, modèle, tâche, temps mesuré, observations GPU/CPU. Objectif : construire une vraie référence de perf locale.
Sur Q1, le chunk contenant littéralement SEUIL_1NEWTON (Etape-1-Calcul-des-zéros-non- triviaux.md, "v15 — SEUIL_1NEWTON=20 000 : Phase 2 adaptative...") se classe au
rang 7 (distance 1.464) sur la requête "Quel est le seuil SEUIL_1NEWTON et pourquoi
cette valeur ?" :
--k |
Chunk clé (rang 7) inclus ? | Résultat génération |
|---|---|---|
| 3 (ancien défaut) | ❌ | Réponse tronquée absurde (5 [niveau-2-analyse-complexe.md]) — aucune valeur trouvée |
| 6 | ❌ (rang 7 > 6) | Chunks plus proches du sujet (compute_zeros_v13/14/15.py, "pourquoi 65 et pas 20 ?") mais toujours pas le bon — génération a aussi expiré le timeout HTTP (400 s) sous charge CPU élevée |
| 8 | ✅ | Réponse correcte 20000, citée, aucune hallucination |
Cause du bruit de fond : le corpus mélange documentation technique (code, analyses)
et cours pédagogique niveau 0-5 (niveau-1-series.md, niveau-2-analyse-complexe.md...) —
all-MiniLM-L6-v2 rapproche parfois des chunks de cours généralistes du vocabulaire de
la question avant les chunks techniques précis (déjà noté dans Handoff.md du 19/07).
Action : défaut de scripts/rag_query.py --k changé de 3 → 8 (voir commentaire
dans le script). Coût : génération plus longue (plus de contexte) mais fiabilité très
supérieure — aucune régression de hors-sujet observée sur Q2 (8 chunks, tous pertinents).
| Piège | Symptôme | Solution |
|---|---|---|
| Service arrêté après libération RAM manuelle |
ollama list / ollama serve ne répond pas |
ollama serve &, revérifier avec ollama list
|
OLLAMA_KEEP_ALIVE expire entre deux questions |
Rechargement modèle (délai supplémentaire) inattendu en plein test | Enchaîner les questions du test dans la fenêtre de 5 min, ou raccourcir volontairement l'attente |
GPU mal détecté par outils tiers (canirun.ai) |
GTX 960M annoncée en 2 Go via WebGPU | Ollama natif (CUDA) détecte correctement les 4 Go — ne pas se fier aux détecteurs web pour dimensionner |
Relancer ollama serve & alors qu'une instance tourne déjà |
Error: listen tcp 127.0.0.1:11434: bind: address already in use |
Pas grave : le port 11434 est déjà occupé par l'instance existante, qui répond normalement. Toujours vérifier AVANT de lancer (§1) : systemctl status ollama ou pgrep -fa ollama
|
Contexte : plusieurs ollama serve & lancés à la suite dans la même session sans
vérification préalable de l'état du service.
A.1 — htop montre 9 lignes "ollama serve" sous le même arbre
Ligne Tasks: 165, 860 thr, 126 kthr en haut : ce ne sont pas 9 processus distincts
mais les threads du même processus ollama serve (PID racine 538774), affichés par
htop en vue arborescente. VIRT/RES identiques sur chaque ligne → confirme qu'il s'agit
d'un seul processus multi-threadé, pas d'une fuite de processus zombies.
A.2 — Tentative de relance : port déjà occupé
ollama serve & lancé une 2ᵉ fois → nouveau PID (554456) mais
Error: listen tcp 127.0.0.1:11434: bind: address already in use. L'instance d'origine
(538774) tournait déjà et répond normalement — ollama list fonctionne et affiche les
4 modèles sans erreur.
A.3 — Confirmation que mathstral reste accessible malgré l'erreur
Même après une 2ᵉ tentative infructueuse (PID 554862, même erreur bind), ollama list | grep mathstral retrouve bien mathstral:latest (surligné) — la génération n'est donc
jamais interrompue par ces tentatives de relance en double.
Leçon retenue : l'erreur address already in use est un signal rassurant, pas
un échec — elle prouve qu'Ollama tournait déjà. Le réflexe correct reste néanmoins de
vérifier systemctl status ollama --no-pager 2>/dev/null || pgrep -fa ollama avant
tout ollama serve &, pour éviter le bruit inutile dans les logs et les PID orphelins
en arrière-plan (jobs [1], [2]... qui s'accumulent dans le shell).
B — Test RAG complet Q1/Q2 (25/07/2026) : pas d'OOM, mais incompatibilité torch/GPU
Aucun OOM pendant tout le test (2 générations mathstral + rechargements) : RAM
utilisée restée stable à ~4,4 Go / 15,5 Go, swap ~0 — confirme le bénéfice de
l'upgrade RAM 8→16 Go du 25/07/2026 (voir STACK.md). Contrairement à l'incident du
06/07 (crash sous 8 Go), aucune marge critique observée cette fois.
Incident trouvé, non lié à la RAM : sentence-transformers (embedding de la requête,
modèle all-MiniLM-L6-v2) plantait avec CUDA error: no kernel image is available for execution on the device. Cause : torch a été mis à jour vers 2.11.0+cu130, qui a
abandonné le support de l'architecture Maxwell (compute capability 5.0) de la GTX 960M.
mathstral n'est pas concerné — il passe par le moteur CUDA natif d'ollama
(llama.cpp), qui gère toujours cette GPU sans problème (36 % CPU / 64 % GPU observé,
VRAM ~3,76/4 Go pendant la génération).
Contournement appliqué le 25/07/2026 (à chaque appel, pas encore automatisé dans le script) :
export CUDA_VISIBLE_DEVICES="" # force l'embedding sur CPU, laisse mathstral sur GPU
python scripts/rag_query.py "..." --k 8Coût : négligeable (~2 s pour charger + encoder la question en CPU).
Résolu et automatisé le 02/08/2026 : retrieval() dans scripts/rag_query.py force
désormais SentenceTransformer(MODELE_EMBEDDING, device="cpu") directement — plus besoin
de poser la variable d'environnement à chaque appel. Vérifié en conditions réelles
(/mnt/vault_rag monté, --no-llm --k 3) : chargement 3.43 s, embedding 0.876 s,
recherche HNSW 0.224 s, aucune erreur CUDA. Commit e01bb1d (Riemann_Lab_C), synchronisé
et poussé sur les 4 branches (main 92fe8a7, Riemann_Lab_IA 0692938,
Riemann_Lab_Test fe4142b).
Diagnostic du 2026-07-06 sur PC1 (
zeta-lab, 7,6 Go RAM, GTX 960M 4 Go VRAM). Méthode :dmesg/journalctl -k(sudo NOPASSWD, pas d'OOM kernel classique ni throttling trouvés) + lecture directe de/var/log/syslog(groupeadm, sans sudo) pour les événementssystemd-oomdet les logsollama.
| Date | Symptôme | Cause identifiée | RAM/VRAM au moment du fait | Résolution | Prévention |
|---|---|---|---|---|---|
| 2026-07-05/06 ~00:23 | Fenêtres fermées (VS Code + Firefox/Claude.ai) pendant test mathstral |
systemd-oomd (OOM userspace, basé sur la pression mémoire PSI — pas le kernel OOM killer) a tué app-code.scope (21 proc., pression 78,70 % > seuil 50 % pendant >20 s) puis snap.firefox.scope (14 proc., 66,36 %). Aucun reboot, aucun OOM kernel classique, aucun throttling thermique. Ollama était en réalité arrêté depuis 14:58 le 05/07 (redémarré seulement à 08:35 le 06/07) → ce n'est pas un chargement mathstral en cours qui a déclenché ce kill précis, mais l'accumulation seule de VS Code (2h28 de CPU cumulé) + Firefox |
VS Code 2,2 Go ; RAM totale système 7,6 Go ; swap quasi inutilisé (swappiness=10 via zeta_turbo_on.sh) |
Aucune action — kill silencieux, pas de reboot nécessaire | Fermer Firefox/onglets superflus avant sessions longues ; free -h avant de lancer un gros test ; le seuil oomd (50 % de pression sur user.slice) est bas pour une machine à 7,6 Go |
| 2026-07-05 ~14:28 | Chargement mathstral en timeout (1 m 47 s, context canceled) |
systemd-oomd a tué Firefox (21 proc., pression 74,50 %) puis VS Code (23 proc., pression 93,89 %) pendant le chargement du modèle (offload partiel GPU 19-23/33 couches, reste sur CPU/RAM) |
VRAM GPU libre ~3,5-3,7 Go/4 Go (marge GPU correcte) ; RAM système saturée par VS Code + Firefox + chargement modèle | Ollama arrêté manuellement à 14:58 après l'incident | Vérifier RAM libre avant ollama run mathstral ; fermer apps lourdes avant chaque test |
| 2026-07-06 ~09:19 | Nouveau chargement mathstral en timeout (1 m 31 s) — relancé manuellement par hprzeta sans attendre la fin du diagnostic, ~22 min avant la session d'analyse | Pattern identique à 14:28 : systemd-oomd tue GNOME Shell (3 proc.) puis VS Code (31 proc., 2,9 Go, pression 73,45 %) |
VRAM GPU libre ~3,55-3,68 Go/4 Go ; VS Code déjà à 2,9 Go RAM avant le kill (fuite progressive avec la durée de session) | Aucune — kill silencieux | Confirmé : relance manuelle, pas de cause automatique (cron/extension) — attendre la fin d'un diagnostic avant de relancer un test suspecté fautif |
| 2026-07-06 | VS Code tué 2x par systemd-oomd pendant test mathstral | Pression mémoire >50-80% (user slice), cgroup app-code visé | RAM totale 7.6G, VS Code 1.5G + mathstral chargé | Travailler hors VS Code (terminal système dédié) | Fermer VS Code avant tout test mathstral ; upgrade RAM (déjà noté STACK.md) |
Cause structurelle commune : mathstral-7B (quantifié Q4) n'offload que 19-23 couches
sur 33 vers le GPU (960M, 4 Go VRAM) — le reste tourne sur CPU/RAM système. Sur une
machine à seulement 7,6 Go de RAM, combiné à VS Code (qui accumule 2-3 Go avec la durée
de session) et Firefox/Claude.ai ouverts, la pression mémoire dépasse régulièrement le
seuil de 50 % que systemd-oomd applique à user.slice, qui tue alors le plus gros
consommateur — souvent VS Code, jamais Ollama lui-même (il tourne dans system.slice,
non surveillé par cette règle). Le swap (swappiness=10, config zeta_turbo) n'amortit
pas ces pics : il privilégie la performance de calcul au détriment de la marge mémoire.
Piste de prévention pour Objectif 2 (RAG) : avant tout test mathstral, fermer
Firefox et les fenêtres VS Code non essentielles, ou lancer le test depuis un terminal
ssh sans session graphique pour libérer la RAM disputée par user.slice.
- Guide-RAG-BrainVault-Debutant — pédagogie RAG, vocabulaire, schémas
- STACK — stack outils complet, roadmap Objectif 2
-
scripts/rag_monitor.py— surveillance du vault (complémentaire, pas Ollama lui-même)
Guide-Ollama-Pratique.md · wiki racine · branche master · hprzeta · MAJ 2026-08-02 · 246 lignes