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]

@Rickmer Ja ist vermutlich nicht der beste Prompt, war aber das erste was mir so in den Sinn kam.
Wollte nur mal testen was da neues bei rumkam mit dem Model. Ergebnisorientiert sicher keine gute Wahl, aber eine nette Spielerei.

 

[SpartanerTom]

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.

Test-Roundup​

Das ganze findet mittlerweile auf meinem neuen Daily Driver Linux System statt:

Zugrunde liegen dem ganzen separat geführte Python 3.11.5 Installationen mit folgender pytorch-Version:

Spoiler: pip show torch

Name: torch
Version: 2.2.1+rocm5.7
Summary: Tensors and Dynamic neural networks in Python with strong GPU acceleration
Home-page: https://pytorch.org/
Author: PyTorch Team
Author-email: packages@pytorch.org
License: BSD-3

Als Frontend für Stable Diffusion kommen folgende Kandidaten zur Verwendung:

ComfyUI | Revision 2049 (>Github)
Automatic1111 | Version 1.8 (>Github)
Automatic1111 | mit Forge Backend f0.0.17v1.8.0rc-latest-273 (>Github)
Fooocus | Version 2.1.857 (>Github)

Fooocus wurde hierbei der Vollständigkeit halber her getestet. Hier ist wird vor allem ein Augenmerk auf einfache Verwendbarkeit gelegt, während Automatic1111 und vor allem ComfyUI auf Vielseitigkeit und Geschwindigkeit setzen.

Prompt Parameter:​

positive prompt

beautiful spring landscape, blooming flowers, sunny weather

negative prompt

text, watermark

weitere Parameter

1024x1024 Pixel
DPM++  2M Karras
30 steps
CFG 7
random seed
no refiner
no live preview
batchsize 1
batchcount 5

Verwendeter Checkpoint
SDXL Artium v1.0 by FrenzyX (>CivitAI)

Generations-Benchmarks auf einen Blick​

Das Teilnehmerfeld zeigt sich insgesamt relativ dicht beieinander. Foocus landet mit etwas über 0.8 Iterationen pro Sekunde auf dem letzten Platz was in etwa 70% der Geschwindigkeit von ComfyUI mit gesetztem "dont-upcast-attention" flag entspricht. Obwohl das Forge Backend grundsätzlich leichte Verbesserungen gegenüber den Main-Branch verspricht bewahrheitet sich dies in meinem kleinen Testparcours zunächst nicht. 0.97 it/s für das Forge-Backend stehen 1.11 it/s für den Main-Branch gegenüber. Allerdings ist der gewählte Anwendungfall auch nicht optimal, da insbesondere Karten mit kleinerer VRAM Kapazität von den Verbesserungen im Speichermanagment profitieren sollen.

Stichwort Speicherverwaltung​

Da ich in der Vergangenheit häufiger Out-Of-Memory-Probleme durch momentane VRAM-Spikes hatte, habe ich mir dieses Mal auch den Verlauf der VRAM-Auslastung angesehen:

Spoiler: VRAM-Verlauf ComfyUI-Baseline

Spoiler: VRAM-Verlauf ComfyUI-noUpcast

Spoiler: VRAM-Verlauf A1111-main

Spoiler: VRAM-Verlauf A1111-forge

Spoiler: VRAM-Verlauf Fooocus

Hier zeigt sich für ComfyUI nur ein kleiner Spike am Ende des ersten VAE-Encodings, während Automatic1111 im main branch bei jedem VAE-Encoding einen sehr starken sprunghaften Anstieg des VRAM-Verbrauchs aufweist. Dieser Umstand kann insbesondere nahe des VRAM Limits eine Hürde darstellen. Interessanterweise weißt A1111 mit Forge ähnlich wie ComfyUI nur einen kleinen Spike beim ersten VAE Encoding auf, aber auch ingesamt liegt hier der Gesamtverbrauch etwas höher als bei den anderen Lösungen. Woran dies liegt ist mir zur Zeit nicht unmittelbar klar. Am kompaktesten und unauffälligsten ist der VRAM Verlauf bei Fooocus, womit dieses Paket seinem Ruf als Gutes All-In-One Paket zum Einstieg und Rumprobieren durchaus gerecht wird.

Fazit​

