ComfyUI 跑 Qwen Image 2.1 文生图：bf16 与 int8 显存取舍和配置

AI智能摘要

ComfyUI 跑 Qwen Image 2.1 时,很多人一上来就加载最高精度权重,结果刚点生成便显存溢出。这款来自阿里 Qwen 团队的开源文生图模型提供了 bf16 与 int8 两条路线:前者画质更细,后者显存约减半。文章从模型文件与目录放置讲起,梳理节点连接、1024 与 2K 分辨率的取舍、25 步默认设置,并按 16GB、24GB、32GB 显存给出 int8 与 bf16 的搭配建议。读完你能明白该从哪一档开始,如何在显存有限时把一次文生图稳稳跑通。

— 此摘要由AI分析文章内容生成，仅供参考。

很多人装好 ComfyUI 后第一反应就是加载最高精度权重，结果一点生成就 OOM（显存溢出），白等半天还得重启。Qwen Image 2.1 这个来自阿里 Qwen 团队的开源文生图模型其实给了两条路：精度更高的 bf16，和显存减半的 int8。它一个模型同时覆盖文生图和指令编辑，原生支持 2K 输出和 PNG 透明背景（据 ComfyUI 官方文档，查阅时间 2026-10-11）。这篇就按下载放置、节点连接、分辨率与步数、bf16 与 int8 对比、透明背景排错的顺序，带你按自己的显存把一次文生图跑通。

先搞清楚要下载哪几个文件

Qwen Image 2.1 的文生图工作流不是单一文件，它由三个组件拼起来：扩散模型（diffusion model）、文本编码器（text encoder）和 VAE。每个组件又分 int8 和 bf16 两种精度，这正是显存取舍的核心。

根据 Comfy-Org 在 Hugging Face 上的发布，以及社区实测仓库记录的文件大小（查阅时间 2026-10-11），常用权重如下：

组件	int8 版本	bf16 版本	大致体积
扩散模型	`qwen_image_2.1_int8_convrot.safetensors`	`qwen_image_2.1_bf16.safetensors`	int8 约 6.76 GB / bf16 约 13.25 GB
文本编码器	`qwen3vl_8b_int8_convrot.safetensors`	`qwen3vl_8b_bf16.safetensors`	int8 显存更低
VAE	`qwen_image_2.1_vae_bf16.safetensors`	（通用）	体积小，不用纠结精度

这里要点出一个容易被忽略的事实：官方模板默认加载的就是 int8 扩散模型加 int8 文本编码器（据 ComfyUI 官方文档）。换句话说，int8 不是"低配妥协版"，而是被当成普通 ComfyUI 用户的标准起点。第一次装没必要从最高精度开始，先用 int8 跑通，再按需升级。

下载后按组件分别放进对应目录：

ComfyUI/
└── models/
    ├── diffusion_models/   # 放 qwen_image_2.1_*.safetensors
    ├── text_encoders/      # 放 qwen3vl_8b_*.safetensors
    └── vae/                # 放 qwen_image_2.1_vae_bf16.safetensors

VAE 只有一个 bf16 版本，体积小，不参与显存博弈，无脑放进去即可。真正要在 int8 和 bf16 之间二选一的，是扩散模型和文本编码器。

节点连接：先更新 ComfyUI，再加载模板

装好模型别急着连线。如果你导入 Qwen Image 2.1 的官方工作流后，看到提示缺少 TextEncodeQwenImage21、QwenImage21Cache 之类的核心节点，正确做法不是去 Manager 搜第三方节点，而是先更新 ComfyUI 本体（据 YOLO LAB 部署教程，查阅时间 2026-10-11）。因为 Qwen Image 2.1 是 ComfyUI 原生支持的，这些节点随核心版本一起发布，第三方包反而容易冲突。

更新完成后，从 ComfyUI 的模板库直接调出 Qwen Image 2.1 的文生图（text-to-image）工作流。原生工作流会自动把节点连好，核心链路大致是：

扩散模型加载节点读取 diffusion_models/ 里的权重
文本编码节点读取 text_encoders/ 里的 qwen3vl 编码器，把你的提示词转成条件
采样器（KSampler）接收扩散模型和编码后的正负提示词，执行去噪
VAE 解码节点把潜空间结果转成图像
保存节点输出 PNG

如果你是手动搭建，关键是别把文本编码器和扩散模型的精度搞混——两者是独立加载的，可以一个 int8 一个 bf16 混搭。文本编码器主要在"编码提示词"阶段工作，扩散模型则在"采样去噪"阶段工作，二者的显存占用是分时的，这给了混搭优化的空间。

工作流里还有一个实验性的 KV cache 节点（Qwen Image 2.1 Cache），它在采样步之间缓存文本和参考前缀。它暴露两个控制项（据 ComfyUI 官方文档）：

