当前位置：首页 > news >正文

Dreambooth云训练实战：用Colab Notebook零环境配置跑通人像微调

news 2026/6/21 20:30:07

1. 项目概述：为什么在Notebook里跑Dreambooth，而不是直接装本地SD？

“Stable Diffusion Tutorial Part 1: Run Dreambooth in Notebooks”这个标题看着像入门课，但实际踩中了当前中文用户最真实的痛点——不是不想学Dreambooth，而是卡在第一步：根本跑不起来。我带过二十多个毕设学生、帮过三十多位设计师朋友搭SD环境，90%的人第一次失败，不是因为不懂LoRA或文本编码器，而是因为显存报错、CUDA版本冲突、依赖包循环降级、或者连pip install torch都提示“no matching distribution”。这时候，Jupyter Notebook不是“教学辅助工具”，而是唯一能绕过系统环境地狱的逃生通道。

核心关键词“Stable Diffusion”“Dreambooth”“Notebooks”三者组合，本质是解决一个现实矛盾：Dreambooth需要微调整个UNet权重，对显存和算力要求极高（至少12GB VRAM），而绝大多数人的本地机器只有RTX 3060（12GB）甚至3050（6GB），装完驱动、CUDA、PyTorch再塞进WebUI，显存余量连加载基础模型都不够。而Notebook（特指Google Colab、Kaggle或国内可稳定访问的云Notebook平台）直接提供A100/V100级别的GPU，预装好CUDA 11.8 + PyTorch 2.0.1 + xformers，你只需要点几下“运行全部”，5分钟内就能看到第一张微调后的图像生成出来。这不是偷懒，是工程效率的合理取舍——就像盖楼先搭脚手架，而不是徒手砌砖。

适合谁来参考？三类人最刚需：一是计算机/数字媒体专业做毕设的学生，时间紧、答辩压着，没精力折腾Linux内核兼容性；二是平面/插画师想快速定制个人风格模型，但对命令行有心理阴影；三是刚接触AI绘画的技术转行者，需要从“能出图”建立信心，再逐步深入架构。注意，这里说的Notebook不是指本地VS Code里开个.ipynb文件——那种方式依然要自己配环境。我们谈的是云端托管式Notebook，它的价值在于把“环境配置”这个黑盒，压缩成一个可复现、可分享、可回滚的代码单元。比如你调试好一个Dreambooth训练脚本，导出为.ipynb，发给同事，他点开就能跑，中间不涉及任何“你电脑上装了什么”的玄学问题。这才是标题里“Part 1”的真实含义：它不是教程的起点，而是生产落地的第一块基石。

2. 核心设计逻辑：为什么选Colab而非Kaggle？为什么用diffusers而非webui？

2.1 平台选型：Colab免费GPU的隐藏规则与实测稳定性

很多人一上来就问：“Kaggle不是也免费送GPU吗？为什么教程偏爱Colab？”这个问题我拿三台设备连续测试了47天，结论很明确：Colab的A100免费时长更可控，Kaggle的P100资源更稀缺且易中断。具体数据如下：

平台	免费GPU型号	单次最长运行时长	每日总可用时长	中断率（>10min训练）	实测显存可用率
Google Colab Pro	A100 40GB	24小时	无硬限制（Pro版）	<3%	38.2GB（xformers启用后）
Google Colab Free	T4 16GB	12小时	每日约10-12小时	~12%	14.1GB
Kaggle GPU	P100 16GB	30小时/周	周限额制	~28%	12.6GB（常因后台进程占用）

关键差异在“中断率”。Kaggle的GPU会因检测到“非Kaggle竞赛相关操作”主动终止内核，尤其当你加载自定义数据集（如本地上传的100张人像照片）或调用HuggingFace Hub私有模型时，触发风控的概率极高。而Colab Free虽然也有12小时上限，但它只按“内核活跃时间”计时，你暂停训练、去改参数、喝杯咖啡，时间不消耗。更重要的是，Colab支持挂载Google Drive，这意味着你的训练数据、模型检查点、日志文件全存在自己的网盘里，关机不丢——这点对毕设党简直是救命稻草，再也不用担心“训练到第800步突然断连，重头再来”。

提示：Colab Free的T4显卡跑Dreambooth确实吃力（batch_size只能设1），但足够完成Part 1的全流程验证。如果你需要加速，建议用Colab Pro（$10/月），它提供的A100能让训练速度提升3.2倍，且支持--gradient_checkpointing参数开启，显存占用直降40%。

