Ryzen AI Max+ 395 (Strix Halo) : 128 Go de mémoire pour LLM locaux

#Pourquoi le Ryzen AI Max+ 395 change la donne pour le LLM local

Faire tourner un gros modèle en local se heurte presque toujours au même mur : la mémoire vidéo. Une RTX 4090 plafonne à 24 Go, une RTX 5090 à 32 Go, et au-delà il faut empiler plusieurs cartes ou se tourner vers un Mac Studio. Le Ryzen AI Max+ 395 attaque ce mur par un autre angle : au lieu d'une VRAM dédiée limitée, il partage un grand pool de mémoire unifiée entre le CPU, le GPU intégré et le NPU. Sur un modèle équipé de 128 Go, on peut réserver plus de 90 Go au GPU pour l'inférence.

Concrètement, cela ouvre une catégorie de machines qui n'existait pas côté PC : des mini-PC et des laptops sous 2 000–2 500 € capables de charger un modèle 70B, voire des mixtures-of-experts bien plus grosses, sans carte graphique dédiée et sans configuration multi-GPU. C'est le premier concurrent x86 crédible au Mac Studio pour l'IA locale à grande capacité mémoire.

#La puce en détail

Le Ryzen AI Max+ 395 est un APU monolithique qui combine trois moteurs de calcul sur un seul die, tous branchés sur le même contrôleur mémoire. Pour le LLM, c'est surtout le GPU et la mémoire qui comptent, mais l'ensemble forme un tout cohérent.

CPU — 16 cœurs Zen 5

16 cœurs / 32 threads Zen 5, utiles pour le prétraitement, l'offload CPU partiel et tout ce qui n'est pas l'inférence GPU elle-même.

GPU — Radeon 8060S (RDNA 3.5)

40 unités de calcul en architecture RDNA 3.5. C'est le plus gros GPU intégré du marché PC, et c'est lui qui porte l'inférence via ROCm ou Vulkan.

NPU — XDNA 2, ~50 TOPS

Un accélérateur dédié à l'IA à basse consommation. Pertinent pour certaines charges optimisées, mais la plupart des runtimes LLM (Ollama, llama.cpp) ciblent aujourd'hui le GPU, pas le NPU.

Mémoire — LPDDR5X jusqu'à 128 Go

Bus 256 bits, LPDDR5X à 8000 MT/s, soit environ 256 Go/s de bande passante partagée. Unifiée entre CPU, GPU et NPU.

#Mémoire unifiée 128 Go, le vrai argument

Sur un GPU classique, VRAM et RAM système sont deux pools séparés : un modèle qui déborde de la VRAM bascule sur la RAM via le PCIe, et l'inférence s'effondre. Sur le Ryzen AI Max+ 395, il n'y a qu'un seul pool physique. Le GPU adresse directement la mémoire unifiée, exactement comme la mémoire unifiée d'un Mac Apple Silicon. Pas de copie entre deux espaces, pas de goulet PCIe.

La quantité effectivement disponible pour le modèle dépend de la répartition entre mémoire « système » et mémoire « GPU ». Selon le firmware et l'OS, on réserve une partie fixe au GPU (paramètre UMA dans le BIOS) et/ou on laisse le pilote allouer dynamiquement le reste (GTT sous Linux). En pratique, sur une machine 128 Go, il est courant de rendre 96 Go et souvent plus accessibles au GPU pour l'inférence.

Un seul pool

128 Go partagés. Ce que le modèle n'utilise pas reste dispo pour le système, et inversement.

Allocation GPU généreuse

90 Go et au-delà mobilisables pour les poids du modèle et le cache de contexte, selon la config BIOS/pilote.

Pas de mur PCIe

Contrairement à un GPU dédié qui déborde sur la RAM, ici tout tient dans le même espace mémoire haute vitesse.

Contexte long confortable

La marge mémoire permet des fenêtres de contexte étendues là où un GPU 24 Go doit sacrifier soit la taille du modèle, soit le contexte.

#Quels modèles passent (70B Q4, MoE)

Avec ~90 Go utilisables, le Ryzen AI Max+ 395 change complètement la liste des modèles envisageables par rapport à un GPU 16–24 Go. Voici les paliers concrets, en gardant les repères VRAM habituels en Q4 : 7B ≈ 5 Go, 14B ≈ 9 Go, 32B ≈ 19 Go, 70B ≈ 40 Go.

70B en Q4_K_M (~40 Go)

Tient largement, avec de la marge pour un gros contexte. C'est le cas d'usage phare : un Llama 70B ou équivalent, impossible sur une seule RTX 4090.

70B en Q8_0 (~75 Go)

Passe aussi, presque sans perte de qualité. Impensable sur un GPU grand public sans multi-GPU.

MoE type Llama 4 Scout / Qwen3-30B-A3B

