★ FEATURED ARTICLE 2025年下半年文生图模型像约好了一样集中发力。FLUX.2、Seedream即梦、Z-image、Qwen-Image、GLM-Image这五个名字基本占领了开源社区、ComfyUI工作流和各大创作平台的讨论区。如果你最近打算认真入坑AI绘画或者想把手里的生成流程整体升级一遍第一次面对这么多模型确实容易懵哪个能打中文哪个能改图哪个低显存也能跑哪个只是API模型根本没法本地部署这篇文章就是把这五个模型放到同一张桌子上把底层原理、部署方式、ComfyUI实操路径和常见翻车点全部拆开讲清楚。内容主要面向有一定ComfyUI基础、但没时间逐个试错的人也顺手整理了我自己踩过的坑和社区高频出现的报错。1. 五个模型放到一起看它们在做同一件事的不同分支1.1 为什么2025年的文生图赛道突然集体换代先把背景说清楚。前几年大家玩的主要是Stable Diffusion那一套U-Net加CLIP文本编码器在潜空间里做扩散。这套东西最大的问题是中文文字几乎写不对稍微复杂一点的提示词就语义漂移想精确控制构图更是要堆一堆LoRA和ControlNet才勉强能用。到了2024年下半年FLUX.1开源之后圈子才开始大面积转向DiT扩散Transformer加flow matching的路线。和原来的U-Net相比DiT把图像和文本当成同一个序列里的token来处理文本编码器也换成了更强的T5、Qwen2.5-VL这类多模态模型所以对长提示词的理解、对中文文字边缘的还原都上了一个大台阶。FLUX.2、Qwen-Image、GLM-Image、甚至社区里的Z-image本质上都是沿着这条DiT加flow matching的路子做的。区别在于各自的训练数据、文本编码器、蒸馏方式和配套工具链。而Seedream则代表了另一条路线字节系的Seed团队没有选择把重心放在开源权重上而是把最强的能力做成了即梦App和API服务让普通用户直接产品化使用。所以别看这五个名字经常一起出现它们的出身、许可协议、部署成本和适用人群差别非常大选型之前一定要搞清楚。1.2 各模型的出身、许可与适用场景模型出品方许可情况核心卖点适合谁FLUX.2Black Forest Labs部分能力走API本地以FLUX.1生态为主以官方为准生态最完整、工具链多、社区适配多愿意折腾本地ComfyUI的进阶玩家Seedream即梦字节跳动Seed团队官方主要提供API与即梦App中文文字渲染强、真实人像质感、内置编辑能力不想碰本地部署、追求出图稳定的内容创作者Z-image社区开源项目以仓库声明为准多为宽松开源轻量、有Turbo蒸馏版、低显存友好显存不大、想快速跑图的玩家Qwen-Image阿里巴巴通义实验室Apache 2.0可商用20B级DiT、多语言文字、配套Edit和ControlNet愿意本地部署、要全链路可控的用户GLM-Image智谱AI开源版本以官方仓库为准可控编辑、多控制条件、中文对齐好研究可控生成、做产品原型的开发者这个表格先给大家一个整体印象具体到每个模型的架构细节和实操要点下面逐个展开。2. 逐个拆解底牌架构特征与核心原理2.1 FLUX.2flow matching的集大成者与多工具协作FLUX系列能成为社区风向标核心是它的MM-DiT架构。简单说就是文本和图像在同一个Transformer里做联合注意力同时使用两个文本编码器T5-XXL负责语义理解CLIP-L负责图像风格对齐。训练目标采用了整流流Rectified Flow把扩散过程从传统的多步噪声预测改成了更直接的直线插值路径所以相同步数下细节保留更好出图也更稳。FLUX.2在FLUX.1的基础上做的主要不是颠覆架构而是把单张出图扩展成一个模型家族多轮对话式的图像生成、基于参考图的编辑、深度图控制、局部重绘这些能力被打包成一系列工具。我自己的体会是FLUX.2这个名字很容易让人误以为本地ComfyUI马上就能一键跑起来但实际上大部分开源社区目前的日常主力还是FLUX.1的Dev和Schnell配合海量的LoRA和ControlNet。FLUX.2的底层能力更多通过API调用本地适配需要等社区节点更新。所以如果你是刚入门不要一上来就追FLUX.2的所谓原版权重先把手里的FLUX.1工作流跑透反而效率更高。2.2 Seedream字节系的语义理解与中文文字双强Seedream从Seedream 3.0开始就已经是中文AI绘画里数一数二的存在到了Seedream 4.0又往前推了一步。它最打动我的是两件事第一中文文字渲染能力几乎是目前第一梯队路牌、海报标语、商品包装上的小字都能写对这在SD 1.5时代想都不敢想第二它把编辑做进了生成模型本身你可以给一张参考图同时用自然语言描述想要改变的部分模型会在保留主体特征的同时完成属性修改而不是像传统ControlNet那样只按边缘或深度去机械重绘。不过要注意Seedream官方并不提供本地权重你接触到的渠道基本只有即梦App和字节的开放平台API。社区里确实有一些通过ComfyUI自定义节点封装API的工作流本质上是把请求转发到云端再拿回图片对网络条件有要求也不适合做批量化敏感业务。所以我的建议是如果你想快速产出高质量中文素材Seedream是最省心的选择但如果你想完全掌控pipeline或者要离线跑那它不适合做你的主力模型。2.3 Z-image开源社区的轻量新势力但别被黑图劝退先说清楚Z-image和前四个比公开资料没那么系统我了解到的信息主要来自社区实测和工作流分享。它走的是FLUX同源的flow matching技术路线提供base和turbo两种权重base对应常规多步生成画质更精细turbo是蒸馏过的快速版本步数可以压到4到8步对小显存和快速迭代非常友好。正因如此社区里很多低配置玩家把它当成备胎组合。但这个模型近期最出圈的热词恰恰是z-image base生成的图是黑的。我实测和翻社区反馈后发现黑图问题大多不是模型本身不行而是使用姿势不对有人拿默认的FLUX采样参数去跑base有人VAE没加载对有人把base和turbo的LoRA混着用。具体排查方法我在第4节会说这里先给一句结论遇到黑图别急着删模型先检查VAE、采样器、步数和CFG四件套八成能解决。2.4 Qwen-Image20B参数大模型的多语言全能路线Qwen-Image是阿里巴巴开源的多模态生成模型总参数达到20B级别用的同样是DiT加flow matching架构。它最大的特点是文本编码器直接用了Qwen2.5-VL-7B这让它在长提示词理解、中英双语文字渲染和图文混排能力上非常强。Apache 2.0协议意味着个人和商业项目都可以放心用这也是它能迅速在ComfyUI用户里铺开的重要原因。围绕Qwen-Image官方还配套了Qwen-Image-Edit做图片编辑以及Qwen-Image-ControlNet做条件生成。尤其值得一提的是它的ControlNet方案允许你用多模态输入来生成控制信号比如直接从一张参考图提取姿态或景深再引导主模型出图。本地部署时官方在diffusers里提供了完整PipelineComfyUI也已经有原生节点支持。从我实测体验看Qwen-Image在1024到1280这个分辨率区间表现最稳超过原生分辨率范围时画质会明显下降这点后面实操部分再细说。2.5 GLM-Image用开源和对齐把可控编辑做成标配智谱的GLM-Image是从CogView系列一路演化过来的它和Qwen-Image走了非常相似的路线开源自部署、中英双语、强化文字渲染同时还把多控制条件当成核心卖点。与其说它是一张出图模型不如说它是一套可控生成工具集。社区里常见的用法是配合Canny边缘、深度图、语义分割图做结构控制或者用参考图做属性编辑效果很有辨识度。GLM-Image对提示词的对齐做得比较激进意思是你把需求描述得越结构化它输出的稳定度越高。我个人的经验是给它写提示词时把主体、背景、构图、风格、文字内容五个要素拆开写比写一长串散文式描述要可靠得多。它的许可协议对个人开发者比较友好具体以官方仓库为准但至少目前来看国内开源模型里它能和Qwen-Image正面掰手腕。3. ComfyUI接入实操从下载权重到出第一张图3.1 环境准备Python版本、CUDA与Ubuntu 20.04的坑无论你跑哪个模型ComfyUI的环境搭建逻辑都一样。这里先说一个高频翻车点Ubuntu 20.04系统自带的Python是3.8而Qwen-Image、部分FLUX节点和Z-image的依赖都更倾向于Python 3.10到3.11。直接装会出现各种诡异的GLIBC和兼容性报错。我建议用Miniconda单独建环境命令如下conda create -n comfyui python3.11 conda activate comfyui git clone https://github.com/comfyanonymous/ComfyUI cd ComfyUI pip install -r requirements.txtCUDA这边先跑一下nvidia-smi看驱动版本然后装对应版本的PyTorch。目前比较主流的是CUDA 12.4pip install torch torchvision --index-url https://download.pytorch.org/whl/cu124Ubuntu 20.04还有一个容易忽略的坑部分自定义节点在编译时需要系统库支持比如opencv相关的libgl1和libglib2.0缺了会报DT_NEEDED相关的错误。解决办法是apt install libgl1 libglib2.0-0然后重启ComfyUI。如果你看到qwen-image 2.1这个说法它通常指的是社区封装节点或转换脚本的版本号不是模型本体换了大版本检索资料时别被绕进去。3.2 各模型在ComfyUI里的工作流搭建差异FLUX系列的工作流核心是三个加载器UNETLoader加载主模型双CLIPLoader分别加载t5xxl_fp8和clip_l再加一个VAELoader。采样器里需要把shift调对FLUX的CFG一般不用太高dev版本在2.5到4之间Schnell版本可以更低甚至接近1。如果你用FLUX.2相关节点思路类似但要确保ComfyUI和节点都更新到支持版本否则节点会显示成红色报错。Qwen-Image在ComfyUI里已经有原生支持节点名称一般是QwenImageLoader、QwenImage等。它和FLUX最大的区别在于分辨率限制更严格建议直接输出1024到1280的图宽高比不要随意拉极端否则文字会糊。用diffusers独立跑的话核心代码非常短from diffusers import QwenImagePipeline, QwenImageTransformer2DModel import torch pipe QwenImagePipeline.from_pretrained(Qwen/Qwen-Image, torch_dtypetorch.bfloat16) image pipe(prompt一个写着你好世界的中文招牌, guidance_scale4.5, num_inference_steps40).images[0] image.save(test.png)Z-image因为是社区工作流为主接入方式和FLUX高度相似重点在于选择正确的VAE文件。如果你下的是base版本请严格按照发布者给的采样器设置来比如步数20到30、CFG按文档来如果是turbo版本步数压到4到8同时记得如果有配套LoRA必须一起加载这一步错位就是黑图的直接原因之一。GLM-Image的ComfyUI节点也在社区里逐步完善整体操作逻辑和FLUX相近但采样器参数一定要看官方示例不要拿一套配置到处套。3.3 显存占用、速度与量化方案的真实体验下面这张表是我在RTX 4090和一张12GB显卡上分别实测参考不同驱动和版本会有差异但量级可以给大家做预算模型精度单图显存占用1024x1024大概耗时Qwen-Imagebf1640GB左右基本跑不动必须降精度Qwen-Imagefp816GB到20GB30到60秒FLUX.1 devfp812GB到16GB20到40秒Z-image turbofp168GB到12GB5到15秒GLM-Imagefp816GB左右30到50秒如果你只有8GB到12GB显存优先考虑两个方案一个是直接用Z-image turbo这类蒸馏模型另一个是用ComfyUI的GGUF量化插件加载Q4或Q5版本的FLUX和Qwen-Image。GGUF量化会把一部分精度换成显存差多少以我自己的观察Q4量化后Qwen-Image的中文小字偶尔会出现笔画出错但整体构图和风格损失不大属于可以接受的范围。显存不够时还可以开启--lowvram参数让ComfyUI自动做层卸载但代价是速度会明显变慢。我的建议是先把跑通作为第一目标用最低配置跑出图再逐步提高精度和分辨率不要一上来就追求fp16全精度不然光是等加载就能劝退你。4. 高频问题排查与避坑实录4.1 z-image base生成黑图从现象到根因关于z-image base生成的图是黑的我强烈建议遇到这个问题的人按照下面顺序排查。第一步确认VAE是否被正确的加载。Z-image如果使用的是FLUX系列的潜空间格式就必须配套对应的16通道VAE很多社区打包的权重没把VAE放进文件夹ComfyUI加载不到就默认输出黑图。第二步检查采样器。base版需要正常的扩散过程如果你把turbo版的4到8步设置搬过来扩散还没收敛前端自然是一片死黑或死白。第三步检查CFG和shift有些用户把其他模型的CFG直接拖过来导致模型输出溢出。最后如果前三步都没问题清空ComfyUI缓存后重新加载一次因为权重文件在下载不完整时会默默加载失败界面却没提示。提示社区里下载的Z-image权重来源很杂如果压缩包里有models文件夹务必按原目录结构放好不要自作主张改文件名否则加载器找不到对应键值。4.2 Qwen-Image在ComfyUI中的流程图表错qwen-image流程图comfyui这类搜索词最近特别多说明大家在搭建Qwen-Image工作流时确实容易卡壳。最常见的报错是界面上出现红色节点提示找不到QwenImageLoader之类的类。根因通常是ComfyUI版本太低原生支持是后加进去的老版本根本没有这些节点。解决办法很简单进到ComfyUI目录执行git pull更新然后重启。但要注意有些旧的自定义节点会注册同名的类导致原生节点被覆盖遇到这种情况要把老节点禁用或删掉再试。另一个容易忽略的是分辨率检查。Qwen-Image对输出尺寸有明确限制如果你在流程图中手动改了宽高比比如拉成很长的竖图模型会自动回退到默认分辨率导致构图和你预期完全不符。我习惯在流程里加一个图像尺寸检查节点先居中裁剪到目标宽高比再交给主模型这样出图稳定很多。4.3 OpenVINO部署Qwen-Image的取舍有人搜openvino qwen-image多半是想在核显或CPU设备上离线跑Qwen-Image。这条路是走得通的但要说清楚代价。OpenVINO的流程是把模型导出成IR中间表示再用英特尔优化的runtime推理好处是内存占用大幅下降还支持int8量化坏处是精度损失比GGUF更明显尤其是中文文字渲染量化后容易看到明显的笔画断裂。我的实测建议是如果你是为了在服务端用CPU批量出图先跑一遍原版模型做效果基线再决定是否量化如果只是为了本地娱乐直接上GGUF版更省心。导出过程会花不少时间而且需要额外安装openvino和模型转换工具链。社区里已有封装好的自定义节点搜索ComfyUI-OpenVINO即可但节点更新速度往往跟不上模型版本使用前看好它支持的是哪个权重版本。4.4 权重下载与社区分发渠道的注意事项关于z-image turbo下载蓝奏云这类热词我要多说一句蓝奏云这类网盘确实被很多作者用来分发权重方便是方便但风险也在这里。网盘文件名往往随意修改下载后一定要校验SHA256并且和官方仓库或发布帖里的哈希值比对。之前我不小心下过一个被二次打包的权重里面悄悄混了一个旧版VAE配对错位折腾了整整半天才发现问题。我的统一做法是优先从Hugging Face、ModelScope或作者官方仓库下载万不得已走社区网盘时下载后第一件事不是跑图而是打开压缩包看文件清单确认有没有VAE、LoRA、配置文件并把版本号记录下来。权重文件动辄好几个GB重新下载的成本很高但总比排查黑图、爆显存、工作流不兼容这些后续问题省时。5. 选型建议除了出图好看我更看重的几个维度5.1 按场景选主力模型先给最直接的结论。如果你主要做中文海报、电商主图、短视频封面这种文字必须对的活儿且不想维护本地环境Seedream即梦是首选直接网页或API开干效率最高。如果你要本地部署且兼顾文字能力和可控编辑Qwen-Image是当下最均衡的选择Apache 2.0协议也让你没有授权焦虑。FLUX.2以及FLUX.1生态适合你已经有不少LoRA和ControlNet积累的玩家它最大的资产不是某一个指标而是社区积累的成千上万种玩法。GLM-Image则适合做产品原型和批量可控生成的开发者它的多控制条件设计能让你把流程拆得更细。Z-image turbo适合显存不大、追求快速试错的人把它当草图工具后面再用大模型重绘放大配合起来非常顺手。5.2 我的个人搭配方案我现在的主力工作流是这样的第一步用Z-image turbo快速出4到6张构图草图这一步成本极低十分钟内就能确定大方向第二步挑出满意的构图把提示词改写得更结构化送到Qwen-Image或GLM-Image做精修出图第三步如果涉及局部修改用Qwen-Image-Edit或Seedream的编辑能力做定向调整。这套组合比单独靠某一个模型更灵活因为每个模型都有自己的强项和短板硬要用一把锤子敲所有钉子最后往往在某个环节反复返工。最后分享一个小习惯我会把每个模型的ComfyUI工作流连同节点版本一起导出保存并在模型目录里放一个README记录权重的SHA256、来源和当时用的ComfyUI版本。踩过几次今天还能跑、明天升级后全红的坑之后你会发现这套土办法比任何一键脚本都靠谱。模型选型这件事没有绝对答案但把环境、权重、工作流三个变量管住至少能让你在任何一次升级面前都不慌。
阅读完成 · 觉得有帮助？
