Passer au contenu principal
Matériel non recommandé. Tokios ne recommande pas AMD Strix Halo (Ryzen AI Max+ 395) comme plateforme d’inférence principale. Ce matériel a été exploré par la communauté ; le support des pilotes reste irrégulier, la stabilité ROCm dépend des versions exactes du noyau et du firmware, et Vulkan constitue le seul backend fiable. Pour un déploiement en production ou une utilisation quotidienne, nous préconisons plutôt un Mac Studio, un DGX Spark ou une station de travail RTX. Cette page s’adresse aux utilisateurs déjà en possession de matériel Strix Halo souhaitant en tirer le meilleur parti.
AMD Ryzen AI Max+ 395 (« Strix Halo ») intègre jusqu’à 128 Go de mémoire unifiée partagée entre le processeur et la puce graphique Radeon 8060S. Cette capacité suffit à charger des modèles qui exigeraient autrement une carte graphique dédiée d’une valeur supérieure à $2,000. Toutefois, la bande passante mémoire de 215 Go/s ainsi que la nature MoE ou dense du modèle déterminent si vous obtiendrez 2 tokens/s ou 30 tokens/s. Cette page précise quels modèles sont compatibles et quelles performances attendre.

​
Verdict rapide : les modèles MoE l’emportent

Sur Strix Halo, les modèles MoE (mixture-of-experts) sont 3 à 14 fois plus rapides que les modèles denses possédant le même nombre total de paramètres. La raison en est la bande passante : seuls les paramètres actifs d’un modèle MoE sont lus depuis la mémoire pour chaque token généré. Ainsi, un modèle MoE de 122B paramètres doté de 10B paramètres actifs produit des tokens à une vitesse proche de celle d’un modèle dense de 10B paramètres, et non de celui de 122B paramètres. Lorsque vous sélectionnez un modèle pour un usage quotidien, privilégiez un modèle MoE dont l’ID de modèle amont se situe entre 35B et 122B.

​
128GB unified memory explained

Le Strix Halo ne dispose pas de mémoire vidéo dédiée. Le iGPU puise dans le même pool DDR5 que le processeur. Dès la sortie d’usine, le BIOS et le système d’exploitation réservent une partie de ces 128 Go :

​
Configuration de la mémoire via le BIOS sous Linux

Sous Linux, le noyau gère automatiquement cette répartition. Après le démarrage, on constate généralement que 95 à 110 Go sont accessibles pour les tâches GPU. Dans la plupart des cas, aucune modification manuelle du BIOS n’est nécessaire.

​
Configuration de la mémoire sous Windows

Sous Windows, il faut configurer 2 éléments :
  1. BIOS → UMA Frame Buffer — sélectionnez l’option la plus élevée proposée (souvent « Auto » ou une valeur fixe).
  2. AMD Adrenalin → VRAM allocation — ouvrez AMD Software: Adrenalin Edition, accédez à Settings → Graphics → Advanced puis déplacez le curseur de la VRAM jusqu’à 96 Go.
Sans cette allocation de VRAM via Adrenalin sous Windows, votre iGPU ne détectera que 15.5 Go, un volume insuffisant pour charger des modèles volumineux. Configurez d’abord le BIOS ainsi que le curseur d’Adrenalin avant d’essayer de charger des modèles nécessitant plus de 30B paramètres.

​
Compatibilité avec les modèles denses

Les modèles denses activent chacun des paramètres pour chaque jeton, ce qui exige de lire l’intégralité du tenseur de poids depuis la mémoire à chaque étape. À 215 Go/s, cela fixe une limite stricte à la vitesse de traitement des jetons.
Le modèle Qwen3-Coder-30B en configuration Q4_K_M est le modèle dense privilégié par la communauté pour les agents de programmation (Cline, Aider, opencode) sur Strix Halo. Il s’intègre sans difficulté et atteint une vitesse de génération de 10 à 15 jetons par seconde.

​
Compatibilité avec les modèles MoE

Les modèles MoE maintiennent un nombre total de paramètres élevé, mais n’activent qu’une fraction de ceux-ci par jeton. Cela réduit considérablement la bande passante mémoire requise à chaque étape, permettant ainsi une génération bien plus rapide. Les modèles MoE dotés de 3 à 12B paramètres actifs représentent le meilleur compromis. Ils offrent une qualité de pointe tout en maintenant des vitesses de réponse rapides lors de conversations ou de sessions de codage.
GLM-4.6 (357B au total / 32B actifs) ne s’adapte pas à Strix Halo. Avec une quantification à Q4_K_M, il requiert environ 178 Go, soit bien plus que le pool de mémoire unifié de 128 Go, même en recourant au regroupement de nœuds RDMA à 2 unités (256 Go). Pour Strix Halo, privilégiez plutôt GLM-4.5-Air. Consultez la page famille GLM pour comparer toutes les variantes.

​
Kimi K3 sur Strix Halo

Kimi K3 ne convient pas à Strix Halo. Ses 2.8 Tores de paramètres au total (soit environ 50B actifs par jeton grâce à Stable LatentMoE) exigent près de 1.4 téraoctets en précision MXFP4 native. Le pool de mémoire total de Strix Halo, soit environ 128 Go — voire 90 à 110 Go après déduction des ressources système — se révèle 1.27 téraoctets en dessous du minimum requis. Moonshot recommande d’exécuter K3 sur un supernœud doté de 64 accélérateurs ou davantage. Pour le calcul complet de la mémoire nécessaire, consultez le document analyse approfondie du matériel pour Kimi K3. Pour Strix Halo, les modèles compatibles figurent dans les tableaux ci-dessus ; ils peuvent atteindre environ 122B MoE en précision Q4 sur un seul nœud. Consultez ce qu’il convient d’exécuter à la place de Kimi K3 afin de choisir le modèle idéal pour une consommation mémoire de 128 Go.

