ローカル高速化メモ

torch2

現在、torch2がデフォルトになりました。
Hyper-SDなどの改造不要の最適化やパラメータの調整で速くできるのでtorch.compile改造はおすすめしません。

古い情報

CUDA使用率

画像生成速度には、CUDA使用率が大きく影響する。
アスカベンチで同じグラボの他人の結果より明らかに遅い場合、なんらかの原因でCUDAがフルに使われていない可能性もある。
（これを確認する場合、Win11なら、GPUスケジューリングをオフにしてタスクマネージャーで項目をクリックしてCudaに切り替えるのが簡単）
このページにある対策を行ってもアスカベンチで期待したパフォーマンスが出ない、という場合でも、高解像度やHires fixした場合は512x512単体生成よりもCUDAがフルに使われやすい傾向があるので、
もしそっちでCUDA使用率が100%近くなってて、そういう生成方法がメインだという場合は、アスカベンチで劣っていても気にしなくていい可能性もある。

ちなみに、速度が速いほどCPUのシングル性能の影響が大きくなる。旧世代CPUを使っているなら最新世代のCPUに買い替えるのもあり。

モジュールによる高速化

環境によりますが、xformersかsdpによって速度が変わることはないと思われます。

古い情報

2023-03-19現在、たぶんこの順で速い。

1. torch2 cu118 --opt-sdp-no-mem-attention torch.compile(不安定)(Linux限定)
2. torch2 cu118 --opt-sdp-no-mem-attention
3. torch1 cu117 xformers cudnnのバージョンアップ

torch2 cu118 --opt-sdp-no-mem-attention/--opt-sdp-attention

xformersはnvidia限定だがこっちはRadeonでも動くはず。
環境によっては--opt-sdp-attentionのほうが高速?

詳細説明

導入した人たちの感想（ある程度集まったらまとめます）

297今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった (ﾜｯﾁｮｲ d112-SwXs)2023/03/19(日) 20:04:41.62ID:pGBhW2el0
ワイも
torch: 2.0.0+cu118
にして、xformersじゃなくsdpっていうのにしたんやけど
30it/sが35it/sになったから効果はあったと思うわ

ただし生成結果が変わって前の絵を全て捨てる事になる諸刃の剣やな

336今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった (ﾜｯﾁｮｲ a1c3-7LVk)2023/03/19(日) 20:55:05.01ID:Mipkannl0>>345
torch2.0にしたらなんかVRAMの消費量上がる？
なんかすぐにメモリアウトするし、生成後にメモリ使用率が下がらんくなった
当方3060TI　vram8Gや

459今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった (ﾜｯﾁｮｲ 1154-CSnB)2023/03/20(月) 01:02:56.60ID:fmUx+vru0
>>449
起動時のコマンドラインに--opt-sdp-no-mem-attention付けた？x-formerの代わりや
--opt-sdp-attentionの方が速いとか言うけどこっちは生成する度に結果が微妙に違うガバガバやし上とほぼ速度差なかったわ

467今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった (ﾜｯﾁｮｲ 13ba-2lPJ)2023/03/20(月) 01:26:42.72ID:0uuy3D7h0>>516
torch2にしたらddetailer使えなくなってた

488今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった (ﾜｯﾁｮｲ 1154-BQ3C)2023/03/20(月) 02:09:36.21ID:mGnI1SHN0>>493
>>449だが、ちゃんとアスカベンチ回して全部計測してきた
RTX4070ti
　38.1s torch1.13.1+cu117
　22.2s torch1.13.1+cu117+cudnn更新
　19.9s torch2.0.0.1+cu118
元々cudnnは更新済みだったけどそこから少しだけ早くなってたけど思ったほどではなかった
こんなもんかな？

583今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった (ﾜｯﾁｮｲ e17b-CSnB)2023/03/20(月) 10:47:01.35ID:zgEqc5Jw0
torch2入れたけどlora使った時の生成速度上がって幸せになれた

379今、天王星のwiki見てきたら軌道傾斜角(i) が0.774°だった (ﾜｯﾁｮｲ c97b-DkPe)2023/03/21(火) 18:53:37.44ID:R54ixFAd0
GTX1080でtorch2+cu118にxformerビルドして入れてみたが
大体5秒くらいしか早くならんな
RTX4090ほちい

xformers

Meta Researchが開発した最適化ライブラリ。高速化とVRAM消費減少効果がある。
インストールは1111の標準機能で簡単にできる。
このオプションをつけるとわずかに出力内容が変化し、常に同じ結果にならない。
とはいえ体感できるか難しいほど小さい変化のため気にする必要はない。

