基于 JuiceFS 构建 AI 推理：多模态复杂 I/O、跨云与多租户支持

技术分享 3周前 (10-18) 0 999+

随着 AI 技术的快速发展，推理服务的需求在市场中不断增长，已成为各行各业广泛关注的关键应用。随着思维链、慢思考等技术的出现，模型的推理能力也在不断的增强。推理能力的实际应用覆盖了更多行业和场景，成为企业部署 AI 基础设施时不可忽视的关键因素。更多企业关注如何高效、可靠、经济地将 AI 落地并解决实际应用中的问题。将更多的计算资源投入推理计算已成为更具性价比的性能提升方式。

与此同时，推理服务对存储系统提出了更高的要求。不仅需要高性能、低延迟的数据访问能力，还必须支持弹性扩展、资源隔离以及多云部署等特性。如何选择合适的存储方案，已成为企业在构建 AI 基础设施过程中必须面对的重要课题。JuiceFS 已在多个推理服务场景中得到广泛应用，服务对象涵盖基础大模型平台、多模态应用和企业级 AI 服务等不同类型客户。在对这些实践案例深入分析的基础上，我们总结出一系列具有代表性的存储需求与挑战。

本文将分为两个部分展开探讨。第一部分聚焦推理服务中的存储访问特征，结合 JuiceFS 的应用实践，梳理推理场景下的关键需求与常见问题；第二部分将系统性比较几种主流存储方案的优势与限制，帮助用户在构建推理系统时做出更合理的选型决策。

01 推理服务的存储需求：多模态复杂 I/O、跨云与多租户支持

下图列举了 JuiceFS 当前已服务的部分客户，其中包括多个 AI 基础平台以及 AI 应用客户。这些平台的主要业务以推理服务为核心，同时涵盖部分微调训练等任务。

在与客户合作的过程中，我们观察到推理业务对存储提出了以下典型需求：

多模态 I/O 模式更复杂：推理正快速向多模态方向发展，涉及大量小文件管理、mmap 式随机读取等访问模式。这些场景对 I/O 吞吐与延迟极为敏感，直接影响模型响应速度与用户体验。
云原生部署需求：推理流量具有明显的波峰波谷特征，要求底层存储能够快速响应突发请求，并与云原生调度系统协同，实现分钟级扩缩容。
多云多区域架构趋势明显：为提升业务的可用性与容灾能力，越来越多客户选择在多云或多区域部署推理服务。存储系统需要具备良好的跨区域一致性与成本控制能力。
资源共享与隔离并重：推理任务更强调资源复用，特别是在多租户或多业务线共用集群时，如何在确保高资源利用率的同时实现有效隔离与数据安全，成为系统稳定运行的基础。

实践 1：模型加载性能挑战

我们可以从推理服务的各个阶段来分析文件访问的需求。推理服务的主要阶段包括：

如上所述，每个阶段的文件访问需求不同。其中， I/O 瓶颈主要集中在冷启动阶段的模型加载和运行时模型切换上，尤其是如何能够高效地读取模型文件。

方案1：将模型文件打包进容器镜像。在小规模推理场景中，许多用户会将模型文件、代码依赖和扩展包打包进容器镜像，并通过 Kubernetes 启动。这种方式曾经较为简单，但随着推理规模的扩大，暴露出了一些问题：

镜像文件过大：随着模型文件的增大，容器镜像也变得庞大，导致拉取镜像时容易超时。
解压慢：容器镜像采用分层存储，每一镜像层的解压过程是串行操作且由于模型过大，解压时速度较慢，效率低下。
资源浪费：如果多个推理服务需要使用相同的模型，难以实现共享模型，导致频繁的下载和解压操作，浪费了大量资源。
频繁切换模型：需要频繁切换模型的场景中，效率更低。

方案2：将模型文件存储在对象存储中。每次推理实例启动时，从对象存储拉取模型文件。这种方式虽然避免了镜像拉取超时的问题，但仍然面临以下挑战：

带宽竞争：在大规模集群中，多个推理实例同时拉取模型时，可能发生带宽竞争，导致启动时间延长，影响用户体验。
效率低下：许多模型文件格式（如 Safetensors 格式）使用 mmap 进行懒加载，但对象存储不支持 mmap，因此必须先下载文件到本地再进行读取，既浪费了存储空间，又降低了读取效率。

方案3：使用 JuiceFS 等高性能文件系统。相较于对象存储和容器镜像，将模型文件存储在高性能文件系统中是一个更有效的方案。JuiceFS 作为这一方案的实现，具有以下优势：

