本文介绍在使用函数计算部署AI推理应用时,模型存储的常用方法,并对这些方法的优缺点和适用场景进行比较分析。
背景信息
函数的存储类型请参见函数存储选型。其中,适合用作GPU存储模型的包括以下两种。
除此之外,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加速器获得更高的吞吐能力。
管理方法多样:
配置简单:相比NAS文件系统,函数实例挂载OSS Bucket无需打通VPC,即配即用。
成本:相比NAS,一般来说OSS成本更优。
说明
从实现原理上,OSS挂载使用FUSE用户态文件系统机制实现。应用访问OSS挂载点上的文件时,平台最终将其转换为OSS API调用实现对数据的访问。因此OSS挂载还有以下特征:
其工作在用户态,会占用函数实例的资源配额,如CPU、内存、临时存储等,因此建议在较大规格的GPU实例上使用。
数据的访问使用OSS API,其吞吐量和时延最终受限于OSS API服务,因此更适合访问数量较少的大文件(如模型加载场景),不宜用于访问大量小文件。
当前的实现还无法使能系统的PageCache,相比NAS文件系统,这意味着单个实例内应用如果需要多次访问同一个模型文件,无法利用PageCache加速效果。
使用场景
大量实例并行加载模型,需要更高存储吞吐能力避免实例间带宽不足的情况。
需要本地冗余,或者多地域部署的场景。
访问数量较少的大文件(比如模型加载场景)。
总结对比
对比项 | 随镜像分发 | NAS挂载 | OSS挂载 |
模型尺寸 |
| 无 | 无 |
吞吐 | 较快 |
|
|
兼容性 | 好 | 好 |
|
管理方法 | 容器镜像 | VPC内挂载后使用 |
|
多AZ | 支持 | 不支持 | 支持 |
PageCache使能 | 有 | 有 | 无 |
成本 | 不产生额外费用 | 一般来说NAS比OSS略高,请以各产品当前计费规则为准
|
基于以上对比,根据FC GPU不同使用模式、不同容器并发启动数量、不同模型管理需求等维度,FC GPU模型托管的最佳实践如下:
测试数据
通过对Stable Diffusion模型切换耗时的测量,对比不同模型存储方法的性能差异。本次测试的选取的模型和模型尺寸大小如下表。
模型 | 尺寸(GB) |
Anything-v4.5-pruned-mergedVae.safetensors | 3.97 |
Anything-v5.0-PRT-RE.safetensors | 1.99 |
CounterfeitV30_v30.safetensors | 3.95 |
Deliberate_v2.safetensors | 1.99 |
DreamShaper_6_NoVae.safetensors | 5.55 |
cetusMix_Coda2.safetensors | 3.59 |
chilloutmix_NiPrunedFp32Fix.safetensors | 3.97 |
pastelmix-fp32.ckpt | 3.97 |
revAnimated_v122.safetensors | 5.13 |
sd_xl_base_1.0.safetensors | 6.46 |
第一次模型切换耗时(单位:秒) | 第二次模型切换耗时(单位:秒) |
测试结论如下:
PageCache使能。在这个场景中,Stable Diffusion第一次加载模型时,会读取模型文件两次,其中一次用于计算模型文件的哈希值。后续触发模型加载时,则只读取模型文件一次。第一次访问NAS挂载点上的文件时,会在内核填充相应的PageCache,从而加速第二次访问。访问OSS挂载点不具备使能PageCache的特性。
影响耗时的其他因素。除了存储介质本身,模型加载耗时还与应用本身的实现细节相关,如应用本身的吞吐能力,以及读取模型文件时的IO模式(顺序读取、随机读取)。