五大AI绘图模型横评：从扩散模型原理到本地部署避坑指南

最近这波AI绘图模型的迭代速度快得离谱，前脚刚把FLUX.1的工作流调顺手，后脚FLUX.2、Z-image、Qwen-Image、GLM-Image这些名字就一起涌上来；再加上国内即梦背后的Seedream一直被大家拿来跟开源模型对比，一时间好多人都被绕晕了。这篇文章我想把自己这段时间整理的核心知识、实测心得和踩坑记录写下来，不光是告诉你这五个模型分别是谁，更重要的是帮你理清：它们各自擅长什么、部署的时候要注意什么、为什么同样的提示词在不同模型里出图结果会差这么多。如果你正准备入坑AI绘图，或者已经想用这些模型搭自己的工作流，这篇文章应该能帮你省掉不少瞎折腾的时间。

1. 五个模型怎么来的：先看懂这张牌桌

1.1 为什么短短半年冒出这么多图像生成模型

其实一年多以前，本地绘图生态还被SD系列和Midjourney二分天下，大家讨论最多的是“这个模型手画得对不对”“写实风格够不够真”。但从今年开始，情况明显变了：一方面，扩散模型底层的框架越来越统一，DiT（Diffusion Transformer）和Rectified Flow逐渐成了主流，很多团队不再需要从零造轮子，而是可以把大语言模型、多模态编码器和图像生成器直接拼起来；另一方面，中文语义理解成了新的竞争点，因为英文模型在处理中文长提示词时经常“听不懂”或者把中文文字画成乱码。

所以你会发现，这波模型几乎都是“大厂开源+产品化收口”的组合拳：阿里拿出了Qwen-Image，智谱推出了GLM-Image，字节的即梦背后是Seedream，黑森林实验室继续迭代FLUX系列，还有一个身份比较模糊、但热度很高的开源模型Z-image。它们不是在同一个维度上做完全一样的事情，更像是在抢“谁最会用中文指令画图”和“谁最适合嵌入工作流”这两张牌。

1.2 一张速查表看懂五个模型的核心差异

先给一张我整理过很多次的对照表，信息来自各家公开资料、社区讨论和我自己的实测，版本更新很快，但大的定位不会变：

从这张表能看出来，这五个模型各有各的主场。FLUX.2更像是“画质天花板选手”，Seedream和GLM-Image更懂中文用户，Qwen-Image强在大模型理解能力，Z-image则是社区里“轻量、能跑”的另类选择。你如果非要用一个模型通吃所有场景，大概率会处处碰壁。

1.3 按场景选模型，别被评测榜牵着走

选模型最忌讳的就是只看谁的榜单分数高。我实际用下来的经验是，应该先想清楚你的目标是什么，再反过来挑工具。

如果你要的是电商海报、短视频封面，或者你手头有一堆中文商品描述要批量转成图，那Seedream和GLM-Image的优先级很高，因为它们在产品里已经把中文提示词、文字渲染、尺寸比例这些细节调过了，出图基本不用二次翻译。

如果你想要的是“一张图能看出镜头感、光影氛围、甚至欧美杂志排版质感”，FLUX.2会更合适，尤其是对英文Prompt理解非常好，但对中文要求高时你得先翻译一下再喂给它。

如果你GPU显存不大，只有6到8G，又不想花钱调API，那Z-image Turbo是目前社区里折腾成本相对低的选项，虽然画质有妥协，但它能让你在本地先把一条基础出图链路跑通。

如果你需要把图像生成塞进一个人工智能Agent里，让它能自动理解“画面左边是猫右边是狗，猫穿红色衣服”这类细节，Qwen-Image是更稳的底座，因为它的语言理解基础是千问模型，对空间位置、属性归属的把握明显强于传统文生图模型。

简单说，没有哪个模型是“神”，但有最适合你当下场景的那个。

2. 逐个拆解：五个模型的底层逻辑与技术特点

2.1 FLUX.2：把“线性去噪”这件事做到极致

FLUX.2对我来说最值得聊的不是又提高了多少分，而是它明确把Rectified Flow这条路走通了。很多刚接触的读者不理解Rectified Flow是什么意思，我用一个粗浅但生动的方式解释：传统扩散模型去噪像在雾霾天找人，每一步都只能看到模糊轮廓，走一步修正一步；Rectified Flow则是先画一条从噪声到图像的“直线”，再去让模型慢慢纠正这条直线的曲率。这样理论上需要的步数更少，生成过程也更稳定。