変化の検証ページ作ったので記録はこちらへ
→「xformersの検証」

対応GPU

NVIDIA
GeForce GTX 1000(Pascal)、RTX 2000(Turing)シリーズ以降
GeForce 900番台以前でも動くけど逆効果だったという報告あり

導入方法

初めて導入する場合

set COMMANDLINE_ARGS= --xformers

古い環境から更新する場合

set COMMANDLINE_ARGS= --reinstall-torch --reinstall-xformers

venvを削除してからWebUIを起動する手もあり

Torchバージョンが1111のデフォルトではない場合
ここで対応するTorchバージョンを確認してから、「pip install xformers==x.x.x」でインストールする。

開発版をインストールする

pip install --pre -U xformers

でコンパイル無しで導入できるようになった。
なお、対応するTorchバージョンが入っている必要がある。

アスカテストのtime taken
--xformers --opt-sdp-attention　18.50
--xformers　20.30
--opt-sdp-attention　18.47
--opt-sdp-no-mem-attention　18.40
--xformers --opt-sdp-no-mem-attention　18.60
両方指定の場合はsdpが有効になってる雰囲気です

torch.compile(非推奨)

NVIDIAがTensorRTを使えるようにするExtensionを公開したのでそちらを推奨。改造不要でTensorRTが使える。

以下は上級者向け。またWebUIのアプデで以下の手順が使えない可能性あり。
(TensorRTみたいな感じで)モデルの事前コンパイルを行うことによって、
生成処理を高速化する仕組みがtorch2には実装されている。
これを1111で使えるように改造する。

Windowsには対応していない(WSL2で動かすことになる)

手順

参考
https://github.com/AUTOMATIC1111/stable-diffusion-...

前提として、torch2で1111が動作できていること。

1. modules/sd_hijack.pyのself.optimization_method = apply_optimizations()の前に次のコードを入れる(L171-172)
インデントの位置が前後と揃うようにする。

        try:
            import torch._dynamo as dynamo
            torch._dynamo.config.verbose = True
            torch.backends.cudnn.benchmark = True
            m.model = torch.compile(m.model, mode="reduce-overhead", fullgraph=False)
            print("Model compiled set")
        except Exception as err:
            print(f"Model compile not supported: {err}")

modeはdefault, reduce-overhead, max-autotuneから選べます
max-autotuneは10分以上かかる割に効果が薄かった
defaultだとコンパイル半分くらいで済む。こっちでも良いかも？

なお、残念ながら8GBの環境ではcompile完了前にCUDA OOMで死にました・・・。
reduce-overheadだとVRAMを食っていくけどdefaultだと消費しないので完走できる。だけど速さは感じない。
3060でreduce-overheadを試したら9.6GBだったので10GBあれば使えるかも。速さは劇的ってほどではない。
samplerは変えても再コンパイルは走らなかった。

2. repositories/stable-diffusion-stability-ai/ldm/modules/diffusionmodules/util.pyのcheckpointメソッドを編集(L113-114)
(これをしないとエラーになる)

- return CheckpointFunction.apply(func, len(inputs), *args)
+ return CheckpointFunction.apply(func, len(inputs), *inputs, *params)

バッチサイズ等を変えた後にGenerateを押すと返ってこなくなることがあります。リロードすると直る。この辺動作が怪しいです。

xformersは必要ない。
以下の警告が出るけど無視しても動く。

