ComfyUIはMacでどれくらい大きなモデルを動かせる？2026年メモリ、ノード、リモート展開ガイド

メモリ不足でComfyUIの読み込みが止まり、生成後の拡大処理で失敗する。
最短の解決策は、単一モデルの容量ではなく完成したワークフローでピークメモリ、ノード互換性、処理時間を確認し、変動が大きい案件だけリモートMacへ切り替えることです。

この記事は、MシリーズMacでComfyUIを使いたい個人クリエイター向けです。複雑なワークフローやカスタムノードを再利用するデザインチーム、統合メモリや短期的なリモート算力を見積もる担当者にも役立ちます。

判断の前提

ComfyUIはmacOS向けDesktop版でApple siliconに対応しており、Metal高速化を利用できます。ただし、対応していることと、目的のワークフローが最後まで正しく生成できることは別です。対応状況はComfyUI、PyTorch、macOS、カスタムノードの更新で変わるため、2026年9月4日時点でも固定的な「この容量ならこのモデル」という保証はできません。

ComfyUI公式のmacOSインストール手順でも、導入手順と実行環境を確認できます。購入前は、次の順序で判断してください。

判定項目	確認する内容	不合格時の判断
メモリ	モデル群を同時に読み込んだピーク値	モデルを減らすか、統合メモリに余裕のある環境で再検証
ノード	カスタムノードの依存関係と出力結果	該当ノードを固定版に戻すか、代替ノードを探す
速度	初回読み込み、通常生成、拡大処理の所要時間	解像度やバッチを見直し、案件単位で遠隔環境を検討
保存領域	モデル、出力、キャッシュ、作業用一時ファイル	モデル用ディレクトリを分離し、空き容量を確保
回復性	連続実行、切断後の処理、再起動後の復元	ノードとワークフローを固定して再試行

ここでいう「大きなモデル」とは、重みファイルの容量だけを指しません。基盤モデル、テキストエンコーダー、VAE、Control系モデル、拡大モデルが同時に常駐する構成なら、ファイルを順番に読み込む簡単な例よりピークが高くなります。

メモリ構成の見積もり

ComfyUI Macのモデル構成を決めるときは、まずワークフローを構成する資産を一覧化します。基盤モデルだけを読み込んで成功しても、制御画像、複数のエンコーダー、拡大処理まで追加した時点で停止することがあります。

統合メモリはGPU専用メモリと同じ考え方ではありません。アプリケーション、macOS、ComfyUI本体、キャッシュ、入力画像、出力処理も同じメモリ資源を使います。そのため、モデルの合計容量ぎりぎりに合わせるのではなく、実行中のピークと空き容量の推移を確認する必要があります。

ワークフロー	同時に確認する構成	メモリ判定のポイント
軽量な画像生成	基盤モデル、テキスト処理、VAE	初回読み込み後に再生成できるか
制御付き生成	基盤モデル、制御モデル、入力画像、VAE	制御処理の開始時にピークが上がらないか
高解像度処理	生成系モデル、拡大モデル、複数の中間画像	拡大段階でメモリが解放されるか
チーム用の複合処理	複数モデル、カスタムノード、成果物出力	ユーザー別の資産とキャッシュが衝突しないか

「ComfyUIはMacでどれくらい大きなモデルを動かせるか」という問いに、モデル名だけで答えるのは危険です。同じモデルでも、低い解像度と大きな解像度、単一画像と複数画像、通常生成と拡大処理では必要なメモリが変わります。

注意
メモリ圧力が発生したときは、単にアプリを再起動して成功した結果を採用しないでください。再起動直後だけ通るワークフローは、連続バッチやチーム運用では再現性が不足しています。

ノード互換性の確認

Metal高速化を有効にできても、すべてのカスタムノードがApple silicon向けに動くとは限りません。特に、特定のGPU実装、CUDA前提の処理、OS固有のバイナリ、古いPython依存関係を含むノードは注意が必要です。

ComfyUIのカスタムノード概要で役割を確認し、導入時は公式のカスタムノードインストール手順に従います。確認する順番は、次のとおりです。

