Stable-Diffusion-WebGPU-Demo

• Eine Demo zur Stable Diffusion-Bildgenerierung, die direkt im Browser läuft und ohne separaten Server auf Basis von WebGPU und WebAssembly funktioniert
• Nutzbar nur, wenn in der aktuellen Chrome-Version die Flags "Experimental WebAssembly" und "Experimental WebAssembly JavaScript Promise Integration (JSPI)" aktiviert sind
• Erzeugt Bilder anhand von Prompt, Negative Prompt und der Anzahl der Inference-Schritte; Modelldateien werden zwischengespeichert, sodass sie nicht jedes Mal erneut heruntergeladen werden müssen
• Entstanden durch Patches an onnxruntime, emscripten, binaryen zur Speicherzuweisung über 4 GB sowie durch ein JS-Port von Pythons StableDiffusionPipeline
• Derzeit langsam wegen fehlender Multithreading-Unterstützung und noch nicht implementierter WebGPU-Operationen, aber mit Aussicht auf Verbesserungen durch JS-Kernel-Implementierung und memory64-Unterstützung

---

Ausführungsanforderungen

• Im aktuellen Chrome-Browser müssen die Flags Experimental WebAssembly und Experimental WebAssembly JavaScript Promise Integration (JSPI) aktiviert werden
• Model files werden gecacht, daher ist bei einem erneuten Besuch kein erneuter Download nötig

Eingaben und Funktionsweise

• Als Eingaben stehen Prompt, Negative Prompt und die Anzahl der Inference-Schritte zur Verfügung
  • Durch die Verwendung des PNDM Scheduler wird die tatsächliche Schrittzahl vom Eingabewert i zu i+1 verarbeitet
• Jeder Schritt dauert etwa 1 Minute; für die Ausführung des VAE decoder zur Bilderzeugung kommen zusätzlich etwa 10 Sekunden hinzu
• Wenn DevTools geöffnet sind, wird die Gesamtgeschwindigkeit etwa halbiert
• UNET läuft nur auf der CPU, ist dort 10 % schneller als auf der GPU und liefert auf der GPU keine korrekten Ergebnisse, wodurch der Browser-Tab hängen bleibt
• Die minimale Schrittzahl für akzeptable Ergebnisse liegt bei 20; für Demo-Zwecke sind auch 3 Schritte ausreichend

FAQ

• Fehler protobuf parsing failed

  • In DevTools zu Application → Storage wechseln und "Clear site data" ausführen

• Fehler sbox_fatal_memory_exceeded

  • Es steht nicht genug RAM für die Ausführung von SD zur Verfügung; versuche, den Tab oder den Browser neu zu laden

• Implementierungsweise

  • Pythons StableDiffusionPipeline wurde nach JS portiert
  • onnxruntime sowie emscripten+binaryen (WebAssembly-Compiler-Toolchain) wurden gepatcht, um Speicherzuweisung und -nutzung über 4 GB zu unterstützen
  • Sobald die zugehörigen Pull Requests in Releases enthalten sind, kann jeder im Browser Code kompilieren und ausführen, der mehr als 4 GB Speicher verwendet

• Ursachen der langsamen Geschwindigkeit

  • Es gibt noch keine Multithreading-Unterstützung, daher wird nur ein CPU-Kern verwendet
  • Über den WebAssembly.Memory-Konstruktor kann kein 64-Bit-Speicher mit SharedArrayBuffer erzeugt werden
  • Es wurde eine Änderung der Spezifikation für das "memory64"-Flag vorgeschlagen; nach Annahme soll Unterstützung durch einen Patch der V8-Engine folgen

• Ob GPU-Ausführung möglich ist

  • Die Ausführung erfolgt auf der GPU, aber WebGPU in onnxruntime befindet sich noch in einer frühen Phase, daher sind viele Operationen nicht implementiert
  • Daten werden fortlaufend über JS zwischen CPU und GPU übertragen
  • Sobald für die meisten Operationen JS-Kernel implementiert sind, ist eine deutliche Geschwindigkeitssteigerung möglich

• Ob lokale Ausführung möglich ist

  • Ja, der Code dieser Seite wird im Repository stable-diffusion-webgpu-minimal bereitgestellt

