企业官网建设流程全解析

1. 五个模型到底在解决什么问题

先把结论摆在前面：FLUX.2、Seedream（即梦）、Z-image、Qwen-Image、GLM-Image 这五个名字，本质上代表的是当前文生图领域里五条不同的技术路线和产品思路。它们不是简单的"谁比谁强"的关系，而是各自在生成质量、推理速度、中文语义理解、部署成本、生态开放度这几个维度上做了不同的取舍。你如果只是看排行榜选模型，大概率会踩坑，因为排行榜测的那些prompt跟你实际业务里的prompt根本不是一回事。

我自己从去年开始陆续把这几个模型都跑了一遍，有在云端API上试的，也有在本地ComfyUI里搭工作流跑的，还有在Ubuntu 20.04上折腾Qwen-Image 2.1的。踩过的坑包括但不限于：Z-image base生成全黑图、Qwen-Image在ComfyUI里节点连错导致显存爆掉、FLUX.2的量化版本选错导致出图糊成一片。这篇文章就把这些经验系统性地整理出来，从每个模型的核心定位讲起，再到实际部署和调优，最后给一份常见问题的速查表。

适合谁看？如果你是刚接触AI绘画想搞清楚该选哪个模型的，这篇能帮你省下大量试错时间；如果你已经在用ComfyUI搭工作流但遇到各种报错的，里面的排查思路应该能对上你的问题；如果你是做产品选型需要评估部署成本的，关于显存占用和推理速度的对比部分可以直接参考。

2. 五个模型的核心定位与技术路线拆解

2.1 FLUX.2：追求极致画质的DiT架构代表

FLUX系列从诞生起就走的是**Diffusion Transformer（DiT）**路线，跟传统的UNet架构不一样。FLUX.2作为迭代版本，核心改进在于文本编码器的语义对齐能力和去噪过程的细节保留。简单打个比方：传统UNet像是在一张模糊照片上反复擦除和重绘，而DiT更像是把整张图切成无数小块，每一块都同时参与全局的注意力计算，所以它在处理复杂构图和多主体场景时明显更稳。

FLUX.2的实际优势体现在几个方面。第一是手部细节，这是AI绘画的老大难问题，FLUX.2在手指数量、关节弯曲这些细节上的准确率比上一代提升明显。第二是文字渲染，你在图里让它写个招牌、写个标语，它基本能写对，这在以前的模型上几乎不可能。第三是风格一致性，同一个prompt跑多次，出图的风格波动比较小。

但代价也很直接：显存占用大、推理速度慢。完整版FLUX.2在FP16精度下需要接近24GB显存才能跑得舒服，即使用量化版本，想要出1024x1024以上的图，16GB显存也是起步线。所以它更适合对画质有极致要求、且硬件条件允许的场景。

2.2 Seedream（即梦）：产品化程度最高的中文友好方案

Seedream是字节跳动即梦平台背后的图像生成模型。它跟FLUX.2最大的区别在于：Seedream是一个产品化的模型，不是给你本地部署用的。你通过即梦的网页端或者API调用它，背后的一切部署、优化、加速都由平台搞定。

这个定位决定了它的几个特点。首先是中文prompt理解极强，你直接写"一个穿汉服的女孩站在江南水乡的石桥上，背景是烟雨朦胧的远山"，它能准确理解"汉服""江南水乡""烟雨朦胧"这些带有文化语境的词，而很多英文模型对这类中文特有概念的理解会打折扣。其次是出图速度快，平台侧做了大量推理优化，通常几秒到十几秒就能出一张图。第三是风格模板丰富，即梦内置了大量预设风格，你不需要写复杂的prompt就能出特定风格的图。

局限也很明显：你无法控制底层参数，不能调采样器、不能改CFG scale、不能换VAE。对于想要精细控制生成过程的用户来说，这既是优点（省心）也是缺点（不灵活）。另外API调用是按量计费的，大批量生成时成本需要算清楚。

2.3 Z-image：轻量化与Turbo加速的实用派

Z-image这个模型在社区里的讨论热度主要来自两个方面：一是它的轻量化设计，二是Turbo版本带来的极快推理速度。Z-image base的参数量相比FLUX.2小不少，这意味着它能在消费级显卡上跑起来，比如12GB甚至8GB显存的卡。

但这里有个非常关键的坑，也是热搜词里提到的："z-image base 生成的图是黑的"。这个问题我亲自遇到过，原因通常有三个：一是VAE没配对，Z-image需要特定的VAE文件，用错了就会出全黑或者全灰的图；二是采样步数设得太低，base版本如果只跑4-6步，去噪不充分就会出黑图；三是模型加载精度问题，有些量化版本在特定显卡上会出现数值溢出导致输出全黑。

