监控让您能充分了解已部署的扩散模型的性能和健康状况。当监控发现性能下降、生成质量降低、模型漂移等问题，或者您开发出了一个改进的模型版本时，您就需要采取策略对生产环境中的模型进行再训练和更新。手动执行这些更新在大规模情况下不切实际且有风险。因此，建立自动化、可靠的流程对于维持高质量服务是必不可少的。
模型更新的触发因素
有几个因素可能需要对您已部署的扩散模型进行再训练或更新：
- 性能下降： 监控可能显示平均生成延迟（Lgen）增加、请求吞吐量 (throughput)（Treq）减少、错误率提高或GPU利用率不佳（Ugpu）。这可能源于请求模式的变化、基础设施问题或模型轻微的性能衰退。
- 语义漂移： 用户请求的图像类型或风格可能随时间变化。如果模型在不再反映当前使用模式的数据上进行训练，其输出质量或相关性可能会降低。这是一种语义漂移的形式。
- 数据漂移： 输入数据（例如，文本提示、条件图像）的统计属性可能发生变化，这可能导致模型生成质量较低的输出。
- 质量下降： 自动化质量指标或人工反馈循环可能表明生成图像的感知质量、连贯性或美学吸引力有所下降。
- 新数据可用： 您可能获得了新的训练数据，可以提高模型的能力，涵盖代表性不足的类别，或增强其与期望风格的一致性。
- 改进的模型架构或训练技术： 研究常产生更好的模型架构、训练方案或优化方法（如改进的采样器或微调 (fine-tuning)策略），这些都值得更新已部署的模型。
- 错误修复或依赖更新： 可能需要更新以修复模型推理 (inference)代码、评分逻辑或底层依赖项（例如 PyTorch、Diffusers 库）中的错误。
再训练与微调 (fine-tuning)
当触发更新时，您通常有两种主要方法：
- 完全再训练： 使用更新的数据集或训练配置，从头开始或从基础检查点训练模型。这计算密集且昂贵，特别是对于大型扩散模型，但对于重大的架构变化或解决根本问题可能是必要的。
- 微调： 获取一个现有已训练模型的检查点，并继续训练过程，步数较少，通常在更具体或更新的数据集上进行。微调通常比完全再训练快得多且便宜得多。它对于使模型适应新数据、调整其风格或纳入增量改进非常有效。
选择取决于更新的原因、所需更改的程度以及可用的计算资源。对于适应中度漂移或纳入较小的新数据集，微调通常是首选方法。
候选模型的评估
在部署更新后的模型之前，必须进行严格评估。这通常包括：
- 离线评估： 使用定量指标（例如，FID、IS、CLIP 分数，如果适用）在保留的评估数据集上评估候选模型，并将其与当前已部署的模型进行比较。推理 (inference)延迟和内存使用等性能指标也应进行基准测试。
- 定性评估： 使用代表性提示（包括边缘情况）生成多样化的样本图像集，并由人工评审员评估其质量、风格一致性以及对提示的遵守情况。这种主观评估对于生成模型尤为重要，因为客观指标无法反映全貌。
"3. 影子部署（可选）： 将候选模型与生产模型并行部署，向其提供一部分实时流量，但不将结果返回给用户。这使您可以在全面上线前监控其性能、稳定性以及生成质量。"
模型的持续集成与持续部署（CI/CD）
手动管理再训练、评估和部署过程效率低下且容易出错。实施专门为机器学习 (machine learning)工作流设计（常称为MLOps流水线）的CI/CD流水线是模型更新的标准做法。
用于更新扩散模型的典型CI/CD流水线可能如下所示：
一个典型的模型再训练和部署CI/CD流水线，包含构建、训练、评估、注册、预发布、测试、批准和部署到生产环境等阶段。
此类流水线的主要组成部分包括：
- 源代码管理： 用于训练、推理 (inference)和基础设施的代码在Git中管理。
- 自动化构建与测试： 确保代码质量并构建容器镜像。
- 自动化训练/微调 (fine-tuning)： 在专用基础设施（例如，带有GPU的Kubernetes集群、云AI平台）上触发训练任务。
- 实验追踪： 记录每次训练运行的参数 (parameter)、指标和工件（使用MLflow、Weights & Biases等工具）。
- 模型注册中心： 一个集中式系统（例如，MLflow模型注册中心、SageMaker模型注册中心、Vertex AI模型注册中心），用于对已训练模型工件和元数据进行版本管理、存储和管理。这便于检索特定模型版本以进行部署。
- 自动化评估： 运行评估脚本并生成报告。
- 预发布环境： 一个类似生产的环境，用于在部署给真实用户之前的最终测试。
- 部署策略： 实施安全的发布模式。
安全部署策略
简单地将旧模型即时替换为新模型（“原地”更新）是有风险的。如果新模型存在未预见的问题，它会立即影响所有用户。更安全的策略包括：
- 蓝绿部署： 维护两个相同的生产环境：“蓝色”（当前在线版本）和“绿色”（新版本）。一旦“绿色”环境经过测试并准备就绪，流量就会从“蓝色”切换到“绿色”。如果出现问题，流量可以迅速切换回“蓝色”。这最大限度地减少了停机时间，但在切换过程中需要两倍的基础设施。
- 金丝雀发布： 逐步将一小部分生产流量（例如1%、5%、20%）路由到新的模型版本，同时密切监控其性能和质量。如果它表现良好，则逐步增加流量百分比，直到处理100%。如果出现问题，流量可以迅速路由回稳定版本，限制影响。
- 滚动更新： 随着时间推移，逐步用运行新版本模型的实例替换运行旧版本模型的实例。这在Kubernetes等容器编排系统中很常见。
第6章“高级部署技术”更详细地讨论了金丝雀发布和A/B测试，但主要原则是在模型转换期间最小化风险。
回滚机制
任何更新策略中必不可少的部分是，如果新模型导致问题（例如崩溃、高错误率、低质量生成、意外成本），能够快速回滚到之前稳定的版本。CI/CD流水线和模型注册中心通过追踪以前的版本并提供快速重新部署它们的机制来促进这一点。
通过将这些再训练和更新策略整合到您的MLOps实践中，您可以确保已部署的扩散模型随着时间推移保持有效、高效，并与用户期望保持一致，即使数据、需求和模型本身都在演变。
