Stable Diffusion WebGPU demosu

• Tarayıcıda doğrudan çalışan Stable Diffusion görüntü üretim demosu; ayrı bir sunucu olmadan WebGPU ve WebAssembly tabanlı çalışıyor
• Kullanmak için en güncel Chrome sürümünde "Experimental WebAssembly" ve "Experimental WebAssembly JavaScript Promise Integration (JSPI)" bayraklarının etkinleştirilmesi gerekiyor
• Prompt, Negative Prompt ve inference step sayısını alarak görüntü üretiyor; model dosyaları önbelleğe alınır, bu yüzden her seferinde yeniden indirilmeleri gerekmez
• 4GB'ı aşan bellek ayırma için onnxruntime, emscripten, binaryen yamalandı ve Python'daki StableDiffusionPipeline JS'ye taşındı
• Çoklu iş parçacığı desteği olmaması ve WebGPU işlemlerinin tam uygulanmamış olması nedeniyle şu anda yavaş, ancak ileride JS kernel implementasyonu ve memory64 desteği ile iyileştirilebileceği belirtiliyor

---

Çalıştırma gereksinimleri

• En güncel Chrome tarayıcısında Experimental WebAssembly ve Experimental WebAssembly JavaScript Promise Integration (JSPI) bayraklarının etkinleştirilmesi gerekir
• Model files önbelleğe alınır; site yeniden ziyaret edildiğinde tekrar indirilmeleri gerekmez

Girdi ve çalışma şekli

• Girdi olarak Prompt, Negative Prompt ve inference step sayısı verilir
  • PNDM Scheduler kullanıldığı için gerçek step, girilen i değerinden i+1 olarak işlenir
• Her step yaklaşık 1 dakika sürer, görüntü üretimi için VAE decoder çalıştırılması da ek olarak yaklaşık 10 saniye alır
• DevTools açıkken genel hız yaklaşık 2 kat düşer
• UNET yalnızca CPU'da çalışır; GPU'dan %10 daha hızlıdır ve GPU'da doğru sonuç üretmediği için tarayıcı sekmesini kilitler
• Kabul edilebilir sonuç almak için gereken minimum step sayısı 20'dir, ancak demo amacıyla 3 step de kullanılabilir

SSS

• protobuf parsing failed hatası

  • DevTools'ta Application → Storage bölümüne gidip "Clear site data" çalıştırın

• sbox_fatal_memory_exceeded hatası

  • Bu, SD çalıştırmak için gerekli RAM'in yetersiz olduğu anlamına gelir; sekmeyi veya tarayıcıyı yeniden yüklemeyi deneyin

• Uygulama yöntemi

  • Python'daki StableDiffusionPipeline JS'ye taşındı
  • onnxruntime ile emscripten+binaryen (WebAssembly derleyici araç zinciri) yamalanarak 4GB üstü bellek ayırma ve kullanım desteği sağlandı
  • İlgili pull request'ler sürümlere yansıdığında herkes tarayıcıda 4GB'tan fazla bellek kullanan kodu derleyip çalıştırabilecek

• Yavaşlığın nedeni

  • Henüz çoklu iş parçacığı desteği yok, bu yüzden yalnızca tek bir CPU çekirdeği kullanılıyor
  • SharedArrayBuffer üzerinden 64 bit bellek, WebAssembly.Memory constructor aracılığıyla oluşturulamıyor
  • "memory64" bayrağı için bir spesifikasyon değişikliği önerildi; kabul edildikten sonra V8 motoru yamalanarak destek eklenecek

• GPU'da çalıştırma durumu

  • GPU'da çalışıyor, ancak onnxruntime'ın WebGPU desteği henüz erken aşamada olduğu için birçok işlem uygulanmamış durumda
  • Veriler JS üzerinden sürekli olarak CPU ile taşınıyor
  • Çoğu işlem için JS kernel'leri implemente edildiğinde hız büyük ölçüde artabilir

• Yerelde çalıştırma mümkün mü

  • Evet; ilgili sayfanın kodu stable-diffusion-webgpu-minimal deposunda sağlanıyor

