桌面端运行 Qwen-Image-2.1-Turbo：BaoCut 3.5 与首次本地耗时实测

的仓库Qwen-Image-2.1-Turbo于 2026 年 10 月 9 日出现在 Hugging Face 上，拥有 707 个赞、权重文件、一个许可证文件，以及 Qwen-Image-2.1 GitHub 新闻列表中的一行——这就是它的全部发布公告。五天后，它已经在人们的桌面上运行起来。BaoCut 3.5 是一款中国桌面编辑工具，它集成了该检查点，并开始在本机生成图像，而不是通过服务器；X/@dotey 于 2026 年 10 月 13 日报道称，在其 Mac Mini M2 上，1080p 下生成一张图片大约需要三到五分钟，2K 下则接近二十分钟。另外，一款名为 Siliconed 的开源 macOS 应用于 2026 年 10 月 11 日在模型自己的讨论板上发帖称，在 M1 Pro 上实测 1024² 为 118 秒，而同一台机器运行 Z-Image Turbo——人们正在两者之间选择的另一个 8 步开放检查点——用时 82 到 85 秒。Qwen-Image-2.1是两个本地移植版所源自的基础模型，于 2026 年 9 月 20 日发布。该加速检查点比其父模型年轻三周，并且没有自己的独立评估。

这就是这件事的轮廓：一个从未上线、只是被发布的检查点，如今在厂商尚未公开谈及它太多之前，就已进入桌面软件之中。接下来会把代码仓库实际陈述的内容与首批用户所报告的内容区分开来，因为这两者并不是同一类说法。

该仓库确认了什么，以及没有确认什么

以下所有内容均来自模型卡、许可证文件和项目变更日志——这些都是一手资料，任何人都可核查。

• 有日期，而且在关键之处都标注了日期。Hugging Face API 显示该仓库创建于 2026-10-09T04:50:01Z，最后修改于 2026-10-12。Qwen-Image-2.1 的 GitHub 新闻列表中有一条与之对应的记录：“2026.10.09：我们发布了 Qwen-Image-2.1-Turbo，仅需 8 个去噪步骤即可完成图像生成与编辑。”同一份更新日志还记载，Pro 和 Turbo API 于同一天在 Alibaba Cloud Model Studio 上线。这是一次发布；这是一次没有发布会的发布。

• 它是什么。 模型卡将其称为“Qwen-Image-2.1 的加速检查点，用于文生图生成和图像编辑，仅需 8 个去噪步数”，它基于相同的 7B 视觉生成架构。它既不是新系列，也不是新架构。它只是基础检查点围绕一条短得多的采样轨迹重新打包而成。

• 一次下载即可获得两种能力。文生图和指令引导编辑都由这一个 checkpoint 提供。模型卡自带的示例对二者使用相同的已保存 8 步调度以及相同的默认 CFG=1，并通过将一张游艇草图转化为照片级逼真图像来演示编辑功能。

• 调度表随权重一同分发。 该检查点自带其推荐的采样调度表，因此 Diffusers 会自动加载它。模型卡明确指出，仅设置 `num_inference_steps` 并不会覆盖已保存的调度表。前缀 KV 缓存会在各去噪步骤之间复用文本和参考图像的上下文。

• 该工具包需要两个版本。 所述的安装环境为：兼容 CUDA 的 PyTorch 构建版本、从源码安装的 Diffusers、transformers 5.17.0 或更高版本、accelerate 以及 pillow。该检查点需要 Diffusers 支持由 pipeline 配置的采样 sigma，此功能在 PR #14950 中加入——在撰写本文时，需使用源码树，而非带标签的发布版本。

• 许可证没有变化，它依然是那道商业壁垒。 该仓库采用 qwen-research 许可证。该协议授予的权利"仅限非商业用途"，并规定商业使用需向供应商另行申请许可。Turbo 并未对此有任何放宽。

• 没有任何形式的基准测试。卡片上没有 Turbo checkpoint 的任何分数，没有与基础版本的对比，没有延迟数据，也没有内存数据。厂商对此一概不予公布。

• 不要与基础模型的数字混淆。如果你看到某个 Elo 评分或质量宣称挂在 Qwen-Image-2.1 名下，请先确认它属于哪个检查点。公开的 image-arena 排行榜条目属于 Qwen-Image-2.1，即 9 月 20 日发布的基础模型，而不是 Turbo。