ワークフローで使用しているノード名を一覧化します。
各ノードの公式リポジトリでApple silicon、macOS、必要なPython依存関係を確認します。
依存パッケージを導入し、ノードが一覧に表示されることを確認します。
サンプル画像ではなく、実際に使う入力形式を渡します。
生成画像の色、構図、制御結果、メタデータを期待値と比較します。
エラーが出なかった場合も、CPU処理へのフォールバックや未実行の分岐がないかログを確認します。
検証済みのノード版と依存関係を記録し、自動更新を止める運用にします。

ノードの登録やインストールに成功しただけでは、互換性の証明になりません。正しい画像が最後まで出力されること、再起動後にも同じワークフローを呼び出せることまでが合格条件です。Registryのバージョン管理説明も、更新を管理する際の確認材料になります。

生成時間の計測

速度を比較するときは、固定条件を先に決めます。モデル、サンプラー、ステップ設定、解像度、バッチ数、入力画像、カスタムノードの版、ComfyUIとmacOSの版を記録してください。条件が一つでも変われば、別の測定結果として扱います。

計測は「初回読み込み」「2回目以降の生成」「拡大処理」に分けます。初回だけ遅いのか、繰り返し生成でも遅いのか、拡大段階だけがボトルネックなのかを分離しないと、Macの選定を誤ります。

ComfyUIを終了し、同じ環境で起動します。
モデルの読み込み開始から生成可能になるまでを記録します。
固定した入力で通常生成を実行します。
同じ条件で再度生成し、初回との差を記録します。
拡大処理や制御処理を追加し、段階ごとの時間とピークメモリを記録します。
連続して目標バッチを処理し、失敗回数と再実行の有無を残します。

公式のComfyUI初回生成ガイドは基本的な動作確認に使えますが、購入判断にはあなたの完成ワークフローが必要です。単発の生成時間だけを広告や比較表の根拠にしないでください。

保存領域と復旧設計

モデルを保存する場所と、アプリの資源、自動生成されるキャッシュ、出力先は分けて管理します。モデルの追加や入れ替えが多い場合、アプリの更新とモデル資産を同じディレクトリに置くと、移行や再インストール時の復旧範囲が分かりにくくなります。

ComfyUIの設定とモデルディレクトリに関する説明を確認し、次の情報をバックアップしてください。

ワークフローのJSONファイル
カスタムノード名と検証済みの版
Python依存関係の記録
モデルの配置先とファイル名
主要設定と入力素材の参照先
成功した出力例と期待する検査結果

出力画像や中間ファイルを長期間残す運用では、生成処理そのものより保存領域が先に逼迫することがあります。不要なキャッシュを削除する前に、再生成に必要な設定や入力素材が残っているか確認してください。

チーム運用とリモート展開

個人利用では、ローカルMacの直接操作が最も単純です。モデルを頻繁に交換せず、ワークフローが固定され、作業場所からファイルを扱う必要があるなら、毎回転送するよりローカル環境の方が管理しやすくなります。

一方、デザインチームでは次の問題が発生します。

同じモデルをユーザーごとに保存して容量が重複する
実行待ちのジョブが増え、誰の処理か分かりにくくなる
入力素材と出力成果物の権限が混ざる
リモート画面が切断されたとき、処理が継続するか分からない
ノードを更新した担当者によって、検証済み環境が変わる

リモートMacを採用する場合は、まず小さな実案件でファイル転送、セッション切断、処理の保活、出力回収を確認します。作業終了後に成果物を誰が取得できるか、モデル資産を誰が更新できるかも決めておく必要があります。

日本国内で短期の検証環境を比較する場合は、KvmkitのMac miniレンタル案内を確認できます。地域より先に、必要なソフトウェア、ファイル転送方式、接続方法、利用期間を整理してください。

2026年版ワークフロー受け入れ確認

次の項目をすべて実行し、未確認の項目を「対応済み」と扱わないでください。

[ ] 基盤モデル、テキストエンコーダー、VAE、制御モデル、拡大モデルを一覧化した
[ ] 完成ワークフローを読み込み、実行中のピークメモリを記録した
[ ] 初回読み込み、通常生成、拡大処理を別々に計測した
[ ] 解像度、バッチ数、サンプラー、ステップ設定を固定した
[ ] 使用するカスタムノードの公式リポジトリを確認した
[ ] ノードのインストール成功だけでなく、画像の出力結果を確認した
[ ] ComfyUI、macOS、PyTorch、ノードの版を記録した
[ ] モデルディレクトリとアプリ資源ディレクトリを分離した
[ ] ワークフロー、ノード一覧、主要設定をバックアップした
[ ] 目標バッチを連続実行し、失敗と再起動後の復旧を確認した
[ ] リモート利用時の転送、切断、処理継続、成果物回収を確認した
[ ] ノードの自動更新で検証済み環境が変わらないようにした

