TensorRTで画像生成4倍速？！にするLsmithをWindows(Docker WSL2)にインストールする手順まとめ

TnsorRT用に画像生成AIのモデルを変換して爆速で生成できるWebUI「Lsmith」をWLS2エンジンを用いたDocker Desktopにインストールして動かす方法を解説します。
公式によると従来のStable Diffusion WebUI(1111)の4倍に高速化できます。

この魔法のような技術を、今回はWin11のWSL2エンジンで動くDocker版で試してみました。

１，事前準備
２，Lsmithをダウンロード
３，Dockerで起動する
４，DockerのLismthを起動・シャットダウンする方法
- Lsmithを起動する方法
- Lsmithを終了する方法
５，どれくらい高速になるのか検証！！
- 比較条件と意図
- 比較結果

１，事前準備

前提とする環境

Windows 11
WSL2インストール済み
Docker Desktopインストール済み
Gitインストール済み

これら4点をインストールしていない方は、まず以下の記事通りにしてインストールしてください。

全部の準備に30分もかかりません。（回線速度次第ですが）

２，Lsmithをダウンロード

適当なフォルダを作成し、そのフォルダ内で右クリック→「ターミナルで開く」をクリック。

そして以下のコマンドをまるごとコピペしてエンターします。

git clone https://github.com/ddPn08/Lsmith.git
cd Lsmith

改行が含まれているので云々と警告されますが、「強制的に貼り付け」してください。

その後、以下のコマンドを入力。

git submodule update --init --recursive

これでGitはおしまいです。

あとはDockerで起動するだけ。

３，Dockerで起動する

インストールを行う

まずDocker Desktopを起動します。

Windowsボタンを押して、検索窓に「docker」と入力し、Docker Desktopを起動します。

その後以下のコマンドを入力します。

docker-compose up --build

そして10分くらい待ちます。

この時エラーが出る方は、Dockerを起動していないのが原因です。（多分）

タスクバー右下にちゃんとクジラさんマークが表示されているか確認してください。
Docker起動時はこのマークがあるはずです。

水色の文字がいっぱい出て進捗を教えてくれます。
私の時は7分くらいかかりました。

[+] Building 398.5s (15/15) FINISHED

インストール終了後、ファイアウォールの警告が出たら、
「プライベートネットワーク」「パブリックネットワーク」それぞれにチェックを入れて
「アクセスを許可する」を選択。

この「 Installing torch」で進捗表示もなく5分くらい待たされますが、正常です。

変にクリックとかせず待ちます。

INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

上記の1文が出たらインストール終了です。
お疲れ様でした。

ブラウザ検索窓に「http://127.0.0.1:8000/app/」と打ち込みWebUIにアクセスします。

各種設定：Lsmith WebUIモデルをTnsorRT用に変換

「Engine」メニューに移ります。

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の最低限の最適化（？？）

全体的に何言ってるか分からないので、デフォルト通りに
「Build dynamic shape ダイナミックシェイプをビルド」のみチェックします。

変換を実行する

中央下部の「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側でも確認できます。

This may take about 10 minutes. Please wait until the process is finished.

10分くらい変換にかかるようです。気長に待ちましょう……

変換中のシステム負荷

諸々で15GBくらいRAMを使用するので、ブラウザなどは閉じたほうが良いかもしれません。

VRAMももちろんドカ食いです。
VRAMが24GBもなくてもモデル変換自体はできます。

RTX3060の動作事例あるので。勿論遅くなります。

変換されたモデルを使用する

Success!
The model has been built successfully. You can now generate images!

上記のようにモデル変換が終わったらお知らせしてくれます。

では「Generate」メニューに移動します。

そして変換したモデルを選択します。

この時、モデルをリロードすること！！！

あとはいつも通り諸々プロンプトやサンプラーを選び生成です。

４，DockerのLismthを起動・シャットダウンする方法

Lsmithを起動する方法

まずWindowsでDockerを起動します。

「Containers」メニューのLsmithっぽい名前のイメージを選択し、再生ボタンを押して起動します。

デフォルト設定ではポート8000を利用するので、「http://localhost:8000/app/」にアクセスしてください。

再生ボタンを押した数秒後にはもう起動しています。

1111版より高速で嬉しいですね☆

Lsmithを終了する方法

Dockerのマークであるクジラがタスクバーにあるので、クジラマークを右クリック→Dashboardをクリックします。

そして起動時同様に「Containers」メニューのLsmithっぽい名前のイメージを選択し、Stopボタンを押します。

停止には10秒くらいかかります。

５，どれくらい高速になるのか検証！！

比較条件と意図

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に格納した上で比較します。

比較結果

モデル	１回目	２回目	３回目	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倍になるか⁈

追記：せっかくなのでハンデ戦してみました。

アスカベンチほど本格的にはせず、公式例どおり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無効を加えた感じ。

ハンデ戦	１回目	２回目	３回目	平均	割合
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