如果你在2026年搜“AI绘画”，大概率会越搜越乱：同一时间冒出SD、Flux、ComfyUI、LoRA、ControlNet一堆新词，中间还夹着各种“SD卡修复工具”“LoRa通信方案”的无关内容。我先把边界划清楚——这里说的SD，全称是Stable Diffusion，是当前开源AI绘画的基石模型，跟数码相机里那张存储卡没有半毛钱关系；而LoRA也是“Low-Rank Adaptation”的缩写，是模型微调技术，不是远距离通信协议。搜索时被这些同名词带偏，几乎是每个新手必踩的坑。
这篇不打算教科书式地从头讲，而是按照我实际使用的顺序，把2026年真正能用上的AI绘画生态串一遍：先讲模型生态怎么选，再讲新模型Flux怎么落地，接着把ComfyUI这个工作流平台拆开，最后把LoRA和ControlNet这两个“上手难度最高但价值最大”的模块讲透。无论你是刚接触AI绘画的新手，还是已经用惯了WebUI想迁移的老人，这篇文章都能提供一个完整的坐标系，帮你大致判断“我该学什么、该避什么坑”。
1. 2026年的AI绘画生态，到底长什么样
1.1 两条主线并存：经典SD生态与Flux新势力
2026年的开源AI绘画，已经不是某一款模型独占的时代了。目前最实用、社区资源最多的，仍然是Stable Diffusion衍生出来的整个软件生态。从最老的SD 1.5，到后来的SDXL，再到SD 3.5系列，这条技术线绵延了几年，积累了海量的LoRA模型、ControlNet控制模型、微调版本和教程，可以说是“船大难掉头但配件齐全”。
另一条主线是Black Forest Labs推出的Flux系列。它走的是MMDiT架构，底层设计理念和SD很不一样，尤其在文字渲染、手指细节、复杂光影上明显更接近商业出图的水准。我到目前为止的经验是：如果你对画面质量要求很高，Flux是最省心的选择；但如果你需要大量可选的LoRA和ControlNet控制方式，原生的SD生态仍然不可替代。
我通常会建议新用户不要二选一，而是两条线都装上。硬要对比的话，可以看这张表，直观感受一下定位差异：
| 模型系列 | 优势 | 劣势 | 适合场景 |
|---|---|---|---|
| SD 1.5 | LoRA/ControlNet资源极多，显存要求低 | 画面精细度一般 | 入门练习、老资源复用 |
| SDXL | 画质均衡，生态较丰富 | 需要6G以上显存才舒服 | 通用出图、商业风格尝试 |
| SD 3.5 | 新架构，文字理解更强 | 插件适配仍不稳定 | 想尝鲜的进阶用户 |
| Flux [dev/schnell] | 画质上限高、文字效果好 | 显存和模型体积都大 | 高质量出图、追求细节 |
1.2 四个关键词，就是整个生态的骨架
很多人学AI绘画，容易被“工具”二字困住，总想着把某款软件学会。但实际上这套生态本质上是四层能力在协作：基础模型负责“画得像”，ComfyUI负责“把流程串起来”，LoRA负责“让模型学会特定风格或角色”，ControlNet负责“让构图听你的话”。
我用一个比较接地气的类比来解释：基础模型像是一个有绘画天赋但没受过定向训练的画师，什么都能画，但每个领域都不精；LoRA是给这位画师戴的“风格眼镜”，戴一副就学会一种画风；ControlNet是给画师铺的“构图草稿纸”，在上面画好轮廓姿势，画师就照着草稿来；而ComfyUI是整间工作室的管理系统，画师怎么开工、用哪些工具、先做哪一步，都由这套系统调度。
如果你能把这四层各自的职责想明白，后面学东西就不会乱了。反过来，如果一上来就疯狂收集各种模型包、插件包，但连“文生图工作流最基本的几个节点”都搭不清楚，那大概率会陷入“下载半天，生成一张糊图”的窘境。
2. SD生态的效率核心：模型、VAE与采样器
2.1 模型文件怎么选、怎么下
开始接触SD时，第一步就要面对模型文件的选择问题。目前主流模型文件格式是.safetensors，它比老的.ckpt更安全，不会在执行时被注入恶意代码，加载速度也更快。从社区下载模型时，我基本只认safetensors后缀的版本。
一个完整的checkpoint大模型文件里，通常打包了三样东西：UNet（负责理解画面结构）、VAE（负责把潜在空间解码成人眼能看到的图像）、CLIP文本编码器（负责理解提示词）。所以在下载模型时，除了看画风是否喜欢，还要注意模型页面标注的训练基础版本——比如是基于SD 1.5训练的，还是基于SDXL训练的。这个信息决定了它适合搭配哪些LoRA、哪些ControlNet，一旦搭错，轻则没效果，重则直接报错。
还有个细节很多人忽略：模型页提供的fp16、fp32、pruned等版本，本质上是精度和体积之间的取舍。fp16在日常使用中几乎看不出差别，但文件大小只占一半，我一般无脑选择fp16或pruned版本。下载渠道方面，建议优先看模型发布者自己的页面和Civitai这类社区，尽量别去一些“整合包满天飞”的论坛，避免下到融了奇怪东西的改版模型。
让新手最头痛的是下载速度。国内访问Hugging Face经常像蜗牛爬，这里教大家一个很稳的办法：设置环境变量HF_ENDPOINT=https://hf-mirror.com，这会让Python的下载库自动走国内镜像节点。实测下载速度能快好几倍，而且这个方法在ComfyUI、SD WebUI里都通用。
2.2 VAE不是玄学：黑图与噪点的真正原因
如果你生成的图像大面积发灰、发黑，或者明显有彩色噪点，十有八九是VAE出了问题。VAE的全称是Variational Autoencoder，它的工作很简单：把UNet生成的“潜在噪声”解码成真正的图像。很多社区模型在发布时并没有把合适的VAE打包进去，或者自带的VAE是早期版本，解码质量很差，这时就需要单独下载一个VAE文件并手动挂载。
以SDXL为例，社区里推荐最多的是sdxl_vae，而在SD 1.5生态里，常用的是vae-ft-mse-840000。我刚开始用SD时就吃过亏，生成了一百多张灰蒙蒙的图，还以为是参数没调好，后来才知道只要在设置里换一下VAE，立刻恢复正常。这里也提醒大家：在ComfyUI里，如果加载checkpoint后仍然出黑图，优先检查VAE Loader节点有没有正确加载单独的VAE文件。
VAE的加载方式不同平台不太一致。WebUI是在设置里指定，ComfyUI则通常会在工作流里单独放一个“Load VAE”节点。为了省事，也可以把下载好的VAE文件放进models/vae目录，然后在工作流里用VAE Loader把它接进解码环节。
2.3 采样器和CFG的搭配速查表
采样器和CFG（Classifier-Free Guidance）是看起来最“参数化”的部分，但也是我踩坑最多的地方。初学者容易盲目调高CFG，觉得“越贴近提示词越好”，结果画面过曝、对比度拉满，整张图完全没法看。CFG一般建议在4到8之间打转，想更贴提示词可以往7、8走，想在风格上放飞一点可以降到4、5。
采样器方面，不同采样器的个性差异很大，我用下来觉得可以这样归类：
| 采样器 | 特点 | 推荐步数 | 适用场景 |
|---|---|---|---|
| Euler a | 出图快、变化大 | 20~30 | 快速尝试风格 |
| DPM++ 2M Karras | 通用性好，细节稳定 | 20~30 | 默认首选 |
| UniPC / DEIS | 适合少量步数出图 | 15~20 | 追求效率 |
| DDIM | 稳定，步数可压缩 | 20~30 | 需要一致性 |
我日常的主力组合是“DPM++ 2M Karras + 步数28 + CFG 6”。这个组合在大多数SDXL模型上效果都稳定，很少出现崩图。但请注意——这不是标准答案，每个模型都有自己的脾气，如果你换了个模型发现出图效果变怪，先别急着调采样器，优先看看模型页有没有推荐参数。
3. Flux：2026年最值得掌握的新模型
3.1 聊聊Flux和SD的本质差异
Flux之所以在2026年讨论度这么高，不是因为它“画得比SD好看一点”，而是它的底层架构改变了很多底层限制。最明显的体验是文字渲染能力——以前用SD系列画带有中文或英文招牌的图，经常出现鬼画符一样的乱码文字，但Flux对文字的符号理解能力强很多，经过简单设置就能生成基本可读的标语、门牌、海报文字。
另一个直观差异是它对提示词的理解。SD系列传统上依赖CLIP文本编码器，对长句、复杂逻辑的理解有上限。而Flux同时使用了CLIP和T5两个文本编码器，T5更擅长处理长文本和指令式描述，这就让Flux可以理解“画面左侧有一盏暖黄色的台灯，光源昏黄，倒映在木桌表面”这种包含明确空间和光线的描述。
这也就解释了为什么Flux对显存和模型文件的要求远高于SD系列。它的模型文件动辄十几GB，加载时需要额外加载T5编码器，所以很多老显卡用户上手Flux的第一反应是“跑不动”。想让Flux跑得起来，通常有两个方向：一是选择社区量化版本，把模型体积压到6~8GB左右；二是通过工作流设置让模型以fp8精度运行，在牺牲少量画质的前提下大幅降低显存占用。
我个人的建议是：显存在8G以上的显卡，完全可以尝试量化版Flux；如果只有6G甚至更低，那就先安心把SDXL跑好，等换了设备再上Flux不迟。
3.2 硬件门槛与量化选择
Flux官方发布的模型有pro、dev、schnell三个版本。pro是收费API，我们本地能用到的主要是dev和schnell。dev版本的画质上限最高，但一般需要蒸馏LoRA辅助加速才能快速出图；schnell版本主打速度快，官方说法是可以4到8步出图，特别适合批量测试。
显存需求方面，原始bf16精度的Flux模型在运行时至少需要16GB以上显存，这直接劝退了很多中低端卡。所以社区很快搞出了GGUF量化格式和NF4版本，能用更小的显存跑起来。如果你想在8GB显存上流畅出图，建议改用GGUF量化版本，配合ComfyUI的Unet Loader（GGUF）节点加载，出图速度和画质都在可接受范围内。
还有一个常被忽略的点：Flux需要额外的T5文本编码器文件（比如t5xxl_fp8_e4m3fn.safetensors），加载它本身也要占用几GB显存。如果显存紧张，建议优先把T5换成fp8精度的版本，它和full精度的视觉差异并不大，但能省下一大块显存。具体的下载目录位置，我放在后面的ComfyUI部署章节里讲，配合工作流一起说更容易理解。
3.3 ComfyUI里的Flux文生图完整工作流
在ComfyUI中搭建Flux工作流，最核心的是理解“模型文件需要分开加载”。SD时代我们习惯用Load Checkpoint一次性加载整个大模型，但Flux最好拆开处理：用Load Diffusion Model加载UNet，用Load CLIP分别加载CLIP-L和T5-XXL两个文本编码器，最后再单独加载VAE（Flux通常使用SDXL的VAE，或者专用的fp16 fix版VAE）。
我建议新手直接复制官方模板，不要手动搭。打开ComfyUI后点击界面右侧的“工作流”菜单，里面一般自带Flux经典模板，加载后把模型路径指向你下载的位置就能跑起来。如果加载时报错“Could not find T5 model”，说明T5文件没被识别，去models/clip目录检查一下文件名是否匹配，文件放对位置后再点“加载默认设置”刷新。
在生成参数上，Flux的CFG通常建议设成1，这和SD系列差距非常大——不要惯性思维直接填6，否则会糊成一团。步数方面，dev版本我用20步左右，schnell版本4到8步就够了。采样器选择上，Euler是Flux用户最常用的，简单稳定，不太需要折腾。
4. ComfyUI：把节点玩明白，才算入对门
4.1 安装：选整合包还是手动部署
ComfyUI是目前最主流的工作流平台，它用节点和连线代替了传统WebUI的“一键出图”界面。对Windows用户，我推荐直接使用秋叶做的整合包，里面的依赖、Python环境、常用插件都是预制好的，下载解压后运行run_nvidia_gpu.bat就能启动。省去配环境的时间，这对刚接触AI绘画的人来说省心太多。
但整合包也有缺点：版本更新滞后，插件冲突排查困难。如果你想长期深入用ComfyUI，我建议跑一段时间后改成手动部署。手动部署其实不复杂，首先是安装Python和Git，然后克隆官方代码仓库，安装依赖后用命令启动。手动部署的另一个好处是能直接使用ComfyUI Manager、更新模型目录结构，自由度比整合包高很多。
启动时常用的命令参数：
python main.py --lowvram --port 8188其中--lowvram会限制显存占用，适合显存不足8G的机器；--port可以自定义访问端口。如果有多台机器，还可以加--listen 0.0.0.0让局域网内其他设备也能访问，不过要注意防火墙设置，别把服务暴露到公网。
4.2 工作流基础语法：节点与连线
ComfyUI的思维方式其实不复杂：把出图过程拆成一个个小步骤，每个步骤是一个节点，节点之间用连线传递数据。最简单的文生图工作流包含五件事：加载大模型、输入提示词、设置采样参数、解码图像、保存图像。对应到节点上就是Checkpoint Loader、CLIP Text Encode、KSampler、VAE Decode、Save Image。
第一次接触这类界面的人很容易被密密麻麻的连线劝退，我的建议是：别急着从零搭，先从模板库里加载官方示例，比如“文生图基础工作流”或者“图生图工作流”，然后逐个节点看。看的时候要养成一个好习惯——关注节点左侧的“输入”和右侧的“输出”，理解数据是从哪一步流到哪一步的。只要看懂一条链路，后面所有工作流都只是一个“变大变复杂的版本”。
很多人分享工作流会贴一张截图，或者给一段JSON文件。JSON文件直接拖进ComfyUI窗口就能自动载入，截图则需要你照着重新连线。这里也提醒一句：从网上随意下载JSON工作流后，务必看清它调用了哪些自定义节点，缺了会报红，通常需要先安装对应插件。
4.3 提速和插件：告别漫长等待
如果你觉得ComfyUI出图慢，八成不是ComfyUI本身慢，而是没有做模型加速。最常用的加速方法是把SDXL模型或Flux模型跑在fp8精度下，这可以在ComfyUI启动参数或模型加载节点中配置。fp8的视觉效果和bf16差别很小，但显存占用和速度都有明显优化。
我还会装一个ComfyUI-Manager插件，它可以可视化管理所有自定义节点，遇到报错缺少节点时，点击“Install Missing Custom Nodes”就能自动补齐，非常省事。另外两个高频插件是ComfyUI-ControlNet（后面讲ControlNet章节会用到）和ComfyUI-VideoHelperSuite（批量处理图片、制作动画时很有用）。插件装得越多越好似乎是个误区，我实际用下来发现，日常稳定出图其实只要四五个核心插件就够了，装太多反而会导致启动变慢甚至冲突。
如果显存还是不够，可以把部分任务放到CPU上跑。ComfyUI里有Force CPU节点，或者调整VAE解码环节为CPU执行。过程会慢一些，但至少不会异常退出。
5. LoRA：从小白到能训练自己的风格
5.1 LoRA原理：给模型戴一副可拆卸的“眼镜”
先澄清一个很容易搜偏的问题：AI绘画里的LoRA，全称是Low-Rank Adaptation，和低功耗广域网通信的LoRa不是同一个东西。如果你在搜索引擎里搜“LoRA通信”，那是另一门技术，别搞混。
LoRA的核心思想特别有意思：它不去改写大模型的全部权重，而是训练两个很小的矩阵，让它们的乘积在特定任务上近似于一个权重增量。用数学表示就是：ΔW = A × B，其中A和B的秩r远小于原始权重矩阵的维度。这样做的好处是训练参数量极小、显存占用小，而且训练出来的LoRA文件通常只有几十到几百MB，随时可以卸载或更换。
理解这点之后，全量微调、freeze微调和LoRA微调的区别就很清楚了：全量微调是把整个模型的所有层都重新训练，效果上限高但成本巨大；freeze微调只训练最后几层或某一部分层，成本降低但灵活性有限；LoRA则是冻结大部分权重，只在旁边加两个低秩矩阵进行训练。现实场景中，90%以上的需求都可以用LoRA解决，尤其是在特定人物、特定画风、特定物体上，训练成本和时间都非常可控。
5.2 一次完整的LoRA训练实操
以训练一个“个人插画风格”的LoRA为例。首先要准备数据集，我建议用10到50张风格统一、主体清晰的图片，图片最好是正方形构图，分辨率不低于512×512。素材收集后处理成训练集时，控制变量很重要，如果画面里有多个人物或复杂背景，会把模型的注意力带偏。
训练工具我用的是kohya_ss，它提供图形界面，适合初学者。重要参数方面，我最常调整的是这几项：
| 参数 | 我的常用值 | 说明 |
|---|---|---|
| 分辨率 | 512或768 | 要与数据集主要分辨率一致 |
| 训练轮数（epochs） | 10~20 | 轮数太多容易过拟合 |
| 学习率 | 1e-4左右 | 太高会学过头，太低效果出不来看 |
| 网络维数（dim） | 32或64 | 决定LoRA容量 |
| 网络alpha | dim的一半 | 控制输出权重强度 |
关于过拟合问题，我见的案例特别多：训练轮数一多，模型确实能画“很像”某个风格，但生成其他姿势、其他场景时容易崩坏，输出的图像几乎都复制了训练集里的构图。这种情况下，我一般减半epochs、调低学习率，或者扩充数据集。训练结束后会输出一个.safetensors文件，这个就是LoRA最终产物了。
5.3 LoRA在ComfyUI/WebUI中的调用与常见问题
在ComfyUI里调用LoRA，需要用到Load LoRA节点。这个节点会接收一个基础模型，再接收LoRA文件，然后输出一个被改造过的新模型。把它串在Checkpoint Loader和KSampler之间即可。记得在提示词里加入触发词，例如训练时在描述里反复出现的“xxx style”这类的词，一定要原样写上，否则LoRA不会生效。
WebUI用户就简单多了，在文生图界面下方找到LoRA选项卡，点一下就会自动把触发词加到提示词里。如果出现“LoRA加载了但完全没变化”，我通常按三步排查：先看模型基底是否匹配（SD 1.5的LoRA不应该用在SDXL模型上），再看触发词有没有缺失，最后看LoRA权重是否调得太低（建议先调到0.8左右）。
关于社区里常提到的网络词“全量微调、freeze微调以及lora微调”，这里也可以补充一句：如果你做的是偏开发向的工作，把LoRA应用到大语言模型或图像模型之外的领域，比如OpenVLA这类机器人操作模型，思路是一样的——冻结基座，只训练低秩适配器。这个思路在2026年已经非常通用，已经完全超出了AI绘画的范围。
6. ControlNet：让每一笔都有边界
6.1 ControlNet原理与常用条件类型
ControlNet的提出，解决了纯粹靠提示词控制构图不稳定的问题。论文思路是：在原始扩散模型旁边加一个“可训练的条件分支”，把Canny边缘图、深度图、姿态骨架等条件一起送入网络，让生成过程遵循这个额外约束。简单来说，它给扩散模型提供了一份“参考稿”，让AI知道什么位置该是什么形状。
实际使用中，ControlNet要搭配“预处理器”使用。预处理器负责把输入图片转换成模型能理解的条件图，比如把一张人物照片转换成骨架姿态图。如果预处理器选错了，后面的ControlNet几乎等于白接。我用得最多的几种类型：Canny边缘适合保留物体轮廓细节；Depth深度图适合控制空间层次；OpenPose骨架适合人物姿势；Lineart线稿适合把线稿变成上色成品。
| ControlNet类型 | 预处理器 | 适用场景 |
|---|---|---|
| Canny | Canny边缘检测 | 产品结构、建筑轮廓 |
| Depth | MiDaS/Zoe | 多物体层次、背景深度 |
| OpenPose | DWPose/OpenPose | 人物姿势、动态动作 |
| Lineart | Lineart提取器 | 线稿上色、漫画风格 |
| MLSD | MLSD直线检测 | 室内布局、直线透视 |
6.2 OpenPose姿态控制实战
拿最常见的“用OpenPose控制人物姿态”来举例。在ComfyUI里搭建时，链路大致是：Load Image（上传一张示例人物图）→ OpenPose预处理器（提取姿态骨架）→ Load ControlNet Model（加载OpenPose的ControlNet模型）→ Apply ControlNet（应用条件）→ 最后和文本编码结果一起送入KSampler。
实际操作中，我会把ControlNet的Strength参数稳定在0.6到0.9之间。如果强度太接近1，姿势会被死死锁住，人物衣服和细节都会变得僵硬；太低则等于没控制。还有一个容易被忽略但很关键的参数是Start Percent和End Percent，它控制ControlNet在采样的哪个阶段起作用。我一般让它在前期参与（比如0.0到0.6），这样先确定构图再利用模型自由发挥细节，效果比全程生效更自然。
如果接到一个姿势完全没变化，多半是预处理器没有输出有效骨架图，或ControlNet模型没有真正加载成功。如果画面崩坏但姿势对，一般是Strength过高或者CFG设置不匹配导致的“过度约束”。
6.3 多ControlNet叠加与Flux新生态
单个ControlNet只是“单一参考”，更常用的玩法是同时叠加多个条件。比如在产品设计里，我经常把Canny边缘和Depth深度图同时接进去，Canny守住外形轮廓，Depth守住前后层次，这样换风格时物体结构不会飞掉。ComfyUI支持多个ControlNet同时接入，Apply ControlNet节点可以链式串联，每个通道单独设置强度，思路类似于用多个控制器共同稳定生成方向。
现在SD 1.5生态的ControlNet最全，SDXL次之，Flux的ControlNet生态目前还在追赶阶段。如果你想在Flux上使用ControlNet，建议去社区找适配Flux的官方ControlNet模型。我自己实测下来的感受是：Flux的ControlNet可控性比SD稍弱，但已经有了不错的可用性，尤其搭配Canny和Depth，基本能够满足常见的“底图重绘”需求。
7. 踩坑实录：问题与排查速查表
7.1 黑图、OOM、LoRA不生效
这一节把我这两年实际遇到的高频问题集中写出来，每一条都是真金白银趟过来的经验。
| 问题现象 | 常见原因 | 排查与解决 |
|---|---|---|
| 生成图全黑/全灰 | VAE未加载或加载错误 | 单独加载VAE，或更换社区推荐的VAE文件 |
| 显存OOM（out of memory） | 模型过大、工作流太复杂 | 降低分辨率；使用量化模型；开启--lowvram |
| LoRA加载了但没效果 | 基底模型不匹配/触发词缺失 | 确认LoRA的训练基底版本，补全触发词，提高权重 |
| ControlNet完全失效 | 预处理器选错/模型未加载 | 检查预处理节点输出，确认模型文件放对路径 |
| Flux加载报错“CLIP not found” | T5文本编码器未下载 | 在models/clip目录放入T5文件并重启ComfyUI |
| 下载模型很慢 | 网络节点问题 | 设置HF_ENDPOINT镜像节点，或用下载工具 |
关于OOM我还要多说一句，2026年许多新显卡都开始支持对显存和内存进行统一调度，但老显卡用户千万不要指望系统自动解决。手动降低显存压力的思路优先级是：先换量化版模型，再降低分辨率，最后才是启用CPU offload。换量化版模型的画质损失肉眼几乎看不出，但速度提升非常明显。
7.2 工作流管理与模型维护的心得
聊完了排错，最后分
