RAKSUL TechBlog

RAKSULグループのエンジニアが技術トピックを発信するブログです

FLUX 2.0を32GBユニファイドメモリMacBookで使ってみた

Technology 生成AI FLUX AdventCalendar Stable Diffusion ComfyAI

こんにちは。ノバセルCTOの磯部です。

この記事はノバセル テクノ場 出張版2025 Advent Calendar 2025の1日目です。ノバセルでは毎週「テクノ場」と呼ばれるLightning Talkを行い、技術的な共有を行っています。今年は「テクノ場」の出張版として、アドベントカレンダーとして社外にも向けて技術的な共有を行います。

さて、皆さん画像生成AIは使っておられますか。ChatGPTやGeminiで画像を生成した経験があるエンジニアの方は多いと思いますが、これらはクローズドなモデルであり、カスタマイズ性やコスト、セキュリティの面で課題となることもあります。

そこで注目されるのが、ローカル環境で実行可能なOpen Weightモデル（重みが公開されているモデル）です。そして2025年11月、最新のモデル「FLUX 2.0」が登場しました。

FLUX 2.0は、Stable Diffusionの初期開発メンバーも参加するドイツの「Black Forest Labs (BFL)」によって開発されました。

本記事では、FLUX 2.0のOpen Weight版であるFLUX 2.0 [dev]をComfyUIを使ってローカル環境（32GBユニファイドメモリMacBook）で動かせるのかを検証します。

先にネタバラシをしておくとローカル環境で動かすことはできなかったのでタイトルは釣りです。しかし、公式APIノードを使用することでFLUX 2.0 [pro]をComfyUI上で動かすことができたので、その方法をお教えしたいと思います。

FLUX 2.0とは？Stable Diffusionとの違い

FLUX 2.0 [dev]は、320億（32B）パラメータという、Open Weightモデルとしては非常に大規模です。その性能は、現在最高峰とされるクローズドモデル（GoogleのNano Banana Proなど）には一歩及ばないものの、非常に高い性能とコストパフォーマンスを誇ります。

出典：FLUX.2: Frontier Visual Intelligence

アーキテクチャの刷新：DiffusionからFlow Matchingへ

以前の主流であったStable Diffusion（SD1.5, SDXLなど）は、「Latent Diffusion Model (LDM)」を採用しています。これは、ノイズ画像を徐々に綺麗にしていく（拡散プロセス）ことで画像を生成する技術で、主に「U-Net」という構造が使われます。

一方、FLUX 2.0はStable Diffusion 3.0でも採用されている「Latent Flow Matching」という新しいアプローチを採用しています。これは、拡散プロセスよりも効率的に、ノイズから画像への「流れ（Flow）」を直接学習する手法です。

さらに、コア部分にはU-Netではなく、LLMで広く使われる「Transformer」（Rectified Flow Transformer）が採用されています。

graph LR
    subgraph "Stable Diffusion (Diffusion Model / U-Net)"
        A[ノイズ] --> B(デノイズ Step 1);
        B --> C(...);
        C --> D(デノイズ Step N);
    end

    subgraph "FLUX 2.0 (Flow Matching / Transformer)"
        F[ノイズ] ==> G(Flowを直接辿る);
    end

    D --> I[最終画像];
    G --> I;

このアーキテクチャの刷新により、FLUX 2.0はより効率的で、整合性の高い画像生成を実現しています。

高い表現力

FLUX 2.0は、Mistralベースの強力な視覚言語モデル（VLM）をText Encoderとして搭載しています。これにより、複雑なプロンプトを深く理解し、現実世界の知識に基づいた描写が可能です。

性能比較では、Nano Banana Proがロジックを重視し、指示の正確性や構造的な整合性に優れています。一方、FLUX 2.0は美的センスを重視し、映画的でリッチなビジュアル表現に強みがあると評価されることが多いです。