控制项	可选值	作用
`device`	`auto`（默认）、`gpu`、`cpu`、`off`	`auto` 先用空闲显存再用内存；`cpu` 走内存、几乎不损速度；`off` 每步重算，最慢但适合调试时排除缓存干扰
`dtype`	`default`（默认）、`int8`、`int4`	缓存存储精度，`default` 无损；`int8` 缓存减半、精度接近 bf16；`int4` 再减一半但每步误差大约翻倍

文生图默认模板的设置对大多数配置都够用，刚上手不用动它。

分辨率与采样步数：从默认值开始

Qwen Image 2.1 的文生图工作流默认参数是 25 步、1024×1024（据 brief 核验的模型设定）。这组默认值是比较稳妥的起点，建议第一次生成就用它验证整条链路通不通，别一上来就拉满。

分辨率上，这个模型原生支持 2K 输出，但 2K 的显存和时间开销明显高于 1024。实际策略是：

先用 1024×1024 跑通并调好提示词，确认画面方向正确
需要高分辨率成片时，再把宽高改到 2K 档位重新生成，或走后续放大

采样步数 25 步是质量和速度的平衡点。想更快出草图可以降到 15–20 步看构图，定稿再回到 25 步甚至略高。但步数不是越高越好，边际收益会递减，盲目堆到 50 步往往只是浪费时间。

bf16 与 int8：显存减半，画质差多少

这是本文最核心的取舍。先说结论：对 Qwen Image 2.1 这类图像生成模型，int8 量化后的画质损失在大多数场景下肉眼几乎看不出来，但显存直接砍半（据社区实测文章，查阅时间 2026-10-11）。扩散模型从 bf16 的约 13.25 GB 降到 int8 的约 6.76 GB，差不多就是一半。

那什么时候才值得上 bf16？简单说，当你显存和系统内存都很充足、又追求极致细节一致性时，可以把扩散模型或文本编码器单独换回 bf16。但没必要两个组件同时全上 bf16——那样显存压力会陡增。

结合社区整理的部署策略，可以按显存条件对号入座（据 YOLO LAB 部署教程）：

GPU 显存	建议起点
16GB	int8 扩散 + int8 编码器，1024 分辨率，Batch 1，必要时开 offload（分流到内存）
24GB	int8 路线更宽裕，可以开始测更高分辨率和多参考图
32GB（如 RTX 5090）	先用 int8 建立稳定基线，再逐项把扩散模型或文本编码器升到 bf16；注意 32GB 不代表双 bf16 权重加全部激活、缓存都能永久常驻
多 GPU / 服务器	再考虑 bf16 全精度与并行方案

还有一点关于 FP8 的提醒：FP8 需要较新显卡架构支持（如 40 系及以后），16GB 的 30 系卡基本用不上（据社区实测文章）。所以 30 系用户别去纠结 FP8，int8 就是你的主力路线。

最重要的一句话是：模型文件没必要全部同时永久塞进显存。文本编码器主要在编码阶段工作，扩散模型在采样阶段工作，二者分时占用显存。这意味着即便显存不算特别大，靠 int8 加合理的 offload，也能把这个模型跑起来。

透明背景保存与常见排错

Qwen Image 2.1 支持 PNG 透明背景输出，但很多人第一次保存时发现背景是白的或黑的，没有真正的透明通道。排查从这几个方向入手：

确认保存节点输出的是带 Alpha 通道的 PNG，而不是 JPG。JPG 根本不支持透明，格式选错就不可能有透明背景。
检查工作流里是否正确接入了带透明处理的输出链路。如果用的是普通 VAE 解码加标准保存，透明信息可能在中途丢失，需要用模板里针对透明背景的节点配置。
提示词里明确要求透明/无背景的主体，有助于模型生成干净的边缘。

其它高频报错和应对：

加载工作流提示缺少 TextEncodeQwenImage21 等节点：优先更新 ComfyUI 核心，别装第三方节点。
一生成就 OOM：先确认用的是 int8 而非 bf16，再把分辨率降回 1024、Batch 设为 1，仍不够就开 offload 把部分权重分流到内存。
画面出诡异色块或崩坏，怀疑是缓存问题：把 KV cache 节点的 device 临时设成 off，让它每步重算以排除缓存干扰，确认后再切回 auto。
内存（RAM）而非显存爆掉：注意 offload 和 cache 的 cpu 模式都会吃系统内存，内存小的机器要留意。

跑完一次之后往哪调

按上面步骤，你应该已经用 int8 组合在 1024×1024、25 步下跑出了第一张图。验证成功的标志是：没有 OOM，输出的 PNG 符合提示词方向，需要透明时背景确实透明。

接下来的调整方向很清晰：画面方向对了但细节不够，先在 int8 下把分辨率推到 2K 看效果；如果显存还有富余且追求更高一致性，再单独把文本编码器或扩散模型换成 bf16，一次只换一个，对比前后再决定值不值。显存紧张就反过来，保持 int8、善用 offload，把稳定出图放在第一位。先跑通，再优化，这是本地部署最省时间的路径。