Qwen-Image-2.1 发布后,我在本地前前后后跑了三轮测试。第一轮是最朴素的"默认参数直接跑",结果在 4090 上都给我弹了 CUDA out of memory;第二轮改成 fp8 加各种 offload,总算能出图,但速度和稳定性还是怪怪的;到了第三轮,也就是这次,我把--lowvram这个参数单独拎出来做了对照,顺手把 Qwen-Image-2.1 和几个主流开源模型拉上擂台比了一遍。

这篇文章其实就是第三轮的测试笔记。主要回答三个问题:第一,--lowvram到底在干什么,什么时候该开、什么时候开了反而亏;第二,这个 20B 级别的模型和 FLUX.1-dev、SD3.5 Large、SDXL 放在一起,到底强在哪、弱在哪;第三,结合最近大家都在搜的 GGUF 量化、ComfyUI 整合包、Mac 本地部署,给出一份能直接照着抄的部署方案。

不管你是刚把 ComfyUI 装好的新手,还是已经跑过几个模型的熟手,下面这些数据和坑,基本都能对上号。

1. 测试环境与三轮测试的背景

1.1 手头的设备与部署基线

先交代一下环境,免得后面数据没有参考系:

• 主力机:RTX 4090 24GB,内存 128GB,系统 Ubuntu 22.04
• 第二台:RTX 3060 12GB,内存 64GB,Windows 11
• 备用机:Mac mini M2 Pro,32GB 统一内存

部署方式以 ComfyUI 为主,部分数据用 diffusers 的 Python API 复测过一遍。模型本体是 20B 参数的 DiT 架构,配套的文本编码器是 Qwen2.5-3B,整体走的是 flow matching 那套生成范式,这一点和 FLUX 同源,所以采样器选择上有不少共通的地方。

这里有个前提要先说清楚:20B 参数模型在 bf16 精度下,光权重就接近 40GB,这已经超出了绝大多数家用显卡的显存。所以本地跑的方案其实就两条路——要么上量化(FP8 或 GGUF 的 INT4/INT5),要么老老实实开 offload。--lowvram就是后面这条路的核心开关。

1.2 前两轮踩过的坑,这轮要解决什么问题

第一轮测试我几乎没做任何优化,直接默认精度去跑。结果 4090 上 1024x1024 都会爆显存,不是一闪而过的报错,是那种生成到一半直接崩溃、ComfyUI 整个卡死的状态。那一轮我基本没产出任何有效对比图,全在跟 OOM 搏斗。

第二轮我做了三件事:换 FP8 权重、开 VAE tiling、加上模型 CPU offload。能出图了,但当时经验不足,offload 开得过于激进,导致一张图要等很久,而且我注意到在 4090 这种级别的卡上,盲目开 offload 反而把本来能塞进显存的数据也丢到内存里来回搬运,属于自己给自己找麻烦。

所以第三轮我把重点放在了"--lowvram该不该用"这个具体问题上:什么显存规模开、什么显存规模不开、开了之后速度损失到底有多大,顺带用同一组提示词把 Qwen-Image-2.1 和 FLUX.1-dev、SD3.5 Large、SDXL 拉出来做横向对比。这篇记录的就是这一轮的结果。

2. --lowvram 到底干了什么,该不该开

2.1 它改变的不是画质,是显存策略

--lowvram不是滤镜,不是采样器,不影响你最后出图的画质和风格。它只做一件事:改变模型在显存里的存放策略。

默认情况下,推理框架会把模型权重一次性全部塞进显存,塞得下就正常跑,塞不下直接 OOM。开了--lowvram之后,框架会把模型拆成若干块,每一块用之前才从内存搬运到显存,算完这一块后又释放掉,腾出空间给下一块。整个过程是自动的,不需要你手动干预。

用一个生活化的比喻:默认模式是"把所有菜一次端上灶台",好处是手边什么都有,做菜一气呵成;坏处是灶台不够大,菜一多就摆不下。--lowvram是"做一道菜从冰箱拿一次食材",灶台永远不挤,但你来回开冰箱的次数多了,总时长自然变长。

需要注意,很多框架里的--lowvram和--medvram是两档位:中档只把次要模块(比如文本编码器、VAE)挪出显存,主力模型仍然留在 GPU 上;低档则是连主力模型都分块搬运。对于 Qwen-Image-2.1 这种大模型,我们讨论的基本都是低档位,也就是真正意义上的分块 offload。

2.2 三组实测数据,直接看结论

我以 1024x1024、20 步、同一提示词为基准,在 4090 和 3060 上分别测了不开--lowvram和开启后的表现。采样器统一 Euler,CFG 4,精度 FP8。