2.2 框架选型：diffusers库比WebUI更适合Notebook的底层原因

另一个常被忽略的关键决策是：为什么不用Automatic1111 WebUI的Dreambooth扩展，而坚持用HuggingFace的diffusers库？答案藏在代码执行模型里。WebUI本质是Flask服务，所有操作通过HTTP请求触发，你在Notebook里调用它，等于“在Python里启动一个Web服务器，再用requests发POST请求过去”，多了一层网络通信开销。而diffusers是纯Python库，所有训练逻辑（如Trainer.train()）直接在当前Python进程中执行，内存地址、梯度张量、优化器状态全部在同一个上下文里流转。这带来三个硬性优势：

第一，调试精度高。当Loss突然飙升，你可以直接在训练循环里加print(loss.item())，甚至用torch.autograd.gradcheck()验证梯度计算是否正确。而在WebUI里，你只能看日志文件，等它写完再打开，错过关键瞬态。

第二，参数控制粒度细。Dreambooth训练有17个关键超参（如learning_rate,train_batch_size,max_train_steps），diffusers允许你用字典形式动态传入：

training_args = TrainingArguments( output_dir="./dreambooth-model", per_device_train_batch_size=1, gradient_accumulation_steps=4, learning_rate=5e-6, num_train_epochs=1, report_to="tensorboard" )

而WebUI的UI界面最多暴露5个参数，剩下12个得手动改源码，这对Notebook用户等于宣判死刑。

第三，与Notebook生态天然融合。你可以用matplotlib实时画Loss曲线，用wandb一键同步实验指标，甚至把训练过程封装成函数，配合ipywidgets做成交互式滑块调节学习率——这些在WebUI里要么做不到，要么要重写前端。

注意：别被“diffusers看起来代码多”吓退。我统计过，一个完整Dreambooth训练脚本（含数据加载、模型加载、训练循环、保存）在diffusers里只需127行，而WebUI的Dreambooth扩展源码超过2300行。前者是“给你一把瑞士军刀”，后者是“给你一栋装修好的别墅，但你想换个灯泡得先考电工证”。

3. 实操全流程拆解：从零开始跑通Dreambooth训练的7个关键环节

3.1 环境初始化：三行命令搞定CUDA与PyTorch兼容性

在Colab里，第一步永远不是写训练代码，而是确认GPU驱动与PyTorch版本握手成功。很多人跳过这步，直接pip install diffusers，结果训练时爆CUDA error: no kernel image is available for execution on the device。这是因为Colab默认的CUDA版本（12.1）与PyTorch 2.0.1预编译包要求的CUDA 11.8不匹配。解决方案不是降级CUDA（不可能），而是换用CUDA 11.8兼容的PyTorch：

# 在Colab第一个cell执行（必须！） !nvidia-smi # 查看GPU型号和CUDA版本（通常显示12.x） !pip uninstall -y torch torchvision torchaudio # 彻底清空旧包 !pip install torch==2.0.1+cu118 torchvision==0.15.2+cu118 --extra-index-url https://download.pytorch.org/whl/cu118

这三行命令背后有严格逻辑：nvidia-smi输出的CUDA版本只是驱动支持的最高版本，实际运行时PyTorch会找自己编译时绑定的CUDA runtime。PyTorch 2.0.1官方wheel包只提供cu117和cu118两个版本，而Colab的驱动向下兼容cu118，所以必须强制安装cu118版本。实测发现，如果跳过uninstall直接install，pip会因依赖冲突静默失败，后续所有操作都建立在错误基础上。

实操心得：每次新开Colab notebook，务必先运行这三行。我曾因漏掉uninstall，在同一个notebook里反复调试3小时，最后发现torch.cuda.is_available()返回False——根源就是PyTorch和CUDA runtime没对上号。

3.2 数据准备：为什么必须用15-25张图，且要包含3种构图？

Dreambooth对数据质量极度敏感，不是“越多越好”，而是“精准打击”。我分析过132个成功案例的训练集，发现最优解是18±3张图，且必须满足“三三制”构图法则：

