FLUX.1 + COMFYUI
メモリボトルネック完全解析.

// なぜ 16GB / 32GB Mac では Flux.1 が 60 分以上かかるのか。「赤いメモリ圧力」と swap の連鎖が AI 画像生成を破壊するメカニズムを解析し、64GB 統合メモリが唯一の解決策である理由をデータで証明します。

Flux.1 ComfyUI Mac メモリボトルネック 64GB統合メモリ解析

01_問題の核心：Flux.1 が Mac を「詰まらせる」本当の理由

2026年初頭、AI 創作コミュニティで急増した検索キーワードがあります。「ComfyUI M4 Mac 遅い」「Flux.1 生成 60分」「Mac メモリ圧力 赤」。これらはすべて、同一の根本原因から派生しています。統合メモリ（Unified Memory）の絶対容量不足です。

Flux.1 Dev は FP16 精度でモデルウェイトだけで約 23GB、推論時の中間テンソル・KVキャッシュ・VAEデコーダを合算すると、ピーク時のメモリ使用量は 30〜38GB に達します。Flux.1 Schnell でも同様に 20〜28GB 程度が必要です。これに対して 16GB モデルでは全体の 2〜3 倍もの不足が生じ、macOS はディスクへの swap を余儀なくされます。swap が発生した瞬間、GPU と CPU が共有する統合メモリへのアクセス帯域（M4 Pro の場合 273 GB/s）は事実上意味を失い、NVMe SSD を介した読み書きのボトルネックに変わります。SSD の実効スループットは理論値で 7 GB/s 前後ですから、帯域は 97% 以上削減されます。これが「60 分かかる」の正体です。

⚠ 赤いメモリ圧力（Red Memory Pressure）とは
macOS の「アクティビティモニタ」でメモリ圧力が赤くなった状態は、OS がメモリページをディスクに圧縮・スワップし始めていることを意味します。この状態では GPU カーネルが必要なテンソルをタイムリーに受け取れず、MPS（Metal Performance Shaders）パイプラインに深刻なストールが発生します。一度赤くなると、ファンが最大回転しても性能はほぼ回復しません。

02_統合メモリ アーキテクチャの解剖：なぜ Mac は特別なのか

Apple Silicon の最大の特徴は、CPU・GPU・ANE（Apple Neural Engine）が 単一の統合メモリプール を共有している点です。従来の x86 システムでは CPU が DDR5 DRAM を、GPU が GDDR6/HBM を別々に持ちます。そのため、CPU → GPU へのデータ転送（PCIe 経由）がボトルネックになるケースが多く、ゲーミング GPU の VRAM 上限（RTX 4090 で 24GB）がモデルサイズの制約になっていました。

Apple Silicon ではその転送コストがゼロです。モデルウェイトをメモリに一度ロードすれば、GPU と CPU が同じ物理アドレスを参照します。PyTorch の MPS バックエンドはこれを活用し、Metal API 経由でシェーダコードをGPU に直接ディスパッチします。この設計が、統合メモリ容量さえ十分であれば Flux.1 のような巨大モデルが驚くほど高速に動く理由です。逆説的ですが、この設計があるからこそ「容量不足時のペナルティ」も他のアーキテクチャより深刻になります。swap が CPU メモリ側に食い込むと GPU 側にも影響が出るためです。

M4 Pro メモリ帯域
273 GB/s

CPU+GPU 統合帯域幅（実測値）

SSD swap 帯域
~7 GB/s

NVMe Gen4 実効スループット（大幅低下）

帯域削減率
97.4%

swap 発生時の実効帯域低下

03_メモリ別パフォーマンス実測：16GB vs 32GB vs 64GB

以下は、ComfyUI + Flux.1 Dev（FP8 量化済み、1024×1024、20ステップ）を用いた実測データです。各機種とも macOS 15.x、PyTorch 2.4+、ComfyUI 最新版を使用しています。

構成 統合メモリ 1枚あたり生成時間 メモリ圧力 swap 発生
M4 (基本) / Mac mini 16 GB 60〜90 分以上 赤（常時） 大量発生
M4 Pro / MacBook Pro 14" 24 GB 15〜30 分 赤（高頻度） 断続的に発生
M4 Pro / MacBook Pro 14" 32 GB 3〜8 分 黄（条件次第） フルモデル時に発生
M4 Pro / macgpu ノード 64 GB 45〜90 秒 緑（常時） 発生なし

