fix(gpu): débloque make apply-gpu — repo amdgpu rhel9.7 + pin commit llama.cpp (#47)

Le `dnf upgrade` du rôle common avait bumpé gpu-01 en AlmaLinux 9.8, mais
repo.radeon.com ne publie pas latest/rhel/9.8 (ni 9.5) — seulement 9.4/9.6/9.7.
`make apply-gpu` échouait alors dès `common` sur « Cannot download repomd.xml »
pour le repo amdgpu.

- rocm_rhel_version 9.4 → 9.7 (dernière mineure publiée par radeon) + piège
  documenté dans le README rocm (avec workaround live /etc/dnf/vars/amdgpudistro).
- Pin llama_server_commit au commit construit sur g01 : sans pin le rôle clonait
  HEAD → rebuild (~15 min) + restart GPU non déterministe à chaque apply.
- Réconciliation du drop-in llama-embed (ubatch 2048) dans l'unit rendu par le
  rôle (apply ciblé) ; drop-in temporaire supprimé. RAG validé (rag-query OK).
- Doc : etat-cluster + journal 2026-06-22 mis à jour.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

ansible/roles/llama_server/README.md

@@ -4,7 +4,10 @@ Compile llama.cpp (backend HIP/ROCm) et déploie le service **llama-server GPU**
 
 ## Ce que fait le rôle
 
-- Clone + build llama.cpp (cmake HIP, `gfx1030`) — build seulement si le binaire est absent
+- Clone + build llama.cpp (cmake HIP, `gfx1030`) — build seulement si le binaire est absent.
+  Le commit est **pinné** (`llama_server_commit`) : sans pin, le clone tirait `HEAD` et un
+  `make apply-gpu` pouvait déclencher un rebuild (~15 min) + restart GPU non déterministe. Pour
+  monter de version : bumper le SHA dans `defaults/main.yml`, puis l'apply rebuild de façon voulue.
 - Service systemd `llama-server` : modèle GGUF depuis `/mnt/models` (NFS), `:1234`
 - Embeddings activés (`--embeddings`, pooling mean)
 - Ouvre le port dans le firewall, désactive l'ancien service lm-studio

ansible/roles/llama_server/defaults/main.yml

@@ -2,6 +2,11 @@
 llama_server_port: 1234
 llama_server_host: "0.0.0.0"
 llama_amdgpu_targets: "gfx1030"
+# Commit llama.cpp pinné. Sans pin, le rôle clonait HEAD → chaque `make apply-gpu` pouvait se
+# déclarer « changed » et déclencher un rebuild complet (~15 min) + restart du llama-server GPU,
+# de façon non déterministe. Pinné = build reproductible et apply idempotent. Pour monter de
+# version : bumper ce SHA puis relancer un apply (le rebuild sera alors voulu et explicite).
+llama_server_commit: "84de01a1f1c847292b8d90a9c0bff6619f2919be"
 rocm_path: "/opt/rocm"
 hsa_override_gfx_version: "10.3.0"
 

ansible/roles/rocm/README.md

@@ -15,13 +15,34 @@ Stack GPU AMD sur gpu-01 (AlmaLinux, RX 6700XT) : repos AMD, runtime ROCm, paque
 
 | Variable | Défaut |
 |---|---|
-| `rocm_rhel_version` | `9.4` |
+| `rocm_rhel_version` | `9.7` |
 | `hsa_override_gfx_version` | `10.3.0` |
 
 ## ⚠️ Contrainte critique
 
 La RX 6700XT (**gfx1031**) n'est pas supportée officiellement par ROCm. Sans `HSA_OVERRIDE_GFX_VERSION=10.3.0` (la faire passer pour une gfx1030), **tout calcul GPU échoue**. La variable doit être présente dans l'environnement de chaque service GPU (le template systemd de llama_server la définit aussi).
 
+## ⚠️ Piège `rocm_rhel_version` — radeon.com ne publie pas toutes les mineures
+
+`repo.radeon.com/amdgpu/latest/rhel/<v>/` n'existe **pas** pour chaque mineure RHEL. Au 2026-06-22 :
+`9.4` ✅, `9.5` ❌, `9.6` ✅, `9.7` ✅, `9.8` ❌ — alors que gpu-01 tourne sous **AlmaLinux 9.8**.
+Il faut donc pinner `rocm_rhel_version` sur la dernière mineure **publiée** (`9.7`), pas sur le
+`VERSION_ID` de l'hôte.
+
+**Symptôme si décalé** (vécu le 2026-06-22 après un `dnf upgrade` qui a bumpé l'hôte en 9.8) :
+`make apply-gpu` échoue **dès le rôle `common`** :
+> `Failed to download metadata for repo 'amdgpu': Cannot download repomd.xml … All mirrors were tried`
+
+La cause est le **repo `amdgpu.repo` package-shipped** (écrit par `amdgpu-install`, visible via
+`amdgpu.repo.rpmsave`), dont la `baseurl` utilise `$amdgpudistro` (vide → repli sur `$releasever`
+= 9.8 → 404). Le repo géré par CE rôle (`latest/rhel/{{ rocm_rhel_version }}`) est correct, mais
+`common` tourne **avant** `rocm` dans le playbook → il bute sur le repo cassé en premier.
+
+**Workaround live** (soigne dnf immédiatement, sans rejouer le rôle) :
+```bash
+echo 9.7 > /etc/dnf/vars/amdgpudistro && dnf repolist   # doit lister amdgpu sans erreur
+```
+
 ## Caveat
 
 Les repos pointent vers `latest` — un `make apply-gpu` peut tirer une nouvelle version majeure de ROCm. Après upgrade kernel ou ROCm, vérifier `rocm-smi` et un completion de test avant de considérer le nœud sain (voir `admin/ia/rocm.md`).

ansible/roles/rocm/defaults/main.yml

@@ -1,5 +1,12 @@
 ---
-rocm_rhel_version: "9.4"
+# Version RHEL ciblée pour le repo amdgpu de radeon.com. ⚠️ NE PAS suivre aveuglément
+# le VERSION_ID de l'hôte : repo.radeon.com ne publie PAS toutes les mineures. Au 2026-06-22
+# il expose latest/rhel/{9.4, 9.6, 9.7} (PAS 9.5, PAS 9.8) — alors que gpu-01 est en AlmaLinux 9.8.
+# Pinné sur la plus récente publiée (9.7). Symptôme si décalé : `make apply-gpu` échoue dès le
+# rôle `common` sur « Failed to download metadata for repo 'amdgpu': Cannot download repomd.xml »
+# (le repo package-shipped utilise $amdgpudistro/$releasever → 9.8 → 404). Workaround live :
+# `echo 9.7 > /etc/dnf/vars/amdgpudistro`. Cf. ansible/roles/rocm/README.md.
+rocm_rhel_version: "9.7"
 rocm_amdgpu_repo: "https://repo.radeon.com/amdgpu/latest/rhel/{{ rocm_rhel_version }}/main/x86_64/"
 rocm_repo: "https://repo.radeon.com/rocm/rhel9/latest/main/"
 rocm_gpg_key: "https://repo.radeon.com/rocm/rocm.gpg.key"