Demo Stable Diffusion WebGPU

• Demo pembuatan gambar Stable Diffusion yang berjalan langsung di browser, beroperasi berbasis WebGPU dan WebAssembly tanpa server terpisah
• Dapat digunakan setelah mengaktifkan flag "Experimental WebAssembly" dan "Experimental WebAssembly JavaScript Promise Integration (JSPI)" di Chrome terbaru
• Menghasilkan gambar dengan menerima input Prompt, Negative Prompt, dan jumlah inference step; file model di-cache sehingga tidak perlu diunduh ulang setiap kali
• Hasil dari patch pada onnxruntime, emscripten, binaryen untuk alokasi memori di atas 4GB serta porting StableDiffusionPipeline Python ke JS
• Saat ini masih lambat karena belum mendukung multithreading dan operasi WebGPU belum diimplementasikan, tetapi menunjukkan potensi peningkatan melalui implementasi kernel JS dan dukungan memory64 di masa mendatang

---

Persyaratan menjalankan

• Perlu mengaktifkan flag Experimental WebAssembly dan Experimental WebAssembly JavaScript Promise Integration (JSPI) di browser Chrome terbaru
• Model files di-cache sehingga tidak perlu diunduh ulang saat berkunjung kembali

Input dan cara kerja

• Item input yang disediakan: Prompt, Negative Prompt, dan jumlah inference step
  • Karena menggunakan PNDM Scheduler, step sebenarnya diproses dari nilai input i menjadi i+1
• Setiap step memakan waktu sekitar 1 menit, dan menjalankan VAE decoder untuk pembuatan gambar membutuhkan tambahan sekitar 10 detik
• Jika DevTools dibuka, kecepatan keseluruhan menjadi sekitar 2 kali lebih lambat
• UNET hanya berjalan di CPU; 10% lebih cepat daripada GPU, sementara di GPU tidak menghasilkan keluaran yang benar dan membuat tab browser berhenti merespons
• Jumlah step minimum untuk mendapatkan hasil yang dapat diterima adalah 20, sedangkan untuk tujuan demo 3 step juga tidak masalah

FAQ

• Error protobuf parsing failed

  • Di DevTools, buka Application → Storage lalu jalankan "Clear site data"

• Error sbox_fatal_memory_exceeded

  • Kondisi RAM tidak mencukupi untuk menjalankan SD; coba atasi dengan memuat ulang tab atau browser

• Cara implementasi

  • StableDiffusionPipeline dari Python di-port ke JS
  • onnxruntime dan emscripten+binaryen (toolchain compiler WebAssembly) di-patch untuk mendukung alokasi dan penggunaan memori di atas 4GB
  • Jika pull request terkait masuk ke rilis, siapa pun dapat mengompilasi dan menjalankan kode yang menggunakan memori di atas 4GB di browser

• Penyebab lambat

  • Karena multithreading belum didukung, masih hanya menggunakan satu core CPU
  • Pembuatan memori 64-bit dengan SharedArrayBuffer melalui constructor WebAssembly.Memory tidak memungkinkan
  • Mengusulkan perubahan spesifikasi flag "memory64", dan setelah diadopsi berencana mem-patch engine V8 untuk mendukungnya

• Apakah berjalan di GPU

  • Berjalan di GPU, tetapi WebGPU pada onnxruntime masih tahap awal sehingga banyak operasi belum diimplementasikan
  • Data terus-menerus ditransfer melalui JS antara CPU dan GPU
  • Jika kernel JS diimplementasikan untuk sebagian besar operasi, kecepatan dapat meningkat drastis

• Apakah bisa dijalankan secara lokal

  • Bisa, dan kode halaman tersebut tersedia di repositori stable-diffusion-webgpu-minimal

• Apakah bisa menjalankan LLM besar dengan transformers.js

  • Paket onnxruntime yang sudah di-patch (@aislamov/onnxruntime-web64) dapat digunakan, tetapi tidak dijamin berfungsi di semua kasus
  • Build tersebut dibatasi pada memori 8GB sehingga dapat memuat bobot hingga sekitar 4GB

