Funk-lab/admin/incidents-llm-gpu.md

Incidents LLM / GPU — llama-server (gpu-01)

Journal dédié des incidents d'inférence : llama-server (ROCm / RX 6700XT sur gpu-01) et chaîne LLM STT-server / Hermes → LiteLLM → llama-server. Voir aussi incidents.md (matériel & services storage-01/k8s) et admin/ia/llama_server.md.

---

2026-06-19 — llama-server gelé : /health OK mais inférence bloquée → 502 sur tout le LLM

Symptômes

• STT (HUD, composer texte) : 502 Server Error: Bad Gateway for url: http://stt.lab.local/v1/ask
• Petite activité GPU visible sur gpu-01 (le slot d'inférence tourne en rond)
• STT-server : GET /healthz → 200, mais POST /v1/ask → 502
• llama-server :1234 : /health → {"status":"ok"} et /v1/models → qwen3-8b listé → l'apparence est « up », ce qui masque la panne
• Mais une génération réelle ne renvoie jamais rien : curl /v1/chat/completions hang (45 s sans un seul token)
• LiteLLM (storage-01) : litellm.Timeout: APITimeoutError - Request timed out. timeout value=600.0, time taken=600.0s. Received Model Group=hermes-default (après 2 retries)

Cause

Le llama-server (gpu-01, :1234, qwen3-8b) était dans un état wedgé après ~2 jours d'uptime (démarré le 2026-06-17 21:04). Les endpoints de contrôle (/health, /v1/models) répondaient encore, mais le slot d'inférence ROCm était bloqué (vraisemblablement une requête avortée laissée dans le slot). Chaîne du 502 :

HUD composer → STT-server (/v1/ask) → LiteLLM :4000 (hermes-default) → llama-server gpu-01 :1234  ← GELÉ

LiteLLM attend request_timeout = 600 s, échoue, et le STT-server renvoie 502.

Diagnostic (commandes utiles)

# 1) STT-server : confirmer que le 502 vient de lui (et pas de Traefik)
kubectl -n ai logs <pod stt-server> --tail=50    # → "POST /v1/ask HTTP/1.1" 502

# 2) LiteLLM : voir le timeout
ssh storage-01 'journalctl -u litellm -n 40 --no-pager --output=cat'
# → litellm.Timeout ... timeout value=600.0 ... Model Group=hermes-default

# 3) llama-server : /health MENT — tester une VRAIE génération
ssh gpu-01 'curl -s -m 30 http://127.0.0.1:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"qwen3-8b\",\"messages\":[{\"role\":\"user\",\"content\":\"Dis bonjour. /no_think\"}],\"max_tokens\":30}"'
# gelé (aucune sortie) = wedgé   |   réponse JSON = sain

Résolution

Redémarrer le service d'inférence sur gpu-01 :

ssh gpu-01 'sudo systemctl restart llama-server'

• L'ancienne instance gelée met ~40 s à mourir (état deactivating le temps que le slot bloqué se libère) — systemctl restart peut dépasser un timeout SSH court, c'est normal ; vérifier avec systemctl is-active llama-server jusqu'à active.
• Au redémarrage, /v1/chat/completions renvoie 503 {"error":"Loading model"} pendant ~30 s (rechargement du modèle en VRAM) — normal, attendre.
• Validation : génération directe ("Bonjour." en ~80 ms) puis bout-en-bout POST http://stt.lab.local/v1/ask → {"reply":"Bonjour.","model":"hermes-default"}.

Observations / suites (hors présent incident)

• ⚠️ Piège du health-check : /health et /v1/models restent verts quand le serveur est wedgé → un check qui ne fait pas une vraie génération ne voit pas la panne (même angle mort que le crash-loop Qdrant en activating, cf. incidents.md).
• Latence cerveau : post-restart, 30-45 s pour une réponse triviale via STT-server alors que le llama-server direct est à ~80 ms → le surcoût vient du pipeline du cerveau (mémoire/embeddings Qdrant stt-memory + LiteLLM). À investiguer séparément.
• Bruit LiteLLM : Invalid model name model=qwen3-1.7b-monitor (profil monitor Hermes) dans les logs — pré-existant, non lié à cet incident.

Prévention (pistes)

• Probe applicative : sonde qui fait une vraie génération /v1/chat/completions (pas seulement /health) → alerte si le LLM ne produit plus de tokens.
• Watchdog : si LiteLLM accumule des Timeout sur hermes-default, redémarrer automatiquement llama-server sur gpu-01.
• Réduire le request_timeout LiteLLM (600 s est très long → un 502 tardif et opaque).