• Ob sich mit transformers.js große LLMs ausführen lassen

  • Das gepatchte onnxruntime-Paket (@aislamov/onnxruntime-web64) kann verwendet werden, allerdings ist die Funktionsfähigkeit nicht in allen Fällen garantiert
  • Dieser Build ist auf 8 GB Speicher begrenzt und kann Gewichte bis etwa 4 GB laden

• Geplante Pull Requests für das onnxruntime-Repository

  • Sind vorgesehen; es ist die zweite Arbeit nach dem früheren Hinzufügen von GPU-Beschleunigung zu den node.js-Bindings

[GN⁺]

Hacker-News-Kommentare

• Das MLC-Team hatte das schon im März zum Laufen gebracht: https://github.com/mlc-ai/web-stable-diffusion
  Noch beeindruckender ist, dass sie danach sogar Support für mehrere große Sprachmodelle hinzugefügt haben: https://webllm.mlc.ai/

  • Wirklich beeindruckend, und die Performance scheint auch deutlich besser zu sein. Ich hatte einen anderen Ansatz verfolgt, bei dem beliebige ONNX-Modelle ohne vorherige Modifikationen ausgeführt werden

• „Lädt 3,5 GB und verwendet 8 GB RAM“
  Interessant, dass Browser so geworden sind. Das Web hat das Betriebssystem aufgefressen

  • Ich verstehe diese Kritik nicht ganz. Man führt Stable Diffusion über den Browser auf dem eigenen Rechner aus — wie soll das gehen, ohne es herunterzuladen und in den RAM zu laden?
    Wenn man es ohne Browser direkt herunterlädt und ausführt, wären Download-Größe und RAM-Nutzung fast identisch
  • Das Web hat Javas ursprüngliche Prämisse aufgefressen
  • Deshalb gibt es Firmen, die Laptops verkaufen, bei denen das Betriebssystem im Grunde der Browser ist, und Firmen, die auf Smart-TVs dasselbe tun
  • Es ist interessant zu sehen, wie sich das mit wachsender Bandbreite und einer reiferen Web-Sandbox zu Apps entwickelt, die man einfach benutzt statt sie herunterzuladen, zu installieren und zu warten. Manche werden das hassen, aber für die breite Masse öffnet es viele Türen
  • Ich denke inzwischen, dass WebGPU auch für solche Anwendungsfälle nützlich ist und nicht nur für Echtzeit-interaktive WebXR-Seiten, gestreamten Multiplayer-Status oder viele Draw Calls.
    Solche Erfahrungen im Browser anzubieten vereinfacht manches, und es scheint keinen einfacheren Weg zu geben, Stable Diffusion auszuführen, daher hoffe ich, dass solche Projekte weiter unterstützt werden

• Offenbar braucht man die neueste Chrome-Version mit aktivierten Flags für Experimental WebAssembly und Experimental WebAssembly JavaScript Promise Integration (JSPI), also warte ich wohl, bis das in Firefox ankommt

  • Immerhin erlaubt Firefox jetzt CSS-Scrollbar-Styling, das ist also gut
  • Ich habe die geforderten chrome:flags in Brave aktiviert, aber es lief trotzdem nicht. Auf meinen M1-Macs habe ich Chrome noch nie heruntergeladen und habe auch jetzt nicht vor, damit anzufangen
  • Ich habe es in Canary aktiviert, konnte es aber trotzdem nicht zum Laufen bringen
  • Heißt das, du wirst es in Chrome nicht einmal versuchen?
  • Was macht das zweite Flag eigentlich?

• Hier ist es ebenfalls schon implementiert: https://websd.mlc.ai/#text-to-image-generation-demo
  MLC nutzt Apache TVM für WebGPU-Codegenerierung und Auto-Tuning, und die Performance ist ziemlich ordentlich

• Ich habe Stable Diffusion von MLC-AI als benutzerdefinierten Hintergrundgenerator in meine Website integriert. Die Modelldaten kommen von Hugging Face
  https://dustinbrett.com/

  • Wenn man sieht, wie flüssig und schnell das ist, ist es traurig, dass jede Handy-App für ein paar Bildschirme und ein paar API-Aufrufe gleich 200 MB verlangt
  • Auf einem iPhone 12 mini wurde es problemlos geladen, und das Handy ist nicht einmal heiß geworden. Wirklich beeindruckend
  • Die Website ist beeindruckend, und alles läuft sehr flüssig. Am Ende habe ich viel länger als nötig Doom gespielt