3张正面半身照：肩部以上，纯色背景（白墙/灰幕最佳），人脸占画面60%-70%，用于学习面部结构；
3张侧脸/45度角照：展示颧骨、下颌线轮廓，避免头发遮挡耳朵，用于校准3D空间感；
3张全身/场景照：人物在自然光下站立/行走，背景有简单纹理（木地板、窗帘），用于学习姿态与光影关系；
剩余9张作为补充：包括特写（眼睛、嘴唇）、戴眼镜/帽子的变体、不同表情（微笑/严肃），但严禁使用美颜过度、AI生成图、或多人合影。

为什么不能少于15张？因为Dreambooth的损失函数包含两项：重建损失（Reconstruction Loss）和先验保留损失（Prior Preservation Loss）。前者靠你的18张图拟合，后者靠模型自身对“person”类别的先验知识（来自LAION数据集）防止过拟合。如果图太少，先验损失权重会失衡，导致模型把“你的脸”记成“所有人的脸”，生成结果出现“脸泛滥”（同一张脸出现在不同角色身上）。

注意：所有图片必须统一尺寸。不要用手机原图（4000×3000），直接缩放到512×512像素。Colab的T4显卡处理大图会触发OOM，且SD的VAE编码器输入固定为512×512，缩放是必须步骤。我写了个一键预处理脚本：

from PIL import Image import os def resize_images(input_folder, output_folder, size=(512, 512)): os.makedirs(output_folder, exist_ok=True) for img_name in os.listdir(input_folder): if img_name.lower().endswith(('.png', '.jpg', '.jpeg')): img = Image.open(os.path.join(input_folder, img_name)) img = img.resize(size, Image.LANCZOS) # 用LANCZOS抗锯齿 img.save(os.path.join(output_folder, img_name)) resize_images("./raw_photos", "./processed_photos")

3.3 模型加载：如何选择base model才能兼顾速度与效果？

标题里没提模型，但这是决定成败的隐性关键。很多人直接用runwayml/stable-diffusion-v1-5，结果训练3小时出图全是塑料质感。真正该用的是经过LoRA微调的轻量基座，比如hakurei/waifu-diffusion或prompthero/openjourney。原因很简单：v1-5是通用模型，对“人像”理解停留在“person”这个宽泛token上；而waifu-diffusion在二次元人像数据上专项优化过，它的文本编码器对“anime style, detailed eyes, soft shading”这类提示词响应更灵敏，相当于给Dreambooth装了个精准制导系统。

具体选型逻辑如下表：

Base Model	训练速度（T4）	人像细节表现	适用风格	下载链接
`runwayml/stable-diffusion-v1-5`	★★☆☆☆（慢）	一般（需更多step）	写实/通用	HuggingFace Hub
`hakurei/waifu-diffusion`	★★★★☆（快）	优秀（眼睛/发丝锐利）	二次元/插画	HuggingFace Hub
`stabilityai/stable-diffusion-2-1`	★★☆☆☆（慢）	写实但偏冷色调	高清摄影	HuggingFace Hub
`SG161222/Realistic_Vision_V2.0`	★★★☆☆（中）	极致写实（皮肤纹理）	真人肖像	Civitai

实测数据：用waifu-diffusion基座，18张图训练800步，生成效果已接近v1-5训练2000步的水平。速度提升的背后是模型权重的“领域适配度”——就像让一个专攻眼科的医生去治牙疼，肯定不如牙医快。

提示：在Colab中加载模型时，务必加variant="fp16"参数：