这组数据能读出几件事:

第一,4090 不开--lowvram其实是能跑的,显存占用 22.5G 已经非常贴近 24G 的上限。这时候系统里只要有一点其他开销——比如浏览器、另一个 ComfyUI 工作流、甚至显存频率波动——就容易踩线。所以我的结论是:4090 上可以不开,但只适合"专心只跑一个任务"的场景。

第二,3060 12G 不开必崩,开了之后能用,但 130 秒一张图的体验,说实话比较煎熬。同样是 3060,换成 GGUF Q5 量化之后,显存占用降到 6.8G,速度反而提升到 95 秒。这说明在小显存卡上,"量化 + 轻量 offload"才是正解,单纯依赖--lowvram只能保底,谈不上好用。

第三,--lowvram带来的速度损失,在 4090 上大约是 47%,在 3060 上因为不得不开,就没有对比意义。这个损耗比例跟模型的参数量、显存带宽强相关,模型越大、带宽越吃紧,搬运成本就越高。

2.3 我的判断标准:一张表说清楚

把镜头拉远一点,不用死磕具体数值,直接按显存档位给结论:

补充一个很多人忽略的点:开了--lowvram之后,显存虽然省了,但内存(RAM)占用会大幅上升,因为模型分块在内存和显存之间搬运。建议系统内存至少 32GB,64GB 更舒服。我 4090 那台是 128GB 内存,开--lowvram后峰值能占到 30GB 左右,如果只有 16GB 内存,很可能在显存之前先被内存卡死。

所以回到题目:"--lowvram该不该用?"我的答案是:它是保命开关,不是性能开关。显存富裕时开了亏,显存紧张时不开崩。真正想在小卡上舒服地跑,重点应该放在量化上。

3. 多模型横向对比:Qwen-Image-2.1 的真实水平

3.1 控制变量:怎么比才公平

这轮对比我选了三个对手:FLUX.1-dev、SD3.5 Large、SDXL。选择标准很简单——都是目前开源社区里讨论度最高的文生图模型,而且覆盖了从 3.5B 到 20B 的参数量级。

为了让结果尽量公平,我做了这些约定:

• 统一分辨率 1024x1024,统一固定随机种子
• 每个模型用官方推荐的步数和 CFG:SDXL 用 30 步、CFG 6,FLUX.1-dev 用 25 步、CFG 3.5,SD3.5 Large 用 30 步、CFG 4.5,Qwen-Image-2.1 用 24 步、CFG 4
• 同一组提示词,我用中文写,让 FLUX 和 SDXL 不擅长中文的弱点如实体现在结果里
• 对比维度:提示词理解、中文文字渲染、构图细节、生成速度、显存需求

提示词正文是:老式茶馆木质招牌上写着"福来茶馆",夜晚灯光昏黄温暖,招牌边缘有少量青苔,电影感光影,柔和景深。

3.2 中文与复杂提示词专项

这一轮基本是 Qwen 的主场,结果也很清楚:

• Qwen-Image-2.1:招牌上"福来茶馆"四个字一字不差,字型和背景的氛围融合得不错,青苔、灯光、电影感这些关键词都体现在画面里。提示词里的多个限定条件基本全覆盖。
• FLUX.1-dev:画面构图、光影非常稳,但招牌上的字变成了类似繁体中文的乱码,能看出"像字"但不是一个可读的词语。中文理解是硬伤。
• SD3.5 Large:整体构图尚可,文字全部乱码,而且"青苔"这个元素基本漏掉了。
• SDXL:构图偏平,氛围弱,文字乱码,对"电影感"的还原最差。

这里给一个判断:如果你工作流里带中文文字——电商海报、店铺招牌、菜单、书名封面,那 Qwen-Image-2.1 基本是当前开源模型里唯一能打的选择。FLUX 系列即使用了各种 LoRA 和细节增强手段,中文字形的稳定性和准确率也还是追不上原生支持中文的 Qwen。

3.3 画质、细节与速度账本

文字专项之外,我还测了纯画面场景,提示词是:雨后江南石板小巷,一个穿红色连衣裙的女孩背影,撑着油纸伞,湿润地面有倒影。

画质细节方面,Qwen-Image-2.1 和 FLUX.1-dev 属于同一梯队,人物姿势、手部结构、雨天地面反光都处理得比较自然;SD3.5 Large 画面干净,但细节层次偏薄;SDXL 在 1024 分辨率下已经明显露出上限,细节偏塑料,光影关系也平。

