Qwen-Image 与 FLUX 显存对比：22GB 卡跑 1024 实测

结论放前面：22GB 显存上跑 1024×1024，Qwen-Image 2.1 需要 79 秒、峰值 22.4GB，只剩 96MB 余量；FLUX3 Klein 只要 13.3 秒、峰值 11.7GB，还空着 10GB。要速度和批量出图选 FLUX，要图里放中文选 Qwen。下面每一个数字都是这台机器上跑出来的。

测试条件：一条提示词、一个种子、四档分辨率

机器是 RTX 2080 Ti 22GB，nvidia-smi 报 22528MB。系统 Windows，ComfyUI 0.43.0，PyTorch 2.10.0+cu130。采样器统一 euler，调度器 simple，种子固定 20261107，两个模型每个分辨率都跑 20 步。

提示词只有一条，内容是咖啡馆吧台上的一块手写木牌特写，牌面文字指定为 今日特调 冰美式 18 元，右侧一杯加冰美式，暖黄吊灯做虚化背景。挑这条是因为它同时压住两件事：中文文字渲染准不准，细节质感够不够。

量化档位都取现成能跑的组合。Qwen 侧用 qwen_image_2.1_int8_convrot 配 qwen3vl_8b_int8_convrot，VAE 挂 qwen_image_2.1_vae_bf16。FLUX 侧用 flux3_image_klein_int8_convrot，CLIP 只能用哈希命名那个文件，type 选 flux3，VAE 挂 flux2-vae。

显存不是从日志里读的。每次提交前记一次 system_stats 的 vram_free，生成过程中每 0.35 秒再采一次，取整个区间的最小值换算成峰值。ComfyUI 本身不打印峰值显存，任务管理器给的是驱动估算值，两者差得很远。

四档分辨率的耗时与峰值显存

下面的耗时是模型已经在显存里的第二次及以后，第一次要算上读盘时间，另外单列。

FLUX 那一侧几乎线性，从 512 到 1280 峰值只涨 1.2GB，耗时涨 5 倍但绝对值仍然小。这类曲线好预测，加分辨率就是加时间，不会突然撞墙。

Qwen 到 1024 就顶住了。22.4GB 占掉 22GB 卡的全部余量，只剩 96MB，这个数字我复测三次都是 96MB 上下。96MB 是什么概念，浏览器硬件加速、录屏、另一个进程的显存池都能随随便便吃掉几倍于它的量。

1280 那一行的峰值回落要单独解释，见第五节，那不是好消息。分辨率与耗时的关系可以对照站内另一篇 BindWeave 在 ComfyUI 上的部署实测，同样是 DiT 架构，同样的平方级增长。

16.4GB 与 10.8GB：常驻占用才是分水岭

把模型全部卸载再测基线：22528MB 的卡上空载只剩 21260MB 可用，系统与显示占掉 1268MB。然后加载 Qwen 那一组权重，只跑一张 256×256 两步的图，峰值就到了 16.4GB。

这意味着三件套躺在显存里就吃掉 16.4GB，还没开始算 1024 的激活开销。FLUX 同条件只有 10.8GB，两者差 5.6GB，这 5.6GB 直接决定了 22GB 卡上 Qwen 能不能上 1024。

冷启动加载耗时的差距同样明显，Qwen 134.7 秒，FLUX 44.0 秒。换模型试效果的场景里，这个差距比出图速度更折磨人。想省下来只有一条路，让模型常驻别反复卸载，代价是显存一直被占着。

顺带说一句，Qwen-Image 2.1 刚开源时站内写过一篇 Qwen-Image-2.1 的参数与生态拆解，当时提到更小显存占用，现在有了具体数字：7B 的视觉主干确实不大，真正吃显存的是那个 8B 级文本编码器。

CFG 与步数的账：79 秒里有多少是白跑的

Qwen 的默认 cfg 是 2.5，FLUX3 Klein 是蒸馏模型，cfg 固定 1.0。cfg 大于 1 时每一步要跑两次前向，一次带条件一次空条件，所以同样 20 步，Qwen 实际做了 40 次前向。

实测把这个差值抠出来了。同分辨率 1024、同 20 步，把 cfg 从 2.5 压到 1.0，耗时从 78.6 秒掉到 40.3 秒，比值 1.95，和理论上的 2 倍对得上。

代价是画面散掉。cfg 1.0 下 Qwen 的构图明显松，牌面文字也不再稳定复现。这一档只能用来估算速度上限，不能拿来出片。

步数同样线性。1024 分辨率、cfg 2.5 保持不动，20 步 78.6 秒，8 步 32.4 秒，比值 0.41，跟 8 除以 20 得到的 0.4 几乎一致。所以想把 Qwen 的 1024 压进 40 秒，可行的办法只有降步数到 8 步左右，cfg 不能动，动了就不出正经图。

1024 之后峰值反而回落，别当成好消息

Qwen 从 1024 到 1280，峰值从 22.4GB 掉到 15.9GB，耗时从 79 秒涨到 164.7 秒。看到余量变大就以为能上更高分辨率，这是最容易踩的误判。

