Qwen-Image 2.1 on Mac: No Official Apple Silicon Path

Qwen-Image 2.1 is the image model that Alibaba's Qwen team released on September 20, 2026. It is a 7B single-stream DiT that generates and edits images with one set of weights, and it ships with native 2K output and native transparent PNG. The Mac question, however, has a short answer: there is no official Apple Silicon path. Qwen documents day-0 support for CUDA stacks, AMD Radeon, and eight FlagOS chip platforms, and nothing at all for MLX or Metal. Consequently, everything running on a Mac today is a community port, and most of those are less than a week old.

TL;DR: On unified memory, 64GB is the realistic tier today (about 78 seconds per 1024x1024 image on an M5 Max through mflux). 32GB runs it slowly. 16GB and 24GB have no published working run. The license is non-commercial: no separate commercial agreement, no client work.

What Qwen-Image 2.1 actually is

A diffusion transformer (DiT) is the architecture family this release belongs to, and the specs below come from the model card and the GitHub repo.

• The 7B-parameter generator is a 32-layer single-stream DiT with block-causal attention.
• The Qwen3-VL 8B text encoder is a separate model that encodes both the text instruction and any condition images into one representation.
• The 64-channel RGBA VAE is what produces native transparency, through 16x spatial compression.
• Up to 10 reference images can be supplied per request, plus local edits via circles, painted annotations, or a separate mask.
• Native 2K output is the pipeline default at 2048x2048, and the recommended aspect ratios run as wide as 2752x1536.
• 40 inference steps are the default, using Flow Matching with Euler discrete scheduling.

Two smaller pieces matter for anyone planning a local install. In addition, Qwen ships two optional prompt rewriters, both fine-tuned Qwen3.5-VL 9B checkpoints (PE-T2I and PE-I2I). The full bf16 checkpoint, meanwhile, is 33.12GB on disk: 17.54GB of text encoder, 14.23GB of transformer, 1.35GB of VAE. That encoder is not a rounding error. In fact, it is bigger than the model everyone calls "7B".

Day-0 integrations were wide: Diffusers (QwenImage21Pipeline, PR 14804), ComfyUI with official Comfy-Org weights, vLLM-Omni, SGLang, and LightX2V. Notably, the model card has 42,469 downloads and 2,258 likes as of this check.

The Mac answer, straight

Qwen's repo has a Hardware Support section. It covers AMD Radeon via ROCm and a set of heterogeneous chips through FlagOS, where T-Head zhenwu and Arm builds are linked. There is, however, no Apple Silicon entry, no MLX mention, and no Metal mention.

We found no published memory table of any kind. The README's only memory guidance is a single line of code, pipe.enable_model_cpu_offload(), with the note that it is for GPUs with limited memory. Therefore, there is no minimum VRAM figure, no tier list, nothing. If you want to know whether it fits your Mac, nobody at Qwen has answered that question yet. So what is left for a Mac user?

This is the article where our usual local-AI advice does not transfer. In our experience, image models have no Ollama or LM Studio path, so the workflow in our LM Studio on Mac guide is not the one you need here.

Every official measurement is CUDA

The SGLang cookbook is the source behind most of the numbers circulating this week, and it is the only place with published, dated figures. Its rows were all measured on September 20, 2026, at 1024x1024, 40 steps, CFG 1, one RGBA PNG per request. Specifically, the times are median latency after warmup, including PNG serialization.

Read the last two rows together, because they say more than the headline numbers. The RTX 4090 hits 22.7 GiB peak only because SGLang offloads the text encoder layer by layer. That is why it is nearly four times slower than the RTX PRO 6000 despite a similar memory footprint. The DGX Spark has unified memory like a Mac, and the cookbook does not publish a peak figure for it at all. Even a 128GB unified machine built by NVIDIA takes 35 seconds for one 1024x1024 image. In other words, the unified-memory tier that comes closest to a Mac is the slowest row in the table. Every row uses the same weights, the same step count and the same resolution, so what you see across those five rows is hardware and software, not a different workload.

Therefore, none of this ran on Apple Silicon, and no Apple Silicon row appears anywhere in the table.

What actually runs on a Mac, as of September 25

Four community efforts exist. None is official, none carries Qwen's blessing, and one of them, notably, has never been run by anyone but its uploader.

