Génération d’images par IA en local sur AMD (ROCm) : ComfyUI + Z-Image Turbo

Mise à jour du 16/09/2026 : Je n’utilise plus cette configuration ComfyUI sur ma propre machine ; désormais, la génération d’images se fait via un serveur GPU distant. Les instructions ci-dessous restent inchangées et fonctionnent toujours si vous souhaitez les utiliser sur votre propre machine AMD.

Ma machine AMD transforme une description textuelle en une image finale de 1024×1024 en environ 27 secondes : pas de compte cloud requis, pas de frais par image, et aucune file d’attente avec les demandes d’autres utilisateurs. Or, il s’agit d’un processeur AMD que la plupart des gens pensent incapable d’effectuer ce genre de tâche.

Résultat final

On peut remettre à plus tard les explications de configuration. Au quotidien, j’ouvre un onglet dans le navigateur ou je lance le processus depuis le terminal. Dans tous les cas :

Métrique	Valeur
Résolution	1024×1024
Étapes / CFG	8 étapes, CFG 1,0
Temps de génération (en chauffage)	~27 s (plage mesurée : 26,5–30,4 s)
Démarrage à froid (première image après redémarrage)	~43,5 s, pendant le chargement d’environ 20 Go de poids

L’utilisation réelle sur cette machine n’est pas la création artistique pour elle-même. Il s’agit d’un script qui génère en lot diverses variantes d’avatars pour une application de chat auto-hébergée : 222 fichiers PNG se trouvent déjà dans le dossier de sortie, et le nombre ne cesse d’augmenter. Une infrastructure fiable et sans chichi – exactement ce qu’on attend d’un outil que l’on a conçu par plaisir puis dont on est venu dépendre.

Le matériel

Il s’agit d’une machine dotée de 128 Go de mémoire unifiée : un AMD Ryzen AI Max+ 395 (« Strix Halo ») équipé d’un iGPU Radeon 8060S intégré au même package que le processeur. C’est l’ASUS ROG Flow Z13 mentionné dans mon article sur mon home-lab, avant qu’une panne de courant ne le mette hors service. Il n’y a aucune carte graphique dédiée.

Voici l’élément crucial : le firmware réserve 64 Go sur ces 128 Go pour en faire de la « VRAM » dédiée à l’iGPU. Les logs de démarrage de ComfyUI indiquent d’ailleurs Total VRAM 65536 MB, total RAM 63920 MB. Il s’agit là de plus de VRAM que ce que propose n’importe quelle carte graphique grand public de NVIDIA ; il ne s’agit pas en effet de coûteuse mémoire GDDR soudée sur une carte graphique. Ce sont simplement des mémoires système attribuées au GPU par le firmware, avec environ 31 Go supplémentaires de mémoire GTT accessible au GPU si nécessaire.

Composant	Spécifications
Processeur	AMD Ryzen AI Max+ 395, 16 cœurs / 32 threads
iGPU	Radeon 8060S, architecture ROCm gfx1151
Mémoire	128 Go de mémoire unifiée LPDDR5X — 64 Go attribués à la VRAM, environ 62 Go restants pour Linux
Système d’exploitation	Bazzite (système immuable, basé sur Fedora Silverblue)
Carte graphique dédiée	Aucune

Les poids des modèles utilisés dans cette configuration occupent au total environ 20,7 Go. Ce volume tient facilement dans les 64 Go de VRAM disponibles ; en revanche, sur une carte graphique grand public typique dotée de 8 à 16 Go de VRAM, cela serait impossible sans transférer certaines couches vers la mémoire système, au prix d’une baisse notable des performances.

Stack logiciel

Les versions nécessaires au bon fonctionnement, telles qu’installées actuellement :

Composant	Version
ComfyUI	v0.27.0 (git checkout)
Python	3.12.13, dans un environnement virtuel créé avec uv
PyTorch	2.12.1+rocm7.2
torchvision	0.27.1+rocm7.2
torchaudio	2.11.0+rocm7.2
pytorch-triton-rocm	3.5.1
ROCm	7.2, prise en charge native du gfx1151

Détail intéressant : la version de PyTorch compilée pour ROCm se fait passer pour CUDA. Les logs de démarrage indiquent littéralement Device: cuda:0 AMD Radeon 8060S : native. Le code Python conçu pour une carte NVIDIA fonctionne sans problème, car il croit communiquer avec une telle carte. De même, ComfyUI désactive automatiquement cuDNN sur ce matériel et fait appel à l’implémentation d’attention standard de PyTorch (sans xformers ni flash-attn) ; cela fonctionne parfaitement malgré tout.

