Stabilité et problèmes connus

L'essentiel

• La plateforme est décrite comme « enfin stable » côté ROCm/Linux depuis janvier 2026, à condition d'un noyau 6.18.4 ou plus récent et d'un firmware 2026010+ ².
• Subsistent : des crashs sous forte charge GPU rapportés depuis mars 2026 sans cause établie ¹, un bug amdgpu de type gfx ring timeout ³, et des problèmes USB liés à la veille ^{4 6}.
• Pour un serveur (veille désactivée, pas de périphérique USB-C), les problèmes de veille sont neutralisés ; le risque restant est le crash sous charge GPU, qui doit être testé sur 24 h.
• Aucune source ne rapporte d'erreur mémoire matérielle ; aucune ne mesure les températures. La mémoire n'a pas d'ECC annoncé chez Framework.
• Statut À vérifier : tous les éléments sont des rapports communautaires ou constructeur, non reproduits par nous.

Inventaire des problèmes

Lecture pour un serveur

Les correctifs prérequis (BIOS 3.06, noyau 6.18.4+, firmware 2026010+) résolvent trois problèmes sur les six qui concernent un serveur. Les deux problèmes GPU restants n'ont pas de correctif confirmé : c'est l'objet de Q-012 et de l'expérimentation « Stabilité 24 h sous charge ».

Mesures de précaution retenues (hypothèses)

Ces mesures découlent des sources ; elles sont à confirmer lors de l'installation Hypothèse.

1. BIOS 3.06 ou plus récent avant toute mesure.
2. Noyau 6.18.4 ou plus récent, linux-firmware récent ; ne jamais descendre en dessous après une mise à jour (voir rollback dans la vue d'ensemble Linux).
3. Désactiver la veille (s2idle) et l'hibernation ; machine allumée en permanence, sur onduleur.
4. amdgpu.gpu_recovery=1 dans la ligne de commande du noyau pour récupérer d'un ring timeout sans redémarrage (à tester : le paramètre peut aussi masquer des problèmes).
5. Ne pas installer AMDVLK ; utiliser RADV.
6. Côté llama.cpp : -fa 1, --no-mmap, -dio selon le backend ; GGML_HIP_NO_VMM=ON à la compilation HIP.
7. Superviser dmesg (motifs amdgpu, ring, timeout, reset), la température et le redémarrage automatique du service d'inférence (voir Monitoring).
8. Redémarrage planifié hebdomadaire hors heures ouvrées tant que la stabilité longue durée n'est pas démontrée.

Questions ouvertes

• Q-001Combien d'utilisateurs simultanés la Box peut-elle réellement servir ?HauteOuverte
• Q-011Combien de mémoire GPU peut-on réellement allouer sur 128 Go ?HauteOuverte
• Q-012La plateforme Strix Halo est-elle assez stable pour un serveur 24 h/24 ?HauteOuverte

Ce qu'il reste à tester

• Benchmark gpt-oss-120b à 1 utilisateur : Vulkan vs ROCm, contexte court et longSur le Framework Desktop, gpt-oss-120b MXFP4 atteint au moins 50 t/s en tg128 avec l'un des deux backends, et le prefill pp512 dépasse 500 t/s ; la génération baisse de moins de 20 % à 32k de profondeur.À tester
• Montée en charge de 1 à 10 utilisateurs : gpt-oss-120b et Qwen3-30B-A3BAvec llama-server -np 8 --kv-unified et KV q8_0, gpt-oss-120b sert 3 utilisateurs simultanés à plus de 25 t/s chacun avec un TTFT p95 inférieur à 3 s sur prompts courts ; à 10 utilisateurs, le débit par utilisateur reste au-dessus de 10 t/s. Le comportement suit la courbe publiée pour Qwen3.6-35B-A3B (59 → 20 t/s par utilisateur de 1 à 8 slots) décalée vers le bas.À tester
• Comparer Vulkan/RADV et ROCm/HIP dans llama.cppVulkan/RADV est plus rapide en génération (+15 à +30 %) et ROCm/HIP plus rapide en prompt processing au-delà de quelques milliers de tokens ; pour les prompts RAG de la Box (4k à 16k tokens), la différence de temps de réponse total est inférieure à 20 % et la stabilité départage les deux.À tester
• Évaluer vLLM sur ROCm gfx1151En septembre 2026, l'image officielle vllm/vllm-openai-rocm démarre sur gfx1151 avec ROCm 7.x sans patch, sert un MoE de taille moyenne, et donne un TTFT p95 inférieur à celui de llama-server à 5 clients ; mais elle ne sert pas gpt-oss-120b en MXFP4 sans conversion, et réserve plus de mémoire que llama-server pour un même contexte.À tester
• Mesurer la consommation et le bruit en inférenceAu repos le système consomme 10 à 15 W ; en inférence gpt-oss-120b mono-utilisateur 100 à 130 W ; sous 4 slots 120 à 150 W. Le bruit reste sous 42 dBA à 1 m en charge avec le ventilateur Noctua, ce qui autorise une installation dans un bureau.À tester
• Mesurer la mémoire GPU allouable sur le Framework DesktopAvec BIOS 3.06, UMA à 512 Mo, noyau 6.18.4+ et ttm.pages_limit fixé via amd-ttm, le GPU peut allouer au moins 100 Go de façon stable ; gpt-oss-120b MXFP4 se charge avec 32k tokens de contexte pour 4 slots.À tester
• Stabilité sous charge continue pendant 24 heuresAvec 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.À tester