Qwen-Image-2.1-Turbo on a Desktop: BaoCut 3.5 and the First Local Timings

The repository for Qwen-Image-2.1-Turbo appeared on Hugging Face on 9 October 2026 with 707 likes, weights, a licence file, and a single line in the Qwen-Image-2.1 GitHub news list as its entire announcement. Five days later it is already running on people's desks. BaoCut 3.5, a Chinese desktop editing tool, integrated the checkpoint and started generating images on the local machine instead of through a server; X/@dotey reported on 13 October 2026 that a picture takes roughly three to five minutes at 1080p on their Mac Mini M2 and close to twenty minutes at 2K. Separately, an open-source macOS app called Siliconed posted to the model's own discussion board on 11 October 2026 with a measured 118 seconds at 1024² on an M1 Pro, and the same machine running Z-Image Turbo — the other 8-step open checkpoint people are choosing between — in 82 to 85 seconds. Qwen-Image-2.1, the base model both local ports are derived from, was released on 20 September 2026. The accelerated checkpoint is three weeks younger than its parent and has no independent evaluation of its own.

That is the shape of this story: a checkpoint that was never launched, only published, now arriving inside desktop software before the vendor has said much of anything about it in public. What follows separates what the repository actually states from what the first users are reporting, because the two are not the same kind of claim.

What the repository confirms, and what it does not

Everything below comes from the model card, the licence file, and the project changelog — primary sources, checkable by anyone.

• Dated, and dated where it counts. The Hugging Face API reports the repository as created at 2026-10-09T04:50:01Z and last modified 2026-10-12. The Qwen-Image-2.1 GitHub news list carries the matching entry: "2026.10.09: We released Qwen-Image-2.1-Turbo for image generation and editing in just 8 denoising steps." The same changelog records that the Pro and Turbo APIs went live on A​libaba Cloud Model Studio that same day. This is a release; it is a release without a launch.

• What it is. The card calls it "an accelerated checkpoint of Qwen-Image-2.1 for text-to-image generation and image editing with 8 denoising steps", built on the same 7B visual generation architecture. It is not a new family and not a new architecture. It is the base checkpoint repackaged around a much shorter sampling trajectory.

• Both capabilities in one download. Text-to-image and instruction-guided editing are served by this single checkpoint. The card's own examples use the same saved 8-step schedule and the same default CFG=1 for both, and demonstrate editing by turning a sketch of a yacht into a photorealistic image.

• The schedule travels with the weights. The checkpoint ships its recommended sampling schedule, so Diffusers loads it automatically. The card is explicit that setting `num_inference_steps` alone does not override that saved schedule. Prefix KV caching reuses text and reference-image context across denoising steps.

• Two versions of the toolkit are required. The stated install is a CUDA-compatible PyTorch build, Diffusers from source, transformers 5.17.0 or later, accelerate and pillow. The checkpoint needs Diffusers support for pipeline-configured sampling sigmas, added in PR #14950 — source tree, not a tagged release at the time of writing.

• The licence is unchanged, and it is the commercial wall. The repository carries the qwen-research licence. That agreement grants rights "FOR NON-COMMERCIAL PURPOSES ONLY" and states that commercial use requires a separate licence requested from the vendor. Nothing about Turbo relaxes it.

• No benchmark of any kind. There is no score for the Turbo checkpoint on the card, no comparison against the base, no latency figure, and no memory figure. The vendor publishes none of it.

• Not to be confused with the base model's numbers. If you see an Elo or a quality claim attached to the Qwen-Image-2.1 name, check which checkpoint it belongs to. The public image-arena row belongs to Qwen-Image-2.1, the 20 September base model, not to Turbo.

The first two local reports, and why they disagree

Two independent people put numbers on local inference within four days of the repository appearing. They measured different machines, different resolutions, and different pipelines, and their results differ by roughly an order of magnitude at the same nominal task. Both are worth reading; neither is a benchmark.

The desktop-editor report. X/@dotey, 13 October 2026: BaoCut 3.5 has integrated Qwen-Image-2.1-Turbo, and image generation happens on the local machine rather than through a server. On their Mac Mini M2, a 1080p image takes about three to five minutes and a 2K image close to twenty. They also note the tool will produce NSFW output, and that an agent can be pointed at the machine's local image service.

The native-app report. On 11 October 2026 the author of Siliconed posted to the checkpoint's own Hugging Face discussion board. Siliconed is an open-source, Apache-2.0-licensed macOS app that runs the model in Swift and Metal with no Python and no ComfyUI in the loop, comparing every stage — text encoder, transformer, VAE — channel by channel against the Diffusers implementation in fp32. On the reference machine, a MacBook Pro M1 Pro with 16 GB of unified memory, at 1024², 8 steps and CFG 1, Qwen-Image-2.1-Turbo renders in 118 seconds; a 1024×1536 render takes 190 seconds, an edit with one reference image 212 seconds, and an edit with two reference images 285 seconds. Peak memory stays between 1.8 and 2.7 GB with zero swap-outs. Z-Image Turbo on the same machine and the same resolution takes 82 to 85 seconds.

• Why 3–5 minutes and 118 seconds are not a contradiction. The poster's figure is a Mac Mini M2 at 1080p inside an application; the app's figure is an M1 Pro at 1024² driven directly. Different silicon, different pixel count, different amount of work happening around the model. Neither number tells you what your machine will do.

