拥抱 AI，我们需要什么样的存储系统？

文件存储作为已有 30 多年历史的传统技术， 在 AI 时代因其高并发、高吞吐量和低延迟的特点，成为处理大规模数据集和复杂训练任务的核心解决方案。相比对象存储，文件系统在性能和元数据处理上更具优势，并且 POSIX 协议的支持降低了 AI 开发者的学习门槛。

JuiceFS 是一款自 2017 年开始研发的文件存储系统，目前我们的社区版已经获得了 GitHub 11K 星标，是同领域内增长最快的项目。2019 年起，我们与多家 AI 企业深入合作，包括大模型公司如 MiniMax、智谱、阶跃星辰，以及小红书、知乎等知名互联网公司；此外，还涉及自动驾驶、生物信息科技以及量化金融行业的领先企业。本文将基于我们在 AI 领域的实际经验，分享 AI 企业在存储选型时常见的挑战，以及我们的行业观察。

01 用户视角下，存储系统选型为什么这么难？

在确定存储系统需求时，量化和数字化至关重要。大家时常使用的如“大规模”、“大文件”和“高性能”带有主观色彩，不同人理解差异较大。例如，50GB 和 50TB 级别的数据量对不同人意义不同，类似地，“大文件”可以是 1MB，也可以是 1GB。性能要求也应具体量化，如吞吐量和 IOPS。为了准确选型，需明确数字指标。例如，500TB 容量、5 亿文件，其中大部分为 GB 级文件，也有少量百 KB 级文件；吞吐量要求为 20GB/s，峰值吞吐量可能更高，IOPS 也需明确预期。

量化数字的同时，还需要考虑业务增长性与存储的扩展性。在 AI 领域，因为技术和数据变化极快，准确预测需求非常困难。例如，计算机视觉领域的数据集每年可能成倍增长，语言模型在过去三年中参数量和数据集规模已增长 1000 倍。因此，精确的容量规划几乎不现实。面对这种快速变化，选择具备良好扩展性和灵活性的存储系统变得至关重要，以应对未来不断变化的业务需求。

此外，AI 业务数据流的复杂性也是容量规划时需要考虑的重要因素。如今的 AI 应用不再是单一环节的工作，而是涉及到多个数据流和复杂的流程。这些数据流变得越来越长，从数据采集到处理、训练，再到推理和应用，每一个环节都可能产生大量的中间数据。因此，存储系统不仅要支持大规模的数据存储，还要具备方便数据流动的能力，能够应对多变的 AI 业务需求。

在 AI 的推理阶段，数据量通常较小，主要使用预训练好的模型数据，并以大文件为主。在一些情况下，模型数量会非常庞大，例如使用像 Stable Diffusion 这类的社区模型时，模型数量可能达到 10 万到数十万。

随着数据结构日趋复杂，存储需求也在变化，过去以处理结构化数据为主的大数据技术，如列存储和行存储，已逐步被半结构化数据（如 JSON、CSV 文件）所取代，尤其是像语言模型中大量使用的 JSON 格式和生成过程中的日志数据，这些数据的规模同样庞大。

因此，存储系统的选型难度在于，不仅需要满足大规模数据存储的需求，还必须具备处理复杂数据流和多变数据结构的能力，以应对 AI 应用中快速变化的数据需求和不断演化的业务环境。

AI Pipeline on JuiceFS

02 存储系统选型中的几个难题

难题 1：集中式架构 vs 分布式架构

在过去，集中式架构采用少量的节点和高性能硬件，通过精简架构来最大化硬件性能。然而，随着 AI 应用场景的不断扩展，越来越多的工作负载开始依赖于分布式系统，而且分布式系统的规模也在不断扩大。例如，ETL 可能需要几千到几万核的 CPU，而训练任务则可能使用数百甚至数千个 GPU。这种变化导致集中式架构在面对 AI 需求时遇到了几个核心挑战：