按需配置：与传统的高性能文件系统不同，JuiceFS 在性能和容量上可以根据需求进行灵活配置，避免了性能和容量强耦合的问题。
多云数据分发能力：传统的云文件系统通常不支持多云环境的数据分发，而 JuiceFS 则具备跨云分发的能力，能够在多个云环境中高效分发数据，提升了灵活性，下文将详细介绍 JuiceFS 如何在多云架构中使用。

下图展示了在引入 JuiceFS 后，模型文件加载流程的改进。在构建容器镜像时，我们将模型文件从镜像中分离出来，存储在 JuiceFS 中，而容器镜像仅包含业务代码和运行所需的基础环境。

这种做法带来了显著的好处。首先，模型文件与镜像的冷启动过程得以分离，避免了在本地解压庞大模型镜像层的操作。

其次，与对象存储方案相比，在使用 JuiceFS 时，冷启动阶段不需要将完整的模型文件下载到算力节点本地，也无需加载完整的模型文件（如 safetensors 模型文件），推理实例可以快速完成冷启动。这种按需加载模式，在弹性扩展场景下尤为关键，它能确保新实例快速启动并迅速投入服务。尽管首次推理会因按需加载模型而略有延迟，但后续请求的推理速度会得到显著提升。

除了这些优化，JuiceFS 还通过其强大的缓存能力进一步提升推理服务的性能。除了社区版提供的本地缓存功能，JuiceFS 企业版进一步提供了分布式缓存功能。这使得我们能够构建大规模的缓存空间，将常用的模型文件集中存储在缓存中，从而显著提升读取性能。

特别是在大规模实例启动或扩容的场景中，例如在 stable diffusion 等需要频繁切换模型的应用中，通过分布式缓存集群，可以大幅度减少模型加载时间，显著提高用户的前端体验。下图展示了 JuiceFS 分布式缓存架构。在推理服务部署后，我们将 JuiceFS 挂载到推理节点上，节点读取模型文件时，节点会先尝试从缓存集群中获取数据，由于缓存集群都是有由高速介质组成，且通讯都在内网高速网络，所以获取数据的性能是非常好的。缓存未命中时，相应的缓存节点踩会从对象存储拉取数据返回给节点，并填充缓存。我们还可以通过 warmup 的方式来预先填充缓存，将需要加载的模型文件在节点启动前填充到缓存层。当推理实例启动时，所有实例会直接从缓存集群命中模型文件，这样就无需每个推理实例单独从对象存储拉取文件，从而避免了高并发拉取文件时对对象存储带宽的竞争问题。

实践 2：多区域模型文件同步与一致性管理

越来越多的企业选择多云架构来部署推理服务，并在不同云厂商之间灵活调度资源以优化成本结构。如下图所示，在一个典型的推理服务部署案例中，客户构建了跨多个云服务商和数据中心的基础设施，用以支持高并发、低延迟的推理请求。多云架构不仅能有效规避单点故障带来的业务中断风险，还支持根据区域网络条件、资源价格、计算能力等因素，动态选择最合适的计算节点，从而在保障性能的同时，实现更优的成本控制。

为确保推理模型和配置文件在不同区域间的一致性，客户通常会在某一主站点使用对象存储作为统一的模型仓库，通过中心化管理模型版本与配置。在推理任务调度过程中，系统可根据资源情况选择合适的算力资源，而模型文件则需要尽可能部署在靠近计算资源或高吞吐网络环境中，以提升冷启动效率和服务响应速度。

在传统实践中，模型文件常需人工迁移至调度的计算集群，随着模型迭代频繁，易导致操作繁琐和数据不一致问题。同时，推理集群规模通常较大，在冷启动过程中，节点并发拉取模型会引发带宽竞争，形成性能瓶颈，尤其在多云架构下，模型分发和加载成为一项挑战。

JuiceFS 提供的解决方案是通过镜像文件系统来实现从主站点到各个镜像站点的元数据实时同步。每个站点本地的客户端都能看到统一的文件系统视图。对于数据文件是否需要做全量同步，或者按需缓存和加载，提供了两种方案。

第一种方案是通过异步复制方式，将对象存储的数据完整复制到多个站点。每个站点优先读取本地的对象存储。第二种方案是只在镜像站点部署分布式缓存层，而不进行数据持久化。所需的数据会按需预热到缓存中，从而提高本地读取性能。