また、FLUX 2.0には以下のような特徴があります。

  • テキストレンダリング能力: Stable Diffusionが苦手としていた文字の描写能力が向上。広告バナーのキャッチコピー生成に有効。
  • マルチリファレンス生成: 最大10枚の参照画像から、スタイルや被写体の一貫性を維持したまま新しい画像を生成できる。

商用利用の注意点

FLUX 2.0にはいくつかのバリエーションがあります。

  • FLUX.2 [Pro] / [Flex]: API経由で提供される商用モデル。価格計算ページ
  • FLUX.2 [dev]: 今回使用するOpen Weightモデル。

FLUX.2 [dev]は誰でもダウンロード可能ですが、「Open Source」とは異なり、「FLUX [dev] Non-Commercial License」の下で公開されています。

このライセンスの解釈は非常に重要です。

  1. 研究・個人利用: 無料で利用可能。
  2. 生成物（Output）の利用: 生成された画像自体は、禁止用途を除き商用利用可能。
  3. モデルの利用制限: モデル自体を「Non-Commercial Purpose（非商用目的）」以外で利用することは制限されている。

ライセンス条項では、「収益を生む活動」での利用は非商用目的に含まれないと明記されています。したがって、企業が業務の一環として（例：従業員が広告制作のためにローカルPCで画像を生成する）このモデルを利用する場合、それは「商用目的でのモデルの利用」と見なされます。

企業が業務フローに組み込む場合は、BFLから商用ライセンスを取得する必要があります。セルフホスト用の商用ライセンスは、月額$1999（20万枚まで）で提供されています。ライセンスページ

本記事では、あくまで技術検証という位置づけでFLUX.2 [dev]を使用します。

まずは公式デモでFLUX 2.0の性能を体験する

ローカル環境構築の前に、まずはBlack Forest Labsの公式サイトで性能を体験してみましょう。

https://bfl.ai/play

汎用的な冬のキャンペーンバナーを想定し、テキスト描写を試すプロンプトを入力してみます。

プロンプト例:

A promotional banner for a winter campaign. A cheerful Japanese woman in a warm coat is smiling in a snowy city street. Bokeh background with illumination. Text on the image: "冬の集客応援キャンペーン". High quality, commercial photography.

実際の広告として効果的かはさておき、非常にリアルな画像と「冬の集客応援キャンペーン」というテキストが破綻なく描写されています。フォントにはまだ違和感が残りますが、従来のStable Diffusionではこのレベルのテキスト生成は困難でした。

最大10までの素材をインプットとして使用することもできます。どうでしょう？及第点ぐらいはあるんじゃないでしょうか。

ローカル環境でFLUX 2.0を動かす

Open Weightモデルの真価は、ローカル環境で自由にカスタマイズできることにあります。FLUX 2.0を動かすためのインターフェースとして、今回はComfyUIを使用します。

ComfyUIとは？

ComfyUIは、画像生成プロセスをノード（機能ブロック）を繋ぎ合わせることで構築するツールです。

Stable Diffusion用と思われがちですが、ComfyUIは汎用的なプラットフォームであり、FLUXのような異なるアーキテクチャのモデルもサポートしています。処理の流れが可視化されるため、複雑なワークフローも管理しやすいのが特徴です。

勝算

FLUX.2 [dev]（32Bパラメータ）は非常に巨大で、本来はデータセンター級のGPU（64GB以上のVRAM）が必要です。しかし、以下の技術によりコンシューマー環境でも動作可能になっています。

  1. 量子化 (Quantization): モデルの精度を維持しつつデータサイズを削減する技術。通常、AIモデルの重みはFP16（16ビット浮動小数点数）やBF16で保持されますが、これをより小さいビット数で表現することでメモリ使用量を削減します。BFLとNVIDIA、ComfyUIチームの協力により、FP8（8ビット浮動小数点数）に量子化されたモデルが提供されており、VRAM要件が約40%削減されます。
  2. Weight Streaming / Offloading: VRAMが不足する場合に、モデルの一部をシステムRAMに退避させる技術。ComfyUIではこの機能が強化されています。

