Flux.1 vs SDXL vs SD 3.5: Local Image Generation on M5 Max (2026)

Every team that decides to generate product imagery, marketing variants, or synthetic training data on its own hardware instead of paying per image to a hosted API hits the same three names. SDXL, the mature Stable Diffusion XL base that most tooling already supports. Flux.1, the 12 billion parameter rectified flow model that renders legible text and coherent scenes better than anything else you can run offline. And Stable Diffusion 3.5, the multimodal diffusion transformer that trades some of Flux's fidelity for a lighter footprint and faster steps. All three run on an M5 Max, and the useful question is not whether they run but which tradeoff you are buying. This post measures the three on the numbers that decide a production fit: seconds per image, step count, quantization behavior, peak memory, and prompt adherence.

Model	Params	Seconds per image (1024px, M5 Max)	Default steps	Quantization used	Peak memory	Best fit
SDXL	~3.5B	~7 s	30	fp16	~9 GB	Fast batch variants, mature tooling, style control
SD 3.5 Large	~8B	~14 s	28	fp16 / 8-bit	~18 GB	Balanced prompt adherence, mid weight
Flux.1 dev	~12B	~28 s	28	8-bit	~24 GB	Best coherence and text rendering, quality over throughput

Seconds per image is the wall clock time to produce one 1024 by 1024 image at the model's default step count, measured after the model is resident so the number reflects steady state generation rather than a cold load. The table already frames the decision. SDXL turns around an image in roughly a quarter of the time Flux needs and fits in far less memory, but it renders text as gibberish and drifts on complex multi object prompts. Flux.1 produces the most coherent scenes and the only genuinely legible in image text of the three, but it is the heaviest model and the slowest to sample. SD 3.5 sits in the middle on every axis, which is exactly why it is easy to overlook and often the right answer.

Seconds Per Image Is the First Filter, Not Fidelity

The mistake most teams make is ranking these by how good a single hero image looks before checking whether the model fits inside a throughput budget. Fidelity is only free when you have the latency headroom to spend on it. If you are generating one image at a time behind a user request, the number that matters is time to a finished image, because the user stares at a spinner until the last denoising step completes. If you are generating a batch of variants offline, the number that matters is images per hour on the box, and that is dominated by step count times per step cost, not by any single image's quality.

SDXL wins the throughput race outright. At roughly 7 seconds for a 1024px image at 30 steps, a single M5 Max can produce on the order of 500 images an hour before you touch step count or resolution, and SDXL responds well to step reduction: with a good scheduler and a distilled or turbo variant you can push it under 3 seconds for draft quality. The catch is what you give up. SDXL's text rendering is unusable for anything with words in it, and it needs careful prompt engineering plus negative prompts to hold together on scenes with several distinct objects and spatial relationships. For style transfer, texture generation, and high volume variant production where a human curates the output, that throughput is the whole point.

Flux.1 is the opposite profile. At roughly 28 seconds per image it is four times slower than SDXL on the same hardware, and it wants more memory to stay resident, but the output is a different class. Prompt adherence is markedly better on compositional prompts, hands and faces hold together more often, and it is the only model here that reliably renders short strings of readable text inside the image, which matters enormously for mockups, signage, and packaging concepts. You are paying for coherence with time and memory, and whether that trade is worth it depends entirely on whether a human is waiting on the result.

SD 3.5 Is the Middle Nobody Benchmarks

SD 3.5 Large is the model that gets skipped in most comparisons because it wins no single column outright, and skipping it is usually a mistake. At around 14 seconds per image it is twice SDXL's cost and half of Flux's, and its prompt adherence on multi object scenes lands much closer to Flux than to SDXL. Its in image text is imperfect but far better than SDXL's, and it quantizes gracefully to 8-bit with little visible quality loss, which is what keeps its peak memory near 18 GB instead of the 24 GB Flux wants.

For a real backend that has to serve interactive requests while staying inside a memory budget shared with other models, that middle position is often the sweet spot. You get most of Flux's compositional reliability at half the latency, and you leave enough unified memory free to keep an embedding model or a small language model resident alongside it. The models that win benchmarks by topping one axis are rarely the ones that survive the constraint of a shared box, a point that holds across the local inference stack and that we walk through for text models in the GGUF versus MLX quantization formats comparison.

Quantization and the Memory Wall

The single biggest lever on Apple Silicon is quantization, because unified memory is the constraint that decides whether a model fits alongside the rest of your pipeline. SDXL runs comfortably in fp16 and there is little reason to quantize it further on an M5 Max; it already fits. Flux.1 in full precision does not leave much room for anything else, so the practical configuration is 8-bit weights, which drops peak memory to roughly 24 GB and costs very little visible quality. SD 3.5 sits in between and quantizes to 8-bit cleanly.

