Qwen-Image-2.1-Turbo：8 步检查点是什么，以及它与 Qwen-Image-2.1 有何不同

Qwen-Image-2.1-Turbo的加速检查点Qwen-Image-2.1：相同的7B视觉生成主干，相同的两项任务——文生图生成和指令引导的图像编辑——以及八个去噪步骤，而基础检查点自己的示例使用四十步。它不是新架构，也不是新模型系列，文件内没有第二个模型。该检查点于2026年10月9日上传至Hugging Face，这一日期既由仓库的创建时间戳承载，也由Qwen-Image项目自己的新闻列表中的一行承载；以下所有内容是该模型的常设描述，于2026年10月13日根据供应商自己的材料重新确立，而非根据任何人对它的总结。

如果你输入该模型的名称是为了弄清它是什么，简短的回答就是上一段。有用的回答则在于对比。

Turbo 版本，逐一维度解析

以下每一行都来自该检查点自身的仓库——模型卡片、model_index.json、transformer/config.json 以及 LICENSE——或来自 GitHub 上的 Qwen-Image 项目仓库，均为今日读取。凡厂商未发布任何内容之处，我们如实说明，而非凭空补全。

• 步数——Qwen-Image-2.1-Turbo 只需 8 个去噪步数，而 Qwen-Image-2.1 需要 40 个。这个 40 是厂商自己给出的数字，其模型卡上的每个 Qwen-Image-2.1 示例都采用了该值，GitHub 上该项目的参数表也将其列为默认值。

• 速度——步数是 Qwen 唯一给出的速度声明，而且它只是一个计数，而非测量结果。两个检查点均未给出延迟、吞吐量或每 GPU 图像数，两张模型卡也都没有说明其示例是在什么硬件上生成的。

• 质量权衡——未量化。Qwen-Image-2.1-Turbo 没有评估得分，Qwen-Image-2.1 也没有，而且厂商的资料中没有任何地方对两者进行过直接对比。Turbo 卡片上展示的图片是厂商挑选的八步输出；它们只能说明该检查点能生成图像，并不能说明为了达到八步而牺牲了多少保真度。在撰写本文时，我们无法获得针对这两个检查点中任何一个的第三方基准测试结果。

• 采样调度表所在之处——这是卡片所揭示的唯一一处结构性差异。Turbo 的 model_index.json包含一个由八个值组成的 sample_sigmas数组，从 1.0 一路降到 0.414568，卡片中还说明该调度表会随检查点一同保存并自动加载——“仅设置 num_inference_steps并不会覆盖它。”Qwen-Image-2.1 则在调用时接收步数。变通办法是在调用时显式传入 sigmas参数，卡片还指出其他调度表“尚未针对该检查点进行评估”。

• 主干网络 — 完全相同。Turbo 的 transformer/config.json 与基础检查点逐字段匹配：32 层，32 个注意力头，每个 128 维，patch 大小 1，64 个输入和输出通道，causal_condition 为 true，上下文输入维度为 4096。两个文件之间唯一不同的值是记录的 Diffusers 版本。

• 文本编码器、VAE 与调度器——Turbo 的 model_index.json将 Qwen3VLForConditionalGeneration指定为文本编码器，搭配 Qwen3VLProcessor、AutoencoderKLQwenImage21 VAE 以及 FlowMatchEulerDiscreteScheduler。这些与 Qwen-Image-2.1 所声明的组件类完全相同。该项目的架构说明将共享的文本编码器描述为 Qwen3-VL 8B 视觉语言模型，并将该 VAE 描述为具有 16× 空间压缩的 64 通道 RGBA 自编码器。

• 引导默认值 —Turbo 模型卡默认标注为 CFG 1，这会从每个步骤中移除无分类器引导这一过程。基础模型的模型卡则完全没有说明引导的默认值。

• 分辨率预设 —两者均为这相同的七种，逐字取自 Turbo 卡片：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。

• 磁盘占用 —Turbo 仓库自身的文件清单总计约 32.5 GB，其中包含一个 14.2 GB 的 transformer、一个 17.5 GB 的文本编码器和一个 0.7 GB 的 VAE，这是根据该仓库今日公布的文件大小计算得出的。这是基础 checkpoint 在 bfloat16 精度下的组件集合，而厂商并未自行推出任何量化版本。

Qwen 实际上如何看待速度与保真度之间的取舍

厂商的说法比标题所暗示的更为有限，值得按其模型卡自身的表述来读。Qwen-Image-2.1-Turbo 被描述为“Qwen-Image-2.1 的一个加速检查点，用于文本到图像生成和图像编辑，具有 8 个去噪步骤”，它“采用相同的 7B 视觉生成架构，并可直接通过 QwenImage21Pipeline加载。”该模型卡对收益的表述是流程性的，而非视觉上的：该检查点“包含其推荐的采样调度，因此无需手动配置调度器即可直接使用。”