Faire en sorte que ROCm fonctionne correctement

Les difficultés de configuration proviennent de quelques variables d’environnement dans le script de lancement :

HSA_OVERRIDE_GFX_VERSION=11.5.1
PYTORCH_HIP_ALLOC_CONF=expandable_segments:True
HIP_VISIBLE_DEVICES=0

• HSA_OVERRIDE_GFX_VERSION indique à ROCm que la GPU est du type gfx1151. Dans ROCm 7.2, cette variable est redondante (les logs indiquent déjà “native”), mais je la garde par précaution ; dans les anciennes versions de ROCm, cet ajustement était indispensable pour que ce genre d’iGPU puisse fonctionner.
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:True empêche l’allocateur de fragmenter la VRAM dans le cadre de la mémoire unifiée. Sans cette option, on risque de rencontrer des erreurs de saturation mémoire même lorsqu’il reste encore de la mémoire disponible.
• HIP_VISIBLE_DEVICES=0 limite l’utilisation à une seule GPU. Ce n’est pas très spectaculaire, mais utile si vous ajoutez du matériel ultérieurement.

Une dernière chose : l’adresse d’écoute du serveur est fixée de manière stricte à 127.0.0.1 dans le script de lancement — il ne s’agit pas d’un paramètre configurable, mais d’une valeur codée en dur. Le commentaire associé la qualifie de “modèle de sécurité global”, ce qui est tout à fait exact. Souhaitez-vous que le serveur soit accessible depuis un autre appareil ? Dans ce cas, il vous faudra utiliser un reverse proxy ou un VPN ; il n’existe aucun commutateur permettant d’activer cette fonctionnalité.

Comment un prompt se transforme en image

Cette étape est souvent perçue comme mystérieuse, mais ce n’est pas le cas. Il s’agit d’un pipeline court et fixe que ComfyUI configure à partir de son modèle officiel :

Paramètres de Z-Image Turbo

Z-Image Turbo est la version optimisée et rapide du modèle Z-Image d’Alibaba (d’après ce que je comprends, il provient de leur Tongyi Lab ; il compte environ 6 milliards de paramètres et est distribué sous licence Apache-2.0). Le terme « optimisé » a ici un sens concret : 8 étapes de génération et un paramètre CFG à 1,0 suffisent pour obtenir une image finale, contre les 20 à 30+ étapes requises par les modèles plus anciens. Voici les paramètres de mon workflow sauvegardé ; ce sont simplement les valeurs par défaut officielles. Il n’y a pas de combinaison magique à trouver.

Paramètre	Valeur
Étapes	8
CFG	1,0
Échantillonneur	res_multistep
Planificateur	simple
Décalage ModelSamplingAuraFlow	3
Résolution	1024×1024
Type CLIPLoader	lumina2
Prompt négatif	mis à zéro (ConditioningZeroOut)

Cette dernière ligne mérite explication : avec un CFG à 1,0, il n’y a rien contre quoi le prompt négatif puisse agir ; c’est pourquoi le workflow le met à zéro via un nœud ConditioningZeroOut, au lieu d’encoder un texte qui ne servirait à rien. Vous pouvez tout de même saisir un prompt négatif si cela vous rassure ; cela ne modifiera en rien l’image générée.

Les trois fichiers qui effectuent le travail réel :

Fichier	Taille	Rôle
z_image_turbo_bf16.safetensors	12,3 Go	transformateur de diffusion (bf16)
qwen_3_4b.safetensors	8,0 Go	encodeur de texte
ae.safetensors	0,34 Go	VAE

Performance mesurée

Il ne s’agit pas de chiffres tirés d’un article de blog de lancement ; ce sont les données enregistrées sur cette machine. Lors d’une série de 20 requêtes consécutives, les temps de traitement se sont situés entre 26,62 s et 30,41 s. Ainsi, « environ 27 secondes » représente une moyenne stable et reproductible, et non un cas idéal sélectionné au hasard. Cela équivaut à environ 2,5–3 secondes par étape d’échantillonnage, une fois pris en compte le codage du texte et le décodage VAE.

La première image générée après un démarrage à froid du service a nécessité 43,54 secondes, car c’est à ce moment-là que près de 20 Go de poids sont chargés depuis le disque. Par la suite, tout se fait en mode « chaud ». Si votre première image de la journée met plus de temps à se générer, c’est pour cette raison, et non parce qu’il y aurait un problème.