検証環境

今回は以下の環境で検証しました。Apple Silicon MacはメモリをGPUと共有するユニファイドメモリ構造のため、Offloadingとの相性が良く、32GBのメモリがあれば動作が期待できるかも知れません。

  • PC: MacBook Air (15-inch, 2025)
  • Chip: Apple M4
  • Memory: 32GB

ワークフローの解説

ComfyUI公式ドキュメントで提供されているFLUX 2.0 [dev] 用サンプルワークフローをインポートします。

※ 本記事では、ComfyUIのセットアップ、モデルのダウンロード、ワークフローのインポートは完了している前提で進めます。

主要な部分を解説します。

1. モデルのロード (Step 1エリア)

画像生成には、役割の異なる3つのモデルが必要です。

  • UNETLoader: FLUX 2.0の本体（拡散モデル）をロードします。ここではFP8量子化されたflux2_dev_fp8mixed.safetensorsを使用します。
  • CLIPLoader: Text Encoder（VLM）をロードします。CLIP（またはVLM）は、プロンプト（テキスト）をモデルが理解できる数値表現（ベクトル）に変換する役割を担います。FLUX 2.0の強力な言語理解はここに由来します。
  • VAELoader: VAE (Variational Autoencoder)をロードします。画像を効率的な「潜在空間」に圧縮（エンコード）したり、画像に復元（デコード）したりする役割を持ちます。画像生成の計算は潜在空間で行われます。

2. プロンプト入力 (Step 2エリア)

  • CLIPTextEncode: ここにプロンプトを入力します。

3. 参照画像 (Step 3エリア)

  • LoadImage, ReferenceLatent: 参照画像を使用する機能（Multi-Reference）です。今回はまずText-to-Imageを試すため、ReferenceLatentノードをバイパス（無効化）します。

4. サンプリングと保存 (Custom samplerエリア)

  • SamplerCustomAdvanced: ここが画像生成の心臓部です。設定されたステップ数に基づき、Flow Matchingアルゴリズムを用いて画像を生成します。
  • VAEDecode: 潜在空間のデータを画像データに復元し、保存します。

ローカル環境での実践

この環境を使って、先程公式デモで試した冬期キャンペーンバナーを生成してみましょう。

CLIPTextEncodeノードに、同じプロンプトを入力します。解像度は1024x1024（widthとheightノードで設定）とします。

A promotional banner for a winter campaign. A cheerful Japanese woman in a warm coat is smiling in a snowy city street. Bokeh background with illumination. Text on the image: "冬の集客応援キャンペーン". High quality, commercial photography.

実行結果

NVIDIA製の高性能GPU（RTX 4090など）であれば1分未満で完了します。

M4 MacBook (32GBメモリ) の環境で、ステップ数20（デフォルト設定）で実行してみましたが、66GBのメモリを必要とし、Swapが大量に発生した結果PCがシャットダウンしてしまいました。

開発元やNVIDIAの公式情報によると、Flux 2.0のメモリ要件は以下のようになっています。

  • デフォルト（FP16/BF16）: 約90GBのVRAMが必要。
  • 省メモリモード（lowVRAM）: 約64GBのVRAMが必要。

FP8量子化は、メモリ使用量を約40%削減します。これを省メモリモード（64GB）に適用して計算すると、64GB × (1 - 0.40) = **約38.4GB**となります。

正直に白状すると、私はFP16からFP8量子化することで、メモリ使用率が50%近く削減できるものだと思い込んでいました。しかし、実際にはEmbedding層（入力）とLM Head（出力）等の量子化されないレイヤーの存在が大きく、他にも計算中間値用メモリの消費もあり、削減率は50%に大きく届かないようです。

