クラウドGPUでComfyUIを使う：セットアップ、ストレージ、コストガイド

クラウドでComfyUIを実行すること自体は簡単です。それを再現可能、プライベート、かつ低コストに保つことこそが本当の作業です。

実用的なComfyUIクラウドGPU構成では、使い捨てのコンピュート、永続ファイル、プライベートアクセス、停止ルールという4つの要素を分離します。GPUインスタンスは交換可能なものとして扱い、モデル、ワークフロー、入力、出力はインスタンス終了後も残るストレージに配置します。これにより、ワークフロースタックを再ダウンロードしたり、昨日の画像がどこに行ったのか悩んだりせずに再開できる構成になります。

このガイドはプロバイダーに依存しません。インタラクティブな作業向けにComfyUIクラウドGPUをセットアップする方法、ストレージを計画する方法、単一のGPU時間単価だけで全体が分かるふりをせずにコストを計算する方法を解説します。

要点

ほとんどの個人開発者や小規模AIチームでは、まず次のデプロイパターンから始めてください。

1. 理論上のベンチマークではなく、実際のワークフロー1つを実行するのに十分なVRAMを持つインタラクティブGPU VMまたはポッドを選びます。
2. モデルをダウンロードしたりカスタムノードをインストールしたりする前に、永続ストレージをアタッチします。
3. ComfyUIのWebプロセスはデフォルトでプライベートに保ちます。公開ポートを開放するのではなく、認証付きデスクトップ、トンネル、またはプロバイダーのプロキシを使用します。
4. 作業中の各グラフ、モデルリビジョン、出力を永続マウントに保存します。
5. 代表的な生成を測定し、作業セッションが終わったらすぐにGPUを停止します。

重要な原則はシンプルです。ComfyUIクラウドGPUは容易に置き換えられるべきですが、作業状態はそうであってはなりません。

1. インストール前に適切なクラウド構成を選ぶ

実際にComfyUIを操作するセッションには、ブラウザ、ターミナル、永続マウントを利用できるGPU VM、ポッド、またはリモートデスクトップ環境を選びましょう。同じセッション内でログの確認、グラフのテスト、モデルの追加、反復作業を行えるため、リクエスト専用エンドポイントよりも通常はデバッグが容易です。

リクエスト指向のデプロイは、ワークフローが安定し、入力の受け取り方、出力の返し方、呼び出し元の認証方法、障害からの復旧方法を把握してから使用してください。目標が完成したプロダクトAPIではなくワークフロー開発である場合は、インタラクティブなComfyUIクラウドGPUサービスが適切な出発点です。

デプロイ前に、以下のプロバイダー固有の質問に答えてください。

ComfyUIに最適なクラウドGPUを、モデル名だけで選んではいけません。ワークフローのピーク時メモリ需要から検討してください。チェックポイント、テキストエンコーダー、VAE、Controlモデル、LoRA、バッチサイズ、解像度、動画またはアップスケーリングの各ステージは、すべてVRAMを取り合います。より大規模または長時間稼働するマシンに決める前に、代表的なグラフを1つ実行し、ピーク時の挙動を記録してください。

より広範なプラットフォームのトレードオフについては、FlatkeyのクラウドGPUレンタルプラットフォーム、GPUの選定、サーバーレスGPU容量と専用GPU容量の比較に関するガイドを参照してください。

2. 最初に永続ストレージをアタッチする

クラウドで最もよくある失敗は、すべてをインスタンスの一時ファイルシステムにダウンロードしてしまうことです。そのマシンを停止、再構築、または置き換えると、モデルキャッシュ、出力、ワークフロー、ローカルでの変更がすべて失われる可能性があります。

最初のインストール前に、永続ボリュームを作成してアタッチしてください。そのボリューム上では、小さくて単純なディレクトリレイアウトを維持します。

/workspace/comfy-data/
├── models/
│   ├── checkpoints/
│   ├── vae/
│   ├── loras/
│   ├── controlnet/
│   └── upscale_models/
├── input/
├── output/
├── workflows/
├── custom-node-notes/
└── run-notes/

