TnsorRT用に画像生成AIのモデルを変換して爆速で生成できるWebUI「Lsmith」をWLS2エンジンを用いたDocker Desktopにインストールして動かす方法を解説します。
公式によると従来のStable Diffusion WebUI(1111)の4倍に高速化できます。
この魔法のような技術を、今回はWin11のWSL2エンジンで動くDocker版で試してみました。
![](https://economylife.net/wp-content/uploads/2023/02/image-61-1024x257.png)
1,事前準備
- Windows 11
- WSL2インストール済み
- Docker Desktopインストール済み
- Gitインストール済み
これら4点をインストールしていない方は、まず以下の記事通りにしてインストールしてください。
全部の準備に30分もかかりません。(回線速度次第ですが)
2,Lsmithをダウンロード
![](https://economylife.net/wp-content/uploads/2023/02/image-61-1-1024x451.jpg)
適当なフォルダを作成し、そのフォルダ内で右クリック→「ターミナルで開く」をクリック。
![](https://economylife.net/wp-content/uploads/2023/02/image-43-2.jpg)
そして以下のコマンドをまるごとコピペしてエンターします。
git clone https://github.com/ddPn08/Lsmith.git
cd Lsmith
改行が含まれているので云々と警告されますが、「強制的に貼り付け」してください。
その後、以下のコマンドを入力。
git submodule update --init --recursive
これでGitはおしまいです。
あとはDockerで起動するだけ。
3,Dockerで起動する
インストールを行う
まずDocker Desktopを起動します。
![](https://economylife.net/wp-content/uploads/2023/02/image-37-1024x511.jpg)
Windowsボタンを押して、検索窓に「docker」と入力し、Docker Desktopを起動します。
その後以下のコマンドを入力します。
docker-compose up --build
そして10分くらい待ちます。
この時エラーが出る方は、Dockerを起動していないのが原因です。(多分)
![](https://economylife.net/wp-content/uploads/2023/02/image-47.jpg)
タスクバー右下にちゃんとクジラさんマークが表示されているか確認してください。
Docker起動時はこのマークがあるはずです。
![](https://economylife.net/wp-content/uploads/2023/02/image-48-1024x407.png)
水色の文字がいっぱい出て進捗を教えてくれます。
私の時は7分くらいかかりました。
[+] Building 398.5s (15/15) FINISHED
![](https://economylife.net/wp-content/uploads/2023/02/image-49.jpg)
インストール終了後、ファイアウォールの警告が出たら、
「プライベートネットワーク」「パブリックネットワーク」それぞれにチェックを入れて
「アクセスを許可する」を選択。
![](https://economylife.net/wp-content/uploads/2023/02/image-49.png)
この「 Installing torch」で進捗表示もなく5分くらい待たされますが、正常です。
変にクリックとかせず待ちます。
![](https://economylife.net/wp-content/uploads/2023/02/image-50-1024x185.jpg)
INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
上記の1文が出たらインストール終了です。
お疲れ様でした。
ブラウザ検索窓に「http://127.0.0.1:8000/app/」と打ち込みWebUIにアクセスします。
![](https://economylife.net/wp-content/uploads/2023/02/image-51-1024x386.png)
各種設定:Lsmith WebUIモデルをTnsorRT用に変換
![](https://economylife.net/wp-content/uploads/2023/02/image-52.jpg)
「Engine」メニューに移ります。
![](https://economylife.net/wp-content/uploads/2023/02/image-55-1024x495.jpg)
Model ID (required)
変換元モデルを指定します。
モデルまとめページで適当に選びましょう。
ここではAnything v4.0にしました。
andite/anything-v4.0
Hugging Face Access Token
通常は空欄でOK。
アクセストークンがないとダウンロードできないモデルを変換したい時は、HuggingFaceのアクセストークンを入れましょう。
Optimization Image Width/Height
最適化する画像サイズ(横/縦)
デフォは縦横ともに512です。
もしや同じモデルでも512×768の縦長最適化モデルと、768正方形最適化モデルを別に用意する時代が来る?!
大抵は両方512 or 768でしょう。
Denoising precision
モデル精度を選択します。
- float32
- float16
おすすめはfloat16です。
でもエラーが出やすいので、エラーが出たらfloat32(fp32)にします。
Max batch size
ビルドのバッチサイズです。
ハードウェアリソース次第ではバッチサイズを増やしてモデル最適化時間を短縮できます。
訂正:ココのバッチサイズは画像生成時の並列生成枚数のことでした。
その他設定
- Build static batch 静的バッチでビルド
- Build dynamic shape ダイナミックシェイプ(???)をビルド
- Build preview features ビルドをプレビューする(??)
- Force engine build 強制ビルド
- Force onnx export Onnxの強制エクスポート(??)
- Force onnx optimize Onnxの強制最適化(??)
- Onnx minimal optimization Onnxの最低限の最適化(??)
![](https://economylife.net/wp-content/uploads/2023/02/image-53-1024x228.jpg)
全体的に何言ってるか分からないので、デフォルト通りに
「Build dynamic shape ダイナミックシェイプをビルド」のみチェックします。
おすすめの設定まとめ
![](https://economylife.net/wp-content/uploads/2023/02/image-54-1024x509.jpg)
変換を実行する
中央下部の「Build」ボタンでスタートです。
エラーが出たらモデル精度をfloat32(fp32)にします。
大抵それで動き出します。
コンソールにこんな感じで表示されたら、変換が正常にスタートしています。
Exporting model: models/andite/anything-v4.0/onnx/unet.onnx
Downloading (…)_pytorch_model.bin”;: 100%|██████████| 3.44G/3.44G [02:47<00:00, 20.5MB/s]
Downloading (…)ain/unet/config.json: 100%|██████████| 1.02k/1.02k [00:00<00:00, 2.23MB/s]
WebUI側でも確認できます。
![](https://economylife.net/wp-content/uploads/2023/02/image-56-1024x195.png)
This may take about 10 minutes. Please wait until the process is finished.
10分くらい変換にかかるようです。気長に待ちましょう……
変換中のシステム負荷
![](https://economylife.net/wp-content/uploads/2023/02/image-55.png)
諸々で15GBくらいRAMを使用するので、ブラウザなどは閉じたほうが良いかもしれません。
![](https://economylife.net/wp-content/uploads/2023/02/image-57.png)
VRAMももちろんドカ食いです。
VRAMが24GBもなくてもモデル変換自体はできます。
RTX3060の動作事例あるので。勿論遅くなります。
変換されたモデルを使用する
![](https://economylife.net/wp-content/uploads/2023/02/image-59-1024x241.png)
Success!
The model has been built successfully. You can now generate images!
上記のようにモデル変換が終わったらお知らせしてくれます。
では「Generate」メニューに移動します。
![](https://economylife.net/wp-content/uploads/2023/02/image-58.jpg)
そして変換したモデルを選択します。
この時、モデルをリロードすること!!!
![](https://economylife.net/wp-content/uploads/2023/02/image-60.jpg)
あとはいつも通り諸々プロンプトやサンプラーを選び生成です。
4,DockerのLismthを起動・シャットダウンする方法
Lsmithを起動する方法
まずWindowsでDockerを起動します。
「Containers」メニューのLsmithっぽい名前のイメージを選択し、再生ボタンを押して起動します。
![](https://economylife.net/wp-content/uploads/2023/02/image-64-1-1024x428.jpg)
デフォルト設定ではポート8000を利用するので、「http://localhost:8000/app/」にアクセスしてください。
再生ボタンを押した数秒後にはもう起動しています。
1111版より高速で嬉しいですね☆
Lsmithを終了する方法
Dockerのマークであるクジラがタスクバーにあるので、クジラマークを右クリック→Dashboardをクリックします。
![](https://economylife.net/wp-content/uploads/2023/02/image-63.jpg)
そして起動時同様に「Containers」メニューのLsmithっぽい名前のイメージを選択し、Stopボタンを押します。
![](https://economylife.net/wp-content/uploads/2023/02/image-64-2-1024x537.jpg)
停止には10秒くらいかかります。
5,どれくらい高速になるのか検証!!
比較条件と意図
WebUI(1111版)での普通モデルでの生成と比較してみます。
HuggingFaceのモデルを変換する関係でNAIは不可なため、モデルはAny v4でいきます。
fp16のTensorRT変換はエラーで失敗したため、fp32で変換しました。
そのため比較するモデルは以下の3つです。
- 1111にて。その1:anything-v4.0-pruned-fp32.safetensors
- 1111にて。その2:anything-v4.0-pruned-fp16.safetensors
- Lsmith WebUIにて:TensorRT変換後のanything-v4.0 精度fp32
モデル以外は統一して10枚(バッチサイズ1)で生成して、所要時間の平均を比べます。
なおパラメータを考えるのが面倒なのでアスカテストのモデルだけ違う版でいきます。
- masterpiece, best quality, masterpiece, asuka langley sitting cross legged on a chair
- Negative prompt: lowres, bad anatomy, bad hands, text, error, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, normal quality, jpeg artifacts,signature, watermark, username, blurry, artist name
- Steps: 28,
- Sampler: Euler,
- CFG scale: 12,
- Seed: 2870305590,
- Size: 512×512,
- Model hash: 変更して比較
- Clip skip: 2,
- ENSD: 31337
現時点のLsmith WebUIにはVAE選択機能がないので、公平にするため1111版もVAEなしで行きます。
なお、高速を目指した1111版と比べるため、1111版ではckptでなくsafetensors版モデルを使用し、xformersを有効にし、RAMに格納した上で比較します。
比較結果
![](https://economylife.net/wp-content/uploads/2023/02/image-62.png)
モデル | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 | fp16を1とした時の割合 |
anything-v4.0-pruned-fp32.safetensors | 13.20 | 13.34 | 13.18 | 13.36 | 13.28 | 13.27 | 1.004 |
anything-v4.0-pruned-fp16.safetensors | 13.28 | 13.12 | 13.22 | 13.20 | 13.27 | 13.22 | 1.000 |
TensorRT 変換後fp32 | 8.09 | 7.99 | 7.97 | 8.03 | 7.99 | 8.01 | 0.606 |
結果として、1.4倍速でした。
前評判が4倍速ってのを踏まえると肩透かし感がありますが、ハードウェアは同一なのにここまで早くなるのは目覚ましい進化ですね!!
なおsteps数が大きいほどモデル変換の恩恵が大きくなります。
150stepsで1枚生成を何度か繰り返した際は、大体fp16版の1111での2倍速になりました。
fp16精度でのモデル変換ができていれば違ったんでしょうか?!
あるいはDockerが低速化の原因か…⁈
webUI(1111)で、fp32かつckpt版のモデルを使用し、RAMにモデルを格納せず、xformars無効、VAE有効で比較をやればもっと劇的な差だったんでしょうが。。。
実用的でない検証しても役に立ちませんが、時間があれば1回くらいハンデ戦しても良いかもしれません。ハンデ付きなら本当に以下のように4.19倍になるか⁈
![](https://economylife.net/wp-content/uploads/2023/02/image-61-1024x257.png)
追記:せっかくなのでハンデ戦してみました。
アスカベンチほど本格的にはせず、公式例どおり150stepsで1枚生成を3回やってみました。
(パラメーターは以下通り)
1girl,solo, hatsune miku,
Negative prompt: lowres, bad anatomy, bad hands, text, error, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, normal quality, jpeg artifacts,signature, watermark, username, blurry, artist name
Steps: 150, Sampler: DDIM, CFG scale: 7, Seed: 1753076808, Size: 512×512, Model hash: 357b1f1ce6, Model: anything-v4.0-pruned-fp32, Clip skip: 2, ENSD: 31337
ただしWebUI(1111)のみ
- ckpt版のモデル
- RAMにモデルを格納しない
- xformars無効
- VAE有効
以上4点のハンデを付けました。
2022年10月くらいの平均的生成環境にxformars無効を加えた感じ。
ハンデ戦 | 1回目 | 2回目 | 3回目 | 平均 | 割合 |
automatic1111 | 11.30 | 11.38 | 11.16 | 11.28 | 2.729 |
Lsmith(WSL2+Docker) | 4.18 | 4.07 | 4.15 | 4.13 | 1 |
Lsmith(win11直接) | 4.29 | 4.17 | 4.25 | 4.24 | 1.025 |
結果としてはTnsorRT変換後は2.7倍速でした。
公式の約4倍には届きませんが、色々な1111での高速化を無視して比べればかなり高速になった実感があります。
これ以上はWSL2+DockerでなくネイティブWindows環境でなきゃダメかも……
さらに追記:Lsmith(win11ネイティブ環境で動作)でも検証しましたが、表の通り、2.5%=誤差程度に若干遅いだけですた…
ひとまず40%高速化を喜びましょう!!
今回のより遥かに容易に3割高速化できる方法もご覧ください。webui(1111)で完結します。
また、webui(1111)では、これでさらに7%高速化できます。