Leserartikel Stable Diffusion lokal auf AMD Grafikkarten

Hallo Liebe CBler,

in den letzten Tagen habe ich mich aus Neugier mal in das Rabbit Hole einer lokalen Stable Diffusion Installation zur KI gestützten Bildergeneration begeben. Ich wollte mal ein bisschen herumprobieren und insbesondere Beleuchten wie gut (oder schlecht) das ganze lokal auf meiner AMD RX6800 läuft. Ich wage mal das ganze etwas strukturierter zu gestalten und will dies hier in Form eines kleinen Leserartikels präsentieren. Angesiedelt habe ich das ganze im "Multimedia" Unterforum, da hier auch der entsprechende Sammelthread verortet ist.

Umfang und Kenntnisse:​

Dieser Leserartikel basiert auf meiner Erfahrung von einigen Abenden Recherche und Rumprobierens ohne weitere Vorkenntnisse in der praktischen Anwendung von KI zur Bilderstellung. Es handelt sich also weder um eine erschöpfende Abhandlung, noch um „Einrichtungstipps von einem Profi“. Vielmehr ist es die out-of-the-box Erfahrung einiger Möglichkeiten um Stable Diffusion lokal auf einer AMD GPU zu nutzen.

Die Hardware:​

CPU	Ryzen 7 5800X3D (Curve Optimizer -30)
RAM	Crucial 32GB DDR4 3600MHz CL16
GPU	XFX RX 6800 16GB (NAVI 21 XL, Sienna Cichlid), Powertarget 200W
Storage	Crucial P2 1TB NVMe PCIe 3.0 x4 (für Modelle und Python System)

Die Software:​

Für den Softwareunterbau habe ich einige Optionen ausgesucht und ausprobiert. Diese stellen keinen Anspruch auf Vollständigkeit oder optimale Performance. Allerdings sind es in meinen Augen recht populäre Varianten auf die ein Einsteiger auch stoßen würde:

Automatic1111
Genutzt wurde der DirectML fork von Ishqqytiger, zu finden auf GitHub in der Version 1.6.0 auf meiner Windows 10 Installation.

ComfyUI (Windows 10)
Genutzt wurde die GUI (GitHub) per git clone eines Snapshots von dieser Woche mit dem DirectML paket von Pytorch (torch-directml).

SHARK Studio
Genutzt wurde das portable Stable Release (GitHub) in der Version 20231009.984.

ComfyUI (Ubuntu, ROCm)
Genutzt wurde wie unter Windows der aktuelle GitHub snapshot mit der zusätzlichen ROCm PyTorch Nightly Implementierung für die ROCm Suite von AMD in der Version 5.7.

Der Prompt:​

Für den Prompt der Performance Vergleiche habe ich mich an dem Benchmark-Artikel von TomsHardware gehalten. Letztlich hätte ich beliebige andere Einstellungen nehmen können, aber ich dachte ich halte mich mal an ein solches Beispiel. Ich finde nicht, dass die Parameter besonders elegant sind, aber es ist was es ist. An dieser Stelle sei auch nochmal erwähnt, dass dies nicht bedeutet, dass meine Werte in diesem Artikel direkt mit denen von TH vergleichbar sind.

Als Modell habe ich v1-5-pruned-emaonly in der safetensor Variante verwendet. Zu finden z.B. hier auf Huggingface:
https://huggingface.co/runwayml/stable-diffusion-v1-5/tree/main

Ansonsten wurden keine gesonderten VAEs oder LoRAs verwendet.

positive prompt

postapocalyptic steampunk city, exploration, cinematic, realistic, hyper detailed, photorealistic maximum detail, volumetric light, (((focus))), wide-angle, (((brightly lit))), (((vegetation))), lightning, vines, destruction, devastation, wartorn, ruins

negative prompt

(((blurry))), ((foggy)), (((dark))), ((monochrome)), sun, (((depth of field)))

Parameter

512x512Px, 100 steps, CFG 15, euler sampler, standard scheduler, batch size 1, batch count 5

Der Performance-Vergleich:​

Die Unterschiede in der Generationsgeschwindigkeit decken für den oben genannten Prompt für die verschiedenen getesteten Software-Setups fast eine Größenordnung ab. Bitte bedenkt, dass dies nur ein relativer Leistungsvergleich meiner Hardware und der genannten Modelle+Parameter darstellt. Dies wird in anderen Zusammensetzungen deutlich abweichen.

