はじめに
※記事一覧
今回の記事では、個人的にStable Diffusionで遭遇したトラブル事例を書きます。
所謂「おま環境」かもしれないので、あくまで参考程度にどうぞ。
Model Browserでサムネイルが消える
Stability MatrixのModel Browserでは、モデルやLoRAを検索して一覧表示できます。
なぜか分からないんですど、たまに画像が一切でなくなって、個別にクリックしたら画像が見れる、といった状況に何度もなりました。
たいていはStability Matrix自体を終了させて起動し直すと回復することが多かったです。
最悪、Windows再起動。
それでも治らない時もあったんですが、気がついたら治ってたりしたので謎。
原因がよくわからないので、これといった対策をうててないのが実情です。
仕方ないので現時点ではModel Browserでの管理をやめてしまって、civitAIをブラウザで開いてダウンロードするようにしています。
生成時に98%から異様に時間がかかる
Stable Diffusionで生成するとき、進捗度98%までは早いんだけど、そこから1分近く待たされてた。ログを見たけど、何をしてるのかよく分からず。
処理的には生成⇒Hires⇒Adetailerとなってるはずで、Adetailerが仮に悪さしてるようなら敢えて使わず、画像を選定し終わってから部分修正した方が効率的かも。
なお今回の場合、Adetailerが始まりさえすれば早い。その前のHiresの段階で遅いのか、Adetailerの前の処理が重いのか不明。
自己解決した流れとしては、Windows再起動して、Stable Diffusion起動しようとしたらVAEが～っと起動できず冷や汗かいて、ためしにVAEなしにしてADetailerもやめたら早くなってた。
VAEが壊れてたんでしょうか？
なおPC電源きらず、スリープして数日ずっと使い続けてたのがダメだったのかもしれない。
やはり再起動……！！ 再起動は全てを解決する……！！
生成時に98%からWindows全体が異様に重くなる
今回は1分どころか数分以上もWindows自体が重くなって、タスクマネージャーすらまともに起動しないくらい遅い状態です。
色々切り分けていったら、外付けHDDを付けている時だけ再現する模様。
Claudeに質問したら可能性としては下記が考えられるようです。
仮想メモリ（ページファイル）のスワップ先問題
Stable Diffusionは画像生成の最終段階（デコード処理）でVRAMやRAMを大量消費します。メモリが不足すると、Windowsは自動的に「仮想メモリ」としてディスクにデータを書き出します。この書き出し先に外付けHDDが選ばれていると、USB3接続でも内蔵SSDと比べて圧倒的に遅く、システム全体が詰まる原因になります。
確認方法： 設定 → システム → バージョン情報 → システムの詳細設定 → パフォーマンス → 仮想メモリ で、ページファイルの設定先ドライブを確認。
環境を確認したところ、仮想メモリは全体的にシステム自動割当になってるので、原因ではなさそうでした。
モデルや画像の自動保存先
生成完了直前（98%）に画像ファイルを書き出すタイミングで、保存先や一時ファイルの書き込み先が外付けHDDになっている場合、そこがボトルネックになります。Stability Matrix側の出力フォルダの設定を確認してみてください。
環境を確認したところ、外付けHDDではなく、内蔵HDDになってたので原因ではなさそうでした。
Windowsの自動インデックス作成
外付けHDDが接続されていると、Windowsのインデックスサービスがドライブの内容を読み込もうとして、生成処理と競合することがあります。
環境を確認したところ、外付けHDDのインデックスが有効になってたので解除しました。とはいえ、これが原因とは考えにくいです。まぁフリーソフトEverythingをいれてるので、ファイル検索でインデックス無くても困らないので解除してる状態です。
電力不足によるUSBスロットルング
高負荷時にGPUやCPUが電力を大量消費すると、USBコントローラーへの電力が不安定になり、外付けHDDがスロットリング（速度制限）を起こすことがあります。これがシステム全体のI/O待ちを引き起こすことがあります。
今回の症状ですが、電力不足が原因だったようです。Stable Diffusionのような高負荷処理をする場合は「高パフォーマンス」または「究極のパフォーマンス」が推奨だそうで、「バランス」になっている場合、高負荷時でもCPUクロックの上昇が遅れたり、USB電力が絞られたりすることがあるらしく今回の事象に繋がっていた模様。
ためしに「高パフォーマンス」に変更したら、再現しなくなりました。
高パフォーマンス
VRAM不足
しばらくは大丈夫だったんですが、ずっとPCつけっぱなしで休止とかしてると、また例の現象が起こり始めました。
一度StabilityMatrixの画面で起動中のパッケージ（今回はStable Diffusion）をStop → Startしましたが改善せず。なおPC再起動すれば治ります。
そもそも原因はなんだろうかと探ってみたところ、原因が分かりました。
専用GPUメモリ：11.6/12.0GB（ほぼ限界）
システムRAM：29.1/31.8GB（92%）
共有GPUメモリ：2.2/15.9GB使用中
VRAMとRAMの両方が同時に限界に達していたのが原因でした。
・hires.fix処理中にVRAMが12GB満杯になる
・VRAMが溢れると共有GPUメモリ（システムRAM）へスワップする
・RAMも32GBほぼ満杯なのでそこも逼迫
・結果としてシステム全体が重くなって止まって見える
ちなみにStable DiffusionをStopしたままであれば軽いですんですが、生成せずとも起動するだけで重いです。こういう場合、SDXLモデル専用のVRAM節約オプションで、モデルの常駐サイズを抑えつつ生成できます。
設定場所（StabilityMatrix）
→ パッケージの設定
→ VRAMのところにある–medvram-sdxl にチェック
このあとでStable Diffusionを起動すれば、VRAMの使用量がかなり減って、動きが軽くなりました。
WebUIが起動しない（インターネットが不通）
インターネットが不通だと、起動時にエラーになるようです。
この前ネット障害が発生して、NTTの修理待ちになった時にエラーになってました。
仕方ないのでテザリングでネット接続したら回避できました。
WebUIが起動しない（インターネットは繋がっている）
Stability Matrix自体は起動してて、インターネットに繋がっていても、パッケージのところからWebUIが起動できない事があります。
ストップからリスタートとして一度で起動しない場合、もう一度同じようにリスタートすれば改善することもありました。
何度やっても変わらない場合、ログをみてVAEだとかLORAとかのエラーっぽいものが出てたら、対象ファイルをバックアップや退避などして、それらをStability Matrixで操作して無効・削除にしてリスタートを試みるのがよいでしょう。
Checkpoint ManagerでLoRAを選択するとエラーになる
Stability MatrixでLoRAを管理する機能、Checkpoint Managerでのトラブル例です。
LoRAをダウンロードして、エクスプローラーから手動でCheckPoint Managerへダウンロードしまくってたら、一部のLoRAにおいて表示されているのに、クリックなどをしようとすると「Model not found in index」とエラーになりました。
Stability Matrixを再起動しても症状が変わらず、一番左下にある「Setting」の「Checkpointキャッシュのリセット」を実行したら直りました。本来はModel Browserのラベルが正しくない時に押すべきものらしいので、もしかしたら別の原因で改善したのかもしれません。というのも、エラーには英語で後ほど操作してくれって警告も出ていたので、自然と直ってる可能性も捨てきれないんですよね。
とりあえずダメ元での備忘として書いておきます。
LoRAのファイル名を変更しても、LoRAを呼び出す時に違う名前になってしまう
AUTOMATIC1111標準では「学習時の ss_output_name」が優先されてしまう。一部バージョンでは 「Use filename as identifier」 みたいなオプションがあり、それをONにするとファイル名で呼び出せるらしいが、あいにく見当たらず。
LoRA Info Editorの「Drag and drop a .safetensors file into the drop zone below to view and edit its metadata.」というエリアに、編集したいLoRAファイル（例：old_lora.safetensors）をドラッグ＆ドロップ。
メタデータが表示されるので、ss_output_name フィールドを探し（複数あるかもしれないので要注意）、新しい呼び出し名（例：new_lora_name）を入力してから、保存し直せばOK。
環境のみなおし
上記とは別に、SSDの書き込み量とメモリ使用量が増えていた件も、腰を据えて見直したのでまとめておきます。
メモリ
–medvram-sdxl
VRAM節約のために有効にしていたこのオプション、実はシステムRAM側を逆に圧迫していました。
pythonプロセスが20GB前後まで膨れ上がり、生成のたびにRAMとディスクの間でデータが行き来して遅くなっていたようです。
外したところRAM使用量は半分以下まで下がり、生成速度もむしろ速くなりました。VRAM不足も特に再発なし。
PC Managerのブースト
ブースト＝メモリ解放機能のことですが、Stable Diffusion起動前は有用ですが、起動してる最中に使うと逆効果でした。
SDが確保しているメモリを強制的にページファイルへ追い出すだけなので、次の生成でまた読み込み直しになり、かえって重くなります。
使うならSD起動前にするようにして、ソフト閉じたほうが安全です。
生成が終わったらSDを止める
地味ですが、起動したまま放置するとpythonプロセスがRAMを握ったまま離さず、他のアプリ用のメモリがじわじわ圧迫されていきます。
「久しぶりに生成したら重い」の主因は大体これでした。
長時間使わないならSDを止めましょう。
HyperX NGENUITY
このキーボードについてたというソフトです。
先日なぜかどんどんメモリをくいつづけ、30時間経過するころには10GBも使ってるという異常事態に。しかもソフトウェア内でこのキーボードが候補に出てこないので、設定変更もできず単にメモリを食い潰すだけの危険な代物になってしまったので、アンインストールしました。
切替器を使っていてキーボードの色をPCごとに変えたい、という場合はWindows11標準でついてくる動的ライティング機能を使いましょう。そのPCでの色を指定できるので、波打ったりとか特殊な効果が不要で、単色で光ってさえいればいいということであればHyperX NGENUITYは不要でいいと思います。
SSD書き込み
Eagleの library-caches フォルダ
今回一番の大物でした。
Eagle（画像管理ソフト）がライブラリの読み込み高速化のために作るキャッシュフォルダですが、タグ付けなど些細な操作のたびに数百MB単位のファイルを丸ごと書き直す仕様で、SSD書き込み量のかなりの割合を占めていました。
このフォルダを外付けSSD側にジャンクション（ショートカットのようなもの）で逃がしたところ、内蔵SSDへの書き込みが激減しました（詳細）。
以前は10日くらいでSSD寿命が1%減ったのですが、この対策しただけで37日で1%減るようになり、単純計算で1/3未満の書き込みになったようです。
Amazon Photos
自動にしてたら書き込みを常時行ってたのでやめました。
やるなら手動でやるか、別ソフトなどがいいかもしれません。
BUFFALOみまもり合図
書き込み量がかなり多かったのでアンインストールしました。
SD起動中に休止しない
PC休止（スリープ）時のディスク書き込み量が、SD未起動時と比べて数倍に増えることが分かりました。
SDの状態までローカル保存して、再開時に再現しようとするので、SSDに膨大な書き込みをしてしまうからです。
よってPCのスリープ・休止前はSDを終了しましょう。
AdBlock（ブラウザ拡張機能）
1日あたりの書き込み量が一桁変わるレベルで悪さをしていました。
無効化したら明らかに落ち着きました。
Eagleの AI Search プラグイン
使っていなかったのに、モデルファイルやログが数GB溜まっていたのでアンインストール。
書き込み量というより容量の問題ですが、ついでに整理しました。
動作が極端に重くなる（95%付近で止まり、キーボードも効かなくなる）
SDの画像生成の95%あたりで止まって、ひどい時はキーボード入力すら受け付けなくなる症状。
原因は一つではなく、いくつかが絡んでいました。
上述してきた以外の対応を書いておきます。
USBの省電力設定
外付けドライブを使っている場合、「USBのセレクティブサスペンド」と「一定時間後にハードディスクの電源を切る」設定が、電源プランを高パフォーマンスにしても別枠で残っていて悪さをしていました。
生成の最後にドライブへ書き込むタイミング（これが生成95%付近）で、外付けドライブが省電力から復帰する一瞬の遅延が全体を巻き込んで止めていたようです。
両方とも無効にしたら改善しました。
コメント