ROCm et Vulkan sur gfx1151

L'essentiel

• Le GPU du Framework Desktop est identifié gfx1151 (Strix Halo, RDNA 3.5) dans la matrice ROCm ¹.
• Support officiel : ROCm 7.13.0 preview (15 mai 2026) ², puis ROCm 10.0.0 stable (26 août 2026) ³. Avant : « fonctionne mais non listé ».
• Le support officiel ne couvre qu'Ubuntu (26.04 noyau 7.0, 24.04.4 noyau OEM 6.17) ; hors de ces distributions, AMD exige un noyau 6.18.4 ou plus récent ⁴.
• Pour llama.cpp, les sources 2026 convergent vers Vulkan/RADV pour la génération et HIP pour les prompts longs ; une source conteste cette généralisation. Rien n'est tranché (Q-008).
• AMD a abandonné AMDVLK le 15 septembre 2025 au profit de RADV ¹² ; ne pas l'installer.

Chronologie du support gfx1151

Noyau et distributions

Distributions et statut ROCm :

Le choix est instruit dans Q-007 et sur la vue d'ensemble Linux.

Vulkan/RADV ou ROCm/HIP pour llama.cpp

Deux backends GPU sont utilisables par llama.cpp sur Strix Halo : HIP (ROCm, cible gfx1151) et Vulkan via le pilote Mesa RADV. Les mesures publiées :

Ce que cela implique pour la Box

• Le RAG envoie au modèle des prompts de plusieurs milliers de tokens (contexte documentaire) : la phase de prompt processing pèse sur le TTFT. ROCm pourrait y être avantageux.
• La génération pèse sur la fluidité perçue : Vulkan y est plus rapide selon la majorité des sources.
• La stabilité est le premier critère pour un serveur : Vulkan/RADV est décrit comme « le plus stable » ; ROCm exige des flags spécifiques (ci-dessous).
• Décision provisoire du dossier (ADR-004) : llama.cpp comme runtime ; le backend reste ouvert (Q-008) jusqu'à mesure.

Flags et réglages cités par les sources

Ces flags proviennent des sources ; ils n'ont pas été vérifiés par nous Communauté.

Installation de ROCm : grandes lignes

Aucune commande d'installation n'a été relevée textuellement dans les sources consultées ; cette section décrit la démarche, pas une procédure. Les commandes seront ajoutées après lecture de la documentation d'installation ROCm 10.0 et validation sur la machine (Installation).

1. Choisir la voie : Ubuntu 26.04 ou 24.04.4 avec les dépôts AMD (voie officielle, pilote noyau inbox ¹), ou Fedora 43 avec les paquets ROCm de la distribution (voie communautaire ⁸).
2. Vérifier le noyau : 6.18.4 ou plus récent, firmware linux-firmware récent (2026010+).
3. Régler le BIOS et la mémoire GPU : voir Mémoire GPU.
4. Installer ROCm 10.0 (dépôts AMD) ou les paquets distribution ; vérifier avec rocminfo que le GPU apparaît comme gfx1151.
5. Compiler ou récupérer llama.cpp avec le backend HIP (flags ci-dessus) et le backend Vulkan (Mesa RADV, glslc récent) pour pouvoir comparer.
6. Alternative sans installation : les conteneurs kyuz0 ¹⁸ fournissent des builds Vulkan et ROCm prêts à l'emploi.

Autres runtimes : vLLM fonctionne via les nightlies TheRock et HIP_FORCE_DEV_KERNARG=1, mais gfx1151 n'est pas dans la liste upstream et amdsmi ne reconnaît pas la puce ¹¹ ; à considérer comme expérimental. Ollama est déconseillé par plusieurs guides au profit de llama.cpp direct ¹⁷.

Questions ouvertes

• Q-002Quel runtime d'inférence est le plus performant sur AMD Strix Halo ?HauteEn cours
• Q-007Quelle distribution Linux pour la Box ?MoyenneOuverte
• Q-008Vulkan (RADV) ou ROCm (HIP) pour llama.cpp sur Strix Halo ?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
• 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 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

• 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
• 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
• 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