pipe = StableDiffusionPipeline.from_pretrained( "hakurei/waifu-diffusion", torch_dtype=torch.float16, variant="fp16", # 关键！否则自动加载fp32，显存直接爆 use_safetensors=True )

variant="fp16"告诉HuggingFace优先下载半精度权重（.safetensors文件），比全精度小50%，加载快2倍，且T4显卡对fp16运算原生支持。

3.4 训练参数配置：learning_rate和max_train_steps的黄金比例

Dreambooth最反直觉的参数是学习率（learning_rate）。新手常设1e-4，结果5分钟Loss就崩到nan。真相是：Dreambooth需要极低的学习率，但必须配合足够多的训练步数。我的经验公式是：

learning_rate = 5e-6 × (18 / 实际图片数) max_train_steps = 1200 × (实际图片数 / 18)

即以18张图为基准，图片每增减1张，学习率按比例缩放，总步数同理。例如你只有12张图，learning_rate应设5e-6 × (18/12) = 7.5e-6，max_train_steps设1200 × (12/18) = 800。

为什么？因为Dreambooth的本质是“在预训练权重上做微小扰动”，不是从头训练。高学习率会让优化器暴力覆盖原始权重，破坏模型对“person”类别的先验知识，导致生成图出现“鬼脸”（五官错位、多只眼睛）。而足够多的步数，让梯度下降能沿着损失曲面平缓滑行，找到那个既拟合你的数据、又保留先验的平衡点。

在diffusers中，这些参数通过TrainingArguments传入：

training_args = TrainingArguments( output_dir="./dreambooth-output", per_device_train_batch_size=1, # T4只能设1 gradient_accumulation_steps=4, # 等效batch_size=4 learning_rate=5e-6, max_train_steps=800, report_to="tensorboard", logging_dir="./logs", save_steps=200, # 每200步存一次检查点 seed=42 )

其中gradient_accumulation_steps=4是T4用户的救命参数——它让模型前向传播4次、累积梯度后再反向更新，等效于batch_size=4，大幅提升训练稳定性。

实操心得：第一次训练务必设save_steps=100，而不是默认的500。因为前300步Loss波动极大，存多几个检查点，方便后续用--resume_from_checkpoint从中断处续训，避免重头再来。

3.5 训练过程监控：如何读懂TensorBoard里的Loss曲线？

启动训练后，别干等。立刻在Colab新cell里启动TensorBoard：

%load_ext tensorboard %tensorboard --logdir ./logs

你会看到两条核心曲线：train_loss（蓝色）和learning_rate（橙色）。重点看train_loss的形态：

健康曲线：前100步快速下降（从2.5→0.8），之后缓慢收敛，在0.4-0.6区间小幅震荡。这说明模型正在有效学习。
过拟合曲线：Loss前200步降到0.3，之后反弹到0.9并持续上升。此时必须立即中断，降低学习率或增加先验损失权重。
欠拟合曲线：Loss始终在1.8-2.2之间横盘，毫无下降趋势。大概率是学习率太低，或数据质量差（如全是模糊图）。

我整理了Loss异常的速查表：

Loss曲线特征	可能原因	紧急处理方案
前50步Loss=nan	学习率过高或梯度爆炸	立即设`learning_rate=1e-6`，加`--max_grad_norm=1.0`裁剪梯度
200步后Loss>1.5	数据分辨率不足或背景干扰大	重新裁剪图片，确保人脸居中，背景纯色
Loss在0.5上下剧烈抖动（±0.3）	batch_size太小或梯度累积不足	增加`gradient_accumulation_steps`到8（T4需配合`per_device_train_batch_size=1`）
Loss平稳在0.4但生成图模糊	先验损失权重不足	在训练脚本中调高`--prior_loss_weight=0.8`（默认0.5）

注意：TensorBoard的log目录必须和TrainingArguments.output_dir一致，否则看不到曲线。很多新手把logdir写成./logs，但训练参数里output_dir是./dreambooth-output，导致监控失效。

3.6 模型保存与加载：safetensors格式的三大不可替代优势

训练完成后，模型默认保存在./dreambooth-output目录。但别急着用！必须先做格式转换：

# 将diffusers格式转为safetensors（推荐） !pip install safetensors !python convert_diffusers_to_sd.py \ --model_path ./dreambooth-output \ --checkpoint_path ./dreambooth-lora.safetensors \ --half

为什么必须转safetensors？三个硬理由：

安全性：.bin或.ckpt文件可执行任意Python代码，下载别人分享的模型可能中木马；而safetensors是纯张量存储格式，加载时不会执行代码，彻底杜绝安全风险。
加载速度：实测对比，T4加载dreambooth-lora.safetensors（286MB）耗时1.3秒，加载同内容.bin（412MB）耗时3.7秒，快2.8倍。
跨平台兼容：safetensors被WebUI、ComfyUI、Fooocus全系支持，你今天在Colab训的模型，明天就能直接拖进本地WebUI使用，无需任何转换。

转换后，你会得到dreambooth-lora.safetensors文件。把它下载到本地，放进WebUI的models/Lora/目录，重启WebUI，在提示词里加上<lora:dreambooth-lora:1>即可调用——这就是标题里“Run Dreambooth”的终极交付物。

实操心得：转换脚本中的--half参数至关重要。它把权重转为float16，文件体积缩小50%，且T4对fp16推理原生支持，生成速度提升40%。漏掉这个参数，你的模型在WebUI里可能报“out of memory”。

3.7 生成效果验证：用3组提示词做压力测试

模型不是保存完就结束，必须用结构化提示词验证。我设计了三组黄金测试集，每组5条提示，覆盖不同维度：

第一组：基础身份识别（验证是否记住“你”）

photo of a person, realistic, studio lighting
portrait of a person, medium shot, shallow depth of field
a person sitting on a sofa, natural light
full body photo of a person, street background
person wearing glasses, close-up, detailed skin texture

第二组：风格迁移（验证泛化能力）

anime style portrait of a person, vibrant colors, detailed eyes
cyberpunk portrait of a person, neon lights, rain effect
oil painting of a person, impasto technique, visible brush strokes
sketch drawing of a person, pencil on paper, cross-hatching
3d render of a person, unreal engine, cinematic lighting

第三组：组合创新（验证创造性）

person as a robot, metallic skin, glowing blue eyes, sci-fi
person riding a dragon, fantasy background, epic scale
person underwater, bubbles, caustic light, marine life
person made of flowers, macro photography, bokeh background
person floating in space, stars, nebula, astronaut suit

关键不是看单张图多好看，而是看一致性：同一组提示下，5张图是否都保持你的面部特征？如果只有前两张像，后面三张变成别人的脸，说明训练不足，需回炉重训800步。如果所有图都像但风格僵硬（比如动漫风还是写实脸），说明先验损失权重太高，需调低--prior_loss_weight。

注意：测试时务必关闭WebUI的“Hires.fix”和“ADetailer”，它们会二次处理人脸，干扰判断。用基础采样器（Euler a，steps=20）生成，确保结果纯粹反映模型能力。

4. 常见问题与排查技巧实录：那些文档里不会写的坑

4.1 “RuntimeError: CUDA out of memory”——T4显存榨干指南

这是Colab用户最高频报错，表面是显存不够，根因是内存碎片化。T4的16GB显存不是一块完整蛋糕，而是被CUDA context、PyTorch cache、VAE encoder等模块切成小块。当Dreambooth加载UNet（约6GB）、VAE（1.2GB）、Text Encoder（0.8GB）后，剩余显存不足2GB，而训练时梯度张量需要连续显存，碎片无法拼合。

解决方案分三级：

一级急救（立即生效）：

import gc gc.collect() # 强制Python垃圾回收 torch.cuda.empty_cache() # 清空CUDA缓存

在报错后立刻运行，能释放1.5-2GB显存，往往能续命一轮训练。

二级优化（训练前必做）：

# 启用xformers（T4专属加速器） pipe.enable_xformers_memory_efficient_attention() # 启用梯度检查点（牺牲速度换显存） pipe.unet.enable_gradient_checkpointing() # VAE用半精度 pipe.vae.to(torch.float16)

这三项组合，可将显存占用从14.2GB压到9.8GB，降幅31%。

三级根治（长期方案）：改用LoRA微调替代Dreambooth全参数微调。LoRA只训练两个小矩阵（约15MB），显存占用恒定在3GB内，且效果接近Dreambooth的85%。代码只需替换DreamBoothTrainer为LoraLoaderMixin，我把完整LoRA训练脚本放在文末附录。

踩坑实录：有位毕设同学死磕Dreambooth，连续3天在Colab重训，直到第四天才试LoRA，结果2小时出图，答辩顺利通过。技术选型不是越重越好，而是“够用就好”。

4.2 “ValueError: Input is not a valid image”——图片预处理的隐形雷区

这个报错90%源于图片元数据污染。手机拍的照片自带EXIF信息（GPS坐标、相机型号、拍摄时间），某些PIL版本读取时会因编码问题崩溃。解决方案不是重装PIL，而是用OpenCV绕过：

import cv2 import numpy as np def load_image_cv2(path): img = cv2.imread(path) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # BGR转RGB return Image.fromarray(img) # 替换所有PIL.Image.open()为load_image_cv2()

OpenCV不解析EXIF，直接读像素，100%规避此问题。

另一雷区是透明通道（Alpha Channel）。PNG图若有透明背景，VAE编码器会把alpha当颜色通道处理，导致生成图边缘发绿。必须强制转RGB：

img = Image.open(path).convert("RGB") # 强制丢弃alpha通道

4.3 “Loss stays at 2.5 forever”——数据质量诊断四步法

Loss不降不是代码问题，而是数据在抗议。按顺序检查：

检查分辨率：用PIL.Image.open().size确认所有图都是512×512。有张图是513×512？整个batch都会被拒绝。
检查文件名：Colab对中文路径支持差，文件名含中文、空格、特殊符号（如&、#）会导致Dataset加载失败，静默跳过该图。用os.rename()批量清理。
检查人脸占比：用face_recognition库快速扫描：

import face_recognition for img_path in image_paths: img = face_recognition.load_image_file(img_path) face_locations = face_recognition.face_locations(img) if len(face_locations) == 0: print(f"Warning: {img_path} has no detectable face")

没有检测到人脸的图，直接剔除。 4.检查光照均匀性：用OpenCV算标准差：

gray = cv2.cvtColor(cv2.imread(img_path), cv2.COLOR_BGR2GRAY) std = np.std(gray) if std < 25: # 标准差过低=画面过平，缺乏纹理 print(f"Low contrast: {img_path}")

标准差低于25的图，细节不足，影响特征学习。

4.4 “Generated image looks like a different person”——先验损失失效的修复方案

这是Dreambooth最头疼的问题：模型记住了你的脸，但忘了“person”这个词原本的意思，导致生成时把你的脸套在猫、汽车上。根源是--prior_loss_weight参数没调好。

默认值0.5太保守。实测黄金值是0.8，但需配合调整：

# 在训练命令中加入 --prior_loss_weight=0.8 \ --num_class_images=200 \ # 从HuggingFace下载200张person类先验图 --sample_batch_size=4

--num_class_images指定先验图数量，200是平衡点——太少（50）则先验弱，太多（500）则压制个性。这些先验图会自动从HuggingFace下载，存到./class-images，训练时与你的图交替喂入。

独家技巧：如果仍不理想，可在提示词里加锚定词。比如你的名字叫“李明”，训练时用"a photo of [V] person"，生成时用"a photo of [V] person named Li Ming"，[V]是Dreambooth的特殊token，模型会把它和你的脸强绑定，大幅提升身份稳定性。

5. 毕设与实战延伸：如何把Notebook训练成果转化为毕业设计亮点？

5.1 毕设答辩的三大加分项设计

很多同学把Dreambooth当成“会用就行”，但在答辩现场，教授最想看到的是工程思维。我帮三位学生设计了以下可落地的加分项：

加分项1：训练过程可视化仪表盘
不用复杂框架，就用matplotlib实时画图：

import matplotlib.pyplot as plt from IPython.display import clear_output loss_history = [] for step, loss in enumerate(train_losses): loss_history.append(loss) if step % 50 == 0: clear_output(wait=True) plt.figure(figsize=(10,4)) plt.subplot(1,2,1) plt.plot(loss_history) plt.title("Training Loss") plt.subplot(1,2,2) plt.hist(loss_history[-100:], bins=20) plt.title("Loss Distribution (last 100 steps)") plt.show()

答辩时投屏展示，教授一眼看出你懂训练动态，不是调包侠。

加分项2：A/B测试对比报告
用同一组提示词，分别生成：

基座模型（waifu-diffusion）结果
Dreambooth微调后结果
LoRA微调后结果
用PS做像素级对比（放大100%看眼睛纹理），量化提升：比如“瞳孔高光清晰度提升37%”，“发丝分离度从2.1px提升到0.8px”。这种数据比“效果更好”有力十倍。

加分项3：轻量化部署方案
证明你考虑了落地：把safetensors模型转成ONNX格式，用onnxruntime在CPU上推理（虽慢但可行），写个Streamlit网页，让教授现场输入提示词生成。代码不到50行，却体现全栈能力。

5.2 从Notebook到ComfyUI：无缝迁移的三步走

标题里提到“comfyui + stable video diffusion中文版下载”，说明用户关注工作流整合。Notebook训好的模型，迁移到ComfyUI只需三步：

模型放置：把dreambooth-lora.safetensors复制到ComfyUI/models/loras/目录；
节点配置：在ComfyUI工作流中，添加Lora Loader节点，lora_name选你的模型，strength_model设0.8（避免过强失真）；
提示词注入：在CLIP Text Encode节点的positive prompt里，开头加<lora:dreambooth-lora:1>,，确保LoRA权重生效。

关键技巧：ComfyUI的KSampler节点中，cfg值建议设7-9，steps设30，比WebUI默认值更稳。我测试过，同样提示词，WebUI生成有15%概率崩坏，ComfyUI因节点化流程控制更精细，成功率92%。