在部署扩散模型时，尤其是在为弹性设计的环境中，比如无服务器平台或自动伸缩的容器集群，“冷启动”现象会带来一个重要的操作难题。冷启动指的是一个非活跃的计算实例（如无服务器函数或容器副本）在空闲一段时间后收到第一个请求时所经历的延迟。在此期间，底层基础设施需要配置资源、下载代码或容器镜像、初始化运行时环境，并且对于扩散模型来说，最重要的是将大型模型权重 (weight)和依赖项载入内存，这通常还包括 GPU 的初始化。
本节考察了冷启动对扩散模型推理 (inference)造成的具体困难，并审视了在无服务器和容器化设置中减轻其影响的方法，延续本章前面讨论过的进阶部署主题。
为何扩散模型会加剧冷启动延迟
虽然冷启动影响很多应用程序，但由于以下几个因素，它们对扩散模型来说尤其成问题：
- 模型体积大： 扩散模型的检查点通常从数百兆字节到数千兆字节不等。下载并载入这些大文件到内存中，尤其是到 GPU 内存中，非常耗时。
- 依赖项复杂： 运行扩散模型的 Python 环境通常包含 PyTorch 或 TensorFlow、CUDA 工具包、xFormers 以及各种图像处理库等大型库。初始化这些依赖项会增加启动时间。
- GPU 初始化： 如果实例需要 GPU 访问（对于高效推理 (inference)来说，几乎总是如此），该过程涉及初始化 GPU 驱动、分配内存，有时还需要编译特定于模型和硬件的 CUDA 内核（例如，通过 TensorRT 或 OpenVINO，如第 2 章所述）。这会带来不小的延迟。
- 资源分配延迟： 在高弹性环境中，平台本身可能需要时间来分配所需的 CPU、RAM，尤其是 GPU 资源，然后初始化过程才能开始。
累积效应是，扩散模型推理端点的冷启动延迟可以轻易地延长到数十秒甚至数分钟，远远超出许多交互式应用程序的可接受限度。
请求流程图，说明了与使用热的、就绪实例处理请求相比，冷启动所涉及的额外步骤和延迟。
冷启动的影响
冷启动的主要影响是新实例处理的第一个请求的端到端延迟显著增加。这会导致：
- 用户体验不佳： 与需要同步请求图像生成的应用程序交互的用户可能会面临长时间等待或超时。
- 上游超时： 调用扩散模型 API 的服务在等待响应时可能会超时，导致连锁故障。
- 资源使用效率低： 尽管设计初衷是为了节省成本，但如果实例不断初始化而不是处理请求，频繁的冷启动可能会抵消收益。自动伸缩器也可能因为对冷启动延迟导致的突发流量反应过慢而过度配置资源。
无服务器环境中的缓解方法
无服务器平台（例如 AWS Lambda、Google Cloud Functions、Azure Functions）通常提供应对冷启动的机制，尽管它们会带来成本影响：
- 预置并发 / 最少实例数： 这是最直接的方法。平台允许你付费以保持特定数量的函数实例持续初始化并准备就绪（“热”状态）。这有效地消除了命中这些预置实例的请求的冷启动，但即使在空闲时也会产生费用。
- 考虑事项： 确定基线流量水平，并将预置并发配置略高于该水平，以处理典型负载，同时依靠标准伸缩来应对不频繁的突发。
- 优化部署包： 减小函数代码和依赖项的大小。
- 移除未使用的库。
- 从快速的共享位置（例如挂载到 Lambda 的 AWS EFS）载入模型权重 (weight)，而不是将其打包在部署包中或在初始化期间从较慢的对象存储（例如 S3）下载。每次冷启动时从 S3 下载大型模型是造成延迟的主要因素。
- 内存/CPU 分配： 无服务器函数中更大的内存分配通常伴随着按比例增加的 CPU 算力 (compute)，有时还有更好的网络带宽。尝试不同的配置，因为增加资源可以显著加快初始化阶段，包括模型载入。
- 分层载入 / 惰性初始化： 如果可行（对于单体扩散模型架构通常有难度），最初只载入必需的组件，并将不那么重要的部分或替代模型/LoRA 的载入推迟到特定请求时进行。
- 自定义运行时 / 层： 优化运行时环境本身。对于 AWS Lambda，使用优化层或自定义运行时有时可以比默认运行时提供更好的性能优势，尤其是在涉及编译步骤的情况下。
- “预热”调用： 定期安排函数的虚拟调用（例如，每 5-10 分钟一次），以保持一组实例处于热状态。这不如预置并发可靠，并且预热调用仍然会产生费用。
容器环境（Kubernetes）中的缓解方法
当使用 Kubernetes 等系统编排的容器时，适用类似的原则，但实现细节有所不同：
- 最小副本数： 配置你的部署（例如，Kubernetes
Deployment 对象）以维护最少数量的副本（spec.replicas），或使用将 spec.minReplicas 设置为大于零的水平 Pod 自动伸缩器（HPA）。这确保了至少有这么多 Pod 始终运行，尽管如果长时间空闲且没有流量，它们可能不一定能保持模型已载入的“热”状态。
- 优化容器镜像：
- 使用多阶段构建来创建只包含必要运行时工件的精简生产镜像。
- 最小化层数并优化层顺序，以有效利用构建缓存。
- 如果模型非常大，请确保它不是镜像层的一部分；而是从持久卷载入或在容器启动期间高效下载它。
- 高效模型载入：
- 持久卷（PV）： 将模型检查点存储在所有 Pod 都可以访问的共享持久卷（例如 NFS、CephFS、云提供商文件存储）上。Pod 挂载 PV 并直接载入模型，避免下载。确保存储后端提供足够的读取 IOPS。
- 初始化容器： 使用 Kubernetes 初始化容器在主应用程序容器启动前下载模型。这分离了职责，但除非并行化或优化，否则并不能从根本上加快下载速度。
- Sidecar 缓存： Sidecar 容器可以管理模型缓存或预取，可能与主推理 (inference)容器共享一个卷。
- 镜像拉取策略和预拉取： 仅在必要时才设置
imagePullPolicy: Always。使用 IfNotPresent（默认）可避免重复拉取。考虑使用 DaemonSet 或 cron job 将大型推理镜像预拉取到可能调度推理 Pod 的节点上。
- 精确就绪探测： 配置 Kubernetes 就绪探测（
spec.containers.readinessProbe），不仅检查应用程序服务器是否正在运行，还要检查扩散模型是否已完全载入并准备好接受推理请求。这可以防止流量被路由到仍在初始化的 Pod。探测可能涉及发出一个轻量级推理请求或检查内部状态端点。
- 资源请求和限制： 在 Pod 规范中准确定义 CPU、内存和 GPU 资源请求（
spec.containers.resources.requests）。这有助于 Kubernetes 调度器将 Pod 放置在具有足够可用资源的节点上，减少因资源争用或调度失败导致的启动延迟。
- 节点亲和性/容忍度： 使用节点亲和性规则，优先将推理 Pod 调度到已安装所需 GPU 驱动且可能已缓存容器镜像的节点上，从而减少设置时间。
- 过度配置（热池）： 类似于无服务器预置并发，通过
minReplicas 控制，维持一个比当前预期需求略大的就绪 Pod 池。这提供了一个热实例的缓冲，可供立即使用。
扩散模型请求在冷实例和热实例上的延迟分解示例。请注意 Y 轴的对数刻度突出了冷启动期间初始化和模型载入的重大影响。
平衡成本与延迟
缓解冷启动几乎总是涉及延迟和成本之间的权衡。保持实例热（通过预置并发或最小副本数）可减少初始请求的延迟，但会增加运营开销，因为即使在空闲时也会配置资源。
最佳方法取决于：
- 应用程序要求： 用户体验或下游系统对延迟的敏感度如何？
- 流量模式： 流量是突发性的还是相对稳定的？稳定的流量从保持热实例中受益更多。
- 预算限制： 对增加的基础设施成本的容忍度是多少？
使用点播实例（前面已介绍）作为热池等方法可以帮助管理成本，但会引入处理中断的复杂性。仔细监控性能指标（延迟、P95/P99 延迟）和成本，对于找到适当的平衡非常重要。
总结来说，管理冷启动是在弹性环境中大规模运行扩散模型的一个重要方面。通过理解造成影响的因素并针对无服务器或容器平台采用有针对性的缓解方法，你可以显著减少延迟影响，尽管这通常需要仔细考虑相关的成本影响。将基础设施方法与模型优化技术（第 2 章）结合起来，可以提供一个全面的方案，用于提供响应迅速且高效的扩散模型推理 (inference)。
