1. 项目概述与核心思路1.1 这个项目到底是做什么的先说结论这是一个用 Python Keras 从零实现文生图生成式 AI 应用的完整实战项目。所谓“从文字到图像”就是把自然语言描述比如“一只戴着帽子的柯基坐在沙滩上”变成一张风格符合描述的图片所谓“从概念到落地”指的是不停留在跑通一个 Demo而是要把模型推理、后端服务、接口封装、实际调用这条链路完整走通。我最早接触 Keras 是在 TensorFlow 2 时代当时它的定位是“对新手友好的高层 API”。很多人觉得 Keras 只能做分类、回归这类传统任务搞生成式 AI 必须要上 PyTorch。实际上从 Keras 3 开始情况发生了根本性变化——它支持 TensorFlow、PyTorch、JAX 三种后端切换而且像 Diffusion 模型这种复杂的训练循环也可以用 Keras 的train_step重写机制来实现。这个项目选择 Keras 而不是直接上 PyTorch一个重要原因是团队里有人对 Keras 更熟另一个原因是 Keras 3 的模型导出、量化、部署链路比较顺对“落地”环节有实打实的好处。如果你是下面这几类人这篇分享应该对你有帮助已经会用 Keras 做图像分类或回归想往生成式 AI 方向转型的工程师在 PyTorch 里用过 diffusers但想换一套工具链做对比验证的开发需要快速把文生图能力集成到现有业务系统而不是仅仅在 Notebook 里跑着玩的同学1.2 为什么选扩散模型而不是 GAN文生图领域的主流技术路线经历过一个明显切换。早期大家热衷 GAN生成对抗网络尤其是 StyleGAN 系列在人脸生成的质量上做到了很强的水准。但 GAN 有一个很麻烦的问题训练不稳定判别器和生成器的对抗容易出现模式崩塌调起来非常痛苦。而且 GAN 对文本条件的控制能力偏弱很难做到“改一个词就精准地改一个视觉特征”这种细粒度语义控制。扩散模型Diffusion Model的思路完全不同。它不是让两个网络互相博弈而是模拟一个“先加噪声再逐渐去噪”的过程。你把一张真实图片逐步加噪变成纯随机噪声然后训练一个神经网络学会反向操作——从噪声里一步步恢复出原图。生成新图的时候就从一个随机噪声向量出发反复去噪最后得到一张从未存在过的新图片。这个思路有种“润物细无声”的感觉。训练过程没有对抗博弈loss 曲线通常比较稳定条件控制也可以做得自然——只要把文本向量拼接到去噪网络的输入里就能让模型“看着文字去画画”。所以这个实战项目选了扩散模型作为核心架构逻辑上更稳工程上也更可控。2. 环境准备与工具选型2.1 硬件到底怎么选做生成式 AI 的实战硬件是第一道坎。先把话说透纯 CPU 跑 Diffusion 训练不是不行而是慢到怀疑人生。一个 256x256 分辨率的小型扩散模型在消费级 GPU 上训练几小时到一两天在 CPU 上可能要跑一两周。如果你只是做推理用别人训好的模型生成图片CPU 倒是勉强能用但单张图可能要等几十秒体验很差。我的建议是这样分档入门学习用云端免费环境比如某知名的 Notebook 平台挂载 T4 级别的 GPU足够跑通小型模型的训练和推理个人实战一张 8GB 以上显存的 NVIDIA 消费级显卡比如 4060 Ti 及以上可以比较舒服地训练 256x256 的模型生产落地服务器级别的 A 系列或更高级的卡或者直接用云 GPU 实例按需付费避免一次性大额投入这个项目里我用的是 8GB 显存的消费级显卡跑 256x256 分辨率、约 100 万张图像的数据集微调一个 epoch 大约 40 分钟训练 10 个 epoch 基本能出明显效果。如果你是刚开始建议先把分辨率降到 128x128能让迭代速度大幅提升。2.2 依赖安装的实操细节Keras 3 的环境安装有几个容易踩坑的地方。我用的是 Python 3.10 版本实测 3.11 和 3.12 也能跑但个别底层库可能出现兼容性警告。# 创建独立环境避免污染系统 Python conda create -n keras_diffusion python3.10 -y conda activate keras_diffusion # 安装 GPU 版 TensorFlow 作为后端Keras 3 也支持 JAX/PyTorch 后端 pip install tensorflow # 安装 Keras 3 pip install keras # 图像处理和数据下载工具 pip install pillow numpy matplotlib tqdm注意一个细节Keras 3 的 API 名称和 Keras 2 有一些差异比如keras.optimizers.Adam的用法基本一致但tf.keras和keras两个命名空间不要混着用。我第一版代码里混用了两个命名空间导致模型权重保存后无法正常加载折腾了半天才发现是这个问题。如果你选择 PyTorch 后端还需要pip install torch torchvision然后在环境变量里指定KERAS_BACKENDtorch。切换后端的好处是可以灵活用不同生态的现成模型和算子坏处是对 Keras API 的兼容性要仔细验证不是所有模型层都能跨后端无缝迁移。实际项目里我建议选定一个后端用到底别频繁切换。2.3 关键依赖库的版本锁定生成式 AI 对版本比较敏感。我实测过的稳定组合是Python 3.10TensorFlow 2.15Keras 3.1NumPy 1.24注意 2.x 版本在某些 tf.data 管道里可能报类型转换问题Pillow 10.x不建议追求最新的库版本。比如 NumPy 2.0 发布初期和 TensorFlow 的兼容性出了问题训练中途经常报_ARRAY_API not found之类的错误网上搜一圈才会发现是版本冲突。锁版本是省时间的好办法。3. 数据准备与预处理经验3.1 数据集从哪来要多少量级文生图模型的数据通常是一对对的图片 对应的文字描述。公开数据集很多但不同的数据集有不同的使用限制选的时候留个心眼。对于这个实战项目我用了某公开的图文数据集大概 200 万对从中抽样了 50 万对用于训练。很多人会问“需要多少数据才能训练一个能用的文生图模型”。这个问题没有标准答案完全取决于任务复杂度单一概念生成比如只生成猫的图片1 万到 5 万张就能看到不错的效果多风格多物体生成比如 100 个类别的图文生成至少 50 万到 100 万对通用文生图像市面上的商业产品需要数亿级别的图文对和巨大的算力对于个人或小团队实战我的建议是不要从零训一个通用模型而是用预训练模型 微调LoRA 或全量微调的路线。就像你不需要自己造一个大型语言模型只需要在一个开源模型基础上做领域适配。3.2 数据清洗的三个步骤如果说模型架构决定了效果上限那么数据质量直接决定了你能不能接近这个上限。我在这个项目里做了三步清洗第一步去重。用感知哈希算法把相似度过高的图片挑出来删除避免模型反复看到几乎一样的图导致过拟合和多样性下降。第二步过滤低质量文本。很多数据集的文字描述是自动生成的质量参差不齐。有些描述只有一两个词“一只猫”有些则是完全无意义的乱码。我用一个简单的规则描述少于 5 个字符或超过 200 个字符的样本直接删掉。另外中英文混编的描述对中文提示词的生成效果影响很大如果目标是中文场景优先保留中文描述为主的样本。第三步尺寸统一。训练扩散模型时图片尺寸必须一致。我统一缩放到 256x256如果原图不是正方形先按短边中心裁剪再缩放避免物体形变。这个过程是一个经常被忽略的细节直接缩放非正方形图会导致物体被压扁训练出的模型生成的人脸会“长宽失调”。3.3 tf.data 数据管道的高效写法Keras 生态里tf.data是做数据管道最顺手的工具。它的核心优势是支持并行读取、预取和乱序能把 GPU 喂得很饱。我的数据管道大致是这样写的import tensorflow as tf def load_image(image_path): img tf.io.read_file(image_path) img tf.image.decode_jpeg(img, channels3) img tf.image.resize(img, [256, 256]) img tf.cast(img, tf.float32) / 127.5 - 1.0 # 缩放到 [-1, 1] return img def load_text(text): # 将文本转为 token id 序列这里用预训练分词器 tokens tokenizer.encode(text, max_length77, pad_to_max_lengthTrue) return tf.convert_to_tensor(tokens, dtypetf.int32) def preprocess_sample(image_path, text): image load_image(image_path) tokens load_text(text) return image, tokens dataset tf.data.Dataset.from_tensor_slices((image_paths, texts)) dataset dataset.map(preprocess_sample, num_parallel_callstf.data.AUTOTUNE) dataset dataset.shuffle(buffer_size10000) dataset dataset.batch(16) dataset dataset.prefetch(tf.data.AUTOTUNE)几个关键点图片归一化到 [-1, 1] 而不是 [0, 1]是因为扩散模型里的噪声分布是基于标准正态分布的输入范围对称有利于训练稳定。num_parallel_callstf.data.AUTOTUNE让 TF 自动决定并行度不用手动调。prefetch可以在 GPU 训练时减少等待时间务必加上。我自己踩过的一个坑是 token 长度设置为 77。这是从某个著名的 CLIP 模型来的惯例因为该模型的文本编码器固定接受 77 个 token。超过这个长度会被截断短了会补 padding。如果你的模型用不同的文本编码器这个数字要跟着改不要想当然。3.4 数据增强用还是不用扩散模型的训练目标和分类模型不同它要学习的是“从噪声恢复原图”的能力所以数据增强要谨慎。常用的随机裁剪、翻转、颜色抖动等增强在分类任务里能提升泛化性在扩散模型里却可能让模型学会“模糊地恢复”因为同一个语义在不同增强版本里对应的目标图像不一样。我的经验是扩散模型训练阶段只做极其轻微的中心裁剪或者干脆不做翻转也只在数据量偏少时用水平翻转。等模型训练稳定后如果想增加多样性再考虑逐步引入更强的增强。这一点和 GAN 训练很像——目标函数太复杂模型承担不了多余的变异。4. 模型架构设计与实现细节4.1 整体架构拆解文本编码器 扩散模型文生图扩散模型的完整结构可以分为两部分文本编码器把自然语言描述转换成向量表示可以是一个预训练的多模态模型比如 CLIP或者纯文本模型如 BERT。这个向量会作为“条件”注入到图像生成网络里告诉它“该画什么”。图像生成模型去噪网络通常用 U-Net 结构输入是带噪声的图像和当前噪声步数输出是预测的噪声从而一步步还原出图像。为什么用 U-Net因为它的编码器-解码器结构配合跳跃连接skip connection既能捕捉全局语义又能保留细节纹理。从加噪图像里恢复原图本质上是做“去噪 超分”的混合任务U-Net 这种多尺度结构天然适合。为什么文本编码器必须“冻结”因为预训练文本编码器已经学到了丰富的语义空间如果和图像生成网络一起训练不仅会让整个训练过程极其不稳定反而可能“忘记”本来学到的语义理解能力。我在实验里尝试过解冻文本编码器结果 loss 直接漂移生成图像的文字相关性明显下降所以冻结是正确选择。4.2 扩散过程的数学直觉很多初学者一看到扩散模型的公式就头大其实核心思想可以用一个生活化类比讲清楚想象你有一张清晰的照片你拿一张透明的磨砂纸一点点盖上去每盖一层照片就越模糊直到完全看不清。现在反过来你手里只有一张完全模糊的白纸但你有一台“时光机”知道每张磨砂纸对应的模糊程度和模糊方向——你只需要一步一步消除模糊就能还原出清晰照片。数学上前向加噪过程就是x_t sqrt(α_t) * x_0 sqrt(1 - α_t) * ε其中 ε 是标准正态分布的噪声α_t 是一个随时间步变化的值决定了每一步加多少噪声。训练的时候我们随机采样一个时间步 t给干净图像 x_0 加上对应强度的噪声得到 x_t然后让模型去预测这个 ε。模型输出的噪声和真实噪声越接近loss 就越小。生成的时候我们从纯噪声 x_T 出发逐步调用模型预测噪声并用一个更新公式“去噪一步”重复 T 步就得到 x_0。我用的是 DDPMDenoising Diffusion Probabilistic Models 的经典调度训练步数 T1000。在这个项目里我用了一部分时间步的采样来加速训练——每次只随机抽 10% 的时间步100 个训练效果几乎无损但速度提升了将近 10 倍。这个技巧在官方论文里没有强调在实际工程里却非常实用。4.3 Keras 动态学习率与训练循环Keras 3 里重写训练循环核心是用keras.Model的子类化subclassing覆盖train_step方法。扩散模型的核心逻辑其实不在模型本身而在训练循环里如何构造“加噪后的图 文本条件 时间步”三元组。我这样处理class DiffusionModel(keras.Model): def __init__(self, unet, text_encoder, **kwargs): super().__init__(**kwargs) self.unet unet self.text_encoder text_encoder def train_step(self, batch): images, text_tokens batch batch_size tf.shape(images)[0] t tf.random.uniform([batch_size], 0, 1000, dtypetf.int32) noise tf.random.normal(tf.shape(images)) images_noisy self.forward_diffusion(images, t, noise) with tf.GradientTape() as tape: text_embedding self.text_encoder(text_tokens) predicted_noise self.unet([images_noisy, t, text_embedding]) loss self.loss_fn(noise, predicted_noise) grads tape.gradient(loss, self.unet.trainable_variables) self.optimizer.apply_gradients(zip(grads, self.unet.trainable_variables)) return {loss: loss}这里有一个容易忽略的细节时间步 t 本身会被送进网络通常经过一个位置编码类似 Transformer 里的正弦位置编码然后与图像特征融合。很多新手会遗漏这一步导致训练 Loss 下降得特别慢——因为模型根本不知道当前噪声水平是多少。训练时我还用了余弦退火学习率调度把初始学习率设为 1e-4先用 5 个 epoch 的 warmup 线性升到 1e-3再逐步衰减。在扩散模型上warmup 几乎是必须的——直接上大学习率loss 大概率炸掉。这也是我对比多次实验后总结的经验。4.4 导出自定义推理层训练完成后模型推理不能直接用训练时的 U-Net 结构。因为生成过程需要反复调用 U-Net1000 步或者加速后的 50 步每次调用都要重新经过文本编码器。文本编码器本身很大反复调用会浪费大量计算时间。所以我把推理封装成一个keras.Model子类把文本编码的结果缓存起来只跑一次class InferenceModel(keras.Model): def __init__(self, diffusion_model, text_encoder): super().__init__() self.diffusion_model diffusion_model self.text_encoder text_encoder self.scheduler DDIMScheduler(num_steps50) def generate(self, prompt): text_embedding self.text_encoder([prompt]) x tf.random.normal([1, 256, 256, 3]) for t in self.scheduler.timesteps: noise_pred self.diffusion_model.unet([x, t, text_embedding]) x self.scheduler.step(noise_pred, t, x) return xDDIM 采样Denoising Diffusion Implicit Models 是一个关键加速手段——它把原来 1000 步的生成缩减到 50 步代价是图像质量和多样性稍有下降但对大多数应用完全够用。从 1000 步到 50 步生成速度提升了 20 倍这在服务端推理场景里是决定性的优化。5. 微调与训练实战5.1 从头训练还是微调决策树面向不同场景选路不同如果目标是验证算法、学习原理从头训练一个小型模型数据集 5 万张以内只跑 10-20 轮能看到效果就行如果目标是产品化用预训练模型比如某个已有的文生图基座模型做微调或 LoRA 适配可以大幅节省算力和时间为什么因为从头训练通用文生图模型对算力的要求极高单卡基本没戏。预训练模型已经掌握了“什么是猫、什么是山、什么是光线”的基础知识你要做的无非是在特定风格、特定人物、特定产品上做领域迁移。这就像你不需要重新学一门语言只需要学点行业术语。我这个项目采用的是“预训练 全量微调”的策略加载一个公开的文生图模型权重用 50 万图文对微调 10 个 epoch。全程单卡 8GB 显存借助梯度累积gradient accumulation把有效 batch size 提到 64实际每次前向 16 张累积 4 次再更新一次梯度。5.2 LoRA 微调的配置与实用建议LoRALow-Rank Adaptation 是微调阶段的一个重点。它的思路很巧妙冻结原始模型的大部分权重只在每一层旁边加一个低秩的旁路分支一个小的矩阵分解训练时只更新这个旁路。这样既能达到微调的效果又让可训练参数量急剧下降。Keras 3 实现 LoRA 有两种方式一种是手写一个包装层另一种是用第三方扩展库。我推荐手写一个简单的 LoRA 层来理解原理class LoRALayer(keras.layers.Layer): def __init__(self, original_layer, rank4): super().__init__() self.original_layer original_layer self.original_layer.trainable False self.rank rank self.down_proj self.add_weight( shape(original_layer.units, rank), initializerhe_normal, trainableTrue ) self.up_proj self.add_weight( shape(rank, original_layer.units), initializerzeros, trainableTrue ) def call(self, inputs): original_output self.original_layer(inputs) lora_output tf.matmul(tf.matmul(inputs, self.down_proj), self.up_proj) return original_output lora_outputrank 的选择没有标准答案但有一个经验范围4-16 是常见选择数字越大表达能力越强但过拟合风险也越高。对特定风格的适配比如“水墨风格”“赛博朋克”rank8 基本够用对特定人物的脸部特征学习可能需要 rank16 甚至 32。LoRA 最大的工程价值是“一次训练到处复用”。训练完只导出一个几十 MB 的小权重文件部署时加载到预训练模型上就能生效。不同的 LoRA 权重还可以叠加比如一个风格 LoRA 加一个内容 LoRA给产品提供灵活的配置能力。5.3 训练过程中的监控与判活训练扩散模型最怕的就是“看起来在降 Loss实际什么都没学到”。我训练时同时跟踪几类指标Loss 值本身正常在 0.1-0.3 之间波动稳定下降定期生成的样本可视化每 500 步保存几张图“无图无真相”文本相关性主观评分训练中随机抽几个 prompt看生成图是否真的遵循了描述Loss 持续下降但生成图像一直在模糊色块的状态大概率是模型容量不足或学习率太低。Loss 不降甚至上升大概率是学习率太高、梯度爆炸或数据管道有问题比如标签和图片错位。从训练过程来看我自己用得顺手的监控方式是把生成样本直接写到 TensorBoard 的 image 面板里每个 epoch 看一遍比盯 Loss 曲线直观得多。5.4 显存不够的救急方案显存不够是单卡训练最常见的瓶颈我踩过几次之后总结了三个招数。第一招是用mixed_precision。Keras 3 提供一行开启的混合精度训练让部分张量用 float16 计算显存占用能下降 40% 左右。代价是偶尔出现数值稳定性问题可在 loss 计算上保持 float32 精度。keras.mixed_precision.set_global_policy(mixed_float16)第二招是梯度累积。前向传播若干个小 batch累计梯度后再更新一次等效于增大 batch size显存压力不变。要注意的是 BatchNorm 层在这种模式下表现会异常统计量更新频率降低扩散模型的 U-Net 里通常用 GroupNorm 而不是 BatchNorm所以问题不大。第三招是模型切分。如果模型实在太大可以把 U-Net 的某些层用tf.distribute或手工设置 GPU 显存逐步分配或者干脆把输入分辨率降到 192x192 测试逻辑再回到 256 跑正式训练。6. 从模型到落地部署6.1 导出模型的三种链路训练完成后模型不能直接放到生产环境因为环境不同、接口要求不同。我建议按用途导出不同格式继续训练保存完整 checkpoint权重 优化器状态用于中断后恢复Keras 原生格式适合在 Python 服务端快速加载推理量化 / 转换格式适合部署在边缘设备或 Java/Go 等语言的环境中Keras 3 的model.save()默认保存为.keras格式是 zip 压缩包包含权重、结构、配置非常方便。如果你需要转成其他框架能识别的格式比如 ONNX可以用专门的转换工具。实际部署时我踩过一个坑保存的.keras文件在加载时要求模型类定义相同。如果把自定义的DiffusionModel类写在一个临时脚本里后来类名或路径变了加载就会失败。所以建议把模型类定义放在一个独立模块里保证可复用。6.2 在 CPU 上跑推理的低成本方案不是所有业务场景都有 GPU。例如一个内部小工具只是偶尔用一下文生图功能没必要为了它专门买一张 GPU 卡。但 CPU 推理非常慢一个 256x256 的图50 步采样可能要半分钟到一分钟。低成本方案是提前预计算文本向量只缓存文本向量避免每次重复跑文本编码器把生成过程中的中间结果保存成缓存支持断点续画批量生成时把多张图一次性生成充分利用 CPU 多核。另一个思路是量化。把模型权重从 float32 压到 float16 或 int8推理速度能提升 3-8 倍质量损失在可接受范围。Keras 3 的量化 API 已经比较简单主要操作是把模型各层替换为量化版本。不过量化后对 NaN 和梯度的敏感度比较高部署前务必做一批端到端测试。6.3 部署成后端服务的完整示例把这个模型变成真正可用的服务我用 Flask 写了一个极简 HTTP 服务。为什么选 Flask 而不是 FastAPI因为我这个项目里并发的需求低Flask 足够而且中间件生态丰富排障容易。如果你负责的是一个高并发的生成场景推荐用 FastAPI原生异步。from flask import Flask, request, jsonify import base64 from io import BytesIO from PIL import Image import numpy as np app Flask(__name__) model InferenceModel.load_weights_from_pretrained(...) app.route(/generate, methods[POST]) def generate(): data request.get_json() prompt data.get(prompt, ) negative_prompt data.get(negative_prompt, None) steps int(data.get(steps, 50)) image model.generate(prompt, negative_prompt, steps) buffer BytesIO() Image.fromarray(image).save(buffer, formatPNG) encoded base64.b64encode(buffer.getvalue()).decode(utf-8) return jsonify({image_base64: encoded}) if __name__ __main__: app.run(host0.0.0.0, port8000)这里有两个细节值得说明返回 base64 编码的图像而不是直接返回文件路径因为很多调用方是跨语言、跨服务器的二进制文件传参会很麻烦base64 是通用交换格式。negative_prompt负面提示词是控制生成质量的利器。比如你在 prompt 里写“一只猫”negative_prompt 写“模糊低质量水印”模型在去噪过程中会刻意避开这些负面特征生成结果更干净。第一次部署时我遇到过一个典型问题服务加载模型时占用的内存很大几个 GB如果直接用 Flask 的开发服务器跑单请求模型加载超时很常见。解决办法是在启动时预加载模型只用一次并加大应用服务器的超时设置。生产环境可以再套一层缓存把高频 prompt 的结果直接存内存或 Redis请求来直接返回秒出图。7. 常见问题速查与避坑手册7.1 训练阶段的坑问题现象常见原因解决思路Loss 不降训练 10 轮 loss 依旧在 0.5 以上波动学习率过高或过低用 warmup 余弦退火初始学习率 1e-4生成全黑图生成的图像全黑/全白归一化范围不对确认输入范围是 [-1,1]输出用tanh或clip生成图与文本无关换 prompt 图基本不变文本条件没注入或注入太弱检查文本编码器是否冻结、向量拼接位置是否正确显存溢出跑几步就 OOMbatch 太大 / 分辨率太高降低 batch、开混合精度、梯度累积Loss 下降但图糊全是色块没细节容量不足 / 数据增强过度增大模型容量减少增强幅度7.2 推理阶段的坑推理阶段的问题往往是训练阶段体验不到的。我整理几个最常见的推理速度太慢。解决办法是减少采样步数50 步已经是比较好的平衡点、使用 DDIM 或更快的采样器、开启模型量化和混合精度。生成图像重复度高。同一 prompt 用不同随机种子生成结果太相似。一般是训练数据多样性不足导致少数是采样器本身 randomness 不够。项目里我增加了负 prompt 和随机种子控制多样性有明显改善。图像有明显棋盘格伪影。通常是 U-Net 上采样和卷积配置问题常见于某些自定义模型结构里。检查转置卷积是不是 stride 不对或者反卷积核没有初始化好。模型加载报错 mismatch。多见于自定义层类名不一致导致反序列化失败。建议训练完立刻测试model.save→model.load回环确认无误再进入部署环节。7.3 关于“从概念到落地”我的一点感受踩了几次坑之后我对这个标题里“落地”二字的感受特别深。模型的训练代码再漂亮如果后面没有服务化、接口化和工程化的一环它始终只能在 Notebook 里当个玩具。反过来如果只是把别人的模型包一层 API不做任何训练层面的适配技术含量不低但真正业务效果还是会被数据和 Fine-tuning 质量限制。这个项目的完整链路是整理数据 → 设计模型 → 训练微调 → 导出部署 → API 服务。每一步都有独立的工程坑任何一环断掉都会让整个链路阻塞。如果你刚起步我建议不要直接复刻这个全套工程。先跑通一个“最小闭环”拿公开预训练模型 一个 Flask 接口生成一张图感受一下端到端的体验再一步步替换成自己的模型、自己的数据、自己的优化方案。由简到繁是学习和交付都更稳妥的路径。最后分享一个小技巧训练之前把 prompt 和最终图像固定一组样本作为“验收基线”。模型每训练一段时间就在这组样本上生成一遍肉眼对比前后效果。这比任何 Loss 曲线都更能告诉你模型是否真的在进步。这套方法我沿用至今基本所有生成式项目都会保留这么一组“照妖镜”人眼看一眼胜过刷一百次指标。