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>

admin/ops/etat-cluster.md

@@ -138,8 +138,9 @@
 > défaut (512)**, or en mode `--embeddings`+pooling toute l'entrée doit tenir dans un seul ubatch
 > → tout chunk > 512 tokens échouait (CHUNK_MAX=2000 chars ≈ 700 tokens). **Corrigé** : `--batch-size`
 > /`--ubatch-size = 2048` (= ctx) → ré-ingestion **436/436, 0 erreur**. Fix durable dans le rôle
-> `llama_server` (`llama_embed_ubatch_size`) ; appliqué en live via drop-in systemd sur g01 (à
-> réconcilier au prochain `make apply-gpu`). `rag-ingest` gagne aussi un retry sur 5xx transitoires.
+> `llama_server` (`llama_embed_ubatch_size`) — **réconcilié le 2026-06-22** : l'unit `llama-embed`
+> rendu par le rôle porte désormais les flags, drop-in systemd temporaire **supprimé**.
+> `rag-ingest` gagne aussi un retry sur 5xx transitoires.
 >
 > ⚠️ Drift IaC mineur (corrigé) : `ansible/roles/rag/defaults/main.yml` mentionnait encore
 > `embed_url: :1234` / `embed_model: qwen3-8b` (variables **mortes** — les scripts déployés

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"

progress/2026-06-22.md

@@ -51,8 +51,21 @@ et le **fix du batch embed** (`llama-embed` ubatch 512 → 2048). Détail : `pro
 
 ---
 
+## Réconciliation `make apply-gpu` + durcissement IaC (soir)
+
+- ✅ **Drop-in `llama-embed` réconcilié.** Apply ciblé `--tags llama_server` (commit llama.cpp pinné
+  → zéro rebuild, seul `llama-embed` redémarre) : l'unit rendu par le rôle porte maintenant
+  `--batch-size/--ubatch-size 2048`. Drop-in temporaire `batch.conf` **supprimé**. `ubatch 2048`
+  effectif sur le process, `rag-query` OK → RAG intact.
+- 🐛 **Repo `amdgpu` cassé sur gpu-01** (cause du blocage `make apply-gpu` complet) : le `dnf upgrade`
+  du rôle `common` avait bumpé l'hôte en AlmaLinux **9.8**, mais radeon.com ne publie pas de
+  `rhel/9.8` (ni 9.5) — seulement 9.4/9.6/**9.7**. Le repo package-shipped (`$amdgpudistro`) tombait
+  en 404. **Soigné en live** (`/etc/dnf/vars/amdgpudistro=9.7` → `dnf repolist` propre) et **durci en
+  IaC** : `rocm_rhel_version` 9.4 → 9.7, `llama_server_commit` pinné, pièges documentés dans les
+  README de rôle. (PR `fix/gpu-apply-amdgpu-repo-and-commit-pin`.)
+
 ## Prochaines étapes
 
-- Tester sur le poste : « Asa » réveille, « Asa stop » endort, partiels en direct (ASR onnx actif).
 - Si le wake word « asa » génère des faux positifs/négatifs, ajuster `wake_aliases`.
-- `make apply-gpu` (réconcilier le drop-in `llama-embed` du 21/06) + 1er test d'action vocale (#43).
+- **1er test d'action vocale** (#43, contexte 🤖 Agent → `hermes-exec`).
+- Vérifier qu'un `make apply-gpu` **complet** repasse vert (repo amdgpu sain) à la prochaine occasion.