最近在AI绘画社区里你会看到一个问题被反复问起为什么我用Z-image base生成的图是黑的如果你也卡在这一步先别急着换模型。过去这一个多月FLUX.2、Seedream即梦、Z-image、Qwen-Image、GLM-Image几乎同时涌入大家的视野它们来自不同团队、走不同技术路线部署方式、显存需求和使用习惯也完全不同。把五个模型搅在一起对比或者指望一套流程通吃是很多人踩坑的根源。这篇内容我就按我的实际使用经验把这五款模型的出身、架构、部署差异和真实表现一次说清楚尤其把Z-image黑图、本地部署显存、ComfyUI配置这些高频问题掰开揉碎给你一份可以直接照着用的参考。1. 五款模型的地图出身不同路线注定不同先说结论这五个模型虽然都是文生图但它们不是同一类东西。背后团队的积累方向不同导致它们的架构、生态、开放程度和擅长场景差异很大。搞懂它是谁家的、怎么训练出来的很多使用上的疑问会迎刃而解。1.1 从扩散模型到DiT架构一次快速定位过去两年图像生成的主流框架是扩散模型Stable Diffusion系列是代表。2024年之后行业逐渐从U-Net架构转向DiTDiffusion Transformer简单说就是把图像切成小块patch用Transformer的注意力机制去处理效果更好、扩展性更强。FLUX系列、SD3.5、Qwen-Image、GLM-Image都是DiT路线。Z-image虽然基于SD3.5但它属于微调模型不是独立从零训练的。在这个背景下五款模型大致分三个梯队FLUX.2是目前社区生态最完整、上限很高的通用模型Seedream即梦是字节系产品背后的自研模型走的是平台化路线Z-image是社区微调的轻量方案Qwen-Image和GLM-Image则是大模型团队把基座大模型的经验搬进图像生成对中文和长文本理解非常友好。1.2 FLUX.2从FLUX.1长出来的主流之选FLUX.2是黑森林实验室在FLUX.1之后的迭代版本。FLUX.1当年靠DiT架构、flow matching训练和原生多分辨率支持成为社区公认质量天花板之一。FLUX.2延续了这些特性并在语义理解、细节质感和风格控制上做了增强。它还保留了schnell这种快速版走Apache 2.0协议开源对个人和商业使用都很友好这也是它成为ComfyUI工作流主力模型的原因。1.3 Seedream即梦中文场景的体验派Seedream是字节跳动旗下即梦AI背后的自研图像生成模型目前能接触到的版本基本是Seedream 4.0。它的强项在原生高分辨率2K级别、中文理解、文字渲染和整体画面质感。它的分发方式主要是即梦平台和火山方舟API权重不完全开放给本地部署。如果你需要中文海报、电商主图、带中文标语的设计稿Seedream是我个人用过所有模型里最稳的之一。1.4 Z-image从SD3.5 Large下手微调的轻量黑马Z-image严格说不是从零训练的模型它是基于Stable Diffusion 3.5 Large做微调的社区模型。它的模型文件非常小核心只有900MB左右但依赖SD3.5 Large的中文文本编码器。因为权重开放、工具链兼容SD3.5生态很多人在低显存机器上用它。Z-image同时提供了Base和Turbo两个版本Turbo经过蒸馏可以4步出图速度极快。社区里讨论的Z-image黑图问题绝大多数出在部署环节后面我会专门拆解排查链路。1.5 Qwen-Image与GLM-Image基座大模型团队的下场解法Qwen-Image来自阿里的通义实验室走MM-DiT多模态DiT路线总参数在2.5B级别权重开放。它的特点是原生支持多种分辨率1024到1440像素中文语义理解强而且能跟Qwen系列大模型联动形成了文本生成→图像生成→迭代优化的完整链路。GLM-Image来自智谱同样走开源路线参数规模在4B量级。它的打法更接近基座模型思路超长提示词支持、参考图输入、最高4K分辨率生成。如果你需要长段落中文描述、风格参考图保持一致GLM-Image的表现非常亮眼。下面是这五款模型的基本信息对照模型来源团队架构类型参数量级开放程度最突出优势FLUX.2黑森林实验室DiT Flow Matching较大B级Schnell开源通用质量、生态完整、英文排版Seedream 4.0字节跳动即梦自研扩散模型未公开平台/API为主原生2K、中文理解、文字渲染Z-image社区微调基于SD3.5 Large约900MB开放轻量、低显存、支持量化Qwen-Image阿里通义MM-DiT约2.5B开放中文理解与多分辨率GLM-Image智谱自研生成框架约4B开放超长提示词、参考图、4K2. 架构层面的核心差异为什么有的模型只吃8GB有的跑不动很多人在本地部署时最关心显存。其实显存需求不是拍脑袋决定的它来自架构设计。理解了下面几个关键点你就能预测一个模型大概要多少资源。2.1 MM-DiT文本不再走旁路而是参与核心注意力传统Stable Diffusion把文本编码后的向量作为条件通过Cross-Attention注入U-Net图像和文本的信息融合程度有限。MM-DiT多模态DiT的做法更激进把文本token和图像token拼接在一起放进同一个Transformer的注意力层里做双向交互。FLUX系列最早大规模采用这种设计Qwen-Image也是类似思路。这意味着模型能在生成的每个阶段都看到文本细节而不是只在开始时草草注入。代价是注意力矩阵变大计算量上升显存需求也水涨船高。这也是FLUX.2、Qwen-Image这类模型跑起来比Z-image吃资源的核心原因。2.2 Flow Matching与蒸馏为什么Z-image Turbo能4步出图扩散模型传统做法是逐步去噪通常需要20到50步。Flow Matching换了一种思路不预测噪声而是学习如何把纯噪声平滑地流动到真实图像分布这让训练更稳定推理需要的步数也更少。FLUX.2、SD3.5都用了Flow Matching。Z-image Turbo则是把flow matching模型进一步蒸馏把推理步数压到4步左右。蒸馏的本质是让一个少步数的学生模型去模仿多步数教师模型的输出代价是分辨率变化、复杂提示词的鲁棒性会略差。所以Z-image Turbo适合快速出图Z-image Base适合追求质量。2.3 原生分辨率训练为什么老模型锁512新模型随意出早期SD 1.5用512x512训练超过分辨率就容易崩结构。FLUX.2、Qwen-Image、Seedream等模型在训练时就混合了多种分辨率和宽高比模型学会了在不同尺寸下保持构图。这是原生能力不是后处理能替代的。实际使用中FLUX.2和Qwen-Image在竖构图、方形图、超宽图上表现都很稳定这对设计场景非常重要。2.4 中文文本编码器与超长提示词细心的朋友会发现Seedream、Qwen-Image、GLM-Image的中文理解都明显强于FLUX.2。原因在文本编码环节。FLUX.2依赖的文本编码器T5系列虽然英文章强大但中文字符的编码效率不算高。Qwen-Image和GLM-Image在训练时就专门优化了中文编码甚至支持几千字的超长提示词这对写详细描述的玩家是决定性优势。3. FLUX.2 与 Seedream即梦的实战要点从能做到好用这两款模型代表两种完全不同的使用方式一个适合本地折腾、深度可控一个适合在线出图、追求效率。把它们放在一起讲是因为它们都是我画设计素材时的高频选择。3.1 FLUX.2在ComfyUI里的接入与常用配置FLUX.2的接入逻辑跟FLUX.1很接近需要单独加载文本编码器模型本体放到unet或diffusion_model目录用DualCLIPLoader方式加载双文本编码器。Schnell版本文件小、速度快适合日常测试高配版本dev级别质量更好但对显存要求高。我的习惯配置是采样器Euler调度器SimpleCFG设为1.0步数25到30。FLUX系列对CFG非常敏感很多人一开始按SD的习惯把CFG调到7结果画面过饱和、细节崩坏。如果你刚开始用FLUX.2记住这句先把CFG降到1再谈其它参数。3.2 Seedream即梦的正确打开方式平台与APISeedream目前主要靠即梦平台和API开放。本地没有现成权重所以我更愿意把它当成生产工具而不是玩具。实际使用中即梦平台的中文提示词理解能力非常强你直接写一只戴草帽的橘猫在夏日海边背景有中文标语招牌这种描述它都能稳定输出。最关键的是原生2K分辨率省去了大量高清放大流程。如果你做商业项目需要批量出图或者搭建自动化流程走API是更合理的选择。API方式下可以统一管理提示词、分辨率、负面词和回调接口和现有业务系统对接也方便。Seedream在中文渲染上的优势目前本地开源模型很难完全追上特别是海报标题字、招牌字这种场景。3.3 文字渲染与构图质量实测我专门测试过两组场景。第一组是英文海报FLUX.2的文字排版准确率极高单词拼写几乎不出错这得益于它强大的英文编码器。第二组是中文LogoSeedream对中文结构的理解明显更好笔画不乱、布局稳定。构图方面FLUX.2在处理复杂光影、透视、材质细节上更真实相近风格切换更自由Seedream在画面整体协调性、色彩通透度上更讨喜。我的建议是英文和自由创作优先FLUX.2中文商业素材优先Seedream两者互补并不冲突。4. Z-image900M小模型的社区路线和让人头疼的黑图问题Z-image是社区讨论度很高的模型因为它让低配置用户看到了本地跑好图的希望。但伴随而来的问题也特别集中尤其是Base版本生成黑图。这一章我把它单独拎出来因为Z-image是五款里最容易在部署上栽跟头的。4.1 Z-image Base与Turbo的差异、下载与依赖Z-image基于SD3.5 Large微调但模型本体只有约900MB。它不包含文本编码器需要配合SD3.5 Large的中文文本编码器才能工作千万别把这个依赖漏了。Z-image Turbo经过蒸馏文件更小4步即可出图Base版本需要更多步数实测25到35步但细节更细腻。因为文件小Z-image在国内社区经常通过网盘转存分发比如蓝奏云这类链接。下载后要注意文件完整性很多人解压到一半丢文件导致推理时黑图或报错。模型放置路径建议ComfyUI/models/diffusion_models/。4.2 Base版本黑图问题的完整排查链路黑图是Z-image用户最头疼的问题但九成原因就那么几个。我把排查顺序整理成清单你照着顺序检查基本能在十分钟内定位文本编码器版本Z-image依赖的是SD3.5 Large的文本编码器如果你错用了SD3 Medium的clip或者FLUX的clip生成结果大概率黑图。需要检查ComfyUI里加载的是否为sd3.5_large_fp8或精度更高的对应文件。CFG与采样器设置Z-image是基于Flow Matching训练的模型官方推荐CFG在1到2之间很多节点默认CFG是7直接拉高会导致画面污染甚至全黑。采样器优先选Euler或DDIM调度器优先Simple不要一上来就换DPM系列。步数设置Base版本至少25步以上。如果你用默认的8步就停输出往往是黑场。Turbo版本则反过来步数超过8反而可能出现噪点。负面提示词写法Flow Matching模型对负面提示词不敏感不用像SD 1.5那样写一大串low quality、bad anatomy。如果你把大量字符塞进负面词某些实现会因为token越界导致输出异常。负面词保持空白或只写低质量就够了。文件路径与ComfyUI节点确认模型文件确实在diffusion_models目录且用了对应的Load Diffusion Model节点。很多人下了模型但ComfyUI没有扫描到走了旧模型的加载路径也会表现为输出异常。依赖库版本较老版本的ComfyUI对SD3.5系列支持不完整建议先升级到最新版本再排查。如果你用了sage attention等加速插件先禁用它们做对照实验。4.3 低显存跑Z-image量化与LoraZ-image官方社区提供了Int8量化版本在12GB显存以下表现良好。RTX 3060 12GB实测跑Int8量化版开启ComfyUI的fp8文本编码器后一张1024x1024图片大约需要6到8秒这个速度对低配置用户非常友好。Z-image还兼容SD3.5生态的Lora训练工具链。我在一个头像风格迁移项目里用20张图训练了一个Z-image的Lora单张图1920x1080分辨率下也能稳定保持人物特征。这不光说明Z-image轻量更说明它没有因为体积小就牺牲可控性社区衍生能力强。4.4 适合谁用局限在哪里Z-image适合这些场景低显存本地部署爱好者、需要快速出图验证想法的人、想尝鲜SD3.5生态但不想下载超大模型的人。局限也很明显因为它是微调模型基座SD3.5的上限决定了它的综合质量不如FLUX.2或Qwen-Image复杂场景、多人交互、精细手部仍会翻车。别指望它取代大模型它更像小身材好上手的社区工具。5. Qwen-Image 与 GLM-Image把大模型那套玩法搬进生图阿里和智谱做图像生成风格跟传统图像团队不太一样。它们把大模型里的长文本理解、多模态对齐、工具链编排思路带进了生图用户体验上的变化非常明显。5.1 Qwen-Image的MM-DiT和多分辨率支持Qwen-Image采用MM-DiT架构文本和图像token一起参与注意力计算训练时混合多种分辨率和宽高比。实际出图时1024x1024到1440x1440范围都可以直接生成不用先出小图再放大。总参数约2.5B比起FLUX.2那些大块头要轻不少但质量没有明显妥协。中文描述理解是它的强项你写口语化描述、成语、带情绪的文案它都能正确响应。在ComfyUI里接入Qwen-Image非常顺滑切到最新版本就能直接用新的加载器加载。注意它对ComfyUI版本有要求如果你用老版本节点会报model not recognized之类的错。升级后配合标准的CLIPTextEncode和KSampler就能跑通。5.2 Qwen-Image流程图在ComfyUI里的搭建思路很多人搜Qwen-Image流程图ComfyUI其实是想要一套可复用的工作流模板。我分享一套自己常用的基础链路加载Qwen-Image模型用CheckpointLoader新版本或对应的UnetLoader加载把文本编码器路径配置好。编写中文提示词建议把主体、风格、构图、光照拆开写例如主体一只机械猫风格赛博朋克构图低角度仰视光照霓虹灯蓝紫光。Qwen-Image对这种结构化文本理解得特别好。采样参数步数20到30起步CFG从3到5之间测试采样器推荐dpmpp_2m或Euler调度器normal或simple。后处理Qwen-Image支持在原生分辨率下保持细节输出后可以接一个放大节点如Ultimate SD Upscale或修脸节点做精修。这套流程比传统工作流更简化因为Qwen-Image原生分辨率足够高不需要多次HD放大。我的实测是一张1440x1440出图后高清放大到2K画面结构依然稳定。5.3 GLM-Image超长提示词、参考图输入和4K生成GLM-Image更像图像生成的基座模型。它支持非常长的中文提示词我测试过一段约800字的分镜描述它能抓住关键信息不会因为文本过长而丢失主体。更实用的是参考图输入你可以给一张风格图再给一段文字描述它能保持风格的同时完成内容变化。这一点在角色一致性、系列海报生成上非常好用。GLM-Image最高可生成4K分辨率但本地显存压力不小。实际使用建议先输出2K再配合放大工具推到4K。如果你的场景是需要大量长文本创作、多轮风格统一的工作流GLM-Image是本地开源模型中的最优解之一。5.4 中文长文本与字节级BPE编码细节Qwen-Image在文本处理上有一个细节它使用E2B char/byte BPE编码能更快地编码长文本、支持多语言内容。对用户来说感知就是提示词写得再长它也能把语义细节带进生成过程不容易出现提示词太长尾段被忽略的问题。GLM-Image也类似专门优化了长文本编码效率。如果你以前用FLUX时感觉提示词超过200字就失控换这两款会有明显区别。6. 部署实测显存占多少、速度多快、ComfyUI到底怎么配这一章是我自己折腾完一轮之后的实践记录。注意具体数据会因环境不同浮动但趋势和相对关系可以参考。6.1 我的测试环境与显存占用测试环境一台RTX 4090 24GB一台RTX 3060 12GB内存均为32GB系统Ubuntu 20.04和Windows 11各跑了一遍。模型均为半精度或fp8精度加载。模型半精度权重大小最低显存参考推荐显存1024图实测速度4090FLUX.2 Schnell约10GB16GB24GB约5到10秒Seedream 4.0在线服务无无约10到20秒APIZ-image Base约0.9GB6GB12GB约3到5秒Z-image Turbo约0.9GB6GB12GB约1到2秒Qwen-Image约5GB左右12GB16GB约10到15秒GLM-Image约8GB级16GB24GB约15到25秒FLUX.2建议直接用fp8加载模型和文本编码器能显著降低显存占用16GB卡也能跑出不错效果RTX 3060适合跑Z-image和Qwen-Image的精简模式不建议硬上GLM-Image全精度。6.2 采样参数与出图质量速查表我把常用的参数组合整理成了表方便你直接照抄模型步数CFG采样器调度器备注FLUX.220到301.0EulerSimpleCFG过高必翻车Z-image Base25到351.0到2.0Euler或DDIMSimple推荐配Int8量化Z-image Turbo4到61.0EulerSimple步数多了反而噪Qwen-Image20到303.0到5.0dpmpp_2mNormal结构化提示词有效GLM-Image40到503.0到5.0dpmpp_2mNormal长文本越稳定6.3 ComfyUI常见报错黑图、模型不认识、节点缺失我整理了几个高频问题按先排除环境再怀疑模型的原则处理模型文件加载后节点报红色警告多见于ComfyUI版本太旧。解决办法是升级ComfyUI或到对应模型官方页面确认支持的版本要求。Z-image生成黑图回到第4.2节排查链路先确认文本编码器再调CFG和步数。Qwen-Image跑一半内存溢出降低分辨率到1024级别或使用fp8精度加载。也可以把batch_size降为1。采样器列表里找不到Euler切换调度器为Simple或Normal采样器名称会跟着变不影响出图质量。6.4 Ubuntu 20.04下ComfyUI跑Qwen-Image的系统级注意点Ubuntu 20.04自带Python版本和PyTorch对CUDA的支持比较敏感我踩过的坑有三个。第一是PyTorch版本要匹配CUDA建议用cu121或cu124版本不要直接pip install torch默认版本否则可能被编译成CPU版。第二是gcc版本不能太老编译部分依赖时会报错升级到gcc 9以上能避免大部分问题。第三是虚拟环境必须独立建直接装到系统环境会碰到numpy版本冲突。如果你在Ubuntu 20.04上跑ComfyUI Qwen-Image遇到启动即卡死先检查显卡驱动是否识别到CUDA执行nvidia-smi看显存和驱动版本。这一步能过滤掉八成环境问题。6.5 量化工具与显存优化对大模型fp8量化是最实用的方案。40系和50系显卡对fp8有硬件加速加载FLUX.2和GLM-Image时能明显降显存。Z-image这类小模型则适合Int8量化RTX 3060实测比fp16快且省显存。还有一个容易忽略的点ComfyUI的VRAM管理选项在设置里可以关闭自动加载到显存。多模型切换频繁时会频繁爆显存关掉这个选项后系统会按需调度省心不少。7. 选型建议按需求挑模型别按热度挑模型最后聊聊怎么选。我自己见过太多人因为某个模型在社交平台刷屏就跑去下载结果用起来处处别扭。选模型应该先问自己三个问题我的显存有多少我的主要场景是中文还是英文我是在本地折腾还是要快速出商业稿7.1 典型需求对应的模型选择需求类型推荐方案原因本地低显存尝试新绘图Z-image Base/Turbo模型小、要求低、工具链完整英文海报、设计稿、自由创作FLUX.2英文排版稳、质量上限高中文海报、电商主图、商业素材Seedream即梦API/平台中文渲染强、原生2K中文长文本、系列化创作GLM-Image超长提示词参考图保持风格结构化流程、团队自动化Qwen-Image与Qwen大模型联动、协议友好人物模型训练、风格微调Z-image或FLUX.2社区Lora生态完整上手快7.2 本地跑还是云端API这个选择影响很大本地跑的好处是免费、可控、数据不出机器适合个人创作、实验和隐私敏感的内容。代价是硬件成本、时间成本和折腾成本。云端API的好处是省心、算力弹性大适合商业项目和生产环境。Seedream这类没有开放本地权重的模型走API是唯一高性价比路径FLUX.2、Qwen-Image这类开源模型如果你的显卡不错本地会是更自由的选择。我个人的组合方式是日常灵感验证用Z-image Turbo本地秒出图正式设计稿用FLUX.2本地精修中文商业交付用Seedream API省时间长文本和系列化项目用GLM-Image保持风格稳定。Qwen-Image则作为自动化流程的补充特别是需要和文本大模型联动时非常顺。7.3 一点个人体会这些模型之间不存在谁彻底替代谁的关系。FLUX.2不会因为Seedream中文强就失去价值Z-image也不会因为体积小就被大模型碾压。它们各自服务不同的人群和场景。我最后的建议很简单别做氛围型选手别人说什么好就去下载什么先明确你要解决的问题、你的硬件边界、你的内容语言然后从上面任意一个推荐组合开始测试。模型只是工具真正重要的是你用它把想法变成作品的过程。
