Mémoire GPU allouable sous Linux

L'essentiel

• Sur Strix Halo, CPU et GPU partagent physiquement les 128 Go (mémoire unifiée). Le GPU y accède par deux mécanismes : une petite réservation « VRAM » fixée dans le BIOS (UMA) et le GTT, pool de mémoire système mappé à la demande ¹.
• Par défaut, le GTT est limité à ≈ 50 % de la RAM, soit ≈ 64 Go : insuffisant pour gpt-oss-120b (≈ 61 Go) plus son KV cache.
• AMD recommande de garder la réservation BIOS petite (0,5 Go) et d'augmenter la limite TTM/GTT via ttm.pages_limit ou l'outil amd-ttm ¹.
• Plafonds observés : ≈ 108 Go (août 2025, segfaults à 110 Go) ² et 120 Go (guides 2026) ³. Le chiffre « 96 Go » souvent cité est une limite Windows ⁶.
• Rien n'a été mesuré par nous ; la valeur réelle pour la Box est la question Q-011.

Pourquoi c'est central

Le dimensionnement de la Box repose sur la mémoire que le GPU peut réellement utiliser :

À 64 Go de GTT, le modèle principal ne tient pas. À 96 Go, il tient avec peu de marge pour le KV cache multi-utilisateurs. À 108–120 Go, tout tient. La différence entre 96 et 120 Go décide du modèle principal (Q-009) et du nombre d'utilisateurs simultanés (Q-001).

Ce que dit AMD (documentation officielle)

Le guide « Strix Halo system optimization » de ROCm 10.0 ¹ :

• deux notions : GART (mappage noyau) et GTT (pool pour les processus utilisateur) ; « by default, the GTT limit is set to approximately 50 percent of total system RAM » ;
• réserver de la VRAM dédiée dans le BIOS n'apporte aucun gain puisque la mémoire est physiquement partagée ; recommandation : « keeping the dedicated VRAM reservation in BIOS small (for example 0.5 GB) and increasing the shared (TTM/GTT) limit instead » ;
• le paramètre est /sys/module/ttm/parameters/pages_limit, exprimé en pages de 4 Kio, pas en Go ;
• outil : pipx install amd-debug-tools puis amd-ttm --set 100 (exemple donné pour 100 Go, soit 26 214 400 pages sur un système à « 125.65 GB » de mémoire totale) ;
• prérequis : noyau 6.18.4 ou plus récent (patches fusionnés upstream) ; Fedora 43, Ubuntu 26.04 et Arch listés stables.

Ce que dit la communauté

Tableau des paramètres

Conversion : Go × 262 144 = pages de 4 Kio (100 Go = 26 214 400 ; 120 Go = 31 457 280).

Le contournement « 24 Go » et son incompatibilité

Le fil « Framework Desktop Crashes » ⁸ cite, comme contournement des hard locks, la limitation de la mémoire iGPU à 24 Go dans le BIOS. Ce contournement est incompatible avec l'usage LLM de la Box ; s'il s'avérait nécessaire pour la stabilité, la machine serait disqualifiée. Ce lien entre allocation mémoire et stabilité est la raison de tester les deux ensemble (Q-011 et Q-012).

Procédure « à tester »

Canevas de l'expérimentation « Mesurer la mémoire GPU allouable » ; chaque étape est à valider sur la machine.

1. Mettre le BIOS à jour en 3.06 ou plus récent ⁵ ; régler l'UMA Frame Buffer au minimum (512 Mo si disponible).
2. Installer la distribution retenue avec un noyau 6.18.4 ou plus récent ; relever uname -r, la version de linux-firmware et le contenu de /sys/module/ (présence de ttm, amdttm, amdgpu).
3. Relever la valeur par défaut de /sys/module/ttm/parameters/pages_limit et la mémoire GPU vue par rocminfo ou vulkaninfo.
4. Fixer la limite à 100 Go avec amd-ttm --set 100 (voie AMD) ; redémarrer si nécessaire ; vérifier la nouvelle valeur.
5. Charger avec llama.cpp (Vulkan puis ROCm) un modèle de taille croissante, ou gpt-oss-120b avec un contexte croissant, jusqu'à l'échec : noter la dernière allocation stable et le type d'échec (OOM propre, segfault, hard lock).
6. Répéter à 110 puis 120 Go.
7. Consigner : BIOS, noyau, firmware, paramètre, allocation maximale stable, comportement à l'échec. Le résultat alimente Q-011 et la fiche Framework (gpuMemoryMaxGb).

Questions ouvertes

• 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