​
Qwen3.8 sur Strix Halo

The Qwen3.8 flagship shipped in August 2026 as Qwen3.8-2.4T-A95B: a Mixture-of-Experts model with 2.4 trillion total parameters and 95B active per token, text-only, released under Qwen’s custom qwen3.8-max license. The generation also includes Qwen3.8-27B (released 2026-08-14, Apache-2.0), a dense vision-language model that does fit Strix Halo — see below.

​
Mémoire dédiée aux poids selon chaque niveau de quantification

Même avec la quantification la plus poussée, Strix Halo ne peut pas exécuter Qwen3.8-2.4T-A95B. Il s’agit d’un modèle destiné à un cluster multi-nœuds nécessitant au minimum 5 unités DGX Spark (ou équivalent) à Q2 ; en pratique, il faut compter sur 10 nœuds ou plus à Q4 pour disposer d’une marge suffisante pour le cache KV. Pour connaître les exigences complètes du cluster, consultez la page du modèle Qwen3.8.
Les modèles MoE chargent tous les poids des experts en mémoire, même si seule une partie s’active par jeton. Qwen3.8-2.4T-A95B active 95B de ses 2.4T experts, mais la quantité de 1.2 téraoctets à Q4 constitue une limite absolue. L’avantage des modèles MoE réside dans le calcul (moins d’opérations FLOP par jeton) et non dans l’utilisation de la mémoire.

​
Le modèle Qwen3.8 adapté à Strix Halo

Qwen3.8-27B is the single-machine member of the generation: a dense 27B vision-language model released 2026-08-14 under Apache-2.0. The official 30.9 GB FP8 build fits a 96 GB GPU allocation with room to spare, and even the 55.6 GB BF16 release fits — though a Q4_K_M GGUF (~17 GB, not yet published) will be the practical llama.cpp/Vulkan path on this hardware. Full sizing is on the Qwen3.8 model page; tested configurations will be added here once verified.

​
Comparaison entre les backends ROCm et Vulkan

L’iGPU Radeon 8060S de Strix Halo (gfx1151) permet d’exécuter l’inférence via plusieurs backends 2, chacun présentant ses propres avantages et limites. Privilégiez Vulkan sauf si vous avez une raison précise d’utiliser ROCm (par exemple, la précision BF16 pour l’évaluation d’un réglage fin).
Consultez vLLM et alternatives sur Strix Halo pour connaître les options d’exécution, y compris llama.cpp Vulkan et Ollama.

​
Contraintes liées à la bande passante

La mémoire DDR5 de Strix Halo offre une bande passante théorique de 215 Go/s. Ce chiffre est le plus déterminant pour évaluer les performances :
  • Token generation is memory-bandwidth-bound. Each token requires reading the model’s active weights from memory.
  • Un modèle dense de taille 70B en format Q4 (~40 Go) nécessite 40 Go ÷ 215 Go/s ≈ 186m secondes par jeton, soit environ 5 jetons par seconde.
  • Un modèle MoE de taille 122B avec 10B composantes actives en format Q4 (~7 Go de poids actifs) requiert 7 Go ÷ 215 Go/s ≈ 33m secondes par jeton, soit environ 30 jetons par seconde.
Le traitement des invites (préremplissage) repose sur les capacités de calcul et s’effectue plus rapidement que la génération de jetons. Les invites longues se traitent en un temps record, puis la génération se stabilise à un rythme limité par la bande passante.

​
Attentes de performance selon les cas d’usage

​
Cluster expérimental de 2 nœuds utilisant le protocole RDMA

2 Strix Halo nodes can provide 256 GB of aggregate unified memory through llama.cpp RPC, but this is a proof-of-concept path, not a production configuration.
L’outil llama.cpp qualifie le protocole RPC de fragile, peu sécurisé et réservé à la phase de preuve de concept. Il convient de ne jamais exposer un serveur RPC à un réseau non fiable, ni de s’y fier pour un déploiement en production. La configuration réseau, la compatibilité des modèles, la capacité de traitement et les performances doivent être validées localement.
Cette approche ne doit être envisagée que pour des expérimentations contrôlées lorsqu’un seul nœud ne suffit pas à héberger le modèle. L’article Matériel local pour DeepSeek V4 Flash explique pourquoi son format GGUF sans perte peut être intégré à un pool de mémoire global, tout en restant un déploiement expérimental sur Strix Halo.

​
Vérifiez votre utilisation de la mémoire

Avant de charger un modèle, déterminez la quantité de mémoire GPU disponible :
Déduisez-y la surcharge du système d’exploitation (~4 Go) et réservez 2 à 4 Go pour le cache KV selon la longueur de contexte souhaitée. Un modèle de 70 Go en format Q4 laisse environ 20 Go pour le cache KV sur une allocation totale de 96 Go, ce qui suffit généralement pour un contexte de 8K à 16K sur la plupart des modèles.

​
Prochaines étapes

Cas d’utilisation de Strix Halo

Configurez le connecteur Tokios sur votre boîtier Strix Halo afin d’en permettre l’accès à distance.

vLLM et autres solutions compatibles sur Strix Halo

Options d’exécution telles que llama.cpp Vulkan et Ollama.

Guide de quantification

Découvrez les niveaux de quantification GGUF ainsi que les compromis en matière de qualité.