Lokale KI-Bildgenerierung auf AMD (ROCm): ComfyUI + Z-Image Turbo

Update vom 16.09.2026: Ich nutze diese ComfyUI-Konfiguration mittlerweile nicht mehr auf meinem eigenen Rechner – meine tägliche Bildgenerierung erfolgt nun auf einem entfernten GPU-System. Die untenstehenden Anweisungen sind unverändert und funktionieren nach wie vor, falls Sie dies auf Ihrem eigenen AMD-Rechner ausführen möchten.

Mein AMD-Rechner wandelt einen Text-Prompt in ein fertiges 1024×1024-Bild in etwa 27 Sekunden um – ohne Cloud-Konto, ohne Gebühren pro Bild sowie ohne Warteschlange, in der tausende andere Leute warten müssten. Dabei handelt es sich um einen AMD-Chip, von dem die meisten Leute annehmen, dass er so etwas überhaupt nicht leisten kann.

Was am Ende dabei herauskommt

Die Einrichtung kann warten. Im Alltag öffne ich entweder ein Browserfenster oder starte das Programm über das Terminal. In jedem Fall gilt:

Metrik	Wert
Auflösung	1024×1024
Schritte / CFG	8 Schritte, CFG 1,0
Generierungszeit nach Warmstart	ca. 27 Sekunden (Messbereich: 26,5–30,4 Sekunden)
Kaltstart (erstes Bild nach Neustart)	ca. 43,5 Sekunden – dabei werden ca. 20 GB an Gewichten geladen

Der eigentliche Anwendungsfall auf diesem System ist nicht die Erstellung von Kunst um der Kunst willen. Es handelt sich vielmehr um ein Skript, das in Batch-Verfahren Avatare für eine selbstgehostete Chat-Anwendung generiert: Im Ausgabeverzeichnis befinden sich bereits 222 PNG-Dateien – und die Zahl steigt weiter. Eine langweilige, aber zuverlässige Infrastruktur – genau das, was man von etwas erwartet, das man aus Spaß gebaut hat und auf das man später angewiesen ist.

Die Hardware

Es handelt sich um ein System mit 128 GB gemeinsam genutztem Speicher: ein AMD Ryzen AI Max+ 395 („Strix Halo“), bei dem die Radeon 8060S iGPU im selben Package wie die CPU untergebracht ist. Es ist das ASUS ROG Flow Z13 aus meinem Home-Lab-Beitrag; nach einem Stromausfall wurde das Gerät jedoch außer Betrieb gesetzt. Es gibt keinerlei dedizierte Grafikkarte.

Nun zum Wichtigen: Das Firmware teilt davon 64 GB als dedizierten „VRAM“ für die iGPU zu – der Startlog von ComfyUI zeigt folgendes an: Total VRAM 65536 MB, total RAM 63920 MB. Das ist mehr VRAM, als jede Consumer-NVIDIA-Grafikkarte bietet; schließlich handelt es sich dabei nicht um teuren GDDR-Speicher, der auf einer Grafikkarte verlötet ist. Es handelt sich lediglich um Systemspeicher, den das Firmware der GPU zuweist – zusätzlich stehen noch ca. 31 GB an GPU-zugänglichem Speicher zur Verfügung, falls nötig.

Komponente	Spezifikationen
CPU	AMD Ryzen AI Max+ 395, 16 Kerne / 32 Threads
iGPU	Radeon 8060S, ROCm-Architektur gfx1151
Speicher	128 GB gemeinsam genutzter LPDDR5X-Speicher – davon 64 GB als VRAM, ca. 62 GB bleiben für Linux übrig
Betriebssystem	Bazzite (immutabel, basierend auf Fedora Silverblue)
Dedizierte Grafikkarte	Keine

Die Modellgewichte für diese gesamte Konfiguration belaufen sich auf etwa 20,7 GB. Das passt problemlos in die 64-GB-VRAM-Kapazität; bei herkömmlichen Consumer-Grafikkarten mit nur 8–16 GB VRAM wäre das jedoch unmöglich – es sei denn, man lädt Teile der Modelle in den Systemspeicher um und akzeptiert dabei Geschwindigkeitseinbußen.

Software-Stack

Die Versionen, die für das Funktionieren erforderlich sind – so wie sie momentan installiert sind:

Komponente	Version
ComfyUI	v0.27.0 (git checkout)
Python	3.12.13, in einem mit uv erstellten 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; unterstützt nativ gfx1151