Z-image Turbo则是另一个思路：通过蒸馏技术把采样步数压缩到1-4步，牺牲一点画质换取极快的生成速度。实测下来，Turbo版本在4步左右能出可用的图，1-2步则更适合做草图或者快速预览。热搜词里提到的"z-image turbo下载蓝奏云"说明社区对它的本地部署需求很旺盛，但我要提醒一句：下载模型文件一定要从官方或可信渠道获取，来路不明的模型文件可能被篡改过，跑出来的结果不可控。

2.4 Qwen-Image：中文语义理解与ComfyUI生态的深度结合

Qwen-Image是通义千问系列的图像生成模型，它最大的卖点就是中文语义理解的深度。跟Seedream类似，它对中文prompt的理解能力远超纯英文训练的模型，但不同的是，Qwen-Image支持本地部署，而且跟ComfyUI的集成做得相当成熟。

热搜词里"qwen-image流程图comfyui"和"ubuntu20.04 comfyui qwen-image 2.1 cnblog"这两个搜索意图很明确：大家想知道怎么在ComfyUI里把Qwen-Image的工作流搭起来。我实际在Ubuntu 20.04上部署过Qwen-Image 2.1，整体流程是：装好ComfyUI基础环境 → 下载Qwen-Image的模型文件和对应的文本编码器 → 在ComfyUI里加载自定义节点 → 连接工作流 → 调参出图。

这里有个容易忽略的点：Qwen-Image的文本编码器跟FLUX系列不通用。你不能直接把FLUX的文本编码器拿来给Qwen-Image用，必须用配套的。另外"openvino qwen-image"这个搜索词说明有人在做Intel OpenVINO的推理加速，如果你用的是Intel的核显或者Arc独显，这条路线值得关注，能比纯CPU推理快不少。

2.5 GLM-Image：智谱系的多模态延伸

GLM-Image是智谱AI在多模态方向上的图像生成模型。它的特点在于跟GLM系列语言模型的协同，也就是说它在理解复杂、多层次的文本描述时，能借助语言模型的能力做更精准的语义解析。比如你写一段包含多个条件约束的prompt："一只橘猫坐在窗台上，窗外是下雨的街道，暖色调灯光，胶片质感，景深虚化"，GLM-Image在条件组合的准确性上表现不错。

从部署角度看，GLM-Image的生态开放度介于Seedream和Qwen-Image之间：有API可以用，也有社区在尝试本地部署，但ComfyUI的集成成熟度不如Qwen-Image。如果你的工作流重度依赖ComfyUI，Qwen-Image可能是更顺手的选择；如果你更看重语义理解的深度，GLM-Image值得一试。

3. 部署实操：从环境准备到出图的全流程

3.1 硬件选型与显存估算

在动手之前，先算清楚你的硬件能跑什么。下面这张表是我实测下来的显存占用参考，精度统一按FP16算，出图分辨率1024x1024：

显存估算的逻辑是这样的：模型权重占大头，FLUX.2完整版FP16大约23GB，量化到8bit大约12GB，4bit大约7GB。然后是激活值和注意力矩阵，这部分跟出图分辨率成正比，1024x1024大约需要2-4GB。最后是VAE解码的峰值占用，大约1-2GB。所以如果你用4bit量化的FLUX.2跑1024x1024，8GB显存是理论底线，但实际跑起来会因为碎片化而OOM，建议留出2GB余量。

注意：显存不够时的第一选择不是降分辨率，而是换量化版本。分辨率降到512会严重影响出图质量，而4bit量化对画质的影响在多数场景下可以接受。

3.2 ComfyUI环境搭建与Qwen-Image工作流配置

ComfyUI是目前最主流的本地部署方案，它的节点式工作流虽然上手门槛高，但灵活度是其他方案比不了的。下面以Ubuntu 20.04上部署Qwen-Image 2.1为例，把关键步骤走一遍。

第一步是基础环境。Ubuntu 20.04自带的Python是3.8，但ComfyUI和Qwen-Image的依赖需要Python 3.10以上。我建议用conda建一个独立环境：

conda create -n comfy python=3.10 conda activate comfy

然后是PyTorch的安装。这里要注意CUDA版本跟显卡驱动的匹配，RTX 40系显卡建议用CUDA 12.1以上：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

接着克隆ComfyUI并安装依赖：

git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI pip install -r requirements.txt