• What the app reports is self-reported, and says so. The author is the author. Against that: the method is published, every number comes with a stated measurement instrument — `phys_footprint` sampled every 100 ms, swap from `vm_stat` — and the project publishes a chip table with one line filled in and a public form for readers to add their own. That is more than the vendor gives you, and less than an independent lab.

• Memory is the number that decides feasibility. A 31.2 GB Standard install runs on a 16 GB Mac because weights are streamed from disk as they are needed, within a stated budget of three-quarters of system memory minus 2 GB. That is why an install size bigger than your RAM is not automatically a blocker, and why disk read throughput — not VRAM — is the constraint.

• The resolution ceiling is a real limit. The macOS port caps output at a 1024×1536 surface, any side 512 or more and a multiple of 16, on the grounds that this is the largest size measured with zero swap on a 16 GB machine. Larger renders are refused up front rather than allowed to thrash. If your work needs the base model's 2048-class presets, this local path will not give them to you.

Local weights mean no moderation layer, and that cuts both ways

The most-quoted line from the 13 October post is that the model generates NSFW images. It is worth being precise about what that is and is not.

It is not a feature the vendor advertises. The model card says nothing about content policy for the open checkpoint, and the licence does not carve out any exception: it grants non-commercial use and requires you to comply with applicable law, full stop. What the report describes is the ordinary consequence of running a diffusion model on your own hardware — there is no provider between your prompt and the sampler, so there is no provider-side filter to trip. Every open image checkpoint behaves this way. The difference here is speed and packaging: an 8-step model of this class is now fast enough on consumer hardware that the local path no longer feels like a compromise.

The compliance question moves entirely to you. If you intend to ship anything built on this checkpoint, the licence is the binding constraint, and it is not a permissive one — the base model is distributed under the same non-commercial research terms, and the Turbo checkpoint inherits them unchanged. Local inference does not change what you are allowed to do with the output.

The part that is genuinely new: a tool an agent can call

Both reports converge on the same detail, and it is the one with the longer tail. The 13 October post mentions that an agent can be pointed at the machine's local image service. The macOS port ships exactly that interface: a helper binary called `silicontrol` inside the app bundle that drives the running window from a terminal, with commands to list models, queue a render with `--wait --out`, and read status, emitting JSON lines with a final `"ok"` field. There is one queue and never two renders at once.

A local image endpoint that answers in JSON lines and returns a file path is a tool-call target. That is a different proposition from pasting prompts into a web UI: a coding agent can decide it needs a diagram, a placeholder, or a variant, call the local service, and keep working with no API key, no per-image billing, and no data leaving the machine. For non-commercial work — research, internal prototypes, evaluation harnesses — that is a genuinely new capability at 8 steps and under 3 GB of peak memory.

It also has a hard edge, and the same licence draws it. The moment the thing you are building is a product rather than a research artefact, the local path stops being the easy answer and the non-commercial restriction becomes the deciding fact.

Where a routing layer fits, and where it does not

Qwen-Image-2.1-Turbo is a research-licensed weight download. It is not a hosted endpoint on OrcaRouter, and nothing here should be read as saying otherwise. The honest split is by workload.

If your images have to be produced on a machine you control, for privacy, for cost, or because there is no connectivity, then this checkpoint and a local runner are the answer, and the routing question never arises — the non-commercial licence and the disk budget are your two constraints. If instead you are calling image models in production, where a request needs to land somewhere reliable and you would rather not hold a vendor relationship per model, that is the problem OrcaRouter exists for: 200+ models behind one OpenAI-compatible endpoint at provider list price with zero markup, automatic failover when a provider degrades, and a routing DSL for the cases where you want to express preference rather than accept a default. The two arrangements are not in competition. A local checkpoint is a tool on your desk; a router is what you put in front of the hosted models you call when the work leaves the desk.

The practical reason to keep them apart in your head is that they fail differently. A local render fails when the machine is busy, the disk is slow, or the memory budget is exceeded. A hosted call fails when a provider does. Only one of those is worth solving with failover.

What we still cannot say

Three things would settle this checkpoint's reputation, and none of them exists yet.

• No independent evaluation. Turbo has no arena row, no published Elo, and no third-party quality comparison against either Qwen-Image-2.1 or Z-Image Turbo. The quality cost of dropping from the base model's longer sampling trajectory to 8 steps is simply unmeasured in public.

• No vendor throughput or memory figure. The card characterises the checkpoint and says nothing about what it costs to run. Every number in this article that is not a date comes from a user, and every one of those is stamped with the machine it was measured on.

• One chip in the public table. The macOS port's results table has exactly one filled row, an M1 Pro, and an invitation for everyone else to add theirs. If you are about to buy hardware for this, you are extrapolating from that row plus one Mac Mini M2 anecdote.

What can be said confidently is narrower and more useful. The checkpoint exists, it is dated 9 October 2026, it does generation and editing in 8 steps at 7B, its schedule is baked into the weights, it is non-commercial, and it went from a repository to running inside desktop software in under a week with no launch at all. That is a real event in local image generation, and it is happening before anyone has published a number you can hold the vendor to.

Model choices like this one are also where the failure modes show up: the documented AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive , where each entry carries its own sources, severity, confidence grade and disputed flag.