FLUX.2在FLUX.1的基础上强化了几个很实际的点：文字渲染更不容易出现错字漏字；人物肢体结构更自然；对大场景里的多个小物体，丢失画面元素的情况少一些。我实测下来确实能感受到，相同提示词下，FLUX.2的“镜头语言”更丰富，广角、特写、景深这些概念它都能反应在画面里。

不过它的代价也很现实：显存压力大、模型体积不小，加载速度比轻量模型慢一截。如果你用旧版本的ComfyUI节点去加载FLUX.2，大概率会报类型错误或者采样器不识别，这不是模型问题，是生态还没完全跟上。建议用新版节点，并且尽量把工作流精简，不要同时挂一堆没用的插件。

2.2 Seedream：不是单个模型，而是一套产品能力

Seedream这个词在社区里出现，基本都是跟“即梦”绑在一起。对普通用户来说，Seedream不是让你去下载一个权重然后自己跑，而是藏在即梦AI应用后面的一整套生成与编辑能力。

它的强项很明确：中文理解。很多开源模型在英文提示下表现很好，一旦换成中文长句就开始乱编，但Seedream在“画面元素由中文文本准确控制”这件事上做得很成熟。比如你写“一杯拿铁放在木质桌面上，旁边有一本打开的笔记本，笔记本上写着‘你好，世界’”，它生成的画面里，中文文字和摆放位置通常都不会离谱。

我甚至觉得，Seedream的另一个隐形优势是“产品化的边界设计”。官方把它封装成了清晰的能力接口：文生图、局部重绘、扩展画布、生成后编辑。它可能不是所有场景里画质最高的，但在“中文用户拿它干正事”这件事上，它比很多开源模型省心。如果你做的是国内社交媒体内容、商品图、短视频封面，Seedream是值得优先考虑的选择。

2.3 Z-image：身份神秘但“轻量出图”标签鲜明

Z-image可能是这五个模型里信息最“碎”的一个。我最初看到这个名字是在社区讨论里，有人分享说base版本出了黑图，有人则把Turbo版本传到网盘分流，再后来就看到Hugging Face上的权重包和相关代码仓库。我手上没有特别权威的官方技术报告，所以只能从实际工程视角来分析它。

从能拿到的文件结构看，Z-image同时提供了base和turbo两个分支。base走的是常规扩散生成路线，质量更完整但需要更多采样步数；turbo则明显做了蒸馏压缩，标称少步出图，对低显存用户特别友好。网上大家折腾得最多的也是turbo版本，因为它在4到8步之间就能出一个肉眼可看的结果，速度比FLUX.2快得多，当然细节和稳定性会打折扣。

为什么Z-image base会生成黑图？这其实是一个很好的排查案例，我会在后面的避坑部分展开。这里先给一个结论：黑图大概率不是模型“废了”，而是加载的时候精度不匹配、VAE没配好、或者采样器设置太极端。你换一个环境重新加载，往往就正常了。

2.4 Qwen-Image：用千问的脑子去画图

Qwen-Image是阿里推出的开源文生图模型，它给我的第一印象是：这不像一个单纯的“画图模型”，更像是一个把语言理解能力前置到生成流程里的多模态系统。它可以看作是把千问系列大模型对语言、视觉的理解能力，和扩散生成融合在了一起。

这意味着什么？你可以用更自然的句子描述画面。传统文生图模型比较喜欢“名词堆叠”式的提示词，比如“猫，窗户，雨，蓝调”，但Qwen-Image能吃下结构更复杂的话，像“一只橘猫蹲在窗台上往外看，窗外下着雨，背景虚化，整体色调偏冷”——它能在语义层面把主体、动作、氛围分开处理，而不是简单当关键词拼贴。

部署上，Qwen-Image同样需要比较大的显存和内存，但因为开源生态比较完善，Hugging Face上的模型卡、ComfyUI节点都在快速跟进。不少人还尝试用OpenVINO把模型转成CPU/核显可跑的格式，这个后面我会单独说。简而言之，如果你希望模型“听懂人话”而不是“猜关键词”，Qwen-Image的底座思路是目前这五个模型里最贴近大模型方向的。

2.5 GLM-Image：中文原生长板，和Agent天然契合

GLM-Image来自智谱，跟GLM语言模型是一家人。我在它身上看到最明显的特点，是“中文提示词理解的高稳定性”。过去用国外模型写中文提示词，经常被拆成一个个字来编码，结果画面出现莫名其妙的元素；GLM-Image把GLM的语言编码直接拿来做文本条件，中文句子内部的关联、否定、并列关系，它都能更好保持。

举例来说，你写“画面中不要出现红色元素，但路标除外”，很多模型会把“红色元素”和“路标”搅在一起，导致生成一个红色的路标。GLM-Image在这类复杂约束上的表现会稳定很多，因为它对“否定+例外”这样的语义结构有更强的理解能力。