Exécution en tant que service

Je ne veux pas avoir à surveiller manuellement un processus Python dans un terminal chaque fois que j’ai besoin d’une image ; c’est pourquoi le tout s’exécute en tant qu’unité utilisateur systemd, lancée au moment de la connexion :

ExecStart=%h/comfy/start-comfyui.sh
WorkingDirectory=%h/comfy/ComfyUI
EnvironmentFile=-%h/comfy/comfy.env
Restart=on-failure
RestartSec=5
TimeoutStartSec=120

Le fichier d’environnement permet de définir le port ainsi que les arguments supplémentaires de démarrage en un seul endroit modifiable. Par-dessus cela se trouve un petit utilitaire, comfyctl, de sorte que l’utilisation quotidienne se fait simplement ainsi :

comfyctl start      # starts the service, waits for it to answer, opens the workflow
comfyctl status     # server health + unit state + newest output file
comfyctl generate "a foggy harbor at dawn, cinematic"
comfyctl stop
comfyctl logs

Si le processus se termine de manière inattendue, Restart=on-failure le relance après 5 secondes, jusqu’à 5 fois par minute ; ensuite systemd abandonne (évitant ainsi un boucle de plantages infinie). Un minuteur hebdomadaire effectue des mises à jour via git pull --ff-only, redémarre le service, puis vérifie le contenu de /system_stats avant de considérer l’opération comme réussie. L’icône du bureau correspondante a été générée par l’IA elle-même ; je l’aime plus que je ne devrais probablement.

Utilisation en mode headless

L’interface web convient pour des utilisations ponctuelles, mais dans notre cas, l’utilisation quotidienne se fait via des scripts. Un script Python utilisant uniquement les modules standard de la bibliothèque crée le graphe sous forme de JSON, l’envoie au serveur, attend le résultat, puis affiche le chemin vers le fichier PNG généré :

python3 ~/comfy/comfy-generate.py "a foggy harbor at dawn, cinematic" \
  --steps 8 --width 1024 --height 1024 --out ~/Pictures/harbor.png

L’API HTTP, le script de contrôle ainsi que l’accès à distance sécurisé depuis d’autres appareils feront l’objet d’un article détaillé chacun : ComfyUI en mode headless : exécutez-le en tant que service et utilisez-le depuis n’importe où.

Pièges à éviter

• Le message “cuda:0” dans les journaux est normal. PyTorch avec ROCm identifie la carte graphique AMD comme un périphérique CUDA. Ce n’est pas une mauvaise configuration, et le système n’utilise absolument pas de carte NVIDIA en secret.
• La première image générée après un redémarrage met plus de temps à apparaître. Il faut environ 43 secondes pour charger les poids du modèle ; ensuite, le temps de génération se stabilise autour de 27 secondes. Ne paniquez pas si vous redémarrez en pleine session : tout est normal.
• Les prompts négatifs ne servent à rien ici. Avec un paramètre CFG fixé à 1,0, les prompts négatifs sont ignorés par conception. Si vous rencontrez un problème avec une image générée, le prompt négatif n’en est pas la cause.
• Vous ne pouvez pas simplement accéder au service depuis votre téléphone. L’adresse d’écoute est volontairement limitée à 127.0.0.1. Pour autoriser un accès à distance, il faut mettre en place son propre proxy inverse ou un VPN ; modifier un fichier de configuration ne suffit pas.
• Le logiciel se met à jour automatiquement chaque semaine. C’est pratique… jusqu’à ce que ce ne le soit plus. Le mécanisme de mise à jour empêche les mises à jour silencieuses, mais un changement majeur dans la version principale peut quand même survenir sans préavis.
• 64 Go semblent beaucoup, jusqu’à ce que vous chargiez plusieurs modèles. Ce workflow nécessite environ 20,7 Go de mémoire pour les poids du modèle. Chargez-en plusieurs en même temps, ou exécutez une autre application gourmande en ressources GPU, et la marge de manœuvre disparaîtra rapidement.

Voir aussi : ComfyUI sans interface graphique : exécution en tant que service, utilisation depuis n’importe où · ASUS ROG Flow Z13 : mon laboratoire domestique portable qui a refusé de le rester · DisPatch : une application de chat auto-hébergée pour les agents IA locaux · StudioForge : un serveur LLM utilisant uniquement le GPU, qui a remplacé LM Studio