先月買った自身初購入のミニPCでAMD Ryzen AIを積んだRyzen 7 8845HS搭載AOOSTAR GEM12 Pro MAXにプリインストール・クリーンインストール済みWindows 11 Proとは別にマルチブート、AMDXDNA(Ryzen AI NPU)が実装されたLinuxカーネル6.14な25.04ベータを入れ、USB SSDブートしていたUbuntuにamdgpu対応のStable Diffusion WebUIをインストールして使ってみた話。
Stable Diffusionとは、ミュンヘン大学CompVisグループにより開発され、Runway、Stability AI社を加えた3グループにより2022年に公開されたテキストから画像を生成するAI機能をもつText2Imageなオープンソースソフトウェア。
以後、Stable Diffsion 1.1、...、1.5、2.0、2.1、3.0、XL(SDXL)、XL Turbo、3.5など留まることなく、3.5だけでもMedium、Large、Large Turboなどがあり、その進化に伴い、Text2Image(txt2image)だけでなく、Image2Image(img2img)など機能追加され、常に進化している、いわゆる生成AI技術であり、生成AIソフトウェア。
また、Stability AI社に限っていえば、単一画像からの高品質3Dオブジェクト生成するStable Zero 123、音楽や音響効果を生成するStable Audio、AIアシスタントなどと呼ばれることもあるLLM/Large Language Model/大規模言語モデルであるStable Beluga、マルチバイリンガルな言語モデルStable LM系、日本語専用言語モデルJapanese Stable LM2 1.6B、プログラムコードやクエリの作成補助やコード生成するStable Code系などもあります。
そんなStable Diffusionは、Deep Generative Neural Network/深層生成ニューラルネットワークの一種であるLatent Diffusion Model/潜在拡散モデルから成っているとされます。
出典:Stable Diffusion by Wikipedia
3.5がリリースされた今でも人気が高いのが、SD1.5モデルとのこと。
理由はいろいろあるようですが、軽量・高速・リアリティ・少ないオプション(設定が容易)・CFG設定にも絡むにせよプロンプト次第で様々な画像を生成可能、Stable Diffusionの公開から3年足らずながら、時系列的、相対的に初期に近いバージョンゆえ、対応モデルもノウハウなど情報も豊富といった点がウケている模様。
こうした特徴もあって追加学習させ新たなモデルを生成する際のベースモデルとしてとか、クラウドではなく、さほど高性能でないPCでさえ、近年話題のローカルでAI(エッジAI)といったシーンにも都合よく、人気があるようです。
逆にSD1.5は、非現実的な画像生成は苦手でプロンプトでリアリティのない指定をしたとしても生成されるのは、現実的な範囲での画像となります(テクニックによってはできなくもないという噂も)。
例えば、SD1.5で「野球をしている猫」のような英文や単語の羅列をプロンプトに入れても、せいぜい「球場にいる猫の横に硬球が転がっている」ような画像が生成されるとか、そんなイメージ。
SDXLや3.0、3.5など、そうした描画にも長けたモデルを使うと複雑な設定をしなくても期待通り?「ユニフォームを着たバッターボックスに立つネコに投手のネコが投球している」といったような画像が生成されるのとは対象的。
とはいえ、より現実的にという面では、SD1.5がダントツなんだとか。
また、初期のSD1.5では、プロンプトには単語もしくはワンフレーズ区切りのみという制約があった模様、これが同じSD1.5でも後に改善され、後続モデルでもそうであるように英文も解釈されるようになり、より使い勝手が良くなったという面も。
比較のため、微調整は必要なものの、Linux上のStable Diffusion Web UI amdgpuでモデルとしてSDXL 1.0系+ポーズやスタイル系のLoraを併用してみたところ、プロンプトなど条件は、ほぼほぼ同じでデフォルトのAmuse 3.0(Windows)作に寄せて「ハットにサングラス、スーツに身を包んだ犬がパソコンを操作」的な微妙に人っぽくもあり、ほんの少し現実離れしたような画像も生成できました。
ただ、Amuseの方は、SD1.5ベースっぽい?
尤も前掲の生成画像は姿勢も同じようなのを選んだわけですが、非現実的と言うなら、明らかに、こっちですけどね。
AMD Ryzen 7 8845HS/Linux/SD Web UIなSDXL1.0系+Loraにおいてバッチカウント 4で同時に生成されたのが、他1枚、前掲写真右の1枚、そして、この2枚の4枚。
Stable Diffusion Web UIとは、Stable Diffusionの生成AIを使うにあたり、ブラウザを操作パネルとしたもの。
AUTOMATIC1111/stable-diffusion-webuiや、このフォークで高速化を施したというlllyasviel / stable-diffusion-webui-forge、NVIDIA/CUDAのみならず、AMD GPU/ROCmにも対応なlshqqytiger/stable-diffusion-webui-amdgpu、そしてForge版lshqqytiger / stable-diffusion-webui-amdgpu-forgeなどがあります。
GPU分野トップシェアなNVIDIAのGPUに対応している一方、快進撃を続け猛追するAMD製GPUに対応してくれているのが、stable diffusion webui amdgpu。
尚、AMDはじめ、外付けグラフィックボードではなく、チップ搭載のiGPU/Integrated GPUも増えており、このiGPUでもBIOSなどで明示的にVRAM設定できる機種もあれば、自動割当される機種もあり、後者で自動割当して欲しいところでされないといったことも起こり得る模様。
そうしたVRAM自動割当なiGPUにおいて、NVIDIAで言うところのCUDAにあたるAMD Radeon GPU用ROCm、そのROCm付きのPytorchは、VRAM以外のRAMを使わないようになっているらしく、Pytorchをいじることなく、VRAM割当を行えるよう動的に共有ライブラリを読み込ませる機能を持つforce-host-alloction-APU(allocationではなく、alloctionなのは、ご愛嬌かと)も併用するのが吉です。
自身のマシンもRAMは32GBですが、dmesgで見るとVRAMの初期割当は512MB、GTTは、15452Mと合計すると仕様的なVRAM割当可能な最大16GBと合致しているものの、もし、512MBで処理されてしまうと、15GBも割り当てられるメモリが残っているはずなのに、すぐに消耗してしまい、それ以上実行できないといった状態になると思われるので、ありがたい限りです。
AMD、Ryzen、Radeon搭載マシンでStable Diffusionを使うにあたり、必要となり得る環境と補足は次の通りです。
Ryzen AIソフトウェアというか、Ryzen AI NPUについては、Stable Diffusion Web UIで現状対応しているものはなさ気ですが、何れにせよ、Ryzen AIマシンには必須。
あとPythonはじめ、各種バージョンは、かなり重要。
必要なツールやアプリは、リンク付きなものは、そこにインストール方法が掲載されており、それ以外はディストロのパッケージマネージャでインストールできます。
ROCmの導入は、amdgpu-installの方が、上書き・更新も含め、手軽で簡単・便利ですが、--usecaseとかオプション値に、その組み合わせとして何を指定するのが正解なのか、よりよいのかとか、ありえない組み合わせもあるのかとか、--no-dkmsとした場合、後でapt install amdgpu-dkmsする必要があるのかとか、そうした場合、何かしている時にdkmsに関する警告らしきものが表示されることがあるけど、どうすれば回避できるのかとか、公式ドキュメントを見ても理解するのが難しい...と自身は未だに感じています。
注意事項的なものは、覚えておかないと自身のようにハマり、おそらく、何度も何度もやり直す羽目になるでしょう。
リアルタイムな状態・ステータスの確認はできた方が幸せになれるはずです。(CPU/GPU/iGPU/NPUを可視化する on Linux Ryzen 7 8845HS)
Install PyTorch for ROCmには、ROCm用Pytorchのインストールと後段に[Verify PyTorch installation]としてPyTorch環境が、また、ROCmによりGPU|iGPUが正常に認識されているか否かの確認方法が載っています。
その確認方法と自身のAMD Ryzen 7 8845HS/AMD Radeon Graphics 780M搭載ミニPCにおける実行結果がこれ。
後段にpip3とcondaのTorch環境が載ってますが、後者は残骸、自身は前者を使っているのでROCm対応torchのバージョンは、2.8.0.dev20250418+rocm6.4(なのにtorchvisionが0.22.0.dev20250418+rocm6.3とrocm6.3になってしまっているのはなんでだろう?)。
AMD Ryzenな今回は、stable-diffusion-webui-amdgpuをgit cloneします。
必要ならStable Diffusion用のパスを作って移動。
また、前後どちらでも良いものの、ここでは、pyenvを使うものとして、(まだ、なければ作成の上、)先に仮想環境に入っておきます。
尚、AnacondaやMinicondaなどcondaをインストール済みな場合、デフォルトでcondaのbase環境に入っていたりするのでconda info -eして確認、baseにいたら、conda deactivateしておきましょう。
そうしないとconda baseのPythonバージョンになってしまったりするので。
rocmが正常にインストールできたか確認できるスクリプトをgithubで公開してくれている方がいらっしゃるので、ありがたく使わせて頂くと良いでしょう。
実行してバッチリだとこんな感じの心地よい出力を得ることができます。
本来は、gfx1103なRyzen 7 8845HSですが、gfx1100となっているのは、~/.bashrcでexport HSA_OVERRIDE_GFX_VERSION=11.0.0してあるから。(ん?もしや11.0.3でもいける?あ、いけた)
そして後片付け。
冒頭リンクにあるとおり、webui.shだけダウンロードして、これの実行でgit cloneもする方法もありますが、ここでは、素直にgithubリポジトリをgit clone。
Web UIの実行に移る前にAMD Radeon iGPUな場合、前述の通り、確実にVRAMへの自動割当が行われるようにforce-host-alloction-APUもgit cloneしておきます。
ここで、まず、共有ライブラリlibforcegttalloc.soを生成します。
その名も「強制GTTメモリ割り当てライブラリ」といったものになっています。
尚、環境が整っていれば、hipccコマンドもあるかと思います。
ここで作ったlibforcegttalloc.soと/usr/lib64あたりにあるはずの(なければ後述のようにソフトリンクする、ビルドする等した)libMIOpen.so.1.0を環境変数LD_PRELOADに設定するとVRAM自動割当されないAMD Radeon iGPUなマシンでも必要に応じてVRAMに上限までの範囲内でメモリ割当してくれるようになります。
また、このツールでは、test/以下にプロンプト、出力ファイル名、デバイスの順に3つの引数を渡すことでStable Diffusionによる生成画像を出力してくれるpythonスクリプトdiffusion.pyも同梱されているので予行演習として試しておくと安心です。
尚、このとき、LD_PRELOADとHSA_OVERRIDE_GFX_VERSION(後者はRyzen 7 8845HSでは、=11.0.0等)設定を前置します。
ここで、自身の場合、複数のライブラリが不足しており、エラーの度に順次、探すとROCmがインストールされた/opt/rocm6.4/libにはあったので、そこから結果13件ほどソフトリンクを張る必要がありました。
LD_LIBRARY_PATHに/opt/rocm6.4/libを設定した方が早かったか...。
環境が整ったところでtest/diffusion.pyを実行するとaccelerateがないよ警告だかエラー(大勢に影響ないワーニングということなのか?出力を遡らないとその存在に気づけない)が出るかも、その場合は、pip installしてdiffusion.pyを実行。
無事完了すれば、カレントディレクトリにoutput.jpgが作成されており、デフォルトのプロンプトで、それが、宇宙飛行士の画像なら、正常にStable Diffusionで生成された画像ということで正常です。
自身はここで、はしゃいで、もう1つ違うプロンプトで違う画像も出力してみたって噂も。
更にstable-diffusion-webui-amdgpuを起動する前準備として必須パッケージのインストール。
前述の通り、URLのrocmバージョンも大事、各所と合わせる必要あり。
requirements.txtを2度インストールしているのは、このファイルの動きに疎い自身が、こうするとうまく調整してくれるものと思い込んでいるからですが、あってますかね?
情報によっては、最初の1度だけpip install -r requirements.txtしたあと、pip uninstall torchしてURL指定の上、torch/torchvision/torch audioをインストールしていることも。(こっちが正解?)
ちなみに自身は、何度かやってみた中、以前はできていたのですが、最終的にtorchaudioを入れるとエラーになったので単にこれを外して凌いでしまいましたが、なんでだったんでしょ?
名前からしてText to Speechとかでは必要ですよねtorchaudio、そうならゆくゆくは使ってみたいんですけどね、といってもSD Web UIには見当たらない気がしますが...。
というわけでstable-diffusion-webui-amdgpuに移動していよいよStable Diffusion Web UIを起動します。
尚、LD_PRELOAD、COMMANDLINE_ARGS、HSA_OVERRIDE_GFX_VERSIONも、webui_user.shなどで別途設定済みであれば、コマンドライン上では不要、[./webui.sh]だけでいけます。
(Linuxで)TCMallocを使う場合、google-perftools(か、tcmallocだったか、librust-tcmalloc-*的なものはあって内1つはインストール済みも指摘されたものはubuntuリポジトリにはなかった、もう1つの候補の名称、失念)をapt installする必要があるかと。
あと、次のような場合、webui.shの編集が必要になります。
結果、ブラウザや既に開いていればブラウザタブにStable DiffusionのWeb UI(127.0.0.1:7860/localhost:7860)が自動的に表示されます。
尚、自身は、後でstable-diffusion-webui-amdgpu-forge(Forge版)に気づき、追加インストール、requirements.txtはなく、requirements_version.txtのみ、webui-user.sh、webui.shともにForgeじゃない方のオリジナルと同一だったので、じゃない方から編集済みのwebui-user.sh、webui.shをForge版にコピー。
これでwebui.shは起動したものの、なぜか、--use-cpu allフラグ・オプションを付けても尚、txt2imgのgenerateボタンを押してもすぐに戻ってしまう現象が...というわけでForgeでの画像生成は、今のところできていません。
というか、Stable Diffusion Web UIを入れてみようと思ってから、実際に使えるまでの道のり、結構、壁もあって時間がかかりましたが、そういう話ネットには、ほとんどなく、あっさりできました的な情報ばかりな気がするのは、なぜ?
Stable Diffusion Web UI(127.0.0.1:7860/localhost:7860 可視部のスクショ)。
起動直後のStable Diffusion Web UI(127.0.0.1:7860/localhost:7860 全画面スクショ)でデフォルトのcheckpointとtxt2imgタブが選択された状態で表示されます。
画面左上が、そのcheckpointと言われるモデル選択メニュー、デフォルトでは[v1-5-pruned-emaonly.safetensors[6ce0161689]]となっており、要約してみると「SD1.5をスリム化及び品質と安定性を確保したHugging Face社開発の(従前Pytorchで使われていた.pthや.ptといったpickleフォーマット)より安全性が高いモデル」といった感じかと。
次の段は、機能別とも言えるタブで左からテキストから画像生成[txt2img]、画像から画像生成[img2img]、アップスケール他[Extras]、生成画像のパラメータ確認と他機能への送信[PNG Info]、複数のチェックポイントを統合、新たなモデルを生成する[Checkpoint Merger]、モデルを訓練する[Train]、設定画面[Settings]、拡張機能の管理[Extensions]。
この内、txt2imgのみ構成に触れると、テキスト入力欄として[(ポジティブ)プロンプト]/[ネガティブプロンプト]、右に[Generate|生成]ボタン、その下に左から[パラメータ読み込み]、[パラメータ削除]、[パラメータ適用]ボタン、下が[保存済みパラメータ選択]メニュー、その右が[編集]ボタン。
下に行くといくつかタブが並んでますが、[Generation]にだけ触れると左ペインが設定、右ペインが生成画像表示エリアと各種ボタン、[サンプリングメソッド|サンプリング手法]選択(生成画像の雰囲気が変化)、[スケジュールタイプ]メニュー、主に数値とスライダなどで設定できる[サンプリングステップ数](ノイズ除去行程数/高いほど精度向上も時間はかかる)、[Hires.fix]と[Rfiner]開閉ボタン、[生成画像サイズ]、[バッチカウント|生成画像数]、[バッチサイズ](データセット分割時の1つ分のサイズ)、[CFGスケール](プロンプト忠実度の程度/高過ぎれば生成画像精度が落ちるケースも)、[シード値](乱数で使用)、[スクリプト]。
前述の通り、SD1.5は、そのリアルさが人気の理由の1つですが、奇抜や奇想天外、想像を・人知を超える画像というわけではなく、より現実世界に近いといった意味のリアルさであり、もちろん前掲のネコのように写真並み以上の画像も生成してくれますが、pencilやoil painting、water paintingなどのフレーズも入れれば、鉛筆画、油絵風、水彩画風など画風を変えることもできます。
ただ、この時、「油絵風」にしたいのが、生成する画像全体なのか、リアルな部屋の壁に掛かっている絵を指すのかなど表現として受け取り方という点だけからしても揺らぎがあるので、バッチカウントは、最低でも3や4(3パターンか4パターン)にしないと期待した画像を取得するのは難しくなることがあります。
このスクショは、油絵風(oil painting)をポジティブプロンプトの1つとして指定、更にバッチカウント4として生成される画像は4枚、これとは別にこれらが合成された画像も生成され、その合成画像1枚を選択した様子ですが、4枚中、油絵風は1枚、他の3枚中1枚は、モニタ上の油絵、残る2枚は壁掛けの額に入った油絵といった結果となっています。
バッチカウント1だと、むしろ、写真のようにしか見えず、どこか一部でも油絵になっているのかどうかも判別できないほど微妙だったため、バッチサイズを増やして試すことにした次第。
仮にバッチカウント1でもCFGスケールの値によっては、油絵風になったかもしれませんが。
また、ポジティブプロンプトのベースとして[masterpiece, best quality, high quality, ultra detailed]、(人が対象なら)ネガティブプロンプトのベースとして[worst quality, low quality, bad anatomy, bad hands]を入れると精度が高くなる傾向があるようです。
更に描いて欲しい内容に応じて特にネガティブプロンプトのベース、それ自体を増やす必要が出てくるケースもあるでしょう。
あと、生成画像の縦横サイズ指定ですが、「モデルが学習したサイズ」か、整数倍した数ならうまく生成できる一方、1/2とかだと期待した通りにならないので注意。
軽量で早くできるだろうと思い込んで、あれ?サイズ以外、何も設定変えてないのに急に劣化した...なにこれ、と思ったら、サイズを何れも半分(512x512を256x256)にしたことが原因で、気づくまでに、だいぶ時間を浪費しました...。
ただ、実は、今回、Web UIの起動においてCOMMANDLINE_ARGSに[--use-cpu all]を指定しています。
これを指定しなくても起動自体はできるのですが、txt2imgの[Generate]ボタンが効かない(クリックはできるも一瞬でボタンが戻ってしまう)ため。
どこかでStable Diffusion Web UIにおいてiGPUの場合は、--use-cpuフラグを使うみたいな記述を見かけたことがあったような、なかったような...記憶は曖昧。
とは言え、[--use-cpu all]指定していても実際のところ、iGPUが機能している様子は、CoreCtrl、nvtop、rocm-smiでも画像生成中のみならず、Stable Diffusionの起動時も、確認できている状況。
今回使用しているAMD Ryzen 7 8845HS/Hawk PointのiGPUが機能しているのは、Stable Diffusion Web UIに限らず、INT8は論外っぽく、Ryzen 7 8845HSでは厳しそうなComfyでも...、CPUオンリー版でしか使えなかったDocker版LocalAIでも然り。
一方でiGPUで処理できれば、CPUより高速なはず?512x512、ステップ数20、バッチカウント1、seed -1で1分前後はかかるというのは、CPUで処理されてる?iGPUならこんなもの?というのが判断出来かねている状況。
と言ってもamd / RyzenAI-SW Tutorialを一通りやってみると必ずしもCPUよりiGPUが高速とは限らず、むしろCPUの方が高速な方が多いくらいかも?ただ、CPUで処理する分をiGPU(とかNPU)で処理すれば、その分、CPU負荷が低減して並行・並列処理ができるのがメリット?ということなら速さは問題ではないのでしょうが。
SDで[--use-cpu all]を指定しないと正常機能しないけど、iGPUで処理できてるってことでよい?別途、iGPU用フラグがあるわけじゃないよね?
この点さえスッキリすれば、仮に生成時間が今と同程度だったとしてもLinuxでの生成画像AIは、stable-diffusion-webui-amdgpu一択で十分と思えるのですが。
尤も今はWindows版しかないAmuseは、AMD自体ではないものの、Ryzen AI(NPU)に最適化する為に作られたAMDパートナー製なので何れLinux版もリリースされるだろうという期待もありますが。
そのあたりを確認してみたくて、--use-rocmフラグがあるというSD.Nextを使うべく、Stability Matrix経由でインストール、既に単独で入れていたものと共用しようとモデルやLoraはソフトリンクを張り、(Loraはなぜか効かない模様も)使用して起動。
ちなみにインストールが簡単というStability Matrixの謳い文句の1つとは裏腹に直感的とは言い難い使い勝手で起動して普通に使えるようにするまで結構時間がかかりました...。
SD.Nextは、SD.Nextで実行中の状態がわかりづらい...SD.Next下部やStability Matrix画面もステータスとなる文字列自体の更新も時間がかかると、ホントに動いているのか?と...。
さておき、SD.Nextで専用項目のある[--use-rocm]をONにしつつも、専用項目はないので[Extra Launch Argments]経由ですが、やはり、[--use-cpu all]フラグを付けないと生成(Generate)ボタンが効かなくなる事象が発生するのは、SD Web UI amdgpu同様。
一方、a cute catというプロンプトはじめ画像中央下段にあるように設定してみると(VRAM最大16GB、デフォルトは512MBな使用マシンにおいて)[GPU 7140 MB 46%]という表記が、同じ条件でもう1度やっても、おかしいのか、たまたまなのか、必然なのか同じ数値。
GPU使用量の表示があるということは、さすが、--use-rocmオプションがあるだけのことはあり、SD.Nextでは、iGPUだけで、もしくは、CPUとiGPUを併用して処理してくれている...と期待したい一方、
なぜか、SSD上にある同じモデルを使ったプロンプトなど設定もほぼほぼ同一な素のSD Web UI amdgpuよりもStability Matrix/SD.Nextの方が、2〜3倍時間がかかる感じ(画像情報の設定だと前者が1分ちょっとで済むところが、後者だと3〜4分ほど)。
これってSD.Nextの生成画像情報には、GPUの表記とともに生々しい数値やパーセンテージはありつつも、実はiGPUを使えていないのか...。
とは言え、何れにせよ、Stable Diffusion系は、GPU|iGPUを使う場合でも、いやAMDに限っては?--cpu allフラグ付きで--use-rocmオプションのないstable-diffusion-webui(-amdgpu)、どっちのオプションも取ることができるSD.Nextも、実際には、GPU|iGPU「を」、もしくは、GPU|iGPU「も」使っている、いや、後者は使おうとはしているが使えていない?ってこと?...って、結局、どういうこと...?
というわけで同じ条件でもう1度、今度はCoreCtrlを眺めつつ...と思ったら、CPUやGPUで干渉しているのか、稀にブラックスクリーンに成った直後に復帰したことが1度だけあったものの、再ログイン後、amdgpuがactiveになったままなのは救いも、それ以外は何度やっても強制再ログイン状態に...、軽量なCLIならばとnvtopを眺めつつなら実行でき、やはり、GPUも使っていることになっている。
それと気づいてみれば、nvtopだとforce-host-alloction-APUの恩恵を受けられないのか?右上段の[MEM]は、512MBがMax、一方、GPUのステータスバーやグラフ凡例の[GPU0 %]も50%やら60%やらそれ以上も示す感じ...。
ただ、うろ覚えもforce-host-alloction-APUは、デフォルトで割当のVRAMが不足する場合、CPUから融通してもらうとか何とか...あったような...とするとG+CであってもVRAMであることに違いはないから、そこに齟齬はないのか。
これは、朗報と言うべきか、迷宮に放り込まれたというべきか...。