GPU实例模型存储最佳实践

背景信息

函数的存储类型请参见函数存储选型。其中，适合用作GPU存储模型的包括以下两种。

• 文件系统NAS

• 对象存储OSS

除此之外，GPU函数使用自定义容器镜像部署业务，因此还可以将模型文件直接放置到容器镜像中。

每种方法都有其独特的应用场景和技术特点，选择模型存储方式时应当考虑具体需求、执行环境以及团队的工作流程，以达到模型存储在效率和成本上的平衡。

模型随容器镜像分发

将训练好的模型和相关应用代码一起打包在容器镜像中，模型文件随容器镜像分发，这是最直接的方法之一。

优缺点

优点：

• 便利性：创建好镜像后，可以直接运行它进行推理而无需额外配置。

• 一致性：确保每个环境中的模型版本都是一致的，减少了由于不同环境中模型版本差异导致的问题。

缺点：

• 镜像体积：镜像可能会非常大，特别是对于大尺寸模型。

• 更新耗时：每次模型更新时都需要重新构建和分发镜像，这可能是一个耗时的过程。

说明

为了提升函数实例的冷启动速度，平台会对容器镜像进行预处理。如果镜像尺寸过大，一方面可能会超出平台对镜像大小的限制，另一方面也会导致镜像加速预处理所需时间的延长。

• 关于平台镜像大小限制，请参见GPU镜像大小限制是多少？

• 关于镜像预处理和函数状态的信息，请参见自定义镜像函数状态及调用。

使用场景

• 模型尺寸相对较小，例如百兆字节左右。

• 模型变更频率较低，可以考虑将模型打包在容器镜像中。

如果您的模型文件较大、迭代频繁或随镜像发布时超过平台镜像大小限制，建议模型与镜像分离。

模型放在NAS文件存储

函数计算平台支持将NAS文件系统挂载到函数实例的指定目录，将模型存储在NAS文件系统，应用程序通过访问NAS挂载点目录实现模型文件的加载。

优缺点

优点：

• 兼容性：相比FUSE类文件系统，NAS提供的POSIX文件接口较为完整和成熟，因此在应用兼容性方面表现较好。

• 容量：NAS能够提供PiB级的存储容量。

缺点：

• 依赖VPC网络：一方面，需要为函数配置VPC访问通道才能访问NAS挂载点，在配置时涉及的云产品权限点相对较多；另一方面，函数实例冷启动时，平台为实例建立VPC访问通道会产生秒级的耗时。

• 内容管理方式比较单一：NAS文件系统需要挂载才能使用，相对单一，需要建立相应的业务流程将模型文件分发到NAS实例上。

• 不支持双活和多AZ，详情请参见NAS常见问题。

说明

在大量容器同时启动加载模型的场景下，容易触及NAS的带宽瓶颈，导致实例启动耗时增加，甚至因超时而失败。例如，定时HPA批量设置GPU快照、突发流量触发大量弹性GPU实例的创建。

• 可以从控制台查看NAS性能监控（读吞吐）。

• 可以通过向NAS增加数据量的方式来提升NAS读写吞吐量。

采用NAS来存储模型文件，建议选用通用型NAS中的“性能型”，其主要原因在于该类型NAS可以提供较高的初始读带宽，约600MB/s，详情请参见通用型NAS。

使用场景

在函数计算弹性GPU实例时，需要快速的启动性能。

模型放在OSS对象存储

函数计算平台支持将对象存储OSS Bucket挂载到函数实例的指定目录，应用程序可以直接从OSS挂载点加载模型。

优点

• 带宽：OSS的带宽上限较高，相比NAS不易出现函数实例间带宽争抢现象，详情请见OSS使用限制及性能指标。与此同时，还可以通过开通OSS加速器获得更高的吞吐能力。

• 管理方法多样：

  • 提供控制台、开放API等访问通道。

  • 提供多种本地可用的对象存储管理工具，请参见OSS常用工具。

  • 可使用OSS跨区域复制功能进行模型同步与管理。

• 配置简单：相比NAS文件系统，函数实例挂载OSS Bucket无需打通VPC，即配即用。

• 成本：若仅比较容量和吞吐速率，相比NAS，一般来说OSS的成本更优。

说明

从实现原理上，OSS挂载使用FUSE用户态文件系统机制实现。应用访问OSS挂载点上的文件时，平台最终将其转换为OSS API调用实现对数据的访问。因此OSS挂载还有以下特征：

• 其工作在用户态，会占用函数实例的资源配额，如CPU、内存、临时存储等，因此建议在较大规格的GPU实例上使用。

• 数据的访问使用OSS API，其吞吐量和时延最终受限于OSS API服务，因此更适合访问数量较少的大文件（如模型加载场景），不宜用于访问大量小文件。

• 相比随机读写，OSS挂载对顺序读写更友好。特别地，在加载大文件时，顺序读将能够充分利用文件系统的预读机制，从而达到更优的网络吞吐速率和加载时延。

  • 以safetensors文件为例，使用针对顺序读优化过的版本将大幅缩短从OSS挂载点加载模型文件的耗时：load_file: load tensors ordered by their offsets。

  • 若无法调整应用的IO模式，则可以考虑在加载文件前，先顺序读取一遍文件，将内容预热到系统PageCache，应用后续将从PageCache加载文件。

使用场景

• 大量实例并行加载模型，需要更高的存储吞吐能力，以避免实例间带宽不足的情况。

• 需要本地冗余，或者多地域部署的场景。

• 访问数量较少的大文件（比如模型加载场景），并且IO模式为顺序读取。

总结对比

基于以上对比，根据FC GPU不同使用模式、不同容器并发启动数量、不同模型管理需求等维度，FC GPU模型托管的最佳实践如下：

• 如果对文件系统API兼容性有较高要求，或者应用使用随机读且无法转换为对内存PageCache的访问，推荐使用通用性能型NAS。

• 在大并发GPU容器同时启动使用场景下，为了避免NAS的单点带宽瓶颈，推荐OSS ACCL。

• 在多地域单元化部署使用场景下，为了减少模型管理复杂度与跨域同步难度，推荐OSS和OSS ACCL。

测试数据

通过对Stable Diffusion模型切换耗时的测量，对比不同模型存储方法的性能差异。本次测试的选取的模型和模型尺寸大小如下表。

测试结论如下：

• PageCache使能。在这个场景中，Stable Diffusion第一次加载模型时，会读取模型文件两次，其中一次用于计算模型文件的哈希值。后续触发模型加载时，则只读取模型文件一次。

• OSS场景下，应用读取模型文件的IO模式对耗时影响非常大，图中safetensors文件加载使用了顺序读优化过的版本，否则加载耗时将大大增加。

• 影响耗时的其他因素。除了存储介质本身，模型加载耗时还与应用本身的实现细节相关，如应用本身的吞吐能力，以及读取模型文件时的IO模式（顺序读取、随机读取）。