Qwen-Image 2.1 Turbo on a Mac: 4.20 GB at Q4, 32.5 GB at BF16

Qwen-Image 2.1 Turbo is the 8-step distilled checkpoint of Qwen-Image 2.1, published on 2026-10-09, and it is the first build in that family a Mac can realistically generate images with. Community ports followed within a day: mflux (MLX) bundles quantized for Apple Silicon, and a full GGUF ladder. The denoiser is not the hard part. The Qwen3-VL text encoder is 17.5 GB on its own, and every quant decision below follows from that one file.

TL;DR: There is still no official Apple Silicon path. Qwen's Turbo card installs a CUDA PyTorch build and the GitHub repo's hardware section lists AMD Radeon and FlagOS chips, nothing for Metal. Two community routes work. A GGUF denoiser at Q4_K_M (4.20 GB) plus a quantized Qwen3-VL encoder (5.15 GB) and the VAE (676 MB) is about 10 GB of files, which is the only combination of published files that fits a 16 GB Mac under the memory budget we apply. The mflux bundles are all-in-one: 10.6 GB at 4-bit, 14.5 GB at 6-bit, 18.5 GB at 8-bit. Turbo stays under the Qwen Research License: research and evaluation only. No Apple Silicon timing exists for it anywhere.

Does Qwen-Image 2.1 Turbo run on your Mac?

Yes, through three community routes, and none of them is supported by Qwen.

• The denoiser is only part of the download. The text encoder dominates the checkpoint: 17.5 GB of the 32.5 GB repository.
• The runtimes that work are ComfyUI with ComfyUI-GGUF, stable-diffusion.cpp, and Unsloth Desktop for the GGUF files. The mflux bundles need Osaurus 0.25.21 or newer.
• Stock mflux does not read Turbo's sampling grid yet, per Osaurus's own bundle notes, and a runtime that falls back to the base model's shifted schedule produces degraded images.
• The license is research only for the checkpoint and for both mflux bundles, before any performance question matters.

Demand is not the issue. The Turbo repository reports 4,702 downloads and 537 likes since 2026-10-09, the unsloth GGUF repository 50,453 downloads, and an abliterated Qwen3-VL encoder built for this pipeline 100,530 downloads.

What Turbo changes versus Qwen-Image 2.1

The important framing is that this is a tuning of the existing family, not a new architecture. The repository carries base_model: Qwen/Qwen-Image-2.1 and loads through the same QwenImage21Pipeline in Diffusers.

Three details matter more than the step count. First, setting num_inference_steps on its own does not override Turbo's saved schedule, and an explicit sigmas argument is the only way to try something else. Second, prefix KV caching reuses the text and reference-image context across those 8 steps, which is why the step reduction is not the whole story. Third, editing is in the same checkpoint as generation: the card's edit example runs at 2048x2048 with a reference image, and Osaurus ships up to 10 ordered reference images in one bundle.

The text encoder decides whether it fits

Here is the Turbo repository exactly as the file tree prints it. Every figure is a decimal gigabyte or megabyte as the repository page displays it, read 2026-10-12.

Those four weight files total 32,440,133,648 bytes. The whole repository, tokenizer and example renders included, is 32.5 GB as the tree page prints it. The two transformer shards account for 14.23 GB, the same size as the F16 GGUF in unsloth's ladder: at F16 the denoiser is not compressed at all, it is the bf16 transformer re-serialized in another container.

The memory lesson is in the first row. A GGUF is the denoiser only, as unsloth puts it on its own card, so it needs the VAE and an encoder alongside it. Shrinking the transformer to 4.20 GB does not shrink the 17.5 GB encoder. That is why a 16 GB Mac cannot run the pipeline as published, and why every small-Mac recipe is really a choice about the encoder:

Which GGUF quant should you download?

unsloth published its GGUF ladder on 2026-10-10 at 05:33 UTC, using its Dynamic 2.0 per-tensor layout with an importance matrix collected on Turbo's own 8-step schedule. The quality column is unsloth's LPIPS against the bf16 Turbo transformer, same encoder, same VAE, same prompts and seeds, at 1024x1024, 8 steps, CFG 1, rendered through its own diffusers route. Lower is better, and two bf16 runs of the same seeds score 0.000.

The publisher's recommendation is Q4_K_M for most hardware, and the curve explains the pick. Q2_K scores 0.374, which is a visibly different picture, Q4_K_M lands at 0.153 for 4.20 GB, and Q8_0 reaches 0.036 for 7.64 GB, so the returns flatten quickly once you are past 4 bits. Below 4 bits the drift is visible at 8 steps, which is why unsloth steers anyone who has to go smaller toward Q3_K_XL rather than Q2_K. Quantization is the obvious lever on a Mac, but it is the second lever: the encoder table above moves the total further than any choice in this one.