真实原因是文本编码器在采样开始前被换出了。那 8GB 级的编码器只在前处理阶段用一次，用完就被 ComfyUI 让出去，8.7GB 的空间转给激活使用，于是峰值看起来降了，重新调度的开销全摊在时间上。

有个简单的判据：峰值下降而耗时上升，基本就是发生了换出。真正宽裕的档位一定是峰值和耗时同时可控，比如 FLUX 在 1024 那一行，11.7GB 配 13.3 秒。

这条也解释了社区里一个常见困惑，为什么有人报 1280 只占 15GB 有人说占了 22GB。两个人测的可能都是真的，差别在于他们是全新加载后第一次跑，还是模型已经被换进换出过几轮。

中文文字渲染：同种子单张对比

同一条提示词、同一个种子、都是 1024×1024，各出一张。

Qwen 那张牌面三行全部正确，今日特调、冰美式、18 元，笔画完整，粉笔质感也保住了，木纹与杯壁水珠的细节同样在线。

FLUX3 Klein 那张整体更接近商业摄影，光线更干净，但牌面出现替代字：式 写成了 弐，日 的横笔多了一道，接近 目。远看能读通，近看就是错字。

结论很直接。要往图里放中文、放价格牌、放海报标题，Qwen 这一档目前没有可替代的本地方案。要纯画面质感和速度，FLUX3 Klein 的性价比高得多。

需要说清楚的是，这只是一张样本，只能说明这一次的表现，不代表稳定的错字率。要下定论得多跑几十张做统计，这个活本轮没做。

按显存档位选：从实测推出来的分档表

把上面的常驻占用和激活增量拼起来，能反推不同显存档位能跑到什么分辨率。22GB 那一行是实测，其余是按常驻加激活推的上限，没上真机验证，只能当参考。

8GB 那一行给不出具体数字，因为两套权重加载后都超过 10GB，光常驻就装不下，再谈分辨率没有意义。这个档位必须换量化格式，而我这台机器上只有 int8 与 bf16 两档，没有实测依据就不写数。

如果显存吃紧又想本地跑，站内那篇 本地模型接 Ollama 踩的上下文坑 里的排查顺序同样适用，先量基线、再看常驻、最后才调分辨率。

在自己机器上复现这套测量

ComfyUI 默认端口 8188，把下面三条走一遍就能拿到自己的数字。先卸载模型拿干净基线，这个接口返回空 body，解析 JSON 会报错，属正常。

curl -s -X POST http://127.0.0.1:8188/free \
  -H "Content-Type: application/json" \
  -d '{"unload_models":true,"free_memory":true}'

然后读一次显存，记下 vram_total 与 vram_free。生成过程中要反复读这一个接口，取最小值，不能只看首尾两次。

curl -s http://127.0.0.1:8188/system_stats \
 | python3 -c "import sys,json;d=json.load(sys.stdin)['devices'][0];print(d['vram_total'],d['vram_free'])"

提交任务用同一份 workflow 导出的 API 格式 JSON，改宽高和步数即可重跑。峰值换成 GB 用总显存减去最小空闲，再除以 1048576。

这套方法的价值在于可比。同一台机器、同一个种子、同一段采样间隔，换一个参数再跑，差值就是那个参数的真实成本。转述别人的数字永远做不到这一步，因为对方的基线里可能还躺着别的模型。

三个容易踩的坑

第一个是拿冷启动数据当性能。512 那一档我记到 134.6 秒，其中约 122 秒在读 16GB 权重，真正出图只有 12.3 秒。很多人第一次试新模型觉得慢到不能用，就是这个原因，第二次跑同一个配置会快一个数量级。

第二个是加载过程中的 vram_free 不能信。模型正在从磁盘往显存里搬，读到的是碎片化的中间态，数值会虚高。要等 history 里出现结果、进程空闲两秒之后再读，否则测出来的余量偏乐观。

第三个是 FLUX3 Klein 的 CLIP 文件名。下拉框里会出现多个同名副本，只有一个能用，选错的表现是模型加载成功但编码器报维度不匹配。这个坑站内另一篇 ComfyUI 装 FLUX 模型的损坏文件排查 里有完整的定位路径，不再重复。

常见问题

22GB 显存跑 Qwen-Image 2.1，最高能出多大图？
1280×1280 实测能跑完，单张 164.7 秒。日常可用档是 768×768，33.1 秒、峰值 21.6GB。1024×1024 虽然出得来，但峰值 22.4GB 只剩 96MB，后台开个吃显存的程序就可能直接 OOM。

只有 12GB 显卡，这两个还能用吗？
FLUX3 Klein 能用，768×768 峰值 11.3GB，1024×1024 的 11.7GB 属于极限。Qwen-Image 2.1 的 int8 组合光加载就要 16.4GB，12GB 卡跑不起来，必须换更小的文本编码器或 GGUF 量化档。

为什么 Qwen 比 FLUX 慢将近六倍？
两部分叠加。cfg 2.5 让每一步跑两次前向，实测把 cfg 降到 1.0，时间从 78.6 秒变 40.3 秒，正好一半。剩下的是模型本身的差异，FLUX3 Klein 是蒸馏模型，20 步里有大量冗余，13.3 秒就收敛。