Qwen-Image-2.1-Turbo与Qwen-Image-2.1：基础检查点与加速版之间究竟有何变化

相同的 7B 视觉生成组件。相同的 32 个单流 DiT 层。相同的七种分辨率预设，相同的统一生成与编辑界面，相同的非商业许可证，相同的 pipeline 类来加载它。Qwen-Image-2.1-Turbo 和 Qwen-Image-2.1并不是两个需要按能力二选一的模型——Turbo 检查点是对基础模型的微调，而仓库在其自身的元数据中也是这样说明的。区分它们的是单一采样轨迹，以及该轨迹的存储方式。一个运行四十步。另一个运行八步，并且在调用时拒绝接受其他任何设定。关于这一对模型，所有值得关注之处都在第二句话里。

从相同的部分开始

在探讨差异之前，相同之处值得我们梳理一番，因为它远比“Turbo”这个标签所暗示的更为广泛，也正是这一点让替换变得诱人。

• 架构。Turbo 卡片声明，它“使用与 Qwen-Image-2.1 相同的 7B 视觉生成架构”。该项目将这一组件描述为 7B 参数，分布在 32 个 Single-Stream DiT 层上。Turbo 仓库中没有任何内容表明存在更小、经过剪枝或重新设计架构的主干。

• 功能。两个检查点都被描述为可执行文生图生成与图像编辑。Turbo 继承基础模型的功能范围，而非重新阐述：基础模型的模型卡记录了原生 RGBA 透明度、最多 10 张参考图像，以及通过圆圈、涂绘标注或独立蒙版指定的局部编辑，并保留人物与产品的身份特征。

• 分辨率。Turbo 的卡片上写着“使用与 Qwen-Image-2.1 相同的分辨率预设”，然后列出了这些：1:1 为 2048 × 2048，4:3 为 2400 × 1792，3:4 为 1792 × 2400，3:2 为 2528 × 1696，2:3 为 1696 × 2528，16:9 为 2752 × 1536，9:16 为 1536 × 2752。基础模型的卡片列出了完全相同的表格。两张卡片在其示例中都使用 2048 分辨率级别。

• 加载路径。两者都通过 Diffusers 中的 QwenImage21Pipeline 加载。Turbo 卡片的快速开始就是基础卡片的快速开始，只是更改了检查点名称，并将 torch_dtype 写成了 dtype 而不是 torch_dtype。

• 许可文书。两者均依据 Qwen-Image-2.1 Research License Agreement 获得授权，都标注了 license: other 和 license_name: qwen-research，并且两者的仓库里都有一份 LICENSE 文件，就放在权重文件旁边。

如果你已经接好了 Qwen-Image-2.1，那么迁移面确实很小。也正因如此，那个行为不符合你预期的参数，才更值得仔细琢磨。

调度已从你的代码中移出，并转入检查点。

在基础模型上，步数由你自行设置。Qwen-Image-2.1 的模型卡片中，文生图示例、编辑示例和 RGBA 透明度示例都传入 num_inference_steps=40，而按照 Diffusers 的常规用法，这个数字是调用时的参数。那张卡片上没有任何内容告诉你，该检查点对调度方案有讲究。

在 Turbo 上，调度方案属于 checkpoint 元数据。卡片中说明，该 checkpoint“包含其推荐的采样调度方案，因此无需手动配置调度器即可直接使用”，随后在采样部分具体说明了这在实践中意味着什么：“推荐的 8 步采样调度方案会随 checkpoint 一起保存并自动加载。仅设置 num_inference_steps 并不会覆盖它。”

由此得出两点，而这两点都容易在相反的方向上出错。

第一点是，八并不是一个你可以向上调整的默认值。如果你想知道 Turbo 在十二步或二十步时是什么样子，卡片会告诉你，唯一途径是显式传入调用时的 sigmas 参数——然后又通过指出其他调度“尚未针对此检查点进行评估”而关上了这项实验的大门。这是供应商在告诉你，八步配置才是他们所背书的配置，而其他任何东西都是你独自踏入的未探索领域。这是一句异常诚实的话，应当被理解为一条边界，而不是一份邀请。

