为文章《Qwen-Image 2.1 悄然发布》生成的主视觉卡片,画面中有一张圆角卡片,标注为“Qwen-Image 2.1”,并带有 7B 参数标记;旁边是两张较小的卡片,分别标注为“PE-T2I”和“PE-I2I”,标记为 9B;还有一条绶带,上面写着“悄然发布,并非毫无预告”。
Engineering & Research

Qwen-Image 2.1 悄然发布:深入解析 Qwen/Qwen-Image-2.1-PE-I2I

作者

Magnus Corvin

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

2026年9月20日,Qwen-Image团队将Qwen-Image 2.1发布到了Hugging Face和ModelScope上——权重文件、许可证文件、模型卡和一篇博客文章,全部在同一天内完成,几乎没有提前预热。最引人注目的数字是视觉生成组件中的70亿参数。而几乎还没有人打开看过的部分是Qwen/Qwen-Image-2.1-PE-I2I,它是随图像模型一同发布的两个提示词重写检查点之一。它不是图像模型。它是在图像模型看到你的指令之前,决定你的指令含义的那个东西——而在本次发布中,正是这个组件在悄无声息地决定你的输出以何种语言返回。

这里的“静默发布”实际上意味着什么

措辞很重要,因为无论往哪个方向都容易说过头。Qwen-Image 2.1 既没有被泄露,也不是未经预告就发布。有发布日期为 2026 年 9 月 20 日的厂商博客文章,有一个新闻栏目标注为同一天的 GitHub 仓库,还有可实时下载的权重。它没有得到的,是一段预热期:唯一的提前信号是 9 月 17 日的一则通知,通过 ModelScope 提供 50 个抢先体验名额,并要求入选的测试者在 9 月 29 日前发布一个样本或一篇评测。三天后,权重就公开了。没有主题演讲,没有基准测试的保密期,也没有媒体宣传周期。

这是一种特定类型的发布,值得精确命名。厂商宣布了它。厂商并未推广它。对于任何考虑是否基于它进行构建的人来说,实际后果是目前还没有独立评估可供参考——只有厂商自己的材料,以及抢先体验测试者在接下来一周内发布的任何内容。在阿里巴巴外部有人公开运行它之前,请将本文中的每一项质量声明都视为来自模型卡和博客文章。

为什么 PE-I2I 检查点才是那个有趣的

Qwen-Image 2.1 版本包含三个可下载的部分,而不是一个:

• Qwen/Qwen-Image-2.1——图像模型本身。视觉生成组件采用 32 层单流 DiT,参数量为 7B;配备 Qwen3-VL 8B 文本编码器,以及一个 64 通道 RGBA VAE,具备 16× 空间压缩。三个组件合计约 33 GB。

• Qwen/Qwen-Image-2.1-PE-T2I —— 用于文生图的提示词重写器。一个经过微调的 Qwen3.5-VL 9B,约 18.8 GB。

• Qwen/Qwen-Image-2.1-PE-I2I——一个用于图生图编辑的提示词改写器。同样是微调后的 Qwen3.5-VL 9B,同样约 18.8 GB,于 9 月 20 日 08:46 UTC 上传至 Hugging Face。

"PE" 指的是提示增强(prompt enhancement)。I2I 变体接收一个模糊的编辑指令以及一张或多张输入图像,并将其改写为精确、无歧义的编辑指令,供下游扩散模型使用。该仓库自身的描述对输入形态说得很直白:输入图像始终存在,因此这始终是图像编辑任务,而绝非从无到有的文生图。改写代码位于 prompt_rewrite/ 文件夹中,该文件夹同时服务于两个检查点 — --task t2i 或 --task edit — 包含一条 transformers 路径、一条 vLLM 路径、用于常驻服务的 serve.sh 加上 client.py,以及用于共享逻辑的 pe_core.py。

这就是为什么这一点比听起来更重要。图像模型根本不知道你想表达什么。它所掌握的只是你的提示词字面上说了什么,再叠加文本编码器对其的处理权重。而坐在它前面的重写器,正是消解歧义的地方——或者把歧义错误地消解掉,而且在你生成的每一张图上都保持一致。在一个支持多达 10 张参考图的统一生成与编辑模型中,这个消解环节比平时更容易出错。

系统提示词是语言决策所在之处

