DEV Community

bigkijimon
bigkijimon

Posted on • Originally published at zenn.dev

FLUX.2 dev（32B）はM1 Max 64GBで動くか、計算する前にディスクを見た話

#comfyui #flux #applesilicon

「FLUX.2 dev（32B・BF16）はM1 Max 64GBで動くのか」——ネットの2026年版ベンチマーク記事はM4 Max/M5 Maxの数字ばかりで、4年落ちのM1 Max 64GBの実測値はどこにも無い。だから自分の機体で計算し、ディスクの中身を見た。結論から言うと、計算するまでもなくアウトで、しかもこの機体にFLUX.2の実体ファイルは1つも存在しなかった。

1. 64GBという数字の中身

まず自分の機体の統合メモリを疑わずに実測する。

$ sysctl -n hw.memsize
68719476736
Enter fullscreen mode Exit fullscreen mode

68,719,476,736 バイト ÷ 1024^3 = ちょうど64.0GB。スペック表の「64GB」は誇張なしでそのまま統合メモリの実量である。

もう一つ、GPU側が使える上限を絞る iogpu.wired_limit_mb も見ておく。

$ sysctl -a | grep iogpu.wired_limit_mb
iogpu.wired_limit_mb: 0
Enter fullscreen mode Exit fullscreen mode

0はmacOSの既定値（未調整）を意味する。この機体は64GB機向けに推奨されるカスタム値（57344MB≒56GB）を一度も設定していない、素のままの状態だった。

先に結論を言っておくと、この値を推奨の57344MBまで引き上げてもFLUX.2 devのBF16は収まらない。GPU（Metal）に割り当てられる上限が56GBになるだけで、FLUX.2 BF16の必要量64GBはそれすら超える。チューニングで縮められる余地の話ではなく、モデルサイズそのものの話であることを先に押さえておく。

2. FLUX.2 dev（32B）をBF16で読むと何が起きるか

公開されているFLUX.2 devはパラメータ数32B。重みだけをBF16（2byte/param）で読み込むと必要メモリは単純計算できる。

32,000,000,000 params × 2 bytes = 64,000,000,000 bytes ≒ 64.0 GB
Enter fullscreen mode Exit fullscreen mode

重みだけで統合メモリ64GBの全量と同着になる。 OS、ComfyUI本体、テキストエンコーダ、VAE、推論時のアクティベーション——これら全部を置く場所がゼロになる。「動くか動かないか」の議論以前に、電卓の時点で詰んでいる。

3. 実際にディスクにあるのは何か

では自分のComfyUI環境に実際に置いてあるFLUX系の重みを見る。

$ find ~/Documents/ComfyUI/models -iname "*flux*"
flux1-schnell-Q6_K.gguf   9,834,955,808 bytes (9.83 GB)
flux1-dev-Q6_K.gguf       9,857,000,736 bytes (9.86 GB)
Enter fullscreen mode Exit fullscreen mode

どちらもFLUX.1（12Bクラス）のQ6_K量子化版だった。FLUX.2（32B）の実体ファイルは1個も無い。

ややこしいのは、ComfyUI自体はFLUX.2やZ-Imageのノードコードとワークフローテンプレートをすでにバンドルしていること（diffusers/pipelines/flux2/、comfy_extrasのノード、comfyui-frontend-package==1.45.19同梱のテンプレJSON群を確認）。つまり「ComfyUIがFLUX.2に対応している」ことと「このMacでFLUX.2が動く」ことはまったく別の話で、前者は満たされていても後者の主語（モデル本体）が存在しない。

必要メモリの対比

M1 Max 64GBに対するFLUX.1 Q6_K実測・FLUX.1 BF16計算値・FLUX.2 BF16計算値の必要メモリ比較棒グラフ。FLUX.2のBF16計算値64.0GBが実装メモリ上限64.0GBとちょうど重なる

4. 量子化はなぜ答えなのか

FLUX.1（12B）をフルBF16で読むと計算上は次の通り。

12,000,000,000 params × 2 bytes = 24,000,000,000 bytes ≒ 24.0 GB
Enter fullscreen mode Exit fullscreen mode

24GBなら64GB機に十分収まる数字だが、実際にディスクにあるのはQ6_K量子化版だった。Q6_K（およそ0.75byte/param換算）で計算すると次の通り。

12,000,000,000 params × 0.75 bytes = 9,000,000,000 bytes ≒ 9.0 GB
Enter fullscreen mode Exit fullscreen mode

計算値9.0GBと実測ファイルサイズ9.83〜9.86GB（VAE・追加テンソル分の上乗せを含む）はほぼ一致する。収まるはずのBF16をあえて使わず量子化版を選ぶのは、「動くか」ではなく「他の常駐プロセスと同居できる余白を残せるか」の判断だとわかる。ComfyUI本体、OS、他のアプリが同時に走っている前提なら、収まる/収まらないぎりぎりの数字ではなく余裕のある数字を選ぶのが実務的な選択になる。

ちなみに「Q6_K」のKはGGUF形式のK-quant系列を指す。単純に全パラメータを6bit均等に落とすのではなく、層やテンソルの重要度に応じてビット幅を配分するブロック単位の量子化方式で、同じ平均ビット幅の単純量子化より劣化が少ないとされる（llama.cpp由来の命名）。ここでは中身の量子化アルゴリズムの検証はしていない前提で、あくまでファイルサイズという一次情報だけを扱っている。

5. M1 Maxの実測値はネット上のどこにも無い

ネタ元にした2026年版のApple Silicon向けStable Diffusion/FLUXガイド記事は、実測ベンチマークをM4 Max・M5 Maxでしか取っていない。4年落ちのM1 Max 64GBの実測行は空白のままだった。新しいチップの記事が量産される一方で、まだ現役の旧世代機の数字は誰も取らない——今回の計算と実ファイル調査は、その空白を埋める一次情報でもある。

中古のM1 Max 64GB Studio/MacBook Proはローカル画像生成の入門機として今なお安く出回っている。「64GBあれば大抵のモデルは動くだろう」という感覚だけで大型モデルの重みをダウンロードし始める前に、パラメータ数×精度の掛け算だけは電卓で先にやっておいた方がいい。今回のケースでは、その電卓の答えを待つまでもなく、そもそも該当ファイルがディスク上に存在しないことが分かった。

まとめ：再現できる学び

  1. 「FLUX.2 dev 32BがM1 Max 64GBで動くか」は動かす前の電卓で否と言える。 BF16なら重み単体で統合メモリの全量を使い切り、他の何も置けない。

  2. モデル名の世代とサイズを混同しない。 「FLUX」と一括りにされがちだが、FLUX.1（12B）とFLUX.2（32B）はサイズが約2.7倍違う別物。ComfyUIの対応コードがあることと、実際にモデル本体が手元にあることも別の話。

  3. 量子化は「動く/動かない」の二択の手段ではなく、「同居できる余白を残す」ための選択。 収まる数字のBF16があっても、実務では量子化版が置かれていた。

  4. 自分の機体の数字はsysctl -n hw.memsizeとfind ... -inameで誰でも1分で取れる。ベンチマーク記事が新型番ばかりを追いかけるなら、手元の旧世代機の一次情報は自分で作るしかない。

※Z-Image-Turboとの比較も当初の計画にあったが、一次情報（外部の検証済み事実要約・ローカルのモデル実体）がどちらも揃わなかったため本記事のスコープからは除外した。

Top comments (0)