Les mixtures-of-experts sont le terrain idéal : on charge tous les poids en mémoire (gros), mais seuls quelques milliards de paramètres sont actifs par token, donc la vitesse reste bonne.

Gros MoE (200B+ en Q4)

Des modèles comme Qwen3-235B-A22B en quantification agressive peuvent tenir dans 90 Go. Le débit dépend du nombre de paramètres actifs, pas de la taille totale.

DeepSeek 671B et consorts

Trop gros même en Q4 (bien au-delà de 100 Go pour les poids). Restent hors de portée sans offload disque — préférez un Mac Studio à très grande mémoire ou une station llama.cpp dédiée.

#Perfs réelles : la bande passante décide

C'est le point à comprendre avant tout achat. La génération de tokens d'un modèle dense est limitée par la bande passante mémoire, pas par la puissance de calcul brute. Le débit théorique plafond se calcule grossièrement en divisant la bande passante par la taille du modèle en mémoire.

Le Ryzen AI Max+ 395 offre environ 256 Go/s. Un modèle 70B en Q4 (~40 Go) plafonne donc théoriquement autour de 6 tokens/s, et en pratique on observe plutôt 4 à 5 tokens/s en génération — lisible, mais pas rapide. À l'inverse, un MoE 30B-A3B ne lit qu'une petite partie des poids par token et grimpe facilement à plusieurs dizaines de tokens/s. Le prétraitement du prompt, lui, s'appuie sur les 40 CU du GPU et reste correct.

Modèle dense 70B Q4

≈ 4–5 tok/s en génération. Confortable pour du rédactionnel et de l'analyse, lent pour du chat très interactif.

Modèle dense 32B Q4

Nettement plus fluide (~19 Go lus/token), bon compromis qualité/vitesse au quotidien.

MoE 30B-A3B

Plusieurs dizaines de tok/s : la vitesse dépend des ~3B actifs, pas des 30B totaux.

Comparaison RTX

Une RTX 4090 (~1000 Go/s) écrase le Strix Halo en débit pur, mais plafonne à 24 Go et ne peut tout simplement pas charger un 70B seule.

#Mini-PC vs laptop vs Mac Studio, le comparatif honnête

Le Ryzen AI Max+ 395 se décline en plusieurs formats. Le choix se joue sur la mobilité, le refroidissement soutenu et le prix, la puce restant identique. Face à lui, la référence à battre reste le Mac Studio et ses variantes M-Max/Ultra à grande mémoire unifiée.

Mini-PC (ex. Framework Desktop, GMKtec EVO-X2)

Le meilleur rapport perf soutenue/prix. Refroidissement stable pour de l'inférence longue, compact, silencieux, idéal en serveur domestique 24/7.

Laptop (ex. HP ZBook Ultra G1a, Asus ROG Flow Z13)

La même capacité mémoire en mobilité, mais throttling thermique sur charge longue et autonomie limitée en inférence. Pratique pour travailler partout, moins pour un serveur.

Mac Studio (M-Max / Ultra)