Zusammenfassend möchte ich mich zu keiner eindeutigen Empfehlung hinreißen lassen. Alle getesteten Softwarelösungen sind (in meinem Anwendungsfall) gut nutzbar und findet sicher seine Abnehmer. ComfyUI bringt als mächtiges Node-basiertes WebUI eine höhere Einstiegshürde mit, liefert dafür aber maximale Flexibilität und häufig zuerst cutting edge Features wie z.B. Stable Cascade. Autmatic1111 profitiert dafür von seiner einerseits leichter zugängigen Weboberfläche und vielen A1111 spezifischen Online-Tutorials.

Besonders herausgehoben sei insgesondere für Einsteiger an dieser Stelle Fooocus, wenn es zunächst einfach mal nur um ein Ausprobieren gehen soll ist diese Lösung vermutlich die beste Wahl. Zudem hier auch ein integriertes GPT-2 basiertes LLM zur Hilfe steht, welches den eigenen Text-Prompt noch etwas zu optimieren versucht.

Ergänzung (6. März 2024)

Im Folgenden noch die einzelnen Bilder zu den getesteten WebUIs:

Spoiler: ComfyUI-Baseline

Spoiler: ComfyUI-noUpcast

Spoiler: Automatic1111-main

Spoiler: Automatic1111-forge

Spoiler: Fooocus

 

[Rickmer]

Danke für's Update

Auch wenn mit Stable Cascade schon der vielversprechende Nachfolger in den Startlöchern steht

Persönlich muss ich sagen, dass ich viel mehr auf Stable Diffusion 3 gespannt bin, welches ja auch in der Zwischenzeit angekündigt wurde.

Stable Cascade hat in ein paar Versuchen von mir sehr schnell gezeigt, dass es absolut keine Fähigkeit, relationale Prompts auszuführen (also sowas wie 'cat on the table, dog under the table').

Damit ist SC mMn schlicht zu 'dumm'.

Aber vielleicht wird das ja noch im finalen Release gefixt.

Automatic1111 | mit Forge Backend f0.0.17v1.8.0rc-latest-273 (>Github)

Ich bin gespannt

SDXL Artium v1.0 by FrenzyX (>CivitAI)

Nice. Einer meiner Favouriten.

Obwohl das Forge Backend grundsätzlich leichte Verbesserungen gegenüber den Main-Branch verspricht bewahrheitet sich dies in meinem kleinen Testparcours zunächst nicht. 0.97 it/s für das Forge-Backend stehen 1.11 it/s für den Main-Branch gegenüber. Allerdings ist der gewählte Anwendungfall auch nicht optimal, da insbesondere Karten mit kleinerer VRAM Kapazität von den Verbesserungen im Speichermanagment profitieren sollen.

Etwas merkwürdig. Forge sollte eigentlich in keiner Situation wirklich langsamer sein, nur in manchen Situationen signifikant schneller.

Es sind nicht nur Karten mit kleinem vram, die signifikant profitieren, sondern auch mit der RTX 4090 habe ich festgestellt, dass ich deutlich höhere Auflösungen erreichen kann, ohne das vom VRAM in den RAM ausgelagert wird - und damit höhere Auflösungen ohne Verlangsamung genutzt werden können.
Außerdem ist die maximal erreichbare Auflösung ohne Tricks (Tiled VAE, Ultimate SD Upscale Script, etc) signifikant höher. Mit A1111 ist 3440x1440 nativ ziemlich das Limit, mit Forge geht da noch viel mehr und auch schneller.

Falls du nichts der Art bemerkt hast, liegt das vielleicht an ROCm?
Bzw. andersrum gedacht daran, dass die Optimierungen in Forge für nvidia GPU Architekturen gemacht sind?

 

[SpartanerTom]

@Rickmer
Ich will mir die Forge-Thematik auf jeden Fall noch einmal genauer ansehen. Insbesondere wenn man die VRAM-Auslastung stärker mit einbezieht. Da ist im vorliegenden Fall ja eher Langeweile angesagt. Das habe ich allerdings in diesem Run nicht mehr geschafft, da saubere Vorbereitungen der Dependencies und Testen für die vorliegenden Fälle schon fast vier Stunden gedauert hat.

Es kann aber natürlich auch generell eine Limitierung durch ROCm vorliegen, welches nicht explizit unterstützt wird. Ich habe hier schlicht per git checkout zwischen den branches main und lllyasviel/main gewechselt. Vielleicht bleiben hier irgendwo nicht berücksichtigte Altlasten zurück, obwohl es laut Dokumentation eigentlich funktionieren sollte.

Eventuell sollte man das Ganze mal mit einer ganz sauberen Installation von A1111 mit Forge testen.

 

[Rickmer]

Eventuell sollte man das Ganze mal mit einer ganz sauberen Installation von A1111 mit Forge testen.