• Rencana pull request ke repositori onnxruntime

  • Direncanakan akan dilakukan, sebagai pekerjaan kedua setelah sebelumnya menambahkan akselerasi GPU pada binding node.js

[GN⁺]

Komentar Hacker News

• Tim MLC sudah menjalankan ini sejak Maret: https://github.com/mlc-ai/web-stable-diffusion
  Yang lebih mengesankan, mereka kemudian bahkan menambahkan dukungan untuk berbagai large language model: https://webllm.mlc.ai/

  • Sangat mengesankan, dan performanya juga terlihat jauh lebih baik. Saya sendiri mengikuti pendekatan lain yang menjalankan model ONNX arbitrer tanpa modifikasi sebelumnya

• “Memuat 3.5GB dan menggunakan RAM 8GB”
  Menarik melihat browser menjadi seperti ini. Web telah memakan sistem operasi

  • Saya kurang paham kritik ini. Kita menjalankan Stable Diffusion di komputer saya lewat browser, jadi bagaimana mungkin melakukannya tanpa mengunduhnya dan memuatnya ke RAM?
    Bahkan jika diunduh dan dijalankan langsung tanpa browser, ukuran unduhan dan penggunaan RAM-nya kemungkinan hampir sama
  • Web telah memakan premis asli Java
  • Itulah sebabnya ada perusahaan yang menjual laptop dengan sistem operasi yang pada dasarnya adalah browser, dan ada perusahaan yang melakukan hal yang sama pada smart TV
  • Menarik melihat bagaimana, seiring bandwidth meningkat dan sandbox web makin matang, aplikasi berevolusi menjadi sesuatu yang tinggal dipakai alih-alih diunduh, dipasang, dan dirawat. Sebagian orang mungkin tidak suka, tetapi ini membuka banyak pintu bagi masyarakat umum
  • Sekarang saya jadi berpikir WebGPU juga berguna untuk penggunaan seperti ini, bukan hanya untuk halaman WebXR interaktif real-time, state multiplayer streaming, atau banyak draw call.
    Ada sisi yang menjadi lebih sederhana saat pengalaman seperti ini diberikan lewat browser, dan sepertinya tidak ada cara yang lebih mudah daripada ini untuk menjalankan Stable Diffusion, jadi saya harap proyek seperti ini terus didukung

• Ternyata perlu Chrome terbaru dengan flag Experimental WebAssembly dan Experimental WebAssembly JavaScript Promise Integration (JSPI) aktif, jadi sepertinya saya harus menunggu sampai masuk ke Firefox

  • Setidaknya Firefox sekarang mengizinkan styling scrollbar CSS, jadi itu kabar baik
  • Saya sudah mengaktifkan chrome:flags yang diminta di Brave, tapi tetap tidak berjalan. Saya belum pernah mengunduh Chrome di Mac M1 saya, dan tidak berniat memulainya sekarang
  • Sudah saya aktifkan di Canary, tapi tetap saja tidak berhasil dijalankan
  • Jadi memang tidak mau mencoba di Chrome sama sekali?
  • Flag kedua itu fungsinya apa?

• Ini juga sudah diimplementasikan di sini: https://websd.mlc.ai/#text-to-image-generation-demo
  MLC melakukan generasi kode WebGPU dan auto-tuning dengan Apache TVM, dan performanya juga cukup bagus

• Saya mengintegrasikan Stable Diffusion dari MLC-AI ke situs web saya sebagai generator latar belakang kustom. Data modelnya diambil dari Hugging Face
  https://dustinbrett.com/

  • Melihat sesuatu yang selancar dan secepat ini justru membuat sedih bahwa semua aplikasi di ponsel meminta 200MB hanya untuk menampilkan beberapa layar dan mengirim beberapa panggilan API
  • Di iPhone 12 mini termuat dengan baik dan ponselnya juga tidak panas. Sangat mengesankan
  • Situs webnya mengesankan dan semuanya berjalan sangat mulus. Akhirnya saya malah bermain Doom lebih lama dari yang seharusnya