初日からすべてのフォルダが必要なわけではありません。重要なのは、再利用するアセットと最終成果物を耐久性のあるマウントに置き、スクラッチファイルや再構築可能な環境は、そのほうが便利であればインスタンスディスクに残すことです。

ComfyUIでは、起動フラグを通じて便利なディレクトリ制御機能を提供しています。--base-directoryはモデル、カスタムノード、入力、出力、一時ファイル、ユーザーデータのベースロケーションを変更します。--input-directory、--output-directory、--extra-model-paths-configを使うと、さらに詳細に指定できます。パスをテンプレートに組み込む前に、最新のComfyUI起動フラグリファレンスを確認してください。

具体的なクラウドストレージの例として、RunPodはコンテナのファイルシステムが一時的である一方、ボリュームはコンテナのライフサイクル外で永続化されると説明しています。プロバイダーごとに用語は異なるため、依存する前に、停止、再起動、終了時の正確な挙動を各プロバイダー自身のストレージドキュメントで確認してください。RunPodの永続化ガイドは、この違いを理解するうえで役立ちます。

3. 再現可能なベースラインでComfyUIをインストールする

インストールの基準は上流プロジェクトに従ってください。ComfyUIの最新の手動インストールガイドでは、対応プラットフォーム、GPU固有のPyTorchの選択、依存関係のインストール、モデルディレクトリ、comfy-cli オプションについて説明されています。まず公式のComfyUI READMEを確認し、チーム固有の追加事項は独自のメモに固定して記録してください。

Linuxクラウドマシンでは、大まかな手順は次のようになります。

git clone https://github.com/Comfy-Org/ComfyUI.git
cd ComfyUI

python -m venv .venv
source .venv/bin/activate

# Install the PyTorch build that matches this GPU/driver environment.
# Follow the current upstream ComfyUI and PyTorch instructions rather than
# copying a CUDA wheel command from an old image.
pip install -r requirements.txt

python main.py \
  --base-directory /workspace/comfy-data \
  --input-directory /workspace/comfy-data/input \
  --output-directory /workspace/comfy-data/output \
  --disable-auto-launch

これは意図的にベースラインであり、万能なコピー＆ペースト用インストーラーではありません。クラウドイメージは、ドライバー、Pythonバージョン、CUDA互換性、マウントポイント、権限の点で異なります。実行中のマシンで python main.py --help を確認し、動作したら既知の正常な起動コマンドを run-notes/ に記録してください。

別のUIとモデルライブラリを共有する場合や、ComfyUIのデフォルトディレクトリ以外にモデルを配置する場合は、フォルダーを無計画にシンボリックリンクするのではなく、上流の extra_model_paths.yaml の仕組みを使用してください。これにより関係が明示され、後の再構築で予想外の問題が起きにくくなります。

4. --listen を使用する前に安全なリモートアクセスを設定する

デフォルトでは、ComfyUIは 127.0.0.1 で待ち受け、ポート 8188 を使用します。起動オプションでは、別のバインドアドレス、ポート、TLS証明書／キーファイル、設定可能なCORSヘッダーもサポートされています。正確な動作については、最新のCLI引数を確認してください。

この柔軟性は、認証されていない画像生成コンソールをパブリックインターネットに公開してよいという意味ではありません。インタラクティブな作業では、通常、安全なクラウドGPUデスクトップ上のComfyUIというパターンの方が安全です。

• 認証済みのリモートデスクトップセッション内でブラウザーを開き、ComfyUIをループバックに維持する。あるいは
• 認証済みSSHトンネルまたはプロバイダー管理のプロキシを使用する。あるいは
• 意図的に公開するComfyUIサービスの前段に、ID制御とTLSを備えたリバースプロキシを配置する。