文中点名了三种机制，也只有三种。八步调度本身。默认的 CFG 1，它会省去 guidance pass。还有前缀 KV 缓存，它“在去噪步骤之间复用文本和参考图像上下文”——这一机制 Base 模型也有文档记载，而且在循环总共只有八次迭代时，它的重要性只会更高，而非更低。

现在说说那些没有写出来的部分。这张模型卡片从未声称 Turbo checkpoint 能达到 Qwen-Image-2.1 的输出质量。它从未说明牺牲了多少质量，也没有说明哪些类别会最先退化——纹理、小字文本、人脸、多参考一致性。它从未使用“蒸馏”这个词，仓库中也没有任何地方声明存在教师—学生关系。元数据实际说明的则是衍生关系：Hugging Face 的标签带有 base_model:Qwen/Qwen-Image-2.1 以及 base_model:finetune:Qwen/Qwen-Image-2.1，而 ModelScope 的模型记录列出了同一个父模型，关系为“finetune”。换句话说，Qwen 自身的定位是 基础 checkpoint 的微调版本，而质量问题则留给运行它的人自行判断。

与其说这是批评，不如说是这次发布本身的形态。一个厂商发布了加速版检查点却没有提供基准测试，恰恰是在邀请读者自己去跑那种对比：相同的提示词、相同的随机种子、两个检查点，四十步对八步。

输入、输出，以及这个东西实际有多大

该卡片记录了两个输入模态和一个输出模态，它们均属于基础模型，未作更改。

• 文本进，图像出——一条文本提示即可生成一张光栅图像。该卡片给出的范例是一张 1696 × 2528 的竖版海报，展示部分涵盖了人像摄影、字体排版与海报设计，以及 UI 与信息布局；这些体现的是 Qw​en 对于文本渲染与布局保真度的主张，而非对其的实测。

• 图像输入，图像输出——同一流水线可在提示词旁接收一张输入图像，用于指令引导式编辑。该卡片的示例将一艘游艇草图转换为 2048 × 2048 的逼真照片，并将输入加载为 RGBA。该展示还演示了多参考合成和四图室内合成。这里有一个需要留意的数字：“最多 10 张参考图像”这一数字属于 Qwen-Image-2.1 的文档，而 Turbo 卡片并未重述参考图像数量上限。应将 10 视为基础模型已公布的数字，而非 Turbo 的规格。

• Tongyi——模型卡将透明图像生成列入展示类别，而随附的 VAE 类与基础模型所用的是同一个 64 通道 RGBA 自编码器，因此 alpha 输出是针对该检查点明确记录的，而非仅仅是名义上的继承。

• 输出分辨率——与上文列出的七个预设相同，横屏最高 2752 × 1536，竖屏最高 1536 × 2752，其中 2048 × 2048 为默认档位。该项目将 Qwen-Image-2.1 描述为原生支持 2K 分辨率；两个仓库中均未声称有高于该级别的原生层级，也没有任何内容记载有放大阶段。

• 模型规模——视觉生成组件在 32 个单流 DiT 层中共有 7B 参数，采用 bfloat16 精度，完整仓库在磁盘上约占用 32.5 GB。这里没有可引用的文本上下文窗口，因为它不是文本模型；transformer 配置中的 4096 维上下文输入是编码后的提示词与条件图像表示，而非 token 窗口。

许可证，以及权重所在的位置

Qwen-Image-2.1-Turbo 依据 Qw​en Research License Agreement 发布。该仓库的元数据写着 license: other，并带有 license_name: qwen-research 以及 license_link: LICENSE，同时仓库中还与权重放在一起的有一个 LICENSE 文件。我们今天对比了这两份许可证文件：Turbo 仓库的 LICENSE 与基础模型的逐字节完全相同，这一点值得了解，因为它意味着加速并未带来条款上的任何变化。

协议本身是怎么说的——直接从文件里读出来的：授权是"仅限非商业用途"，"非商业"被定义为"仅用于研究或评估目的"，而商业用途需要"从我们这里获得一份单独的商用许可"，可通过model-business@notice.qwencloud.com申请。协议自己的页眉把这一版本的日期定为2026年9月20日。如果你想要八步生成的原因，是它能让模型便宜到足以放在某个产品背后，那么这里真正构成约束的是许可，而不是步数，而这个仓库里没有任何一页能解决这一点。

权重可在两个地方下载，且均为官方渠道：Hugging Face 上的 Qwen/Qwen-Image-2.1-Turbo，以及 ModelScope 上的 Qwen/Qwen-Image-2.1-Turbo。Hugging Face 仓库未设置访问门禁。其元数据未列出任何托管推理服务提供方，因此就厂商自己的列表所示，目前没有第三方端点可以为你运行这个确切的检查点。

对于托管路线，有 Qw​en 自家的方案：该项目的新闻列表记录，Qwen-Image-2.1 Pro 和 Turbo API 已于 2026 年 10 月 9 日在 Aliba​ba Cloud Model Studio 上线，而 GitHub README 提供的是“托管 API，或者在你自己的环境中用 Diffusers 运行 Turbo checkpoint”。Turbo 端点的每张图片价格，并未在我们读到的厂商 API 参考页面上说明，该页面改为指向另一个模型定价页面——因此，在我们能够核实的材料中，请把该价格视为未公布，并在据此做规划之前先查看厂商的定价页面。

