ComfyUI 如何加载 LoRA、DreamBooth 等微调模型？操作步骤详解

在如今的 AI 图像生成领域，Stable Diffusion 已经成为内容创作者和开发者的标配工具。但当你想让模型画出某个特定角色、独特艺术风格，甚至是你家猫的模样时，标准模型往往“认不出来”——它没见过。

这时候就需要微调技术出场了。LoRA 和 DreamBooth 正是目前最主流的两种方案，而 ComfyUI 凭借其节点式架构，成了高级用户构建定制化生成流程的首选平台。相比传统 WebUI 的线性操作，ComfyUI 允许你精确控制每一步：从模型加载、权重注入到提示词编码，一切尽在掌握。

那么问题来了：如何在 ComfyUI 中真正用好这些微调模型？不是简单拖个节点就完事，而是理解背后的机制、规避常见坑点，并构建可复现的工作流。这才是高手和普通用户的分水岭。

---

我们先来看 LoRA —— 这个如今几乎人人必用的技术，到底怎么在 ComfyUI 里被“激活”的？

LoRA，全称 Low-Rank Adaptation，核心思想很聪明：我不重训整个大模型，只在关键层（比如注意力模块）插入少量可训练参数。具体来说，原始权重矩阵 $ W $ 不动，新增一个低秩分解 $ \Delta W = A \cdot B $，其中 $ r \ll d $，参数量可能只有原模型的千分之一。训练快、体积小、还能叠加使用，简直是为 ComfyUI 这种模块化系统量身定做的。

你在 HuggingFace 上下载的 .safetensors 文件，通常就是这样一个增量包。当 ComfyUI 加载时，流程其实是这样的：

1. 先通过 CheckpointLoaderSimple 载入基础模型（如 SD v1.5）；
2. 再由 LoraLoader 节点读取 LoRA 权重文件；
3. 系统自动识别该 LoRA 是作用于 U-Net 还是文本编码器（Text Encoder），并根据元数据定位到具体的子模块（如 to_k, to_q 层）；
4. 将 LoRA 的 $ A $ 和 $ B $ 矩阵相乘后，乘以用户设定的 strength 值，再加到原始权重上；
5. 后续的前向传播就会带上这份“定制记忆”。

这个过程完全是动态的，意味着你可以随时切换不同的 LoRA，甚至在同一工作流中叠加多个。比如先加一个“动漫风”LoRA，再叠一个“赛博朋克灯光”，最后来个“写实皮肤纹理”，组合出独一无二的效果。

这也解释了为什么 LoRA 比完整微调更受青睐。看看这个对比就明白了：

维度	LoRA	完整微调
模型大小	<100MB	>4GB
显存占用	极低	高，需重新加载大模型
可组合性	✅ 支持多 LoRA 叠加	❌ 单一模型，无法混合
推理兼容性	所有支持 LoRA 的前端通用	专用，迁移困难

所以，在 ComfyUI 里，LoRA 不只是“能用”，而是“应该优先用”。它的设计哲学和节点系统的灵活性完美契合：每一个 LoRA 就是一个功能插件，按需启用，即插即用。

实际操作中，很多人会卡在第一步：文件放哪？其实很简单，把 .safetensors 文件丢进 ComfyUI/models/loras/ 目录就行。重启界面后，LoraLoader 节点就能在下拉菜单里看到它了。

但别急着连节点。这里有个关键细节：LoRA 强度（strength）并非越高越好。设成 1.0 看似“完全生效”，但容易导致过拟合或风格溢出。经验上，0.6~0.8 是比较安全的区间，既能体现特征又不至于破坏整体协调性。你可以建两个 LoraLoader 节点，分别设置不同强度，对比输出效果。

再进一步，有些 LoRA 只修改文本编码器（Text Encoder），有些则同时影响 U-Net 和 Text Encoder。如果你发现加了 LoRA 后图像变化不大，可能是因为你的工作流用了 Empty Latent Image + 高采样步数，而文本编码没被正确传递。务必检查 CLIPTextEncode 节点是否连接到了正确的文本输入链路。

说到这，不妨看看底层逻辑。虽然 ComfyUI 是图形界面，但它本质跑的是 Diffusers 风格的管道。下面这段伪代码，揭示了 LoRA 注入的真实过程：

import torch
from diffusers import StableDiffusionPipeline

pipe = StableDiffusionPipeline.from_pretrained("runwayml/stable-diffusion-v1-5")
lora_weights = torch.load("path/to/lora.safetensors")

# 注入至 UNet 和 Text Encoder
pipe.unet.load_attn_procs(lora_weights)
pipe.text_encoder.load_attn_procs(lora_weights)

prompt = "a beautiful cyberpunk girl, wearing neon glasses"
image = pipe(prompt, num_inference_steps=30).images[0]

没错，LoraLoader 节点干的就是这件事。只不过你不用写代码，点几下鼠标就行。这种封装极大降低了使用门槛，但也容易让人忽略背后的依赖关系——比如，如果 LoRA 训练时用的是 SDXL，而你加载在 SD v1.5 上，结果自然对不上号。

---

再来看 DreamBooth。如果说 LoRA 是“轻改装”，那 DreamBooth 就是“深度定制”。它最早由 Google 提出，目标很明确：给我几张照片，我要把这个对象“种”进模型里。

典型的例子是“sks cat”——用三五张自家猫咪的照片，配合特殊标识符 sks，训练后只要输入 sks cat in a spacesuit，就能生成这只猫穿宇航服的样子。关键是，它不只是复制训练图，而是学会了泛化。

DreamBooth 的实现方式有两种：

1. 完整模型导出：把全部微调后的权重保存为一个新的 .ckpt 或 .safetensors 文件；
2. LoRA 形式导出：仅保存增量部分，运行时注入基础模型。

