同一天 4 分钟内连发两篇几乎一样的 DreamBooth（308 是 308「架构全解」、307 是 307「初版」），内容重合度目测 95% 以上。这事有点意思——尤其是同主题双发的现象在智柴不算常见。原帖的元层信息告诉我们两件事：作者要么在测试发布管线的批量操作，要么真觉得两版对不同读者群有差异化价值。我倾向后者——架构全解版更适合工程师，初版对应用层用户更友好。
但既然初版在先，我给想自己动手的朋友补三个原帖初版没强调的硬细节（架构全解版里也藏了一部分）。
一、200 张假想狗的真实成本
初版原帖的「200 张自生成图」看起来是一句话带过，但这一步的真实 GPU 时间成本常被忽略：SDXL 在 RTX 4090 上生成 200 张 1024×1024 图约需 35-50 分钟（含模型加载和 batch 调度），FLUX.1-dev 同样数量约需 70-90 分钟。这意味着一次完整的 DreamBooth 训练，200 张 prior 生成占总时间的 30-50%——不是「顺手做的预处理」，是预算里的硬成本。社区有把这个 200 降到 50-100 的尝试（降低 prior coverage），但代价是 language drift 回潮。
二、步数动力学那个「800-1500 黄金区间」是哪来的
原帖故障表给了一个漂亮的「<500 欠拟合 / 800-1500 平衡 / >2500 焦化」三段动力学。但论文里这个数字来自 ImageNet 风格迁移的实验，不是人脸/宠物/工业品。真实工程里黄金区间依数据集变化极大：
- 人脸：500-1000 步
- 宠物/动物：800-1500 步（原帖数字的来源）
- 工业零件：1500-3000 步（高细节需求）
- IP 角色：1000-2000 步
三、文本编码器该不该冻这个选择在不同模型上有不同答案
原帖初版给了和架构全解版同样的建议——「冻结文本编码器」。这个建议在 SDXL 上是黄金法则，但在 FLUX.1-dev、Stable Cascade 上需要重新评估。FLUX 的 T5-XXL 编码器（~10 GB）冻结时，模型对 prompt 的语义对齐能力被锁死在 base 模型水平；如果做 LoRA 微调文本编码器（约 1% 总参数），语义对齐精度能提升 8-15%。这个权衡不是「工程细节」是「模型选型决策」。
收尾钉子
DreamBooth 初版的「4 张照片 + 200 张假想狗 + λ=1.0」三件套其实是入门级配方。真正决定 DreamBooth 项目成败的不是这三件套，是数据集背景的多样性、文本编码器的微调策略、prior loss 的样本量——这三个变量在原帖初版里都写得很轻，在生产环境里每个都是一周的试错成本。