使用百万量级图像，微调 SDXL 的血泪细节：Part 2（转载+翻译）
原文链接：https://www.reddit.com/r/StableDiffusion/comments/1gdkpqp/the_gory_details_of_finetuning_sdxl_for_40m/
翻译工具：OpenAI o1-preview
关于大型 SDXL 微调模型是如何训练的细节非常少，因此，就像我的模型 bigASP 的第一个版本一样，我在这里分享所有细节，以帮助社区。这将会是一篇很长的文章，因为我尽可能多地倾注了我的经验。我希望它能帮助到一些人。
上一篇帖子(https://b23.tv/btA8VW9)可能有助于理解背景，但我也会在这里尽力涵盖所有内容。
概述
版本 2 在 6,716,761 张图像上进行了训练，所有图像的分辨率都超过 1 兆像素，并尽可能使用原始图像，以将压缩伪影减至最小。每张图像在磁盘上约为 1MB，使数据集达到每百万张图像约 1TB。
在训练之前，每张图像都经过以下处理流程：
CLIP-B/32 嵌入：将其保存到数据库中，用于管道的后续阶段。这也是过滤无法加载的图像的阶段。
使用自定义训练的质量模型对每张图像进行 0 到 9（包含 0 和 9）的评分。
使用 JoyTag 为每张图像生成标签。
使用 JoyCaption Alpha Two 为每张图像生成标题。
使用提示词 “a watermark” 的 OWLv2 来检测图像中的水印。
VAE 编码，将预编码的潜变量使用 gzip 压缩保存到磁盘。
训练是使用自定义的训练脚本完成的，该脚本使用 diffusers 库来处理模型本身。与使用像 kohya 这样的更成熟的训练脚本相比，这有利有弊。它使我能够完全理解所有内部机制，并实现我想要的任何调整。缺点是需要花费大量时间调试出现的细微问题，这通常导致代价高昂的错误。对我来说，这些错误只是学习的成本，权衡是值得的。但我绝不推荐这种自虐的方式。
质量模型
对数据集中的所有图像进行 0 到 9 的评分有两个目的。首先，得分为 0 的图像会在训练中被完全丢弃。在我的情况下，我特别需要从数据集中过滤掉广告、视频预览缩略图等内容，我确保这些内容归入 0 分档。其次，在训练期间，得分标签会被添加到图像的提示词前。随后，用户可以使用这些得分标签来引导他们生成的质量。理论上，这使得模型仍然可以从训练集中的“劣质图像”中学习，同时在推理时保留高质量的输出。这种使用得分标签的方法是由令人难以置信的 Pony Diffusion 模型所开创的。
用于评估图像质量的模型分两个阶段构建。首先，我手动收集了一个两两图像比较的数据集。这个数据集中，每个条目是两张图像，以及一个指示哪张图像“更好”的值。我通过自己对 2000 张图像进行评级来构建这个数据集。图像的优劣尽可能地客观。例如，彩色照片不一定比黑白照片“更好”，即使彩色照片通常更受欢迎。而是基于每张图像在其特定风格和主题上的表现来评价。这有助于防止评分系统使模型偏向于特定类型的生成，而是专注于影响质量。
我尝试让一个经过良好提示的 VLM（视觉语言模型）对图像进行评级，发现机器评级与我的评级有 83% 的吻合率。这可能足够好了，以至于未来可以使用机器评级来构建该数据集，或者至少提供显著的扩充。在这一版本中，我选择了 “人机交互” 的评级方式，其中机器评级以及 VLM 关于其评级原因的解释作为参考，我提供最终的评级。我发现 VLM 最大的不足在于判断压缩伪影和图像的整体“清晰度”。
然后，使用这个两两比较的数据集来训练一个模型，预测每对图像中哪个“更好”。我使用了管道中之前生成的 CLIP-B/32 嵌入，在其上训练了一个小的分类器头。这在如此小的数据集上效果很好。通过添加受损的图像对，数据集得到了一定的增强。图像会随机通过压缩或模糊进行损坏，然后在数据集中添加原始图像和受损图像之间的评级，受损图像总是输。这有助于模型学习检测压缩伪影和其他基本质量问题。训练后，这个分类器模型在验证集上达到了 90% 的准确率。
现在进入第二个阶段。从更大的语料库中提取 8192 张随机图像。使用训练好的分类器模型，成对的图像在“竞技场”中进行两两比较，并建立一个 ELO 排名。有 8192 个 “回合” 在这场 “比赛” 中，每个回合将所有 8192 张图像与随机的竞争对手进行比较。
然后，将 ELO 评级分成 10 个档次，建立每张图像 0-9 的质量评分。使用这些已建立的评分，训练第二个模型，方法与之前非常相似，使用 CLIP-B/32 嵌入并在其上训练一个分类器头。训练后，该模型在验证集上达到了 54% 的准确率。虽然这看起来相当低，但其任务比第一阶段的分类器模型要困难得多，需要预测一张图像属于 10 个档次中的哪一个。将实际为 “7” 的图像评为 “8” 被认为是失败的，即使非常接近。我可能应该在这里使用更好的准确率指标……
现在，这个最终的 “排名” 模型可以用于对更大的数据集进行评分。我对一小部分图像进行了测试，并可视化了所有排名，以确保模型按预期工作。每个等级 10 张图像，组织成一个表格，每行一个等级。这让我能够直观地验证从等级 0 到等级 9 整体上是否呈现“梯度”，以及模型在排名中是否保持客观。
那么，为什么要为一个质量模型大费周章？为什么不直接收集一个人类对图像评分 1-10 的数据集，并直接训练一个模型？为什么要使用 ELO？
首先，对于人类来说，两两比较的评级要容易得多。想象一下，评估一张单独的图像并将其分配到十个档次中的一个，是多么困难的任务。经验上，人类在这方面非常糟糕。因此，让我们的源评级数据集是两两比较的更有意义，我们需要找到一种方法来训练一个可以输出 0-9 评分的模型。
在理想情况下，我会让 ELO 竞技场基于所有的人类评级。即，抓取 8000 张图像，将它们放入一个竞技场，在 8000 个回合中进行比较。但这需要超过 6400 万次比较，这是不可行的。因此，我们采用了一个两阶段的系统，我们训练并使用一个分类器模型来为我们执行竞技场的比较。
那么，为什么选择 ELO？一个更简单的方法是直接使用分类器模型简单地将 8000 张图像从最好到最差排序，然后将其分成每个包含 800 张图像的 10 个档次。但这会引入固有的偏差，即每个档次的可能性均等。实际上，数据集中给定图像的质量更可能遵循高斯或类似的非均匀分布。ELO 是一种更中立的方式来分层图像，因此当我们根据其 ELO 排名对它们进行分档时，更有可能获得反映数据集中图像质量真实分布的分布。
完成所有这些工作，并对所有图像进行评分后，得分标签就可以添加到扩散模型训练期间使用的提示词中。在训练期间，数据管道获取图像的评级。由此，它可以为该图像编码所有可能适用的得分标签。例如，如果图像的评级为 3，所有可能的得分标签是：score_3，score_1_up，score_2_up，score_3_up。它会随机选择其中一些标签添加到图像的提示中。通常它只选择一个，但有时会选择两个或三个，以模拟用户通常只使用一个得分标签，但有时会使用更多。这些得分标签被添加到提示词的开头。下划线会被随机更改为空格，以帮助模型学习 “score 1” 和 “score_1” 是相同的。得分标签之间随机使用逗号或空格分隔。最后，在 10% 的情况下，得分标签会被完全丢弃。这使模型具有灵活性，用户在推理期间不必使用得分标签。
JoyTag
使用 JoyTag 为数据集中的所有图像生成标签。这些标签被保存到数据库中，并在训练期间使用。训练期间，使用一个相当复杂的系统来随机选择图像标签的子集，并将它们形成一个提示词。我在版本 1 的细节中记录了此选择过程，所以一定要查看。但是，简而言之，随机选择一定数量的标签，使用随机分隔符连接，随机删除下划线，并使用已知的别名随机替换标签。重要的是，对于版本 2，在训练期间，仅有 10% 的时间使用纯标签的提示词。其余时间，使用图像的标题。
标题生成
使用 JoyCaption Alpha Two 的早期版本为 bigASP 版本 2 生成标题。它以随机模式运行，生成扩散模型在训练期间将看到的各种类型的标题。首先，从以 45 个单词为中心、标准差为 30 个单词的正态分布中选择一个单词数量。
然后，选择标题类型：60% 的情况下是 “Descriptive”（描述性），20% 的情况下是 “Training Prompt”（训练提示），10% 的情况下是 “MidJourney”，10% 的情况下是 “Descriptive (Informal)”（描述性（非正式））。描述性标题是图像的直接描述。它们是 JoyCaption Alpha Two 最稳定的模式，这就是我对它们赋予如此大权重的原因。然而，它们非常正式，对于用户在生成图像时实际编写的内容来说有些别扭。MidJourney 和 Training Prompt 风格的标题模仿了用户在生成图像时实际编写的内容。它们由描述用户想要内容的自然语言、标签、句子片段等混合组成。然而，这些模式在 Alpha Two 中有点不稳定，所以我不得不谨慎使用。我还在 25% 的情况下随机添加 “Include whether the image is sfw, suggestive, or nsfw.”（包括图像是 “sfw”（安全）、“suggestive”（暗示性）还是 “nsfw”（不安全））到 JoyCaption 的提示中，因为 JoyCaption 目前没有像我希望的那样经常包含这些信息。
有许多方式来提示 JoyCaption Alpha Two，所以在这里有很多可玩的东西，但我想保持事情简单，并发挥其当前的优势，尽管我肯定可以对其进行更多的优化。
在这一点上，标题可以直接用作训练期间的提示词（得分标签添加到前面）。然而，关于 JoyCaption 的早期版本，我绝对想要修复一些特定问题，因为它们可能会阻碍 bigASP 的性能。Training Prompt 和 MidJourney 模式偶尔会陷入重复循环；它使用了大量空洞的内容，例如 “this image is a” 或 “in this image there is”；它没有像我希望的那样频繁使用非正式或粗俗的词汇；其水印检测准确率不佳；有时使用模棱两可的语言；我需要将图像来源添加到标题中。
为了在 670 万张图像的规模上解决这些问题，我训练并使用了一系列三个微调的 Llama 3.1 8B 模型，对标题进行重点编辑。第一个模型是多用途的：修复故障、替换同义词、消除歧义，并删除诸如 “this image is” 之类的冗余部分。第二个模型根据 OWLv2 的检测结果，修复对水印的提及。如果有水印，它确保始终提及。如果没有水印，它要么删除提及，要么改为 “no watermark”（无水印）。这对于确保在推理期间扩散模型除非明确要求，否则永远不生成水印至关重要。第三个模型在标题中添加图像来源（如果已知）。这样，用户可以提示指定来源。
训练这些模型相当直接。第一步是收集大约 200 个样本，我手动编辑标题以修复上述问题。为了确保标题编辑方式的多样性，减少我引入偏差的可能性，我使用现有的 LLM 进行零样本（zero-shot）处理。虽然所有现有的 LLM 在进行我想要的编辑方面实际上都相当糟糕，但通过一个相当长且精心编写的提示，我可以让其中一些做得还可以。重要的是，它们作为 “第三方” 编辑标题，有助于打破我的偏见。我在这里又进行了人机交互的数据收集方式，LLM 提供建议，我要么修正它们的错误，要么从头开始编辑。一旦收集了 200 个样本，我就有足够的数据对 Llama 3.1 8B 进行初步微调。Unsloth 使这变得相当容易，我只需在其上训练一个小的 LORA。一旦这个初始模型被训练出来，我就用它来代替之前的其他 LLM，并在进行人机交互的同时收集更多的样本，同时评估模型的性能。不同的任务需要不同数量的数据，但最终的微调都在大约 400 到 800 个样本之间。
在这里的设置非常标准：LORA 等级为 16，alpha 为 16，没有 dropout，目标是所有内容，没有偏置，批大小为 64，160 个预热样本，3200 个训练样本，学习率为 1e-4。
我必须说，400 是一个非常小的样本数量，而 Llama 3.1 8B 能够从这样的小数据集中进行漂亮的微调。我非常印象深刻。
对于我需要的每个模型，这个过程都重复了一遍，每个模型都按顺序消耗前一个模型编辑的标题。这就引出了实际在 670 万个标题上运行这些模型的巨量任务。直接使用 HuggingFace transformers 进行推理，即使使用 torch.compile 或 unsloth，在我的本地机器上每个模型也要花费 7 天。这意味着要花 3 周时间处理所有三个模型。幸运的是，我尝试了 vLLM，哇哦！vLLM 能够实现足够的吞吐量，在 48 小时内完成了整个数据集！通过一些优化以最大化利用率，我能够将时间降至 30 小时。真是太棒了。
经过所有这些编辑处理后，标题达到了训练所需的最终状态。
VAE 编码
这一步相当简单，只需将所有图像通过 SDXL 的 VAE，并将潜变量保存到磁盘。预编码可以在训练期间节省 VRAM 和处理，也大大缩小了数据集大小。数据集中的每张图像大约为 1MB，这意味着整个数据集接近 7TB，这使得我在云端利用更大的机器进行训练变得不可行。但是，一旦经过 gzip 压缩，潜变量只有大约 100KB，每张图像大小为原来的 10%，将整个数据集降至 725GB，更易于管理。（注意：我尝试了 zstandard，看看它是否能进一步压缩，但在更高设置下的压缩率反而更差。需要调查。）
长宽比分桶及更多
就像版本 1 和许多其他模型一样，我使用了长宽比分桶（aspect ratio bucketing），使不同的长宽比可以被馈送到模型中。这已经被详细记录了，所以我在这里不再详细说明。唯一不同的是，在版本 2 中，我还基于提示词长度进行了分桶。
我在训练版本 1 时注意到的一个问题是，大多数批次都有不同数量的提示词块。如果不熟悉的话，为了处理超过文本编码器限制（75 个标记）的提示词，NovelAI 发明了一种技术，几乎所有人都在他们的训练脚本和推理 UI 中实现了。超过 75 个标记的提示词被拆分为 “块”（chunks），每个块为 75 个标记（或更少）。这些块由文本编码器分别编码，然后所有嵌入被连接在一起，扩展了 UNET 的交叉注意力（cross attention）。
在一个批次中，如果一张图像只有 1 个块，而另一张有 2 个块，它们必须填充到相同的长度，因此第一张图像会附加 1 个纯填充的块。这不一定是坏事；unet 只是忽略填充。但我遇到的问题是，在较大的小批量（mini-batch）大小（在我的情况下为 16）下，绝大多数批次由于概率原因，模型在训练期间看到的几乎所有批次都有 2 或 3 个块，以及大量填充物。一方面，这是低效的，因为更多的块需要更多的计算。其次，我不确定这对模型会有什么影响，如果它在训练期间习惯于看到 2 或 3 个块，但在推理期间只得到 1 个块。即使有填充，模型可能会在数值上习惯于交叉注意力标记的数量。
为了解决这个问题，在长宽比分桶阶段，我估计图像提示词将具有的标记数量，计算它将有多少个块，然后基于此也进行分桶。虽然不可能 100% 准确（由于前置的得分标签等引起的长度随机性），但它使批次中块的分布更加均匀。
UCG（无条件引导）
一如既往，在一小部分时间内，将提示词完全丢弃，设置为空字符串。对于版本 2，这个比例是 5%。与版本 1 相比，我删除了随机将文本嵌入设置为零的代码。这种将嵌入随机设置为零的做法源于 Stability 的参考训练代码，但我一直不太明白，因为几乎没有 UI 将诸如文本条件之类的条件设置为零。所以我完全禁用了该代码，只是在 5% 的情况下，将提示词设置为空字符串，这是传统的做法。
训练
训练的开始与版本 1 几乎完全相同。使用 min-snr 损失，模型使用 fp32 和 AMP，AdamW 优化器，批大小为 2048，没有 EMA，没有偏移噪声，学习率为 1e-4，权重衰减为 0.1，余弦退火，线性预热 100,000 个训练样本，启用了文本编码器 1 的训练，文本编码器 2 保持冻结，min_snr_gamma=5，使用 GradScaler，Adam 的 beta1=0.9，beta2=0.999，eps=1e-8。一切都从 SDXL 1.0 初始化。
与版本 1 相比，我将训练样本从 3000 万增加到 4000 万。我觉得 3000 万让模型有点训练不足。
一个包含 2048 张图像的验证数据集从数据集中切分出来，并在整个训练过程中用于计算验证损失。在计算验证损失的同时，还测量了一个稳定的训练损失。稳定的训练损失类似于验证，但它使用的 2048 张图像切片未从训练中排除。训练扩散模型的一个问题是其训练损失非常嘈杂，因此很难跟踪模型学习训练集的效果。稳定的训练损失有帮助，因为其图像是训练集的一部分，因此它测量了模型对训练集的学习情况，但它们是固定的，因此损失更加稳定。通过监测稳定的训练损失和验证损失，我可以很好地了解 A）模型是否在学习，B）模型是否过拟合。
训练是在云端租用的一台 8xH100 SXM5 机器上进行的。与版本 1 相比，这次迭代速度稍快，可能是由于 PyTorch 和驱动程序在这几个月中的优化。达到 80 张图像/秒。整个训练运行花费了不到 6 天。
训练开始于启动服务器，将潜变量和元数据通过 rsync 传输过去，以及所有的训练脚本，打开 tmux，然后开始运行。一切都记录到 WandB，以帮助我跟踪统计数据，每 500,000 个样本保存一次检查点。我会不时地将检查点通过 rsync 传输到我的本地机器，并将它们上传到 HuggingFace 作为备份。
在我的本地机器上，我使用检查点在训练过程中生成样本。虽然验证损失的下降很好看，但模型在推理中生成的实际样本对于衡量模型的实际性能至关重要。我有一组提示词和固定的种子，针对每个检查点运行，并将所有内容编译成一个表格，保存为 HTML 文件供我查看。这样我就可以轻松比较每个提示词在训练过程中的进展。
事后分析（有效的地方）
版本 2 的最大区别在于引入了标题，而不仅仅是标签。这无疑是成功的，为模型带来了大量可提示的概念。它也使用户使用模型变得容易得多。
总体而言，我对 JoyCaption Alpha Two 的表现感到满意。随着 JoyCaption 向其 1.0 版本推进，我计划将其发展到可以直接在训练管道中使用的程度，无需所有这些 Llama 3.1 8B 模型来修复标题。
bigASP v2 相当好地遵循了提示词。无论如何都没有达到 FLUX 或 DALLE 3 的水平，但对于仅有一位开发者在研究这个项目，我对结果感到满意。随着 JoyCaption 准确性的提高，我预计提示词的遵循度也会提高。当然，bigASP 的未来版本可能会使用更先进的模型，如 FLUX 作为基础。
我认为将训练长度增加到 4000 万是一个好举措。根据训练期间生成的样本图像，模型在训练后期进行了大量的“收紧”，如果这有意义的话。我知道像 Pony XL 这样的模型的训练量是我的多倍。但仅这一次运行就花费了大约 3600 美元，所以……对于我来说，很难做得更多。
根据我的观察，质量模型似乎有所改进。“良好”质量的范围现在更高了，score_5 有点像体面质量的分界线。而版本 1 大概在 7 分左右截止。对我来说，这是一件好事，因为它扩大了 bigASP 的输出范围。
有些用户不喜欢使用得分标签，所以 10% 的情况下不使用它们是一个好举措。用户还报告说，他们可以在没有得分标签的情况下获得“更好”的生成结果。这是有道理的，因为得分标签可能会限制模型的创造力。但当然，不指定得分标签会导致生成的质量范围更大，所以这是一个权衡。我很高兴用户现在有了这个选择。
对于版本 2，我在数据集中添加了 200 万张 SFW（Safe For Work）图像。目的是扩大 bigASP 所了解的概念范围，因为 NSFW 图像中包含的内容通常非常有限。例如，版本 1 根本不知道如何绘制冰激凌甜筒。添加 SFW 数据的效果很好。bigASP 现在不仅是一个出色的写实 SFW 模型（我经常生成几乎无法分辨是 AI 生成的大自然照片），NSFW 方面也大大受益。最重要的是，有着无聊背景和平淡光线的 NSFW 生成图像已成为过去！
我还在数据集中添加了大量以男性为中心的图像。我一直希望 bigASP 能成为一个适用于所有用户的模型，将 50% 的人群排除在训练数据之外是愚蠢的。虽然版本 1 的确有以男性为中心的数据，但并没有达到应有的代表性。版本 2 的数据在这方面要好得多，而且效果显著。男性生成的效果比以往更加接近于女性的质量。这方面还有更多工作要做，但正在变得更好。
事后分析（效果不佳的地方）
用于修复标题的微调 Llama 模型本身偶尔会失败。这种情况相当罕见，可能是每 1000 个标题中有 1 个，但这当然不是理想的。由于它们是串联的，这增加了错误率。解决方法当然是让 JoyCaption 自身在生成我想要的标题方面变得更好。所以我必须等待我在那方面的工作完成 :p
我认为 SFW 数据集可以进一步扩充。它的效果很好，但还可以加强。
我在版本 2 中尝试添加了 “写实” 领域之外的内容。我对 bigASP 的期望之一是能够创建更具风格化或抽象的图像。我的重点不一定是在绘画/动漫等方面。有更好的模型适用于此。但能够在照片中更超现实或具有艺术感会很好。为此，我在数据集中注入了少量的古典艺术作品，以及看起来像电影剧照的图像。然而，在我的测试中，这两者似乎都没有被很好地学到。版本 2 现在可以在写实领域之外运行，但我想在这里进一步改进，让它学习更多关于艺术和电影的内容，从中获得大量的风格。
为图像生成标题是一个巨大的瓶颈。当时我还没有发现 vLLM 的超快速度，所以运行 JoyCaption 处理所有图像花费了很长时间。我有可能让 JoyCaption 与 vLLM 一起工作（多模态模型总是很棘手），这可能会大大加快速度。
事后分析（效果很差的地方）
我要先说，我对版本 2 非常满意。我认为它比版本 1 有了巨大的改进，能力得到了极大的扩展。它在生成细节和真实感方面的能力更强了。如前所述，我已经生成了一些几乎无法与真实照片区分的自然照片。这对于 SDXL 来说是疯狂的。是的，版本 2 有时甚至可以生成文字！这对于 SDXL 来说又是一个困难的壮举。
但是，这也是痛苦的部分。版本 2 有时仍然……情绪化不稳定。我们都知道 SDXL 有多么不一致。但感觉 bigASP v2 生成的畸形尸体的频率过高。这里那里出现的位置不对的四肢、糟糕的手、奇怪的面孔都可以接受，但我说的是肉泥般的生成。这让我非常困扰的是，我也许可以将其归结为 SDXL 就是 SDXL。这是一项令人难以置信的技术，但也有其缺陷。但是 Pony XL 并没有这个问题。Pony XL 的所有生成结果并不都是“出色”的，但身体恐怖的出现频率要低得多。所以没有理由 bigASP 不能更频繁地正确生成基本的人体解剖结构。
坦率地说，我不确定为什么会发生这种情况。有一种理论是，SDXL 正在被推向极限。大多数涉及特写的提示效果很好。而且直观地说，这些是“更简单”的图像。需要更广视角、对图像要求更高的提示？这时 bigASP 就会陷入挣扎。相比之下，来自 Pony XL 的 2D 艺术可能在“复杂性”上更简单，因此问题更少，而 bigASP 对 SDXL 的有限计算能力要求更高。另一方面，Pony XL 与照片相比，可能要处理数量级更多的概念和风格，所以就耸耸肩吧。
另一个理论是，bigASP 的数据集中几乎没有坏数据。这与基础的 SDXL 形成对比。虽然这对只对基础模型稍作修改的 LORA 来说不是问题，但 bigASP 正在进行大量修改。这既是它的优势，也是它的劣势。因此，在推理期间，bigASP 可能已经忘记了“坏”生成是什么样的，因此难以使用 CFG（分类自由引导，Classifier-Free Guidance）远离它们。这可以解释为什么对 bigASP 应用扰动注意力引导（Perturbed Attention Guidance）会有很大帮助。这是一种人为地生成坏数据的方法，让模型远离其预测。
还有一种理论是，基础的 SDXL 可能有问题。大自然摄影的效果往往比包含人类的图像要好得多。如果人类在基础的 SDXL 中被大量审查（考虑到我们从 SD 3 中看到的情况，这并非不可能），这可能会削弱 SDXL 天然生成真实感人类的能力，使得 bigASP 在微调中难以修复。也许需要更多的训练，比如 Pony XL 那样的级别？呃……
最后（也是最可能）的理论是……我搞砸了。我已经来回检查了代码，但还没有发现任何问题。但有可能在某处存在微妙的问题。也许 min-snr 损失存在问题，我应该使用正常的损失来训练？我不知道。
虽然许多用户能够应对版本 2 的这个缺陷（比我自己的成功率要高得多！），而且当版本 2 达到好的生成效果时，它的确很棒，但我认为这会给模型的新用户带来很多阻力。用户应该专注于如何为他们的用例创建最佳图像，而不是如何避免模型生成肉泥般的东西。
图表
Wandb 运行：
https://api.wandb.ai/links/hungerstrike/ula40f97
验证损失：
稳定损失：
源代码
用于训练脚本、Python notebook、数据处理等的源代码都已为版本 1 提供：https://github.com/fpgaminer/bigasp-training
我会很快用版本 2 的代码更新这个仓库。一如既往，这些代码仅供参考；我并不将其维护为供他人使用的东西。但也许人们看到我所做的所有工作会有所帮助。
最后的想法
我希望所有这些对他人有用。我绝不是这方面的专家；只是一个想创造酷东西的业余爱好者。但人们似乎喜欢上次我“倾倒”我所有的经验，所以这次也一样。