Qwen-Image的模型文件需要放到models/checkpoints/目录下，文本编码器放到models/clip/目录下，VAE放到models/vae/目录下。这里最容易出错的地方是文件命名和目录结构，ComfyUI对文件名有特定要求，放错了就加载不出来。

工作流的连接逻辑是这样的：Load Checkpoint节点加载Qwen-Image主模型 →CLIP Text Encode节点分别接正向和负向prompt →Empty Latent Image设定出图尺寸 →KSampler做去噪 →VAE Decode解码 →Save Image保存。Qwen-Image 2.1的推荐参数是：采样器用dpmpp_2m，调度器用karras，步数20-30，CFG scale 7-8。

提示：Qwen-Image对CFG scale比较敏感，设太高会出现色彩过饱和，设太低则画面发灰。建议从7开始试，根据出图效果微调。

3.3 Z-image全黑图问题的完整排查流程

"z-image base 生成的图是黑的"这个问题在社区里问得特别多，我把排查流程整理成一个决策树，你按顺序检查：

首先确认VAE是否匹配。Z-image需要配套的VAE文件，如果你用了SD1.5或者SDXL的VAE，输出大概率是全黑或全灰。检查方法是在ComfyUI里看VAE加载节点的文件名，确认跟模型配套。

其次检查采样步数。Z-image base如果步数低于8，去噪不充分就会出黑图。建议base版本至少跑15步，Turbo版本可以降到4步但不要低于2步。

第三检查模型精度。如果你用的是fp16版本但在某些老显卡上跑，可能会出现数值溢出。换成fp32或者bf16试试。

第四检查prompt是否为空。有些工作流里如果正向prompt为空，模型会输出纯噪声，解码后就是黑图。确保prompt不为空。

第五检查Latent尺寸。如果Empty Latent Image的宽高设成了0或者负数，也会出黑图。确认尺寸是64的倍数，比如1024x1024。

如果以上都排查了还是黑图，那可能是模型文件本身损坏了。重新下载一次，下载后校验文件哈希值。

3.4 OpenVINO加速Qwen-Image的实践

如果你用的是Intel的硬件（核显或者Arc独显），OpenVINO是一条值得走的加速路线。它的原理是把PyTorch模型转换成OpenVINO的IR格式，然后利用Intel硬件的推理加速能力。

转换流程大致是：先用optimum-intel工具把Qwen-Image的模型导出为OpenVINO格式，然后在ComfyUI里装OpenVINO的自定义节点，加载转换后的模型。实测下来，在Intel Arc A770上，OpenVINO加速后的Qwen-Image推理速度比纯CPU快3-5倍，虽然还是比不上NVIDIA显卡，但对于没有N卡的用戶来说是个可用的方案。

注意：OpenVINO的模型转换过程对版本匹配要求很严格，optimum-intel的版本、OpenVINO runtime的版本、模型本身的版本三者必须兼容，否则转换会失败或者推理结果异常。

4. 模型选型与参数调优的实战经验

4.1 什么场景选什么模型：一张决策表

选模型的核心逻辑是匹配你的约束条件。约束条件包括：硬件显存、是否需要本地部署、prompt主要用什么语言、对出图速度的要求、对画质的容忍度。下面这张表是我根据实际项目经验整理的选型参考：

这张表的使用方法是：先确定你的硬约束（显存、是否必须本地），然后在满足硬约束的模型里选最匹配场景需求的。不要为了追求画质硬上跑不动的模型，量化到4bit之后画质优势可能就没了。

4.2 采样器与调度器的搭配逻辑

采样器和调度器的组合对出图质量影响很大，但很多教程只给推荐值不说为什么。我解释一下背后的逻辑。

采样器决定的是如何去噪，调度器决定的是每步去噪的噪声水平怎么变化。打个比方：采样器是开车的方式（匀速、加速、刹车），调度器是路况（平坦、上坡、下坡）。

euler是最基础的采样器，速度快但细节一般，适合快速预览。dpmpp_2m是中高端选择，细节和速度平衡得好，适合大多数场景。dpmpp_3m_sde质量更高但速度慢，适合最终出图。ddim是确定性采样，同种子同参数出图完全一致，适合需要复现的场景。

调度器方面，normal是线性变化，karras是在高噪声阶段多花时间，exponential是指数变化。实测下来，dpmpp_2m+karras是通用性最好的组合，dpmpp_3m_sde+exponential适合追求极致细节。

提示：换采样器或调度器后，CFG scale的最优值会变。比如euler在CFG 7下表现好，dpmpp_2m可能在CFG 5-6下更自然。换参数后要重新试几张。

4.3 量化版本的选择与画质损失评估