• transformers.js ile büyük LLM çalıştırmak mümkün mü

  • Yamalanmış onnxruntime paketi (@aislamov/onnxruntime-web64) kullanılabilir, ancak her durumda çalışacağı garanti edilmez
  • Bu build 8GB bellekle sınırlıdır, bu nedenle yaklaşık 4GB ağırlığa kadar yükleme yapılabilir

• onnxruntime deposuna pull request planı

  • Planlanıyor; daha önce node.js binding'lerine GPU acceleration eklenmesinin ardından bu ikinci çalışma olacak

[GN⁺]

Hacker News yorumları

• MLC ekibi bunu daha mart ayında çalıştırmıştı: https://github.com/mlc-ai/web-stable-diffusion
  Daha etkileyici olan, sonrasında birkaç büyük dil modeli desteği de eklemiş olmaları: https://webllm.mlc.ai/

  • Gerçekten etkileyici ve performansı da çok daha iyi görünüyor. Ben, önceden değişiklik yapmadan rastgele ONNX modellerini çalıştıran başka bir yaklaşımı izliyordum

• “3,5 GB yüklüyor ve 8 GB RAM kullanıyor”
  Tarayıcının bu noktaya gelmesi ilginç. Web, işletim sistemini yuttu

  • Bu eleştiriyi pek anlamıyorum. Tarayıcı üzerinden kendi bilgisayarımda Stable Diffusion çalıştırıyorum; indirmeden ve RAM’e almadan bunu nasıl yapabilirdi ki?
    Tarayıcı olmadan doğrudan indirip çalıştırsanız da indirme boyutu ve RAM kullanımı neredeyse aynı olurdu
  • Web, Java’nın ilk öncülünü yuttu
  • Bu yüzden işletim sisteminin aslında tarayıcı olduğu dizüstü bilgisayarlar satan bir şirket var; akıllı TV’lerde de aynısını yapan bir şirket var
  • Bant genişliği arttıkça ve web sandbox’ı olgunlaştıkça, indirme·kurma·bakım yerine doğrudan kullanılan uygulamalara evrildiğini görmek ilginç. Bazıları bundan hoşlanmayacak ama geniş kitleler için birçok kapı açıyor
  • Artık WebGPU’nun gerçek zamanlı etkileşimli WebXR sayfaları, akış halinde çok oyunculu durum yönetimi, çok sayıda draw call gibi durumların dışında da bu tür işler için yararlı olduğunu düşünüyorum.
    Bu deneyimi tarayıcıyla sunmanın işleri basitleştiren tarafları var; Stable Diffusion çalıştırmak için bundan daha kolay bir yol da yok gibi görünüyor, bu yüzden böyle projelerin desteklenmeye devam etmesini isterim

• Experimental WebAssembly ve Experimental WebAssembly JavaScript Promise Integration (JSPI) bayrakları açık olan en yeni Chrome gerekiyormuş; o halde Firefox’a gelmesini bekleyeceğim

  • En azından Firefox artık CSS scrollbar stillendirmesine izin veriyor, bu iyi bir şey
  • Brave’de istenen chrome:flags ayarlarını açtım ama yine de çalışmadı. M1 Mac’lerime Chrome indirmiş değilim; şimdi başlamaya da niyetim yok
  • Canary’de açmayı denedim ama yine de çalıştıramadım
  • Chrome’da denemeye bile yanaşmıyor musun?
  • İkinci bayrak ne yapıyor?

• Burada da zaten uygulanmış: https://websd.mlc.ai/#text-to-image-generation-demo
  MLC, Apache TVM ile WebGPU kod üretimi ve otomatik ayarlama yapıyor; performansı da oldukça iyi

• MLC-AI’nin Stable Diffusion’ını web siteme özel arka plan üreticisi olarak entegre ettim. Model verileri Hugging Face’ten geliyor
  https://dustinbrett.com/

  • Bu kadar akıcı ve hızlı olduğunu görünce, telefondaki tüm uygulamaların birkaç ekran göstermek ve birkaç API çağrısı göndermek için 200 MB istemesi üzücü geliyor
  • iPhone 12 mini’de sorunsuz yüklendi ve telefon aşırı ısınmadı. Gerçekten etkileyici
  • Web sitesi etkileyici ve her şey çok akıcı çalışıyor. Sonunda Doom’u gereğinden fazla uzun süre oynadım