1. 单点故障问题：集中式架构中的单节点成为系统的瓶颈，若该节点出现故障，整个系统的性能和稳定性将受到严重影响。

2. 扩展性不足：集中式架构在扩展上存在显著限制，难以应对不断增加的数据量和计算需求。

这两大挑战使得集中式架构在应对分布式计算和大规模 AI 任务时显得捉襟见肘。因此，越来越多的企业开始转向分布式存储架构。以下是几款较为流行的分布式存储产品：

• GlusterFS：作为一个开源分布式文件系统，它适用于小规模集群，但在大规模集群中表现较差，主要因为缺乏独立的元数据引擎，导致随着节点数量增加，性能显著下降。我个人不推荐在大型分布式集群中使用 GlusterFS。

• MinIO：MinIO 是一个面向对象存储的解决方案，主要提供 S3 API，但它并不是真正的文件系统。在数据管道中的多个环节，特别是在需要 POSIX 兼容的场景下，MinIO 和 S3FS 无法完全满足需求。

• Ceph：Ceph 是一个分布式存储系统，提供块存储 RBD、对象存储 RGW 和文件存储 CephFS。在使用 CephFS 时，我强烈推荐使用单一元数据服务器（Single MDS），而不使用 Multi-MDS 方式，后者会导致运维复杂性增加。CephFS 在某些场景下表现优秀，但对大规模集群的运维要求较高。

• Lustre：Lustre 在超算领域使用多年，它需要与一个分布式块存储系统配合使用。虽然其性能强大，但直接与裸盘配合使用时，可能会存在数据可靠性风险。

• JuiceFS：JuiceFS 最初为云环境设计，非常适合在公有云和私有云环境下使用。它支持分布式存储，并提供 POSIX 兼容的文件系统接口，非常适合大规模数据处理和 AI 任务。

难题 2：用户态 vs 内核态

关于用户态客户端与内核态客户端的选择，一直是存储系统设计中的一个重要讨论点。以下是两种客户端架构的主要特点和考量因素。

内核态客户端通常能够提供较低的 IO 路径延迟，性能上可能优于用户态客户端，尤其在需要高性能数据读写的场景中。例如，在处理大量小文件的操作时，内核态客户端的性能通常较为突出。内核态客户端的优点包括：

• 更低的延迟：由于直接运行在操作系统内核中，IO 路径较短，性能潜力更高。

• 资源效率：相比用户态客户端，内核态客户端的 CPU 和内存消耗可能更少。

然而，内核态客户端也有一些挑战，特别是在开发和运维方面：

• 更高的开发和运维复杂度：内核态客户端需要与操作系统内核绑定，且遇到问题时，可能会影响宿主机的稳定性，特别是在虚拟化环境中。

• 内核依赖：每次更新或维护时，可能需要重新编译内核模块，这增加了系统的运维复杂度。

用户态客户端不依赖内核，通常通过用户空间的 FUSE（Filesystem in Userspace）来实现存储访问，具有更高的灵活性和可管理性。JuiceFS 采用的是就是基于 FUSE 的用户态客户端，优点包括：

• 运维简单：无需与操作系统内核绑定，避免了重新编译内核模块的麻烦，系统升级和维护较为简单。

• 更好的隔离性：用户态客户端与宿主机的内核隔离较好，一个客户端的故障不会影响到宿主机或其他客户端。

对于许多现代应用场景来说，尤其是在云环境和虚拟化环境下，用户态客户端在扩展性和运维简便性方面的优势尤为明显。随着计算密集型工作负载的增加，现代 AI 任务的瓶颈更多出现在计算力（如 GPU 间的卡间通信）而非 IO 性能，因此用户态客户端的 IO 性能差异通常不会成为系统的主要瓶颈。

在单机文件系统时代，使用 FUSE 的用户态文件系统性能相较于内核态文件系统较慢。然而，在分布式文件系统的时代，网络延迟和元数据处理效率对性能的影响更大，因此在一些大规模 AI 场景中，用户态文件系统依然能表现出良好的性能。FUSE 客户端的性能经过正确配置和优化后，可以提供较高的吞吐量，能够满足许多应用场景的需求。以下是我们使用 FUSE 对数据吞吐进行的测试。

