From de1cd6c407742094000a66e921ae22e5044541a8 Mon Sep 17 00:00:00 2001 From: ALI YESILKAYA Date: Mon, 22 Jun 2026 21:19:02 +0200 Subject: [PATCH] =?UTF-8?q?fix(gpu):=20d=C3=A9bloque=20make=20apply-gpu=20?= =?UTF-8?q?=E2=80=94=20repo=20amdgpu=20rhel9.7=20+=20pin=20commit=20llama.?= =?UTF-8?q?cpp=20(#47)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- admin/ops/etat-cluster.md | 5 +++-- ansible/roles/llama_server/README.md | 5 ++++- ansible/roles/llama_server/defaults/main.yml | 5 +++++ ansible/roles/rocm/README.md | 23 +++++++++++++++++++- ansible/roles/rocm/defaults/main.yml | 9 +++++++- progress/2026-06-22.md | 17 +++++++++++++-- 6 files changed, 57 insertions(+), 7 deletions(-) diff --git a/admin/ops/etat-cluster.md b/admin/ops/etat-cluster.md index 8fa6b7f..46a85e0 100644 --- a/admin/ops/etat-cluster.md +++ b/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 diff --git a/ansible/roles/llama_server/README.md b/ansible/roles/llama_server/README.md index 61e79ac..697c370 100644 --- a/ansible/roles/llama_server/README.md +++ b/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 diff --git a/ansible/roles/llama_server/defaults/main.yml b/ansible/roles/llama_server/defaults/main.yml index c2a0688..1483fdf 100644 --- a/ansible/roles/llama_server/defaults/main.yml +++ b/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" diff --git a/ansible/roles/rocm/README.md b/ansible/roles/rocm/README.md index 9187c2a..e217713 100644 --- a/ansible/roles/rocm/README.md +++ b/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//` 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`). diff --git a/ansible/roles/rocm/defaults/main.yml b/ansible/roles/rocm/defaults/main.yml index 62a87c6..0232878 100644 --- a/ansible/roles/rocm/defaults/main.yml +++ b/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" diff --git a/progress/2026-06-22.md b/progress/2026-06-22.md index d107406..a484849 100644 --- a/progress/2026-06-22.md +++ b/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.