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)" フラグを有効化する必要あり
  • Prompt、Negative Prompt、inference step数を入力して画像を生成し、モデルファイルはキャッシュされるため毎回再ダウンロードする必要なし
  • 4GBを超えるメモリ割り当てのために onnxruntime、emscripten、binaryen をパッチし、Python の StableDiffusionPipeline を JS に移植した成果物
  • マルチスレッド未対応と WebGPU 演算未実装などにより現時点では速度は遅いが、今後 JS カーネル実装と memory64 対応により改善の可能性を示す

実行要件

  • 最新の Chrome ブラウザーで Experimental WebAssembly および Experimental WebAssembly JavaScript Promise Integration (JSPI) フラグの有効化が必要
  • Model files はキャッシュされるため、再訪時に再ダウンロードは不要

入力と動作方式

  • 入力項目として Prompt、Negative Prompt、inference step数を提供
    • PNDM Scheduler を使用するため、実際の step は入力値 i ではなく i+1 として処理
  • 各 step には約1分かかり、画像生成のための VAE decoder 実行に追加で約10秒かかる
  • DevTools を開いた状態では全体の速度が約2倍遅くなる
  • UNET は CPU でのみ実行され、GPU より10%速く、GPU では正しい結果が出ずブラウザータブが停止する
  • 許容可能な結果を得るための最小 step数は20で、デモ目的なら3 stepでも可

FAQ

  • protobuf parsing failed エラー

    • DevTools で Application → Storage に移動後、"Clear site data" を実行

  • sbox_fatal_memory_exceeded エラー

    • SD 実行に必要な RAM 不足の状態で、タブまたはブラウザーの再読み込みで解決を試す

  • 実装方式

    • Python の StableDiffusionPipeline を JS に移植
    • onnxruntime と emscripten+binaryen（WebAssembly コンパイラツールチェーン）をパッチして、4GB超のメモリ割り当てと使用をサポート
    • 関連 pull request がリリースに反映されれば、誰でもブラウザーで4GB超のメモリを使うコードをコンパイル・実行可能

  • 速度が遅い原因

    • まだ マルチスレッド未対応のため CPU コアを1つしか使わない
    • WebAssembly.Memory コンストラクターによる SharedArrayBuffer では64ビットメモリを生成できない
    • "memory64" フラグ の仕様変更を提案しており、採用後に V8 エンジンをパッチして対応予定

  • GPU 実行可否

    • GPU で実行はされるが、onnxruntime の WebGPU は初期段階のため多くの演算が未実装
    • データが JS を介して CPU と継続的に転送される
    • 大半の演算に JS カーネルが実装されれば速度は大幅に向上する可能性がある

  • ローカル実行可否

    • 可能であり、該当ページのコードは stable-diffusion-webgpu-minimal リポジトリで提供

  • transformers.js で大規模 LLM を実行可能か

    • パッチ済み onnxruntime パッケージ（@aislamov/onnxruntime-web64）を使用できるが、すべてのケースでの動作は保証されない
    • このビルドは8GBメモリに制限されており、約4GBの重みまでロード可能

  • onnxruntime リポジトリの pull request 計画

    • 進行予定であり、以前 node.js バインディングに GPU アクセラレーション を追加したのに続く2件目の作業

関連記事