难题 3： InfiniBand 在存储区域里是必须的吗？

对于是否要使用 InfiniBand（IB）卡，很多客户都有疑问。首先 JuiceFS 当前还不支持 IB 网络。根据我们的观察，InfiniBand 网络目前主要用于 GPU 之间的高速通信，但用于计算节点与存储节点之间的网络连接仍然较少。

原因有以下几点：

1. 组网复杂性：IB 网络的组网相对较为复杂，特别是在大规模网络或三层网络架构中。它要求对整个网络拓扑进行精心设计，涉及的硬件和配置比传统以太网要复杂得多。

2. 成本问题：从网卡到交换机，IB 设备的成本显著高于普通以太网设备，且供应商集中，导致 价格昂贵，且 供应周期长，供应链管理较为困难。

3. 扩展性和灵活性：尽管 IB 在某些存储系统内部的节点间通信中得到应用，但我们更倾向于使用 通用硬件 来搭建存储系统，这样可以更灵活地扩展和管理集群，并且更具成本效益。使用标准硬件还可以更容易地进行硬件异构化，便于将来扩容或升级。

总的来说，IB 网络对于大规模分布式计算和存储系统的计算节点之间的高速通信虽然有优势，但由于其成本、复杂性和扩展性的限制，在计算和存储节点之间的网络连接中并不常见。对于大部分企业来说，使用基于 TCP 的标准网络技术往往更具灵活性和经济性。

难题 4：RDMA 是必需的吗？

对于是否必须使用 RDMA，它的必要性取决于具体的应用场景和需求。RDMA 能够通过降低时延来优化某些操作，但在顺序读写场景下，它对吞吐量的提升并不显著。因此，是否启用 RDMA 需要结合你的工作负载和性能瓶颈来综合考虑。

1. 优化时延：RDMA 的主要优势在于减少时延，特别是在高频率的小数据包交换中，对于需要低延迟的应用场景（如 GPU 集群通信）非常有帮助。

2. 对吞吐量的帮助有限：但如果应用的瓶颈主要集中在顺序读写或大规模数据传输 上，RDMA 对吞吐量的影响相对较小。

3. 运维复杂性：RDMA 的使用需要内核模块的支持，这会增加运维的复杂度。启用 RDMA 后，必须维护和管理相关的内核组件，而且 开发上也需要特定的接口 来支持 RDMA，这对开发团队也是一个额外负担。

4. 硬件要求：RDMA 通常需要专用的硬件支持，比如 InfiniBand (IB) 或 RDMA over Converged Ethernet (RoCE) 网络设备，这些硬件设备相对较贵，且配置和维护要求较高。

虽然 RDMA 在 GPU 集群和高带宽计算环境下有显著的性能优势，但并不代表它适用于所有场景。根据我们目前服务的场景来看：

高带宽 TCP 网络在例如在一些 Transformer 或 Stable Diffusion 等预训练模型的训练过程中，是完全能够满足性能要求，并且成本更低。此外，训练过程中的数据清洗和预处理阶段，通常会消耗大量的 CPU 资源，并且这个阶段更多依赖的是 TCP/IP 网络，因此在这一环节中，RDMA 并非必需，普通的高带宽 TCP 网络足以应对。

下图是我们一个客户真实生产环境中所做的测试，使用的是 TCP 网络，也可以达到非常高的性能，足以支撑大部分 AI 训练工作负载。

• 吞吐量：在实际测试中，峰值吞吐量达到了 100+ GB，平均吞吐量保持在 10GB - 20GB 之间。

• IO 性能：在高并发的情况下，QPS（每秒请求数）峰值可达到 85k - 850k，平均为 650k。

难题 5：如何摆脱性能和容量绑定？

