Lokale KI-Bildgenerierung auf einem AMD-Mini-PC: ComfyUI + Z-Image Turbo

Mein Mini-PC verwandelt einen Text-Prompt in etwa 27 Sekunden in ein fertiges 1024×1024-Bild: kein Cloud-Konto, keine Gebühr pro Bild, keine Warteschlange hinter tausend fremden Prompts. Und das mit einem AMD-Chip, dem die meisten Leute das gar nicht zutrauen würden.

Was am Ende dabei rauskommt

Das Setup-Gerede kann warten. Im Alltag öffne ich einen Browser-Tab oder starte es vom Terminal aus. So oder so:

Metrik	Wert
Auflösung	1024×1024
Steps / CFG	8 Steps, CFG 1.0
Warme Generierungszeit	~27s (gemessene Spanne: 26,5–30,4s)
Kaltstart (erstes Bild nach dem Booten)	~43,5s, während ~20 GB Gewichte laden

Der eigentliche Anwendungsfall auf dieser Kiste ist nicht Kunst um der Kunst willen. Es ist ein Skript, das im Stapel Avatar-Varianten für ein Chatbot-Projekt erzeugt: 222 PNGs im Output-Ordner, Tendenz steigend. Langweilige, zuverlässige Infrastruktur — genau das, was man von etwas will, das man aus Spaß gebaut hat und dann anfing, davon abhängig zu sein.

Die Hardware

Das ist eine Kiste mit 128 GB Unified Memory: ein AMD Ryzen AI Max+ 395 ("Strix Halo") mit einer Radeon-8060S-iGPU auf demselben Package wie die CPU. Nirgends eine dedizierte GPU.

Hier kommt der Teil, der zählt. Die Firmware zweigt 64 GiB dieser 128 GB ab und gibt sie der iGPU als dedizierten "VRAM" — ComfyUIs eigenes Start-Log liest sich Total VRAM 65536 MB, total RAM 63920 MB. Das ist mehr VRAM, als irgendeine Consumer-NVIDIA-Karte verkauft, weil es kein teurer, auf eine Grafikkarte gelöteter GDDR ist. Es ist einfach Systemspeicher, den die Firmware der GPU zugewiesen hat, mit weiteren ~31 GB GPU-zugänglichem GTT dahinter, falls nötig.

Komponente	Spezifikation
CPU	AMD Ryzen AI Max+ 395, 16 Kerne / 32 Threads
iGPU	Radeon 8060S, ROCm-Architektur gfx1151
Speicher	128 GB Unified LPDDR5X — 64 GiB als VRAM abgezweigt, ~62 GiB für Linux übrig
Betriebssystem	Bazzite (unveränderlich, basiert auf Fedora Silverblue)
Dedizierte GPU	Keine

Die Modellgewichte für dieses ganze Setup summieren sich auf etwa 20,7 GB. Bequem innerhalb von 64 GB; aussichtslos auf einer typischen 8–16-GB-Consumer-Karte, es sei denn, man lagert Layer in den Systemspeicher aus und nimmt den Geschwindigkeitsverlust in Kauf.

Software-Stack

Die Versionen, die das gerade zum Laufen bringen, so wie aktuell installiert:

Komponente	Version
ComfyUI	v0.27.0 (git checkout)
Python	3.12.13, in einem mit uv gebauten venv
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, native gfx1151-Unterstützung

Das lustige Detail: Der PyTorch-Build von ROCm tarnt sich als CUDA. Das Start-Log sagt buchstäblich Device: cuda:0 AMD Radeon 8060S : native. Python-Code, der für eine NVIDIA-Karte geschrieben wurde, läuft einfach, weil er glaubt, mit einer zu reden. ComfyUI deaktiviert auf dieser Hardware auch automatisch cuDNN und fällt auf reine PyTorch-Attention zurück (kein xformers, kein flash-attn), und es funktioniert auch ohne sie einwandfrei.

ROCm zur Räson bringen

Der Setup-Schmerz steckt in einer Handvoll Umgebungsvariablen im Start-Skript:

HSA_OVERRIDE_GFX_VERSION=11.5.1
PYTORCH_HIP_ALLOC_CONF=expandable_segments:True
HIP_VISIBLE_DEVICES=0

• HSA_OVERRIDE_GFX_VERSION sagt ROCm, dass die GPU gfx1151 ist. Auf ROCm 7.2 ist das redundant (das Log sagt schon "native"), aber ich behalte es als Absicherung, weil dieser exakte Override auf älteren ROCm-Builds zwingend nötig war, damit iGPUs wie diese überhaupt liefen.
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:True hindert den Allocator daran, den VRAM auf Unified Memory zu fragmentieren. Ohne das kann es zu Out-of-Memory-Fehlern kommen, obwohl technisch noch reichlich Speicher frei ist.
• HIP_VISIBLE_DEVICES=0 pinnt auf die eine GPU. Nicht spannend, aber nützlich, falls jemals Hardware dazukommt.

Noch eine Sache: Die Listen-Adresse des Servers ist im Start-Skript fest auf 127.0.0.1 gepinnt — kein Konfig-Schalter, sondern ein hartcodierter Wert. Der Kommentar dort nennt das "das ganze Sicherheitsmodell", was zutrifft. Willst du von einem anderen Gerät zugreifen? Das ist dein eigener Reverse-Proxy oder VPN, absichtlich kein Flag zum Umlegen.

Wie aus einem Prompt ein Bild wird

Die Leute stellen sich diesen Teil als mysteriös vor, ist er aber nicht. Es ist eine kurze, feste Pipeline, die ComfyUI aus seiner offiziellen Vorlage zusammensteckt:

Z-Image-Turbo-Einstellungen

Z-Image Turbo ist die destillierte, schnelle Variante von Alibabas Z-Image-Modell (nach meinem Verständnis stammt es aus deren Tongyi Lab, etwa 6 Milliarden Parameter, Apache-2.0). "Destilliert" bedeutet hier etwas Konkretes: 8 Steps und CFG 1.0 liefern ein fertiges Bild, statt der 20–30+ Steps, die ältere Modelle wollen. Das sind die Einstellungen aus meinem gespeicherten Workflow, und sie sind einfach die Standardwerte der offiziellen Vorlage. Keine magische Kombination zu suchen.

Einstellung	Wert
Steps	8
CFG	1.0
Sampler	res_multistep
Scheduler	simple
ModelSamplingAuraFlow shift	3
Auflösung	1024×1024
CLIPLoader-Typ	lumina2
Negativer Prompt	auf null gesetzt (ConditioningZeroOut)

Diese letzte Zeile ist eine Erklärung wert: Bei CFG 1.0 hat ein negativer Prompt nichts, wogegen er drücken könnte, also setzt der Workflow ihn mit einem ConditioningZeroOut-Node auf null, statt Text zu enkodieren, der ohnehin nichts bewirkt. Tipp ruhig einen negativen Prompt ein, wenn dich das kontrollierter fühlen lässt. Am Bild ändert es nichts.

Die drei Dateien, die die eigentliche Arbeit machen:

Datei	Größe	Rolle
z_image_turbo_bf16.safetensors	12,3 GB	Diffusion-Transformer (bf16)
qwen_3_4b.safetensors	8,0 GB	Text-Encoder
ae.safetensors	0,34 GB	VAE

Gemessene Leistung

Das sind keine Zahlen aus einem Release-Blogpost, sondern aus dem Journal dieser Maschine. Ein Lauf von 20 aufeinanderfolgenden Prompts protokollierte Zeiten zwischen 26,62s und 30,41s, "~27 Sekunden" ist also ein langweiliger, wiederholbarer Durchschnitt, kein Best-Case-Rosinenpicken. Das läuft auf etwa 2,5–3 Sekunden pro Sampling-Step hinaus, wenn man Text-Encoding und VAE-Decode einrechnet.

Das erste Bild nach einem kalten Dienst-Start brauchte 43,54 Sekunden, weil in diesem Lauf ~20 GB Gewichte von der Festplatte laden. Alles danach ist warm. Wenn sich dein erstes Bild des Tages träge anfühlt, liegt das daran — kein Zeichen dafür, dass etwas kaputt ist.

Als Dienst betreiben

Ich will nicht jedes Mal, wenn ich ein Bild will, einen Python-Prozess in einem Terminal babysitten, also läuft das als systemd-User-Unit, gestartet mit der Login-Session:

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

Die Env-Datei hält Port und zusätzliche Start-Argumente an einem editierbaren Ort. Oben drauf sitzt ein kleiner Wrapper, comfyctl, sodass der Alltagsgebrauch so aussieht:

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

Stirbt der Prozess, bringt Restart=on-failure ihn nach 5 Sekunden zurück, bis zu 5-mal pro Minute, bevor systemd aufgibt (damit eine echte Absturzschleife nicht ewig weiterdreht). Ein wöchentlicher Timer zieht Updates mit git pull --ff-only, startet den Dienst neu und prüft /system_stats, bevor er sich als erfolgreich meldet. Das Desktop-Icon für dieses Ding hat das Modell selbst generiert, was mir mehr gefällt, als es wahrscheinlich sollte.

Es headless machen

Die Web-UI ist für Einzelstücke in Ordnung, aber der tägliche Gebrauch hier ist geskriptet. Ein reines Stdlib-Python-Skript baut den Graph als JSON, sendet ihn per POST, pollt auf das Ergebnis und gibt den Pfad zum fertigen PNG aus:

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

Die HTTP-API, das Kontrollskript und der abgesicherte Fernzugriff von anderen Geräten bekommen einen eigenen, vollständigen Artikel: Headless ComfyUI: Als Dienst betreiben, von überall nutzen.

Stolperfallen

• "cuda:0" in den Logs ist normal. ROCms PyTorch meldet die AMD-GPU als CUDA-Gerät. Das ist keine Fehlkonfiguration und auch keine heimliche Nutzung einer NVIDIA-Karte.
• Das erste Bild nach einem Neustart ist langsam. ~43 Sekunden, während Gewichte laden, dann pendelt es sich bei ~27 ein. Nicht mitten in der Session neu starten und dann in Panik geraten, weil angeblich was kaputt ist.
• Negative Prompts bewirken hier nichts. CFG 1.0 setzt sie absichtlich auf null. Wenn du ein schlechtes Bild debuggst, liegt das Problem nicht beim negativen Prompt.
• Man kann das nicht einfach fürs Handy öffnen. Die Listen-Adresse ist absichtlich auf 127.0.0.1 hartcodiert. Fernzugriff bedeutet, einen eigenen Reverse-Proxy oder VPN aufzusetzen, nicht eine Konfigdatei zu editieren.
• Es aktualisiert sich wöchentlich selbst. Praktisch, bis zu der Woche, in der es das nicht ist. Der Fast-Forward-only-Pull verhindert stille Merges, aber eine breaking Änderung stromaufwärts kann trotzdem landen, während man nicht hinschaut.
• 64 GB klingen nach viel, bis man mehr lädt. Dieser Workflow nutzt etwa 20,7 GB an Gewichten. Mehrere große Modelle gleichzeitig laden oder nebenbei etwas anderes GPU-Hungriges laufen lassen, und der Spielraum verschwindet schnell.