在大规模的推理服务中，从成本效益角度考虑，用户通常选择第二种方案，将分布式缓存部署在站点本地。在节点启动和扩容前增加流水线任务，将需要使用的模型文件一次性预热到分配计算资源的本站点缓存集群中，这个阶段相当于只从对象存储高并发拉取了一次模型文件。这样做的好处在于，当大批推理服务同时冷启动时，只需要并发从本站点域缓存集群中读取模型文件，而不再需要走对象存储专线，多次从对象存储拉取，解决了高并发重复拉取占用带宽导致专线带宽瓶颈的问题。

此外，模型版本的迭代也可以通过预热脚本完成，将新的版本预热到缓存中，同时淘汰过期的版本。整个数据分发和缓存预热过程完全由 JuiceFS 镜像文件系统功能实现，对用户来说是透明的，避免了大量人工数据拷贝工作。

总结来说，JuiceFS 镜像文件系统带来的收益包括：

降本：每个镜像站点只需要部署适量的缓存集群，无需配置过大的容量。
增效：分布式缓存使用本地高速介质，提供良好的吞吐性能，且网络为本区域内网，性能更优。
易用性：不需要人工参与数据拷贝，统一的数据视图自动帮助用户完成数据分发，即使缓存未命中，数据也会自动从对象存储拉取。
可扩展性与稳定性：解决了多节点并发拉取模型文件时的带宽竞争问题，提升了系统性能和用户体验。

实践 3：云原生支持与集群管理

推理服务通常具有突发性和间歇性的负载特点，因此对资源弹性有很高的需求。随着推理服务规模的扩大，计算集群的数量和节点规模也在不断增加，往往需要跨集群、跨区域的调度，这要求存储系统能够轻松支持多集群环境的部署。

此外，在弹性环境中，文件系统需要保证在资源扩展、升级或故障恢复时对业务透明，不影响应用的正常运行。这意味着文件系统必须具备自动故障恢复、资源隔离和无缝升级等能力，以确保业务的持续稳定

JuiceFS 提供了一系列能力来支持云原生环境中的推理服务。

首先，JuiceFS 提供了标准的 Kubernetes CSI 驱动。用户可以在 Kubernetes 环境中方便地使用 PVC 来访问 JuiceFS 文件系统，并支持静态和动态配置方式。

其优势之一是多环境兼容性：为了匹配推理服务对资源弹性的需求，JuiceFS 提供了多种运行模式，适用于标准和 Serverless 的 Kubernetes 环境，无论推理服务采用哪种弹性负载，JuiceFS 的部署都非常简便。

资源优化方面，JuiceFS 支持同一个 PVC 的应用共享挂载卷，并允许对资源进行细粒度定义。这实现了资源的优化利用和租户之间的隔离，确保不同租户在使用不同 PV 时互不干扰。

在稳定性优化方面，JuiceFS 支持挂载点的自动恢复和挂载 Pod 的平滑升级。当挂载 Pod 发生故障需要重启，或需要升级 CSI 驱动或挂载 Pod 镜像时，应用 Pod 无需重新启动，能够保持正常运行。

自动化管理方面，JuiceFS 提供了多种 Operator，包括缓存组管理、预热和数据同步功能。用户可以方便地通过 CRD 来管理这些资源，实现自动化操作。

可视化监控方面，JuiceFS 提供了一个完整的可视化管理平台，支持对挂载 Pod 和应用 Pod 进行监控。用户还可以在平台上进行平滑升级等操作，所有操作都能通过通用界面进行管理。

此外，许多用户通过 Karmada 的多集群管理框架与 JuiceFS 的 CSI 驱动集成，实现了多集群环境下资源调度与存储配置的统一管理。得益于 JuiceFS 架构的简洁性，需要独立部署的后台服务只有元数据服务，其他功能全部在客户端内实现，只需要在算力节点部署客户端即可。在复杂的多 K8s 集群场景中，用户可以通过类似 Karmada 的多集群管理控制面，将 JuiceFS 的相关 CRD 按策略下发到不同集群，即可实现存储卷的简洁部署和高效运维。

实践 4：多租户与数据隔离

在 AI 推理服务场景中，多租户的数据隔离需求非常迫切。一方面，对于面向外部用户的 AI 基础平台和 AI 应用，用户对数据安全和隔离要求较高；另一方面，对于大型企业内部的不同部门、项目组之间也需要实现数据隔离和访问控制。总体来看，多租户环境的需求主要包括三点：

数据隔离与访问控制：不同租户之间需要隔离数据，并实现针对用户的访问权限管理。
存储配额管理：需要对不同租户分配和管理存储容量。
资源隔离与性能管理：不同租户可能需要独立的资源隔离，并对性能（QoS）进行管理和优化。

针对这些需求，JuiceFS 提供了三种不同力度的数据隔离方案：