微调：哪些有文档记录，哪些仅存在于社区

诚实的答案是，Turbo 模型卡没有记录任何形式的微调。它涵盖安装、文生图、图像编辑、采样与宽高比，然后就没了。Qwen-Image 项目仓库中没有任何训练章节、没有 LoRA 说明、没有适配器指南、没有数据集说明，也没有任何训练脚本——我们检查了它的文件树，其中只包含资源文件和两个提示词重写数据文件。

基础模型的表现略好一些，而且那是另一个模型的文档：Qwen-Image-2.1 的资料记录了通过 ModelScope 进行的 LoRA 训练，其基于开源的 DiffSynth-Studio 框架构建。该说法针对的是 Qwen-Image-2.1，而 Turbo 模型卡中没有任何内容将其延伸至加速检查点。

Turbo 目前拥有的一切都是社区作品。截至今天，Hugging Face 上有 47 个仓库声明Qwen/Qwen-Image-2.1-Turbo为其基础模型，而这些几乎全都是量化移植版本——GGUF、FP8、INT8、INT4、NVFP4、MLX、OpenVINO 构建。其中只有一个 LoRA 适配器，是 2026 年 10 月 10 日发布的一款角色替换适配器。这些都不是厂商支持，也没有任何一项经过 Qwen 验证；而且，针对基础检查点的四十步轨迹训练出来的适配器，并不能自动适配已保存的八步调度。如果你是来这里寻找 Turbo LoRA 工作流的，准确的答案是：厂商从未发布过。

如何运行它，以及如何调用它

自托管是一项常规的 Diffusers 任务，只有一个棘手之处。模型卡的安装方式包括 CUDA 兼容的 PyTorch 构建、从源码安装 Diffusers（git+https://github.com/huggingface/diffusers.git）、transformers>=5.17.0、accelerate和pillow。棘手之处在于，该检查点需要一个支持流水线配置采样 sigma 的 Diffusers 构建，这一功能由 PR #14950 添加——在撰写本文时，它还位于源码树中，而不在已打标签的发布版本里，这就是为什么模型卡没有告诉你安装某个版本号。

加载那一行就是基础模型的 pipeline 类，只是把检查点名称换掉了：QwenImage21Pipeline.from_pretrained("Qwen/Qwen-Image-2.1-Turbo", dtype=torch.bfloat16).to("cuda")。生成时则是一次调用，传入提示词、来自预设列表的宽度和高度、use_kv_cache=True，以及一个生成器种子；模型卡中的文生图示例使用 1696 × 2528、种子 42，其编辑示例则以 2048 × 2048 传入一张 RGBA 图像作为 image 参数，种子为 20261009。不要传 num_inference_steps还指望它能起什么作用。

有一个需要提前规划的空缺：Turbo 模型卡没有发布任何显存方面的指引。基础模型的模型卡则有一个显存优化章节，其中展示了 pipe.enable_model_cpu_offload()；而 Turbo 模型卡就到此为止了。由于仓库中有一个 17.5 GB 的文本编码器，这才是你需要按此做预算的数字，而模型卡并没有告诉你它能装在哪块 GPU 上。

所谓调用它而不是运行它，指的是 Qwen 自己在 Alibaba Cloud Model Studio 上托管的 Turbo API。供应商的 API 参考页面上既没有我们能核实的已公布每张图片价格，也没有我们能核实的已公布速率限制——因此，计划上量的读者在决定投入之前，需要先从供应商那里获取两个数字。

OrcaRouter 的定位，直白地说

OrcaRouter 不会路由 Qwen-Image-2.1-Turbo，也不会路由 Qwen-Image-2.1——这两个标识符均未出现在我们今天核查过的实时模型列表中，本页面上的任何内容均不应被解读为提供其中任一模型服务的要约。 我们主推的图像产品线是托管版本：Open​AI GPT-Image 系列、Goog​le 的 Imagen 4 各层级以及 x​AI 的 Grok Imagine 图像端点。

对这个检查点来说，真正具有实际意义的正是这一区分。OrcaRouter 把 200 多个模型放在同一个兼容 OpenAI 的端点之后，按提供商标价提供、零加价，并且当提供商服务降级时，它还会自动进行故障转移——在生产环境中调用托管图像模型时，这正是你所需要的；而当所涉模型是一个 32.5 GB 的研究许可下载文件时，这一点则无关紧要。如果你打算自己运行 Qwen-Image-2.1-Turbo，那么制约因素并不在路由层，而在于 Qw​en 研究许可协议。

所以决定很清晰。八步、一份已保存的调度、一份字节级相同的研究许可证，再加上没有基准测试，意味着这个检查点是一个研究与原型开发工具，直到 Qw​en 发布评估，或者你自己运行一个为止。如果你本周就需要一个生产环境中的图像端点，那是另一笔采购，而那正是我们所出售的那一种。