Man sieht deutlich, dass die out-of-the-box Geschwindigkeit des lshqqytiger DirectML forks von Automatic1111 mit unter einer Iteration pro Sekunde am langsamsten agiert. Der Automatic1111 soll mittlerweile auch mit Optimierungen für Microsoft Olive gut auf AMD Karten laufen - dies habe ich aber nicht getestet. Die Olive-Optimierung schafft hier nochmal ein ganzes Stück Verbesserung (siehe Post #9) auf 3.8 it/s. Die aktuelle Version von ComfyUI, welche ebenfalls DirectML nutzt, schafft bereits aus dem Stand 2.6 it/s. Für die auf Vulkan basierende SHARK Umgebung sind interessanterweise zwei Werte zu nennen. Zunächst erfolgt die Generation mit 3.1 it/s. Läd man jedoch ein Modell erneut, legt SHARK ohne eigenes zutun ein Tuning an, welches den Vorgang auf 4.5 it/s beschleunigt. Ob dies für alle Modelle erfolgt oder - falls nicht - für welche Modelle dieses Tuning erfolgt, kann ich an diesem Punkt nicht sagen. Es ist mir jedoch bei mehreren safetensor models aufgefallen und soll hier erwähnt sein. Der Spitzenreiter ist im Moment klar die Variante, welche die ROCm Suite von AMD nutzen kann. Dies habe ich aktuell nur unter einer nativen Linux Umgebung geschafft, hier werden fast 6 it/s erreicht.


Zur Performance von SHARK gibt es noch einen Punkt zu erwähnen. Während die anderen getesteten Optionen lediglich das lokale Modell laden müssen (was je nach Storage Geschwindigkeit einige Sekunden dauert), müssen für SHARK zunächst erst die Vulkan Shader compiliert werden. Dies dauert mehrere Minuten (für das hier getestete v1-5 Modell etwa 2min30s). Des Weiteren muss dieser Schritt für jede Kombination aus Pixelgröße + Modell + VAE + LoRA erneut durchgeführt werden, was bei häufigem rumprobieren schnell die benötigte Zeit vervielfachen kann. Verwendet man hingegen eine bereits bekannte Kombination, startet die Generation zügig (sofern der Cache nicht manuell geleert wurde). Weiterhin ist zu SHARK der sich durch die Shader zusätzliche ergebende lokale Speicherplatzbedarf zu erwähnen. Ich hatte beim Rumspielen mit verschiedenen Modellen schnell 150GB an .vmfb und .mlir files angehäuft.
Auch die Olive-Optimierung für DirectML kommt nicht ohne Zwischenschritt aus. Hier muss zunächst das normale PyTorch Modell in das ONXX Format transformiert werden. Mehr dazu auch in #9.

Exkurs: Windows Subsystem for Linux 2​

Ein kurzer Exkurs an dieser Stelle zur Verwendung von Microsofts Windows Subsystem for Linux 2 (WSL2) für Stable Diffusion. Ich habe eine Ubuntu 22.04LTS VM per WSL2 eingerichtet und ein bisschen rumprobiert. ROCm habe ich nicht dazu bringen können die GPU als verfügbares Devices zu erkennen. Nach einer kurzen ad hoc recherche ist es wohl so, dass WSL2 die Host-AMD GPU nicht für ROCm Zwecke dem Guest zur Verfügung stellt. DirectML soll hingegen funktionieren. Auch dies habe ich getestet. Die entsprechende DirectML Variante von ComfyUI lässt sich vom WSL2 Container aus unter Ubuntu 22.04LTS starten. Das Webinterface von ComfyUI ist auch problemlos auf dem Host-System per Browser erreichbar. Hier funktioniert alles wunderbar. Die eigentliche Bildergeneration bricht allerdings nach einigen wenigen Iterationen mit einem Fehler ab. Ich habe an dieser Stelle dann nicht mehr Zeit dafür aufgewendet, da ich für DirectML im WSL2 Ubuntu Container nicht viel Leistungszuwachs vermuten würde.

Das Fazit:​

Um ein kurzes Fazit zu ziehen sei hier Folgendes gesagt: Auch wenn die Implementierungen von Stable Diffusion auf AMD Karten noch hinter der Performance der CUDA Alternativen von nVidia zurückliegen ist sehr wohl ein ganz guter Betrieb von SD in einem lokalen Setup möglich. Ich persönlich werde mittelfristig wohl die beiden auf ComfyUI basierenden Optionen nutzen, da selbst die 2.6 it/s unter Windows für ein paar Spielereien ausreichend sind. Falls dann mal wirklich mehr Bilder generiert werden sollen kann man dann flux Ubuntu booten und den Workflow dort ausführen. Das (in meiner persönlichen Wahrnehmung) einfachste Setup geht an SHARK (Studio), welches zugleich die beste AMD Performance unter Windows lieferte. Negativ ist hier allerdings der deutlich merkbare zeitliche Mehraufwand von mehreren Minuten für die Shader Compilation zu nennen, welches insbesondere bei häufigeren VAE/LoRA Kombinationswechseln schnell ins Gewicht fallen kann. Wer hingegen meist mit ein und dem selben Modell arbeitet und nur Prompts austestet, ist hier sicher gut bedient.

Ein Dankeschön gilt jedem, der bis jetzt beim Lesen durchgehalten hat. Ich hoffe dieser kleine Artikel kann einen Anknüpfpunkt für Diskussionen oder Absprungpunkt für Interessierte bieten. Eventuell werde ich den Artikel von meiner Seite aus noch an einigen Punkten ergänzen. Falls es für die Allgemeinheit relevante Fragen im Diskussionsverlauf gibt, werde ich versuchen diese ebenfalls im Eingangspost zu reflektieren.

Bitte seht davon ab in den Kommentaren Hilfsanfragen für konkrete Probleme in euren Setups zu stellen. Support kann (und will) ich an diesem Punkt dahingehend nicht leisten.

Update 06.03.2024: Test-Roundup SDXL​

Mittlerweile ist etwas Zeit vergangen, Zeit genug um einen neuen Blick auf die Situation zu werfen. Auch wenn mit Stable Cascade schon der vielversprechende Nachfolger in den Startlöchern steht habe ich im aktuellen Durchlauf drei Frameworks für SDXL getestet, da die Stable Cascade Unterstützung noch nicht weitflächig verfügbar ist.
Da ich mich zudem weitestgehend im privaten Umfeld von Windows verabschiedet habe hier zunächst nur Tests, welche nativ auf meiner Hardware in Linux laufen. Sollte es besonderes Interesse an Windows spezifischen Tests (z.B. DirectML, ONNX, Windows ROCm/HIP) geben müsste ich die ggf. gesondert noch nachholen.

Wenn ich das nächste Mal etwas mehr Zeit habe werde ich Versuchen die beiden Teile als ein ganzes zusammenzuführen, um das Lesen zu erleichtern. Ich wollte aber dennoch den neuen Testabschnitt bereits jetzt mit euch teilen.

Zum Update mit dem ganzen Text geht es in #22 bzw. HIER

Versionslog:
30.10.2023 Erstes Posting; Fehlerkorrekturen; Ergänzung Exkurs, Olive Optimization
09.11.2023 Update: Einzelbilder-Upload + Automatic1111 mit ROCm
06.03.2024 Update: SDXL und A1111 mit Forge, sowie Fooocus

 

[SpartanerTom]

Ergänzungen zum Hauptartikel​

Hier zur Einzelbetrachtung die erzeugten Bilder nochmal zur größeren Ansicht einzeln. Ich habe versucht die Dateinamen möglichst konsistent zu gestalten (OS_Software_Backend_Seed). Ansonsten stehen die meisten nötigen Informationen auch in den PNG Metadaten (inspizierbar z.B. mit TweakPNG).

Spoiler: Einzelansicht der erzeugten Bilder

Bei den Bildern aus A1111 + Olive sind leider keine Metadaten eingebettet.

Hier wird immer die aktuellste Benchmarkliste unter Berücksichtigung aller Folgeposts stehen. Für die Einzelheiten bitte in den Thread schauen:

Balkenfarbe: rot = ROCm, orange = Vulkan, grün = Olive, schwarz = DirectML
Textfarbe: rot = Ubuntu 22.04LTS, blau = Windows 10

 

[CoMo]

Der erste Github-Link ist kaputt: http://lshqqytiger/

 

[JaeMcBean]

Vielen Dank für den Artikel! Habe nahezu exakt die gleiche Hardware und würde das auch mal ausprobieren wollen. War bislang nur zu faul, aber SHARK scheint ja recht simpel von der Installation zu sein.

 

[SirKhan]

Oh, danke für die Einordnung der Leistung. Ich hab mich immer schon gefragt, ob es sich lohnt, das ML mal auszuprobieren (wegen Windows). Aber dann lasse ich es bleiben.

Ich habe die Szene oben mal bei mir ausprobiert, mit Automatic1111, ROCm und den Einstellungen oben. Mit Linux Mint + Docker eben.
Ich komme mit meiner 6900XT auf 9.5 it/s.
Da werde ich bei Linux bleiben, bis AMD das vollständig auf Windows umsetzt (sie sind ja dabei und Teile laufen schon, aber noch nicht genug). Bis auf den Dualboot ist es ok.

 

[Rickmer]

Schöner Test

Warum steht in der Tabelle 0,8 it/s für A1111 wenn im Screenshot 1,25 zu sehen sind? Kleines Maleur beim Abschreiben?

Meine Installation von A1111 ist alt genug, dass ich den SD1.5 nur als .ckpt statt als .safetensors habe, aber ich habe die oben erwähnten Einstellungen mal durchlaufen lassen:

Mit RTX 4090 und xformers läuft das ganze mit ca. 20 it/s durch.

Der Unterschied zwischen 'in einer halben Minute fertig' und 'dauert 10 Minuten' macht da schon einen ziemlichen Unterschied in der 'user experience'...

Zur Performance von SHARK gibt es noch einen Punkt zu erwähnen. Während die anderen getesteten Optionen lediglich das lokale Modell laden müssen (was je nach Storage Geschwindigkeit einige Sekunden dauert), müssen für SHARK zunächst erst die Vulkan Shader compiliert werden. Dies dauert mehrere Minuten (für das hier getestete v1-5 Modell etwa 2min30s). Des Weiteren muss dieser Schritt für jede Kombination aus Pixelgröße + Modell + VAE + LoRA erneut durchgeführt werden, was bei häufigem rumprobieren schnell die benötigte Zeit vervielfachen kann. Verwendet man hingegen eine bereits bekannte Kombination, startet die Generation zügig (sofern der Cache nicht manuell geleert wurde). Weiterhin ist zu SHARK der sich durch die Shader zusätzliche ergebende lokale Speicherplatzbedarf zu erwähnen. Ich hatte beim Rumspielen mit verschiedenen Modellen schnell 150GB an .vmfb und .mlir files angehäuft.

Das würde SHARK für mich disqualifizieren... ich probiere teils mehrere Checkpoints durch bis ich mir sicher bin, welchen ich für ein spezifisches Bild nutzen will...

 

[SpartanerTom]

Warum steht in der Tabelle 0,8 it/s für A1111 wenn im Screenshot 1,25 zu sehen sind? Kleines Maleur beim Abschreiben?

Das ist ein quirk von dem Python-Skript. Das sind 1.25 Sekunden pro Iteration, also 1/1.25 it/s. Da bin ich auch erst drauf reingefallen, dass sich bei Werten unter eins der Bruch umkehrt.

Ja zum vielfachen Rumprobieren ist SHARK tatsächlich in meiner Wahrnehmung nicht das Optimum. Kann allerdings gut sein, dass es da auch andere Einstellungen gibt die das besser machen. Es gibt ja auch theoretisch eine ROCm Integration unter Windows, aber da muss Upstream erst noch die Unterstützung von AMD für PyTorch nachkommen.

 

[SirKhan]

Ist das Problem nicht, dass pytorch auf MIOpen setzt, aber der neue ROCm-Windows-Treiber nur HIP mitbringt?

Btw. ist da oben schon "Microsoft Olive" (was immer das ist) mit drinnen? Scheint laut dem hier ja massiv (Faktor 10) die Performance zu verbessern:
https://community.amd.com/t5/ai/upd...ed-automatic1111-stable-diffusion/ba-p/630252

 

[SpartanerTom]

Btw. ist da oben schon "Microsoft Olive" (was immer das ist) mit drinnen? Scheint laut dem hier ja massiv (Faktor 10) die Performance zu verbessern:
https://community.amd.com/t5/ai/upd...ed-automatic1111-stable-diffusion/ba-p/630252

Da bin ich ertappt. Das ist ein guter Punkt, den ich stillheimlich vorhin noch als Kommentar hinzugefügt hab. In dem getesteten DirectML fork ist die Olive Unterstützung noch nicht drin und ich habe auch keine separaten Tweaks vorgenommen.

Mein Edit im Artikel:

Der Automatic1111 soll mittlerweile auch mit Optimierungen für Microsoft Olive gut auf AMD Karten laufen - dies habe ich aber nicht getestet.

Mittlerweile hab ich etwas mehr Erfahrung und könnte das eventuell mal Ausprobieren. Für den Artikel wollte ich es aber zunächst bei einer echten Out-Of-The-Box Erfahrung eines Laien halten.

 

[SpartanerTom]

@SirKhan Update zu Olive:

Habe die Olive Implementierung nach der Anleitung aus dem AMD Blog nach einiger Fummelei zum Laufen bekommen. Ich habe es jetzt nur hinbekommen Modelle per Direktimport von Huggingface zu optimieren, meine lokalen Modelle konnte ich nicht aufrufen (kann aber an meiner Unfähigkeit liegen).

Die Modelloptimierung hat etwa sieben Minuten + Downloadzeit von Huggingface beansprucht. Ich habe testweise noch ein anderes SD 1.5 Model optimiert, was auch bei ca. 7min gelandet ist.

Das Ergebnis ist wie folgt:

Die Geschwindigkeit ordnet sich zwischen den beiden SHARK-Ergebnissen ein.

Ein FunFact als Zusatz:

Mein R7 5800X3D schafft bei der CPU Inferenz via SHARK ca. 0.025 it/s, sprich in etwa 1/1800 des getunten GPU Profils.

 

[andi_sco]

@SpartanerTom könntest du die erzeugten Bilder einzeln hochladen? Oder zumindest mit einem weißen Balken zwischen den Bildern?
Dürfte sich dann einfacher anzuschauen sein

 

[SpartanerTom]

@andi_sco Kann ich morgen Nachmittag nachreichen. Was macht mehr Sinn, im Eingangspost hochladen oder separater Post mit Verweis?

 

[andi_sco]

Ich würde die Mods anklingeln, ob sie dir Post#2 geben können. Dann lässt es sich, in meinen Augen, ganz gut auseinander halten.

 

[NameHere]

Ich hoffe da tut sich noch was bei den AMD GPU. Die 7000er Serie soll da schon einiges stärker sein, aber leider immer noch weit abgeschlagen hinter Nvidia.

Meine 3060 schafft ~ 8 it/s

 

[SirKhan]

Hm. Also ich hab mir nun auch mal die DirectML-Version angesehen. Zum einen erreicht sie nicht die Geschwindigkeit von meinem Linux. Und dann ist es irgendwie sehr frickelig.

Beim ersten Versuch (noch mit dem installierten PRO-Treiber 23Q3) habe ich gerade mal 0,5 it/s herausholen können. Danach habe ich den neusten Treiber installiert und siehe da: 5,2 it/s. Ist ok, um mal schnell ein wenig herumzuspielen, ohne Linux starten zu müssen.
Es kamen aber Meldungen wie

Some nodes were not assigned to the preferred execution providers which may or may not have an negative impact on performance. e.g. ORT explicitly assigns shape related ops to CPU to improve perf.

Also dachte ich mir, ich hab das Model ja mit dem alten Treiber optimiert (Olive, ONNX), machste das nochmal. Danach (reoptimized) ist aber die Performance eingebrochen, auf 3,6 it/s :/
Nach ein paar Versuchen habe ich dann Windows neugestartet und nun bin ich wieder bei 0,5 it/s unten

Damit werde ich das Experiment erstmal beenden. ROCm läuft super und ich kann nur hoffen, dass MIOpen und damit PyTorch (ROCm) bald auch auf Windows kommen.

 

[SpartanerTom]

Ich konnte mit AMD Adrenalin 23.11.1 keine praxisrelevanten Verbesserungen der DirectML performance feststellen. Habe aber natürlich auch nur einen begrenzten Testhorizont mit den hier diskutierten Parametern.

P.S. Ich werde die Bilder über das Wochenende noch einpflegen, leider ist über den (katholischen - bevor jemand sich wundert ) Feiertag zu viel dazwischen gekommen.

 

[andi_sco]

Feiertag zu viel dazwischen gekommen

Keine Hektik

 

[SpartanerTom]

Ein weiterer fröhlicher Test in dieser Runde, diesmal main-branch Automatic1111 Version 1.6.0-2 (nicht mehr der AMD fork), ausgeführt nativ unter Ubuntu mit ROCm 5.7 und pytorch 2.2.0.dev20231109+rocm5.7.

Getestet wurde einmal mit Startparameter --no-half und einmal mit --upcast-sampling:

Bei ComfyUI gibt es den Upcast-Parameter auch:

Was zur Upstream-Attention zu erwähnen ist: Es funktioniert nach meiner Erfahrung nicht mit allen Modellen. SD 1.5 und diverse Derivate sind kein Problem, aber SD 2.1 oder SDXL muss wieder auf den Standard zurückfallen. YMMV

Damit ergibt sich folgendes Gesamtbild:

 

[SpartanerTom]

Stable Diffusion XL Turbo läuft auch lokal auf meiner 6800.

Spoiler: Hier mal der schlechteste usecase mit DirectML:

Spoiler: Und hier das ganze ziemlich flott auf ROCm unter Ubuntu:

 

[Rickmer]

Die Architekturischen Meisterleistungen die SDXL Turbo bei dem Prompt erstellt sind unter aller Kanone^^
Wobei grade beim kurzen Gegentest SDXL kaum besser ist...

tori gate, japanese zen garden in autumn, koi pond, wooden bridge