ComfyUIの「CUDA out of memory」を直すための確認順

ComfyUIでCUDA out of memoryが出ると、「VRAMが足りないからGPUを替えるしかない」と考えたくなる。

確かに処理時のGPUメモリが足りなくなったことは分かるが、どの設定が上限を超えさせたのかまではエラー文だけでは分からない。まず失敗した条件を残し、一項目ずつ変えて原因を絞る。

先に失敗したワークフローを保存する

再実行する前に、比較の基準になる情報を残しておく。

ComfyUIのバージョン:
ワークフローJSON:
モデル / VAE / ControlNet / LoRA:
解像度:
バッチ数:
数値精度:
オフロード設定:
エラーログ:

複数の設定を変えてから成功しても、どの変更が効いたのか分からない。失敗した状態も重要な比較材料になる。

まず、ほかのアプリがGPUを使っていないか見る

ComfyUI以外のアプリがGPUメモリを使っていれば、同じワークフローでも使える余裕は減る。ブラウザー、動画編集、別のAIアプリなどを同時に動かしている場合は確認しておく。

PyTorchでは、実際に使っているメモリと、確保して再利用するために予約しているメモリを別の指標として扱う。OSやnvidia-smiが見せる数値とも意味が完全に同じではない。

一瞬の使用量だけで「このモデルは○GB必要」と決めつけず、不要なGPU利用を減らしたうえで同じワークフローを再実行する。

解像度とバッチ数は別々に下げる

次に試しやすいのは解像度とバッチ数だ。

1. バッチ数を変えずに解像度だけ下げる
2. 元の解像度へ戻す
3. 今度はバッチ数だけ下げる
4. どの変更で成功するか記録する

バッチ数を増やすと、複数画像分の中間データを同時に持つ場面が増える。Hugging Face DiffusersのVAE slicingの説明では、4枚を同時にデコードする例でVAE部分のpeak activation memoryが4倍になる例が示されている。ただし、これはVAEデコード部分の例であり、ComfyUIのワークフロー全体が常にバッチ数へ比例してVRAMを使うという意味ではない。

解像度も1枚あたりに扱う空間データ量へ影響する。DiffusersのVAE tilingは、画像を小さなタイルへ分けて一度に処理する範囲を小さくすることでpeak memoryを抑える。したがって解像度を下げることでVRAM不足が解消する場合はあるが、必要量の増え方はモデルやノード構成によって変わる。

両方を同時に下げると動きやすくはなるが、どちらがVRAM使用へ効いていたか分からなくなる。

必要なVRAMはモデル、追加部品、数値精度などでも変わるため、「この解像度なら必ず動く」という固定値にはしない。

VAEやControlNet、LoRAなどを一つずつ確認する

ComfyUIのワークフローでは、中心となるモデル以外にもVAE、ControlNet、複数のLoRA、動画用の追加モデルなどを読み込むことがある。

まず基本的な構成と比べ、追加したものを一つずつ外して確認する。どの部品を加えた時点でVRAM不足になるのかが分かれば、対策を考えやすい。

モデルファイルそのものがVRAM容量より小さくても、実行中には中間データなど別のメモリも必要になる。ファイルサイズだけで動作可否は判断できない。

数値精度やオフロードは、条件を分けて試す

一部の実行環境では、計算に使う数値精度を変えたり、モデルの一部をCPU側へ移すオフロードを使ったりできる。

これらはGPUメモリの使い方を変える方法だが、処理速度やシステムメモリ使用量を同じに保つ仕組みではない。

試すときは、基準の状態から数値精度だけ変更する、基準へ戻してオフロードだけ変更する、というように分ける。

成功したら、VRAM不足が消えたかだけでなく、生成時間やシステムメモリの変化も残しておく。

動く条件を見つけたら、そこから戻していく

一度動く条件が見つかったら、その状態を新しい基準にする。そこから解像度、バッチ数、追加モデルなどを一つずつ元へ戻していく。

目的は最低設定で動かすことではない。自分のワークフローで、どの条件を超えるとVRAM不足になるのかを知ることだ。

この記録があれば、設定を調整するときだけでなく、将来GPUのVRAM容量を比較するときにも判断材料になる。