在复杂光源和语义堆叠的场景上(比如同时要求"逆光""潮湿""景深""电影感"),Qwen-Image-2.1 对多个条件的组合保持得最好,很少出现"顾此失彼"。FLUX 偶尔会在注意力分配上失衡,比如把"青苔"和"石板"混成一团。

速度与显存的账本,放到同一张表里看更直观:

注意比较的是 4090 不开--lowvram的数据。Qwen-Image-2.1 虽然参数量最大,但耗时没有超出 FLUX 太多,主要得益于 DiT 架构和 flow matching 的收敛特性,20 步左右就能出不错的画面,而 FLUX.1-dev 官方建议是 25 到 50 步。

综合下来我的感受:这几类模型现在是错位竞争的。Qwen-Image-2.1 赢在中文原生支持、复杂提示词组合能力和综合画质;FLUX.1-dev 赢在生态成熟、LoRA/ControlNet 配套多、英文风格化效果好;SDXL 则因为轻量、吃配置低,在小显存场景里依然是"最不折腾"的选择。别问"谁最好",问"你的场景里谁会最省事"。

4. 本地部署的实战补充:GGUF、ComfyUI 整合包与 Mac

光聊参数和对比还不够,最近社区里搜得最多的三个部署相关话题,我也都实测了一遍,直接汇报结果。

4.1 ComfyUI 整合包:适合不想碰代码的人

"Qwen-Image-2.1 ComfyUI 整合包"确实是近期搜索量很高的词。所谓整合包,就是把 ComfyUI 主体、模型权重、自定义节点、依赖环境全部打包成一个解压即用的文件夹,省去配环境的痛苦。

实测下来的结论是:整合包确实能开箱即用,但要注意三点。

第一,确认整合包内置的是否为 FP8 权重。有些整合包为了控制体积放的是完整 bf16 权重,在 12G 卡上照样 OOM,你会误以为自己装坏了。

第二,节点版本必须匹配。Qwen-Image 系列对 ComfyUI 核心版本有要求,老版本核心会加载失败或者出图偏灰。装好后第一件事是看节点管理器里有没有可更新的组件,别直接用旧版跑新模型。

第三,不要同时在整合包里堆太多模型。很多人拿到整合包之后顺手把 FLUX、SDXL 全塞进去,启动时 ComfyUI 会尝试缓存模型元信息,塞多了启动反而变慢,甚至崩溃。一个包装一套模型是最省心的用法。

4.2 GGUF 量化:小显存和小内存的救星

GGUF 本来是大语言模型社区常用的量化格式,现在图像模型也全面接入了。原理就是把 20B 参数的权重按 4bit 或 5bit 量化,体积直接缩到原来的三分之一左右。Qwen-Image-2.1 的 GGUF 量化版,在 ComfyUI 里配合专门的 GGUF loader 节点使用。

我实测的 GGUF Q5 版本,在 3060 12G 上的表现是:显存峰值 6.8G,单张 1024x1024 约 95 秒,画质和 FP8 版本肉眼看差距不大,只有放大到细节纹理时能感觉到轻微糊。Q4 版本还能再快一点点,但画面锐度下降就明显了,文字边缘也会开始发虚。

如果你是 8G 或 10G 显存的卡,又不想降低分辨率,强烈建议先从 GGUF 量化版入手。这比硬开--lowvram的体验好得多,因为量化减少的是模型体积,不是搬运次数,速度收益是实打实的。

另外提一句:GGUF 的加载节点和原版模型加载器的使用方式略有差异,注意看节点描述,别把 GGUF 文件直接接到普通加载器上,那样只会报错。

4.3 Mac 本地部署:能跑但要想清楚

"Mac 如何本地部署 Qwen-Image-2.1"最近问的人也不少。核心结论:能跑,但不是所有 Mac 都值得跑。

Mac 没有独立显卡,但它有"统一内存",M 系列芯片的 CPU 和 GPU 共享同一块内存池。对 Qwen-Image-2.1 这种大模型来说,统一内存反而成了优势,因为你可以直接把 20B 权重放进内存,不需要像独显那样频繁搬运。

我在 Mac mini M2 Pro 32G 上实测:用 FP8 权重,1280x1280 分辨率,一张图需要 3 到 6 分钟。注意,是分钟,不是秒。M2 Pro 的 GPU 规模摆在那里,指望它跟 4090 比速度不现实,但如果你的需求是"偶尔出一张图,不想开电脑不想上云",这个速度可以接受。

门槛是这样的:16G 统一内存的机器建议直接放弃,跑起来会非常吃力,而且系统会频繁将内存交换到硬盘,严重影响整机流畅度;32G 是起步线,64G 会比较舒服。

