L'AMD Strix Halo (gfx1151) a une réputation méritée dans la communauté du LLM local : 96GB de RAM unifiée, une bande passante mémoire correcte, et un support ROCm qui, sans être parfait, tient la route pour de l'inférence texte. Ce que j'ai voulu vérifier cette semaine, c'est si cette réputation tenait aussi pour la génération d'image. Verdict : non, pas du tout.
Le test
Sur ma machine RAG Pro (EVO-X2, Strix Halo gfx1151, 96GB unifiés), j'ai comparé Flux1-schnell (déjà en place et fonctionnel) à trois alternatives plus récentes : Qwen-Image-2512 en GGUF Q8, sa variante distillée, et FLUX.2 Klein 9B en bf16 pur — donc sans aucune quantification, pour isoler la variable "kernel non optimisé" de la variable "pénalité de quantification".
| Modèle | Steps | Temps total | Mémoire (GTT) | Verdict |
|---|---|---|---|---|
| Flux1-schnell (baseline) | 4 | ~23-26s | ~32 Go | référence |
| Qwen-Image-2512 (GGUF Q8) | 30 | 704s | 37,0 Go | 30x plus lent |
| Qwen-Image-Distill (GGUF) | 15 | 226s | ~37,4 Go | 10x plus lent |
| FLUX.2 Klein 9B (bf16) | 20 | 198s (8,3s load + 190s gen) | 34,0 Go | 8,6x plus lent |
Ce que ces chiffres ne disent pas au premier coup d'œil
La mémoire n'a jamais été le facteur limitant. Sur les quatre tests, j'ai toujours eu entre 30 et 58 Go de marge libre — aucun OOM, aucun swap significatif. Si la RAM unifiée était le goulot d'étranglement, FLUX.2 Klein en bf16 pur aurait dû s'en sortir correctement : c'est le test le plus "propre" des quatre, sans quantification GGUF pour brouiller les pistes.
Il ne s'en est pas sorti. Et le détail le plus intéressant n'est pas le temps total, mais sa courbe : la génération démarre à 0,2s/step et termine autour de 9s/step — une dégradation en cours de run, pas un temps constant élevé dès le départ. Ce n'est pas la signature d'un kernel simplement "non optimisé mais stable" ; c'est plutôt celle d'un phénomène cumulatif — contention de bande passante entre iGPU et CPU sur une charge soutenue, ou throttling thermique que Flux1-schnell, avec ses 4 steps expédiés en 23 secondes, n'a jamais le temps de déclencher.
Flux1-schnell s'en sort bien précisément parce qu'il ne sollicite jamais la puce longtemps. Les modèles plus lourds, eux, révèlent une limite qui n'apparaît que sur une charge soutenue — probablement la même raison pour laquelle l'inférence LLM (des séquences de tokens courtes et répétées) se comporte bien sur cette architecture là où la diffusion (des passes forward continues et lourdes) s'effondre.
Conclusion
Sur Strix Halo, Flux1-schnell reste la seule option d'image generation viable — pas par choix, mais parce que c'est le seul modèle testé qui ne reste pas assez longtemps sur la puce pour révéler le problème. Pas d'autres essais prévus sur ce matériel pour l'instant.
Le prochain levier, si le besoin se représente, c'est une carte dédiée avec un support ROCm plus mature — typiquement une Radeon PRO W7800 48GB (RDNA3 desktop, gfx1100) plutôt que l'iGPU. Elle sert pour d'autres tests mais à terme je veux tester comment elle va s'en sortir.
