mirror of
https://github.com/Alkatrazz24/Funk-lab.git
synced 2026-07-10 11:04:42 +02:00
docs: progression 2026-05-14 + désignore progress/
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
alkatrazz
parent
e17396a150
commit
24c0bf9e12
9 changed files with 1093 additions and 2 deletions
2
.gitignore
vendored
2
.gitignore
vendored
|
|
@ -20,7 +20,7 @@ keys.txt
|
||||||
.claude/settings.local.json
|
.claude/settings.local.json
|
||||||
|
|
||||||
# Journaux de session (notes de debug, IPs, infos locales)
|
# Journaux de session (notes de debug, IPs, infos locales)
|
||||||
progress/
|
# progress/ — versionnés car référencés par PROGRESS.md
|
||||||
|
|
||||||
# Divers
|
# Divers
|
||||||
.DS_Store
|
.DS_Store
|
||||||
|
|
|
||||||
|
|
@ -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-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-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-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 |
|
||||||
|
|
|
||||||
40
progress/2026-05-09.md
Normal file
40
progress/2026-05-09.md
Normal file
|
|
@ -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 |
|
||||||
114
progress/2026-05-10.md
Normal file
114
progress/2026-05-10.md
Normal file
|
|
@ -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 |
|
||||||
59
progress/2026-05-10b.md
Normal file
59
progress/2026-05-10b.md
Normal file
|
|
@ -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
|
||||||
569
progress/2026-05-11.md
Normal file
569
progress/2026-05-11.md
Normal file
|
|
@ -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
|
||||||
122
progress/2026-05-12.md
Normal file
122
progress/2026-05-12.md
Normal file
|
|
@ -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
|
||||||
140
progress/2026-05-13.md
Normal file
140
progress/2026-05-13.md
Normal file
|
|
@ -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`
|
||||||
47
progress/2026-05-14.md
Normal file
47
progress/2026-05-14.md
Normal file
|
|
@ -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
|
||||||
Loading…
Add table
Add a link
Reference in a new issue