Can FLUX.2 dev (32B) run on an M1 Max 64GB? I looked at the disk before doing the math

Originally published on Zenn (Japanese). Cross-posted here.

"Can FLUX.2 dev (32B, BF16) run on an M1 Max 64GB?" — the 2026 benchmark articles online are all M4 Max / M5 Max numbers; nowhere could I find real measurements for a four-year-old M1 Max 64GB. So I did the math on my own machine and looked at what is actually on the disk. The short version: it is a no before you even finish the math — and not a single FLUX.2 weight file exists on this machine.

1. What "64GB" actually is

First, measure the unified memory on my own machine instead of trusting the spec sheet.

$ sysctl -n hw.memsize
68719476736

68,719,476,736 bytes ÷ 1024^3 = exactly 64.0 GB. The "64GB" on the spec sheet is, with no exaggeration, the actual amount of unified memory.

One more thing worth checking: iogpu.wired_limit_mb, which caps how much the GPU side can use.

$ sysctl -a | grep iogpu.wired_limit_mb
iogpu.wired_limit_mb: 0

0 means the macOS default (untuned). This machine had never once been set to the custom value recommended for 64GB machines (57344MB ≈ 56GB) — it was in its bare, out-of-the-box state.

Let me give the conclusion up front: even if you raise this value to the recommended 57344MB, FLUX.2 dev in BF16 will not fit. All it does is set the GPU (Metal) ceiling to 56GB, and FLUX.2 BF16's requirement of 64GB exceeds even that. This is not something tuning can shrink — it is about the model size itself.

2. What happens when you load FLUX.2 dev (32B) in BF16

The publicly released FLUX.2 dev has 32B parameters. Loading just the weights in BF16 (2 bytes/param), the required memory is a simple calculation.

32,000,000,000 params × 2 bytes = 64,000,000,000 bytes ≒ 64.0 GB

The weights alone tie with the entire 64GB of unified memory. The OS, ComfyUI itself, the text encoder, the VAE, the activations during inference — the space to put all of these becomes zero. Before any "does it run or not" debate, it is already game over at the calculator stage.

3. What is actually on the disk

So let me look at the FLUX-family weights actually present in my ComfyUI environment.

$ 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)

Both were Q6_K quantized versions of FLUX.1 (the 12B class). There is not a single FLUX.2 (32B) weight file.

What makes this confusing is that ComfyUI itself already bundles the node code and workflow templates for FLUX.2 and Z-Image (I confirmed diffusers/pipelines/flux2/, the comfy_extras nodes, and the template JSONs shipped with comfyui-frontend-package==1.45.19). In other words, "ComfyUI supports FLUX.2" and "FLUX.2 runs on this Mac" are entirely different statements; the former can be true while the subject of the latter — the model itself — does not exist.

Memory requirement comparison

4. Why quantization is the answer

Loading FLUX.1 (12B) in full BF16 calculates as follows.

12,000,000,000 params × 2 bytes = 24,000,000,000 bytes ≒ 24.0 GB

24GB is a number that fits comfortably on a 64GB machine, but what was actually on the disk was the Q6_K quantized version. Computing with Q6_K (roughly 0.75 bytes/param) gives:

12,000,000,000 params × 0.75 bytes = 9,000,000,000 bytes ≒ 9.0 GB

The calculated 9.0GB nearly matches the measured file sizes of 9.83–9.86GB (which include the VAE and extra tensors on top). Deliberately choosing the quantized version instead of the BF16 that would fit is a judgment about "can I leave headroom to coexist with other resident processes," not about "does it run." Assuming ComfyUI itself, the OS, and other apps are running at the same time, the practical choice is a number with margin, not a number sitting right on the fit / no-fit edge.

Incidentally, the K in "Q6_K" refers to the K-quant series of the GGUF format. Rather than simply dropping all parameters to a uniform 6 bits, it is a block-wise quantization scheme that allocates bit width according to the importance of layers and tensors, and is said to degrade less than naive quantization at the same average bit width (the naming comes from llama.cpp). Here I am working only from the primary fact of file size, on the premise that I have not verified the internal quantization algorithm.

5. The M1 Max numbers are nowhere online

The 2026 Apple Silicon Stable Diffusion / FLUX guide article I used as a source only took real benchmarks on the M4 Max and M5 Max. The row for the four-year-old M1 Max 64GB was left blank. While articles about the newest chips are mass-produced, no one takes the numbers for the still-current previous generation — so this calculation and file survey is also primary information filling that gap.

Used M1 Max 64GB Studios / MacBook Pros still circulate cheaply as entry machines for local image generation. Before you start downloading large model weights on the feeling that "with 64GB most models will probably run," it is worth doing just the params × precision multiplication on a calculator first. In this case, we did not even have to wait for the calculator's answer — it turned out the file in question simply was not on the disk at all.

Summary: reproducible takeaways

1. "Can FLUX.2 dev 32B run on an M1 Max 64GB" can be answered "no" with a calculator before you run anything. In BF16 the weights alone use up the entire unified memory, leaving room for nothing else.

2. Do not confuse a model name's generation and size. They tend to get lumped together as "FLUX," but FLUX.1 (12B) and FLUX.2 (32B) are different things, about 2.7× apart in size. Having ComfyUI's support code and actually having the model itself at hand are also different matters.

3. Quantization is not a means to a binary "runs / does not run" — it is a choice to leave headroom to coexist. Even when a BF16 that fits exists, in practice the quantized version was what was placed there.

4. Your own machine's numbers can be taken by anyone in a minute with sysctl -n hw.memsize and find ... -iname. If benchmark articles only chase the newest model numbers, you have to make the primary data for your older machine yourself.

Note: a comparison with Z-Image-Turbo was in the original plan, but since neither piece of primary information (an externally verified fact summary / a local model artifact) was available, it was excluded from this article's scope.