Ein interessantes Detail: Die von ROCm bereitgestellte PyTorch-Version gibt sich als CUDA aus. Im Startprotokoll steht wörtlich: Device: cuda:0 AMD Radeon 8060S : native. Python-Code, der für NVIDIA-Grafikkarten geschrieben wurde, läuft einfach weiter – weil er glaubt, mit einer solchen zu kommunizieren. ComfyUI deaktiviert auf dieser Hardware automatisch cuDNN und greift stattdessen auf die Standard-Implementierung von PyTorch zurück (ohne xformers bzw. flash-attn); auch das funktioniert einwandfrei.

ROCm zum Funktionieren bringen

Die Probleme bei der Einrichtung liegen in ein paar Umgebungsvariablen im Startskript:

HSA_OVERRIDE_GFX_VERSION=11.5.1
PYTORCH_HIP_ALLOC_CONF=expandable_segments:True
HIP_VISIBLE_DEVICES=0

• HSA_OVERRIDE_GFX_VERSION weist ROCm darauf hin, dass es sich um eine GPU vom Typ gfx1151 handelt. In ROCm 7.2 ist diese Variable überflüssig – das Log gibt bereits „native“ an – doch ich behalte sie aus Sicheitsgründen bei. Bei älteren ROCm-Versionen war diese Angabe nämlich zwingend erforderlich, damit solche iGPUs überhaupt laufen konnten.
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:True verhindert, dass der Speicherallokator den VRAM bei der gemeinsamen Speichernutzung fragmentiert. Ohne diese Einstellung kann es zu „Out-of-Memory“-Fehlern kommen – obwohl technisch gesehen noch genug Speicher verfügbar ist.
• HIP_VISIBLE_DEVICES=0 begrenzt die Nutzung auf eine einzige GPU. Nicht besonders spannend, aber nützlich, falls man später weitere Hardware hinzufügt.

Noch etwas: Die Adresse, an der der Server lauscht, ist im Startskript fest auf 127.0.0.1 gesetzt – es handelt sich dabei nicht um einen konfigurierbaren Wert, sondern um einen hardcodierten Wert. Der dazugehörige Kommentar bezeichnet dies als „das gesamte Sicherheitsmodell“ – was zutrifft. Möchten Sie den Server von einem anderen Gerät aus erreichen? Dafür benötigen Sie ein Reverse-Proxy oder ein VPN; es gibt bewusst keinen Schalter, den man umschalten könnte.

Wie aus einem Prompt ein Bild entsteht

Diesen Prozess stellen sich viele als geheimnisvoll vor – doch das ist er nicht. Es handelt sich um eine kurze, festgelegte Pipeline, die ComfyUI anhand seiner offiziellen Vorlage zusammenstellt:

Einstellungen für Z-Image Turbo

Z-Image Turbo ist die optimierte, schnellere Variante des Z-Image-Modells von Alibaba – soweit ich weiß stammt es aus deren Tongyi Lab. Es verfügt über etwa 6 Milliarden Parameter und unterliegt der Apache-2.0-Lizenz. „Optimiert“ bedeutet hier konkret: Mit nur 8 Schritten sowie einem CFG-Wert von 1,0 entsteht ein fertiges Bild – im Gegensatz zu den 20–30+ Schritten, die ältere Modelle benötigen. Dies sind die Einstellungen aus meinem gespeicherten Workflow; sie entsprechen einfach den offiziellen Standardeinstellungen. Es gibt keine „magische“ Kombination, nach der man suchen müsste.

Einstellung	Wert
Schritte	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)

Die letzte Zeile ist es wert, erklärt zu werden: Bei einem CFG-Wert von 1,0 gibt es eigentlich nichts, gegen das ein negativer Prompt wirken könnte. Deswegen setzt der Workflow diesen Prompt mittels des ConditioningZeroOut-Nodes auf Null – anstatt unnötigen Text zu verarbeiten. Sie können trotzdem einen negativen Prompt eingeben, falls Ihnen das ein besseres Kontrollgefühl vermittelt; er ändert das Bild jedoch nicht.

Die drei Dateien, die die eigentliche Arbeit leisten:

Datei	Größe	Funktion
z_image_turbo_bf16.safetensors	12,3 GB	Diffusions-Transformer (bf16)
qwen_3_4b.safetensors	8,0 GB	Textencoder
ae.safetensors	0,34 GB	VAE

Gemessene Leistung

Dies sind keine Zahlen aus einem Release-Blogpost – sie stammen aus dem Protokoll dieses Rechners. Bei 20 aufeinanderfolgenden Ausführungen wurden Zeiten zwischen 26,62 Sekunden und 30,41 Sekunden gemessen; „ca. 27 Sekunden“ ist also ein langweiliger, wiederholbarer Durchschnittswert – kein ausgewählter Bestwert. Rechnet man die Textkodierung sowie die VAE-Dekodierung mit ein, ergibt das etwa 2,5 bis 3 Sekunden pro Samplingschritt.