在 ComfyUI 中，前者需要用 CheckpointLoaderSimple 直接加载；后者则走 LoraLoader 流程。推荐哪种？毫无疑问是后者。原因还是那个老问题：效率与灵活性。

完整 DreamBooth 模型动辄 4GB 以上，不仅占空间，还锁死了基础模型。你想换个底模融合风格？不行，得重新训练。而 LoRA 版本呢？同一个 my_dog_lora.safetensors，可以注入 SD v1.5、v2.1 甚至 SDXL，适配性直接拉满。

而且训练阶段也可以更高效。Hugging Face 的 Diffusers 库已经原生支持 DreamBooth + LoRA 训练模式，流程如下：

from diffusers import StableDiffusionPipeline, DreamBoothTrainer

pipe = StableDiffusionPipeline.from_pretrained("runwayml/stable-diffusion-v1-5", torch_dtype=torch.float16)
trainer = DreamBoothTrainer(
    model=pipe,
    train_dataset=dataset,
    identifier_token="sks",
    class_token="cat",
    output_dir="output"
)
trainer.train()
trainer.save_model("output/lora-dreambooth-cat.safetensors", safe_serialization=True)

训练完成后，得到的就是一个标准 LoRA 文件，直接扔进 ComfyUI 就能用。这种方式既保留了 DreamBooth 的高保真还原能力，又继承了 LoRA 的轻量化优势，堪称“鱼与熊掌兼得”。

不过要注意，DreamBooth 对提示词非常敏感。必须使用训练时定义的标识符（如 sks），否则模型压根“不认识”你要画谁。常见的错误是只写“my cat”，却不带 sks，结果生成一堆普通猫咪。

还有个小技巧：如果你发现生成的人物脸部扭曲，可能是训练样本太少或迭代过多导致过拟合。可以在工作流中加入负向提示词 "deformed, blurry, bad anatomy" 来压制异常输出，或者降低 LoRA 强度让基础模型“拉一把”。

---

现在我们把镜头拉远，看整个工作流是如何组织的。

在 ComfyUI 中，一个典型的 LoRA/DreamBooth 生成流程长这样：

graph TD
    A[CheckpointLoaderSimple] --> B[LoraLoader]
    B --> C[CLIPTextEncode (Prompt)]
    B --> D[CLIPTextEncode (Negative Prompt)]
    C --> E[KSampler]
    D --> E
    F[Empty Latent Image] --> E
    E --> G[VAEDecode]
    G --> H[SaveImage]

所有节点构成一张有向无环图（DAG），数据沿边流动。你会发现，LoraLoader 的输出同时连接到了两个地方：一个是后续的文本编码器，另一个其实是隐式的——它修改了 CheckpointLoaderSimple 输出的模型实例。

也就是说，模型本身是被“原地更新”的。这也是为什么你不能并行运行两个不同 LoRA 的任务，除非显式复制模型副本。这点和传统 WebUI 每次都加载独立模型的行为不同，是节点系统特有的“状态共享”特性。

实战中常遇到的问题也不少。比如：

• 现象：生成结果没有体现出自定义特征
  最可能的原因是提示词没用对标识符。确认是否写了 sks man 而不是 a man。其次检查 LoRA 是否真的加载成功——节点有没有报错？文件路径是否存在？命名有没有中文或空格？

• 现象：显存溢出（OOM）
  特别是在 RTX 3060/3070 这类 8GB 显存设备上，同时加载大模型 + 多个 LoRA + 高分辨率 VAE 很容易爆。解决方案包括：

• 使用 --lowvram 启动参数；
• 分离 VAE 解码步骤，用低分辨率 latent 先采样再放大；

• 优先选择 FP16 模型，减少内存占用。

• 现象：风格融合混乱
  同时加载“油画风”和“赛博朋克”LoRA，结果画面一团糟。这不是模型的问题，而是权重叠加的数学本质决定了它们会相互干扰。建议做法是：逐个测试强度，找到平衡点，或者干脆分开生成再后期合成。

工程层面也有不少最佳实践值得遵循：

1. 统一管理模型文件
   所有 LoRA 放在 models/loras/ 下，命名规范如 lora_char_miku_v2.safetensors，避免杂乱无章。

2. 保存可复现的工作流
   ComfyUI 支持导出 .json 或 .flow 文件，包含所有节点配置和连接关系。这是团队协作的关键，确保别人打开就能跑出同样结果。

3. 记录实验参数
   哪个 LoRA、强度多少、用了什么提示词模板，最好单独建个文档。不然一个月后再想复现某张惊艳图，只能靠猜。

4. 安全第一
   第三方 LoRA 虽然方便，但 .ckpt 文件可能包含恶意代码。.safetensors 格式通过序列化保护机制规避了这个问题，应优先选用。

---

回过头看，ComfyUI 的真正价值，不在于它有多“可视化”，而在于它把复杂的 AI 推理过程拆解成了可审计、可调试、可共享的单元。每一个节点都是一个黑盒接口，输入输出清晰，逻辑透明。

当你在 LoraLoader 上滑动 strength 滑块时，背后是一整套从线性代数到工程部署的技术栈在支撑。LoRA 的低秩分解、DreamBooth 的先验保留损失、Diffusers 的模块化设计、safetensors 的安全加载机制……这些都不是孤立存在的。

而你能做的，就是把这些积木搭好，然后看着 AI 把你的想法变成图像。这不仅是技术的应用，更是一种新的创作范式。

未来，随着更多微调方法（如 LyCORIS、IAF-Simple）的出现，ComfyUI 的节点生态也会持续进化。但万变不离其宗：理解原理的人，永远比只会点按钮的人走得更远。