Génération d'images IA en local sur un mini PC AMD : ComfyUI + Z-Image Turbo

Mon mini PC transforme un prompt texte en image 1024×1024 terminée en environ 27 secondes : aucun compte cloud, aucun coût par image, aucune file d'attente derrière mille prompts d'autres personnes. Et c'est une puce AMD dont la plupart des gens pensent qu'elle en est tout simplement incapable.

Ce qu'on obtient

On parlera de la configuration plus tard. Au quotidien, j'ouvre un onglet de navigateur ou je le lance depuis un terminal. Dans les deux cas :

Mesure	Valeur
Résolution	1024×1024
Steps / CFG	8 steps, CFG 1.0
Temps de génération à chaud	~27 s (plage mesurée : 26,5–30,4 s)
Démarrage à froid (première image après le boot)	~43,5 s le temps de charger ~20 Go de poids

L'usage réel sur ce boîtier, ce n'est pas l'art pour l'art. C'est un script qui génère en masse des variantes d'avatars pour un projet de chatbot : 222 PNG dans le dossier de sortie, et ça continue. Une infrastructure ennuyeuse et fiable, exactement ce qu'on veut d'un truc qu'on a construit pour s'amuser et dont on a fini par dépendre.

Le matériel

C'est un boîtier à 128 Go de mémoire unifiée : un AMD Ryzen AI Max+ 395 (« Strix Halo ») avec un iGPU Radeon 8060S sur le même boîtier que le CPU. Aucun GPU dédié nulle part.

Voici la partie qui compte vraiment. Le firmware prélève 64 Gio sur ces 128 Go et les confie à l'iGPU comme « VRAM » dédiée — le propre journal de démarrage de ComfyUI affiche Total VRAM 65536 MB, total RAM 63920 MB. C'est plus de VRAM qu'aucune carte NVIDIA grand public n'en vend, parce que ce n'est pas de la GDDR chère soudée sur une carte graphique. C'est juste de la mémoire système que le firmware a assignée au GPU, avec encore environ 31 Go de GTT accessible au GPU en réserve si besoin.

Composant	Spécification
CPU	AMD Ryzen AI Max+ 395, 16 cœurs / 32 threads
iGPU	Radeon 8060S, architecture ROCm gfx1151
Mémoire	128 Go LPDDR5X unifiés — 64 Gio prélevés comme VRAM, ~62 Gio restants pour Linux
OS	Bazzite (immuable, basé sur Fedora Silverblue)
GPU dédié	Aucun

Les poids du modèle pour toute cette configuration totalisent environ 20,7 Go. Confortable dans 64 Go ; sans espoir sur une carte grand public typique de 8 à 16 Go, sauf à décharger des couches vers la RAM système et à en payer le prix en vitesse.

Stack logicielle

Les versions qui font tourner tout ça, telles qu'installées actuellement :

Composant	Version
ComfyUI	v0.27.0 (checkout git)
Python	3.12.13, dans un venv construit 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 de gfx1151

Le détail amusant : la version de PyTorch pour ROCm se fait passer pour CUDA. Le journal de démarrage dit littéralement Device: cuda:0 AMD Radeon 8060S : native. Du Python écrit pour une carte NVIDIA tourne tel quel, parce qu'il croit parler à une. ComfyUI désactive aussi automatiquement cuDNN sur ce matériel et retombe sur l'attention PyTorch classique (pas de xformers, pas de flash-attn), et ça marche très bien sans eux.

Dresser ROCm

La galère de configuration tient dans une poignée de variables d'environnement du 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 le GPU est un gfx1151. Sur ROCm 7.2 c'est redondant (le journal dit déjà « native ») mais je le garde comme filet de sécurité, parce que sur d'anciennes versions de ROCm, exactement cette surcharge était obligatoire pour qu'un iGPU comme celui-ci fonctionne tout court.
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:True empêche l'allocateur de fragmenter la VRAM sur de la mémoire unifiée. Sans ça, on peut se retrouver avec des erreurs de mémoire insuffisante alors qu'il en reste techniquement plein de disponible.
• HIP_VISIBLE_DEVICES=0 épingle l'unique GPU. Pas palpitant, mais utile le jour où vous ajoutez du matériel.

Encore une chose : l'adresse d'écoute du serveur est verrouillée en dur sur 127.0.0.1 dans le script de lancement — pas une option de config, une valeur codée en dur. Le commentaire à cet endroit l'appelle « tout le modèle de sécurité », ce qui est exact. Vous voulez le rendre accessible depuis un autre appareil ? C'est votre propre reverse proxy ou VPN — volontairement pas un simple drapeau à basculer.

Comment un prompt devient une image

Les gens imaginent cette partie comme mystérieuse, et elle ne l'est pas. C'est un pipeline court et fixe que ComfyUI assemble à partir de son template officiel :

