Scribble at 2023-11-29 16:13:59 Last modified: 2023-11-29 16:24:24

Stable Diffusion での画像生成には一定の時間がかかる。これは当たり前のことだが、設定によって所要時間にはそれなりの違いがある。原則として、分散モデルである Stable Diffusion がトレーニングに使った画像のサイズ（SD系なら512x512、SDXLなら1024x1024）に近いか、或る数の倍数とか、そういう一定の数値で幅と高さが決まるプロポーションだと生成が速いとされている。もちろん、画像のサイズとして小さい方が速いのは言うまでもないが、人の認知能力には限界があるので、極端に画像のサイズを小さく設定して出力を速くしても 0.01 秒と 0.02 秒の違いは人の感覚で判別できないし、逆に極端に画像のサイズを大きく設定して出力が遅くなっても 1,000,000 時間と 1,000,001 時間の違いは分からないだろう（もちろんこの場合は、違いが分かるまでに誰もが死んでしまうからだ）。

それでも、体感として倍くらいとか10倍も生成の所要時間が短くなればありがたい。ということで、既に幾つかの方法が紹介されている。まず、なんにも考えずに Stable Diffusion Web UI をインストールした直後だと、512x512 ピクセルの画像を出力するのに何十秒もかかると思う。もしビデオ・カードや CPU のスペックが高ければ初期状態でも数秒で出力されるとは思うが、一度に出力する枚数が増えると調整の差が大きくなるので、初期状態でどれくらい速いかは問題にしないでおこう。次に、一般的な解説では xformers を有効にしたり、そのバージョンを最新にしたりという対策を紹介している。これも、或る程度は効果がある。

最近では、先日の落書きでご紹介したように Latent Consistency Model for Stable Diffusion WebUI が「爆速」などと書かれて記事になっている事例を見かけるようになったけれど、落書きで指摘したように LCM はしょせん実験段階の仕組みであり、適正に動作する条件がシビアで、モデルやサンプリング方法やプロンプトなど、期待する結果をコントロールしたり指定するための仕組みが殆ど使えないという致命的な制約がある。特に、CFG scale を 1.0 や 2.0 くらいにしないとまともに動かないため（実験済）、プロンプトが殆ど無視されてしまうのは困る。

そして、上記の TensorRT Extension for Stable Diffusion Web UI も、処理速度を向上させる拡張機能として紹介され始めている。でも、残念ながらこれもお勧めできない。理由は、出力するサイズや縦横比が固定されてしまうからだ。僕もこれを入れて実際に使ってみたが、強く推奨されている512x512ピクセルの画像を３秒くらいで出力するのは確かだが、それ以外のサイズを指定するとエラーが出て動作しない。推奨どころか、それ以外のサイズだと動かないのである。これはいかにも使いづらい。そして、冷静に考えてみたら512x512なんてサイズの画像なら、こういう拡張機能を使わなくても数秒で出力できるのである。たとえば、サンプリング方法を速度優先の DDIM などに設定して、サンプリングのステップ数を15くらいにすれば、このくらいのサイズだと TensorRT Extension を使わなくても５秒以内に画像を出力できる。試しに、"scenary, natual, sunrise, sea" というプロンプトで出力してみると、それなりに所要時間のばらつきはあるが、だいたい３秒前後で出力できている。

なので、現在でも生成速度のスピードを上げるための選択としては、もちろん調整が必要なことでもあるが、サンプリング方法のどれを使うかと、サンプリング・ステップの回数が重要だ。先にも述べたように、スピードを重視するなら DDIM が圧倒的に速い。僕も、これまで Karras 系統のサンプリング方法を使ってきたのだが、DDIM があまりにも速いので、８月くらいから DDIM しか使っていない。そして、DDIM が速い理由はサンプリング・ステップの回数が少なくてもデノイズの収束が速いという特徴があるからであり、DPM++ SDE Karras などを使う時は25とか30とか回数を増やさなくてはいけないのが、DDIM では15や20で済む。