北京怎样建设公司网站,网络公司是什么意思,做网批那个网站好,电商网站开发设计方案在大模型的开发与应用中#xff0c;数据预处理、模型开发、训练和推理构成四个关键环节。本文将重点探讨推理环节。在之前的博客中#xff0c;社区用户 BentoML 和贝壳的案例提到了使用 JuiceFS 社区版来提高模型加载的效率。本文将结合我们的实际经验#xff0c;详细介绍企…在大模型的开发与应用中数据预处理、模型开发、训练和推理构成四个关键环节。本文将重点探讨推理环节。在之前的博客中社区用户 BentoML 和贝壳的案例提到了使用 JuiceFS 社区版来提高模型加载的效率。本文将结合我们的实际经验详细介绍企业版在此场景下的优势。
下图是一个典型的大模型推理服务的架构。我们可以观察到几个关键特点。首先架构跨越多个云服务或多个数据中心。目前在大模型领域 GPU 资源紧张多数厂商或公司倾向于采用多云、多数据中心或混合云的策略来部署他们的推理服务。 另一个特点是为了确保数据一致性和管理的便捷性会在特定地区选择公有云的对象存储作为所有模型数据的存储点。当进行推理任务调度时可能会选取特定云服务进行任务调度。数据模型的拉取过程需要人工介入如提前进行数据拷贝。这是因为调度系统不清楚当前数据中心具体需要哪些数据而这些数据又是动态变化的所以数据拷贝过程会带来额外成本。
此外从每个推理计算集群的内部情况来看由于是规模庞大的集群会有数百到数千 GPU 卡因此在推理服务器初始化时会有高并发模型数据拉取需求。
因此概括地说在大模型推理与存储相关的挑战主要集中这样几个方面高效访问数据、跨区域数据快速分发、存量数据读取以及资源优化。接下来将逐个为大家介绍我们在这些场景中的实践经验。
挑战 1如何保证大模型数据的高吞吐、高并发读取
推理环节常需处理百 GB 级别的模型文件满足高并发顺序读取需求。加载速度是用户最关注的问题之一。 为了满足这种场景的性能需求可以借助 JuiceFS 企业版的分布式缓存构建大规模的缓存空间。将常用模型数据集中存储在缓存集群中能显著提高数据读取速度特别是在同时启动数千个推理实例时。此外对于需要频繁切换模型的 AI 应用场景如 Stable Diffusion 文生图服务缓存集群可以大幅减少模型加载时间从而直接提升用户体验。
例如在单机单卡加载 Safetensors 格式的 Stable Diffusion 模型时从缓存集群读取数据的延迟可低至 0.5ms而从对象存储读取的延迟通常在 20ms 左右 性能提升了将近 40 倍。
下图是 JuiceFS 分布式缓存的架构图上层为推理集群中间层为 JuiceFS 缓存集群底层为对象存储右上角是元数据服务。在推理服务部署后首先通过推理集群上挂载的 JuiceFS 访问所需的模型数据。如果数据可以在推理集群的本地内存缓存中找到则直接使用若未命中则查询位于中间的缓存集群。缓存集群如果也未命中最后会从对象存储读取数据。 虽然推理集群和缓存层从图上看似乎是分开的两个层次但在实际应用或部署中如果GPU 机器上有 NVMe SSD这两层可以合并。
在每个 GPU 机器都配备多块 SSD 的情况下下图示例中每个 GPU 机器配有三块 SSD其中一块 SSD 用作本地缓存其余两块 SSD 则用作分布式缓存的存储盘。这种情况下我们推荐一个部署方式在一个 GPU 服务器上部署两个客户端FUSE daemon 和缓存集群客户端。当推理任务需要读取数据时它首先会尝试从本地 FUSE 挂载点读取数据。如果本地缓存中没有相应的模型数据推理任务将通过同一台机器上的另一个 JuiceFS 客户端访问分布式缓存。完成数据读取后数据将返回给推理任务并在缓存集群管理的两块 SSD 及本地 FUSE 挂载点上缓存以便未来快速访问。 这种在一个 GPU 服务器上部署两个客户端的做法有两个主要好处
首先通过本地缓存可以尽量减少网络通信的开销虽然 GPU 服务器间通过高速网卡进行网络通信但网络通信本身还是会产生大量的开销其次通过缓存集群客户端可以让推理任务访问其它 GPU 服务器上的数据实现一个分布式缓存集群的效果。
挑战 2如何在多云、混合云架构中有效地分发模型数据到各计算节点
在多云和混合云架构中由于数据分散在不同的云平台和数据中心传统的手动介入、拷贝和迁移方法不仅成本高而且管理和维护也较为复杂包括权限控制在内的各种问题都十分棘手。
JuiceFS 企业版镜像文件系统功能允许用户将数据从一个地区复制到多个地区形成一对多的复制关系。整个复制流程对用户和应用来说是透明的只需将数据写入指定区域系统便会自动规划并复制到其它多个区域。
下图展示了在镜像文件系统中数据写入与数据读取时的流程。图中展示了两个区域源区域和镜像区域。当数据在源区域写入时JuiceFS 会自动将数据从源区域复制到镜像区域。 在读取数据时镜像区域的客户端首先尝试从其所在区域的对象存储中拉取数据。如果数据不存在或因同步延迟未到达则自动回退到源区域存储通过备用数据源链路拉取数据。因此镜像区域的所有客户端最终都能访问到数据虽然部分数据可能来自备用数据源。 写数据流程示例
这里展示了一个大模型企业实际部署镜像文件系统的案例其架构与文章开头展示的典型架构图相似。在图的顶部有一个中心集群该集群作为数据生产的源头。 步骤 1写数据。数据首先在中心集群中被创建并写入步骤 2全量镜像元数据。数据生产完成后将写入到 JuiceFS 中触发元数据的全量镜像流程。如图所示数据从中心的 JuiceFS 元数据服务被镜像到一个或多个边缘集群本例中为三个使得边缘集群能够就近访问本地集群内的元数据步骤 3预热缓存可选。这一步是为了优化数据访问速度。当有新数据添加后除了复制元数据外还希望能够就近访问这些数据。在没有对象存储的环境中可以结合分布式缓存功能在每个机房内部署一个分布式缓存集群。然后通过缓存预热将新增的数据复制到每个边缘集群的缓存集群中从而加速数据访问。
读数据流程示例
步骤 1访问镜像的元数据服务。如上图绿色编号所示当 GPU 集群需要获取模型数据时首先会访问镜像的元数据服务步骤 2读取元数据并获取数据。在读取到元数据后客户端会首先尝试通过机房内的缓存集群获取所需数据。如果之前进行了缓存预热那么大多数情况下可以直接在机房内的缓存集群中命中所需的模型数据步骤 3回源数据。如果由于某种原因未能在缓存集群中找到数据也无需担心因为所有缓存集群的节点都会自动回源至中心的对象存储桶中获取最终的原始数据。
因此整个数据读取流程是畅通无阻的。即使部分数据未被预热或新数据尚未预热成功也可以通过自动回源的方式从中心的 JuiceFS 存储桶中拉取数据。
挑战 3低成本高效读取海量存量数据
除了多云、混合云架构下数据分发的挑战还有一个常见的需求在与多家大模型公司的交流中我们了解到许多公司希望将其积累的大量原始数据如数 PB 级别直接迁移到 JuiceFS 中。这种需求增加了大规模数据管理的复杂性并可能需要进行数据双写等调整这些都可能影响业务流程的正常运作。
JuiceFS 企业版的「导入对象存储元数据」功能使得企业可以更高效地完成数据导入同时减少对业务的侵入性。用户无需进行数据拷贝只需持续导入元数据即可。同时导入的数据可以通过 JuiceFS 的分布式缓存进行加速从而提升数据访问速度。下图是该功能的工作流程示意图 第一步导入元数据。通过 JuiceFS 的命令行工具用户可以选择性地导入原始数据桶中的部分数据而不必导入整个存储桶。这一过程主要通过前缀匹配实现此步骤仅涉及元数据的导入不拷贝对象存储中的数据因此导入流程会很快完成。
元数据导入不是一次性的操作随着原始数据的增加或修改用户可以再次执行增量导入无需担心重复导入造成额外开销。每次增量导入时系统只会导入新增或修改的部分数据的元数据不会重复导入已处理的文件从而避免额外负担。
第二步读取元数据。当元数据导入到 JuiceFS 后应用例如推理任务便能通过 JuiceFS 客户端访问这些导入的数据。因此应用可以立即开始执行无需等待原始数据桶中的数据拷贝到 JuiceFS 中。
第三步读取数据。在推理等场景中通常会配置分布式缓存以优化数据读取。由于在第一步中仅导入了元数据而未导入实际数据初次通过分布式缓存读取时将无法直接获取数据。
第四步回源原始桶并缓存数据。这一步需要通过分布式缓存系统回源到原始数据桶中从中检索并读取数据。读取完成后数据会自动缓存到 JuiceFS 的分布式缓存中这样在后续访问相同数据时就无需重新回到原始数据桶中进行数据读取从而提高数据访问效率。
经过这几个步骤推理任务便能够快速访问存量数据并获得高性能分布式缓存的加速效果。
挑战 4在异构环境中如何充分利用硬件资源以优化存储和计算性能
异构环境涉及到一个系统内部集成多种不同类型或配置的硬件设备只有充分利用异构的硬件资源才能为企业带来最大价值。在下面这个示例中我们有三台机器每台机器配备的 SSD 数量和容量如下表所示根据每台机器的总存储容量这三台机器的缓存容量比例为 1:2:3。
编号SSD 数量单块 SSD 容量TB总容量TB机器 1248机器 22816机器 33824
默认情况下JuiceFS 的分布式缓存假设所有机器的硬件配置是同构的因此所有缓存节点的权重相同。在这种配置下整个系统的性能将被最小容量机器的容量上限所限制在这个示例中是 8TB其它机器缓存盘无法被充分利用第三台机器中甚至有 ⅔ 可能未被利用。
为了避免这种情况我们引入了「缓存节点权重」的概念允许用户根据实际环境动态或静态地调整每个 GPU 节点的权重。例如第一台 GPU 服务器的缓存权重可以设置为默认值 100第二台为 200第三台为 300这些权重与 SSD 容量的比例1:2:3相对应。通过这种差异化权重设置可以更有效地利用各缓存机器的存储资源优化整体系统的性能。这种方法为处理不同硬件配置的机器提供了一个典型的解决方案。
除了上述这个场景外缓存节点权重还可以应用于其它场景。例如GPU 机器容易出现故障用户可能每周需要对一两台机器进行下线和更换硬件等常规运维操作。因机器直接停机将导致该机器上的缓存数据丢失或暂时无法访问这可能影响整个缓存集群的命中率。在这个场景中也可以使用「缓存节点权重」功能来尽可能减少机器故障或维护过程中对缓存集群利用率的影响。
未来展望
最后让我们探讨一下未来我们在推理场景以及其它潜在应用场景中将要进行哪些改进。
首先引入分布式缓存的多副本特性。目前分布式缓存系统中的数据通常是单副本形式意味着如果某台机器如 GPU 服务器意外宕机该机器上的缓存数据将因缺乏备份而丢失从而直接影响缓存命中率。由于这种情况是突发的我们无法通过人工干预来逐步迁移数据至其它节点。
在这种背景下单副本缓存将不可避免地影响整个缓存集群的效率。因此我们正在考虑将其从单副本升级为多副本。这种升级的好处显而易见尽管使用了更多的存储空间但是可以显著提高机器频繁故障场景的缓存命中率和缓存的可用性。
第二点我们正在探索用户态客户端的实现。当前基于 FUSE 挂载方式的文件系统虽然能有效地实现文件系统功能但由于其依赖 Linux 系统内核涉及用户态与内核态之间的多次切换和数据拷贝因此带来了一定的性能开销。尤其在云上的无服务器serverless和 Kubernetes 环境中FUSE 挂载可能无权限使用这限制了 JuiceFS 的应用场景。
因此我们正在考虑开发一个纯用户态的客户端这将是一个不依赖内核态的组件可以显著降低使用门槛并在不支持 FUSE 的环境中提供服务。此外由于避免了内核态与用户态的频繁切换和内存拷贝这种客户端在性能上也可能有显著提升特别是在需要高吞吐量的 GPU 密集型环境中。
然而这种客户端的一个潜在缺点是它可能不如 POSIX 接口透明因为它可能需要用户通过引入特定的库如 JuiceFS 库来实现功能这种方式可能会对应用程序产生一定的侵入性。
第三提升可观测性。鉴于 JuiceFS 架构中包含多个复杂环节如从 GPU 机器到缓存集群再通过专线回到中心的对象存储以及缓存预热等我们计划引入更便捷的工具和方法来增强整体架构的可观测性。这将有助于 JuiceFS 的用户更快更方便地定位及分析问题。未来我们将进一步优化包括分布式缓存在内的各个组件的可观测性帮助用户在出现问题时进行快速的问题排查和解决。
希望这篇内容能够对你有一些帮助如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。