64GB 環境では、Flux.1 Dev のフル精度モデル（23GB）をロードした後でも、OS・ComfyUI ランタイム・VAE・追加 LoRA のぶんを合わせて余裕のあるバッファが残ります。テンソル演算に必要なワーキングメモリが統合メモリ内に完全に収まるため、Metal シェーダのディスパッチが中断されることなく、GPU 20コアをフル稼働させ続けることができます。

04_GGUF 量化の効果と限界：16GB を「使えるレベル」にする方法

メモリ不足を緩和する手段として、GGUF（GGML Unified Format）による量化があります。Flux.1 Dev の Q4_K_M 量化モデルはファイルサイズが約 10GB まで圧縮され、16GB 環境でも swap を最小限に抑えながら動作させることが可能です。ComfyUI では ComfyUI-GGUF カスタムノードをインストールすることで対応できます。

# ComfyUI-GGUF カスタムノードのインストール $ cd ~/ComfyUI/custom_nodes $ git clone https://github.com/city96/ComfyUI-GGUF.git $ cd ComfyUI-GGUF && pip install -r requirements.txt # Flux.1 Dev Q4_K_M GGUF モデルのダウンロード（約 10GB） $ cd ~/ComfyUI/models/unet $ wget https://huggingface.co/city96/FLUX.1-dev-gguf/resolve/main/flux1-dev-Q4_K_M.gguf # ComfyUI の起動 $ cd ~/ComfyUI $ python main.py --listen 0.0.0.0 --port 8188

ただし、GGUF 量化には明確なトレードオフがあります。Q4_K_M で画像品質は FP16 比で約 5〜8% 低下し、特に細部のテクスチャや文字描画精度が若干落ちます。Q8 量化（ファイルサイズ約 17GB）では品質劣化は 2% 未満ですが、32GB 環境でないとやはり swap が発生します。

⚠ GGUF 量化は「応急処置」であることを理解してください
Q4_K_M でも 16GB 環境ではバッチサイズ 1 の単枚生成しか安定しません。ControlNet・IP-Adapter・Regional Conditioning を組み合わせた本格的なワークフローでは、補助モデルの分だけメモリが積み増され、結局 swap に落ちます。プロダクション品質を求めるなら、64GB が現実的な最低ラインです。

05_実践手順：M4 Pro 64GB ノードで Flux.1 フルパイプラインを構築する

以下は、MACGPU のベアメタル M4 Pro 64GB ノードに SSH 接続し、Flux.1 Dev をフル精度（FP16）で動作させるまでの完全な手順です。敬体で順を追ってご説明いたします。

Step 1：ノード接続とハードウェア確認

# SSH 接続 $ ssh -i ~/.ssh/your_key macgpu@<NODE_IP> # ハードウェア確認 $ system_profiler SPHardwareDataType | grep -E "Chip|Memory" Chip: Apple M4 Pro Memory: 64 GB # Python 環境確認 $ python3 --version Python 3.12.x # Metal / MPS が利用可能か確認 $ python3 -c "import torch; print(torch.backends.mps.is_available())" True

Step 2：ComfyUI のセットアップ

# 作業ディレクトリの作成 $ mkdir -p ~/ai-workspace && cd ~/ai-workspace # ComfyUI のクローン $ git clone https://github.com/comfyanonymous/ComfyUI.git $ cd ComfyUI # 仮想環境の作成と有効化 $ python3 -m venv venv $ source venv/bin/activate # PyTorch（MPS 対応版）と依存関係のインストール $ pip install --upgrade pip $ pip install torch torchvision torchaudio $ pip install -r requirements.txt

Step 3：Flux.1 Dev フルモデルの配置

# Flux.1 Dev（FP16、約 23.8GB）のダウンロード # ※ Hugging Face からダウンロードするには事前にアクセストークンが必要です $ cd ~/ai-workspace/ComfyUI/models/unet $ huggingface-cli download black-forest-labs/FLUX.1-dev \ flux1-dev.safetensors \ --local-dir . # VAE のダウンロード（約 335MB） $ cd ~/ai-workspace/ComfyUI/models/vae $ wget https://huggingface.co/black-forest-labs/FLUX.1-dev/resolve/main/ae.safetensors # テキストエンコーダ（CLIP-L）のダウンロード $ cd ~/ai-workspace/ComfyUI/models/clip $ wget https://huggingface.co/openai/clip-vit-large-patch14/resolve/main/model.safetensors \ -O clip-l.safetensors # T5-XXL テキストエンコーダ（約 9.8GB、FP8 量化版を推奨） $ wget https://huggingface.co/comfyanonymous/flux_text_encoders/resolve/main/t5xxl_fp8_e4m3fn.safetensors

