ZLUDA別館2 ZLUDAannex2
このwikiには行数制限で最大1600行マデというのがあり、さらに総文字数制限もあって、仕方がないので、
ZLUDA別館1 ZLUDAannex1 に続き、
ZLUDA別館2 ZLUDAannex2 を作成した。
目次
関連ページ
ComfyUI-ZLUDA 高機能版
ComfyUI-manager, cuDNN/MIOpen, Triton, Flash Attentnion2, sage attention入りの高機能版。
ComfyUI-ZLUDAには従来からの通常版のほかに、高機能版がある。2025年の5月くらいに実装された。
高機能版にはいろいろと機能が追加されている。
当初は試行錯誤の状態であったが、2025年の7月終盤から8月にかけていろいろと手が加えられ、定まってきたようだ、
と思ったら、2025年8月中旬に 新HIP 6.4.2 が公開されてまた試行錯誤に戻っている。
なのでタイミングが悪いとインストールに失敗する。
#ComfyUI-ZLUDAでは、動くのを確認してからgithubを更新しているのではなく、 #確認するつもりがないものやこれから試す内容の変更をgithubでしているため。 #一般的にはそういう更新はdevブランチでおこない、うまく動くのを確認したのち #それをmain/masterブランチに反映させるのだが、ComfyUI-ZLUDAではなにもかも #masterブランチで行っている。 #この更新スタイルはreForgeもそう。reForgeはmainブランチのほかにdevなど #ブランチが多数あるが、mainが実質devブランチ。 #なのでmainなのに動かなくなることがしょっちゅうで、更新履歴にrevertがとても多い。 #つまり、まぁそんなものだ。
なお、高機能版は機能的には通常版の上位互換なのだけれども、
実際に使って比べてみると必ずしもそうではないですはい。
現在(2025年8月)のComfyUI-ZLUDAにはインストール用batファイルが3つある。
install-legacy.bat 通常版、旧版。以前はinstall.batだったがリネームされた。
install-for-older-amd.bat 旧型VGA(RX570/RX580など)向け。なのでPyTorchなどモジュールが旧い。
install-n.bat 高機能版、新版。
高機能版をインストールすると、通常版に比べ下記が追加導入される。
それと同時に関連しているコードも入れ替えられ、これら機能が有効化される。
#ComfyUI-managerは通常版の時点で入っているので、当然入っている。
- cuDNN/MIOpen
高速化。15%から20%速くなる。ただし代償として条件により不安定になる場合がある。ならない場合もある。
不安定さをピンポイントで回避するためのon/off切り替え用のカスタムノードもある。
cuDNN/MIOpen は、 そもそもTriton や Flash attention などとは独立したもので、これだけインストールしてこれだけ有効化すれば速度が向上するのだが、他のと一緒に導入されたためにいろいろと勘違いされているようだ。
- Triton
高機能化の素。Fluxなどでteacacheなど使って高速化するときなど、いろいろと使われている。
RadeonでZLUDAでの Flash Attention2 などはTritonが無いと動かない。
- Flash Attention 2
省VRAM, 省RAM。その結果として速くなることもある。
なおVRAMが豊富なVGAだとただのオーバーヘッドになるだけなことも。
- sage attention
品質を代償に高速化および省VRAM化。
品質は結構下がるが利点が大きいので、試したうえで判断を。実写と二次元で判断がわかれるかも。
#以前ソースコードをさらりと見たんだけど、たしかint8でやってるので、品質と速度、VRAMは、そういうことかと。
2025年8月現在、高機能版には下記4種類のインストール方法がある。
HIP6.4.2, cuDNN/MIOpen無 RX9000シリーズはコレ一択
HIP6.2.4, cuDNN/MIOpen無
HIP6.2.4, cuDNN/MIOpen有 (従来の高機能版)。インストールには追加作業が必要。
HIP6.4.2, cuDNN/MIOpen有 非推奨。インストールには追加作業が必要。ROCm6.5のMIOpenを使う。
まぁ、以前と比べcuDNN/MIOpenが削られたのだが、
経緯は、
cuDNN/MIOpenにはHIP SDK extensionが必須である。
従来のHIP 6.2.4にはHIP SDK extensionがあるのだが、
しかし新HIP 6.4.2にはマダ無い。また旧HIPのHIP SDK extensionは新HIPには使えない。
HIP SDK extensionの公開元いわく、
I'm planning to release HIP SDK extension that contains customized MIOpen with next version of ZLUDA. cudnn.dll will be available after that.
とのこと。
というわけでリリースまで待てばよいわけだけど、RX9000系は新HIP6.4.2でなければならないので、
いますぐRX9000系で使えるようにするべく、インストール用のinstall-n.batからcuDNN/MIOpenが削られた。
なので、RX7000系などで従来どおりcuDNN/MIOpenを使いたい場合は、install-n.batのcuDNN/MIOpenの部分を
元に戻す。余計な手間が増えるわけだが、cuDNN/MIOpenを有効にすると速度が15%から20%速くなるので、
どうするかは悩ましいところ。
#そのうち新HIP 6.4.2用のHIP SDK extensionが公開されてcuDNN/MIOpenも元に戻ると思うけどね。
2025年9月追記: インストーラー install-n.bat から Flash Attention 2 の部分が無効化された。使うには要有効化。
事前準備
ComfyUI-ZLUDAの高機能版のインストールはinstall-n.batを使ってサクッと出来るように仕込まれてはいるのだが、そのための事前準備が結構要る。
それらはwindowsに起因するものであったりして、Linuxだと不要だったりする。このあたりの事情はAMD RadeonもnVIDIA GeForce同じ。
たとえばTritonなんてLinuxしかサポートしていないので、windowsの場合はRadeonもGeForceどちらも本家版TritonはうごかなくてそれぞれFork版だ。
必須事項にはwindows OS の管理者権限が必要なものもあり、他人まかせ/インストーラーまかせにする類のものではないので、各自でおこなう。
前提
前提として、
A1111-ZLUDAや従来のComfyUI-ZLUDA通常版で画像の生成が出来ていること。
実際は必須ではないのだけれども、ようするにここからの説明の前提として、
Python, Git, Visual C++ Runtime, AMD HIP SDK for Windows
これらインストール済みでうまく動いているのが前提ということ。
なお AMD HIP SDK for Windows は、現在は、最新6.4.2もしくは6.2.4のHIP必須。旧い5.7.1は不可。
ComfyUI-ZLUDA 入手
高機能版は通常版に対し必ずしも完全上位互換というわけではないので、
ここは別途新規にフォルダ造ってインストールしたほうが良いだろう。
そこで、たとえば新規フォルダc:\ComfyUInを作成し、
git clone https://github.com/patientx/ComfyUI-Zluda .
windows OS の設定 パスの最大長の制限レジストリ 開発者モード
windows OSには、PATHは最長260文字という制限がある。
この制限のせいでモジュールによってはインストールが出来ないので、windowsのレジストリの該当部分を書き換えてこの制限を外す。
https://learn.microsoft.com/ja-jp/windows/win32/fileio/maximum-file-path-limitation
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
また、場合によっては window OS の開発者モードを有効にする。
これは通常は必須ではない(無効状態にて確認済み)のだが、PCによっては開発者モードを有効にしないとダメらしい。
windows OSの設定で、設定 - システム - 開発者向け - 開発者モード
Python
Pythonは、Python3.11 もしくは 3.12 が要る。
https://www.python.org/
実際はPython3.10であっても動かすことは出来るので、3.11や3.12は必須ではないのだが、しかしビルド済みのTritonがPython3.11と3.12向けなので、必須としたようだ。この件はComfyUI-ZLUDAのgithubのIssuesあたりでそのようなやりとりがあった。
#なお、いちおうPython3.10でちゃんと動くことはTritonを自ビルドして確認済み。
それでだ、
Pythonは、既にA1111-ZLUDAやComfyUI-ZLUDA通常版などで使っており、そしてそれらはPython3.10だ。
一方、今回インストールするPythonは Python3.11 もしくは 3.12 である。
Pythonはもともと複数バージョンの共存が可能ではあるが、そのやりかたはいくつもあり、ではどうするか、ということになる。
上級者であればポータブル版を使うのだろうけれども、ポータブル版には気を付けなければならないことがあり、たとえば通常版のPythonと比べてライブラリが不足していたりするので、こういうのの対処が出来ないと、のちのち落とし穴となる。
なので、ここではポータブル版ではなく通常版のPythonを使う方法で記述する。
Python通常版をインストールするとなると、Python3.10と3.11, 3.12の共存をどうするかで、
ここでは、Python3.10を優先とするやりかたとする。これは Radeon ZLUDA との兼ね合い。
Python3.11 や 3.12 をインストーラーでインストールする際にPATHを追加するチェックボックスがあり、
先のRadeon ZLUDAではPython3.10のインストールの際にここをチェックしてインストールしているので、
今回のPyhton3.11や3.12では逆にここはチェックせずにインストールする。
そうなると当然、Python3.11, 3.12はPATHには載らない。
ではPython3.11や3.12の実行時はPATHにないのにどうするのかというと、
やりかたは2通り。
- フルパスで実行する
面倒ではあるが、実際に実行するのは1回だけなので。venv仮想環境構築のときの1回だけ。
- py.exeをつかう
コマンドプロンプトで py -3.11 や py -3.12 のように、バージョンを指定してつかう。
これがPython標準のやり方。Python指南サイトならこのやり方とする、のだろうが、
ここはPythonを使うことが目的ではなく、ComfyUIを使って「AI生成を楽しむ」のが目的なので。
あとは、Pythonは3.11と3.12のどちらが良いのかだけど、ComfyUI本家を見る限り、
3.12がよさそう。まぁ、両方入れてもよいとは思うが、それだと管理の手間が増える。
#ちなみに、ROCm/TheRockのlshqqytiger氏ビルド済みwhlが3.11しかないので、3.11入れてますはい。
https://github.com/lshqqytiger/TheRock/releases
#一方の3.12は、3.12も入れればよいわけだけど、3.12はembed/portable版の検証の兼ね合いで、
#入れるとembed/portable版の評価に支障が出るので、3.12は入れずですはい。
#このような条件がなければ、3.12をインストールしますですはい。
AMD HIP SDK for Windows の HIP SDK extension (スキップ可)
* HIPが6.4.xの場合はまだ6.4.x向けのHIP SDK extensionはないのでスキップ
* HIPが6.2.4の場合でcuDNN/MIOpenが不要ならスキップ
cuDNN/MIOpenに必須なHIP SDK extensionをインストールする。
HIPが6.2.4の場合:
まず HIP SDK extension を lshqqytiger氏のgithubから入手する。
https://github.com/lshqqytiger/ZLUDA/releases
HIP-SDK-extension.zip
zipのサイズは2GBくらいある。
場所がgoogle driveなため、ダウンロード数が多いとダウンロードできないことがある。出来ない場合はだいたい数時間待つ。場合によっては翌日まで待つ。
なお同じものと称して他の人が別のところにアップロードしていたりするが、hashが違う。ヤメトケ。
ダウンロードしたHIP-SDK-extension.zipを展開し、AMD HIP SDK for Windowsのある
C:\Program Files\AMD\ROCm\6.2
にコピーする。コピーの際は、windows OS の管理者権限が必要になる。
なお、PCにHIPの5.7.1をインストールしてある場合は、HIPを6.2.4にすること。その際、
6.2.4のHIPをインストールする前に、必ず5.7.1のHIPをwindows OSのアプリの機能で
アンインストールしておく。
アップグレードインストールや上書きインストールなんてのは無いよ。
HIPの5.7.1をアンインストールしたら、6.2.4をインストールする前に zluda.db ファイルを削除しておく。
zluda.db は C:\Users\(ユーザー名)\AppData\Local\ZLUDA\ComputeCache フォルダ内にある。
注意事項1: RX6000系およびそれ以前の旧型VGAの場合
このHIP-SDK-extensionには hipBLASLt(cuBLASLt) が入っているのだが、
RX6000系など旧いVGAはhipBLASLt(cuBLASLt)に対応していないので、アプリによっては起動しなくなる。
対策としては2通り。
a). hipblaslt.dllをインストールしない
HIP-SDK-extension.zipを展開後、コピーする際、hipblaslt.dllは削除しておく。binフォルダの中にある。
b). 各アプリの起動用batで対処する
webui-user.batやcomfyUI-user.batにて、下記1行を追記する。場所はset PATHの次の行くらいに挿入すればOK。
set DISABLE_ADDMM_CUDA_LT=1
アプリによっては内部でこの設定が自動的にされるものもある。
困ったことに、ComfyUI-ZLUDAではハードコーディングされている。なので注意事項2に続く。
注意事項2: RX7000系およびそれ以降の新しいVGAの場合
上記注意事項1と同じhipBLASLt(cuBLASLt)関連で、
RX7000系およびそれ以降の新しいVGAではhipBLASLt(cuBLASLt)に対応しており、
いちおう一般的に起動用batで有効にする場合は下記のように0にする。
set DISABLE_ADDMM_CUDA_LT=0
ところが、ComfyUI-ZLUDAでは
comfy\zluda.py の冒頭付近で
os.environ['DISABLE_ADDMM_CUDA_LT'] = '1'
というコードにより強制的にdisableにされてしまっている。
なので、有効にしようとして起動用batファイルなどでこの環境変数を0に設定しても無意味。
有効にするには上記コードで1を0にするか、もしくはこの行を削除する。
ちなみに Linux ROCm だと hipBLASLt(cuBLASLt) は有効が基本のようだ。
そもそも、PyTorch2.4以降ではcuBLASLt必須なのだが、旧型VGAではcuBLASLtが動かないのでcuBLASLt(の呼び出し元)を無効にして対処している。
#ComfyUI-ZLUDAではなんで新型VGAででも無効にしているのかはわからん。
HIPが6.4.xの場合(非推奨):
HIPが6.4.xの場合、HIP SDK extensionはまだなく、
HIP SDK extension公開元いわく、
I'm planning to release HIP SDK extension that contains customized MIOpen with next version of ZLUDA. cudnn.dll will be available after that.
とのこと。
そこで、代わりにROCm TheRockのROCm6.5, HIP 6.5.2ベースのHIP SDK developから流用する。
HIP SDK developを、lshqqytiger氏のgithubから入手する。下記releasesの、
https://github.com/lshqqytiger/TheRock/releases
2025 May 11のところにある、HIP SDK developのリンクからダウンロードする。
サイズが4GBちかくある。
ダウンロードしたHIP-SDK-develop.zipを一旦展開し、それを
AMD HIP SDK for Windowsのある
C:\Program Files\AMD\ROCm\6.4
にコピーする。コピーの際は、windows OS の管理者権限が必要になる。
このとき、既存のファイルがある場合は上書きをするか否か問われるので、
上書きしない
ちなみに上書きしてしまうとZLUDAは動かない。あとは直上のHIPが6.2.4の場合 と同じ。
Visual Studio
Visual Studio Build Tools 2022 をインストールする。
https://visualstudio.microsoft.com/ja/
インストーラーで C++によるデスクトップ開発 をチェックしてインストール。
Select: Workloads - > Desktop development with C++
それでこの Visual Studioのインストールなんだけど、、、記憶を頼りに書くけど、
Triton は、以前は別途Cコンパイラが必要で、Linuxの場合はOSに標準で入ってたりするわけだが、
windowsでは入っていないので、Visual Studio, MSVCを入れて使うのであった。
それが、確かTritonの3.2.0くらいからか、小さいCコンパイラが付属するようになったので、別途Cコンパイラは不要になった。
なので、いまはもう、Visual Studioは要らないんじゃ?
それとはまた別の話で、Radeonでwindowsの場合はAMD HIP SDK for Windowsをインストールするわけだけど、
その C:\Program Files\AMD\ROCm\6.2\bin の中にはCとC++のコンパイラが入っているので、なのでそもそも
MSVCを入れなくてもCコンパイラは入っている。
となると、Visual Studioは要らないんじゃ??
さらに別の話で、2025年の7月終盤から8月にかけてComfyUI-ZLUDA 高機能版の特にインストールまわりに
手が加えられ、その際に、AMD HIP SDK for WindowsのCとC++のコンパイラを使うようになっているような。
そうであれば、もう、Visual Studioは要らないんじゃ???
#ただ、本当にいらないのかどうかだけど、
#Visual Studio / MSVCはTritonがどうのこうの以前からインストールして使っていたので、
#これをアンインストールして確かめるわけにもいかず、なので、本当にMSVCが必要なのかどうなのかは
#よくわからん。
#Visual Studioのオプション類も、もともと window 10 SDK や windows 11 SDK などいろいろと
#入れてあったので、オプションについてもわからん。
#というわけでMSVC入れて使ってるけど、それはこういう経緯からというだけ。
気を付けるのは、以前は確かにMSVCをインストールしなければならなかったので、
なのでネット上の情報にはその頃の古い情報のままだったりまたその受け売りだったり。
以前から使っている人はいちいちアンインストールして確かめないし。(ひとのこと言えず)
さらに、ComfyUI-ZLUDAのgithubのサイトの記述も、最近の手の加わりようにreadmeが追い付いていなかったりする。
Triton用の Python libs, Include
# 手順としてはもっと後に載せる内容なのだが、話しの流れとしてここで先出し
Tritonを使えるようにするためには、PythonのIncludeフォルダとlibs (libじゃないよ、libsね。)をComfyUIのvenvの中にコピーする必要があるんだけど、以前は
C:\Users\(user ID)\AppData\Local\Programs\Python\Python311
からそれらを手動でコピーしていたのだが、現在はインストーラーの install-n.bat 内で自動化されている。
ただ、自動化されているのはlibsフォルダのコピーだけで、Includeフォルダは自動化されていない。
Includeフォルダをコピーしなくても、一見動いてるといえば動いている。
では問題無いのかというと、のちのち問題が出てトラブルシューティングで
大変になるかもしれず。正直、よくわからない。
#なお、以前はどちらも手動であったため、当然のようにIncludeフォルダをコピーして入れてますはい。
model_management.pyの編集 ( あとまわし可 )
* あとまわし可 *
comfy\model_management.pyをComfyUI-ZLUDA高機能版用に編集する。
高機能版ではなく従来のComfyUI-ZLUDA通常版ではこの編集は必要ないのだが、
それは通常版では起動オプションにて --use-quad-cross-attention で起動しているからで、
これにより attention と VAE attention が
attention: quad attentnion VAE attention: Split attention
となるから。
ところが、ComfyUI-ZLUDAの高機能版でFlash Attention2やsage attentionを使うと、これらは
attention: Flash Attention2 / sage attention VAE attention: pytorch attention
となってしまう。つまりVAEのattentionが変わるのだ。
それでこの、VAEの処理に使われている pytorch attention がだ、RadeonではVAEに使うとイマイチ。動かないわけではないんだけど。
なので実はComfyUI本家ではVAEの処理に限りpytorch attentionはAMD機では使えないように仕込まれている。
ところがZLUDAはComfyUIから見るとCUDAなので、VAEに pytorch attention が使われてしまう。
なので修正が必要なのだが、ComfyUI-ZLUDAの公開元はここに手をいれるつもりは無いようなので、
仕方がないので各自でコードを編集して修正する。
comfy\model_management.pyの、場所は1100行目くらいの、
https://github.com/patientx/ComfyUI-Zluda/blob/5a21015adb460d8c7fcb6f3af44b026d6be2eaf8/comfy/model_management.py#L1088
ココらへん。
def pytorch_attention_enabled_vae():
if is_amd():
return False # enabling pytorch attention on AMD currently causes crash when doing high res
return pytorch_attention_enabled()
ここの if is_amd()条件文のところ常にTrueとなるようにif Trueにする。つまりこう。
def pytorch_attention_enabled_vae():
if True:
return False # enabling pytorch attention on AMD currently causes crash when doing high res
return pytorch_attention_enabled()
この修正により、VAEでpytorch attentionが使われなくなって、その結果、
VAE attention: Split attention
となる。VAE処理時に pytorch attention を回避できるようになる。
いちおう先に書いた通り、修正しなくてもいちおう動くので、修正はあとまわしでも可。
また別の解決方法として、SDXL生成に限るが、後述の
SDXLのVAE用 Flash Attention 2 カスタムノード
をつかう手もある。
ComfyUI起動batファイル 起動オプション
起動用batファイルは、
comfyui.bat (通常版用)とは別に、
comfyui-n.bat (高機能版用)が用意されている。
そこで、まずはこれを、たとえば
comfyui-n-user.bat という名前のファイルにコピーして、
そのcomfyui-n-user.bat を編集し、先頭部分が下記のようになるように4行挿入して、
起動はcomfyui-n-user.batを使うようにする。
===
2025年8月追記:
インストール用batに
copy comfyui-n.bat comfyui-user.bat /y >NUL
が追記された。親切ではあるが、comfyui-n-user.batではなくcomfyui-user.batなところには注意。
===
2025年10月追記:
comfyui-n.batに各種確認用コマンドが追加され、
ファイルの有無やバージョンをコマンドプロンプトウィンドウに表示するようになった。
そのため、行数が大幅に増えた。
今後もこれら確認コマンドは増えたり変更されるとおもわれるが、
基本部分は以前とかわらないので、下記は以前のままそのままだが問題ないだろう。
===
comfyui-n-user.bat (もしくはcomfyui-user.bat)を編集し、起動はcomfyui-n-user.batを使うようにする。
まず、先頭付近に4行追記する。
cd /d "%~dp0"
set PATH=%~dp0zluda;%~dp0.zluda;%HIP_PATH%bin;%PATH%
set "TRITON_CACHE_DIR=%~dp0.triton_cache"
set TORCH_BACKENDS_CUDNN_ENABLED=0
よって先頭部分はだいたいこんな感じになる。
@echo off
cd /d "%~dp0"
set PATH=%~dp0zluda;%~dp0.zluda;%HIP_PATH%bin;%PATH%
set "TRITON_CACHE_DIR=%~dp0.triton_cache"
set TORCH_BACKENDS_CUDNN_ENABLED=0
set FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
なんたら~
かんたら~
続いて、
git pull の行は削除。(なおgitとpullの間にオプションコマンドが追加されているかもしれないが、行ごとバッサリ削除。)
あとは、
ComfyUI起動オプションの set COMMANDLINE_ARGS= に記述できる attention は下記の5つなので、
このなかから選ぶ。(どれにするかで速度やVRAM使用量が違うので、一通り試すのおススメ。)
--use-split-cross-attention
--use-quad-cross-attention
--use-pytorch-cross-attention
--use-sage-attention
--use-flash-attention
それと、予防的にset COMMANDLINE_ARGS=には--disable-cuda-mallocも入れておく。
またPC構成によっては、Tritonが使うVGAを正しく認識できない場合があるので、そういう場合は明示的に設定する。
たとえばVGAがRX7900XTXならグラフィックスアーキテクチャはgfx1100なので、
set TRITON_OVERRIDE_ARCH=gfx1100
をset TRITON_CACHE_DIR の次の行あたりに挿入する。
ここのVGAとgfx名については、こちら ZLUDAannex1 を参照のこと。
#他には、
set "MIOPEN_USER_DB_PATH=%~dp0.miopen_cache"
#あとさ、前から思うんだけど、起動用batにはcall文でvenvのactivate入れるのと、
call venv\Scripts\activate.bat
これとセットで本体起動は
.\zluda\zluda.exe -- %PYTHON% main.py %COMMANDLINE_ARGS%
ではなく
python.exe main.py %COMMANDLINE_ARGS%
にしたほうが。
2025年8月追記:
cuDNN/MIOpenの有効無効切り替え用環境変数 TORCH_BACKENDS_CUDNN_ENABLED が追加された。
値が1で有効、0で無効。未指定だと値は1となり有効。
上記では起動エラーを防ぐため0にしておいた。
なお、0以外にも、"0", "off", "false", "disable", "disabled", "no" これらで無効になる。
あといちおう、TORCH_BACKENDS_CUDNN_ENABLED はComfyUI-ZLUDAだけのなので、他では使えない。
インストール、起動
インストールは install-n.bat をダブルクリックでインストールするのだが、
Python3.11 / 3.12 をPATHに通していない場合は、うかつにダブルクリックしてしまうと、PATHに
Python3.10があるとPython3.10でインストールが進んでしまい、結局インストールに失敗する。
でもここもそのうち自動化され自動判別でうまくいくようになるかもしれん。
現状は自動判別されないので、手動でおこなう。
install-n.batを実行する前に、手動でPython3.11もしくは3.12にてvenv仮想環境をつくる。
venvさえ作ってしまえば、あとは install-n.batが続きを全部やってくれる。
venv仮想環境を作るには、ComfyUIのフォルダにてコマンドプロンプトを開き、下記のコマンドを実行する。
なおフルパス部分の(ユーザー名)とPython311は各自PCにあわせること。
C:\Users\(ユーザー名)\AppData\Local\Programs\Python\Python311\python.exe -m venv venv
ただ上記は長いので、Pythonに慣れた人ならこちらで。
py -3.11 -m venv venv
ここもPython3.12の人は -3.12 にして。
venvが作成されたら、お好みでinstall-n.batに下記の編集をし、install-n.batをダブルクリックで実行してインストール。
まず、install-n.bat の最後の行の、
.\zluda\zluda.exe -- python main.py --auto-launch --use-quad-cross-attention
は削除して起動しないようにしておく。
代わりに
pause
を入れておくのがおススメ。
次に、その少し上でcuDNN/MIOpen用のDLLのインストールがあるのだが、
以前は有効になっていたのだけれども、現在はというと、
:: removed cudnn dll patching , check the results
:: copy zluda\cudnn.dll %VIRTUAL_ENV%\Lib\site-packages\torch\lib\cudnn64_9.dll /y >NUL
こんな感じで:: で無効にされている。有効にしたい場合は行頭の:: 部分を削除し、下記にする。
copy zluda\cudnn.dll %VIRTUAL_ENV%\Lib\site-packages\torch\lib\cudnn64_9.dll /y >NUL
さらに、Flash attention2も、以前は有効になっていたのだけれども、現在は
:: echo :: %time:~0,8% :: - Installing flash-attention
から続く数行がバッサリと :: で無効にされている。
Flash attention2をインストールしたい場合は行頭の :: 部分数行分をすべて削除する。
あと、相変わらず無駄ダウンロードのココ、
echo :: %time:~0,8% :: - Installing required packages
pip install -r requirements.txt --quiet
echo :: %time:~0,8% :: - Installing torch for AMD GPUs (First file is 2.7 GB, please be patient)
pip uninstall torch torchvision torchaudio -y --quiet
pip install torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu118 --quiet
ここがこのままだとtorch群の無駄なダウンロードをやるので、これを修正する。
#これさぁ、他の人からここを含めた修正requestが出たのに、この部分だけ元に戻し適用してんだよなぁ。
上記5行の部分を下記4行にすると無駄なダウンロードを省ける。
echo :: %time:~0,8% :: - Installing torch for AMD GPUs (First file is 2.7 GB, please be patient)
pip install torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu118 --quiet
echo :: %time:~0,8% :: - Installing required packages
pip install -r requirements.txt --quiet
インストールが完了したら、ComfyUI起動は先に作成した comfyui-n-user.bat 。
なおここで、インストールは正常におこなわれたにもかかわらず、起動に失敗する事例が多発している。
nccl.dll というファイルがセキュリティソフトにより隔離され、起動に失敗するようだ。
なんども隔離する模様。
なので、インストール直後に起動しなかったり、
また一度は起動に成功したのに翌日に起動に失敗する場合は、
まずはセキュリティソフトが隔離していないか確認を。
Developer Command Prompt 起動
旧情報になるが、
起動方法に、Developer Command Prompt起動 というのがある。
Visual Studioをインストールするとwindows OSのメニューから Developer Command Prompt を起動できるようになるので、
その Developer Command Prompt でComfyUI-ZLUDAを起動する。
実際はメニュー操作からの手順を踏まずに、ComfyUI起動用batファイルの冒頭(2行目)に
call "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\Tools\VsDevCmd.bat" -arch=amd64
こんな感じにcall噛まして Developer Command Prompt になるようにしていた。ここ -arch=amd64 がとても重要。
現在はこのようなやりかたをしなくてもよいとのこと。
ただ、PCによってはいまでも Developer Command Prompt から起動しないとうまく動かないケースがあるのだそうな。
cuDNN/MIOpen
ComfyUI-ZLUDAでcuDNN/MIOpenを有効にすると速度が15%-20%向上する。
いちおうここでは念のため起動不可にならないように起動用batファイルにて
set TORCH_BACKENDS_CUDNN_ENABLED=0
としてcuDNN/MIOpenを無効にしているが、ここの0を1にすれば有効にできる。
また有効時はComfyUI-ZLUDAでは
set MIOPEN_FIND_MODE=2
として、負荷が軽めになるようになっている。
それともうひとつ、デバッグなどの特殊用途向けだが、
TORCH_BACKENDS_CUDNN_BENCHMARK
という値もあり、未指定だと1で有効になっている。この値を0にするとcuDNNベンチマークを無効化できる。
set TORCH_BACKENDS_CUDNN_BENCHMARK=0
基本的には、cuDNN/MIOpenを有効にする場合はここは未指定(=有効)のままにしておき、
cuDNN/MIOpenの振る舞いはMIOPEN_FIND_MODEで指定する。
それで、cuDNN/MIOpenを有効にするか否か、またMIOPEN_FIND_MODEをどうするかだが、
安定志向ならcuDNN/MIOpenを無効に、
速度重視ならcuDNN/MIOpenを有効にし、MIOPEN_FIND_MODE=2でよいと思う。
いちおう
TORCH_BACKENDS_CUDNN_ENABLED
TORCH_BACKENDS_CUDNN_BENCHMARK
この2つはComfyUI-ZLUDA用のものなので、他では使えない。
一方、
MIOPEN_FIND_MODE
こちらはMIOpen側のもの。なので、他のアプリ、例えばA1111-ZLUDAでMIOpenを導入しているのなら使える。
MIOpen MIOPEN_FIND_MODE
ここで、当初はこの説明は上記だけで十分と思っていたが、ROCm TheRockについて
ネット上で不適切な設定によるおかしな結果がまるでそれが仕様かのように拡散されているので、
仕方がないのでもう少し詳しく書くことにする。
まずそもそものcuDNN/MIOpenだが、これはAIでの深層学習の際に使うもの。
AI深層学習は、データセンター用の機器を用いて学習に数日/数週/数か月かけておこなう。
具体例をあげると、例えばMI300Xは1基あたりVRAM192GBで、サーバ上でこれを8基搭載して束ねて使う。
#ちなみにMI300Xを実際に借りてたけど、そのときは1基あたり1時間US$2だった。8基だと8倍だがこれは借りず。
このようなデータセンター用機材での深層学習は最適化によるわずかな速度向上であっても最終的に
大きな差が出るので、学習開始前に最適化を行う。
最適な方法を割り出すためには、ベンチマークをとる。
各種方法でベンチマークをとり、一番最適な方法を見つけ出して、その方法で学習を行う。
この仕組みがMIOpen2.0以降には組み込まれている。(MIOpen1.0まではいまより簡易的だった)
それで、そのベンチマークは、このような機材でおこなうものであるのだから、
そのベンチマークの負荷やVRAM使用量たるやすさまじいもの。
ただ、学習の本番ではなくテストやデバッグ時には簡易的なベンチマークで済ませたり
ベンチマークを省略したいこともあるので、
その選択肢としてMIOpenでは5つのモードが用意されている。
このモードをどれにするかはMIOPEN_FIND_MODEの値で指定する。
- NORMAL/1
- FAST/2
- HYBRID/3
- 4:(未使用、予約)
- DYNAMIC_HYBRID/5
未指定の場合は モード5/DYNAMIC_HYBRID になる。
それぞれのモードについて:
https://rocm.docs.amd.com/projects/MIOpen/en/latest/how-to/find-and-immediate.html
(説明のため順番は変えてある)
- HYBRID/3
データベース.dbを参照して該当項目がヒットしたら.dbの値を使い、ベンチマークは実行しない。
初回は.dbにヒットしないので、ベンチマークをとり、最適な方法で実行する。
ベンチマークの結果は.dbに格納されて、2回目以降は.dbヒットするので、最速。
- DYNAMIC_HYBRID/5
.dbを参照して該当項目がヒットしたら.dbの値を使い、ベンチマークは実行しない。
ヒットしなかったらベンチマークをとるのだが、その際に各種方式のうちnon-dynamic kernelsを除いて
簡略化しベンチマークをとる。これによりモード3 HYBRIDよりもベンチマーク負荷は軽くなるが、
最適化度合いはモード3 HYBRIDよりも劣ることになる。
- NORMAL/1 本番向け
.dbは参照せず、毎回がっつりベンチマークをとり、最適値で実行する。
ベンチマークなどの前処理に一番時間がかかるが、深層学習の本番ではこのモードで最適化し最速学習させる。
- 4: (未使用、予約)
- FAST/2 ベンチマーク省略
ベンチマークを実行しない。よってデータベースファイル.dbを作らず.dbを更新せず。
.dbを参照して.db内に該当項目がヒットしたら.dbを使う。
ヒットしなかったらimmediate modeで実行する。
一度も他のモードで実行せずに最初からモード2だけで実行すると、.dbはカラなので
必ずimmediate modeとなる。
immediate modeでの実行はつまりベンチマークの結果を反映していないので、
最適化は最低で、非効率。全モードのなかで最低速となる。
でもその最低速でもMIOpenを使わない場合に比べて15%くらい速かったりする。
また、ベンチマークを実行しないのでその分の時間は短略されるのと、ベンチマーク実行の
ためのVRAM追加消費もないので、使い方によっては結果的に最速になることもある。
- 未指定
MIOPEN_FIND_MODE未指定の場合は モード5/DYNAMIC_HYBRID になる。
また、.dbファイルやcacheは C\Users\(ユーザーID)\.miopen フォルダ内に出来る。
上記はAI深層学習向けの説明だが、これMIOpenを個人用PCでのAI画像生成に使うとなると、
ベンチマーク負荷や要求VRAMはデータセンター用機器向けなものだから、
個人用PCには負荷が高すぎ要求VRAM多すぎ。
一方、生成は数秒から数十秒なため、ベンチマークで最適化したところでその恩恵は
微々たるもので、ベンチマーク省略してモード2/FASTで使った時とあまり変わらない。
なので、
個人用PCでAI絵を生成する場合は、モードFAST/2の、
set MIOPEN_FIND_MODE=2
としてベンチマークを省略する。
これが結果的に一番速いし、VRAM使用量増加分も個人PCレベルに抑えられる。
ただ、生成時間が長いもの(Fluxなど?)は、モードを3や5を試してみるのも良いかもしれない。
あとは、
たとえばSDXLではSDXL標準的な縦横サイズの数パターンだけモード3でdBを作っておき、
ある程度dBが溜まったらそれ以降はモード2にする手もある。
このあたりはgithubでいろいろと検証しているひとたちがいるので、そちらを参考にしてみるのも。
なおMIOPEN_FIND_MODE未指定だと、以前のMIOpenが1.0だったときはこんな負荷かからなかったので
未指定でも問題なかったが、MIOpen2.0以降では未指定だとモード5になるので未指定はヤメトケ。
あとそもそもVRAMとRAMが少なすぎる場合はMIOpenは使えない。
ちなみにROCm TheRockはまだ正式リリース前なためかMIOpenが最初から入ってしまっているので、 もしMIOPEN_FIND_MODEを指定せずに使うとモードは5/DYNAMIC_HYBRIDになり、 そのためベンチマーク処理が入ると時間がかかるが、.dbにヒットすれば速い。 ただ、先に書いたようにMIOpenはそもそも深層学習向けのものなので、 初期値のモード5は深層学習向けであって、AI絵向けではない。 にもかかわらず、MIOPEN_FIND_MODEを設定せずに初期値のモード5でAI絵をやると、 妙に時間がかかったり、ベンチマークの負荷やVRAM要求に耐えられなくて停止するわけだが、 そりゃ深層学習向けの設定のまま個人PCでやってればそうなる。 | ネット上では個人PCでそういう深層学習向け設定のままでやっておいて、不安定だの エラーで止まるだのというのがみられるが、そういうのはあまり真に受けないように。 | いちおう、ComfyUI-ZLUDA通常版ではMIOpenはoffだ。 ComfyUI以外のアプリでもZLUDAでは基本offだ。ZLUDAのnightlyにするとonに出来る。 ComfyUI-ZLUDAも高機能版にするとonに出来て、起動用batで MIOPEN_FIND_MODE=2 となっている。 あと、ここZLUDAannexの起動用batサンプルは記載当初からComfyUIもreForgeも MIOPEN_FIND_MODE=2 だ。 https://wikiwiki.jp/sd_toshiaki/ZLUDAannex1#sb12e27a | またComfyUI-ZLUDAには後述する切替用カスタムノード CFZ CUDNN Toggleノードもある。 このノードで通過ノード毎にon/offを切り替えてうまくMIOpenを使っているworkflowもある。 ComfyUI-ZLUDA高機能版は2025年5月からあって、その当時ComfyUI普段使いしていた人だと TheRockでも MIOPEN_FIND_MODE=2 にしたりon/off切替ノードを活用していたりするのだけど、 | 普段使ってない人がレビュー目的でTheRockでちょろっとやってみたってのだとMIOpenまわりが不適切で、 それによるおかしな結果がネット上で拡散されてしまっている。 特にROCm TheRockはまだ正式リリース前なのでおかしな情報が拡散されるのはある程度仕方のない ことではあるけれども、しかし本件に限らずネット上にはそういう情報が多々あるので、 あまり真に受けないように。 | あと、なかにはROCm TheRockでMIOPEN_FIND_MODE=2にしてZLUDAと比較しているのも あるのだが、ZLUDA側のMIOpenを有効にせずに比較していたりして、 それだと速度に10%-20%差が出るのは当然なので、そういうのもあまり真に受けないように。 ちゃんとTheRockとZLUDAでMIOpenまわりを同じにしてやると、TheRockとZLUDAの差は ほとんど無くなる。 それと比較の際、ROCmのバージョンをROCm7と6.xとで比較しているのなら、それ、ROCmの違いの比較だよ。
cuDNN/MIOpen設定 RX6000系限定?おススメ設定と無効化設定方法 (中級者以上向け)
cuDNN/MIOpen関連のおススメ設定と無効化の設定方法。
ソースコードを改変するので中級者以上向け。
* RX6000系向けの設定につき、RX7000やRX9000でも同様の効果があるかは不明 *
* たぶんRX7000でもうまくいくと思うが、RX9000でどうかはわからん *
この改変は、ComfyUI-ZLUDAだけでなく、ComfyUI本家はもちろんA1111系でMIOpenを使う場合も有効。
なので、説明にはComfyUI-ZLUDAの改変ポイントのほかに、A1111系の説明としてreForge用の改変箇所も
書いておく。reForgeなのは、こちら ZLUDAannex1 にてROCm windows版のところで触れた兼ね合い。
まず、
起動batにてMIOPEN_FIND_MODEを2/FASTにする。
SET MIOPEN_FIND_MODE=2
つづいて、
ソースコードにて、torchがimportされた直後にcuDNN用のtorch.backends.cudnn設定を挿入する。
起動からコードを追いかけていき、
import torch
というコードを探す。
実際の挿入箇所は既に Radeon ZLUDA の自力ZLUDA化で触れてあるので、そこを横目でみながら見つける。
見つかったら、その直後に目的に応じて下記コードのどちらかを挿入。
- cuDNN/MIOpenを使う場合:
cuDNNの際に、無茶なcudnn.benchmarkをおこなわないようにする設定を挿入。torch.backends.cudnn.benchmark=False - cuDNN/MIOpenを使わない場合:
下記の1行を挿入すると無効化される。いちおう現在は上記で十分なようであるが、先々のことを考えると、下記3行にしておいたほうがよいと思われる。torch.backends.cudnn.enabled = Falsetorch.backends.cudnn.enabled = False if hasattr(torch.backends.cuda, "enable_cudnn_sdp"): torch.backends.cuda.enable_cudnn_sdp(False)
いちおう現在(2025年10月)のコード挿入ポイントは、
- ComfyUI-ZLUDAの場合、
comfy\model_management.py のここらへん。
https://github.com/patientx/ComfyUI-Zluda/blob/0ff5eda8a50acf98d743c0cd392dab33199da939/comfy/model_management.py#L23
コード挿入後はこんな感じになる。from comfy.cli_args import args, PerformanceFeature import torch torch.backends.cudnn.benchmark=False import sys import importlib なんたら~ かんたら~ - ComfyUI本家も同じく、
comfy\model_management.py のここらへん。
https://github.com/comfyanonymous/ComfyUI/blob/14d642acd66973c81a806dc6f0562d89b4ba3506/comfy/model_management.py#L23 - reForgeは、ブランチによってbackendが異なるため挿入ファイルが異なり、
旧main-old版ブランチはbackendがA1111-Forgeの系譜なので、
modules\initialize.py のココ。
https://github.com/Panchovix/stable-diffusion-webui-reForge/blob/1572cd88a746bcff28a841856ab0a56df1913812/modules/initialize.py#L27
A1111系アプリはどれも基本的にこれと同じ。 - reForge現main版はbackendがComfyUIなので、ファイルが違って、
ldm_patched\modules\model_management.py の、ココらへん。
https://github.com/Panchovix/stable-diffusion-webui-reForge/blob/99bb3d5da9bbeae34d803a2f30f70d9ea45ad228/ldm_patched/modules/model_management.py#L23
なおA1111系でもForgeはバージョンによってはこれと同じ挿入ファイルmodel_management.py。
なお、A1111系は
import torch # noqa: F401
という具合に行頭にインデントがあるので、コード挿入の際は位置を揃えること。
使用にあたり、
もし上記設定をする前に既にComfyUIを使っている場合は、MIOpenのdbやcacheが作られている場合があり、
場所は
C:\Users\(ユーザー名)のところ .miopen というフォルダ。
既にこのフォルダがあったら、とりあえずリネームでもして、避けておく。
効果の程は、
上記設定のうち、
torch.backends.cudnn.enabled = False
にて無効にした場合はcuDNN/MIOpenは使われなくなるので、速度は遅くなるというか、
以前のComfyUI-ZLUDAと同じ速度。
一方、
torch.backends.cudnn.benchmark=False
にした場合は、MIOpenを使うので、以前のComfyUI-ZLUDAと比べて速度は15%から20%速くなる。
以前のではなくComfyUI-ZLUDA高機能版でcuDNN/MIOpenを有効にしこの設定を入れないままと
入れた場合とでの比較だと、速度はほとんど変わらず。多stepsで比較するとわずかに遅くなってるのが
わかるのだが、差は1%未満で、0.5%くらいか、もっと少ないくらい。
解像度変更後の初回のもたつきはなくなる。
HiresFixでの拡大も、これはメモリ搭載量次第だけど、x2倍くらいの拡大なら通常VAEのままで
問題なく拡大出来ている。
#まぁ、x2倍とかの拡大だと通常はTiledVAEを使うので、これはあくまで試験目的ではあるのだけれども。
こんな感じで、torch.backends.cudnn.benchmark=Falseは使い勝手や安定性は以前のとそれほど変わらずに
MIOpenにより速度が速くなるので、コード改変の手間はあるけれども、個人的にはおススメ。
さて、
ここからは推測混じりになるのだが、
まず、MIOpenは、
MIOPEN_FIND_MODEが未設定ではDYNAMIC_HYBRID/5なため、AMD向けのMIOpenのベンチマークを実行する。
一方、nVIDIA向けのcuDNNは、
torch.backends.cudnn.benchmarkが未設定ではTrueであり、cuDNNのベンチマークを実行する。
そして、ComfyUI本家やA1111系ではこれら値はどちらも未指定(2025年10月現在)なため、
MIOpenのベンチマークの試行パターンがx通り
cuDNNのベンチマークの試行パターンがy通り
とすると、
ComfyUI本家版では合計x*y通りのベンチマークを実行。
という具合で、これはやりすぎ。やるならとちらか片方でよくね。
そこで、
MIOPEN_FIND_MODEだけ2/FASTに設定すると、試行回数はcuDNN側のy通りだけとなり、
そして2/FASTではベンチマークを実行せずにimmediate modeとなるので、y通りの試行はすぐに終わる。
#これが、ComfyUI-ZLUDA高機能版の現在(2025年10月)の設定。
一方、
MIOPEN_FIND_MODEは設定せずにtorch.backends.cudnn.benchmarkをFalseに設定すると、試行回数は
MIOpen側のx通りだけとなる。
そして両方の設定をすると、
どちらもベンチマークを実行しなくなるので、その場合は
cuDNNは内部既定の最適値
MIOenはimmediate modeによる最適値
が使われる。
いわゆるプリセットの値が使われるので、値は最適値ではないのだが、プリセット値は事前に演算され導き
出されたものであり、そこそこ最適化はされている値であろう。なのでそれなりに速度は向上する。
cuDNN/MIOpenは、大規模深層学習ではなくいまのAI絵生成程度なら、この程度の最適化値で十分なんじゃないの。
# このやりかたは、SD.Next なら頼めばオプションで設定できるようにしてくれそう。
特殊なカスタムノード CFZ CUDNN Toggleノード など
ノードの中に、CFZから始まるカスタムノードがいくつかインストールされている。
これらはComfyUI-ZLUDA独自のカスタムノードである。
それらのうち、特に使いそうなものとして、
CFZ CUDNN Toggleノード
がある。
これは、cuDNN/MIOpen のOn/Offを切り替えるノード。
cuDNN/MIOpen を使うと15%から20%速度が向上するが、条件によってはcuDNN/MIOpenが
原因でVGAドライバーが応答停止することがあるので、その対策として、その原因のノードの前後に
CFZ CUDNN Toggleを噛ませてこの問題を回避する。
- 使用例1: cuDNN/MIOpen on/off切り替え
cfzフォルダの中に 1step-cudnn-disabler-workflow.json があり、
そのworkflow内にはCFZ CUDNN Toggleノードが組み込まれていて、
このノードを通過すると、起動中のComfyUIのcudnn/MIOpenのon/offが再設定される。
CFZ CUDNN Toggleノード の enable_cudnn切替ボタン にて、
trueでon
falseでoffとなる。
よってこのworkflowを実行すれば、起動中のComfyUIのcuDNN/MIOpenのon/offを切り替えることが出来る。
一度通過させればよいだけなので、モデルはsd1.5で構わないし、サイズは小さくstepsも1でかまわない。
どのような使い方を想定しているかというと、普段はcuDNN/MIOpenをonで高速に生成し、
ドライバ応答停止するworkflowのときだけこれを一度実行してoffにする。
- 使用例2: ピンポイントに VAE Decode だけcuDNN/MIOpenをoffに
先の使用例1の 1step-cudnn-disabler-workflow.json のworkflowでは
VAE Decodeの直前にCFZ CUDNN Toggleノードが一つであったが、
ピンポイントに VAE Decode だけcuDNN/MIOpenをoffにするには、さらに
VAE Decode の直後にもう一つ CFZ CUDNN Toggleノードを噛ませる。
(VAE Decodeを前後からCFZ CUDNN Toggleで挟むようにする。)
そして、
VAE Decode 直前のはenable_cudnn切替ボタンをfalseにし、
VAE Decode 直後のはenable_cudnn切替ボタンをtrueにする。
これにより、VAE Decode処理時のみoffになり、それ以外ではonになる。
どういうときに使うかというと、たとえばHiresFixをするために、
ComfyUIのメニューからworkflowのTemplateの中でUpscaleにあるHiresFixを使う際、
Upscale Image のサイズが大きすぎるとVRAMが盛大に溢れ、cuDNN/MIOpen起因で
VGAドライバー応答停止がおこるのだが、
そこで、発生するノードの前後にCFZ CUDNN Toggleノードを噛ませて一時的にoffにし、これの回避を試みる。
たいていは最後の最後のVAE Decodeだけoffにするだけで回避できる。もちろん限界はある。
#いちおうこのケースではTiled VAEを使うのが一般的な解決方法。
ついでに、VAE Decodeを後述のカスタムノードでFlash Attention 2で処理してやると、
VRAM消費を少し減らせる。
これらは例であって、他にもいろいろな使い方ができるので、これらをうまく利用して速度向上を狙おう。
ComfyUI-ZLUDAには他にもCFZで始まる便利なカスタムノードがいろいろあり、
たとえば、CFZ VAE LoaderなんかはVAE呼び出すのにfp16やbf16を指定できたりする。
cfzフォルダ内にはサンプルworkflowなんかもあるから、いろいろ見てみると良いよ。
基本的な使い方、サンプルworkflow、 wan wan2.2など
ComfyUI-ZLUDA独自のファイルがcfzフォルダの中にいくつか入っており、
たまに中身が増えている。
その中にはwanやwan2.2用のworkflowもある。
workflowはComfyUI-ZLUDAを公開している人のPC用に最適化されているようだ。
#以前はRX6600 8GBだったのだが、2025年前半はRX6800 16Gとのこと。
これらworkflowを試してみるのもよいだろう。
ただし、慣れていないのなら、いきなりこのworkflowを使うのはおすすめしない。
ComfyUIの使い方の基本として、
ComfyUIでなにか新しいのトライする際は、下記の1, 2, 3の順で試すのがよい。
1. まず最初にComfyUI公式のサンプル/テンプレートを試す
基本workflowなので理解しやすい。
まずはComfyUI本家のサンプルページを見る。
https://comfyanonymous.github.io/ComfyUI_examples/
いろいろとサンプルがあるので、それらのページを見る。そこに使いたいものがあるか探す。
見つかったら、手元のComfyUIに導入する。
導入方法は新旧2通りあり、
2024年秋冬以降の新UIでは、
ComfyUIのメニューにてworkflowのテンプレート導入機能があるので、これを使う。
さまざまなテンプレートがあるので、その中から先にサンプルページで見つけたものを探す。
見つかったらクリックすると、workflowが開く。
このとき、ファイルなどが不足している場合はダウンロード画面が開かれるので、
必要であればそれらファイルをダウンロードする。
2025年はこのテンプレートを使った導入方法がComfyUI標準のようであるが、従来からの画像から取り込む方法ももちろん使える。先のサンプルページには、サンプル画像など、ページ内にいくつか画像がある。この画像、画像内部のメタデータにComfyUIのworkflowやPromptが入っていたりするので、そこの画像をダウンロードし、ブラウザのComfyUIの画面にドラッグアンドドロップすると、workflowが現れる。
#たまにメタデータが入っていないハズレもある。
workflowが現れた場合は、そのまま使える。
画面にドラッグアンドドロップした際、ポップアップ画面にエラーメッセージが現れたり、
workflowが赤く染まっている場合は、必要なノード(拡張機能)が不足している。
その場合は、まずmanagerを開き、
Install Missing Custom Nodes
をクリックすると、不足しているノードが自動検索され、簡単にインストールできるようになっている。
(たまに検索に漏れるハズレもあるので、そういうときはSearchのところで検索してノードを見つける)
installしたらrestartを促されるのでComfyUIを再起動。
するとworkflow上の赤い色が消え、使えるようになっている。
#このように簡単にノードをインストール出来るので、ComfyUIユーザーの間では画像のやりとりでworkflowのやりとりをおこなっている。
ちなみに、公式サンプルページにあるworkflowとテンプレートのworkflowは少し違っていることがあるのだが、これはテンプレートは更新されていたりするからで、一方サンプルページのは当初のままだからだったりする。
なので、導入の際はテンプレートからおこなったほうがよさそう。
ComfyUIが公式で用意しているこれらworkflowはどれも基本的なものであり、理解がしやすい。
なので、最初はComfyUI公式のworkflowで試して、どんな感じなのかをつかんでおく。
2. 次はKijai氏wrapperを試す
ComfyUI公式を試した後は、次はKijai氏wrapperを試す。
あたらしい何が出ると、たいていKijai氏wrapperがあるので、それを試す。
先のComfyUI公式と比べると機能が拡張されていたりと、便利に使えるようになっていたりする。
決して上位というわけではないので、逆にとてもシンプルなものもある。
Kijai氏のwrapperのgithubのところには、使い方の説明やサンプルworkflowがあるので、それらを試す。
そこにある画像や動画の中にworkflowが入っていることもあるので、それらもひらいてみる。
また、wrapperを導入するとcustom_nodesフォルダ内にそのwrapperのフォルダが出来て、
そしてその中にexsampleもしくはsampleフォルダがある場合は、
中に各種サンプルworkflowが入っているので、それらも片っ端からひらいてみる。
3. ComfyUI-ZLUDAのcfzフォルダ内workflowやネットで公開されているworkflowを試す
上記ComfyUI公式サンプルとKijai氏wrapperを試すとどんな感じなのかわかるようになるので、
それらを試したあとに、ComfyUI-ZLUDAのcfzフォルダ内workflowやネットで公開されているworkflowを試す。
見ればわかるが、どれもこれもworkflown内のノードがとても込み入っていて、いわるる俺様workflowなので、
初見だとなにがどうなっているかわからないのだけれども、
先にComfyUI公式とKijai氏を試した後であれば、どこが基本部分でどこか拡張部分なのかがわかるし、
すぐに使いこなせる。
逆に、これが最初にいきなり俺様workflowだと理解しないまま使うことになって、たいしたこと出来ん。説明文がついていても、それが何のことなのか説明読んでもわからないだろう。
#あれら説明文って、基本がわかっている人向けだから。
BF16対策 (RX6000向け 他の世代でも有効)
BF16問題というのがあるのでその対策。
旧型RX6000ではこのBF16対策をしないと速度の低下およびVRAM消費が増大することがある。
そこで対策として、強制FP16/強制FP32でこの問題を回避する。
特にComfyUIではSDXLのVAE処理がBF16なので、RX6000ではこの対策は必須である。
#ちなみに他はどうかというと、
#Forge2もVAE時BF16になるので同じ問題がおこる。
#A1111-ZLUDAやSD.NextはFP16でおこないNaNが発生するとFP32になるのでこの問題はおこらないが、VAEの設定でBF16にしていると起こる。
#reForgeはブランチによって挙動はまちまち。
まず、FP16とFP32それぞれの起動用batファイル用に、
comfyui-n-user.batを2つコピーして、
comfyui-n-user-FP16.bat
comfyui-n-user-FP32.bat
とでもする。
それぞれのbatの起動オプションCOMMANDLINE_ARGSのところにFP16/FP32を指定する。
主に使うオプションはこんなところ。これらを組み合わせて指定する。
--force-fp16 すべて強制FP16 --force-fp32 すべて強制FP32 --fp16-unet UNetだけFP16 --fp32-unet UNetだけFP32 --fp16-vae VAE処理だけFP16 --fp32-vae VAE処理だけFP32 --fp16-text-enc text encoderだけFP16 --fp32-text-enc encorderだけFP32
FP16は速度が速くまた省VRAM。ただし演算精度が低いため、最近のモデルによっては精度不足で黒画面しか出ない。例えばLumina2やFramepackでは黒画面。
FP32は画の品質は高い。ただしFP16より速度が落ちるのと、VRAM消費量が増えVRAMが溢れるおそれがある。
まずおススメなのは、SDXL用に、速度重視なら--fp16-vae、品質重視なら--fp32-vae。これだけを指定する。(他のunetとtextencoderは未指定で。)
とりあえずここから始めるのが良いだろう。
FluxはこのBF16対策リンク先のとおり。
FP8で省VRAM高速化 (RX9000シリーズ以降限定)
RX9000シリーズはFP8に対応しており、処理能力がFP16に比べて2倍ある。
ComfyUIでは、機器がFP8に対応していると、使用モデルがFP8なら自動的にFP8での演算になるように仕込まれているのだが、
https://github.com/patientx/ComfyUI-Zluda/blob/8a120713c24958e5b4de826e527373da1b2d47b4/comfy/model_management.py#L314-L333
なぜだかgfx1200が抜けているのでRX9060XTでは自動処理されない。gfx1201はあるのに。 その後gfx1200もコード追加された。
でもそもそもここのif文からして、自動処理はダメかもしれない。
というわけで、FP8で演算させたい場合は、起動用batファイルのCOMMANDLINE_ARGSに
--supports-fp8-compute
を追記する。
他にFP8に関連する起動オプションは、
--fp8_e4m3fn-unet --fp8_e5m2-unet --fp8_e8m0fnu-unet | --fp8_e4m3fn-text-enc --fp8_e5m2-text-enc | --fp16-vae --fp32-vae --bf16-vae
例えば、起動用batファイルのCOMMANDLINE_ARGSに
--supports-fp8-compute --fp8_e5m2-unet --fp8_e5m2-text-enc --fp32-vae
また参考までに、ComfyUIのgithubのissuesにて、
https://github.com/comfyanonymous/ComfyUI/issues/8242#issuecomment-2917985493
こちらによると、下記でfp8で速くなったそうな。
--use-pytorch-cross-attention --fast --supports-fp8-compute
他のattentionのほうがよさそうな気もするが、このあたりは各自試してみて。
モデルをFP8化する方法は、旧い順に、
- FluxのFP8が出たときに公開されたコード
https://huggingface.co/Kijai/flux-fp8/discussions/7
SDXLでも使える。
- 上記をbatファイルで使えるようにしたものと思われるコード
Forge用にこれで変換している人が多いと思われる。
- ComfyUI用カスタムノード
上記batをComfyUIカスタムノードにしたものとのこと。
https://registry.comfy.org/ja/nodes/comfyui_diffusionmodel_fp8_converter
ComfyUI Managerから導入できる。
workflowもexmaple_workflowフォルダに入っている。
ComfyUI-ZLUDA トラブルシューティング
nccl.dll が隔離される そのため起動に失敗する
nccl.dll が隔離される事例がある。
セキュリティソフトにより nccl.dll が隔離される事例をとてもよく見る。
何度も繰り返し隔離されるようだ。
隔離されるともちろん起動できない。
なので、インストール直後に起動しなかったり、
また一度は起動に成功したのに翌日になると起動に失敗する場合は、
まずはセキュリティソフトが隔離していないか確認を。
この件は2025年1月頃から繰り返し起こっているようで、
ComfyUI-ZLUDAのサイトでは冒頭でこの件について触れている。
https://github.com/patientx/ComfyUI-Zluda
冒頭に書かなければならないくらい多発しているもよう。
VGAドライバー応答停止
VGAのドライバーが応答停止することがある。これはcuDNN/MIOpenに起因する。
たいてい、最後のVAE decode処理でVRAMを大量に消費しているときにおこる。
そういうときはたいていはTiled VAEを使うのだが、
ここでCFZ CUDNN ToggleノードをVAE decodeノードの前に噛ませてcuDNN/MIOpenを使わないようにしてやると、回避できることもある。
TritonがVGAを正しく認識しない
起動中にコンソールにTritonが認識するVGAが表示されるが、PCの構成によってはこれが違うVGAになることがある。
そのような場合はフォールバックの仕込みにより gfx1030 になるようになっているので、VGAがたまたまgfx1030ならそのまま問題なく使えるのだが、
違う場合は起動用batファイルで指定してやる。
例えば、VGAがgfx1100なら、起動用batファイルに下記を追記する。
set TRITON_OVERRIDE_ARCH=gfx1100
ここのVGAとgfx名については ZLUDAannex1 を参照のこと。
PCがしばらくフリーズ状態になる
生成中に、PCがしばらくフリーズ状態になる、しかもタスクマネージャーではVRAMもRAMもCPUもどれもまだ余裕がある、なんて場合は、たいていはVRAMが過剰に溢れている。
VRAMが溢れてメインメモリーに過剰な負荷がかかり、PCがしばらくフリーズ状態になる。
タスクマネージャーの表示上は余裕があるように見えるのは、負荷が高すぎてタスクマネージャーの表示更新処理ができないだけ。
VRAMが溢れるといっても少し溢れる程度ではこのような状態にはならないのだが、過剰にあふれるとメインメモリーに過剰な負荷がかかるようになり、PCがフリーズ状態になる。
原因は、VRAM容量に対して使用モデルが大きすぎたり、生成サイズが大きすぎ、動画だとサイズのほかに尺が長すぎなど。
対策は、モデルなら量子化で小さくしたモデルを使ったり、生成サイズを小さくしたり、尺を短くする。
また、Flash attentionやsage attentionを使ったり、動的VRAM/RAMスワップ機構を使うとVRAM使用量を減らせる場合もある。
もちろんVRAMが多いVGAに換装出来ればよいのだが、メインメモリーを増やすと効果がある場合もある。
動画に限りちょっと違うことがあり、
VRAM使用量と動画のサイズの関係だが、
本来であればサイズが大きくなるほどVRAMの使用量が増えてそして溢れるわけだけれども、
動画(workflow)によってはそのあたりはそうならないように作り込まれているものがあって、
画のサイズを少し大きくすると、逆にVRAM使用量が減ったりする。
それではVRAM使用量が減るに従い効率がどんどん落ちて生成時間が長くなっていくかというと、
ちょっとよくわからん。
この挙動は、ソースコードを読まないとはっきりしない感がある。
いずれにしても、このあたりは各自のPCのスペックにあわせて試行錯誤していくしかないようだ。
TAESD 軽量VAE
TAESD
https://github.com/madebyollin/taesd
特徴
特徴
軽量コンパクト、高速で省VRAMなVAE。
品質は落ちる。
一度は試す価値はある。
2025年現在で4種でそれぞれencoderとdecoderがあり、合計8ファイルある。
taesd: SD1.5用
taesdxl: SDXL用
taesd3: SD3用
faef1: Flux.1用
用途
主な用途
VAEで問題が起きたとき、問題の切り分け用に、標準VAEと比較用にTAESD VAEを使う。
高速で省VRAMなので普段使いしている人もいる。使い方によるが、割と使える。
たとえばVRAMが8GB機でSDXL生成する場合は、普段はTAESDで、当たりを引いたときは通常VAEにして同一seed値で清書。
導入方法 使い方
導入方法、使い方
A1111およびその派生は設定のVAEのところで TAESD に切り替える。それだけ。
ComfyUIの場合は要インストール。
まず、TAESDサイトから、拡張子 .pth ファイルをダウンロードする。
https://github.com/madebyollin/taesd
git pullでまとめてダウンロードしてもよいし、
ひとつひとつダウンロードしてもかまわない。
また、緑色の code ボタンをクリックするとDownload ZIPがあるので、
それでまとめて全部zipでダウンロードしてもよい。
ともかく入手する。
次に、ダウンロードした .pthファイルを、
ComfyUIのmodelsフォルダ内にあるvae_approxフォルダの中に.pthファイルをコピーする。
VAEフォルダではなくvae_approxフォルダ。
#たぶんVAEフォルダだとダメだと思う。
workflowにて標準ノードの VAE Loader を追加し、そこで例えばSDXLならtaesdxlを選択する。
ノードVAE LoaderとVAE Decodeを結ぶ。
なおComfyUI起動オプションは下記3種どれでも対応している模様。
#TAESDなら--fp32-vaeでいいんじゃないかな。だってTAESDだし。
--fp16-vae --fp32-vae --bf16-vae
SDXLのVAE用 Flash Attention 2 カスタムノード
ComfyUIで使える、SDXLのVAE用 Flash Attention 2 カスタムノード。
VAEの処理に Flash Attention 2 が使える。
SDXLのVAE処理時の attention は、通常は
Split attention
pytorch attention
のどちらかで、ComfyUI-ZLUDAでは先のmodel_management.pyの改編をしていればVAE処理時のは Split attention になる。
ここで、ComfyUI-ZLUDAの高機能版では Flash Attention 2 が導入されているので、そこで、
SDXLのVAE処理においても Flash Attention 2 を使えるようにするべく、 custom node を作成した。
#ついでにQuadAttentionなど他のも作成してうまく動いたのだけれど、長くなるのでボツにした。
いちおう本カスタムノードはComfyUI-ZLUDAの高機能版で使うためのものだが、特にそれ専用というわけでもなく、Tritonが入ればFlash Attentinon2を導入出来るので、たとえばROCm/TheRockで別途TritonとFlash Attention2を導入すれば、それらでも使える。
利点:
- 省VRAM。結果として速い。
欠点:
- 同一seedであっても毎回細部が変化する。これはそもそもの Flash Attention の仕様。このバラツキ延長で、ごくまれに黒画面が生成されることもある。
- ComfyUI起動後の初回生成時は処理に若干もたつく。
- 一度このカスタムノードを通過すると、ノードを外してもその影響が出る。これは、メモリー上のVAEを直接操作してしまっているため。ComfyUIを再起動すると元に戻る。なおこの問題を回避するコードは可能だが、やらず。
- SDXL専用なので、他では使えない。
速度と省VRAMは、TAESDは別物なので例外とすると、VAEに Flash Attention 2 は速いほうだ。
特にVRAMがわずかに足りてないような場合は効く。そういう場合は、通常はquad-cross-attentionでVAEだけFlash attentnio2にするなんてのにするとよさげ。
速度が向上するにもかかわらず画の品質はそれなりに保たれているので、TAESDのような劣化は無い。
インストール方法/使用方法
インストール方法/使用方法:
ComfyUIのフォルダ内に custom_nodesフォルダがあるので、その中に
新規にフォルダを ComfyUI-vaeDecodeFlashAttnSDXL という名前で作成し、
その中に下記2ファイル__init__.pyとvae_decode_flash_attn_SDXL.pyを作成する。
そしてComfyUIを再起動し、
SDXLのworkflowを開いて、
そこにあるVAE DecodeノードをVAE Decode FlashAttn SDXLに入れ替える。
なお、ComfyUIの起動時のオプションにて、
--use-split-cross-attention
--use-quad-cross-attention
--use-pytorch-cross-attention
--use-sage-attention
--use-flash-attention
このなかのどれにするかで、速度重視や省VRAM重視などを選べる。組み合わせで結構違う。
__init__.py ファイル
from .vae_decode_flash_attn_SDXL import NODE_CLASS_MAPPINGS, NODE_DISPLAY_NAME_MAPPINGS
__all__ = ['NODE_CLASS_MAPPINGS', 'NODE_DISPLAY_NAME_MAPPINGS']
vae_decode_flash_attn_SDXL.py ファイル
import torch
from flash_attn.flash_attn_interface import flash_attn_func
class FlashAttnBlock(torch.nn.Module):
def __init__(self, channels):
super().__init__()
self.norm = torch.nn.GroupNorm(32, channels)
self.q = torch.nn.Conv2d(channels, channels, 1)
self.k = torch.nn.Conv2d(channels, channels, 1)
self.v = torch.nn.Conv2d(channels, channels, 1)
self.proj_out = torch.nn.Conv2d(channels, channels, 1)
def forward(self, x):
h = self.norm(x)
q = self.q(h)
k = self.k(h)
v = self.v(h)
b, c, h_, w_ = q.shape
seq_len = h_ * w_
head_dim = 64
num_heads = c // head_dim
assert c % head_dim == 0, f"channels ({c}) must be divisible by head_dim ({head_dim})"
q = q.reshape(b, num_heads, head_dim, seq_len).permute(0, 1, 3, 2)
k = k.reshape(b, num_heads, head_dim, seq_len).permute(0, 1, 3, 2)
v = v.reshape(b, num_heads, head_dim, seq_len).permute(0, 1, 3, 2)
print(f"[FlashAttention2] x.dtype={x.dtype}, q.dtype={q.dtype}, q.device={q.device}")
out = flash_attn_func(q, k, v, dropout_p=0.0, softmax_scale=None, causal=False)
out = out.permute(0, 1, 3, 2).reshape(b, c, h_, w_)
out = self.proj_out(out)
return x + out
class VAEDecodeFlashAttnSDXL:
@classmethod
def INPUT_TYPES(cls):
return {
"required": {
"samples": ("LATENT",),
"vae": ("VAE",),
},
}
RETURN_TYPES = ("IMAGE",)
FUNCTION = "decode"
CATEGORY = "custom_nodes/VAE"
def decode(self, vae, samples):
decoder = vae.first_stage_model.decoder
replaced_parent_modules = set()
all_module_names = [name for name, _ in decoder.named_modules()]
for name in all_module_names:
if any(name.startswith(parent_name) for parent_name in replaced_parent_modules):
continue
module = decoder.get_submodule(name)
is_attention_block = (
hasattr(module, 'q') and
hasattr(module, 'k') and
hasattr(module, 'v') and
hasattr(module, 'norm') and
hasattr(module, 'proj_out') and
not isinstance(module, FlashAttnBlock)
)
if is_attention_block:
path_parts = name.split('.')
parent_module = decoder
if len(path_parts) > 1:
parent_name = ".".join(path_parts[:-1])
parent_module = decoder.get_submodule(parent_name)
child_name = path_parts[-1]
channels = module.q.in_channels
model_device = next(decoder.parameters()).device
model_dtype = next(decoder.parameters()).dtype
new_block = FlashAttnBlock(channels).to(device=model_device, dtype=model_dtype)
setattr(parent_module, child_name, new_block)
replaced_parent_modules.add(name + '.')
print(f"[VAE Decode FlashAttn] Replaced '{name}' with FlashAttention2 on {model_device}, dtype {model_dtype}")
decoded_image = vae.decode(samples["samples"])
return (decoded_image,)
NODE_CLASS_MAPPINGS = {
"VAEDecodeFlashAttnSDXL": VAEDecodeFlashAttnSDXL
}
NODE_DISPLAY_NAME_MAPPINGS = {
"VAEDecodeFlashAttnSDXL": "VAE Decode FlashAttn SDXL"
}