另一个让我觉得它是“工作流型选手”的原因是，GLM-Image和智谱的Agent体系天然亲近。你可以很容易把它封装成一个技能模块，由语言模型规划、调用、再回来校验结果。如果你正在搭一个自动作图机器人，并且追求中文语境下的可控性，GLM-Image值得重点评估。

3. 本地部署实操：从下载权重到出第一张图

3.1 环境准备：显卡、驱动、依赖的兼容关系

在本地跑这些模型，我建议先别急着下几GB的权重，先把环境理顺。用ComfyUI是比较省心的方案，因为它对节点的管理比纯代码调用更直观，出错时也方便定位。系统层面，Windows和Linux我都在用，没有太大差别，但驱动和CUDA版本一定要对上：N卡用户建议CUDA 12.x系列，驱动尽量更新到最新稳定版，老卡强行跑新模型经常会白折腾。

内存方面，能上32G就上32G，因为模型加载时除了显存，系统内存和交换空间也容易被吃满。我看到很多人出了黑图其实是加载到一半出了资源问题，但表面看就是一张黑图。另外Python环境容易踩坑，ComfyUI自带便携版最好，不要用系统里已有的Python，否则transformers、safetensors这些库版本会乱成一锅粥。

3.2 权重下载与目录放置

不同模型下载后的放置方式不太一样。以ComfyUI为例，FLUX.2的模型权重通常放在models/diffusion_models/或models/unet/，文本编码器放在models/text_encoders/，VAE单独放在models/vae/。Qwen-Image和GLM-Image经常以完整的diffusers目录结构发布，你也可以用ComfyUI-Manager去安装对应节点，让节点自动识别文件路径。

有一点我特别想提醒：Z-image的权重文件因为体积不小，社区分流到网盘的情况很多，常见的就有“z-image turbo下载蓝奏云”这种分享帖。用网盘下载本身没问题，但下载后一定做两个检查：一是核对文件大小和SHA256哈希，防止下载到损坏文件；二是确认压缩包内是否自带VAE和文本编码器，如果只有主模型，出黑图几乎是必然的。

3.3 出图参数：这些坑我都替你踩过了

参数设置其实没有万能公式，但你至少可以按这个基准去起步。FLUX.2建议20到30步，CFG不要开太高，2到4之间比较稳，CFG开大了画面会过饱和，甚至出现“塑料感”。Z-image Turbo是例外，它主打少步出图，4到8步就够了，你别按照常规模型去跑20步，否则反而可能出现颜色崩坏。

分辨率方面，低显存用户从768×768或512×768起步，先看构图，别一上来就2K。如果你要最终输出大图，可以用“低分辨率生成+放大模型”的两段式流程，而不是直接拉高分辨率，这样既节省显存，画质也更可控。采样器我喜欢用Euler a或DPM++ 2M Karras，这两个在多数模型上的表现都比较稳，遇到Z-image Turbo则优先选它文档里指定的采样器。

还有一个容易被忽略的点是负向提示词。不同模型对负向提示词的理解能力差异很大，有的模型压根不吃这一套。我建议在你还不熟悉模型脾气的时候，先不加负向提示词跑一张，再加一种跑一下，对比差异，再决定要不要继续堆。

3.4 一个替代路径：用OpenVINO跑Qwen-Image

经常有人问“我显卡很弱，能不能跑Qwen-Image”，这就要提到OpenVINO这条路线。简单说，OpenVINO是Intel推出的推理加速框架，能把模型转换成中间表示格式，从而在CPU、集成显卡甚至NPU上运行。转换流程大概是先安装optimum-intel，再把Hugging Face上Qwen-Image的模型导出成OpenVINO格式。

我自己试过在纯CPU环境跑一个量化后的Qwen-Image，输出一张图大概需要几分钟，速度确实没办法跟N卡比，但好处是不依赖昂贵硬件，适合验证工作流、跑测试样本。要注意的是，转换成OpenVINO格式后，部分采样过程算子可能不兼容，生成结果可能和原始模型有一点点偏差；如果你发现颜色怪怪的，优先检查转换时选的精度，建议先试fp16，别直接上int8，否则画质损失会很明显。

4. 高频问题排查：黑图、显存不足、中文崩坏

4.1 Z-image base 出黑图：原因与定位方法

“Z-image base生成的图是黑的”这个话题，在社区里已经成了常见提问。我把它当做一个典型排查案例来拆，原因基本逃不出这三类。

