目录

1. 问题诊断：启动时间缓慢的根源

2. 启动时间优化的三大策略

策略一：优化 Dockerfile 减小基础镜像

策略二：利用 PD 磁盘镜像存储运行时依赖

策略三：利用 GKE Image Streaming 和集群自动缩放器

3. 最终结果：启动时间显著提速

---

1. 问题诊断：启动时间缓慢的根源

对 Stable Diffusion WebUI 容器启动过程的时间序列分析显示，运行在容器中的 Stable Diffusion WebUI 启动缓慢主要是由于：

镜像体积庞大：Stable Diffusion 的容器镜像高达 10-20GB。

依赖项重：整个运行时的依赖项较重，导致拉取镜像和初始化 Pod 的时间变长。

在原始启动流程中，从触发 Cluster Autoscaler 到最终服务可用，总耗时超过 10 分钟。因此，优化启动时间成为提高用户体验的关键。

2. 启动时间优化的三大策略

本文重点介绍通过将基础环境与运行时依赖分离，并利用高性能磁盘映像来优化 Stable Diffusion WebUI 容器启动时间的解决方案：

策略一：优化 Dockerfile 减小基础镜像

在对 Stable Diffusion WebUI 官方安装说明的 Dockerfile 进行分析后发现，原始镜像体积达 16.3GB，其中 PyTorch 库就占用了约 5GB。团队决定遵循最小可行环境的原则，将 PyTorch 库、Stable Diffusion 库和扩展从原始镜像中分离出来，只在基础镜像中保留了 NVIDIA 运行时，从而显著减小了基础镜像的体积。

策略二：利用 PD 磁盘镜像存储运行时依赖

将所有运行时库和扩展存储在 PD 磁盘映像中，其大小约为 6.77GB。利用磁盘镜像的优势是最多可以支持 1000 个磁盘同时恢复，非常适合大规模扩缩容的场景。

部署机制：通过 DaemonSet 在 GKE 节点启动时挂载包含运行时依赖项的 PD 磁盘。

服务访问：Stable Diffusion 部署通过 HostPath 访问该磁盘，将运行时环境的创建与容器启动解耦。

策略三：利用 GKE Image Streaming 和集群自动缩放器

GKE Image Streaming：Image Streaming 通过使用网络挂载将容器的数据层附加到 containerd，并利用多层缓存，实现了无论容器大小如何，容器都能在几秒钟内从 ImagePulling 状态转换为 Running 状态，有效将应用启动与数据传输并行化。

集群自动缩放器（CA）优化：启用了 CA 功能，并在新节点注册时通过 DaemonSet 协助挂载磁盘。同时，还利用了 CA 的优化利用率配置文件，该配置优先考虑利用率而非保留备用资源，以进一步减少扩展时间、节省成本并提高机器利用率。

3. 最终结果：启动时间显著提速

最终的启动结果显示出显著的性能提升：

关键事件	优化前时间（秒）	优化后时间（秒）
触发 CA 缩放	225	38
节点启动和 Pod 调度	（已合并）	89
镜像拉取	323（5 分 23 秒）	1
Pod 启动	1	1
服务可用时间（约）	12 分钟以上	约 3 分钟（190 秒）

总体而言，启动新的 Stable Diffusion 容器实例并开始在新的 GKE 节点上提供服务大约只需要 3 分钟，与之前的 12 分钟相比，启动速度的显著提升，极大地改善了用户体验。