Step 4：ComfyUI の起動とメモリ状態確認

# ComfyUI の起動（外部アクセス許可） $ cd ~/ai-workspace/ComfyUI $ python main.py --listen 0.0.0.0 --port 8188 # 別ターミナルで起動後のメモリ使用量を監視 $ python3 -c " import subprocess, time for _ in range(3): result = subprocess.run( ['vm_stat'], capture_output=True, text=True ) lines = result.stdout.split('\n') for l in lines: if 'free' in l or 'swap' in l.lower(): print(l) print('---') time.sleep(10) " # 期待される出力（swap なし、十分な空きページ）： Pages free: 802341. Pages speculative: 15482. Swapins: 0. Swapouts: 0.
✅ 64GB 環境での実測結果
M4 Pro 64GB ノードにて Flux.1 Dev フル精度（1024×1024、20ステップ）を実行した結果、Swapins / Swapouts は共に 0 のまま、生成時間は 平均 52 秒（初回モデルロード含む）でした。メモリ圧力計は常時緑を維持しました。

06_ワークフロー高速化：MPS 最適化とキャッシュ戦略

64GB のメモリリソースを最大限活用するため、いくつかの追加最適化をご紹介いたします。

PyTorch MPS メモリキャッシュの管理

# ComfyUI 実行中に MPS のメモリ使用状況を確認するスクリプト $ python3 <<'EOF' import torch if torch.backends.mps.is_available(): # 現在割り当て済みのメモリ量（バイト） allocated = torch.mps.current_allocated_memory() # MPS ドライバが確保しているメモリ（キャッシュ含む） driver = torch.mps.driver_allocated_memory() print(f"MPS allocated: {allocated / 1024**3:.2f} GB") print(f"MPS driver: {driver / 1024**3:.2f} GB") print(f"Free estimate: {(64 - driver / 1024**3):.2f} GB") EOF # 期待される出力（モデルロード後）： MPS allocated: 26.43 GB MPS driver: 29.81 GB Free estimate: 34.19 GB

64GB 環境では、Flux.1 Dev のウェイトロード後でも約 34GB が OS・アプリ・追加モデルのために確保されていることがわかります。これにより、ControlNet（約 1.4GB）や IP-Adapter（約 1GB）を同時にロードしても余裕が生まれます。

バッチ生成のスループット最適化

# ComfyUI API を使ったバッチ生成スクリプト（例：4枚連続生成） $ cat > ~/batch_flux.py <<'EOF' import urllib.request, json, time SERVER = "http://localhost:8188" def queue_prompt(prompt_json): data = json.dumps({"prompt": prompt_json}).encode('utf-8') req = urllib.request.Request(f"{SERVER}/prompt", data=data, headers={'Content-Type': 'application/json'}) with urllib.request.urlopen(req) as resp: return json.loads(resp.read()) # ここに ComfyUI ワークフロー JSON を記述 # 4枚連続生成の場合、バッチサイズより sequential が安定 for i in range(4): print(f"Queueing image {i+1}/4...") # result = queue_prompt(your_workflow_json) time.sleep(1) EOF

07_Flux.1 Schnell vs Dev：用途に応じた選択指針

Flux.1 には主に 2 つのバリアントがあります。Schnell（高速・ライセンス制約あり）と Dev（高品質・非商用）です。メモリ要件とスピードのトレードオフを以下に整理いたします。

モデル 最小ステップ数 FP16 容量 推奨メモリ 用途
Flux.1 Schnell 4〜8 ステップ 23.8 GB 32GB 以上（64GB 推奨） プロトタイプ・高速反復
Flux.1 Dev 20〜28 ステップ 23.8 GB 64GB 必須 高品質最終出力
Flux.1 Dev GGUF Q8 20〜28 ステップ 17.2 GB 32GB（品質妥協あり） 32GB 環境での代替
Flux.1 Dev GGUF Q4_K_M 20〜28 ステップ 10.1 GB 16GB（品質大幅低下） 動作確認のみ

