Stabilité sous charge continue pendant 24 heures
Faire tourner llama-server 24 h avec 4 slots actifs et journaliser dmesg, températures et consommation, pour vérifier que les crashs GPU rapportés depuis mars 2026 ne se reproduisent pas avec BIOS 3.06 et noyau 6.18.4+.
- Statut du test
- À tester
- Priorité
- Haute
- Prévu pour
- Novembre 2026
- Hypothèse
- Avec BIOS 3.06, noyau 6.18.4+, firmware 2026010+, veille désactivée, amdgpu.gpu_recovery=1 et 100 Go de GTT, llama-server (backend retenu) sert 4 utilisateurs simulés en continu pendant 24 h sans reset GPU, sans erreur amdgpu dans dmesg et sans redémarrage du service.
- Procédure
- 1) Machine dans l'état issu de l'expérimentation mémoire GPU. 2) llama-server avec gpt-oss-120b MXFP4, 4 slots, contexte 32k. 3) Générateur de charge : 4 clients envoyant en boucle des prompts RAG de 4k à 12k tokens avec réponses de 300 à 800 tokens, pauses aléatoires de 5 à 60 s. 4) Journaliser toutes les 30 s : dmesg (motifs amdgpu, ring, timeout, reset, MES), température (sysfs), consommation à la prise (wattmètre), t/s, TTFT, mémoire GTT utilisée. 5) 24 h ; si succès, prolonger à 7 jours en tâche de fond. 6) En cas d'incident : conserver dmesg complet, journal du service, état des paramètres.
- Prochaine action
- Préparer le générateur de charge et le script de journalisation ; acheter un wattmètre à enregistrement.
Pourquoi
Des crashs sous forte charge GPU sont rapportés sur Framework Desktop depuis mars 2026 sans cause établie ni correctif officiel confirmé 1 ; un gfx ring timeout persiste sur des noyaux récents 2 ; la communauté juge ROCm stable depuis le noyau 6.18.4 3. Le plus long test publié est 1,5 jour à 140 W sous Windows 4. Une Box en production tourne 24 h/24 : ce test est la condition de passage de « candidat » à « retenu » (ADR-002).
Ce qui est observé
| Signal | Source de mesure | Seuil d'alerte |
|---|---|---|
Messages amdgpu anormaux (ring, timeout, reset, MES, page fault) | dmesg | tout message = incident |
| Redémarrage du service llama-server | systemd | tout redémarrage = incident |
| Température GPU / CPU | sysfs hwmon | à définir après lecture des maximums constructeur (non trouvés) |
| Consommation à la prise | wattmètre enregistreur | information |
| Débit t/s et TTFT | journal du générateur | dérive supérieure à 20 % = à analyser |
| Mémoire GTT utilisée | sysfs / rocm-smi | approche de la limite = à analyser |
Les options llama.cpp de stabilité citées par la communauté (-fa 1, --no-mmap, -dio) sont appliquées 5.
Critère de succès
24 h sans incident, puis 7 jours. Un reset GPU récupéré par gpu_recovery compte comme incident mineur (à documenter) ; un hard lock ou une corruption de sortie compte comme échec.
Résultat
À venir.
Sources
- 1Framework Desktop Crashes (forum)ForumFiabilité moyenneFramework Community · publié 2026-03 et suite · consulté le 16 sept. 2026 · fiche source
- 2Strix Halo / gfx1151: gfx ring timeout under mundane GL load (forum)ForumFiabilité moyenneFramework Community · publié 2026-05-01 · consulté le 16 sept. 2026 · fiche source
- 3Linux + ROCm: January 2026 Stable Configurations Update (forum, kyuz0)ForumFiabilité moyenneFramework Community · kyuz0 · publié 2026-01-18 · consulté le 16 sept. 2026 · fiche source
- 4Framework Desktop Review: A Solid AMD Strix Halo (ServeTheHome, p. 5)BenchmarkFiabilité hauteServeTheHome · Patrick Kennedy · publié 2025-11-26 · consulté le 16 sept. 2026 · fiche source
- 5amd-strix-halo-toolboxes (README)GitHubFiabilité moyenneGitHub (communauté) · kyuz0 · publié 2025–2026 · consulté le 16 sept. 2026 · fiche source