AtomicChat published its own denoiser ladder a day earlier, on 2026-10-09 at 14:55 UTC, with a different per-tensor layout, and the two ladders are not interchangeable file for file. Pick one publisher's ladder and stay in it.

What the mflux (MLX) bundles quantize

OsaurusAI published three MLX conversions for Apple Silicon on 2026-10-09, and this is the route where the encoder question answers itself. In all three, the transformer and the text and vision encoder are quantized to MLX affine bits with group size 64, while the modulation, timestep embedding and output norm stay in bf16 and the VAE is re-saved in fp32, unquantized.

Osaurus labels the same three bundles 17 GB, 14 GB and 9.9 GB in its own card, and the gap is the unit: those labels are binary gigabytes, while the tree pages and every size in this article are decimal. So the 8-bit build is 18.5 GB of files, about 17 GiB. The card marks the 8-bit build as closest to the original and the 4-bit one as the smallest, with more composition drift between seeds.

Two runtime notes travel with these files. They need Osaurus 0.25.21 or newer, because older versions treat the bundle as Qwen-Image-2.1 and sample it on that model's 40-step schedule, which degrades the images. And stock mflux does not read the fixed 8-node sigma grid yet, which is the same trap in a different tool. If you run mflux yourself rather than through Osaurus, check which grid your build applies before you judge the output.

Which Mac for which build

Everything in the fit column is our arithmetic on the published file sizes, using the same usable-memory budget our recommendation engine applies elsewhere: roughly 70 percent of unified memory at 16 GB and 24 GB, rising toward 85 percent on the largest machines. No runtime peak and no time per image has been published for any of these builds on Apple Silicon, so a fit is not a promise about speed. For example, the two routes with the same denoiser quant land several gigabytes apart, because the mflux bundle carries a quantized encoder inside it while the GGUF route asks you to pick an encoder file such as UD-Q4_K_XL or the 8.71 GB Q8_0 rung.

If you are shopping for a machine around this model, the 16 GB machines are covered in our 16 GB Mac model guide, and the comfortable end of the range is the M5 Max Mac Studio 64 GB pick.

What nobody has measured on Apple Silicon

Qwen publishes no Apple Silicon figure, and neither does unsloth, Osaurus or AtomicChat. Every image measurement on those cards ran on CUDA: AtomicChat's 45-prompt encoder study rendered through stable-diffusion.cpp on an A100 80 GB. So this article carries no time per image, and any number you see quoted for a Mac right now is somebody's arithmetic rather than a run.

What is measurable is the shape of the change. Turbo cuts 40 steps to 8, a fivefold reduction in denoising passes at the same resolution, and it reuses the text and reference context through prefix KV caching. On a Mac that matters more than on a GPU, because every denoising pass is a full forward through the same weights and the bytes it reads come from unified memory rather than a discrete card's VRAM. Quantizing the denoiser from 14.23 GB to 4.20 GB attacks the same problem from the other side. Neither statement is a speed figure, and we do not print one for this model.

The license is the limit, not the memory

The Turbo checkpoint is licensed under the Qwen Research License Agreement, same as Qwen-Image 2.1 itself. Our base model page worked through the text in September and the terms have not moved.

• Non-commercial means research or evaluation, and that is the whole grant of rights.
• Commercial use needs a separate license, requested at model-business@notice.qwencloud.com. There is no self-serve path, and image editing counts as use.
• Both mflux bundles carry it forward. Osaurus tags them non-commercial and research-only, repeats the same address, and adds the detail that Qwen's statement about users owning generated images does not grant commercial use of the model.
• The abliterated encoder is different. Its repository is Apache-2.0 because its base is Qwen3-VL-8B-Instruct, so that file can be redistributed freely, but the denoiser it pairs with is still research only.

The practical consequence is unchanged from the base model: generating client assets, product images or anything you sell with these weights is not covered by the download. If that is your use case, the hardware question is moot.

FAQ

Does Qwen-Image 2.1 Turbo run on a Mac?

Yes, but only through community ports and only with a quantized text encoder on machines below 32 GB. OsaurusAI's mflux bundles do text-to-image and reference editing in one package from 10.6 GB, and the GGUF route pairs a 4.20 GB denoiser with an encoder from 5.15 GB. Qwen itself documents a CUDA build and a .to("cuda") call, and the GitHub repository's hardware section covers AMD Radeon and eight FlagOS chip platforms with no Apple Silicon entry and no MLX mention.