Bande passante mémoire bien supérieure (plusieurs centaines de Go/s, jusqu'à ~800 Go/s sur Ultra) et écosystème MLX très optimisé. Plus rapide sur les modèles denses, mais nettement plus cher à mémoire équivalente.

Mac mini M4 Pro

Moins de mémoire max mais excellent pour les modèles jusqu'à 32B. À considérer si vous n'avez pas besoin des 70B+.

En résumé : le Strix Halo gagne sur le prix à capacité mémoire élevée et sur l'écosystème x86/Linux ; le Mac Studio gagne sur la vitesse de génération et la maturité logicielle. Pour un usage 70B « accessible » sans se ruiner, le Ryzen AI Max+ 395 en mini-PC 128 Go est aujourd'hui l'option x86 la plus pertinente.

#Configuration ROCm et Vulkan sous Linux

Sous Linux, deux voies mènent au GPU intégré : ROCm (la stack de calcul AMD) et Vulkan (portable et souvent plus simple à faire marcher sur ce GPU récent). L'étape clé, commune aux deux, est de rendre assez de mémoire accessible au GPU.

1. 01
   Régler l'allocation mémoire GPU dans le BIOS

   Entrez dans le BIOS/UEFI et cherchez le paramètre UMA Frame Buffer Size (ou « Dedicated GPU Memory »). Réservez-en une part généreuse au GPU. Le reste sera alloué dynamiquement par le pilote amdgpu via la mémoire GTT.
2. 02
   Vérifier la mémoire GTT vue par le pilote

   Sous Linux, la mémoire allouable dynamiquement au GPU passe par le mécanisme GTT du pilote amdgpu. Un noyau récent (6.10+) et un firmware amdgpu à jour maximisent la part utilisable pour l'inférence.
3. 03
   Installer une stack qui cible le GPU

   Le plus simple est d'utiliser une build d'Ollama ou de llama.cpp avec backend Vulkan, qui détecte le Radeon 8060S sans configuration ROCm lourde. Pour ROCm, installez le paquet officiel et vérifiez que le GPU est bien listé.
4. 04
   Forcer la cible GPU si nécessaire

   Le GPU intégré n'étant pas toujours dans la liste officielle des cibles ROCm, il faut parfois indiquer la version d'architecture GFX via une variable d'environnement pour qu'Ollama/llama.cpp l'accepte.
5. 05
   Lancer un modèle et vérifier l'offload

   Démarrez un modèle et confirmez qu'il tourne bien sur le GPU (et non le CPU) avant de conclure quoi que ce soit sur les performances.

# Vérifier que le GPU AMD est détecté par ROCm
rocminfo | grep -i "gfx"

# Voir l'occupation mémoire du GPU en temps réel
rocm-smi

# Lancer un modèle 70B en Q4 avec Ollama
ollama run llama3.3:70b

# Confirmer que le modèle est sur GPU (et pas CPU)
ollama ps

# Le Radeon 8060S (RDNA 3.5) n'est pas toujours reconnu par défaut.
# Indiquez la version GFX pour qu'Ollama accepte le GPU.
export HSA_OVERRIDE_GFX_VERSION=11.0.0
ollama serve

#Configuration sous Windows

Sous Windows, l'expérience est plus « plug and play » côté pilote, mais l'allocation mémoire reste le point sensible. La logique est la même : donner assez de mémoire au GPU, puis utiliser un runtime qui l'exploite.

1. 01
   Installer le dernier pilote AMD Adrenalin

   Utilisez le pilote le plus récent pour le Ryzen AI Max+ 395 : le support LLM du GPU intégré et l'allocation mémoire s'améliorent à chaque version. Les pilotes récents exposent une part importante de la mémoire unifiée comme VRAM.
2. 02
   Régler la mémoire graphique dédiée

   Dans le BIOS (UMA Frame Buffer Size) ou via l'utilitaire AMD, augmentez la mémoire graphique dédiée pour laisser de la place aux gros modèles. Un réglage trop bas fera déborder le modèle sur le CPU.
3. 03
   Installer LM Studio ou Ollama

   LM Studio détecte le GPU AMD et propose un backend adapté ; c'est l'option la plus simple sans ligne de commande. Ollama pour Windows fonctionne aussi et expose son endpoint sur http://localhost:11434.
4. 04
   Charger un GGUF et vérifier l'offload GPU

   Dans LM Studio, chargez un modèle 70B en Q4 et poussez le curseur d'offload GPU au maximum. Surveillez que les couches sont bien sur le GPU et non en CPU.

# Vérifier la version d'Ollama
ollama --version

# Lancer un modèle 70B ; l'endpoint local reste sur :11434
ollama run llama3.3:70b

# Vérifier l'exécution sur GPU
ollama ps

#Dépannage et astuces

Le modèle tourne sur CPU, pas sur GPU

Vérifiez « ollama ps » / « rocm-smi ». Souvent la mémoire GPU allouée est trop faible : augmentez l'UMA Frame Buffer dans le BIOS ou vérifiez la GTT sous Linux.

ROCm ne détecte pas le Radeon 8060S

Le GPU intégré RDNA 3.5 n'est pas toujours dans la liste officielle. Exportez HSA_OVERRIDE_GFX_VERSION, ou basculez sur le backend Vulkan qui le détecte sans surcharge.

Génération anormalement lente sur un 70B dense

C'est attendu : ~4–5 tok/s est le plafond réaliste à 256 Go/s. Pour plus de vitesse, passez sur un MoE ou un modèle plus petit — ce n'est pas un bug.

Impossible d'allouer 90 Go au GPU

Firmware BIOS et pilote/kernel trop anciens brident l'allocation. Mettez à jour le BIOS, le pilote Adrenalin (Windows) ou le noyau/firmware amdgpu (Linux).

Contexte long qui fait planter

Le cache KV s'ajoute aux poids en mémoire. Réduisez num_ctx ou la taille du modèle si vous approchez la limite des ~90 Go.

#Pour aller plus loin

Le Ryzen AI Max+ 395 s'inscrit dans une réflexion plus large sur le matériel et les modèles pour l'IA locale. Ces guides du site prolongent celui-ci :

Choisir son GPU pour l'IA locale

Le guide d'achat qui remet le Strix Halo en perspective face aux RTX et aux Mac, selon votre budget et vos modèles cibles.

Ollama avec GPU AMD (ROCm)

La configuration ROCm détaillée, utile pour tirer le maximum du Radeon 8060S une fois la plateforme en main.

Choisir sa quantification (Q4, Q5, Q8, FP16)

Pour arbitrer entre Q4 rapide et Q8 quasi sans perte quand la mémoire ne manque pas — exactement le cas d'un 128 Go.