Stable Diffusion WebGPU डेमो

 (islamov.ai)
1 पॉइंट द्वारा GN⁺ 2023-07-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ब्राउज़र में सीधे चलने वाला Stable Diffusion इमेज जनरेशन डेमो, जो अलग सर्वर के बिना WebGPU और WebAssembly पर आधारित होकर काम करता है
  • उपयोग के लिए नए Chrome में "Experimental WebAssembly" और "Experimental WebAssembly JavaScript Promise Integration (JSPI)" फ्लैग enable करने होंगे
  • Prompt, Negative Prompt और inference step की संख्या लेकर इमेज बनाता है, और मॉडल फाइलें cache होती हैं, इसलिए हर बार फिर से डाउनलोड करने की जरूरत नहीं
  • 4GB से अधिक memory allocation के लिए onnxruntime, emscripten, binaryen को patch किया गया और Python के StableDiffusionPipeline को JS में port किया गया
  • multithreading support न होने और WebGPU operations implement न होने जैसी वजहों से फिलहाल गति धीमी है, लेकिन आगे JS kernel implementation और memory64 support से सुधार की संभावना बताई गई है

चलाने की आवश्यकताएँ

  • नए Chrome browser में Experimental WebAssembly और Experimental WebAssembly JavaScript Promise Integration (JSPI) फ्लैग enable करने होंगे
  • Model files cache हो जाती हैं, इसलिए दोबारा visit करने पर उन्हें फिर से डाउनलोड करने की जरूरत नहीं

इनपुट और काम करने का तरीका

  • इनपुट के रूप में Prompt, Negative Prompt और inference step की संख्या दी जाती है
    • PNDM Scheduler के उपयोग के कारण असल step, इनपुट मान i से i+1 के रूप में process होता है
  • हर step में लगभग 1 मिनट लगता है, और image generation के लिए VAE decoder चलाने में अतिरिक्त लगभग 10 सेकंड लगते हैं
  • DevTools खुले रहने पर कुल गति लगभग 2 गुना धीमी हो जाती है
  • UNET केवल CPU पर चलता है; यह GPU से 10% तेज है और GPU पर सही result नहीं देता, जिससे browser tab hang हो जाता है
  • स्वीकार्य result पाने के लिए न्यूनतम step संख्या 20 है, लेकिन demo उद्देश्य के लिए 3 step भी ठीक हैं

FAQ

  • protobuf parsing failed error

    • DevTools में Application → Storage पर जाकर "Clear site data" चलाएँ

  • sbox_fatal_memory_exceeded error

    • यह SD चलाने के लिए जरूरी RAM की कमी की स्थिति है; tab या browser reload करके समाधान की कोशिश करें

  • implementation तरीका

    • Python के StableDiffusionPipeline को JS में port किया गया
    • onnxruntime और emscripten+binaryen (WebAssembly compiler toolchain) को patch करके 4GB से अधिक memory allocation और usage support किया गया
    • संबंधित pull request release में शामिल होने पर कोई भी browser में 4GB से अधिक memory इस्तेमाल करने वाला code compile और run कर सकेगा

  • धीमी गति के कारण

    • अभी multithreading support नहीं है, इसलिए केवल एक CPU core इस्तेमाल होता है
    • WebAssembly.Memory constructor के जरिए SharedArrayBuffer से 64-bit memory बनाना संभव नहीं
    • "memory64" फ्लैग specification में बदलाव प्रस्तावित किया गया है, और स्वीकार होने के बाद V8 engine को patch करके support देने की योजना है

  • GPU पर execution

    • GPU पर चलता है, लेकिन onnxruntime का WebGPU शुरुआती stage में है, इसलिए कई operations implement नहीं हुए हैं
    • data लगातार JS के जरिए CPU और GPU के बीच transfer होता रहता है
    • ज्यादातर operations के लिए JS kernels implement हो जाने पर गति में बड़ा सुधार संभव है

  • local execution संभव है या नहीं

    • संभव है, और इस page का code stable-diffusion-webgpu-minimal repository में उपलब्ध है

  • transformers.js से बड़े LLM चलाना संभव है या नहीं

    • patched onnxruntime package (@aislamov/onnxruntime-web64) इस्तेमाल किया जा सकता है, लेकिन हर case में काम करने की guarantee नहीं है
    • यह build 8GB memory तक सीमित है, इसलिए लगभग 4GB weights तक load कर सकता है

  • onnxruntime repository pull request की योजना

    • योजना में है, और यह पहले node.js bindings में GPU acceleration जोड़ने के बाद दूसरा काम होगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-19