部署方式上,ComfyUI 在 Mac 上要用 MPS 后端,安装时注意 PyTorch 的 MPS 版本支持,别装成 CPU-only 版本。另外,Mac 上不要开--lowvram,这套参数主要是针对显存和内存分离的架构设计的,在统一内存模型下反而会引入无谓的搬运开销。

5. 高频问题与排查实录

这几天测试过程中,我自己踩坑加上看社区提问,把出现频率最高的几个问题和排查思路整理成一张速查表,希望能帮你少走弯路。

5.1 OOM 的排查顺序

"CUDA out of memory"是出现频率最高的报错,大部分人在 12G 和 8G 卡上跑 Qwen-Image-2.1 都会遇到。排查顺序建议:

1. 先确认权重精度。bf16 直接换 FP8,显存需求立减一半。
2. 再降分辨率。从 1024x1024 降到 768x768,激活值占用能降一个量级。
3. 然后开 VAE tiling 和 attention slicing,这两个开关不影响模型权重大小,但能大幅降低计算中间值的显存占用。
4. 最后再考虑--lowvram或 GGUF 量化。注意,顺序很重要,很多人一上来就开--lowvram,结果速度损失很大,其实前面几步已经把问题解决了大半。

5.2 出图异常(灰图、噪点、花屏)

生成出来一片灰或者全是噪点的,八成不是显存问题,是 VAE 或精度问题。

最常见的原因是 VAE 文件缺失或不匹配。Qwen-Image 系列的 VAE 是官方专属版本,不能用 SDXL 的 VAE 替代,也不能缺了直接跑。在你看来是"模型生成能力差",实际上是后处理环节没接对。

其次是 dtype 不一致。文本编码器、DiT 主模型、VAE 三者的精度建议保持一致,混用 fp16 和 fp32 容易在部分节点上出现数值溢出,表现就是出图偏灰、颜色发闷。这种情况把三个模块的精度统一成 fp16 或 bf16 就能解决。

5.3 速度异常慢

如果你的卡显存够大,但生成速度明显低于同配置的人,先别急着怀疑硬件。检查一下是否无意中开了某些 offload 选项。很多框架的 offload 是自动的,显存接近上限时自动启用,一旦启用,速度就会掉一截。

另外,检查采样器。flow matching 模型的采样器和传统扩散模型不一样,用错采样器可能导致步数增加但收敛变慢。Qwen-Image-2.1 建议优先用 Euler 或 DPM++ 2M 的 flow 变体,CFG 控制在 3 到 4.5 之间,步数 20 到 30 就够了。超过 30 步,画质收益非常小,纯粹浪费时间。

5.4 下载与安装的琐碎问题

模型下载如果你访问国外站点慢,除了社区网盘分享之外,还有一个更稳定的办法是走国内模型平台,阿里自家的 ModelScope 上就有官方权重和量化版,下载速度比从国外站点拉要快得多。下载时注意核对 SHA256,别贪图省事随便找个网盘转压包,那可能是旧版甚至被改过的权重,出问题排查起来非常痛苦。

另外一个安装细节:整个 ComfyUI 路径和模型路径上不要出现中文和特殊符号。Windows 机器上尤其容易踩,路径一旦有问题,加载时会报一些莫名其妙的文件错误,和模型本身没有任何关系。

6. 最后说两句实际使用的体会

三轮测下来,我对 Qwen-Image-2.1 和--lowvram的判断已经比较明确了。

--lowvram对我来说更像是一个"心理安全开关"。技术上说,它的本质是拿时间换空间,该用的时候能救命,不该用的时候开了就是纯亏。但在实际使用中,我反而觉得它的最大价值是让你敢于把显存同时分给多个任务——开着它,我可以一边跑 Qwen 出图,一边在另一个工作流里做 FLUX 的放大或 LoRA 测试,互相不打架。这种"多任务并行"的收益,往往比单张图省下的几十秒更重要。

所以最后的个人建议是:大显存用户不要把--lowvram当成禁区,小显存用户也不要把--lowvram当成唯一出路。它的正确位置是"方案组合里的一环",和量化、分辨率控制、VAE tiling 配合着用,而不是单兵作战。

至于模型对比,我的口径一直是:选模型不是选参数最多的那个,是选最适配你日常需求的。如果你的出图场景离不开中文文字,或者你习惯用长中文提示词描述画面,Qwen-Image-2.1 是当前开源模型里的最优解;如果你主要做英文艺术风格图,FLUX 生态的周边工具会让你更顺手。

下一步我打算试试给 Qwen-Image-2.1 训练 LoRA,重点看看它对特定风格和特定物体的适配速度。到时候如果测出了值得写的东西,再回来更新。