PE-I2I 仓库随权重一起提供了 system_prompt.txt,并且它对一件事说得异常明确:语言。直接阅读它,重写器被指示要做出 两项独立的语言决策,并将二者区分开来。

• 描述语言。 重写器用来描述此次编辑的文字,遵循用户指令所使用的语言——中文指令用中文描述,英文指令用英文描述;日语、韩语、法语、泰语或其他任何语言的指令,一律用英文描述。

• 渲染文本的语言。 实际绘制到输出图像中、以双引号括起的文本,由严格的优先级顺序决定:首先,如果用户明确指定了确切文本或目标语言,就照字面遵从;其次,如果输入图像中已经包含文本,则匹配该现有文本的主要语言——即使指令是用另一种语言写的;第三,如果图像中没有文本,也未指定语言,则使用指令本身的语言,尤其不要强制使用英语。

该提示用一个实例进一步强化了第二条规则——一张以泰文为主的图片,若用一条未指明语言的英文指令来编辑,就必须渲染出泰文文本——并新增了两项约束:渲染出的文本必须是单一语言的,而不是中英文并列;而“规格表”或“分镜脚本”这类视觉体裁应当通过版式与字体排印来实现,绝不能靠把渲染出的标签切换成英文来达成。

这是一处很小的工程改动,却有着很大的影响范围。如果你正在为一个包装文字至关重要的市场生成产品图像,那么“重写器会保留现有的标签语言”与“重写器会好心地把所有内容都翻译成英语”之间的差异,就是可用素材与被拒素材之间的差异。而且,由于这种行为是在随仓库一起发布的系统提示中规定的,你可以阅读它、对它做 diff,并覆盖它——而对于闭源托管模型内部的同一步骤,你可没法这么说。

哪些是已确认的,哪些不是

在这里精确划定边界,正是一篇“我们所知”类文章的全部意义所在。

• 已从代码仓库和模型卡中确认——7B / 32 层单流 DiT 架构;Qwen3-VL 8B 文本编码器;64 通道 RGBA VAE,空间压缩率为 16×;块因果注意力(block-causal attention),对文本使用 token 级因果掩码,对图像生成使用块级双向掩码;前缀 KV 缓存复用,模型卡称当检查点带有 causal_condition: true时该机制会启用(确实如此);采用欧拉离散调度的流匹配;原生 2K 输出,默认 2048×2048、40 个推理步;七种文档化的宽高比预设;最多支持 10 张参考图像;通过圈选、涂鸦标注或单独掩码进行局部编辑;以及 RGBA 生成、透明图层编辑和从 RGB 照片中提取主体。

• 许可方面已经确认,而这就是关键症结——该版本依据 2026 年 9 月 20 日的 Qwen Research License Agreement 发布,该协议授予的权利“仅限非商业用途”,并声明商业使用需向供应商另行申请许可。与早前以 Apache 2.0 发布的 Qwen-Image 系列相比,这是一项实质性变化。在基于它构建产品之前先把许可文件读一遍,别等到事后才读。

• 未确认——目前尚无独立的基准测试分数。该博客文章引用了一张 Qwen-Image-Bench 对比图表,但其中的数字来自厂商自身,截至本文撰写时尚未被任何第三方复现。Qwen-Image 2.1 没有公布托管端点价格,也没有说明商业许可条款。而且目前也尚无消息表明是否会推出采用宽松许可的变体。

确实存在的一个独立数据点,是一位测试者提供的一手早期体验评测;他通过 Qwen Ambassador 计划获得了访问权限,并通过 ModelScope Studio 界面运行了最终发布版权重。那篇评测报告称,文本到图像的生成时间约为 10–15 秒,编辑约为 18–23 秒,在镜头位置预设和多人物角色分配方面表现强劲,还有一个值得了解的特定失效模式:从大约三张输入图像起,多参考一致性就会下降,侧马尾的位置在侧脸角度下会塌缩成中间马尾。那只是一名评测者,在一个早期访问界面上,且没有显示计时器。这是有用的信号。这不是基准测试。

A generated single-column spec scoreboard titled 'Qwen-Image 2.1 — the scoreboard' listing rows: Generation component 7B, 32-layer single-stream DiT; Text encoder Qwen3-VL 8B; Licence Qwen Research License, non-commercial only; Native output 2048 x 2048 at 40 steps; Reference images up to 10; Transparency native RGBA; Independent score none yet. Footer reads 'Figures per the Qwen vendor model card, unaudited; no third-party reproduction at the time of writing.'