方案一：独立文件系统隔离。针对不同租户分配不同的文件系统进行数据强隔离，即不同的租户分别使用自己的 JuiceFS 文件系统。如果要求进一步的资源和性能隔离，可以将文件系统的元数据服务以及文件系统后端关联的对象存储桶进行完全隔离。这个方案一般是针对 AI 基础平台 toB 的租户环境适用，这类租户的业务需求通常是规模很大、对服务质量要求很高，本方案可以充分保证租户的数据访问性能，不受任何共享资源租户的负载影响。且数据被完全的物理隔离，得到最高的安全保障。

方案二：同一文件系统的子目录隔离。为不同租户分配同一文件系统上的不同子目录，子目录之间互不可见，另外可以通过 JuiceFS 的 token 进行子目录挂载权限的控制，严格控制子目录的数据隔离。这种方案比较多用在如 AI 基础平台 toC 的租户环境，或者企业内部不同项目组之间租户的数据隔离需求。另外在 k8s 环境中，JuiceFS CSI 默认会为动态声明的 PVC 在文件系统上分配不同的子目录，且默认不同的 PVC 不会复用 JuiceFS 客户端，这样既实现了不同业务的数据隔离，也能针对不同业务的客户端进行单独的资源控制和参数优化。当然在非 K8s 环境中，也可以通过 Token 控制客户端对子目录挂载权限，来保证数据安全。这个方案在对象存储上的块数据并没有进行隔离，但是 JuiceFS 的这种块文件在对象存储上是没法直接读取原始文件内容的，所以也并不存在数据内容泄露的问题。

方案三：基于 POSIX ACL 的精细访问控制。在 Linux ACL 基础上，JuiceFS 企业版扩展了组权限控制能力，每个文件可为不同组单独设置权限。结合 UID/GID 映射功能，即使在不同节点上，只要用户名和组名一致，就能实现一致的 ACL 权限管理。此方案适合对单个目录或文件有精细访问控制需求的小规模用户，配置难度较高，使用场景相对有限。

此外，JuiceFS 企业版提供两个关键功能支持多租户管理：

客户端访问令牌（Token）：用于授权客户端访问文件系统，可控制访问 IP 范围、读写权限、子目录挂载权限，以及客户端执行后台任务的权限。同时可限制对象存储的访问流量，实现限额或限流（QS）管理。

配额管理：可对每个子目录分配存储容量和文件数量，结合子目录数据隔离方案，为每个租户精确控制存储资源使用。

02 推理服务中不同存储方案比较

在推理服务的实际应用中，不同类型的存储方案在性能、稳定性、扩展能力以及成本等方面存在明显差异。下文将对几类典型方案进行分析与比较，以帮助企业更全面地评估其适用性。

首先，对象存储是一种低成本的解决方案，适合顺序读大文件的场景，但在处理推理任务中频繁使用的小文件、模型文件（如 Safetensors 格式）以及多模态数据时，性能较差。在多推理节点并行读取数据时，对象存储的带宽容易被耗尽，导致性能瓶颈。虽然它支持最终一致性和几乎无限制的存储容量，但它缺乏对高并发和小文件访问的优化，且不支持异构多云环境的自动数据分发。

高性能文件系统则提供了更高的性能，尤其适用于对计算资源和性能要求较高的场景。它能够完全支持 POSIX 兼容的框架，提供强一致性，但在性能和容量方面强耦合，需要较大的存储容量才能发挥最佳性能。虽然它的稳定性较好，但由于客户端部署在内核态，单个客户端故障可能导致整个系统崩溃。运维成本较高。

纯缓存系统 + 对象存储是一种折衷方案，通过配置分布式缓存提供高吞吐和低延迟的读写性能，但对于海量小文件和高频元数据请求场景的性能有待验证。另外这种方案在多云/多区域架构下难以保证数据的强一致性。

相比之下，JuiceFS + 对象存储提供了多级缓存架构，灵活配置本地和分布式缓存，能够提供高吞吐和低延迟的数据读写性能，特别适合推理服务中的高并发、低延迟需求。它不仅支持高效的元数据操作，还能充分利用以太网络带宽，无需依赖昂贵的专有硬件，确保在同类系统中具有出色的性能。JuiceFS 还具备强一致性，并支持在多云环境中自动化的数据分发，能够保证多地域跨集群的一致性。

从扩展能力来看，JuiceFS 支持高达 1000 亿个文件和 TB/s 的吞吐量，按需配置缓存，可大规模扩展。而对象存储适用于文件数量和容量几乎无限制的场景，但其带宽受限于云厂商的提供。高性能文件系统的扩展能力则受到性能与容量强耦合的限制。