FLUX.1 on Stable Diffusion Web UI Forge の挙動がおかしい....。【解決しない問題が 1 件残った。】
この記事を纏めるために 1 バッチ 12 画 描画を沢山回すことで大量に
描画を積み上げる中で、奇妙な状態をじわじわ感じ始めました。
描画PC では裏で余計な VRAM 消費を避けるために、FLUX.1 on Stable
Diffusion Web UI Forge が稼働していない合間に、microSD カード（USB
アダプタ経由）で、Lenovo X230 3 号機（GPU なし）に描画データを
持ってきて、そこでHailuo AI や Kling AI への動画生成リクエストを
出しつつ、このような記事の執筆をしています。
ところが、microSD カードから Lenovo X230 3 号機で読み込む
データの中に欠損というか不完全なものがあることが、時々気に
なって来ました。ファイル拡張子 「.png」の後に「.crdownload 」
が続き、ダウンロード未完了のような状態です。
最初は描画 PC で microSD カードへの描画データ転送が実際はまだ
完了し切っていないうちに、システムが「USB を安全に外せます」を
返してしまって microSD カードに書き込み中のデータが出て来た
のか、と考えました。
しかし描画 PC の外付けHDD （そこにFLUX.1 on Stable Diffusion Web
UI Forge が内蔵 SDD を経由せず直接書き込みます）の内容を見ると
既にその段階で、その不完全が生じていることが分かりました。
エクスプローラの「プロパティ」から「ツール」を選んで、その
外付け HDD のエラーチェックもしましたが問題ありません。
そういえば、12 描画の 1 単位を終わった都度、サムネイル画を
含めて保存する時に、既に同じ場所に保存している同じ png
ファイルのサムネイルが真っ白の状態が時々出て来るのが
気になっていたのでした。（現在、その現象だけは解消して
その状態が再現出来ません。）
それらのことから、データの保存不良は、Stable Diffusion Web
UI Forge に問題があると推察して、久々に update.bat を実行
しました。描画の雰囲気が変わる時があるので、気に入った描画
の状態を得た時期には、それを充分に収穫しないうちは、頻繁
には実行しないものですが、ここはやむなく実行しました。
update 差分はあったようです。
Stable Diffusion Web UI Forge を再び起動して、直前のプロンプト
や設定を全部リコールしてくるボタンを押して、「seed」は「-1」
にして 12 画バッチを実行しました。
え….？
なんだか表情が大きく違ってる？
折角の描画水準を気に入っていたのに、取返しがつかない事態か？？？
いや…プロンプトをよく見ると、LoRA F1 の一部が勝手に指定したこと
のないものに置き換わっている….。
Asir Asian Portrait Photography Flux.safetensors が 最近設定したことのない
Jisso Style.safetensors に変わっていました。
以前も Asir Asian Portrait Photography Flux.safetensors が勝手に kimDudou_FLUX_v1.safetensors に置き換わっていたことがあって、
後者を LoRA保管フォルダから外していたのでしたが、後者自体
の問題ではなかったようです。
このリコールボタンの仕様不良は以前から気になっていたものですが
今回の update.bat でも改善されていないようです。
なお update.bat 実行直後の当方の環境は以下の通りです。
FLUX.1 対応直後の Stable Diffusion Web UI Forge 起動時には、
「このバージョンの python 環境でデバッグされたものではない」
旨のアラートが出たので、起動時のオプション（引数）でバージョン
チェックを外すバッチ起動にしています。（ --skip-version-check ）
その影響下で発生している（＝デバッグされた環境では出ず、対応を
見落とされている）現象かもしれません。
メモ帳にプロンプトを保存する運用は続けていますので、そこから
内容を戻して処理を再開しました。
表情は元に戻ったでしょうか。直前の大変化の後ではあまりよく
分かりませんが、少しは違ってしまっている感じはします。
魅力的ではありますが、以前とどこか違ってしまっているような….。
保存時に見える画面でのサムネイルが全部真っ白の表示不良は
なくなりました。（update.bat 実行前には、VRAM 枯渇状態
なのかなとは思ってました。）
しかし、保存直後のエクスプローラでの保存状態を確認を
すると、まだわずかに欠損したデータはあるようでした。
grid-0005 などのサムネイル画は記事で採用することが少ないので、
まだ実害は少ないですが、エクスプローラの時系列表示の末端にある
00101-2901766373.png が「crdownload」付で保存不良になったまま
なのは痛いです。
もう少し現象に早く気づいていれば保存直後にデータが欠損して
いることに気づけて救えた画もあったでしょうに、次の描画が
始まればもうその前の描画は消えてしまいますので、今から救う
ことは出来ません。残念です。
「あの画はどこだ？良かったから記事に掲載するつもりだった
のにどこにも無いぞ…」と漠然とおかしさを感じた時点で問題に
気付くべきでした。
当面、次の描画で潰される前にエクスプローラで正しく画が保存
されているかを確認して、問題がある画は再保存する運用を徹底
します……あっ。ダメです。最後に描画させた 12 画の保存直後に
そのサムネイル画 grid-0008.png が保存途中状態「.crdownload 」
で欠損していましたので、再保存しましたが、同じ欠損状態の
ままです。繰り返しましたがやはりダメでした。
サムネイル画を表示させた状態の画面左上にフロッピーディスク（今どき）
マークがあるので、それで保存出来ないかと試しましたが、無反応で、
裏バッチ画面（処理本体）ではエラーが出ているようでした。
末尾に「No space left on device」との OS エラーがありますが、ストレージ
上（外付け HDD）の余裕の問題では無さそうです。
Stable Diffusion Web UI Forge をインストールしている外付け HDD の
空きは 1.03 TB もあります。そしてそのドライブに画を保存しようと
しているのでした。
普段どうでも良いと思っているサムネイル画ですが、釈然としないので
PrtSc キーとペイントで無理繰り保存しました。
そのペイントでの保存も、保存の瞬間に大半がグレーに壊れることもあり、
再びペーストしてから再保存しました。
上掲の「サムネイル画を表示させた状態の画面左上にフロッピーディスク
（今どき）マークがあるので、それで保存出来ないか」の状態の画面を
PrtSc キーとペイントで無理繰り保存したものは、壊れていて後で参照が
出来ませんでした。
やはり VRAM 上で余裕が無い事態なのでしょうか。ペイントごときが
GPU VRAM を競合するのか、という疑問はありますが….。
1 バッチあたりの描画枚数は VRAM 消費に影響はないと聞いたことが
あります。1 画を描画させる処理を複数回シリアルに回すだけですので。
しかし今回の update.bat 実行後の保存状態を見る限り、1 バッチ 12 画
の処理を 2 回ほど実行しては、一旦、Stable Diffusion Web UI Forge を
再起動するか、PC 全体を再起動するかを暫定運用してみるしか無さ
そうです。
Cog Studio が update で稼働モジュールが大きくなってそれまでの
運用が出来なくなったと推察されるのと同じく、仕様改良が裏目と
なり GPU VRAM 8 GB 環境では Stable Diffusion Web UI Forge での
FLUX.1 描画が出来なくなったり、制約が増えたりする懸念は
常に念頭に置いておかねばならないのかもしれません。
ああ…早速もうダメです。
X230 でこの記事の続きを書きつつ、描画PC を再起動してさらに描画
を始めましたら、最初の 12 画とサムネイル画が全部「crdownload」
付で保存不良になってしまいました…。
上掲のサムネイル画と同様に「画像をコピー」からペイントにペースト
して外付け HDD に保存を試しましたがダメです。
保存を抑止されてしまいました。
LoRA F1 ファイルの効きによる VRAM 圧迫なのでしょうか….。
ようやく理想の人物画に近づいたところで、それらを全く保存出来なく
なった、とは….（愕然大絶望）。
システム通知に時折「記憶域の解放（システム稼働環境が逼迫して
います）」が出るようになっていますが、VRAM 圧迫ではどうにも
手の入れようがありません。が、その通知をクリックしてみると….。
えっ？ C ドライブ？ 空きゼロ？
何故なのか？ そしてどう関係あるのか？
とにかくシステム一時ファイルをクリアして、それでペイントでの保存は
出来ましたが、それでも描画の「crdownload」状態は解決しません。
不要なアプリもほとんど C ドライブには入れていません。
ほとんどがもともとインストールされていた Windows 関連と MSI 社
の用途不明のハードウエア管理ユティリティばかりです。
ゲーミングPC だからストレージは大して要らないだろうという設計
なのでしょう。内蔵 SSD 500 GB はこの種の作業では足らなさ過ぎて、
Stable Diffusion Web UI Forge をはじめ、ほとんどの描画環境は外付け
HDD にインストールしてあります。描画結果も外付け HDD に保存して
います。
Cog Studio とその前提となる仮想環境 pinokio だけはインストール
バッチが複雑だったので、設定変更せず C ドライブに入れましたが…。
そのあたりから C ドライブの逼迫が始まっていたのでしょうか。
インストール直後には空きに余裕はありましたが。（またすぐに
余裕がなくなるのか留意が必要です。）
ほぼ唯一「フォト」でスライドショー自動再生したもの（Windows10
時代と異なり、Windows11 では画のページ送りやズームアップ / ダウン
など見せ方に動きがある）を動画記録するために入れていた Wondershare
社の画面キャプチャツール DemoCreator （無償版）とその関連をやむなく
アンインストールして 1.66 GB の空きを確保しました。
まあそれを使ったのは、後にも先にもこの記事 1 回だけでしたし…。
描画の「crdownload」状態が解消して描画を保存出来ました。
目の前真っ暗な絶望からようやく解放されました。
【こちらの不良は解決しました。Stable Diffusion Web UI Forge
自体の問題ではありませんでした。】
その後、PC 再起動で23.8 GB の空き確保したものの、プロンプト
を復活させるためにメモ帳を起動するだけ（Windows11 仕様で
編集中だった複数文書のタブが開き）で空きが 0.2 GBも減り、
1 バッチ 12 画を 3 回動かすと、空きは 2.12 GB まで急減しました。
現環境では1 バッチ 12 画は 3 回を目途に PC を再起動します。
Cog Studio の「Reflesh」が使えなくなった問題も、本件の影響下に
あるのかもしれません。こちらは C ドライブで動くものですから
原因に稼働モジュールが大きくなった、という推察より、まず
稼働環境の圧迫を疑ってみるべきです。
確認しましたら、PC の再起動後、C ドライブの空きが 23.9 GB で
Cog Studio を 1 回動画生成させると空きが 16.8 GB、「Refresh」
させて、もう無事 1 回動画生成で空きが 44 MB。さすがに次は
ないかな、と思った 3 回目の動画生成が意外にも開始され、その
途中で空きをみると 12.5 GB に戻っていました。
次の「Refresh」で 16.5 GB。実行中は 9.77GB。なんとかキワキワ
の連続で動いており、先日の記事の時のように「100% Refresh 実行
は失敗」ではなくなっています。
ただこの状態を見る限り、 C ドライブ枯渇でのエラーだったことは
間違いない一方で、Cog Studio の動作だけで徐々に C ドライブを
枯渇させたようにも思えない感じです。
本日クリアした OS パッチの残骸やログなどが徐々に圧迫を
積み上げていたのでしょうか。そんな一時ファイルをクリア
しただけではペイントからの保存が復活した程度の僅かなもの
でしかありませんでしたが….。
一時期、ネットニュースで騒がれた Windows11 パッチで巨大な
容量の一時ファイルが消されずに残る（現在解消）という事態も
本件に関係があるのかも知れません。
良く分からないままではあるものの、今後はその通知も頼りに
C ドライブの空き状態を確認しつつ作業を続けることにします。
ご覧いただきありがとうございます。
（2024/10/22 執筆）