Do the mflux builds quantize the text encoder as well as the transformer?

Yes, and that is the reason they exist. Both the 8-bit and the 4-bit bundles carry the transformer and the text and vision encoder in the same quantized precision, group size 64, and leave the VAE in fp32. In the 4-bit bundle the encoder accounts for 5.13 GB of the 10.6 GB repository, so the encoder is not a fixed 17.5 GB tax on this route. What you pay instead is precision, and Osaurus prints its own warning about it: the 4-bit build is the smallest of the three and shows more composition drift between seeds. That is what makes a 16 GB or 24 GB Mac a candidate at all here, where the same machine has no path to a bf16 encoder.

What should I download for a 16 GB Mac?

The smallest sane GGUF trio: qwen-image-2.1-turbo-Q4_K_M.gguf at 4.20 GB, Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf at 5.15 GB, and the 676 MB VAE. That is about 10 GB of files against a usable budget near 11 GB on a 16 GB machine, so it is tight before activations and the runtime, and no published run confirms it works. If you want headroom instead, drop the denoiser to Q3_K_XL at 3.61 GB and accept the LPIPS drift, or drop the encoder rung. The one thing you cannot do at 16 GB is keep a bf16 encoder: 17.5 GB of encoder does not fit, whatever the denoiser weighs.

Can I use Qwen-Image 2.1 Turbo commercially?

Not under the download terms. The Qwen Research License Agreement limits use to research and evaluation, and commercial use requires a separate license from Qwen at model-business@notice.qwencloud.com. The mflux bundles repeat that limit explicitly and are tagged non-commercial and research-only. The Apache-2.0 abliterated encoder is the one file in this ecosystem you can redistribute freely, and it does not change the license of the denoiser it feeds.

Is there an Apple Silicon speed figure for Turbo anywhere?

No. Not from Qwen, not from unsloth, not from Osaurus, and not from AtomicChat, whose image measurements ran on an A100 80 GB. What you can reason about is that Turbo does 8 denoising passes where the base checkpoint does 40, and that a 4-bit denoiser reads 4.20 GB per pass instead of 14.23 GB. Size the machine on the memory table above and treat every speed claim you see for a Mac as an estimate until somebody publishes a run.

Sources

• Qwen/Qwen-Image-2.1-Turbo model card: 8-step schedule and CFG 1 defaults, text-to-image and editing examples at 1680x2512 and 2048x2048, aspect-ratio presets, prefix KV caching, license, created 2026-10-09.
• Turbo repository file tree and the file pages for the text encoder, the transformer shards and the VAE: 32.5 GB total, 17.5 GB encoder, 9.97 GB and 4.26 GB shards, 676 MB VAE, read 2026-10-12.
• unsloth/Qwen-Image-2.1-Turbo-GGUF: the quant ladder with exact sizes and LPIPS columns, the 8-step CFG 1 requirement, the stable-diffusion.cpp command, and the note that a GGUF is the denoiser only.
• OsaurusAI/Qwen-Image-2.1-Turbo-mflux-8bit and the 4-bit build: what is quantized, the fp32 VAE, the Osaurus 0.25.21 requirement, the sigma-grid warning, and the non-commercial research-only tag.
• OsaurusAI/Qwen-Image-2.1-Turbo-mflux-6bit and the 8-bit bundle tree: repository totals and per-component sizes for all three bundles.
• Comfy-Org/Qwen-Image-2.1: the bf16, int8 and w4a8 text encoders used by the official ComfyUI template, the int8 denoiser, and the VAE.
• unsloth/Qwen3-VL-8B-Instruct-GGUF: the encoder rungs, UD-Q4_K_XL at 5.15 GB and Q8_0 at 8.71 GB.
• AtomicChat/Qwen-Image-2.1-Turbo-Uncensored-GGUF and its Turbo denoiser ladder: the abliterated encoder sizes and licence, the AD denoiser files, and the A100 measurement conditions.
• QwenLM/Qwen-Image-2.1: the Turbo release note dated 2026-10-09, the CUDA quickstart, and the hardware support section limited to AMD Radeon and FlagOS.
• Download and like counts come from the Hugging Face model API for each repository, read 2026-10-12. Memory fit is ModelFit arithmetic on the published file sizes, not a benchmark: ModelFit runs no benchmarks.

Every decimal figure here is a size or a score printed on a page linked above, and the fit column is our arithmetic. Found an error? Contact us: our editorial standards are on the about page.