しかし、モデルの実行に約38.4GBが必要だとしても、なぜ66GBもの使用量になってしまったのでしょうか。どうやら、ComfyUIがモデルをロードする際の挙動に起因しそうです。

  • ロード時のメモリ倍増現象: ComfyUIが巨大なモデルファイルをロードする際、一時的にファイルサイズの約2倍のメモリ領域を必要とすることが報告されている。
  • ピーク時の計算: Flux 2.0関連ファイル（モデル本体とText Encoder）の合計が33GB〜38GB程度である場合、ロードの瞬間には理論上66GB〜76GBのメモリが一時的に必要となる。観測された66GBという数値は、この現象によるもの。

公式APIノードの使用

ローカル環境で動作しなかったというオチだと少し寂しいのでもう少し調べてみると、Black Forest Labsから公式のAPIノードの提供がありました。

使い方は簡単で、ComfyUIにログインしてクレジットを追加した後に、Node Libraryメニューから [api node] > [image] > [BFL] > [Flux.2 [pro] Image]を選択するだけです。

公式APIノードはText EncoderやVAEを内包しており、実行させるためのワークフローは非常にシンプルです。以下のように「Load Image」と「Save Image」の間を繋ぐだけで動作させることができます。

ただ、この方法だとLoraやControlNetでのカスタマイズは当然できず、ComfyUIを使うメリットはあまりないので、これならばAPIを直接実行するのとあまり変わらないと思います。

今後の展望と代替案

今回の検証では、32GBユニファイドメモリ環境でのFLUX 2.0 [dev]のローカル動作は困難であることがわかりました。APIノードは手軽ですが、ComfyUIの最大の利点であるカスタマイズ性（LoRAやControlNetの利用など）を活かしてFLUX 2.0を使いたい場合、現状では主に2つのアプローチが考えられます。

1. さらなる量子化モデル（FP4）の登場を待つ

現在提供されているのはFP8（8ビット）量子化モデルですが、今後さらにメモリ効率の良いFP4（4ビット浮動小数点数）モデルが登場する可能性があります。実際、前バージョンのFLUX 1系でも、リリースから数ヶ月遅れてFP4モデルが公式から提供されました。FLUX 2.0でも同様にFP4版が登場すれば、32GB環境でも動作が期待できます。

2. Cloud GPUを利用する

今すぐにFLUX 2.0をカスタマイズ環境で使いたい場合、最も現実的で推奨される解決策はCloud GPUサービスの利用です。RunPodのようなサービスでは、高性能なGPU（例: A100やRTX 4090）を時間単位でレンタルできます。

Cloud GPU上にComfyUIを構築すれば、VRAM不足を心配することなく、API経由では不可能な複雑なワークフロー構築や自由なカスタマイズが可能になります。コストはかかりますが、高性能GPUを使っても個人利用の範囲であれば比較的安価に収まるケースも多いです。

ただし、ComfyUIとは別にCloud GPUサービスのアカウント作成や環境設定が必要になるため、本記事では詳細な説明は省略します。

まとめ

本記事では、次世代画像生成モデルFLUX 2.0 [dev] の特徴と、ComfyUIを使ったローカル環境での利用方法について解説しました。

  • FLUX 2.0はFlow MatchingとTransformerを採用し、特にテキスト描写とフォトリアリズムに優れている。
  • FLUX 2.0 [dev]はOpen Weightモデルだが、企業による業務利用には商用ライセンスが必要となる点には十分注意が必要。
  • FLUX 2.0 [dev]は32Bの巨大モデルであり、量子化とComfyUIの最適化を用いても、32GBユニファイドメモリMacBook環境では動作しなかった。
  • FLUX 2.0 [dev]を制限されたリソース下でカスタマイズするには、今後のFP4モデル登場を待つか、Cloud GPUサービスを利用するのが現実的な選択肢となる。
  • FLUX 2.0 [pro]はBlack Forest Labsが提供している公式APIノードを使用することができるが、カスタマイズ性はない。