メモリだけ合格し、ノード互換性や回復性が未確認なら、購入判断は保留してください。ComfyUI Macの構成は、ピークメモリ、処理時間、成功率、運用の手戻りをまとめて評価して初めて決まります。

よくある判断

ComfyUIのモデル容量

「最も大きいモデルを読み込めるか」ではなく、実際に同時常駐するモデル群と中間画像を確認します。複数モデルを使うワークフローでは、単一ファイルの容量を足した値だけではピークを再現できません。

統合メモリの選び方

必要な統合メモリを先に断定するのではなく、完成ワークフローで測ったピークに余裕を持たせて選びます。軽量な固定処理ならローカルを優先し、構成が頻繁に変わるならリモート環境で先に受け入れ試験を行います。

Apple siliconでのノード対応

Apple silicon対応を明記していないノードは、インストール画面だけで判断しません。依存関係、演算子、出力画像、再起動後の再現性を確認し、CUDA専用処理を含む場合は代替手段を用意します。

ローカルMacとリモートMac

長期間にわたって同じ軽量ワークフローを使うならローカルMacが管理しやすいです。短期案件、急な処理量の増加、チーム共有ではリモートMacを試し、接続と成果物の受け渡しまで検証できた場合に採用します。

更新後の再検証

ComfyUI本体、PyTorch、macOS、主要カスタムノードのいずれかを更新したら、保存しておいた固定ワークフローを再実行します。確認するのは起動だけではなく、ピークメモリ、各段階の時間、画像結果、連続処理、再起動後の復旧です。

最終更新：2026年9月4日。 ComfyUI公式のシステム要件、macOSインストール文書、カスタムノード文書、設定文書を基に内容を確認しています。Metalの位置付けについては、Apple公式のMetal資料も参照してください。

手元のMacで固定ワークフローを長期間使うなら、ローカル構成が合理的です。ただし、現行環境でメモリ不足が起きる、カスタムノードを常時保活したい、案件の処理量が短期間だけ増えるという状況では、モデルの再配置、ジョブ待ち、接続切断、成果物回収が負担になります。その場合は、ワークフロー一式を整理してからKvmkitのMac環境で試走し、実際の成功率と運用負荷を比べる方が、推測だけでMacを購入するより安全です。

よくある質問

ComfyUIはMacでどの程度のモデル構成まで扱えますか？

単一モデルの容量ではなく、基盤モデル、テキストエンコーダー、VAE、制御用モデル、拡大用モデルが同時に読み込まれるかで決まります。Apple siliconではMetal高速化を利用できますが、精度、解像度、バッチ数、カスタムノードの実装によって必要な統合メモリは変わるため、完成形のワークフローでピーク値を確認してください。

ComfyUI用のMacは統合メモリをどのように選ぶべきですか？

必要量をモデルファイル1個のサイズに合わせて決めるのではなく、実行時のピークメモリに、アプリ、macOS、キャッシュ、出力処理の余裕を加えて判断します。まず普段使うワークフローを固定し、初回読み込み、通常生成、拡大処理を別々に記録してください。空き容量が少ない状態での選択は避けます。

Apple siliconで動かないカスタムノードはどう見分けられますか？

インストールが完了しても、生成処理が正しく動くとは限りません。ノードの公式リポジトリで対応環境、依存パッケージ、CPU専用処理、CUDA前提の演算子を確認し、実際の入力から出力までを検証します。エラーが出ない場合でも、画像の欠落、色の変化、制御結果の無視がないか確認することが重要です。

ComfyUIはローカルMacとリモートMacのどちらが向いていますか？

固定した軽量ワークフローを長期間使い、物理的なファイル操作が多いならローカルMacが向いています。一方、プロジェクトごとにモデルやノードが変わる、短期間だけ処理量が増える、チームで共有する必要がある場合は、リモートMacで先に実ワークフローを検証する方が安全です。転送、切断後の処理継続、成果物の回収まで確認してください。