第二个是一个没有任何错误信息附带的复现陷阱。拿基础模型的示例，把仓库字符串改成 Turbo checkpoint，保留 num_inference_steps=40 不动，代码就会运行。它不会警告你。它会使用保存的八步调度生成一张图像，而这不会是 Turbo 展示页所显示的输出，因为四十这个值从未被读取。这就是那种看起来什么都没坏的失败模式——渲染完成了，图像也看似合理，而唯一能发现问题的办法，就是你主动去寻找差异。与它一起还埋着第二个依赖：该 checkpoint 需要一个能理解流水线配置的采样 sigma 的 Diffusers 构建，这项支持是在 PR #14950 中添加的；截至撰写本文时，它位于 Diffusers 源码树中，而不是一个已打标签的发布版本里。文中给出的安装方式是 CUDA 兼容的 PyTorch 构建，加上 Diffusers 源码、transformers>=5.17.0、accelerate 和 pillow。

你未曾迈出的那32步，由什么来买单？

这张卡片提到了两种机制，两者都值得了解，因为它们解释了 Turbo 检查点对你调用它的方式做出了怎样的假设。

• 默认 CFG 为 1。“生成默认使用 CFG=1。”在无分类器引导缩放系数为 1 时，模型不会运行 CFG 通常所需的第二次无条件前向过程——这在很大程度上正是轨迹得以缩短、而非被简单截断的原因所在。这也意味着基础模型调整引导系数的习惯无法沿用；这里没有任何可调之处，模型卡也没有提供可供调整的引导建议。

• 前缀 KV 缓存。Turbo 的模型卡写道：“前缀 KV 缓存会在去噪步骤之间复用文本和参考图像上下文。”这是继承而来的机制，并非加速检查点新增的功能：Qwen-Image-2.1 的发布公告将前缀 KV 缓存复用列为基础模型四项重点改进之一，与混合粒度注意力并列；而基础模型的首日服务集成——项目新闻列表中的 vLLM-Omni 和 SGLang 条目——也明确将前缀 KV 缓存列为其支持的功能之一。在四十步循环中，这种复用是一种优化。在八步循环中，它的重要性相对更大，因为每个缓存步骤在总工作量中所占的份额更大。

这张模型卡没有提及任何蒸馏技术。基础模型的 Qwen-Image-2.1 模型卡和项目 README 描述了架构与能力；Turbo 模型卡描述的是机制。如果你想从质量角度推断八步的代价，仓库没有提供任何可供推理的方法——只有一个调度表和一组展示图片。

步数并不是衡量标准

这就是对比中那个诚实答案所在的部分——根本没有什么可对比的，而直言不讳地说明原因，是值得的。

• Turbo 检查点没有任何已发布的评分。它的模型卡上没有任何形式的评测数值。Turbo 没有 Qwen-Image-Bench 结果，没有与基础检查点的并排对比，没有针对步数的消融实验，也没有显示质量在何处趋于平缓的表格。

• 基础检查点的分数由厂商自行报告。Qwen-Image-2.1 系列唯一的头条数字，是基础模型自身的 Qwen-Image-Bench 结果，由厂商针对基础检查点报告。它并非对 Turbo 检查点的实测，也不应被套用到 Turbo 上——加速恰恰正是最有可能影响这一数字的因素，而厂商并未说明影响幅度有多大。

• 两张卡片都没有报告时间或内存信息。两个检查点都没有延迟数据、没有吞吐量数据，也没有内存占用数据，而且两张卡片都未说明其示例所运行的硬件。基础模型的卡片至少还记录了一个内存优化章节；Turbo 卡片记录了安装、生成、编辑、采样和宽高比，然后就止步于此了。

所以目前支持 Turbo 而非基础 checkpoint 的理由，是关于设计意图的理由，而不是关于实测结果的理由。在相同架构和相同 2048 分辨率下，八步生成每张图像的成本应当显著更低。“显著”在这句话里承担着实质作用，而要用一个数字来替代它，唯一的方法就是在你自己的负载上分别运行两个 checkpoint，这也是弄清缩短后的轨迹会如何影响你所关心的那些特定图像的唯一方法。

其他什么都没动，包括许可证。

有两件事，读者本有理由认为已经发生了变化，但实际上并没有。