1件のコメント

 
GN⁺ 2023-07-19
Hacker News のコメント

  • MLC チームはすでに3月にこれを動かしていました: https://github.com/mlc-ai/web-stable-diffusion
    さらに印象的なのは、その後複数の大規模言語モデルのサポートまで追加した点です: https://webllm.mlc.ai/

    • 本当に印象的で、性能もずっと良さそうです。私は事前の修正なしで任意の ONNX モデルを実行する別のアプローチを追っていました

  • 「3.5GB をロードし、RAM を 8GB 使用します」
    ブラウザがここまで来たのは興味深いですね。Web が OSを飲み込んでしまいました

    • この批判はよく分かりません。ブラウザ経由で自分のコンピュータ上で Stable Diffusion を実行するわけで、ダウンロードして RAM に載せずにどうやるのでしょう？
      ブラウザなしで直接ダウンロードして実行しても、ダウンロードサイズと RAM 使用量はほぼ同じはずです
    • Web が Java の当初の前提を飲み込んでしまいました
    • だから、OS がそのままブラウザであるノート PC を売っている会社があり、スマート TV でも同じことをしている会社があるわけです
    • 帯域幅が増え、Web サンドボックスが成熟するにつれて、ダウンロード・インストール・保守の代わりに、ただ使うだけのアプリへ進化していく様子を見るのは興味深いです。嫌がる人もいるでしょうが、一般ユーザーには多くの扉を開いてくれます
    • WebGPU は、リアルタイムのインタラクティブな WebXR ページ、ストリーミングのマルチプレイヤー状態、多数のドローコールのような場合以外にも、こうした用途に有用だと思うようになりました。
      ブラウザでこうした体験を提供すると簡単になる面があり、Stable Diffusion を実行するのにこれ以上簡単な方法もなさそうなので、こういうプロジェクトが継続的に支援されるといいですね

  • Experimental WebAssembly と Experimental WebAssembly JavaScript Promise Integration (JSPI) フラグを有効にした最新の Chrome が必要だなんて、Firefox に入るまで待つしかなさそうです

    • 少なくとも Firefox は今では CSS スクロールバーのスタイリングを許可しているので、それは良いことです
    • Brave で指定された chrome:flags を有効にしましたが、それでも動きませんでした。M1 Mac には Chrome をダウンロードしたことがなく、今さら始めるつもりもありません
    • Canary で有効にしてみましたが、それでも動かせませんでした
    • Chrome では試す気すらないということですか？
    • 2つ目のフラグは何をするものですか？

  • ここにもすでに実装されています: https://websd.mlc.ai/#text-to-image-generation-demo
    MLC は Apache TVM で WebGPU コード生成と自動チューニングを行っていて、性能もかなり良いです

  • MLC-AI の Stable Diffusion を、自分の Web サイトにカスタム背景ジェネレーターとして統合しました。モデルデータは Hugging Face から取得しています
    https://dustinbrett.com/

    • これほど滑らかで速いものを見ると、スマホのあらゆるアプリが数画面を表示して API 呼び出しを数回送るだけで 200MB ずつ要求するのが悲しくなります
    • iPhone 12 mini で問題なく読み込め、スマホが過熱することもありませんでした。本当に印象的です
    • Web サイトが印象的で、すべてが非常に滑らかに動きます。結局、必要以上に長く Doom を遊んでしまいました

  • CPU に縛られる処理は、メインスレッドが止まらないようにサービスワーカーを使うことを検討してもよさそうです

  • 次は WebGPU チャットボットでしょうか？ ブラウザ上で自分の GPU を使って ChatGPT 風のチャットをするような？

    • すでにできます。いくつか制限があります
      大規模言語モデルは、良いモデルほど RAM/VRAM を多く使うので、WebGPU では特に難しいです
    • https://webllm.mlc.ai/
      すでに実装されています

  • 好奇心からですが、これは何に使うのでしょう？
    私が分かるのは、サーバーではなくブラウザで画像を生成するという点です。思い浮かぶのは、画像を変えたり新しく生成したりするためにページをリロードする必要がない、という程度です。
    そうなると、ビジュアルデザインがリアルタイムに変化する Web サイトが可能になるという意味かもしれませんし、機能面でも有意義に変わり得るならかなり面白そうです。ただ、Stable Diffusion がサイトの UI コンポーネントや視覚要素の生成にどれほど役立つのかはよく分かりません

    • 画像を大量生成するコストは高いので有用です。計算コストをクライアントへ移すわけです
    • 用途は、自分のコンピュータで簡単に実行することです。プログラマーである必要も、アプリケーションをインストールする必要もありません
    • 完全にローカルでモデルを実行すれば、プライバシーが大きな利点になります
      センシティブなプロンプトが遠隔地の誰かに漏れることはありません

  • WebGPU での性能とネイティブ実行の性能を比較した指標はありますか？

    • UNET は WebGPU で約1分10秒、CPU シングルスレッドでは1分ほどかかります。VAE は CPU で2分、GPU では約10秒かかります。
      VAE 用の GPU 演算はほとんどすでに実装されていますが、UNET 用はそうではないためのようです。後者の場合、ブラウザが各ステップごとに GPU と CPU の間でデータを投げ続けています

  • 十分に速ければ、個人用途で画像をローカルレンダリングするのに使えます。Web サイトはプロンプトだけを渡し、ユーザーごとに異なる画像をレンダリングすることもできます。
    その時点で著作権はどうなるのでしょう？ モデル自体が著作権の対象なのか、それとも体系が崩れるのでしょうか？

    • その可能性は興味深いですが、今はそういう世界からはかなり遠いです。このスレッドの他の場所でも、これが RAM 8GB を積極的に使うと書かれています。
      それに、多くの Web デザイナーは、モデルがプロンプトを誤解したり、指の本数がおかしい歪んだ結果を作ったり、意図しない文脈で性的・暴力的なコンテンツを偶然作ってしまったりするリスクを受け入れないと思います。
      今日の多くの生成画像モデルでは、通常は10枚以上の中から最良のものを選び、捨てる残りは実際かなりひどいことがあります。
      Web サイトを日常的に動的にイラスト化するには、モデルの品質と予測可能性が今よりはるかに高くなる必要があります。
      とはいえ、絶対にそこまで行けないと言いたいわけではありません。最近のモデルは、数年前なら想像もできないと思われていたことをすでに実現しています。https://xkcd.com/1425/ と比べると、若い読者にはそのジョークの背景にある問題を説明することすら難しいかもしれません！