首日框架支持,这才是那个低调的好消息

模型在发布当天能落到哪些平台上,比模型卡更能说明你是否真的用得上它,而 Qwen-Image 2.1 的落地范围很广:

• Diffusers — QwenImage21Pipeline在发布当天即被合并,模型仓库带有diffusers:QwenImage21Pipeline标签。

• ComfyUI — 原生首日支持,提供文生图和图像编辑工作流模板,以及独立的 Comfy 兼容权重仓库。

• vLLM-Omni — 逐步执行、前缀 KV 缓存、CUDA Graph 解码、FP8 量化,以及张量/Ulysses 并行。

• SGLang —— 一个原生支持的拉取请求于 9 月 17 日落地,三天早于权重发布,涵盖 DiT、RGBA VAE、Qwen3-VL 条件、多张参考图像以及 RGBA 输入/输出,并已在 H200、B200、RTX PRO 6000、RTX 5090 和 RTX 4090 上完成验证。

• LightX2V—— 首日加速,并通过 ROCm 为 AMD Radeon 提供支持,同时借助 FlagOS 实现多芯片支持。

预发布的 SGLang pull request 就是那个信号。框架支持在权重发布之前落地,意味着服务路径是针对检查点测试的,而不是事后根据模型卡编写的。对于一个 7B 组件,旁边还配着一个 17.5 GB 的文本编码器来说,这就是花一个周末无休止地折腾琐事和只花一个下午的区别。

对于显存受限的 GPU,模型卡建议采用 CPU 卸载 — pipe.enable_model_cpu_offload() — 这属于标准的应急手段,而非真正的解决方案。33 GB 的下载量主要来自文本编码器,而非 DiT;扩散 Transformer 本身只占整个包中较小的一半,约为 14 GB。

A screenshot of the Qwen vendor blog page for Qwen-Image 2.1, captured September 20 2026, showing the 2026/09/20 date, the headline 'Compact, Efficient, and Unified Image Creation', the 'Now open weights' hero banner, GitHub, Hugging Face and ModelScope buttons, and the 7B parameter figure.

实用阅读

如果你想今天尝试 Qwen-Image 2.1,诚实的立场是:你可以在本地、在研究许可下进行,但没有独立基准测试,也没有商业权利。对于评估来说,这是一笔合理的交易;对于生产管线来说,则是一笔糟糕的交易,而这两者之间的差距,正是由许可证文件所决定的。

对于想要对图像模型进行基准测试、又不愿把生产路径押注在几天前的检查点上的团队而言,路由层正是将这种风险加以控制的地方。OrcaRouter 以供应商标价、零加价的方式,将 200 多个模型置于同一个兼容 OpenAI 的端点之后,并支持跨供应商的自动故障转移,因此一个尚未经过验证的模型可以与一个你已信任的模型并排放在同一条路由之后,而不是取而代之——而且由于标价是直接透传的,任何被路由的模型一旦供应商降价,当天即可生效,无需等待合同变更。截至本文撰写时,Qwen-Image 2.1 并不在我们路由的模型之列,本文也不会暗示相反的情况。我们确实路由的是其周边的图像产品线——OpenAI 的 GPT-Image 系列、Google 的 Imagen 4 各档位和 Gemini 图像预览版,以及 xAI 的 Grok Imagine 图像端点——在你于自有硬件上评估这位新来者时,故障转移路径正来源于此。

那个悬而未决的问题,正是仓库无法回答的。阿里巴巴以仅限研究的许可证发布了一款 7B 开放权重图像模型,而同年,它又将 Qwen-Image 3.0 作为完全不提供权重的闭源托管模型发布。两次发布,两种截然相反的押注,相隔四个月。这两者中哪一种会决定下一代 Qwen 图像模型的形态——以及研究许可证是否终有一天会转变为商业可用的东西——才是值得关注的地方。权重现在就在 Hugging Face 上,任何人都可以自行阅读许可证文件。

A screenshot of the Hugging Face model card for Qwen/Qwen-Image-2.1, captured September 20 2026, showing the Like and Follow counts, the tags Text-to-Image, Diffusers, Safetensors, QwenImage21Pipeline, rgba, the qwen-research licence, 7B params, BF16 tensor type, and the notice that the model is not deployed by any inference provider.