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>
5.1 KiB
llama_server
Compile llama.cpp (backend HIP/ROCm) et déploie le service llama-server GPU (:1234) sur gpu-01. Sert aussi les embeddings du RAG.
Ce que fait le rôle
- 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 tiraitHEADet unmake apply-gpupouvait déclencher un rebuild (~15 min) + restart GPU non déterministe. Pour monter de version : bumper le SHA dansdefaults/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
- Instance dédiée embeddings (optionnelle,
llama_embed_enabled) : service systemdllama-embedservant un modèle d'embedding spécialisé (ex.nomic-embed-text) sur:1238. Télécharge le GGUF depuisllama_embed_model_urlsi absent. Tourne en CPU (llama_embed_n_gpu_layers: 0) : nomic est minuscule (137M) → ~100 ms déterministe, et ne partage pas la RX 6700XT avec le chat:1234. Mettre sur GPU (99) provoquait une latence bimodale (16 ms / 9-12 s) par contention →docs=0du STT (cf.admin/incidents-llm-gpu.md). - Heartbeat embed (optionnel,
llama_embed_heartbeat_enabled, défauttrue) : service systemdllama-embed-heartbeatqui envoie un petit embed à:1238toutes lesllama_embed_heartbeat_intervals → garde le slot d'embedding chaud. Sans ça, la 1ʳᵉ requête après une pause part à froid (5-8 s) et dépasse le timeout du STT-server (4 s) → recall mémoire vide et RAG documentaire raté (docs=0, cf.admin/ia/stt.md). Pendant dullm-heartbeat(rôlelitellm) côté chat. Logs :journalctl -u llama-embed-heartbeat.
Heartbeat embed — variables
| Variable | Défaut |
|---|---|
llama_embed_heartbeat_enabled |
true (si llama_embed_enabled) |
llama_embed_heartbeat_interval |
20 (s entre deux pings) |
llama_embed_heartbeat_timeout |
15 (s max par ping) |
- Watchdog (optionnel,
llama_watchdog_enabled, défauttrue) : service systemdllama-watchdogqui sonde une vraie génération sur:1234toutes lesllama_watchdog_intervals. Surllama_watchdog_failureséchecs consécutifs →systemctl restart llama-serveren local (tourne en root, pas de SSH). Répare automatiquement le wedge ROCm où/healthreste vert mais l'inférence est morte (cf.admin/incidents-llm-gpu.md). Logs :journalctl -u llama-watchdog.
Watchdog — variables
| Variable | Défaut |
|---|---|
llama_watchdog_enabled |
true |
llama_watchdog_port |
{{ llama_server_port }} (1234) |
llama_watchdog_model |
{{ llama_model_alias }} (qwen3-8b) |
llama_watchdog_interval |
20 (s entre deux sondes) |
llama_watchdog_timeout |
15 (s max par sonde) |
llama_watchdog_failures |
3 (échecs consécutifs avant restart) |
Complémentaire au
llm-heartbeatdu rôlelitellm: le heartbeat empêche la péremption par inactivité de la connexion LiteLLM↔llama-server ; le watchdog répare le figeage du llama-server lui-même. Le watchdog gère le503 "Loading model"post-restart (rechargement VRAM) sans le compter comme échec.
Variables principales
| Variable | Défaut | Surcharge gpu-01 |
|---|---|---|
llama_server_port |
1234 | — |
llama_model_path |
"" |
/mnt/models/bartowski/Qwen3-8B-GGUF/Qwen3-8B-Q4_K_M.gguf |
llama_model_alias |
"" |
qwen3-8b |
llama_ctx_size |
32768 | 32768 |
llama_n_gpu_layers |
99 | — |
hsa_override_gfx_version |
10.3.0 |
— |
llama_embed_enabled |
false |
true |
llama_embed_port |
1238 | — |
llama_embed_model_path |
"" |
/mnt/models/nomic-ai/nomic-embed-text-v1.5.f16.gguf |
llama_embed_model_url |
"" |
URL HuggingFace du GGUF nomic |
llama_embed_model_alias |
nomic-embed-text |
— |
llama_embed_n_gpu_layers |
0 (CPU — évite la contention GPU avec :1234) |
— |
Instances CPU retirées (2026-06-20)
Trois serveurs llama CPU manuels (hors Ansible) tournaient sur gpu-01 et ont été
supprimés (stop + disable + rm des units + ports firewall fermés) car inutilisés —
ils n'étaient même plus routés par LiteLLM (alias absents de /etc/litellm/config.yaml) :
| Service (supprimé) | Port | Modèle | Ex-usage |
|---|---|---|---|
llama-server-system.service |
1236 | Qwen3-1.7B CPU | profil system |
llama-server-monitor.service |
1237 | Qwen3-1.7B CPU | profil monitor |
llama-server-dev.service |
1235 | Qwen3-4B CPU | profil dev |
Le rôle ne gère désormais que l'instance GPU (
llama-server.service,:1234) et l'embed CPU (llama-embed.service,:1238). Les profils Hermèssystem/monitorn'ont plus de backend dédié — repointer leurs alias LiteLLM surqwen3-8b(GPU) si on veut les réactiver.
Caveats
- Rebuild forcé : supprimer le binaire (
/opt/llama.cpp/build/bin/llama-server) puis relancer le rôle - Le modèle vient du NFS — voir caveat du rôle
nfs_client