ネットワーク経路が、ファイアウォール、IDレイヤー、および必要に応じたTLSによって意図的に保護されている場合にのみ、0.0.0.0 にバインドしてください。ブラウザー接続を動作させるだけのために、過度に許容的なCORSを有効にしないでください。カスタムノード、拡張機能、またはプロキシによって信頼境界が変わる場合は、run-notes/ に記録し、別のアカウントまたはデバイスからテストしてください。

これは、非公開の参照画像をアップロードする場合、ノード内でAPIキーを使用する場合、またはチームメイトによるカスタムノードのインストールを許可する場合に特に重要です。カスタムノードのインストールは依存関係の変更として扱ってください。ソースを確認し、バージョンを記録してから、共有本番ボリュームに追加する前に使い捨て環境でテストしてください。

5. 最初のComfyUIクラウドGPU生成を再現可能にする

最初のセッションでは、完璧な画像を追求するのではなく、デプロイメントパターンを検証するべきです。小規模で既知のワークフローを使用し、次のサイクルを完了してください。

1. 機密性のないテスト画像またはプロンプトを1つアップロードする。
2. 永続的なモデルディレクトリからモデルを1つ読み込む。
3. 対象の解像度とバッチサイズで1回生成を実行する。
4. 説明的な名前と日付を付けて、ワークフローJSONを workflows/ に保存する。
5. 最終画像と比較出力があれば、それらを output/ に保持する。
6. モデルリビジョン、関連するカスタムノード、実行時間、メモリに関する回避策を run-notes/ に記録する。

これにより、一度きりのComfyUIクラウドGPU生成が、他の人も再現できる実験になります。また、複数の大規模モデルをダウンロードした後で、ワークフローが想定した設定では実行できないと判明する前に、そのマシンが適切なサイズかどうかも確認できます。

6. GPU選定ではワークロード優先の基準を使う

ComfyUIに最適なクラウドGPUとは、必要な解像度、バッチサイズ、レイテンシで実際のグラフを確実に実行できる、利用可能な選択肢の中で最小のものです。「最適」はグラフによって変わります。

他のクリエイターのVRAM容量を保証として頼りにしないでください。チェックポイント、量子化、ノードのバージョン、解像度、バッチ設定があなたのものと一致しない可能性があります。10分間の代表的なテストは、過度に単純化されたハードウェア推奨よりも有用です。

7. 時間単位のGPU料金ではなく、完了した作業からコストを計算する

クラウドGPUの見積もりは、総コストの一部にすぎません。ワークフローまたはプロジェクトごとに、以下のワークシートを使用してください。

セッションコスト
  = （GPU稼働時間 × 現在のプロバイダーのコンピュート料金）
  + 請求期間中の保持ストレージ
  + 該当する転送、スナップショット、またはプラットフォーム料金

採用した出力1件あたりのコスト
  = セッションコスト / 実際に保持する出力数

2つ目の数値は、生成画像1枚あたりのコストよりも有用な場合がよくあります。短時間のテストを200回実行して5つの出力を保持した場合、採用出力あたりのコストは、名目上の画像1枚あたりの数値よりもワークフローについて多くを示します。

ComfyUIのクラウドGPUでは、以下の実践的な管理策を使用してください。

• 停止の習慣を定める。 誰がいつGPUを停止するかを決めます。ブラウザタブが開いているという理由だけで、GPUを稼働したままにしないでください。
• 永続データと使い捨てデータを分ける。 モデル、ワークフロー、入力、出力は永続ストレージに保存し、スクラッチファイルを誤って保持するための料金を支払わないようにします。
• スケールする前に小さくテストする。 長時間の画像または動画生成に取りかかる前に、控えめな解像度とバッチサイズでグラフを検証します。
• モデルマニフェストを維持する。 何がインストールされているか、その理由を記録します。これにより重複ダウンロードを防ぎ、クリーンアップの安全性が高まります。
• 停止状態の請求額を確認する。 ストレージ、スナップショット、パブリックIP、データ転送のルールはプロバイダーごとに異なります。現在の請求UIとドキュメントで確認してください。
• ランタイムデータを記録する。 繰り返し実行するワークフローでは、実行時間、再試行回数、採用した出力、入力／出力サイズを記録します。これにより、実際の予算ベースラインを作成できます。