Das erste Bild nach einem Neustart des Dienstes benötigte 43,54 Sekunden – schließlich werden in diesem Durchlauf ca. 20 GB an Gewichten von der Festplatte geladen. Danach läuft alles „warm“. Wenn also Ihr erstes Bild des Tages etwas langsam entsteht, liegt das daran – es ist kein Zeichen dafür, dass etwas nicht stimmt.

Ausführen als Dienst

Ich möchte mich nicht jedes Mal um einen Python-Prozess im Terminal kümmern müssen, wenn ich ein Bild benötige – deswegen läuft das Ganze als systemd-User-Unit, die beim Login gestartet wird:

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

Die Umgebungsdatei enthält die Port-Nummer sowie weitere Startparameter an einem einzigen, bearbeitbaren Ort. Darüber hinaus gibt es noch einen kleinen Wrapper namens comfyctl; der alltägliche Gebrauch gestaltet sich somit wie folgt:

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

Fällt der Prozess aus, sorgt Restart=on-failure dafür, dass er nach 5 Sekunden neu gestartet wird – maximal 5 Mal pro Minute, bevor systemd aufgibt (damit es keine endlose Absturzkette gibt). Ein wöchentlicher Timer führt ein git pull --ff-only durch, startet anschließend den Dienst neu und prüft noch /system_stats, bevor er den Vorgang als erfolgreich markiert. Das Desktop-Icon für dieses Programm wurde übrigens vom Modell selbst generiert – was mir gefällt, auch wenn das wohl nicht sein sollte.

Im Headless-Modus arbeiten

Die Web-Benutzeroberfläche ist zwar für einmalige Anwendungen geeignet, doch im Alltag wird hier ein Skript verwendet. Ein Python-Skript, das ausschließlich die Standardbibliotheken nutzt, erstellt den Graphen in JSON-Format, sendet ihn ab, wartet auf das Ergebnis und gibt anschließend den Pfad zur fertigen PNG-Datei aus.

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

Das HTTP-API, das Steuerungsskript sowie der sichere Fernzugriff von anderen Geräten werden in einem eigenen Artikel ausführlich beschrieben: Headless ComfyUI: Als Dienst ausführen, von überall nutzen.

Fallstricke

• „cuda:0“ in den Logs ist normal. PyTorch unter ROCm meldet die AMD-GPU als CUDA-Gerät. Das ist keine Fehlkonfiguration – es wird auch keine NVIDIA-Karte heimlich verwendet.
• Das erste Bild nach einem Neustart entsteht langsam. Es dauert ca. 43 Sekunden, bis die Gewichte geladen sind; danach reduziert sich die Zeit auf etwa 27 Sekunden. Starten Sie das Programm also nicht erneut mitten in einer Sitzung – sonst geraten Sie vielleicht in Panik, weil etwas „kaputt“ zu sein scheint.
• Negative Prompts haben hier keine Wirkung. Bei einem CFG-Wert von 1,0 werden sie von vornherein ignoriert. Falls Sie ein schlechtes Bild analysieren, liegt das Problem also nicht im negativen Prompt.
• Sie können diese Anwendung nicht einfach vom Handy aus nutzen. Die Netzwerkadresse ist absichtlich auf 127.0.0.1 festgelegt. Für den Remote-Zugriff müssen Sie entweder einen Reverse Proxy oder ein VPN einrichten – eine Konfigurationsdatei zu ändern reicht nicht aus.
• Die Software aktualisiert sich wöchentlich. Das ist praktisch – bis zur Woche, in der es nicht mehr klappt. Zwar verhindert das „Fast-Forward-Only“-Verfahren stille Updates, doch ein fehlerhaftes Update von der Entwicklerseite kann trotzdem auftreten.
• 64 GB klingen viel – bis man mehr Modelle lädt. Für diesen Workflow werden etwa 20,7 GB an Gewichten benötigt. Laden Sie mehrere große Modelle gleichzeitig oder führen Sie andere GPU-intensive Aufgaben aus, bleibt kaum noch Speicherplatz übrig.

Verwandte Artikel: Headless ComfyUI: Als Dienst ausführen und von überall nutzen · ASUS ROG Flow Z13: Mein tragbares Heimlabor, das einfach nicht tragbar bleiben wollte · DisPatch: Eine selbstgehostete Chat-Anwendung für lokale KI-Agenten · StudioForge: Ein GPU-exklusiver LLM-Server, der LM Studio abgelöst hat