前两份本地报告，以及它们为何不一致

两个互不相干的人在该仓库出现后的四天内，都为本地推理给出了具体数字。他们测量的是不同的机器、不同的分辨率和不同的流程，而在同一名义任务上，两人的结果相差大约一个数量级。两篇都值得一读；但两者都不是基准测试。

桌面端编辑器的报告。X/@dotey，2026年10月13日：BaoCut 3.5 已集成 Qwen-Image-2.1-Turbo，图像生成在本地机器上完成，而不是通过服务器。在他们的 Mac Mini M2 上，生成一张 1080p 图像大约需要三到五分钟，2K 图像则接近二十分钟。他们还指出，该工具会输出 NSFW 内容，并且可以把智能体指向本机的本地图像服务。

原生应用报告。2026 年 10 月 11 日，Siliconed 的作者在检查点自己的 Hugging Face 讨论板上发帖。Siliconed 是一款开源、采用 Apache-2.0 许可的 macOS 应用，用 Swift 和 Metal 运行模型，流程中不涉及 Python，也不涉及 ComfyUI，并将每个阶段——文本编码器、Transformer、VAE——逐通道与 fp32 的 Diffusers 实现进行对比。在参考机器上，一台配备 16 GB 统一内存的 MacBook Pro M1 Pro，在 1024²、8 步、CFG 1 下，Qwen-Image-2.1-Turbo 渲染耗时 118 秒；1024×1536 渲染耗时 190 秒，使用一张参考图进行编辑耗时 212 秒，使用两张参考图进行编辑耗时 285 秒。峰值内存保持在 1.8 至 2.7 GB 之间，零换出。同一台机器、相同分辨率下，Z-Image Turbo 耗时 82 至 85 秒。

• 为什么 3–5 分钟和 118 秒并不矛盾。 海报上的数字是一台在应用程序内以 1080p 运行的 Mac Mini M2；而应用给出的数字是一台直接驱动、以 1024² 运行的 M1 Pro。不同的芯片、不同的像素数量，模型之外所进行的工作量也不同。这两个数字都无法说明你的机器会跑出什么结果。

• 该应用报告的数据属于自我报告，而且它自己也如实说明了这一点。 作者终究只是作者。但与之相对的是：方法已公开发表，每个数字都配有明确说明的测量工具——`phys_footprint` 每 100 毫秒采样一次，交换区数据取自 `vm_stat`——而且该项目还公布了一张芯片表，其中已填好一行，并提供公开表单供读者补充自己的数据。这比厂商提供给你的多，但比独立实验室少。

• 内存是决定可行性的那个数字。一个 31.2 GB 的标准安装能在 16 GB 的 Mac 上运行，是因为权重会按需从磁盘流式读取，且限定在系统内存的四分之三减去 2 GB 的预算之内。这就是为什么安装体积大于你的内存并不自动构成阻碍，也是为什么真正的限制是磁盘读取吞吐量——而非显存。

• 分辨率上限是一个实实在在的限制。 macOS 版把输出限制在 1024×1536 的画面，任意一边不小于 512 且为 16 的倍数，理由是在 16 GB 机器上实测零交换的最大尺寸就是它。更大的渲染会在一开始就被拒绝，而不是放任它去反复换页。如果你的工作需要基础模型的 2048 级预设，这条本地路径给不了你。

本地权重意味着没有审核层，而这是把双刃剑

10月13日那篇帖子中被引用最多的一句话是，该模型会生成NSFW图像。对于这究竟是什么、又不是什么，值得精确说明。

这不是厂商宣传的功能。模型卡对开放检查点的内容政策只字未提，许可证也没有划出任何例外：它授予非商业使用，并要求你遵守适用法律，仅此而已。报告所描述的是在自有硬件上运行扩散模型的正常结果——你的提示词和采样器之间没有服务提供商，因此不存在可供触发的服务商端过滤器。每个开放图像检查点都如此。这里的差别在于速度和封装：此类8步模型如今在消费级硬件上已经足够快，以至于本地路径不再像是一种妥协。

合规问题完全落到你身上。如果你打算发布任何基于此检查点构建的东西，许可证就是具有约束力的限制，而且它并非宽松型——基础模型依据相同的非商业研究条款分发，Turbo 检查点原样继承这些条款。本地推理不会改变你对输出可以做什么。