Ja, ich war eher erstaunt, bei dir in Forge 12GB VRAM zu sehen während sich A1111 mit 11GB (plus Spikes) begnügt hatte.

Das passt so ein bisschen überhaupt nicht, was ich von Forge kenne - wobei ich zugegeben bei den 'kleinen' Auflösungen wie 1024x1024 eh nicht so wirklich drauf achte.

Für mich war ein 'oha' Effekt als ich festgestellt habe, dass ich bei 832x1216 mit Upscale in Forge problemlos 2x Highres Fix ohne Verlangsamung machen konnte während A1111 irgendwo oberhalb einem 1.6x Upscale anfängt von VRAM in RAM auszulagern mit entsprechender Auswirkung auf die Performance.

 

[SpartanerTom]

@Rickmer
Kurzes Zwischenupdate für das ich zwischendrin mal Zeit gefunden habe (werde den Artikel im Nachgang noch entsprechend anpassen). Ich habe ein paar Dinge getestet und ein paar Dinge neu gelernt

Das größte Problem im vorliegenden Fall ist dass es xformers nicht für AMD/ROCm gibt. Einige Optimierungen gibt es deshalb nicht von Haus aus.

Die Einstellungen zum Attention Upcast beziehen sich (soweit ich das sehen kann) vor allem auf die Verwendung von FP32 in einigen attention layern, welches Performance kostet und ein ganzes Stück mehr VRAM benötigt. Diese Optimierung/Einstellung kann man manuell hinzuschalten, heißen aber bei jedem WebUI anders, weshalb ich das zunächst nicht realisiert habe:

A1111: --upcast-sampling
Forge/Foocus: --disable-attention-upcast
ComfyUI: --dont-upcast-attention

Diese Settings funktionieren wohl nicht mit SD2.* aber ich verwende zur Zeit wenn dann eh SD1.5 oder SDXL.

Mit den entsprechenden Settings liegt Forge für SDXL 1024x1024 bei etwa 7.5GB VRAM Bedarf (wenn man den Hintergrund abzieht). Automatic1111 liegt einige 100MB höher, allerdings ist der Unterschied nicht so riesig. Was für Forge noch ein großer Vorteil ist, ist die integrierte "Never OOM" Extension mit der man TiledVAE einfach erzwingen kann. Denn ich habe bemerkt, dass im VAEDecode Step ca 3GB RAM dauerhaft reserviert werden, die nicht so ohne weiteres wieder freigegeben werden. Mit TiledVAE passiert das nicht und es treten auch keine Spikes auf.

In der Geschwindigkeit überholt Forge ohne FP32 attention auch den main branch und liegt etwa gleichauf mit ComfyUI.

 

[MechanimaL]

Du hattest teilweise diesen Fork benutzt von A1111 für den Test unter Windows/ DirectML, korrekt?
https://github.com/lshqqytiger/stable-diffusion-webui-directml

Für mich stellt sich noch die Frage, was unter Windows aktuell die schnellste Lösung ist für A1111. Es gibt auch noch Zluda Support, das dürfte schneller sein als DirectML, oder? Ist diese "olive-optimierung" damit kombinierbar?

 

[SpartanerTom]

@MechanimaL
Ich bin aus dem Windows Game ehrlich gesagt (im Moment) etwas raus da auf meiner Mühle seit Dezember Linux rennt. Für den DirectML Test hatte ich wie du richtig gesagt hattest den oben genannten branch verwendet.

Olive optimiert die zugrundeliegenden Diffuser und Transformer Modelle und übersetzt diese in ein ONNX Format, welches nativ auf AMD unter Windows laufen kann. Das ist (in meinem Verständnis) konzeptionell vergleichbar mit der "Übersetzung" der Modelle in ein Vulkan-Format wie es SHARK tut. Dabei ist ONNX aber in meiner kurzen Erfahrung deutlich flexibler, weil die Übersetzung nicht für jedes Rendertarget neu erfolgen muss.

Ich würde vermuten, dass man mit ZLUDA die nativen Modelle laufen lassen kann um die beste Performance zu haben, wenn ich das Funktionsprinzip richtig verstanden habe. Nach meinem Verständnis würde ich hier keine übermäßigen Gewinne durch einen ONNX Zwischenschritt erwarten.

Falls ich die Zeit dazu finde kann ich eventuell mal wieder in mein altes Windows booten und die verschiedenen Dinge testen. Allerdings ist dies ehrlich gesagt im Moment eher weiter unten auf meiner Liste.