Réglages de Z-Image Turbo

Z-Image Turbo est la variante distillée et rapide du modèle Z-Image d'Alibaba (d'après ce que je comprends, il vient de leur Tongyi Lab, environ 6 milliards de paramètres, Apache-2.0). « Distillé » a ici un sens concret : 8 steps et CFG 1.0 produisent une image terminée, au lieu des 20 à 30+ steps que réclament les modèles plus anciens. Voici les réglages de mon workflow enregistré, et ce ne sont que les valeurs par défaut du template officiel. Aucune combinaison magique à dénicher.

Réglage	Valeur
Steps	8
CFG	1.0
Sampler	res_multistep
Scheduler	simple
Shift de ModelSamplingAuraFlow	3
Résolution	1024×1024
Type de CLIPLoader	lumina2
Prompt négatif	mis à zéro (ConditioningZeroOut)

Cette dernière ligne mérite une explication : à CFG 1.0, un prompt négatif n'a rien contre quoi pousser, donc le workflow le met à zéro avec un nœud ConditioningZeroOut plutôt que d'encoder un texte qui ne sert à rien. Tapez un prompt négatif si ça vous donne l'impression de mieux contrôler les choses. Ça ne changera rien à l'image.

Les trois fichiers qui font le vrai travail :

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

Performances mesurées

Ce ne sont pas des chiffres tirés d'un article de blog d'annonce ; ils viennent du journal de cette machine. Une série de 20 prompts consécutifs a enregistré des temps entre 26,62 s et 30,41 s, donc « ~27 secondes » est une moyenne ennuyeuse et reproductible, pas un cas idéal trié sur le volet. Ça revient à environ 2,5 à 3 secondes par step d'échantillonnage une fois qu'on intègre l'encodage texte et le décodage VAE.

La première image après un démarrage à froid du service a pris 43,54 secondes, parce que c'est ce run-là qui charge ~20 Go de poids depuis le disque. Tout ce qui suit est à chaud. Si votre première image de la journée traîne un peu, c'est la raison — pas un signe que quelque chose cloche.

Le faire tourner en service

Je ne veux pas materner un processus Python dans un terminal chaque fois que je veux une image, donc ça tourne comme une unité systemd utilisateur, démarrée avec la session de 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 regroupe le port et les arguments de lancement supplémentaires en un seul endroit modifiable. Par-dessus se trouve un petit wrapper, comfyctl, donc l'usage quotidien devient :

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 meurt, Restart=on-failure le relance après 5 secondes, jusqu'à 5 fois par minute avant que systemd n'abandonne (pour qu'une vraie crash-loop ne tourne pas indéfiniment). Une minuterie hebdomadaire récupère les mises à jour avec git pull --ff-only, redémarre le service, et vérifie /system_stats avant de déclarer un succès. L'icône de bureau de ce truc a été générée par le modèle lui-même, ce qui me plaît sans doute plus que ça ne le devrait.

Le faire en headless

L'interface web convient pour les usages ponctuels, mais l'usage quotidien ici est scripté. Un script Python qui n'utilise que la stdlib construit le graphe en JSON, le poste, interroge périodiquement le résultat, et affiche le chemin du PNG terminé :

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, et l'accès distant sécurisé depuis d'autres appareils ont droit à leur propre article complet : ComfyUI en headless : le faire tourner en service, l'utiliser de n'importe où.

Pièges à éviter

• Le « cuda:0 » dans les logs est normal. La version PyTorch de ROCm rapporte le GPU AMD comme un périphérique CUDA. Ce n'est pas une erreur de configuration, et ça n'utilise pas secrètement une carte NVIDIA.
• La première image après un redémarrage est lente. ~43 secondes le temps de charger les poids, puis ça se stabilise autour de ~27. Ne redémarrez pas en pleine session pour ensuite paniquer en pensant que quelque chose est cassé.
• Les prompts négatifs ne servent à rien ici. CFG 1.0 les met à zéro par conception. Si vous déboguez une mauvaise image, le prompt négatif n'est pas là où se trouve le problème.
• On ne peut pas simplement l'ouvrir à son téléphone. L'adresse d'écoute est codée en dur sur 127.0.0.1, volontairement. L'accès distant demande de monter son propre reverse proxy ou VPN, pas de modifier un fichier de config.
• Ça se met à jour tout seul chaque semaine. Pratique, jusqu'à la semaine où ça ne l'est plus. Le pull en fast-forward uniquement empêche les fusions silencieuses, mais un changement en amont qui casse tout peut quand même atterrir pendant que vous ne regardiez pas.
• 64 Go, ça paraît énorme jusqu'à ce qu'on en charge davantage. Ce workflow utilise environ 20,7 Go de poids. Chargez plusieurs gros modèles en même temps, ou faites tourner autre chose de gourmand en GPU à côté, et la marge disparaît vite.