以传统存储系统（如 Ceph 和 Lustre）为例，性能和容量是线性绑定的。为了提升性能，必须增加更多硬盘和节点并进行数据重平衡，这不仅增加了运维复杂性，还可能影响系统整体性能。扩容通常需要在特定时间窗口进行，以避免性能波动。此外，许多云上文件存储产品（如 AWS FSx for Lustre）采用类似的容量与性能绑定定价模型。

然而，许多业务场景中，容量与性能并非线性增长。例如，可能有小数据量但对性能要求高的场景，或大数据量但对性能要求低的场景。

与此不同，JuiceFS 的创新在于解耦了性能与容量。它将对象存储作为后端持久化存储，提供大规模、低成本且可靠的存储方案。性能部分通过缓存加速，当吞吐需求增加时，可以仅通过扩大分布式缓存集群规模来提升吞吐性能，而容量则由对象存储提供支持。这种设计大大提高了存储的扩展性和灵活性，避免了传统存储系统中性能与容量线性绑定的限制。

通过这种解耦方式，JuiceFS 在成本上远低于传统存储系统，提供相似的性能表现，存储和性能组合的成本仅为传统方式的 1/10 左右。

03 如何测试存储系统？

功能测试

存储系统的测试不仅仅是性能评估，还需要涵盖多个关键功能，首先是兼容性测试，尤其是 POSIX 兼容性。在 AI 和分布式架构中，POSIX 文件系统的兼容性至关重要。虽然云计算和 S3 存储普及后，POSIX 的需求有所下降，但随着 AI 应用的兴起，POSIX 兼容的共享存储变得更加重要。我们使用 pjdfstest 和 LTP 这两套测试集，在不同环境中持续验证 POSIX 兼容性，测试结果表明，尽管部分产品出现兼容性问题，但并不意味着不可用，关键是结合具体应用需求做评估。

主流分布式文件系统 POSIX 兼容性比较

基准测试的局限性

性能测试远比单纯对比数据高低复杂。比如，同样是 JuiceFS，在不同环境下的测试结果可能会有几倍的差距。测试时，硬件配置、网络状况、系统参数和并发配置等因素都可能对结果产生重要影响。因此，确保测试环境的一致性至关重要。基准测试可以帮助了解系统的最大性能，但它只能作为参考，无法代表在实际业务中的表现。特别是对于复杂业务负载，上层应用的代码和函数调用会直接影响存储访问的性能。基准测试结果并不能完全预测业务场景下的实际表现。

性能瓶颈往往出现在存储系统与应用之间的匹配不当。例如，在一次客户 PoC 测试中，LMDB 单机数据库在迁移到网络存储后，由于每个小请求变成多个 TCP 请求，导致延迟增加，性能下降。这反映了存储系统与应用不匹配导致的瓶颈。

此外，同步 I/O 与异步 I/O 的差异也显著影响性能。在高并发场景下，异步 I/O 能够提升吞吐量，而同步 I/O 在增加并发请求时效果有限。尤其在 AI 领域，随机 I/O 操作如加载模型时可能遇到性能瓶颈，网络延迟和存储系统的局限性可能让加载速度显著变慢。

可观测性

为准确诊断性能问题，存储系统需要具备深度可观测性，能够分析每个 I/O 请求的行为。除了监测存储系统的吞吐量、延迟等整体指标，关键在于深入理解应用层的 I/O 请求类型，从而判断瓶颈是出现在存储层还是应用层。这种精细化的分析能帮助我们更好地优化存储系统与应用的协同工作，提升整体性能。

04 案例： 支持多云架构 LLM 预训练的 JuiceFS 集群

最后分享一个我们自己在语言模型预训练中的生产集群的案例：

• 该集群中包含了大约 2 亿个文件。

• 总数据量达到 12PB。

• 文件大小较大，大部分文件是 GB 级。

• 读取和写入的吞吐量也非常高。

• 集群的并发客户端数超过 1000 个，客户端通常对应于 Kubernetes 节点，且大多数是物理服务器。这意味着，存储系统需要同时为 1000 多台机器提供数据访问。