商用プロジェクトや、クライアントへの納品物として AI 生成画像を活用される場合は、Flux.1 Dev の FP16 フル精度一択です。そのためには 64GB 統合メモリが現実的な最低条件となります。

08_MACGPU の価値切入点：64GB M4 Pro 裸機ノードで「即日解決」する

ここまでお読みいただければ、64GB 統合メモリの必要性は疑いの余地がないことをご理解いただけたかと存じます。しかし、M4 Pro 64GB 搭載の Mac mini または MacBook Pro を購入するには、2026 年現在で 35〜50 万円前後の初期投資が必要です。さらに、Flux.1 の本格的なワークフローは長時間の稼働を想定するため、個人所有機では熱管理（ファン騒音・テーブル上での連続稼働）も問題になります。

MACGPU が提供する M4 Pro 64GB ベアメタルノード は、これらの課題を一括解決いたします。物理専有ノードのため仮想化によるオーバーヘッドがなく、Metal Performance Shaders のパイプラインを 100% 占有できます。データセンター環境での 24/7 稼働を前提とした冷却設計により、長時間バッチ生成でもサーマルスロットリングが発生しません。また、Hugging Face からのモデルダウンロードには、データセンターの高速回線（最大 10 Gbps）をご利用いただけます。23.8GB の Flux.1 Dev モデルを約 3〜4 分 でダウンロード完了できます。

Flux.1 Dev 生成速度
52 秒/枚

1024×1024、20steps、M4 Pro 64GB 実測

16GB 機との比較
最大 100倍

swap 常時発生環境比（90分→52秒）

初期費用
¥0

月額制・当日利用開始可能

09_よくある質問と追加設定

Q: ComfyUI でメモリ使用量を手動で制限できますか？

はい、可能です。ComfyUI 起動時に --lowvram フラグを追加することで、モデルを CPU メモリに退避させつつ推論時だけ GPU に展開する挙動に切り替えられます。ただし 64GB 環境ではこのフラグは不要です。逆に --highvram フラグを指定すると、ComfyUI がモデルをできる限り GPU メモリ（統合メモリ）に常駐させ、バッチ生成時の再ロードコストを最小化します。64GB ノードでは --highvram の使用を推奨いたします。

# 64GB ノードでの推奨起動オプション $ python main.py \ --listen 0.0.0.0 \ --port 8188 \ --highvram \ --preview-method auto

Q: ControlNet や IP-Adapter は同時に使えますか？

Flux.1 対応の ControlNet（Union モデルで約 6.1GB）および IP-Adapter（約 1.0GB）を同時ロードしても、64GB 環境ではメモリ圧力が緑のまま維持されます。ControlNet + IP-Adapter + Flux.1 Dev の合計メモリ使用量は約 38〜42GB 程度となり、OS や ComfyUI のランタイムも含めて 64GB に余裕で収まります。

Q: データの安全性はどうですか？

MACGPU の物理ノードは専有構成です。他ユーザーと統合メモリ・ストレージを共有することはありません。生成した画像や入力プロンプト、LoRA モデルはすべてノード上に留まり、MACGPU のサーバーには転送されません。AI クリエイティブにおける知的財産保護の観点からも、パブリッククラウドより優れた隔離性を提供いたします。

10_まとめ：2026 年の AI 画像生成、64GB が「普通」になる年

本稿では、Flux.1 + ComfyUI を Mac で動かす際のメモリボトルネックを多角的に解析いたしました。統合メモリ帯域（273 GB/s）と SSD swap 帯域（~7 GB/s）の 97% もの差が、「60分かかる」問題の根本原因であることをデータで示しました。GGUF 量化は応急処置として有効ですが、プロダクション品質のワークフローには FP16 フル精度＋64GB が現実的な要件です。

AI 画像生成の需要は 2026 年に向けてさらに拡大し、Flux.2 や次世代モデルのウェイトはさらに大きくなることが予想されます。今、64GB 統合メモリ環境を確保しておくことは、ハードウェアへの先行投資なしに次世代モデルへ対応できるという意味で、長期的にも賢明な選択です。MACGPU のレンタルノードであれば、月額制で今日から 64GB 環境を利用開始でき、必要に応じていつでもアップグレードや解約が可能です。AI クリエイティブを本気で追求される方に、ぜひご検討いただければ幸いです。