# WindowsでのComfyUIのメモリ不足：VRAM、RAM、ディスクのどれが原因か

ComfyUIがWindowsで`CUDA out of memory`を報告したときは、まずGPUメモリと失敗したワークフローを調べます。生成画像を削除するとディスク空き容量は増えますが、専用VRAMは増えません。一般的なメモリ不足メッセージにはシステムRAMが関わることもあるため、すべての失敗を同じ問題として扱わず、実際のエラー文を残してください。

## 失敗したワークフローを保存し、段階を特定する

ワークフローを保存し、モデル、解像度、バッチサイズ、実行が停止したノードを記録します。エラーレポートとターミナルログを使い、モデルの読み込み、サンプリング、画像のデコード、カスタムノードの実行を区別します。段階によって必要なメモリ量が異なるため、この区別は重要です。

ComfyUIの[トラブルシューティングガイド](https://docs.comfy.org/troubleshooting/overview)は、レポートの確認、画像サイズやバッチサイズの縮小、カスタムノード問題の除外を勧めています。これらは条件を管理した比較として行ってください。すべてのノードを更新し、Pythonを置き換え、モデルも同時に変更すると、再実行が成功してもどの変更が重要だったのか分からなくなります。

## GPUメモリとシステムメモリを別々に確認する

失敗を再現しながら、**タスク マネージャー › パフォーマンス**を開き、GPUの専用メモリをメモリページと並べて確認します。複数GPUのPCでは、そのワークフローで実際に使われているGPUを見ていることを確かめてください。

| リソース | 不足すると変わること |
| --- | --- |
| 専用GPUメモリ | モデルと中間テンソルがGPU上に収まるかどうか |
| システムRAMとコミット量 | WindowsとCPU側の処理に余地があるかどうか |
| ディスク空き容量 | モデル、出力、ページングファイルが増やせるかどうか |

共有GPUメモリは、グラフィックスカード上の追加の物理VRAMではありません。SSDの空き容量が大きくても、大きなモデルがそのカードに収まるわけではありません。Microsoftの[タスク マネージャーのGPU解説](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/)に、各種表示の違いが説明されています。

## 最初の実験を失敗したノードに合わせる

メモリ不足のレポートには、赤くなったノードだけよりも有用な情報が通常含まれています。最初の割り当てエラーと、それを発生させたノードを記録してください。後続の例外は、その最初の失敗の結果である可能性があります。ワークフローのグラフを変更する前に、コピーを保存してください。

| 失敗する段階 | 最初に試す対照実験 | 結果から判断できること |
| --- | --- | --- |
| チェックポイントまたはテキストエンコーダーの読み込み | 同じ最小限のタスクで、互換性のあるより小さなモデルを1つ使う | 読み込みの要求量が障害になっているかどうか |
| サンプリング | バッチを1にしてから、対応しているより小さな画像サイズを別の実行で試す | 中間的なワークロードがより小さなサイズに収まるかどうか |
| サンプリング後のVAEデコード | 互換性のあるタイル化VAEデコードを使う | デコードが失敗したピークだったかどうか |
| アップスケーリングまたは動画処理 | 対応していれば、より小さな入力またはより少ないフレーム数を使う | その段階の入力サイズが失敗を引き起こしているかどうか |
| カスタムノード | 対応している最小の組み込み同等機能を使う | 失敗がそのノード経路に固有のものかどうか |

これらは実験であり、保証ではありません。より小さなチェックポイントではモデルファミリー、必要なノード、出力品質が変わる可能性があるため、それをサポートするワークフローを使用してください。最初のエラーが重みの読み込みに関するものであれば、最終的なJPEG品質を下げても必要なモデルメモリ量は変わりません。

モデル、シード、解像度、バッチ、変更したノード、結果を簡単に記録してください。ワークフローが対応している場合は同じシードを保つと視覚的な比較がしやすくなりますが、精度やノードを変更すると画像が変わり得ることは認識しておいてください。小さな構成で完了できたら、制限となっている段階が明確になるまで、要件を一度に1つずつ戻していきます。

## 需要を一度に1つずつ減らす

まずバッチサイズを1にし、サポートされるより小さい解像度を使います。それでワークフローが完了したら、一度に1つの要素だけ増やして繰り返します。画像の幅と高さを両方2倍にするとピクセル数は4倍になりますが、モデルや各ノードにはそれぞれのコストがあるため、総VRAMが正確に4倍になるわけではありません。

サンプリングではなくデコードで失敗する場合は、ワークフローが対応していれば互換性のあるタイル状VAEデコードノードを試します。出力に継ぎ目などの違いがないか確認してください。単一のモデルを読み込めない場合、出力サイズを小さくするだけでは解決しないことがあります。そのワークフローとハードウェアが対応するモデルや精度を試してください。

再実行の前に、GPUを多用する他の作業を保存して閉じます。失敗したジョブの後もメモリが占有されたままなら、ワークフローを保存してからComfyUIを通常どおり再起動します。再起動で放棄された作業負荷が解放されることはありますが、大きすぎるワークフローが確実に収まるようになるわけではありません。

## ワークフロー全体を再構築せずにVAEデコードを変更する

ComfyUIの[VAE Decode Tiledのドキュメント](https://docs.comfy.org/built-in-nodes/VAEDecodeTiled)では、潜在サンプルをより小さなタイルに分けてデコードする方法を説明しています。互換性のある画像ワークフローの保存済みコピーで、同じ潜在サンプルとVAEをタイル化デコードノードに接続し、その画像出力を既存の保存ノードまたはプレビューノードに接続します。変更を元に戻せるよう、元のワークフローは残しておいてください。

別のモデルから複数のタイル値とオーバーラップ値をコピーするのではなく、まずノードで利用可能なデフォルト値から始めてください。より小さなタイルが必要な場合は、その値だけを変更し、メモリ使用量と結果の画像の両方を確認します。より小さな分割はワーキングセットを減らせますが、処理のオーバーヘッドが増えます。結果を受け入れる前に、滑らかなグラデーション、境界、細部を確認してください。

デコード時のタイル化は、モデルの読み込みやサンプラーの実行に先立って必要となるメモリを減らすものではありません。実行がデコードに到達しない場合は、調査を失敗している段階に戻してください。動画用VAEや特化型モデルには、独自の互換ノードが必要な場合があるため、名前に「tiled」が含まれているという理由だけで画像用デコーダーを代用しないでください。

## インストール形式に合った最適化の方法を使う

公式ガイドには、手動インストール向けの`--lowvram`が記載されています。専用環境から起動する手動インストールの場合、形式は次のとおりです。

```
python main.py --lowvram
```

これはComfyUI Desktop、ポータブル版、サードパーティのランチャーに貼り付ける汎用コマンドではありません。そのインストールが対応する起動設定を使い、既存の引数は保持してください。処理をGPUメモリから移すと、速度とシステムRAMを犠牲にしてVRAM要件を下げられる場合があります。

カスタムノードが関わる失敗では、組み込みのワークフローと比較し、ComfyUIの[カスタムノードのトラブルシューティング](https://docs.comfy.org/troubleshooting/custom-node-issues)に従います。元のワークフローを保持し、どのノードを無効にしたかを記録してください。カスタムノードが欠けるとワークフローが変わるため、再現できる最小の同等タスクで比較します。

## 比較後に起動設定を元に戻す

メモリオプションを試す前に、ランチャーのコピーまたはその引数のメモを保存してください。手動のPython環境、Windowsポータブルパッケージ、デスクトップアプリは、必ずしも同じ方法で起動するとは限りません。オプションは、このインストールを実際に起動している仕組みを通じてのみ追加してください。2つ目のPython環境を作成すると、別の問題を引き起こす可能性があります。

ComfyUIの[起動フラグのリファレンス](https://docs.comfy.org/development/comfyui-server/startup-flags)では、いくつかの独立したメモリ制御とキャッシュ制御を説明しています。これらはまとめて有効にするスイッチの集合ではありません。たとえば、結果のキャッシュを減らすと保持されるメモリを抑えられますが、より多くのノードが再実行される可能性があります。CPUオフロードは追加のシステムRAMを必要とし、ワークフローを遅くする場合があります。

実行に成功したら、出力が完全で使用可能であることを確認してから、通常のタスクを繰り返してください。変更によって小さなテストだけが通るものの、必要なワークフローが依然として失敗する場合は、その境界を記録してください。役に立たなかったテスト用引数を元のランチャーから削除し、次の実験の前に最後に動作していた構成に戻してください。

システムのコミット量がボトルネックになっている場合は、GPUメモリと併せてWindowsのメモリを確認し、動作するページファイル構成を維持してください。ディスク容量を増やすこと、ページファイルの上限を増やすこと、専用VRAMの需要を減らすことはそれぞれ別の介入であり、いずれも他の対策の万能な解決策として提示すべきではありません。

## 出力のクリーンアップは別作業として行う

生成した画像や動画はかなりのディスク容量を使うことがあります。プロジェクトごとに見直し、貴重な結果を再現するのに必要なワークフローと素材は残します。保持するつもりのものは、唯一のコピーを削除する前にバックアップしてください。

エラーがWindowsのコミット量不足であれば、[Windowsメモリガイド](/ja/windows/blog/windows-high-memory-usage)にVRAMとの違いが説明されています。ドライブをきれいに見せるためにページングファイルを削除しないでください。繰り返し発生する失敗を報告するときは、正確なエラー、GPUとドライバー、インストール形式、最小の失敗ワークフローを含め、個人的なプロンプトやパスは除去してください。


Canonical: https://mole.fit/ja/windows/blog/comfyui-out-of-memory-windows