• Bei CPU-gebundenen Aufgaben könnte man überlegen, Service Worker zu verwenden, damit der Main Thread nicht blockiert

• Ist das Nächste dann ein WebGPU-Chatbot? ChatGPT-artiger Chat im Browser auf meiner GPU?

  • Das geht bereits. Es gibt ein paar Einschränkungen
    Große Sprachmodelle brauchen bei besseren Modellen viel RAM/VRAM und sind auf WebGPU besonders anspruchsvoll
  • https://webllm.mlc.ai/
    Ist bereits umgesetzt

• Nur aus Neugier: Wofür nutzt man das?
  Soweit ich weiß, werden Bilder im Browser statt auf dem Server erzeugt. Mir fällt dazu vor allem ein, dass man die Seite nicht neu laden muss, um Bilder zu ändern oder neue zu erzeugen.
  Das könnte bedeuten, dass Websites möglich werden, deren visuelles Design sich in Echtzeit verändert, und wenn sich auch funktional etwas sinnvoll ändern kann, wäre das ziemlich cool. Ich bin mir nur nicht sicher, wie nützlich Stable Diffusion für die Erzeugung von UI-Komponenten oder visuellen Elementen einer Website wirklich ist

  • Das ist nützlich, weil die massenhafte Bilderzeugung teuer ist. Man verlagert die Rechenkosten auf den Client
  • Der Einsatzzweck ist, es einfach auf dem eigenen Rechner laufen zu lassen. Man muss kein Programmierer sein und keine Anwendung installieren
  • Wenn das Modell vollständig lokal läuft, ist Privatsphäre ein großer Vorteil
    Sensible Prompts gelangen nicht an irgendjemanden in der Ferne

• Gibt es Kennzahlen, die die Performance auf WebGPU mit nativer Ausführung vergleichen?

  • UNET braucht auf WebGPU etwa 1 Minute 10 Sekunden, auf einer einzelnen CPU-Thread etwa 1 Minute. VAE braucht auf der CPU 2 Minuten und auf der GPU etwa 10 Sekunden.
    Wahrscheinlich liegt das daran, dass der Großteil der GPU-Berechnungen für VAE bereits implementiert ist, für UNET aber nicht. Im zweiten Fall schiebt der Browser bei jedem Schritt ständig Daten zwischen GPU und CPU hin und her

• Wenn es schnell genug ist, könnte man es privat nutzen, um Bilder lokal zu rendern. Eine Website könnte nur den Prompt übermitteln und pro Nutzer unterschiedliche Bilder rendern.
  Wie wäre dann das Urheberrecht an diesem Punkt? Ist schon das Modell selbst urheberrechtlich geschützt, oder bricht das ganze System auseinander?

  • Die Möglichkeit ist interessant, aber im Moment sind wir noch sehr weit von so einer Welt entfernt. Anderswo in diesem Thread wird erwähnt, dass das 8 GB RAM aktiv nutzt.
    Und ich glaube nicht, dass viele Webdesigner das Risiko akzeptieren würden, dass das Modell Prompts falsch interpretiert, verzerrte Ergebnisse mit falscher Anzahl von Fingern erzeugt oder versehentlich sexuelle bzw. gewalttätige Inhalte in unpassenden Kontexten produziert.
    Bei vielen generativen Bildmodellen heute wählt man meist das beste aus zehn oder mehr Bildern aus, und der Rest, den man verwirft, kann tatsächlich ziemlich schlecht sein.
    Damit Websites routinemäßig dynamisch illustriert werden können, müssten Qualität und Vorhersagbarkeit der Modelle deutlich höher sein als heute.
    Ich will damit nicht sagen, dass wir da nie hinkommen. Neuere Modelle leisten bereits Dinge, die vor ein paar Jahren noch als unvorstellbar galten. Verglichen mit https://xkcd.com/1425/ könnte es für jüngere Leser sogar schwierig sein, das Hintergrundproblem des Witzes überhaupt noch zu erklären!