mflux is the MLX port most Mac users will try first. The project merged Qwen-Image 2.1 support on September 21 (PR 736), and that gives you a mflux-generate-qwen-2.1 command for text-to-image and image-to-image with -q 8 or -q 4 quantization. Meanwhile, the author's own numbers on an M5 Max at 1024x1024, 40 steps, bf16: about 1.5 seconds per step, about 78 seconds end to end, peak around 46GB. With -q 8 that peak drops to about 30.7GB, because Qwen leaves the text encoder in bf16 on purpose to protect conditioning quality. Two things are missing, however. The edit and instruction variant is not ported, and reference editing, RGBA output, and prefix KV caching were still sitting in an open pull request (741) at the time of writing. In other words, you get the base generation path here, not the editing half of the release.

ComfyUI with GGUF weights. ComfyUI's day-0 support is real and official, but the official ComfyUI tutorial for this model mentions no macOS guidance, no Apple Silicon notes, and no memory minimum. It defaults to int8 weights for the diffusion model and the text encoder. On the Mac side, by contrast, a community GGUF conversion (Abiray, 41,605 downloads) plus the ComfyUI-GGUF nodes is the practical route. One community guide reports about 13 seconds per step at 1024x1024 on an M4 Pro with 48GB. At 25 steps, that is a little over five minutes per image. For example, a 25-step run at that pace is not a quick preview; it is a coffee break.

Core ML is Apple's on-device model runtime, and a community conversion exists for it, built for 1024x1024 text-to-image on Apple silicon. Its author measured an M5 MacBook Pro with 32GB at 5.43 to 5.95 seconds per denoising step. Therefore, a full 40-step image takes 221 to 250 seconds, with the transformer package at 14.06GB and a 14.74GB total download. In particular, the page states plainly that minimum memory below 32GB has not been established.

The 4-bit MLX upload. We found zero downloads on mlx-community/Qwen-Image-2.1-MLX-4bit, which was created on September 20, and no benchmarks, no example outputs, and a model card that only restates the architecture. Notably, its 10.50GB of weights quantize the text encoder down to 5.13GB, which no other port does. A second upload from the same day, toxicdog/Qwen-Image-2.1-MLX, also had zero downloads and states that it needs a custom C++/MLX runtime, not ComfyUI or Diffusers. Treat both as untested.

One figure we could not use: community posts quote a 15.6GB memory footprint for a CPU-offload setup. We could not trace it to a published measurement with stated conditions, and as a result it is left out of the table below.

Which Mac can run it

The table below separates what has been measured from what is arithmetic. Measured rows come from the community runs above. In addition, the 16GB and 24GB rows are our weight math, not a benchmark, because nobody has published a working run at those sizes. We ran that arithmetic with the same memory-fit model the ModelFit recommendation engine uses, so those two rows are labeled as arithmetic rather than as speed.

Two caveats on that table. Every measured number is at 1024x1024, but this model's native default is 2048x2048, which is four times the pixels. Nobody has published Apple Silicon timings at the native resolution. Therefore, do not assume the 1024x1024 figures scale cleanly, and do not size a purchase on them. The second caveat concerns memory rather than time. The gap between mflux's 46GB peak and the RTX 4090's 22.7 GiB is not a Mac tax. It is the difference between an MLX port that keeps everything resident and a CUDA stack that offloads the encoder every step. On top of that, no vendor publishes a peak-memory figure for Apple Silicon here, so every Mac number in this article comes from a community run.

If you are sizing hardware for local AI generally rather than for this model, the capacity-versus-bandwidth trade is covered in our local AI hardware bottleneck guide and the VRAM tier cheat sheet. For M5 specifics, the M5 Pro and M5 Max local LLM guide has the bandwidth context that makes the M5 Max result above possible.

The license matters more than the benchmarks

The Qwen Research License Agreement is the license Qwen-Image 2.1 ships under, dated September 20, 2026. Can you use it for client work? The agreement answers that question before any benchmark does. That is a change from the Apache-2.0 terms of earlier Qwen-Image releases, and for most Mac users it is the deciding factor, not the speed.

What the agreement says:

• "Non-Commercial" means research or evaluation purposes only, and the grant of rights covers non-commercial use exclusively.
• Commercial use requires a separate license, requested from Qwen at model-business@notice.qwencloud.com. There is no self-serve path.
• Redistribution requires passing the agreement along and marking modified files.
• Attribution must be retained in a redistributed work, naming Hangzhou Tongyi Laboratory Technology Co., Ltd.
• If you use the model or its outputs to train or improve another model, the documentation must display "Built with Qwen" or "Improved using Qwen".
• You may not use "Qwen" as the primary name of a derivative work or product. Descriptive use such as "fine-tuned from Qwen Image" is allowed.

In practice, therefore, generating client assets, product images, or anything you sell with these weights is not covered by the open download. That is worth knowing before you spend an evening on a local install.

FAQ

Does Qwen-Image 2.1 run on a Mac?

Yes, but only through community ports, and only at 32GB of unified memory or more. mflux (MLX) covers text-to-image and image-to-image, and a community Core ML conversion covers 1024x1024 generation. As of September 25, 2026, Qwen has published no Apple Silicon support and no Apple Silicon benchmarks. The practical consequences are worth spelling out before you download anything. On a 32GB machine you are looking at minutes per image, and one of the ports described below has been tested by exactly one person. On a 64GB machine the MLX route is usable for real work at 1024x1024, though not at the model's native 2K default. On 16GB and 24GB machines, nothing published today supports the claim that it runs. If your use case is commercial, the hardware question is secondary to the license, which we cover below.

Is there official MLX support for Qwen-Image 2.1?

No. Qwen's repo lists day-0 support for Diffusers, ComfyUI, vLLM-Omni, SGLang, and LightX2V, plus AMD Radeon via ROCm and eight FlagOS chip platforms. MLX is not mentioned anywhere. The MLX conversions on Hugging Face are community uploads, and the mlx-community 4-bit one had zero downloads at check time.

How much memory does Qwen-Image 2.1 need?

Qwen publishes no memory table. The closest published reference is CUDA: 22.7 GiB peak on an RTX 4090 with the text encoder offloaded, and 38.4 GiB with the pipeline resident. On a Mac, the one third-party measurement at bf16 reports a peak near 46GB on an M5 Max, and about 30.7GB with -q 8. Plan for 64GB if you want comfortable headroom. However, the weights are not the whole story. The Qwen3-VL encoder is 17.54GB of the 33.12GB bf16 checkpoint, so it decides whether a quantized build fits at all. A build that quantizes the transformer to 8 bits and leaves the encoder in bf16 lands near 30.7GB, which is exactly what the mflux -q 8 row shows. Below 32GB, nobody has published a working run at any precision.

Does ComfyUI support Qwen-Image 2.1 on macOS?

ComfyUI added official day-0 support for the model, and the official tutorial defaults to int8 weights. That tutorial includes no macOS instructions and no memory minimum. In practice, Mac users pair ComfyUI with the ComfyUI-GGUF nodes and a community GGUF conversion, and the reported speed is roughly five minutes per 1024x1024 image on an M4 Pro with 48GB. The reason is granularity rather than raw speed: GGUF lets you choose a quantization that fits your machine, which the int8 default does not. If you already run ComfyUI for other image models, therefore, this is the path with the least new tooling to learn, even though it is not the fastest option measured here.

Can I use Qwen-Image 2.1 commercially?

Not under the download terms. The Qwen Research License Agreement limits use to research and evaluation, defines non-commercial as exactly that, and requires a separately negotiated license for anything commercial. The request address given in the agreement is model-business@notice.qwencloud.com.

Bottom line

Qwen-Image 2.1 is a genuinely interesting release: 7B of generator, one model for generation and editing, real transparency, and 2K output without an upscaler. It also arrives with a research-only license, no official memory guidance, and no Apple Silicon path at all.

If you have 64GB of unified memory and a weekend, mflux works today for text-to-image and image-to-image, and the numbers are usable. If you have 32GB, expect minutes per image and a community conversion that has been tested by exactly one person. If you have 16GB or 24GB, nothing published today supports the claim that it runs, and the honest answer is to wait for the namespace to settle.

For anything commercial, therefore, the Mac question is moot until you have a license in hand.

Every number here comes from a source named in the text, and the 16GB and 24GB rows are our arithmetic, labeled as such. Found an error? Contact us: our editorial standards are on the about page.