第一类是加载精度问题。很多开源模型的权重是bf16格式，如果你的显卡太老，或者ComfyUI没有正确启用bf16转换，就会在推理过程中产生NaN，最后输出一片黑。解决办法是把模型加载精度手动改为fp16，或者直接让ComfyUI走自动精度，但别用fp8去强行压缩，容易出问题。

第二类是VAE不匹配。这里我要强调，Z-image的潜空间很可能是自己训练的，你需要用配套的VAE，而不是随手拿一个SD系列的VAE去接。打个比方，主模型和VAE是一对暗号组合，暗号对不上，解码出来的就是黑图或绿紫混色的花屏。你可以打开工作流检查VAE节点，换成模型包附带的那个，问题往往会消失。

第三类是采样参数太极端。Turbo模型通常只吃低步数，如果你非要把steps拉到30、又把CFG拉到10，输出可能会过曝成白图或黑图。正常先把steps设成6到8、CFG设成1到2，跑一张，再逐步微调。总之一旦黑图，先不要怀疑模型报废，按“精度→VAE→参数”这个顺序一步一步排查，比盲目重装环境有效得多。

4.2 OpenVINO推理速度不理想怎么办

如果你已经成功用OpenVINO跑起了Qwen-Image，但速度慢到无法接受，可以从三方面优化。第一，转模型时固定输入分辨率，避免动态尺寸导致每次推理都重新做图优化；第二，把中间结果的精度保持为fp16，不要盲目追求量化，CPU推理时int8虽然能提速，但图像噪声会明显增加；第三，只跑低分辨率，例如512×512，然后用另一个轻量放大模型把图片补到1024，这样比直接让OpenVINO跑高分辨率要快得多。

另外要留意，OpenVINO对采样器的支持并不完全。如果你导入后报“算子不支持”，可以把采样器改成UniPC或DDIM这一类算子更基础的选项，一般不推荐在转换后的模型上使用依赖复杂去噪公式的采样器。总之，OpenVINO是一条“能跑但别求极致”的路线，适合用来做自动化测试，不适合追求快速出图。

4.3 中文提示词效果差：换模型还是换翻译

很多人在FLUX.2和Qwen-Image上直接输入中文提示词，结果发现模型误读了关键词。这是因为这些模型的文本编码器是按英文语料训练的，中文表达会经过分词、映射后产生信息损失。我的建议是，如果你用的是FLUX.2，尽量把中文提示词机翻成英文再喂给它，翻译的时候不要逐字硬译，而是把“元素+位置+风格+光线”拆成清晰的英文短语，效果会有明显提升。

如果你不想折腾翻译，那就直接用Seedream、GLM-Image这些中文原生模型，它们是针对中文语义做过优化的，中文长句和口语化描述接受度更好。还有一个小技巧：不管用哪个模型，在提示词里把最关键的实体和它们之间的关系写明确，比如“狗在草地上奔跑”而不是“草地和狗”，这样能大幅减少歧义。

4.4 显存不足：一套通用的降载方案

很多没有大显存显卡的读者总担心跑不了大型模型，其实有几个很实用的降载手段。第一，把ComfyUI的智能显存管理打开，它能把部分中间变量自动转移到系统内存；第二，设置单批大小为1，不要一次生成多张，虽然慢一点，但能避免显存瞬间爆炸；第三，选择分块VAE解码，生成大图时逐块解码，而不是一次性把整个潜空间拉进显存。

如果显存还是不够，可以尝试把模型文本编码器用低精度加载。毕竟文本编码器的精度对画面主导性没那么强，用fp8甚至更好的量化都能明显降低占用。最后再不行，就考虑换Z-image Turbo这种轻量模型来跑，它本来就是为资源有限环境设计的。显存不足不是死局，关键是不要同时堆太多大模型和插件。

4.5 问题速查表

这份表格不是标准答案，但每次遇到问题，我都会按这张表从头过一遍，十次有八次能定位到真正原因，剩下两次基本都是权重文件本身损坏，重新下载或者核对哈希就能解决。

我个人在实际操作中最深的体会是：不要试图让一个模型替你解决所有问题。五个模型各有脾气，你可以把它们当成一个团队来用——FLUX.2负责质感大片，Seedream和GLM-Image负责中文商业内容，Qwen-Image负责复杂指令和Agent调用，Z-image Turbo则适合在资源受限时快速试稿。我平时最常用的一套组合是“用Qwen-Image理解需求草稿，再用FLUX.2精修最终画面”，这样既有了语义稳定性，又保住了画质上限。最后再分享一个小技巧：拿到任何一个新模型，先不要急着调参数，把它的README、示例工作流、贡献者给的建议采样器一字不漏地看一遍，这几分钟往往能帮你避开后面一整晚的排错时间。