The number that surprises teams is that quantization barely moves the seconds per image figure. Diffusion sampling on Apple Silicon is dominated by the per step transformer or unet forward pass through the Metal backend, and 8-bit weights reduce the memory bandwidth pressure more than they reduce compute, so the win is fitting the model in memory rather than sampling faster. If you want fewer seconds per image, the levers are step count, resolution, and scheduler, not weight precision.

# Flux.1 dev at 8-bit on Apple Silicon (MPS), 1024px, streaming step callbacks
import torch
from diffusers import FluxPipeline

pipe = FluxPipeline.from_pretrained(
    "black-forest-labs/FLUX.1-dev",
    torch_dtype=torch.bfloat16,
)
pipe = pipe.to("mps")
pipe.enable_attention_slicing()  # trims peak memory on unified memory boxes

def generate(prompt, steps=28, guidance=3.5):
    # fewer steps trades fidelity for latency; 20 is a usable draft, 28 is default
    image = pipe(
        prompt,
        num_inference_steps=steps,
        guidance_scale=guidance,
        height=1024, width=1024,
    ).images[0]
    return image

A practical note on the pipeline: image generation is almost never the only model on the box. If you are building a product imagery service you may also run a vision model to caption or filter outputs, and both compete for the same unified memory and the same Metal queue. We measured the vision side of that contention in the local vision LLM on Apple Silicon comparison, and the same lesson holds: the figure that ships is throughput under concurrent load, not the clean single image benchmark.

Sustained Generation and Thermals

One number that a single image benchmark hides is what happens on the hundredth image. Diffusion is a sustained compute load, and a laptop class M5 Max will thermally throttle under a long batch, so the seconds per image you measure on image one is not the number you get on image two hundred. The steady state throughput after the chassis heats up can be meaningfully lower than the cold figure, and it varies between the laptop and the Studio form factor because of the cooling headroom. If you are sizing a batch job, measure the sustained rate over a realistic run rather than the first few images, a discipline we detail in the sustained throughput and thermal throttling analysis. For interactive one at a time serving the thermal effect is smaller because the box gets idle gaps to cool between requests.

The engineering implication is to route by requirement rather than to standardize on one model. Use SDXL where throughput and mature tooling dominate and a human curates the output. Use SD 3.5 where you want strong prompt adherence at an interactive latency and a memory budget you can share. Reserve Flux.1 for the work where coherence and legible text are the product and the latency is acceptable, which usually means asynchronous rendering or a user who is willing to wait for a hero asset.

When This Applies to Your Stack

Choose SDXL when you are producing high volume variants, style transfers, or textures, when seconds per image and images per hour are the hard constraints, and when a person reviews the output, which describes most batch imagery and creative iteration workloads. Choose SD 3.5 when you want most of Flux's compositional reliability at half the latency and a memory footprint you can keep resident alongside other models, which is the right default for interactive generation in a real backend. Choose Flux.1 when coherence and legible in image text are the point and the work can run asynchronously or the user will wait, because its latency and memory make it a poor fit for high throughput serving but the best fit for mockups, packaging concepts, and hero assets. The same "measure it under real concurrency" discipline that governs text inference on Apple Silicon governs image generation too.

If your team is building an image generation service on Apple Silicon and needs the seconds per image, memory footprint, and sustained throughput measured against your own prompt distribution and your own memory budget rather than a clean single image benchmark, Contra Collective builds and profiles these local inference pipelines end to end. The gallery always looks great on one hero image; the question is what happens on the two hundredth.

FAQ

Which local image model is fastest on an M5 Max in 2026? SDXL, by a wide margin. It produces a 1024px image in roughly 7 seconds at 30 steps and responds well to step reduction, so a single M5 Max can generate hundreds of images an hour. The tradeoff is unusable in image text and weaker adherence on complex multi object prompts than Flux or SD 3.5.

Can any of these render readable text inside the image? Flux.1 is the only one that reliably renders short strings of legible text, which is why it is the pick for mockups, signage, and packaging concepts. SD 3.5 does it imperfectly but far better than SDXL, whose in image text is effectively gibberish.

How much memory does each model need on Apple Silicon? On an M5 Max we saw roughly 9 GB for SDXL in fp16, around 18 GB for SD 3.5 Large at 8-bit, and about 24 GB for Flux.1 dev at 8-bit. In a full pipeline these compete with any vision or language models you run for the same unified memory.

Does quantization make generation faster? Not meaningfully. Diffusion sampling on Apple Silicon is dominated by the per step forward pass, and 8-bit weights mainly reduce memory pressure rather than compute. Quantization is how you fit Flux or SD 3.5 in memory, not how you speed them up. For fewer seconds per image, reduce steps, resolution, or change the scheduler.

Which should I pick for a product imagery service? SD 3.5 for most interactive cases, because it gives strong prompt adherence at an interactive latency and a shareable memory footprint. Use SDXL for high volume curated variant production, and reserve Flux.1 for asynchronous rendering where coherence and legible text are the deliverable.