/home/user/stable-diffusion-webui/venv/lib/python3.10/site-packages/torchvision/transforms/functional_tensor.py:5: 
UserWarning: The torchvision.transforms.functional_tensor module is deprecated in 0.15 and will be **removed in 0.17**. 
Please don't rely on it. You probably just need to use APIs in torchvision.transforms.functional or in torchvision.transforms.v2.functional.
  warnings.warn(

必要なかったこと

1111標準のaccelerate==0.12.0を少なくとも0.15.0以上に更新する必要がある
- この類の問題を克服するためにsd_dreambooth_extensionをpip更新ツールとして使う手がある

出来ればやりたいこと

コンパイルしたいモデルとしたくないモデルを選択したくなる気がする

--opt-channelslast

これはつけるだけ。

--xformers や --opt-sdp-no-mem-attention と併用できる。

環境によっては効果が無かったり逆に遅くなったりするらしいので比較検討しましょう。

ハードウェアアクセラレーションによるGPUスケジューリングを無効にする

VRAM消費を減らす効果がある。速度も向上するかも。
やり方はこちら
公式wikiにも記載がある
redditによれば速度が30%くらいかわることがあるとかないとか
副作用としてDLSS3のフレーム生成が使えなくなる？

モデルを軽量化する

2024年現在、fp16,pruned,safetensorsでの配布(=すでに軽量化された状態)が主流になった。

古い情報

ckptとvae.ptをsafetensorsに変換する
- 最近はckptよりsafetensorsで配布するほうが主流になった。
- vae.ptはWindows Defenderが誤検出を起こすので回避のためにも変換するのが良さそう
  - 変換すると場合によって容量が約半分になる(NAIはそうだった)
pruneする
- VRAMの節約になるかも?
fp16化する

fp16化の副作用として、modules.devices.NansException が発生する。
特にNovelAI系のVAEで発生しやすい(NovelAI,ClearVAE1.0,Nenhanceなどが該当)。

対策としては、fp32で計算するように強制する。(高速化としては本末転倒だけど)

--no-half や--no-half-vae を追加する。速度は落ちてVRAM消費が大幅に増加する。

たまに真っ黒画像が出てもいいから高速化したいのであれば、
disable-nan-checkを追加する手もある。
それと、黒画像は大体VAEが原因なのでNovelAI系VAEを使わない手もある。

VAEをckptに内蔵する

1111に標準で入っているCheckpoint Mergerでもできるようになっている
マージ対象Aに内蔵先モデルを指定して、Interpolation Method を No interpolation 指定
Bake in VAEで内蔵するVAEを選択してマージする

fp16化したモデルにマージするとVAE部分もfp16になる。
それによる高速化も起こりうるかも。
高速化しないと言っている人もいるので検証できたら追記お願いします。

ということでお気持ち表明に反証するで

Extensionsの退避や削除

しばらく使わないときは Dreambooth Extension を削除する(もう使ってない?)
起動時間が劇的に変わる

Extensionにはinstall.pyが同梱されていて毎回起動するので、
不要なExtensionが沢山入ってるなら消すだけでだいぶ速くなるはず。

UIからオフにするだけではダメ
フォルダごと別の場所に退避させとくとか、いっそバッサリ消すとか

LyCORIS Extensionを削除する

1111がLyCORISに標準で対応したためこのExtensionは不要。
このExtensionは今となっては生成を遅くするだけ。

Stepsを減らす

出来るだけ少ないStepsでも期待通りの絵が出る方法を模索する。
末尾にa(ancestral)がつかないサンプラーで再現できないか試す。
DPM++ 2Mは15Stepsでもそれなりに映えるのでおすすめ。
~~UniPCはもっと良い感じ。~~実際はそうでもない。
SchedulerにSimpleを使うとさらに良くなる。
LCM、TurboやHyper-SDはさらに速い。出力を大きく変化させる代わりに10steps未満でまともな絵がでる。

WebUIを高速なストレージに入れる

シーケンシャル3GB以/s上のSSDに配置することで読み込みを高速化する。大容量なSDXLに効果的。

メインメモリを使う

モデルのロード時間を短縮するために、あらかじめRAMに読みこんでおくことが出来る。

Settings - Stable Diffusion

Checkpoints to cache in RAM
VAE Checkpoints to cache in RAM

SuperMergeでもモデル3つのトリプルマージまでRamで高速化できるようになった。
詳しくはローカルのExtensions の SuperMerger を参照。

新しい機能などのために RamDisk が使いたくなったら ImDisk Toolkit が使いやすい。
https://sourceforge.net/projects/imdisk-toolkit/

1111 全部 RamDisk に突っ込んで高速化するのは、必要RAMのわりに恩恵がほとんど無いからおすすめしない。

WSL2で使う

1111_WSL2

以前はLinuxにするだけで1～2割速くなると言われていたが、ドライバやTorchの最適化が進んで速度やメモリ消費の差が小さくなった。
どっちが速いか比較検討してみるのが良さそう。

Linuxに入れる

Windows上の仮想化ではなく実際にインストールする。
Ubuntu24.04 LTS、Python 3.11.9、Torch2.3.1での環境では、推論は2～4%、学習は10%高速化した。VRAM消費は特筆すべき変化はなかった。
またmevram有効時の1111のメモリ消費が激減し、生成開始と終了のもたつきが軽減し、ReForgeとほぼ同じ速度を出せるようになった。いいぞこれ

あと1111やsd-scriptsなどでcheckpoint読み込み中のメモリ消費が跳ね上がる現象がない。

Windowsが入っていない空っぽのSSDに入れるか、サブ機とかお古になったら検討してもいいかも
なお各種ライブラリ等のインストールは原則コマンド打ってやるし、途中でUbuntuのGUI(gdm3)が壊れてリカバリーモードでgdm3を再インストールしたりとかなり面倒

TensorRTを使う

https://github.com/NVIDIA/Stable-Diffusion-WebUI-T...
最適化で大幅に高速化するもので最大2倍速くなるらしい。NVIDIA専用。
1111のExtensionから導入できる。

けど以下の重大な欠点があるのでベンチ以外で使い道はないかな

あらかじめ設定した解像度のみ使用可能
TensorRTモデル変換に時間がかかるしVRAM消費が激しい(しかもOOMになるとWebUI本体がフリーズ)
LoRAはTensorRT変換で埋め込んで使えるが1つしか使えない
ControlNetのようなU-netに干渉するものは一切使えない
Extensionのインストールが不安定で失敗しやすい

venvをいったん消して作り直す

Windows再インストール並みの最終手段。
最新の1111に必要なものしか入らなくなるので軽くなる、かも。
Extension試しまくってると肥大化するので月イチくらいでやるといいかも。

別のUIを使う

1111のWebUIを速くする方法でこれを書くのは本末転倒だが、ほかのUIを使う手もある。
AUTOMATIC1111のWebUIは最近になって速度が改善されたが、Windows版のメモリ消費の多さは変わっていない。Forgeのほうが速くて省VRAM、ComfyUIは速くて省メモリで省VRAM。

GPUを買い替える

ソフトウェア側であれこれ必死にやっても劇的に速くならないのが現実。結局ハードウェアの強化が一番。
場合によっては他のパーツの買い替えも必要になるが、最も効果的。
(give me money:3000.0)

このページを編集するこのページを元に新規ページを作成

印刷する

コメント（2）

カテゴリ：
漫画/アニメ
総合

ローカル高速化メモ - NovelAI 5ch Wiki 先頭へ

タグ

ローカル部

このページへのコメント

TensorRTは拡張機能で運用が楽になったのでおすすめ
アスカベンチ基準で1.6倍程度早くなる

Posted by 名無し(ID:UkNtPSqMXA) 2023年10月25日(水) 00:51:33 返信

--opt-channelslastで使う
5u34v576.7zだけど
人によっては使わない方が良いかもしれない

ここのところ何回か環境構築してるけど
うちで3060でだと､入れないで
オプションにxformersとopt-channelslastと言う形で
Hello Asuka Benchmarkで40.03sと言う数字が出た

5u34v576.7zの中身を入れると43s台後半という酷い数字に

Posted by 名無し(ID:sfrkRBi+dw) 2023年01月09日(月) 20:42:06 返信

コメントをかく

名前	ユーザIDを使用しないで書き込む	ユーザーIDを使う	ログインする
備考	「http://」を含む投稿は禁止されています。
本文
利用規約をご確認のうえご記入下さい

NovelAI 5ch Wiki

torch2

CUDA使用率

モジュールによる高速化

torch2 cu118 --opt-sdp-no-mem-attention/--opt-sdp-attention

torch2.0+SDP(要検証)

xformers

対応GPU

導入方法

開発版をインストールする

torch.compile(非推奨)

--opt-channelslast

ハードウェアアクセラレーションによるGPUスケジューリング を無効にする

モデルを軽量化する

VAEをckptに内蔵する

Extensionsの退避や削除

LyCORIS Extensionを削除する

Stepsを減らす

WebUIを高速なストレージに入れる

メインメモリを使う

WSL2で使う

Linuxに入れる

TensorRTを使う

venvをいったん消して作り直す

別のUIを使う

GPUを買い替える

このページへのコメント

コメントをかく

Menu

はじめに

技術解説・ツール紹介

プロンプトテクニック

部活動

Prompts

R18系Prompts

ローカル部

なんJnovelAI部過去ログ

Wiki

最近更新されたスレッド

2024-07-24

2024-07-20

2024-07-17

2024-07-12

最近更新したページ

2024-07-26

2024-07-25

2024-07-24

2024-07-23

2024-07-22

2024-07-21

最新コメント

2024-07-26

2024-07-25

2024-07-23

2024-07-22

QRコード

table拡張js

アクセス解析中

ハードウェアアクセラレーションによるGPUスケジューリングを無効にする