feat: anti-502 LLM — heartbeat (litellm) + watchdog auto-réparation (llama_server) (#23)

* feat(litellm): heartbeat anti-502 + request_timeout 20s

Cause racine du 502 « 1ʳᵉ demande après une pause » : la connexion keep-alive
LiteLLM↔llama-server devient inactive → llama-server la ferme → LiteLLM garde le
socket mort → la requête suivante part dans le vide → timeout → 502.

- llm-heartbeat : service systemd qui appelle hermes-default toutes les 15s
  (max_tokens:1, /no_think → ~10ms GPU) → la connexion n'est jamais inactive,
  jamais périmée. Logge les échecs → sert aussi de sonde (vraie génération).
- request_timeout 60→20s : un socket périmé échoue vite, dans la fenêtre où
  num_retries:2 peut rejouer sur une connexion neuve (sinon le client abandonnait
  avant le retry → 502 sec).
- Doc : admin/incidents-llm-gpu.md (fix racine) + README rôle.

⚠️ heartbeat appelle hermes-default en continu → si bascule sur Claude (facturé),
mettre llm_heartbeat_enabled: false. request_timeout global → remonter si Claude.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* feat(llama_server): watchdog auto-réparation du wedge ROCm

Service systemd local sur gpu-01 qui sonde une vraie génération sur :1234
(pas juste /health, qui ment quand le slot d'inférence est figé). Sur N
échecs consécutifs → systemctl restart llama-server en local (root, sans
SSH/sudo distant). Gère le 503 "Loading model" post-restart sans le compter
comme échec.

Complète le llm-heartbeat (rôle litellm) : le heartbeat empêche la péremption
par inactivité de la connexion ; le watchdog répare le figeage du serveur lui-même.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

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

ansible/roles/llama_server/README.md

@@ -12,6 +12,28 @@ Compile llama.cpp (backend HIP/ROCm) et déploie le service **llama-server GPU**
   `llama-embed` servant un modèle d'embedding spécialisé (ex. `nomic-embed-text`) sur
   `:1238`, GPU. Télécharge le GGUF depuis `llama_embed_model_url` si absent. Partage le
   binaire et le GPU avec `:1234` (modèle ~300 Mo VRAM).
+- **Watchdog** (optionnel, `llama_watchdog_enabled`, défaut `true`) : service systemd
+  `llama-watchdog` qui sonde une **vraie génération** sur `:1234` toutes les
+  `llama_watchdog_interval` s. Sur `llama_watchdog_failures` échecs consécutifs →
+  `systemctl restart llama-server` **en local** (tourne en root, pas de SSH). Répare
+  automatiquement le wedge ROCm où `/health` reste 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-heartbeat` du rôle `litellm` : 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 le `503 "Loading model"` post-restart
+> (rechargement VRAM) sans le compter comme échec.
 
 ## Variables principales