Reducing VAE decode tiles

夏以降の更新によって、内部的にオブジェクト指向化が進み、各モデルに対応するためパイプラインの実装も精力的に拡張が行われています。主に動画対応の様な部分も強いですけど、それ以外に一番恩恵を受ける修正がVAE出力時に一括処理できなければイメージをタイル割して出力する機能ではないでしょうか？

試しに過去のプロンプトをベースにして試していますが、当時はvaeの動作を --vae-on-cpu オプションを指定してCPUで実行する必要がありました。SYCLのメモリー消費量は現在でもバカ食いするままなのですが、この機能のおかげでSYCL上でvaeの実行が行いやすくなりました。

分割のためのオーバーヘッドはあるものの処理速度の恩恵がとてつもなく大きいので全く問題になりません。

ついでに当時実行したままのプロンプトで画像生成を行ったところ、ほぼ、同じものが出力されるのですが、まったく同じ状態の出力にはならないようです。この辺はggmlや、stable-difusion.cppの変更や修正の影響を受けた結果だと思われます。どちらが正しいのかはさておき、同じ画像を微調整する必要がある場合は、モデルファイルだけでなく実行環境を含めて保存しておく必要があるという事になりますね。

比較のための画像をいくつか出力してますが、どこまで比較するか正直悩ましくてまとめられていません(笑)同一のものが出てきてくれればよかったのですが、今のところ「似ている」感じの物は確認していますが、一致してくれないｗ 

気になるのは現状の方が不具合なのかもしれないという部分もｗ同一のプロンプト出力を比べると、現状のstable-diffusion.cppの方が、手の崩れ具合などが目立っている気がします。リファレンス的なCPUのみの出力を行い比較する必要がありそうですが…面倒くさすぎるｗ

細かいところは多々あるものの、今の環境でflux 1 schnellを改めて今実行してみると1024x1024出力で２８分程度で出力されるので結構軽く感じます。一方、flux 3 image kleinは1024x1024で１時間ぐらいかかってしまいます。

テキスト→イメージだけの個人的な感想となりますが、Flux1-schnell Flux2-klein Flux3Image-kleinは出力画像はあまり変わってはいない印象を受けました。一方Qwen Image系は人の四肢の末端部などの表現や矛盾が減っている印象があります。

int8系で調整されたモデルの実行となるとまた話は変わってきそうですが、、、