• CPU’ya bağlı işler için ana iş parçacığının donmaması adına service worker kullanmayı düşünmek mantıklı olabilir

• Sırada WebGPU chatbot mu var? Tarayıcıda kendi GPU’m ile ChatGPT tarzı sohbet mi?

  • Aslında zaten mümkün. Bazı sınırlamalar var
    Büyük dil modelleri, model iyileştikçe daha çok RAM/VRAM tükettiği için WebGPU’da özellikle zorlu
  • https://webllm.mlc.ai/
    Zaten uygulanmış durumda

• Merakımdan soruyorum, bu ne için kullanılır?
  Bildiğim kadarıyla görüntüyü sunucuda değil tarayıcıda üretiyor. Aklıma gelen tek şey, bir görüntüyü değiştirmek ya da yeniden üretmek için sayfayı yenilemeye gerek kalmaması.
  Bu, görsel tasarımı gerçek zamanlı değişen web sitelerini mümkün kılabilir demek olabilir; işlevsel olarak da anlamlı biçimde değişebiliyorsa epey havalı olurdu. Yine de Stable Diffusion’ın bir sitenin UI bileşenlerini veya görsel öğelerini üretmede ne kadar yararlı olacağından emin değilim

  • Çok sayıda görüntü üretmenin maliyeti yüksek olduğu için yararlı. Hesaplama maliyetini istemciye taşımış oluyorsunuz
  • Kullanım amacı, kendi bilgisayarınızda kolayca çalıştırmak. Programcı olmanız da gerekmez, uygulama kurmanız da
  • Modeli tamamen yerelde çalıştırırsanız gizlilik büyük bir avantajdır
    Hassas prompt’lar uzaktaki birilerine sızmaz

• WebGPU’daki performans ile native çalıştırma performansını karşılaştıran ölçütler var mı?

  • UNET WebGPU’da yaklaşık 1 dakika 10 saniye, CPU’da tek iş parçacığında ise yaklaşık 1 dakika sürüyor. VAE CPU’da 2 dakika, GPU’da ise yaklaşık 10 saniye sürüyor.
    VAE için GPU işlemlerinin çoğu zaten uygulanmış, ama UNET için öyle değil gibi. İkincisinde tarayıcı her adımda verileri sürekli GPU ile CPU arasında taşıyor

• Yeterince hızlıysa kişisel kullanım için görüntüleri yerelde render etmekte kullanılabilir. Web sitesi yalnızca prompt’u iletir ve her kullanıcı için farklı görüntüler render edebilir.
  O noktada telif hakkı ne olur? Modelin kendisi mi telif hakkına tabidir, yoksa sistem mi çöker?

  • Bu olasılık ilginç ama şu an böyle bir dünyadan çok uzağız. Bu tartışmanın başka yerlerinde de bunun 8 GB RAM’i etkin şekilde kullandığı söyleniyor.
    Ayrıca birçok web tasarımcısının, modelin prompt’u yanlış yorumlaması, yanlış sayıda parmak içeren bozuk sonuçlar üretmesi ya da istenmeyen bağlamlarda cinsel/şiddet içerikli şeyleri kazara oluşturması riskini kabul edeceğini sanmıyorum.
    Günümüzde birçok üretici görüntü modelinde genellikle ondan fazla sonuç arasından en iyisi seçilir; atılanların geri kalanı gerçekten oldukça kötü olabilir.
    Web sitelerini rutin olarak dinamik biçimde illüstre etmek için modelin kalitesi ve öngörülebilirliği bugünkünden çok daha yüksek olmalı.
    Yine de bunun asla o noktaya gelemeyeceğini söylemek istemem. Son modeller, birkaç yıl önce hayal bile edilemez sanılan şeyleri şimdiden yapıyor. https://xkcd.com/1425/ ile karşılaştırınca, genç okurlara o şakanın arka planındaki problemi açıklamak bile zor olabilir!