docs: progression 2026-05-14 + désignore progress/

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-07-08 04:34:41 +02:00 · 2026-05-14 22:28:10 +02:00 · 2026-05-14 22:28:10 +02:00 · 24c0bf9e12
commit 24c0bf9e12
parent e17396a150
9 changed files with 1093 additions and 2 deletions
--- a/.gitignore
+++ b/.gitignore
@ -20,7 +20,7 @@ keys.txt
 .claude/settings.local.json

 # Journaux de session (notes de debug, IPs, infos locales)
-progress/
+# progress/ — versionnés car référencés par PROGRESS.md

 # Divers
 .DS_Store
--- a/PROGRESS.md
+++ b/PROGRESS.md
@ -8,4 +8,4 @@
 | [2026-05-11](progress/2026-05-11.md) | Hermes opérationnel (matin) — llama-server ROCm 7.x ×4 perf (après-midi) — LiteLLM proxy + Claude API, switch modèle sans restart Hermes (soir) |
 | [2026-05-12](progress/2026-05-12.md) | Flannel fix, MetalLB + Traefik + DNS wildcard *.lab.local, architecture multi-modèles gpu-01, 5 profils Hermes, docs admin/install/ |
 | [2026-05-13](progress/2026-05-13.md) | Stabilisation multi-modèles — OOM fixes, Qwen3-1.7B sur 14 CPUs (21 tok/s), profils system/monitor finalisés, funk-ai par défaut |