• 集群的读吞吐量峰值达到了接近 200GB/s，读操作主要用于训练过程中读取数据集。

• 写吞吐量的峰值约为 20GB/s，而写操作则主要是周期性地保存模型的 Checkpoint。

在这个生产集群中，需要确保不同地点的任务能够高效访问存储数据。由于算力资源分布在多个供应商和地理位置，客户依赖调度平台来分配计算任务。当任务被调度到某个节点时，存储系统必须确保数据能够快速提供。

有两种方式来实现数据访问：一种是通过网络远程访问数据，例如数据存储在北京，但任务调度到上海，任务通过网络访问北京的数据；另一种是将数据从北京复制到上海，使任务可以直接访问本地存储的数据。

JuiceFS 提供的跨云跨地域多种解决方案，可以减少带宽成本。尽管复制会增加存储空间的冗余，但复制的存储成本远低于远程访问的带宽费用。例如，存储数据 6 个月的费用相当于一次远程数据读取的费用。通过增量同步，避免了昂贵的专线和带宽使用，从而降低整体成本。

在这个典型的 AI 案例中，我们可以看到，在搭建存储系统时，尤其是在进行语言模型预训练时，客户通常无法预见业务的具体发展。初期阶段可能只有一个模糊的业务框架，因此需要选择一种更加通用且具有扩展性的存储方案。以下是设计这个存储系统时，我们所关注的几个关键要素：

1. 完整的 POSIX 兼容性：存储系统需要支持 POSIX 标准和其他常见接口（如 HDFS），以保证应用能够在多种存储环境中顺利运行。

2. 弹性扩展能力：随着数据量和计算需求的增长，存储系统必须具备弹性扩展的能力。无论是容量扩展，还是性能提升，存储系统都应该能够快速适应不断变化的需求。

3. 成熟的 CSI 驱动支持：在 Kubernetes 环境中，绝大多数 AI 应用依赖于 CSI 驱动来管理存储。因此，选择的存储系统需要提供成熟且功能完备的 CSI 驱动，以便与 Kubernetes 集群无缝集成。比如，CSI 需要支持一些重要功能，如子目录挂载、子目录访问控制等，确保在复杂的生产环境中，存储的管理和操作更加灵活。

4. 多云和跨区域支持：随着企业逐步采用多云架构，存储系统需要支持跨多个云平台的部署和数据访问。例如，Kubernetes 的资源调度能力应支持跨区域和多云部署，使得存储系统能够在多个地理位置和云平台之间无缝工作。存储数据可能需要在不同云环境中复制或同步，以确保计算任务能快速就近访问数据，进而提高整体计算效率。

05 总结

当前，无论是在大语言模型还是整个深度学习领域，技术发展仍处于相对早期阶段，且呈现出极大的发散性。因此，在做技术选型时，我们不应期待某一方案能够满足未来三到五年的需求。相反，选型应具备足够的灵活性和适应性，以便根据业务需求的变化进行调整。

虽然性能是选择存储和计算方案时的重要考量，但首先应优先考虑通用性、弹性和性价比。过于追求极致性能的方案可能在初期表现出色，但随着业务规模的扩大，是否能够承受扩展带来的成本和复杂性，需要提前评估。在此背景下，云服务尤为重要，因为云的灵活性和可扩展性使其在时间和资源上的优势更加明显。与传统机房部署相比，云环境能够迅速响应需求变化，更高效地支持业务的快速发展。

JuiceFS 是专为云环境设计的分布式文件系统，利用对象存储作为后端，提供大规模、低成本且可靠的存储解决方案。通过缓存加速性能，按需扩展缓存提升性能，并将容量由对象存储管理，这种解耦设计提升了存储的扩展性和灵活性，避免了传统存储系统中性能与容量线性绑定的限制。对于 AI 企业而言，JuiceFS 是应对快速增长和大规模数据处理的经济之选。