量化是显存不够时的救命稻草，但不同量化级别的画质损失差异很大。我实测了FLUX.2在不同量化级别下的表现：

FP8量化基本无损，这是我推荐的首选。4bit量化在多数场景下画质损失轻微，但在细节丰富的场景（比如毛发、纹理）会有可感知的模糊。3bit量化画质损失明显，除非实在跑不动，否则不建议。

量化的原理是把模型权重的数值精度降低，比如从16位浮点降到8位整数。精度降低会引入量化误差，误差累积到一定程度就表现为画质下降。FP8之所以几乎无损，是因为8位浮点的动态范围足够覆盖权重分布，而4bit整数的动态范围就紧张了。

4.4 中文prompt的写法技巧

Qwen-Image和Seedream对中文的理解好，不代表你可以随便写。中文prompt有几个技巧能显著提升出图质量。

第一是主体前置。把最重要的主体放在prompt最前面，模型对开头的词权重更高。比如"一只橘猫，坐在窗台上，窗外下雨"比"窗外下雨，窗台上坐着一只橘猫"的出图更聚焦在猫上。

第二是用逗号分隔语义单元。中文没有空格分词，模型解析长句时容易混淆边界。用逗号把每个语义单元隔开，模型理解更准确。

第三是避免抽象词。"唯美""高级感""氛围感"这类词模型理解不了，换成具体的视觉描述："柔和的光线""低饱和度色调""浅景深虚化"。

第四是负向prompt也要写中文。如果你用中文正向prompt，负向prompt也用中文，保持语言一致。混用中英文可能导致解析异常。

5. 常见问题排查与避坑指南

5.1 出图质量类问题速查

这类问题最让人头疼，因为原因往往不直观。我整理了一份速查表：

排查的逻辑是从硬件到软件、从简单到复杂。先确认显存够不够、模型文件对不对，再看参数设置，最后才怀疑模型本身的能力上限。

5.2 ComfyUI工作流报错排查

ComfyUI的报错信息有时候很晦涩，我总结了几类常见报错和对应处理。

CUDA out of memory是最常见的，处理方法是降分辨率、换量化版本、减少batch size。如果都不行，在启动ComfyUI时加--lowvram参数，它会优化显存调度。

RuntimeError: Expected all tensors to be on the same device通常是模型和输入数据不在同一个设备上。检查是不是有的节点用了CPU有的用了GPU，统一到GPU上。

KeyError: 'model_type'一般是模型文件格式不对，ComfyUI加载不了。确认下载的是ComfyUI兼容的格式，有些原始格式需要转换。

Node not found是自定义节点没装好。用ComfyUI Manager装，或者手动把节点文件夹放到custom_nodes/目录下然后重启。

注意：ComfyUI的日志在终端里看，不要只看网页端的报错。终端里的完整堆栈信息才能定位到具体是哪一行代码出的问题。

5.3 模型下载与文件管理的坑

模型文件动辄几个GB到几十GB，下载和管理本身就是个工程问题。几个经验：

第一，校验哈希值。下载完先算SHA256，跟官方公布的对一下。文件损坏是很多诡异问题的根源。

第二，目录结构要规范。ComfyUI对模型存放路径有约定，checkpoints放主模型，clip放文本编码器，vae放VAE，controlnet放控制网。放错了加载不出来。

第三，命名要清晰。别用默认的乱码文件名，改成模型名_版本_量化级别.safetensors这样的格式，以后找起来方便。

第四，磁盘空间留足。一个完整的模型库轻松上百GB，SSD建议至少留500GB给模型。

5.4 性能优化的几个实用技巧

最后分享几个实测有效的性能优化技巧。

开启xformers能显著降低显存占用和提升速度，安装后在启动参数里加--xformers。使用TensorRT能把推理速度再提一截，但转换过程比较折腾，适合固定工作流的场景。批处理出图比单张出图效率高，因为模型加载的开销被摊薄了，但要注意显存占用是线性增长的。

预热模型也是个技巧：第一次出图往往比较慢，因为模型要从磁盘加载到显存。如果你要连续出多张图，先跑一张低分辨率的预热一下，后面的出图速度会稳定很多。

我在实际项目里最深的体会是：不要迷信单一模型。一个成熟的工作流往往是多个模型配合的，比如用Z-image Turbo快速出草图选构图，再用FLUX.2精修最终图。模型是工具，工作流才是生产力。另外，参数调优没有银弹，同一套参数在不同prompt下的表现可能差很多，多试多记录，建立自己的参数库，比到处找"最佳参数"靠谱得多。