-| [2026-05-14](progress/2026-05-14.md) | Monitoring complet — NFS provisioner, kube-prometheus-stack, Grafana/Prometheus/AlertManager ingress, 3 dashboards Grafana (k8s/infra/ia), alertes PrometheusRule, métriques ROCm + llama-server, webhook AlertManager → Hermes. Réorganisation doc admin/ (4 domaines : ops/infra/k8s/ia). Fixes : Grafana OOMKilled (1Gi), nftables rule ordering, llama-server --metrics, null receiver AlertManager, umount RAID propre à l'arrêt |
+| [2026-05-14](progress/2026-05-14.md) | Monitoring complet + fix webhook AlertManager→Hermes (BrokenPipeError). RAG opérationnel : Qdrant 284 chunks, rag-ingest/rag-query, skill funk-ai. Souls révisés (4 profils). Docs : alertmanager-webhook, rag, hermes-souls |
--- a/progress/2026-05-09.md
+++ b/progress/2026-05-09.md
@ -0,0 +1,40 @@
+# 2026-05-09 — Initialisation du repo et premières machines
+
+## Accompli
+
+### Poste perso
+- Hermes Agent configuré (Setup 1 — LM Studio local `127.0.0.1:1234`)
+- `~/.ssh/config` créé avec alias `s01`, `g01`, `c01`, `c02`, `c03`
+- `/etc/hosts` : entrées cluster à vérifier (commande tee interrompue)
+
+### Infra physique
+- storage-01 installé AlmaLinux 9.7 — `192.168.1.200` (WAN) / `192.168.10.1` (LAN cluster)
+- gpu-01 installé AlmaLinux 9.7 — `192.168.10.20`
+- Switch GS308EV4 configuré : tous ports Access, storage-01 sur deux NICs physiques (`enp4s0` WAN / `enp6s0f3u2c2` LAN)
+- Connectivité LAN cluster : storage-01 ↔ gpu-01 ✅
+- Internet depuis gpu-01 via NAT storage-01 ✅
+
+### Repo lab-infra
+- `git init` + `.gitignore`
+- Python venv `.venv/` + `ansible-core 2.17`
+- Structure `ansible/` complète : ansible.cfg, inventory.yml, group_vars, host_vars, playbooks, requirements.yml
+- Collections : `ansible.posix`, `community.general`
+- `Makefile` : ping, check, apply, vault-*
+- `.vault_pass` créé localement (gitignored)
+- Clé SSH déployée sur les deux machines
+
+### Rôles Ansible
+- **`common`** appliqué sur storage-01 et gpu-01 : hostname, EPEL, packages, user ansible, sudo, sshd durci, chrony
+- **`gateway`** appliqué sur storage-01 : firewalld désactivé, IP forwarding, nftables NAT
+- Stubs vides créés pour tous les rôles restants
+
+## Problèmes rencontrés / Solutions
+
+| Problème | Solution |
+|---|---|
+| `stdout_callback: yaml` déprécié dans community.general 12 | Remplacé par `stdout_callback = ansible.builtin.default` + `result_format = yaml` |
+| nftables ignoré — firewalld écrase les règles | Ajout de `Stop and disable firewalld` en première tâche du rôle `gateway` |
+| nftables charge `/etc/sysconfig/nftables.conf` sur AlmaLinux 9, pas `/etc/nftables.conf` | Corrigé dans le template dest |
+| `htop` absent des repos de base AlmaLinux 9 | Ajout activation EPEL avant install packages dans `common` |
+| `ansible_host` dans `host_vars/` écrase l'inventaire | Corrigé pour utiliser l'IP WAN `192.168.1.200` |
+| gpu-01 sans DNS (pas de dnsmasq encore) | DNS temporaire `8.8.8.8` configuré via nmcli |
--- a/progress/2026-05-10.md
+++ b/progress/2026-05-10.md
@ -0,0 +1,114 @@
+# 2026-05-10 — dnsmasq, ROCm, LM Studio, NFS, modèles partagés
+
+## Accompli
+
+### Rôle `dnsmasq` (storage-01)
+- Résolution `*.lab.local` opérationnelle depuis le LAN cluster
+- DNS gpu-01 mis à jour : `8.8.8.8` → `192.168.10.1`
+
+### Rôle `rocm` (gpu-01)
+- Repo AMD importé, drivers amdgpu + ROCm installés
+- `HSA_OVERRIDE_GFX_VERSION=10.3.0` positionné en system-wide (profile.d + service systemd)
+- RX 6700XT (gfx1031) détectée par ROCm
+
+### Rôle `lm_studio` (gpu-01) — avec résolution de blocages multiples
+
+LM Studio installe un module Node natif (`watcher.node`) compilé avec GCC 12 qui
+requiert `GLIBCXX_3.4.30`. AlmaLinux 9 / GCC 11 fournit au maximum `GLIBCXX_3.4.29`.
+Le symbole concerné (`std::condition_variable::wait`) existe dans la libstdc++ système
+mais sous le tag `GLIBCXX_3.4.11`.
+
+**Solution retenue : patch ELF de `watcher.node`**
+- `patch-glibcxx-compat.py` : parseur ELF qui réécrit le champ `vna_hash` + la chaîne
+  de version dans la section `.gnu.version_r` de `watcher.node`
+  (`GLIBCXX_3.4.30` → `GLIBCXX_3.4.11`, même longueur → patch in-place)
+- `install-lmstudio-compat.sh` : télécharge le bundle officiel, patche `watcher.node`
+  avant le bootstrap, patche aussi la copie installée
+
+**Architecture du service systemd** :
+- `lms server start` quitte avec code 0 après avoir démarré le daemon → systemd
+  déclenchait un cycle de restart
+- Solution : wrapper `run-llmster.sh` — appelle `lms server start` (qui gère le passkey
+  et démarre `llmster`), puis reste en vie via `pgrep llmster` en boucle
+- Service `active (running)` avec le wrapper comme PID principal et `llmster` tracké
+  dans le cgroup systemd
+- `Restart=on-failure` relance proprement si `llmster` meurt
+
+**Wrapper `lms` global** :
+- `/usr/local/bin/lms` → délègue à `sudo -u lmstudio ... lms "$@"`
+- Accessible depuis n'importe quel user sans préfixe
+
+**Validation** :
+```
+curl http://192.168.10.20:1234/v1/models  # depuis storage-01 → OK
+lms ls  # depuis gpu-01 → liste les modèles
+```
+
+Détail complet des blocages : `ansible/roles/lm_studio/TROUBLESHOOTING.md`
+
+### Rôle `nfs_server` (storage-01)
+
+Le RAID5 `md127` (4×1 TB, créé sous l'OS précédent) a survécu au changement d'OS —
+les superblocs mdadm sont sur les disques, pas sur l'OS. Assemblage automatique au boot.
+
+- `mdadm --detail --scan` → `/etc/mdadm.conf` + rebuild initramfs
+- `md127` (ext4) monté sur `/srv/data` via UUID dans `/etc/fstab`
+- Exports NFS :
+  - `/srv/data/nfs/k8s` → pour le futur NFS provisioner k8s
+  - `/srv/data/models` → modèles LM Studio partagés
+- Ports NFS (111, 2049) déjà ouverts dans nftables (rôle gateway)
+- `nfs-server` actif et enabled
+
+### Rôle `nfs_client` (gpu-01)
+
+- `/mnt/nfs` → `192.168.10.1:/srv/data/nfs/k8s`
+- `/mnt/models` → `192.168.10.1:/srv/data/models`
+- Options robustes aux extinctions fréquentes :
+  - `soft` — échoue proprement (EIO) si serveur injoignable, ne bloque jamais
+  - `timeo=30, retrans=3` — 3 s de timeout, 3 tentatives
+  - `_netdev` — montage après réseau disponible seulement
+  - `nofail` — boot du client non bloqué si storage-01 absent
+  - `x-systemd.automount` — montage à la demande (premier accès), pas au boot
+
+### Migration des modèles LM Studio vers NFS
+
+- Modèles téléchargés : `gemma-4-e2b` (4.4 GB), `gemma-4-e4b` (6.3 GB) + embedding nomic
+- Rsync `/opt/lmstudio/.lmstudio/models/` → `/srv/data/models/` (~80 MB/s LAN interne)
+- Intégrité vérifiée (`diff -rq`) avant suppression locale
+- `/opt/lmstudio/.lmstudio/models` remplacé par symlink → `/mnt/models`
+- LM Studio voit les modèles sans aucun changement de configuration
+- 11 GB libérés sur le disque local de gpu-01
+
+## Problèmes rencontrés / Solutions
+
+| Problème | Solution |
+|---|---|
+| `GLIBCXX_3.4.30 not found` dans `watcher.node` | Patch ELF `vna_hash` + string → `GLIBCXX_3.4.11` |
+| LD_PRELOAD ne satisfait pas DT_VERNEED lié à `libstdc++.so.6` | Abandonné — seul le patch ELF fonctionne |
+| Offsets mal calculés dans le parseur ELF (`vn_aux` à +4 au lieu de +8) | Corrigé en tenant compte du champ `vn_file` |
+| Patch vers `GLIBCXX_3.4.29` : symbole inexistant sous cette version | Cibler `GLIBCXX_3.4.11` — là où le symbole existe réellement |
+| `lms server start` quitte avec 0 → systemd déactivate + tue llmster | Wrapper shell avec boucle `pgrep llmster` comme processus principal |
+| `lms server start` via ExecStartPost : `Invalid passkey` | lms doit démarrer llmster lui-même pour créer le passkey |
+| Port 1234 inaccessible depuis le réseau | `firewall-cmd --permanent --add-port=1234/tcp` |
+| `gcc -lstdc++` introuvable sur AlmaLinux 9 | Chemin complet `/usr/lib64/libstdc++.so.6` |
+| Automount NFS inactif après `ansible.posix.mount state: mounted` | Utiliser `state: present` + `systemctl enable/start *.automount` |
+| Tâche firewalld dans `nfs_server` échoue sur storage-01 (nftables) | Condition `when: firewalld est running` |
+
+## État en fin de journée
+
+| Composant | État |
+|---|---|
+| common (storage-01 + gpu-01) | ✅ |
+| gateway / nftables / NAT | ✅ |
+| dnsmasq | ✅ |
+| ROCm (gpu-01) | ✅ |
+| LM Studio service systemd (gpu-01) | ✅ active (running) |
+| API LM Studio `192.168.10.20:1234` | ✅ accessible depuis storage-01 |
+| RAID5 md127 monté `/srv/data` | ✅ 2.7 TB, état clean |
+| NFS server + exports | ✅ |
+| NFS client gpu-01 (automount) | ✅ |
+| Modèles sur NFS | ✅ gemma-4-e2b, gemma-4-e4b, nomic-embed |
+| Route statique Freebox | ❌ à faire |
+| Premier commit GitHub | ❌ à faire |
+| postgresql / qdrant / minio | ❌ stubs vides |
+| hermes_agent | ❌ stub vide |
--- a/progress/2026-05-10b.md
+++ b/progress/2026-05-10b.md
@ -0,0 +1,59 @@
+# 2026-05-10 — Hermes Agent sur storage-01
+
+## Contexte
+
+Mise en place de Hermes Agent en service systemd sur storage-01, pointant sur LM Studio
+(gpu-01 `192.168.10.20:1234`). Données persistantes sur le RAID5.
+
+---
+
+## Rôle `hermes_agent` (nouveau)
+
+Structure créée :
+```
+roles/hermes_agent/
+├── defaults/main.yml          → variables : user, home, data_dir, LLM endpoint, model
+├── handlers/main.yml          → Reload systemd + Restart hermes-agent
+├── tasks/main.yml             → installation, config, service
+└── templates/
+    ├── hermes-agent.service.j2
+    └── config.yaml.j2
+```
+
+### Ce que fait le rôle
+
+1. **Dépendances** : `curl`, `git`, `tar` via dnf
+2. **Utilisateur** : `hermes` avec home `/opt/hermes` (SSD OS, petit)
+3. **HERMES_HOME** : `/srv/data/hermes` (RAID5) — données agent sur le stockage durable
+4. **Installation** : `curl | bash` idempotent via `stat` sur le binaire (`/opt/hermes/.local/bin/hermes`)
+5. **Config** : `config.yaml` déployé dans `HERMES_HOME` (template Jinja2)
+6. **Service** : `hermes-agent.service` — `User=hermes`, `ExecStart=hermes gateway`
+7. **Firewall** : port `8080/tcp` via firewalld (conditionnel si firewalld actif)
+
+### Variables clés
+
+| Variable | Valeur par défaut |
+|---|---|
+| `hermes_data_dir` | `/srv/data/hermes` (overridé dans host_vars) |
+| `hermes_lm_base_url` | `http://192.168.10.20:1234/v1` |
+| `hermes_model` | `google/gemma-4-e4b-it` |
+| `hermes_context_length` | `16384` |
+| `hermes_gateway_port` | `8080` |
+
+---
+
+## Documentation
+
+- `admin/hermes.md` — commandes admin, config, validation API, réinstallation
+- `admin/README.md` — entrée ajoutée pour hermes.md
+
+---
+
+## Prochaines étapes
+
+- [ ] Appliquer : `ansible-playbook -i inventory.yml playbooks/storage-01.yml --tags hermes_agent`
+- [ ] Vérifier que `hermes gateway` démarre sans erreur et écoute sur 8080
+- [ ] Ajuster `config.yaml.j2` si le format réel diffère (clé `llm.base_url` vs autre)
+- [ ] Route statique Freebox (192.168.10.0/24 → 192.168.1.200)
+- [ ] Premier commit GitHub (repo privé)
+- [ ] Stubs postgresql, qdrant, minio
--- a/progress/2026-05-11.md
+++ b/progress/2026-05-11.md
@ -0,0 +1,569 @@
+# 2026-05-11 — Hermes opérationnel sur Qwen3.5-9B
+
+## Résumé
+
+Hermes Agent pleinement fonctionnel sur storage-01 avec le modèle Qwen3.5-9B sur
+gpu-01. Chemin parcouru : 6 blocages techniques résolus dans la même session.
+
+---
+
+## Blocages rencontrés et résolus
+
+### 1. `auxiliary.compression.context_length` manquant dans config.yaml
+
+**Symptôme** : `Failed to initialize agent: Auxiliary compression model
+google/gemma-4-e4b has a context window of 4,096 tokens, which is below the
+minimum 64,000 required.`
+
+**Cause** : Hermes a deux vérifications de contexte distinctes — le modèle
+principal (`model.context_length`) et le modèle de compression auxiliaire
+(`auxiliary.compression.context_length`). Seule la première était surchargée.
+
+**Fix** : Ajout dans `roles/hermes_agent/templates/config.yaml.j2` :
+```yaml
+auxiliary:
+  compression:
+    context_length: {{ hermes_context_length }}
+```
+
+---
+
+### 2. Crash GPU Vulkan sur Gemma 4 E4B avec long prompt (>800 tokens)
+
+**Symptôme** : `The model has crashed without additional information. (Exit code: null)`
+dès le premier appel Hermes (system prompt ~15 000 tokens). Modèle rechargé avec
+n_ctx=4096 par défaut, puis erreur de contexte en cascade.
+
+**Cause** : Bug dans le backend Vulkan de llama.cpp avec l'architecture Gemma 4.
+Gemma 4 utilise une attention interleaved global/local avec sliding window de 512
+tokens. Quand le prompt dépasse 800 tokens (juste au-delà du sliding window), les
+layers d'attention globale crashent dans l'implémentation Vulkan. Confirmé par
+test binaire : OK à 500 tokens, crash à ~900 tokens.
+
+**Note** : Le crash n'est pas lié à la VRAM — Gemma 4 utilise GQA aggressif, le
+KV cache réel à 65536 tokens est ~2 GB seulement (7 global layers × 65536 × 4096
+bytes). La VRAM ne serait pas le facteur limitant.
+
+**Fix** : Passage sur Qwen3.5-9B qui utilise une attention GQA standard, sans
+problème Vulkan connu. Fichiers modifiés :
+- `host_vars/gpu-01/vars.yml` : `lm_studio_default_model: "qwen/qwen3.5-9b"`
+- `roles/hermes_agent/defaults/main.yml` : `hermes_model: "qwen/qwen3.5-9b"`
+
+---
+
+### 3. dnsmasq crash au boot (interface USB ethernet non disponible)
+
+**Symptôme** : Après reboot de storage-01, gpu-01 ne peut plus télécharger
+de paquets (`yum makecache` bloque). DNS timeout vers 192.168.10.1.
+
+**Cause** : dnsmasq démarre avec `After=network.target` mais l'interface USB
+ethernet `enp6s0f3u2c2` prend plus de temps à apparaître. dnsmasq log :
+`dnsmasq: unknown interface enp6s0f3u2c2` → crash.
+
+**Fix** :
+- Immédiat : `systemctl reset-failed dnsmasq && systemctl start dnsmasq`
+- Permanent : override systemd dans `roles/dnsmasq/tasks/main.yml` qui crée
+  `/etc/systemd/system/dnsmasq.service.d/wait-for-network.conf` :
+  ```ini
+  [Unit]
+  After=network-online.target
+  Wants=network-online.target
+  ```
+
+---
+
+### 4. `LM_API_KEY=qwen/qwen3.5-9b` dans le .env de Hermes
+
+**Symptôme** : `Failed to initialize agent: Failed to initialize OpenAI client:
+bad marshal data (invalid reference)` — erreur trompeuse, masque le vrai problème.
+
+**Cause** : La commande `hermes model` avait écrit le nom du modèle à la place
+de la clé API dans `/srv/data/hermes/.env`. La clé API pour LM Studio doit être
+une chaîne arbitraire (`lm-studio`), pas le nom du modèle.
+
+**Fix** : `sed -i 's/^LM_API_KEY=.*/LM_API_KEY=lm-studio/' /srv/data/hermes/.env`
+
+---
+
+### 5. Fichiers `.pyc` pydantic corrompus sur le RAID5
+
+**Symptôme** : `Failed to initialize OpenAI client: bad marshal data (invalid
+reference)` persistait même après fix du .env.
+
+**Cause** : Le reboot du RAID5 a laissé des fichiers `.pyc` Python partiellement
+écrits dans le venv de Hermes. Spécifiquement `pydantic/fields` et ses
+dépendances. Python essaie de charger le bytecode compilé → `ValueError: bad
+marshal data (invalid reference)`.
+
+**Traceback exact** :
+```
+File ".../openai/_models.py", line 39, in <module>
+    from pydantic.fields import FieldInfo
+  File "<frozen importlib._bootstrap_external>", line 729, in _compile_bytecode
+ValueError: bad marshal data (invalid reference)
+```
+
+**Fix** :
+```bash
+find /srv/data/hermes/hermes-agent/venv/lib/python3.11/site-packages \
+  -name '*.pyc' -delete
+```
+Python recompile les `.pyc` au prochain import depuis les `.py` sources (intacts).
+
+**Leçon** : Données applicatives sur RAID5 = écriture partielle possible sur
+reboot non-propre. Les fichiers `.pyc` ne sont pas critiques (régénérables) mais
+peuvent bloquer l'application entièrement.
+
+---
+
+## Changements ansible
+
+| Fichier | Changement |
+|---|---|
+| `roles/common/tasks/main.yml` | Ajout tâche `Upgrade all packages` (tag `update`) |
+| `roles/common/handlers/main.yml` | Ajout handler `Reboot if kernel updated` |
+| `roles/lm_studio/tasks/main.yml` | Ajout `socat` dans les dépendances dnf |
+| `roles/lm_studio/files/run-llmster.sh` | Ajout `lms unload --all` avant le chargement du modèle |
+| `roles/hermes_agent/templates/config.yaml.j2` | Ajout `auxiliary.compression.context_length` |
+| `roles/hermes_agent/defaults/main.yml` | Modèle passé à `qwen/qwen3.5-9b` |
+| `roles/dnsmasq/tasks/main.yml` | Ajout override systemd `wait-for-network.conf` |
+| `roles/dnsmasq/handlers/main.yml` | Ajout handler `Reload systemd` |
+| `host_vars/gpu-01/vars.yml` | `lm_studio_default_model: "qwen/qwen3.5-9b"` |
+
+---
+
+## État final
+
+- Hermes Agent opérationnel sur storage-01 (`hermes chat` fonctionne)
+- Modèle Qwen3.5-9B chargé sur gpu-01 avec contexte 65 536 tokens via Vulkan
+- Proxy socat actif : `192.168.10.20:1234` → `127.0.0.1:1234` (contourne le
+  rebind llmster post-Vulkan)
+- DNS résolu après reboot grâce à l'override `network-online.target`
+- Mises à jour système effectuées sur storage-01 et gpu-01
+
+## Prochaines étapes (après session matin)
+
+- Configurer Claude (API Anthropic) comme second modèle dans Hermes
+- Route statique Freebox : `192.168.10.0/24` → `192.168.1.200`
+- Premier commit GitHub (repo privé)
+- Stubs rôles : `postgresql`, `qdrant`, `minio`
+
+---
+
+# 2026-05-11 — Session après-midi : llama-server ROCm (remplacement LM Studio)
+
+## Résumé
+
+Remplacement complet de LM Studio pour l'inférence par **llama-server** compilé from
+source avec ROCm 7.x. Gain de performance ×5 (15 → 70 tok/s génération). Résolution
+du bug de contexte `--parallel 4` qui limitait chaque slot à 8192 tokens.
+
+---
+
+## Blocages rencontrés et résolus
+
+### 6. Hermes — temps de réponse de 2 minutes
+
+**Symptôme** : Hermes met ~2 minutes pour répondre, même sur des requêtes courtes.
+
+**Investigation** :
+- `nvtop` : GPU à 90% pendant les 2 minutes → le GPU est utilisé, pas d'idle
+- `journalctl -u lm-studio` : backend = **Vulkan** (pas ROCm)
+- Comparaison : Vulkan ~100 tok/s prefill / ~15 tok/s génération ; Hermes system
+  prompt ≈ 15 000 tokens → ~2 min juste pour le prefill (15 000 ÷ 100 ≈ 150s)
+
+**Tentative 1 — activer le backend ROCm de LM Studio** :
+- `lms runtime get lmstudio-community/gguf-parser --release latest` : backends
+  dans `.lmstudio/extensions/backends/` (Node.js addons + libs partagées)
+- Backend ROCm compilé pour ROCm 6.x : `libhipblas.so.2`, `librocblas.so.4`,
+  `libamdhip64.so.6` — ROCm 7.2.3 installé expose `.so.3`, `.so.5`, `.so.7`
+- Tentative patchelf pour corriger les SONAME : fixe les DT_NEEDED entries
+  mais incompatibilité ABI profonde (structs, signatures de fonctions changées
+  entre ROCm 6 et 7 — SONAME seul n'est pas suffisant)
+- Résultat : crash GPU au warmup (`Exit code: null` = SIGSEGV) pour tous les modèles
+
+**Fix final — llama.cpp compilé from source avec ROCm 7.x** (option B) :
+
+---
+
+### 7. Build llama.cpp from source (ROCm 7.x)
+
+**Packages requis** (non installés initialement) :
+```bash
+sudo dnf install -y hipblas-devel rocblas-devel hip-devel hipcc cmake gcc-c++ git patchelf
+```
+
+**Problème cmake — HIP compiler** :
+- `cmake -DCMAKE_HIP_COMPILER=hipcc` → rejeté (pas dans PATH, cmake ne trouve pas)
+- Fix : utiliser le chemin absolu `{{ rocm_path }}/llvm/bin/clang++`
+
+**Commande de build finale** :
+```bash
+cd /opt/llama.cpp
+cmake -B build \
+  -DGGML_HIP=ON \
+  -DAMDGPU_TARGETS=gfx1030 \
+  -DCMAKE_BUILD_TYPE=Release \
+  -DROCM_PATH=/opt/rocm \
+  -DCMAKE_PREFIX_PATH=/opt/rocm \
+  -DCMAKE_HIP_COMPILER=/opt/rocm/llvm/bin/clang++
+cmake --build build --target llama-server -j$(nproc)
+```
+
+**Note gfx1031 → gfx1030** : RX 6700XT = gfx1031 (non officiel). Target cmake =
+`gfx1030` (compatible) + `HSA_OVERRIDE_GFX_VERSION=10.3.0` dans le service systemd.
+
+**Autre problème** : après `systemctl stop lm-studio`, le processus `llmster`
+survivait (double-fork) et tenait le port 1234.
+Fix : `sudo kill $(pgrep llmster) && sudo kill $(pgrep socat)`
+
+---
+
+### 8. Tentative Qwen3.5-9B sur llama-server — crash ROCm
+
+**Symptôme** : `llama-server` crash au warmup avec Qwen3.5-9B (`ggml_cuda_op_mul_mat`
+assertion failure).
+
+**Cause** : Qwen3.5-9B utilise l'architecture **Gated Delta Net** (hybride SSM +
+attention) — non supportée par le backend ROCm de llama.cpp. Confirmé : crash
+identique avec plusieurs versions GGUF de ce modèle.
+
+**Fix** : Passage sur **Qwen2.5-7B-Instruct** (transformer standard, GQA classique,
+aucun problème ROCm). Modèle déjà présent sur le NFS.
+
+---
+
+### 9. Bug `--parallel 4` — contexte insuffisant pour Hermes
+
+**Symptôme** : Hermes renvoie HTTP 400 `context window exceeded` même avec
+`--ctx-size 32768`. System prompt Hermes = 14 579 tokens.
+
+**Cause** : `--parallel N` divise le ctx-size *total* en N slots égaux.
+Avec `--parallel 4 --ctx-size 32768` → chaque slot = 8192 tokens.
+14 579 > 8192 → dépassement dès le premier appel Hermes.
+
+**Fix** :
+```bash
+sudo sed -i 's/--parallel 4/--parallel 1/' /etc/systemd/system/llama-server.service
+sudo systemctl daemon-reload && sudo systemctl restart llama-server
+```
+
+Corrigé aussi dans `roles/llama_server/defaults/main.yml` : `llama_parallel: 1`.
+
+---
+
+## Performances finales (RX 6700XT, ROCm 7.x natif)
+
+| Backend | Prefill | Génération | TTFT Hermes (15k tokens) |
+|---|---|---|---|
+| LM Studio Vulkan | ~100 tok/s | ~15 tok/s | ~150s |
+| llama-server ROCm 7.x | ~400 tok/s | ~70 tok/s | ~35s |
+
+Gain ×4 prefill, ×4.5 génération — gain ×4 sur le TTFT Hermes.
+
+---
+
+## Changements ansible
+
+| Fichier | Changement |
+|---|---|
+| `roles/llama_server/tasks/main.yml` | Création — build ROCm, service systemd, firewall, désactive lm-studio |
+| `roles/llama_server/defaults/main.yml` | Création — `llama_parallel: 1` (critique : 4 → context bug) |
+| `roles/llama_server/templates/llama-server.service.j2` | Création — template service systemd |
+| `roles/rocm/defaults/main.yml` | Ajout `rocm_build_packages` (hipblas-devel, rocblas-devel, hip-devel, hipcc) |
+| `roles/hermes_agent/defaults/main.yml` | Modèle → `qwen2.5-7b-instruct` |
+| `playbooks/gpu-01.yml` | Remplacement rôle `lm_studio` → `llama_server` |
+| `host_vars/gpu-01/vars.yml` | Suppression vars lm_studio, ajout `llama_model_path` + `llama_model_alias` |
+| `group_vars/gpu_hosts/vars.yml` | Suppression vars lm_studio (port, host, context) |
+| `admin/llama_server.md` | Création — doc ops complète |
+| `admin/lm_studio.md` | Refonte — gestion modèles uniquement, service désactivé |
+| `admin/hermes.md` | Mise à jour — modèle, config.yaml, endpoint llama-server |
+| `admin/systeme.md` | Table services gpu-01 : lm-studio → llama-server |
+| `admin/incidents.md` | Création — incident storage-01 XFS + résolution |
+| `admin/README.md` | Ajout entrées llama_server.md et incidents.md |
+
+---
+
+## État final
+
+- **llama-server** opérationnel sur gpu-01 (`192.168.10.20:1234`) — API OpenAI-compatible
+- **Modèle** : Qwen2.5-7B-Instruct Q4_K_S — 32768 tokens ctx, 1 slot (requis pour Hermes)
+- **Hermes** : fonctionne correctement, réponse en ~35s (vs 2 min avant)
+- **LM Studio** : désactivé pour l'inférence, reste installé pour `lms get` / `lms ls`
+
+## Prochaines étapes (après session matin, avant session LiteLLM)
+
+- ~~Configurer Claude (API Anthropic) comme second modèle dans Hermes~~ ✅ fait
+- Route statique Freebox : `192.168.10.0/24` → `192.168.1.200`
+- Premier commit GitHub (repo privé)
+- Stubs rôles : `postgresql`, `qdrant`, `minio`
+
+---
+
+# 2026-05-11 — Session soir : LiteLLM proxy + intégration Claude API
+
+## Résumé
+
+Déploiement de LiteLLM comme proxy unifié sur storage-01. Hermes passe désormais
+par LiteLLM pour toute inférence — Qwen local par défaut, Claude API switchable
+sans toucher à la configuration de Hermes.
+
+---
+
+## Blocages rencontrés et résolus
+
+### 10. Hermes ne résout pas le provider LiteLLM
+
+**Symptôme** : `hermes -z` échoue avec `AuthError: No inference provider configured`
+même avec `LM_BASE_URL=http://127.0.0.1:4000/v1` dans le `.env`.
+
+**Investigation** :
+- `hermes doctor` avec `LM_API_KEY=lm-studio` → "✓ API key or custom endpoint configured"
+- `hermes doctor` avec `LM_API_KEY=funk-litellm` → pas reconnu
+
+**Cause 1** : `LM_API_KEY` doit valoir `lm-studio` **exactement** — c'est la valeur
+magic qui active le provider "LM Studio" (OpenAI-compatible custom endpoint) dans Hermes.
+Toute autre valeur n'est pas reconnue.
+
+**Cause 2** : `config.yaml` manquait `model.provider: lmstudio` et `model.base_url`.
+Sans ces champs, Hermes ne sait pas quel provider utiliser même si `.env` est correct.
+
+**Format config.yaml correct** :
+```yaml
+model:
+  provider: lmstudio
+  base_url: "http://127.0.0.1:4000/v1"
+  default: "hermes-default"
+  context_length: 65536
+```
+
+**Fix** :
+- `LM_API_KEY=lm-studio` dans `.env` (géré par `lineinfile` Ansible)
+- `litellm_master_key: lm-studio` pour que LiteLLM accepte les requêtes Hermes
+- Ajout de `provider` et `base_url` dans le template `config.yaml.j2`
+
+---
+
+### 11. PermissionError hermes -z depuis le mauvais répertoire
+
+**Symptôme** : `PermissionError: [Errno 13] Permission denied: '/home/ansible/.git'`
+
+**Cause** : `hermes -z` remonte l'arborescence pour trouver un `.git`. Lancé depuis
+`/home/ansible`, l'utilisateur hermes n'a pas accès.
+
+**Fix** : Toujours lancer depuis `/srv/data/hermes` :
+```bash
+cd /srv/data/hermes && hermes -z "question"
+```
+
+---
+
+### 12. 404 sur /api/v1/models à l'init Hermes
+
+**Symptôme** : Logs LiteLLM montrent des `GET /api/v1/models HTTP/1.1" 404`.
+
+**Cause** : Hermes appelle `/api/v1/models` lors de l'initialisation — LiteLLM
+n'expose que `/v1/models`. Ce 404 n'est pas bloquant, les requêtes
+`POST /v1/chat/completions` fonctionnent normalement.
+
+**Fix** : Aucun — comportement Hermes attendu, sans impact fonctionnel.
+
+---
+
+## Architecture finale LiteLLM
+
+```
+Hermes (hermes-default)
+        │  LM_API_KEY=lm-studio
+        │  LM_BASE_URL=http://127.0.0.1:4000/v1
+        ▼
+   LiteLLM (:4000)  master_key=lm-studio
+        │
+        ├── hermes-default → qwen2.5-7b-instruct → llama-server gpu-01  (défaut)
+        ├── hermes-default → claude-sonnet-4-6   → api.anthropic.com    (switch)
+        └── [autres modèles accessibles par nom direct]
+```
+
+**Switch sans toucher Hermes** : modifier uniquement le bloc `hermes-default`
+dans `/etc/litellm/config.yaml` + `sudo systemctl restart litellm`.
+
+**Proof** : Qwen répond "Je suis Claude" (hallucination sur l'identité — comportement
+normal des 7B). La GPU qui chauffe sur gpu-01 est la vraie source de vérité.
+
+---
+
+## Changements ansible
+
+| Fichier | Changement |
+|---|---|
+| `roles/litellm/` | Création complète du rôle (defaults, tasks, handlers, templates) |
+| `roles/litellm/templates/config.yaml.j2` | Alias `hermes-default` + 3 modèles |
+| `roles/litellm/defaults/main.yml` | `master_key: lm-studio`, `host: 127.0.0.1` |
+| `roles/hermes_agent/defaults/main.yml` | `hermes_lm_base_url: 127.0.0.1:4000`, `api_key: lm-studio` |
+| `roles/hermes_agent/templates/config.yaml.j2` | Ajout `provider: lmstudio`, `base_url`, `model.default` |
+| `roles/hermes_agent/templates/hermes-agent.service.j2` | `LM_BASE_URL`/`LM_API_KEY` (pas HERMES_LLM_*), `gateway run` |
+| `roles/hermes_agent/tasks/main.yml` | Tâches `lineinfile` pour `.env` (LM_BASE_URL, LM_API_KEY) |
+| `playbooks/storage-01.yml` | Rôle `litellm` ajouté avant `hermes_agent` |
+| `group_vars/all/vault.yml` | `vault_anthropic_api_key` (clé Anthropic chiffrée) |
+| `admin/hermes.md` | Refonte complète — architecture LiteLLM, config correcte, switch |
+| `admin/litellm.md` | Correction master_key, procédure switch, points d'attention |
+
+---
+
+## État final
+
+- **LiteLLM** opérationnel sur storage-01 (:4000), 4 modèles enregistrés
+- **Hermes** utilise Qwen local via LiteLLM — ~70 tok/s, gratuit
+- **Claude Sonnet/Opus** disponibles via switch LiteLLM uniquement (clé API Anthropic en vault)
+- **Vault Ansible** : `vault_anthropic_api_key` chiffré dans `group_vars/all/vault.yml`
+
+## Prochaines étapes
+
+- Route statique Freebox : `192.168.10.0/24` → `192.168.1.200`
+- Premier commit GitHub (repo privé)
+- **Mémoire Hermes sur cluster** : Qdrant (vectoriel) + PostgreSQL sur storage-01,
+  embeddings via Qwen, retrieval via Claude API pour les tâches complexes
+- Stubs rôles : `postgresql`, `qdrant`, `minio`
+
+---
+
+# 2026-05-11 — Session nuit : Qdrant + PostgreSQL + embeddings + upgrade 14B
+
+## Résumé
+
+Déploiement de la stack mémoire vectorielle complète pour Hermes : PostgreSQL 16 et
+Qdrant v1.13.4 sur storage-01 (RAID5). Activation des embeddings sur llama-server.
+Installation du skill qdrant-vector-search dans Hermes. Indexation de 17 chunks de
+connaissance dans Qdrant. Upgrade modèle Qwen2.5-7B → 14B.
+
+---
+
+## Blocages rencontrés et résolus
+
+### 13. Embeddings llama-server — erreur 400 pooling
+
+**Symptôme** : `curl /v1/embeddings` → `400 Pooling type 'none' is not OAI compatible`
+
+**Cause** : Sur les LLM causaux (Qwen2.5), le pooling par défaut de llama-server est
+`none` (pas de agrégation des token embeddings). Le format OAI attend un vecteur unique.
+
+**Fix** : Ajout du flag `--pooling mean` dans le template service llama-server.
+Variables Ansible : `llama_embeddings: true` + `llama_pooling: "mean"`.
+
+---
+
+### 14. qdrant-client non installé dans le venv Hermes
+
+**Symptôme** : `ModuleNotFoundError: No module named 'qdrant_client'` lors des tests Python.
+
+**Cause** : Le skill qdrant-vector-search fournit la documentation API à Hermes mais
+n'installe pas automatiquement qdrant-client dans tous les environnements.
+
+**Fix** : Installation manuelle + ajout dans le rôle Ansible :
+```bash
+/srv/data/hermes/hermes-agent/venv/bin/pip install "qdrant-client>=1.12.0"
+```
+Tâche `ansible.builtin.pip` ajoutée dans `roles/hermes_agent/tasks/main.yml`.
+
+---
+
+### 15. Hermes utilise execute_code (mauvais env Python) au lieu du terminal
+
+**Symptôme** : Hermes échoue en boucle quand on lui demande d'utiliser qdrant-client.
+Il utilise l'outil `🐍 execute_code` qui tourne dans son propre env Python sans qdrant-client.
+
+**Cause** : Qwen 7B ne sait pas distinguer quand utiliser `execute_code` vs `terminal`.
+Sur les tâches avec imports externes, il faut forcer l'approche "écrire un script + terminal".
+
+**Workaround** : Écrire le script dans `/tmp/script.py` puis exécuter via terminal avec
+le chemin complet `/srv/data/hermes/hermes-agent/venv/bin/python /tmp/script.py`.
+
+**Fix structurel** : PATH du venv ajouté dans le service systemd hermes-agent et
+dans `~/.bashrc` de l'utilisateur hermes.
+
+---
+
+### 16. Segfault llama-server avec Qwen2.5-14B à 32k contexte
+
+**Symptôme** : `code=dumped, signal=SEGV` au démarrage du service après upgrade 14B.
+
+**Cause** : VRAM insuffisante. Qwen2.5-14B Q4_K_M ≈ 8 GB + KV cache 32k ≈ 6 GB = ~14 GB
+→ dépasse les 12 GB de la RX 6700XT.
+
+**Fix** : Réduction du contexte à 16384 tokens dans `host_vars/gpu-01/vars.yml` :
+```yaml
+llama_ctx_size: 16384
+```
+Budget VRAM résultant : ~8 GB (modèle) + ~3 GB (KV cache) = ~11 GB ✅
+
+---
+
+### 17. qdrant-client API : client.search() supprimé en v1.14+
+
+**Découverte** : qdrant-client v1.18 (installé dans le venv) vs serveur Qdrant v1.13.4.
+La méthode `client.search()` a été supprimée en v1.14 — utiliser `client.query_points()`.
+
+**Note** : Warning de compatibilité de version (majeure OK, mineure diff > 1) affiché
+au démarrage du client mais sans impact fonctionnel sur les opérations de base.
+
+---
+
+## Réalisations
+
+### Qdrant opérationnel
+- Collection `hermes_memory` créée : dim=5120 (14B), distance=COSINE
+- 17 chunks de connaissance indexés (architecture, Hermes, LiteLLM, ROCm, PostgreSQL, Ansible)
+- Recherche sémantique validée : score 0.82-0.85 sur requêtes pertinentes
+- Script d'indexation : `admin/index_knowledge.py`
+
+### Skill Hermes
+- `mlops/qdrant` (qdrant-vector-search) installé et actif
+- qdrant-client v1.18 dans le venv Hermes
+- PATH venv dans service systemd et bashrc
+
+### Script hermes-switch
+- `/usr/local/bin/hermes-switch [qwen|claude|status]`
+- Switch LiteLLM + restart automatique
+- Déployé via `roles/litellm/files/hermes-switch`
+
+### Upgrade modèle
+- Qwen2.5-7B → Qwen2.5-14B Q4_K_M
+- Contexte : 32768 → 16384 (contrainte VRAM)
+- Alias API : `qwen2.5-14b-instruct`
+
+---
+
+## Changements ansible
+
+| Fichier | Changement |
+|---|---|
+| `roles/llama_server/defaults/main.yml` | Ajout `llama_embeddings: true`, `llama_pooling: mean` |
+| `roles/llama_server/templates/llama-server.service.j2` | Flags `--embeddings --pooling mean` conditionnels |
+| `roles/hermes_agent/tasks/main.yml` | pip install qdrant-client, PATH venv dans bashrc |
+| `roles/hermes_agent/templates/hermes-agent.service.j2` | `Environment=PATH` avec venv en premier |
+| `roles/litellm/files/hermes-switch` | Création script switch modèle |
+| `roles/litellm/tasks/main.yml` | Déploiement hermes-switch |
+| `roles/litellm/templates/config.yaml.j2` | Alias `qwen2.5-14b-instruct` (remplace 7b) |
+| `host_vars/gpu-01/vars.yml` | Modèle 14B, `llama_ctx_size: 16384` |
+| `admin/index_knowledge.py` | Script indexation Qdrant (17 chunks) |
+| `admin/llama_server.md` | Modèle 14B, embeddings, contrainte VRAM documentés |
+| `admin/litellm.md` | hermes-switch documenté, alias mis à jour |
+| `admin/hermes.md` | Section skill Qdrant ajoutée |
+
+---
+
+## État final
+
+- **PostgreSQL 16** : opérationnel sur storage-01 (RAID5 `/srv/data/postgres`)
+- **Qdrant v1.13.4** : opérationnel sur storage-01 (RAID5 `/srv/data/qdrant`)
+- **llama-server** : Qwen2.5-14B, 16384 ctx, embeddings activés
+- **Hermes** : skill qdrant actif, 17 chunks indexés dans `hermes_memory`
+- **hermes-switch** : déployé et fonctionnel
+
+## Prochaines étapes
+
+- Route statique Freebox : `192.168.10.0/24` → `192.168.1.200`
+- Premier commit GitHub (repo privé)
+- Tester Hermes 14B sur les tâches agent complexes (Qdrant queries)
+- Mettre à jour la dimension des vecteurs dans index_knowledge.py (5120 pour 14B vs 3584 pour 7B)
+- MinIO : rôle à déployer
--- a/progress/2026-05-12.md
+++ b/progress/2026-05-12.md
@ -0,0 +1,122 @@
+# 2026-05-12 — Kubernetes (Flannel fix, MetalLB, Traefik, DNS) + Architecture multi-modèles
+
+## Résumé
+
+Cluster Kubernetes opérationnel : correction du crash Flannel, déploiement MetalLB L2 +
+Traefik + wildcard DNS `*.lab.local`. Mise en place de l'architecture multi-modèles sur
+gpu-01 : 1 instance GPU + 2 instances CPU avec isolation CPUAffinity/MemoryMax.
+Création des 5 profils Hermes. Documentation complète admin/install/.
+
+---
+
+## Flannel CrashLoopBackOff
+
+**Symptôme** : 2 pods flannel en `CrashLoopBackOff` dans kube-system.
+
+**Cause** : Le `ClusterRoleBinding flannel` pointait vers le namespace `kube-flannel`
+(supprimé) au lieu de `kube-system`.
+
+**Fix** :
+```bash
+kubectl patch clusterrolebinding flannel --type='json' \
+  -p='[{"op":"replace","path":"/subjects/0/namespace","value":"kube-system"}]'
+```
+
+---
+
+## MetalLB + Traefik + DNS wildcard
+
+- MetalLB L2 mode : pool `192.168.10.200-230`
+- Traefik : `loadBalancerIP: 192.168.10.200`, helm `logs.general.level=INFO`
+  (pas `log.level` — paramètre invalide → rollback helm)
+- dnsmasq wildcard : `address=/.lab.local/192.168.10.200`
+  → toutes les entrées `*.lab.local` résolvent vers Traefik
+
+---
+
+## Architecture multi-modèles gpu-01
+
+### Instances llama-server
+
+| Service | Port | Modèle | Infra | Isolation |
+|---|---|---|---|---|
+| `llama-server` | 1234 | Qwen3-8B Q4_K_M | GPU RX 6700XT | ROCm |
+| `llama-server-system` | 1236 | Qwen3-1.7B Q4_K_M | CPUs 0-6,16-22 | 6G RAM |
+| `llama-server-monitor` | 1237 | Qwen3-1.7B Q4_K_M | CPUs 7-13,23-29 | 6G RAM |
+
+GPU = RX 6700XT 12 GB VRAM, CPU = Ryzen 9 5950X 16c/32t (32 GB RAM)
+
+### Masquage GPU pour les instances CPU
+
+Les instances CPU crashaient en SEGV car ROCm tentait d'initialiser le GPU même
+avec `--n-gpu-layers 0` :
+```ini
+Environment=ROCR_VISIBLE_DEVICES=
+Environment=HIP_VISIBLE_DEVICES=-1
+```
+
+### Ouverture firewall
+
+```bash
+firewall-cmd --permanent --add-port=1235/tcp --add-port=1236/tcp --add-port=1237/tcp
+firewall-cmd --reload
+```
+
+---
+
+## 5 profils Hermes
+
+Créés avec `HERMES_HOME=/srv/data/hermes hermes profile create <nom>` puis configurés
+dans `/srv/data/hermes/profiles/<nom>/config.yaml`.
+
+| Profil | Modèle LiteLLM | Rôle |
+|---|---|---|
+| `funk-ai` | `qwen3-8b` (GPU) | Principal — par défaut |
+| `brain` | `claude-sonnet-4-6` (API) | Analyse complexe |
+| `dev` | `qwen2.5-7b-dev` (CPU) | Développement (supprimé en session suivante) |
+| `system` | `qwen3-1.7b-system` (CPU) | Tâches système rapides |
+| `monitor` | `qwen3-1.7b-monitor` (CPU) | Monitoring rapide |
+
+Tous pointent vers LiteLLM (`http://127.0.0.1:4000/v1`) qui route selon le modèle.
+
+### Problème HERMES_HOME vs HOME
+
+Les profils créés sans `HERMES_HOME` explicite étaient créés dans `/opt/hermes/.hermes/`
+(HOME du compte hermes) au lieu de `/srv/data/hermes/` (HERMES_HOME).
+
+**Fix** : Toujours préfixer avec `HERMES_HOME=/srv/data/hermes` pour toutes les commandes hermes.
+
+### Problème contexte 64k minimum
+
+Hermes exige un contexte ≥ 64 000 tokens pour tout modèle. Override via config.yaml :
+```yaml
+model:
+  context_length: 65536  # override le check Hermes — llama-server peut rester à 32768
+```
+
+### Profil par défaut
+
+```bash
+HERMES_HOME=/srv/data/hermes hermes profile use funk-ai
+```
+
+---
+
+## Documentation créée
+
+| Fichier | Contenu |
+|---|---|
+| `admin/install/storage-01.md` | Guide complet installation AlmaLinux → RAID5 → 8 phases Ansible |
+| `admin/install/gpu-01.md` | AlmaLinux → ROCm → NFS → llama-server |
+| `admin/install/kubernetes.md` | Talos → talhelper → MetalLB → Traefik → DNS wildcard |
+| `admin/install/README.md` | Index + ordre d'installation |
+| `admin/README.md` | Refonte — 2 sections : guides install vs référence opérationnelle |
+
+---
+
+## État final
+
+- Cluster k8s : Flannel OK, MetalLB OK, Traefik OK, DNS wildcard OK
+- gpu-01 : 3 instances llama-server (GPU + 2 CPU)
+- LiteLLM : 5 modèles routés (qwen3-8b, qwen3-1.7b-system/monitor, claude-sonnet/opus)
+- Hermes : 5 profils créés, `funk-ai` par défaut
--- a/progress/2026-05-13.md
+++ b/progress/2026-05-13.md
@ -0,0 +1,140 @@
+# 2026-05-13 — Stabilisation multi-modèles + profils Hermes finalisés
+
+## Résumé
+
+Stabilisation de l'architecture multi-modèles sur gpu-01. Résolution des OOM kills,
+ajustement des ressources CPU/RAM pour les instances system et monitor. Profils Hermes
+testés et fonctionnels. Architecture finale : 2 instances Qwen3-1.7B sur 14 CPUs
+chacune pour des réponses rapides (<3s).
+
+---
+
+## Blocages résolus
+
+### OOM kill instances CPU à 6 GB
+
+**Symptôme** : `llama-server-system` tué par l'OOM killer en boucle (restart counter >45).
+```
+llama-server-system.service: A process of this unit has been killed by the OOM killer.
+```
+
+**Cause** : Qwen3-1.7B avec `--ctx-size 65536` consomme ~6.2 GB (modèle + KV cache).
+Le `MemoryMax=6G` était trop juste.
+
+**Fix** : `MemoryMax=8G` puis passage à 14 CPUs (voir section suivante).
+
+---
+
+### --cache-type-k q8_0 crash llama-server GPU
+
+**Symptôme** : segfault en boucle dès le démarrage du service GPU.
+```
+Process 24687 (llama-server) dumped core.
+Stack: _ZNK13llama_context5n_ctxEv → load_model
+```
+
+**Cause** : La version compilée de llama-server ne supporte pas le flag `--cache-type-k q8_0`.
+Crash immédiat dans la phase d'allocation du KV cache.
+
+**Fix** : Retrait du flag. GPU reste à `--ctx-size 32768` sans quantification KV.
+
+**À retenir** : Ne pas utiliser `--cache-type-k` sur ce build llama.cpp.
+
+---
+
+### Qwen2.5-14B OOM avec MemoryMax 14 GB
+
+**Tentative** : Utiliser Qwen2.5-14B sur CPU avec 14 GB RAM pour avoir un meilleur modèle.
+
+**Cause du fail** : Qwen2.5-14B a `head_dim=256` (vs 128 pour les autres). Le KV cache
+à 65536 tokens = **24 GB** seul. Même à 32768 tokens : 12 GB KV + 8.8 GB modèle = 21 GB.
+Incompatible avec 14 GB MemoryMax quelle que soit la configuration.
+
+**Fix** : Retour sur Qwen3-1.7B — modèle ultra-léger (1.1 GB), KV cache à 32768 = ~3.5 GB.
+Total ~4.8 GB, largement dans 14 GB.
+
+---
+
+## Architecture finale gpu-01
+
+### Ressources CPU (5950X 16c/32t)
+
+| Zone | CPUs logiques | Cœurs physiques | Usage |
+|---|---|---|---|
+| system | 0-6, 16-22 | 0-6 (× 2 threads) | llama-server-system |
+| monitor | 7-13, 23-29 | 7-13 (× 2 threads) | llama-server-monitor |
+| libre | 14-15, 30-31 | 14-15 | OS + GPU coordination |
+
+### Services
+
+| Service | Port | Modèle | CPUs | RAM | Vitesse |
+|---|---|---|---|---|---|
+| `llama-server` | 1234 | Qwen3-8B GPU | — | VRAM 12G | ~35 tok/s |
+| `llama-server-system` | 1236 | Qwen3-1.7B | 14 (0-6,16-22) | 6G | ~21 tok/s |
+| `llama-server-monitor` | 1237 | Qwen3-1.7B | 14 (7-13,23-29) | 6G | ~21 tok/s |
+
+### Profil dev supprimé
+
+`llama-server-dev` (port 1235, Qwen2.5-7B) supprimé. Ses ressources redistribuées.
+`qwen2.5-7b-dev` retiré de LiteLLM. Profil Hermes `dev` gardé mais inutilisé.
+
+---
+
+## Profils Hermes
+
+### Tableau final
+
+| Profil | Alias | Modèle | Usage |
+|---|---|---|---|
+| `funk-ai` ◆ | `funk-ai` | qwen3-8b (GPU) | Principal, par défaut |
+| `brain` | `brain` | claude-sonnet-4-6 | Analyse complexe / coûteux |
+| `system` | `system` | qwen3-1.7b-system | Appels rapides depuis funk-ai/brain |
+| `monitor` | `monitor` | qwen3-1.7b-monitor | Appels rapides depuis funk-ai/brain |
+
+### Changer de profil
+
+Pas de changement à chaud dans le TUI — ouvrir une nouvelle session :
+```bash
+funk-ai     # TUI avec Qwen3-8B GPU (défaut)
+brain       # TUI avec Claude Sonnet
+system      # TUI avec Qwen3-1.7B (appels rapides)
+monitor     # TUI avec Qwen3-1.7B (appels rapides)
+```
+
+### context_length override
+
+Hermes exige 64k context minimum. Les modèles CPU reportent 32768 via `/v1/models`.
+Override dans chaque `profiles/<nom>/config.yaml` :
+```yaml
+model:
+  context_length: 65536   # bypass la vérification Hermes
+```
+
+---
+
+## LiteLLM config finale
+
+```yaml
+# GPU
+hermes-default / qwen3-8b → http://192.168.10.20:1234/v1
+# CPU
+qwen3-1.7b-system         → http://192.168.10.20:1236/v1
+qwen3-1.7b-monitor        → http://192.168.10.20:1237/v1
+# Cloud
+claude-sonnet-4-6 / claude-opus-4-7 → api.anthropic.com
+```
+
+---
+
+## État final
+
+- `funk-ai` : opérationnel, profil par défaut ✅
+- `brain` : opérationnel (Claude API) ✅
+- `system` : Qwen3-1.7B 14 CPUs, ~21 tok/s ✅
+- `monitor` : Qwen3-1.7B 14 CPUs, ~21 tok/s ✅
+
+## Prochaines étapes
+
+- Tester les appels inter-profils (funk-ai → system/monitor via tool calls)
+- Commit git initial du repo
+- Route statique Freebox `192.168.10.0/24` → `192.168.1.200`
--- a/progress/2026-05-14.md
+++ b/progress/2026-05-14.md
@ -0,0 +1,47 @@
+# 2026-05-14 — Monitoring complet, RAG Hermes, Souls révisés
+
+## Monitoring & Alerting
+
+- **Stack complète** : kube-prometheus-stack, Grafana/Prometheus/AlertManager ingress, 3 dashboards custom (k8s/infra/ia)
+- **Dashboard infrastructure enrichi** : 20+ panels — CPU/RAM/disque, températures CPU+GPU, uptime, RAID5 état/disques, swap, section services systemd (12 stat panels + NFS I/O timeseries)
+- **Fixes dashboard** : mountpoint `/srv` → `/srv/data`, remplacement des regex `instance=~"192\\.168..."` par `job=` (bug PromQL escape), correction JSON stray comma
+- **Règles d'alerte** : PrometheusRule nodes/k8s/ia déployées via ArgoCD
+- **nftables** : ouverture ports 9100/9093/8080 pour pod CIDR `10.42.0.0/16` (Prometheus scraping + AlertManager webhook)
+
+## AlertManager → Hermes webhook
+
+- **Pipeline opérationnel** : AlertManager → `storage-01:9093/webhook` → `ask-agent monitor` → Hermes
+- **Fix BrokenPipeError** : HTTP 200 envoyé immédiatement, `ask-agent` lancé en `threading.Thread` daemon
+- **Fix ANSI parasites** : `NO_COLOR=1 TERM=dumb` passés en env au subprocess
+- **Doc** : `admin/ia/alertmanager-webhook.md` — architecture, test, dépannage, déploiement
+
+## RAG — Documentation Funk dans Hermes
+
+- **Qdrant** : collection `funk-docs` — 284 chunks indexés depuis `admin/`
+- **Scripts** : `rag-ingest` + `rag-query` déployés sur storage-01 (`/usr/local/bin/`)
+- **Embeddings** : Qwen3-8B via llama-server GPU port 1234 (`--embeddings --pooling mean`, dim=4096)
+- **Skill Hermes** : `funk/rag-docs` déployé dans le profil `funk-ai` — `rag-query` utilisable en CLI et depuis Hermes
+- **Rôle Ansible** : `ansible/roles/rag/` — sync docs + ingestion en handler Ansible
+- **Limite connue** : Qwen3-8B = modèle chat, scores peu discriminants (0.90–0.95 uniforme). Upgrade possible vers `nomic-embed-text` ou `bge-m3` si besoin
+- **Doc** : `admin/ia/rag.md` — architecture, mise à jour index, admin Qdrant, limitation embedding
+
+## Hermes — SOUL.md révisés
+
+- **funk-ai** : tableau services complet avec ports, rag-query comme outil, patterns courants (diagnostiquer, vérifier état général)
+- **monitor** : format VERDICT obligatoire (OK/WARNING/ERREUR/CRITIQUE), tableau services Funk + signes d'erreur, sévérités Prometheus, cas spéciaux (Watchdog, HSA_OVERRIDE)
+- **system** : contexte AlmaLinux/k8s ajouté, formats de réponse par type, exemples concrets
+- **brain** : contexte cluster complet (IPs, stack IA, contrainte GPU gfx1031, RAM k8s), quand l'appeler, formats structurés
+- **Doc** : `admin/ia/hermes-souls.md` — résumé des 4 profils, comparatif, déploiement
+
+## Réorganisation doc
+
+- `admin/ia/alertmanager-webhook.md` — nouveau
+- `admin/ia/rag.md` — nouveau
+- `admin/ia/hermes-souls.md` — nouveau
+- `admin/k8s/monitoring.md` — lien vers alertmanager-webhook.md
+
+## Fixes divers
+
+- `funk-cluster` : `check_k8s_pods()` — bug `grep -c || echo 0` double-valeur corrigé, variable intermédiaire
+- `funk-start` : auto-uncordon si nœuds SchedulingDisabled détectés, attente pods infra, `check_k8s_workloads` systématique
+- `funk-status` : `check_k8s_workloads` après vérification nœuds k8s