真正新颖的部分：一个智能体可以调用的工具

两份报告都指向同一个细节，而它正是那条尾巴更长的。10月13日的帖子提到，可以把一个 agent 指向这台机器的本地图像服务。macOS 版本恰好提供了这一接口：应用包内有一个名为 `silicontrol` 的辅助二进制文件，可从终端驱动正在运行的窗口，其命令可列出模型、用 `--wait --out` 排队一次渲染以及读取状态，并输出带有最终 `"ok"` 字段的 JSON 行。只有一个队列，任何时候都不会同时进行两次渲染。

一个以 JSON lines 格式响应并返回文件路径的本地图像端点，就是一个工具调用目标。这与把提示词粘贴进 Web UI 是两回事：编码智能体可以自行判断它需要一张示意图、一个占位图或一个变体，调用本地服务，然后继续工作——无需 API key，无需按图计费，数据也不离开本机。对于非商业用途——研究、内部原型、评测框架——这是一项真正的新能力：仅需 8 步，峰值内存低于 3 GB。

它也有一个硬边界，而划定它的是同一份许可证。当你正在构建的东西是产品而非研究产物时，本地路径就不再是轻松的答案，非商业限制便成为决定性事实。

路由层适用于何处，又不适用于何处

Qwen-Image-2.1-Turbo 是一个采用研究许可的权重下载项。它并非 OrcaRouter 上托管的端点，此处的任何内容都不应被解读为相反的表述。诚实的划分方式是按工作负载来分。

如果你的图像必须在一台你掌控的机器上生成——无论是出于隐私、成本，还是因为根本没有网络连接——那么这个检查点加上本地运行器就是答案，路由的问题根本不会出现：非商业许可证和磁盘预算就是你的两个约束条件。反过来说，如果你是在生产环境中调用图像模型，请求需要落在某个可靠的地方，而你又不想为每个模型都维持一份供应商关系，那么这正是OrcaRouter存在的意义：在一个兼容 OpenAI 的端点背后提供 200+ 个模型，按供应商标价计费，零加价，当某家供应商出现劣化时自动故障转移，并为你想要表达偏好、而非接受默认设置的情形提供一套路由 DSL。这两种安排并不相互竞争。本地检查点是你桌上的工具；而路由器则是当工作离开桌面时，你放在所调用的托管模型前面的东西。

把它们在脑子里区分开来的实际原因在于，二者的失败方式不同。本地渲染会在机器繁忙、磁盘缓慢或内存预算超限时失败。托管调用则会在服务提供商出问题时失败。这当中只有一种值得用故障转移来解决。

我们仍然无法言说的事

有三件事本可以确立这个检查点的声望，但它们目前都还不存在。

• 无独立评测。Turbo 没有竞技场排名记录，没有公开的 Elo 分数，也没有针对 Qwen-Image-2.1 或 Z-Image Turbo 的第三方质量对比。从基础模型较长的采样轨迹降到 8 步，其质量代价在公开信息中根本没有被测量过。

• 没有厂商提供的吞吐量或内存数据。这张卡片只描述了检查点的特征，对其运行成本只字未提。本文中凡是并非日期的数字，都来自用户，而且每一个都标注了它是在哪台机器上测得的。

• 公开表格里只有一款芯片。macOS 移植版的结果表里只有一行填了数据，是 M1 Pro，另外就是邀请其他人也把自己的数据加进去。如果你正准备为此掏钱买硬件，那你无非是拿这一行数据，再加上一则 Mac Mini M2 的轶事，在外推而已。

能笃定说出口的东西，范围更窄，却更有用。这个检查点确实存在，日期是 2026 年 10 月 9 日，它以 7B 的规模在 8 步内完成生成和编辑，它的调度被烘焙进权重里，它是非商业性的，而且它在不到一周内就从代码仓库变成在桌面软件里运行，全程没有任何发布。这是本地图像生成中的一个真实事件，而它发生的时候，还没有人公布过一个能让你拿厂商是问的数字。

这样的模型选择，也正是失效模式暴露之处：这一类模型背后有据可查的 AI 事故与智能体故障，都收录在the OrcaRouter AI Incident Archive中，其中每一条记录都附带各自的来源、严重程度、置信等级和争议标记。