JuiceFS 在多云架构中加速大模型推理

在大模型的开发与应用中，数据预处理、模型开发、训练和推理构成四个关键环节。本文将重点探讨推理环节。在之前的博客中，社区用户 BentoML 和贝壳的案例提到了使用 JuiceFS 社区版来提高模型加载的效率。本文将结合我们的实际经验，详细介绍企业版在此场景下的优势。

下图是一个典型的大模型推理服务的架构。我们可以观察到几个关键特点。首先，架构跨越多个云服务或多个数据中心。目前在大模型领域， GPU 资源紧张，多数厂商或公司倾向于采用多云、多数据中心或混合云的策略来部署他们的推理服务。

另一个特点是，为了确保数据一致性和管理的便捷性，会在特定地区选择公有云的对象存储作为所有模型数据的存储点。当进行推理任务调度时，可能会选取特定云服务进行任务调度。数据模型的拉取过程需要人工介入，如提前进行数据拷贝。这是因为调度系统不清楚当前数据中心具体需要哪些数据，而这些数据又是动态变化的，所以数据拷贝过程会带来额外成本。

此外，从每个推理计算集群的内部情况来看，由于是规模庞大的集群，会有数百到数千 GPU 卡，因此在推理服务器初始化时，会有高并发模型数据拉取需求。

因此，概括地说在大模型推理与存储相关的挑战主要集中这样几个方面：高效访问数据、跨区域数据快速分发、存量数据读取以及资源优化。接下来将逐个为大家介绍我们在这些场景中的实践经验。

挑战 1：如何保证大模型数据的高吞吐、高并发读取？

推理环节常需处理百 GB 级别的模型文件，满足高并发顺序读取需求。加载速度是用户最关注的问题之一。
为了满足这种场景的性能需求，可以借助 JuiceFS 企业版的分布式缓存构建大规模的缓存空间。将常用模型数据集中存储在缓存集群中，能显著提高数据读取速度，特别是在同时启动数千个推理实例时。此外，对于需要频繁切换模型的 AI 应用场景，如 Stable Diffusion 文生图服务，缓存集群可以大幅减少模型加载时间，从而直接提升用户体验。

例如在单机单卡加载 Safetensors 格式的 Stable Diffusion 模型时，从缓存集群读取数据的延迟可低至 0.5ms，而从对象存储读取的延迟通常在 20ms 左右， 性能提升了将近 40 倍。

下图是 JuiceFS 分布式缓存的架构图，上层为推理集群，中间层为 JuiceFS 缓存集群，底层为对象存储，右上角是元数据服务。在推理服务部署后，首先通过推理集群上挂