• Untuk pekerjaan yang terikat CPU, mungkin layak mempertimbangkan penggunaan service worker agar thread utama tidak macet

• Berikutnya chatbot WebGPU? Chat ala ChatGPT di browser memakai GPU saya?

  • Sebenarnya itu sudah bisa. Ada beberapa keterbatasan
    Semakin bagus sebuah large language model, biasanya semakin besar penggunaan RAM/VRAM-nya, sehingga terutama sulit di WebGPU
  • https://webllm.mlc.ai/
    Sudah diimplementasikan

• Penasaran, ini dipakai untuk apa?
  Yang saya tahu, ini menghasilkan gambar di browser, bukan di server. Yang terpikir oleh saya hanya kita tidak perlu me-refresh halaman untuk mengubah atau membuat gambar baru.
  Mungkin itu berarti situs web dengan desain visual yang berubah secara real-time jadi mungkin, dan kalau perubahan fungsionalnya juga berarti, itu bisa sangat keren. Hanya saja saya tidak yakin seberapa berguna Stable Diffusion untuk membuat komponen UI atau elemen visual sebuah situs

  • Ini berguna karena biaya menghasilkan gambar dalam jumlah besar itu mahal. Artinya biaya komputasi dipindahkan ke klien
  • Kegunaannya adalah agar mudah dijalankan di komputer sendiri. Tidak perlu jadi programmer, dan tidak perlu memasang aplikasi
  • Menjalankan model sepenuhnya secara lokal punya keuntungan besar dalam hal privasi
    Prompt sensitif tidak akan bocor ke pihak jauh yang entah siapa

• Adakah metrik yang membandingkan performa di WebGPU dengan performa eksekusi native?

  • UNET memerlukan sekitar 1 menit 10 detik di WebGPU, sedangkan di CPU single-thread sekitar 1 menit. VAE memerlukan 2 menit di CPU, dan sekitar 10 detik di GPU.
    Sepertinya itu karena komputasi GPU untuk VAE sebagian besar sudah diimplementasikan, sedangkan untuk UNET belum. Pada kasus yang terakhir, browser terus melempar data bolak-balik antara GPU dan CPU di setiap langkah

• Jika cukup cepat, ini bisa dipakai untuk merender gambar secara lokal untuk penggunaan personal. Situs web bisa hanya mengirim prompt, lalu setiap pengguna merender gambar yang berbeda.
  Kalau begitu, bagaimana urusan hak ciptanya? Apakah modelnya sendiri yang menjadi objek hak cipta, atau justru keseluruhan kerangkanya runtuh?

  • Kemungkinan itu menarik, tapi saat ini kita masih sangat jauh dari dunia seperti itu. Di bagian lain thread ini juga disebutkan bahwa ini secara aktif menggunakan RAM 8GB.
    Dan saya rasa banyak web designer tidak akan menerima risiko bahwa model salah menafsirkan prompt, menghasilkan output yang terdistorsi dengan jumlah jari yang salah, atau secara tidak sengaja membuat konten seksual atau kekerasan dalam konteks yang tidak dimaksudkan.
    Saat ini, banyak model gambar generatif biasanya memilih yang terbaik dari sepuluh gambar atau lebih, dan sisanya yang dibuang sebenarnya bisa cukup buruk.
    Agar situs web bisa diilustrasikan secara dinamis dalam penggunaan sehari-hari, kualitas dan prediktabilitas model harus jauh lebih tinggi daripada sekarang.
    Namun saya juga tidak ingin mengatakan bahwa kita tidak akan pernah sampai ke sana. Model-model terbaru sudah melakukan hal-hal yang beberapa tahun lalu dianggap mustahil untuk dibayangkan. https://xkcd.com/1425/ Jika dibandingkan dengan itu, bagi pembaca yang lebih muda mungkin bahkan sulit menjelaskan masalah latar belakang yang menjadi bahan lelucon tersebut!