首先是生态系统。当 Qwen-Image-2.1 于 2026 年 9 月 20 日发布时，该项目的新闻列表在同一天记录了五项独立的首日集成：通过 PR #14804 提供 Diffusers 支持；原生 ComfyUI 支持，并发布了用于文生图和编辑的工作流模板；vLLM-Omni 支持，具备逐步执行、CUDA Graph 解码、FP8 量化以及张量并行；SGLang 支持，具备 Cache-DiT 和组件卸载；以及来自 LightX2V 项目的加速。日期为 2026 年 10 月 9 日、涵盖 Qwen-Image-2.1-Turbo 的条目记录了该检查点本身，并注明 Pro 和 Turbo API 已在阿里云百炼（Alibaba Cloud Model Studio）上线。Turbo 没有首日框架列表，新闻列表中的每一条框架条目仍指基础模型。Turbo 检查点通过一个已经存在的管道类加载；对其保存调度的支持是唯一的新增部分，并且它通过 Diffusers 源码而非带标签的发布版本提供。

第二个是许可证。Turbo 附带的是 Qwen Research License Agreement，与基础模型完全一样。加速并没有带来商业例外条款、单独的层级，也没有放宽条款——非商业限制既落在微调模型上，也落在基础模型上。仓库自身的元数据以及权重旁边的许可证文件就是证据；模型卡的许可证部分只有一句话，指向的是同一份协议。如果你看重八步的原因是它让模型足够便宜、可以放进产品里，那么许可证正挡在路中间，而需要为此给出交代的是供应商——不是这个仓库。

托管端点，以及 OrcaRouter 的定位

OrcaRouter 既不路由 Qwen-Image-2.1-Turbo，也不路由 Qwen-Image-2.1。两者都不在我们的目录中，此处也不构成提供其中任一模型的服务要约。如果你需要它们，可选的途径是厂商自有的托管 API、若干第三方平台，或者配合足够新的 Diffusers 构建来使用模型权重，以处理 Turbo checkpoint 保存的采样调度。

OrcaRouter 与这一特定对比相关的场景，正是当你自行托管某个检查点不再是正确答案时所做的那种切换。从你自行运行的开源权重模型迁移到托管式图像端点，不只是更换了模型——更是更换了故障模式。本地进程的故障方式你能够亲眼看到；而托管端点的故障方式则取决于究竟是哪个提供商做出了响应，也取决于其中某个提供商在请求进行中途性能下降时会发生什么。OrcaRouter 把 200 多种模型置于单一 OpenAI 兼容端点之后，并按提供商列表价原价透传、不加任何加价，因此厂商降价当天就能体现在我们这边，而无需等待一轮重新定价。除此之外，它还加入了跨提供商的自动故障转移、用于指定某个请求可使用哪些模型和提供商的路由 DSL，以及将多个模型组合进一次调用的模型融合。我们确实提供前端接入的图像模型是 OpenAI GPT-Image 系列、Google Imagen 4 的各档版本（包括 fast 和 ultra 变体）、Google Gemini 图像预览端点，以及 xAI Grok Imagine 图像端点。

具体来说：如果你是在两个 Qwen 检查点之间做选择，那是一个自托管决策，而偏好其中一个而非另一个的理由在于调度行为和步数。如果你真正需要的是在不拥有 GPU 的情况下让图像投入生产，那才是我们有能力帮助的决策，而它是一个不同的决策。

简短版本

• 选择 Qwen-Image-2.1，前提是你希望该检查点的采样行为与其文档一致，需要调整步数或探索调度方案，或者想要那个在发布当天就获得 Diffusers、ComfyUI、vLLM-Omni、SGLang 和 LightX2V 零日支持的版本。

• 请选择 Qwen-Image-2.1-Turbo如果你想要相同的架构和相同的能力，同时轨迹大幅缩短，并且愿意将八步视为固定设置，并从源码安装 Diffusers 来加载它，

• 无论哪种方式，许可证都一样，而且不要指望有任何已发布的加速版检查点质量数据可供与基础版本对比。步数减少是真实且见诸文档的。但它究竟牺牲了多少图像质量，任何地方都没有文档说明，再怎么读这两张卡也读不出答案——那个答案只存在于你自己的硬件上，用你自己的提示词才能得出。