より一般的な意思決定フレームワークについては、GPU Rental Prices Explainedをお読みください。魅力的な時間単位料金と、完了した作業のコストとの違いを解説しています。

8. クラウドGPUが適切な抽象化ではない場合

ComfyUIは、ノードレベルの制御、ローカルモデルファイル、カスタム処理、視覚的な反復、または特定のグラフが必要な場合に価値があります。しかし、AI機能を提供するための最も簡単な方法とは限りません。

プロダクトのニーズがワークフローレベルの制御ではなくホスト型モデル呼び出しである場合は、マネージドモデル／APIの選択肢を別途比較してください。Flatkeyは、モデルおよびツールのAPI呼び出しのための統一インターフェースを提供します。これにより統合や請求の分散を減らせますが、要件がカスタムのローカルアセットを含む永続的なノードグラフである場合には、ComfyUIの代替にはなりません。誤ったスタックを最適化する前に、この境界を明確にしてください。

事前チェックリスト

ComfyUIのクラウドGPUセッションを開始する前に、以下をすべて確認してください。

• [ ] 永続ストレージがアタッチされ、想定した場所にマウントされている。
• [ ] モデル、ワークフロー、入力、出力のパスが、そのストレージを指している。
• [ ] 現在のGPU／PyTorchの組み合わせが、実際のグラフ1つで検証されている。
• [ ] リモートアクセスが認証されており、認証されていないパブリックポートが公開されていない。
• [ ] ワークフローJSON、モデルリビジョン、カスタムノードの変更が記録される。
• [ ] GPU停止後も何に対して課金が継続するかを把握している。
• [ ] 指名された担当者が、セッション後にコンピュートを停止する。

よくある質問

クラウドGPUでComfyUIを実行するにはどうすればよいですか？

永続ボリュームを備えたインタラクティブGPUマシンをデプロイし、現在のアップストリーム手順に従ってComfyUIをインストールし、ComfyUIのモデル／入力／出力パスをマウント済みストレージに向け、ブラウザアクセスを非公開に保ち、スケールアップ前に代表的なワークフローを1つテストします。

ComfyUIでは何を永続的に保存すべきですか？

再利用するモデル、ワークフロー、再度必要になる入力アセット、最終出力、カスタムノードに関するメモ、小規模な実行ログを保存します。一時キャッシュや再構築可能な環境については、保持する価値がストレージコストを上回る場合を除き、別に扱ってください。

ComfyUI用のセキュアなクラウドGPUデスクトップは必要ですか？

ComfyUIをインターネットに直接公開せずに、インタラクティブなブラウザとターミナルを利用したい場合には、実用的な選択肢です。認証済みのリモートデスクトップ、トンネル、またはプロキシを使用し、アプリはデフォルトで非公開に保ってください。

ComfyUIに最適なクラウドGPUはどれですか？

実際のワークフローのVRAM需要、目標実行時間、ストレージ／アクセス要件に基づいて選んでください。まず想定するグラフをテストしてください。他の人のチェックポイントと解像度で動作するGPUが、あなたの用途に適しているとは限りません。

ComfyUIのクラウドGPUサービスには何が含まれるべきですか？

最低限、互換性のあるGPU環境、永続ストレージ、制御されたネットワークアクセス、ログを確認する手段、稼働中および停止中のリソースについて明確な請求情報が必要です。

このガイドで使用した公式リファレンス

• ComfyUIの手動インストールとモデルディレクトリに関するガイダンス
• ComfyUIの起動フラグ
• ComfyUI CLI引数の定義
• コンテナデータを永続化するためのRunPodガイド — プラットフォーム比較ではなく、具体的なストレージ例として使用

長期的に使えるセットアップは複雑ではありません。GPUは交換可能にし、作業は永続化し、アクセスは非公開に保ち、コンピュートの停止をワークフローの一部にしてください。