大规模部署扩散模型带来了大量存储需求，不仅是模型本身（可达数千兆字节），也包括它们可能生成的海量数据。在构建容器化、编排式基础设施时，对存储做出明智的决策对于性能、成本和运营效率很要紧。
扩散模型的检查点通常在2GB到10GB以上。高效地将这些模型加载到可能许多推理 (inference)服务器的内存中，特别是在扩展事件或Pod重启期间，直接影响服务可用性和冷启动延迟。此外，生成的输出（通常是图片）需要在其生命周期内可靠地存储、便捷地访问并经济高效地管理。
我们来分析一下主要的存储考量以及在可伸缩扩散模型部署背景下的常见方案。
存储模型权重 (weight)
主要难题是为大型模型文件提供快速、可靠的访问，供可能许多分布式推理 (inference)工作程序使用（例如，Kubernetes集群中的Pod）。有几种方法，每种都有其利弊：
-
对象存储（例如，AWS S3、Google Cloud Storage、Azure Blob Storage）：
- 优点： 高可伸缩、持久，通常是每GB最具成本效益的存储方案。非常适合集中管理模型工件。支持版本控制，有助于模型管理。
- 缺点： 与块存储或文件存储相比，读取延迟较高。直接将对象存储挂载为文件系统可能复杂或存在性能局限。需要一种机制将模型下载到本地计算节点。
- 使用模式： 将模型的规范版本存储在对象存储中。实现一个流程（例如，在Kubernetes中使用init容器或启动脚本），在推理服务器启动时将所需模型版本下载到其本地磁盘（或更快的附加卷）上。这会增加启动时间，但使用了经济高效的存储。节点上的缓存机制可以缓解重复下载，如果多个推理进程在同一节点上运行，或者Pod在具有热缓存的节点上频繁重新调度。
-
网络文件系统（NFS）（例如，AWS EFS、Google Filestore、Azure Files）：
- 优点： 可由许多读取器（推理Pod）同时挂载。提供标准文件系统接口，简化应用程序代码的访问。模型的更改对所有客户端立即可见（尽管仍可能需要仔细的缓存管理）。
- 缺点： 可能比对象存储昂贵得多。在高负载下，性能（IOPS、吞吐量 (throughput)）可能成为瓶颈，特别是当许多Pod试图同时读取大型模型文件时。性能层级通常决定成本。
- 使用模式： 使用Kubernetes持久卷（PV）和持久卷声明（PVC）将共享文件系统直接挂载到推理Pod中。模型直接从NFS挂载点读取。适用于额外成本可接受且并发读取性能符合要求的场景。负载下的细致性能测试很要紧。
-
块存储（例如，AWS EBS、Google Persistent Disk、Azure Managed Disks）：
- 优点： 与对象存储或通用NFS相比，提供更低的延迟和更高的IOPS/吞吐量。
- 缺点： 通常不能由多个Pod以读写模式同时挂载（尽管某些平台存在只读多挂载选项）。比对象存储更昂贵。为每个Pod管理单独的卷会增加操作负担。
- 使用模式： 对于许多无状态推理Pod之间的共享模型存储，这种方式不太常见。如果模型在启动时预先烘焙到节点镜像中，或从中央存储库（如对象存储）复制到本地节点存储（如用于临时速度的实例存储SSD），则可能会使用此方式。如果底层存储提供商支持，也可以在Kubernetes中使用ReadOnlyMany卷访问模式。
-
容器镜像层：
- 优点： 初始时最简单的方法；模型是可部署单元的一部分。
- 缺点： 对于大型扩散模型来说效率极低。导致容器镜像极其庞大（数GB），在伸缩/部署期间镜像拉取时间慢，以及容器注册表存储成本高。更新模型需要重新构建和重新部署整个镜像。通常不建议将此方法用于大型模型的生产部署。
从推理Pod访问模型权重的常见模式。对象存储通常需要下载步骤，而NFS允许直接挂载。块存储在许多Pod之间共享访问的情况较少见。
建议： 对于大多数可伸缩部署，将模型存储在对象存储中并在推理节点上实施高效的下载和缓存机制（使用init容器或类似技术）提供了成本、可伸缩性和可管理性的最佳平衡。确保节点具有快速的本地存储（例如，云虚拟机上可用的本地SSD）或足够高性能的附加块存储，以便在初次下载后缓存模型以实现低延迟访问。
存储生成数据
一旦生成图片（或其他工件），就需要对其进行存储。这里的要求与模型存储不同：
- 写入性能： 生成的数据能多快保存而不阻塞推理 (inference)工作程序？
- 持久性： 生成的数据通常需要可靠地持久化。
- 可访问性： 下游系统或用户将如何访问生成的数据？
- 成本： 存储可能数百万或数十亿图片需要经济高效的方案。
- 元数据： 有关生成的信息（提示词 (prompt)、参数 (parameter)、用户ID）如何与存储的工件关联？
常见方法包括：
-
对象存储： 几乎总是最终生成工件的首选存储目的地。它在大容量数据的持久性、可伸缩性和成本效益方面表现出色。
- 使用模式： 推理工作程序生成图片，可能将其写入临时本地缓冲区，然后异步上传到对象存储桶。使用异步上传很要紧，以快速释放推理工作程序（和GPU）用于下一个请求。API响应可能返回一个唯一ID或一个预签名URL，指向对象存储中的最终位置。元数据通常单独存储在数据库中（例如，PostgreSQL、DynamoDB），将ID与生成参数和对象存储路径关联起来。
-
临时本地存储（临时性）： 容器/Pod具有临时本地存储。
- 使用模式： 可用于生成过程中的中间文件或作为异步上传到对象存储之前的临时缓冲区。不适合长期存储，因为Pod终止时数据会丢失。确保为Pod/节点分配了足够的临时存储。
-
数据库： 虽然原始图片数据因大小和成本很少直接存储在传统数据库中，但数据库对于管理与生成图片相关的元数据是必不可少的。
不同存储类型基于成本和访问延迟的示意性比较。对象存储成本最低但延迟较高，而本地SSD提供最快的访问速度，但可能带来更高的实际成本或临时性。请注意，坐标轴是对数刻度。
与基础设施的集成
在Kubernetes环境中：
- 模型加载： 使用init容器以及
aws s3 cp、gsutil cp或自定义下载器等工具，将模型从对象存储拉取到共享的emptyDir卷（如果Pod中多个容器需要）或直接到容器的文件系统或由快速本地/块存储支持的挂载卷。通过Kubernetes Secrets配置安全凭证（例如，作为文件挂载或环境变量）。
- 生成数据： 推理 (inference)应用程序代码使用云提供商SDK（如AWS的Boto3、GCP的google-cloud-storage）异步上传结果到对象存储。凭证同样通过Secrets管理。
- 卷管理： 如果使用NFS或块存储，请使用适当的PV/PVC，并通过云提供商CSI驱动程序管理。
选择正确的存储策略需要平衡模型加载时间（影响冷启动和扩展速度）、存储模型和生成数据的成本以及实现和管理的复杂性。对于大规模扩散模型部署，对象存储用于持久化，以及更快的本地或网络存储用于缓存和活跃使用，这种组合通常是最有效的方式。