Hacker News टिप्पणियाँ

  • MLC टीम ने इसे मार्च में ही चला लिया था: https://github.com/mlc-ai/web-stable-diffusion
    इससे भी ज़्यादा प्रभावशाली बात यह है कि बाद में large language models का सपोर्ट भी जोड़ दिया गया: https://webllm.mlc.ai/

    • यह सच में प्रभावशाली है, और performance भी काफी बेहतर लगती है. मैं एक अलग approach अपना रहा था जिसमें मनमाने ONNX models बिना पहले से बदलाव किए चलाए जा सकें

  • “3.5GB लोड करता है और 8GB RAM इस्तेमाल करता है”
    यह दिलचस्प है कि browser अब ऐसा हो गया है. वेब ने operating system को निगल लिया है

    • मुझे यह आलोचना ठीक से समझ नहीं आती. आप browser के ज़रिए अपने कंप्यूटर पर Stable Diffusion चला रहे हैं, तो इसे डाउनलोड किए बिना और RAM में लोड किए बिना यह कैसे होगा?
      browser के बिना सीधे डाउनलोड करके चलाएँ तब भी download size और RAM usage लगभग वही रहेगा
    • वेब ने Java की मूल परिकल्पना को निगल लिया है
    • इसलिए ऐसी कंपनियाँ हैं जो ऐसे laptop बेचती हैं जिनमें operating system ही browser है, और ऐसी ही कंपनियाँ smart TV पर भी यही काम करती हैं
    • bandwidth बढ़ने और web sandbox के mature होने के साथ, download·install·maintenance की जगह बस इस्तेमाल किए जाने वाले apps में इसका बदलना देखना दिलचस्प है. कुछ लोगों को यह पसंद नहीं आएगा, लेकिन आम लोगों के लिए यह बहुत से दरवाज़े खोलता है
    • अब लगता है कि WebGPU सिर्फ real-time interactive WebXR pages, streaming multiplayer state, या बहुत सारे draw calls जैसी चीज़ों के लिए ही नहीं, बल्कि ऐसे use case के लिए भी उपयोगी है.
      browser के ज़रिए ऐसा experience देना कुछ मामलों में चीज़ों को सरल बना देता है, और Stable Diffusion चलाने का इससे आसान तरीका भी नहीं दिखता, इसलिए अच्छा होगा अगर ऐसे projects को आगे भी support मिलता रहे

  • अगर इसके लिए Experimental WebAssembly और Experimental WebAssembly JavaScript Promise Integration (JSPI) flags ऑन किए हुए latest Chrome की ज़रूरत है, तो लगता है Firefox में आने तक इंतज़ार करना पड़ेगा

    • कम से कम Firefox अब CSS scrollbar styling की अनुमति देता है, तो यह अच्छी बात है
    • मैंने Brave में माँगे गए chrome:flags ऑन किए, लेकिन फिर भी यह नहीं चला. मैंने अपने M1 Mac पर कभी Chrome डाउनलोड नहीं किया, और अब शुरू करने का इरादा भी नहीं है
    • Canary में भी ऑन करके देखा, फिर भी इसे चला नहीं पाया
    • क्या मतलब आप Chrome में कोशिश भी नहीं करेंगे?
    • दूसरा flag करता क्या है?

  • यह यहाँ भी पहले से implement है: https://websd.mlc.ai/#text-to-image-generation-demo
    MLC Apache TVM के साथ WebGPU code generation और auto-tuning करता है, और performance भी काफ़ी ठीक है

  • मैंने MLC-AI के Stable Diffusion को अपनी website में custom background generator के रूप में integrate किया है. model data Hugging Face से लिया गया है
    https://dustinbrett.com/

    • इसे इतना smooth और fast चलते देखकर दुख होता है कि फोन के सारे apps कुछ screens दिखाने और कुछ API calls भेजने के लिए 200MB माँगते हैं
    • यह iPhone 12 mini पर अच्छी तरह लोड हुआ, और फोन ज़्यादा गरम भी नहीं हुआ. सच में प्रभावशाली है
    • website प्रभावशाली है और सब कुछ बहुत smooth तरीके से काम करता है. आखिरकार मैं Doom ज़रूरत से ज़्यादा देर तक खेलता रहा

  • जो काम CPU-bound हैं, उनके लिए service worker इस्तेमाल करने पर विचार किया जा सकता है ताकि main thread रुक न जाए

  • अगला क्या WebGPU chatbot है? browser में मेरे GPU पर ChatGPT जैसी chat?

    • यह पहले से संभव है. बस कुछ सीमाएँ हैं
      बड़े language models, model जितना बेहतर हो उतना ज़्यादा RAM/VRAM लेते हैं, इसलिए WebGPU पर यह खास तौर पर मुश्किल है
    • https://webllm.mlc.ai/
      यह पहले से implement है

  • जिज्ञासा से पूछ रहा हूँ, इसका इस्तेमाल कहाँ होता है?
    मेरी समझ में बस इतना है कि images server पर नहीं बल्कि browser में generate होती हैं. मेरे दिमाग में यही आता है कि image बदलने या नई image बनाने के लिए page refresh करने की ज़रूरत नहीं पड़ेगी.
    तो शायद इसका मतलब यह हो सकता है कि ऐसे websites बनें जिनका visual design real time में बदलता रहे, और अगर functionality भी अर्थपूर्ण ढंग से बदल सके तो यह काफ़ी बढ़िया होगा. लेकिन Stable Diffusion site के UI components या visual elements generate करने में कितना उपयोगी होगा, यह मुझे नहीं पता

    • यह उपयोगी है क्योंकि बड़ी मात्रा में images generate करने की cost महँगी होती है. यानी compute cost को client की तरफ़ शिफ्ट किया जा रहा है
    • इसका use case यह है कि इसे अपने कंप्यूटर पर आसानी से चलाया जा सके. programmer होना ज़रूरी नहीं, और application install करने की भी ज़रूरत नहीं
    • model को पूरी तरह local में चलाने पर privacy एक बड़ा फ़ायदा है
      sensitive prompts किसी दूर बैठे व्यक्ति तक लीक नहीं होते

  • WebGPU की performance और native execution performance की तुलना करने वाला कोई benchmark है?

    • UNET को WebGPU पर लगभग 1 मिनट 10 सेकंड लगते हैं, जबकि CPU single-thread पर लगभग 1 मिनट लगता है. VAE को CPU पर 2 मिनट लगते हैं, और GPU पर लगभग 10 सेकंड.
      शायद ऐसा इसलिए है क्योंकि VAE के लिए ज़्यादातर GPU compute पहले से implement है, लेकिन UNET के लिए नहीं. बाद वाले मामले में browser हर step पर GPU और CPU के बीच लगातार data इधर-उधर भेज रहा है

  • अगर यह काफ़ी तेज़ हो, तो इसे निजी उपयोग के लिए images को local render करने में इस्तेमाल किया जा सकता है. website सिर्फ prompt भेजे, और हर user के लिए अलग image render हो सकती है.
    उस स्थिति में copyright का क्या होगा? क्या model खुद copyright के दायरे में आएगा, या पूरा ढाँचा ही टूट जाएगा?

    • वह संभावना दिलचस्प है, लेकिन अभी हम ऐसी दुनिया से बहुत दूर हैं. इस thread में दूसरी जगह भी कहा गया है कि यह 8GB RAM को सक्रिय रूप से इस्तेमाल करता है.
      और मुझे नहीं लगता कि बहुत से web designers यह जोखिम स्वीकार करेंगे कि model prompt को गलत समझ ले, उँगलियों की गिनती गलत वाली विकृत images बना दे, या अनचाहे संदर्भ में यौन या हिंसक content गलती से बना दे.
      आज के बहुत से generated image models में आम तौर पर दस या उससे ज़्यादा images में से सबसे अच्छी चुननी पड़ती है, और जो बाकी reject होती हैं वे वास्तव में काफ़ी खराब हो सकती हैं.
      अगर websites को रोज़मर्रा में dynamically illustrate करना है, तो models की quality और predictability अभी से कहीं ज़्यादा बेहतर होनी चाहिए.
      फिर भी मैं यह नहीं कहना चाहता कि हम वहाँ कभी पहुँच ही नहीं सकते. हाल के models पहले ही वे काम कर रहे हैं जिन्हें कुछ साल पहले तक अकल्पनीय माना जाता था. https://xkcd.com/1425/ से तुलना करें, तो कम उम्र के पाठकों को शायद उस मज़ाक की पृष्ठभूमि समझाना भी मुश्किल हो सकता है!