摘要：在深度学习领域中，数据是基石，算力是引擎。训练一个模型，需要大量的数据和算力 ，并且需要反复迭代和验证才能得到想要的模型。 为了提升训练效率，缩短训练时间，所有组件之间都需要快速响应，这其中就包括了计算和存储之间的交互。对于⼀个 AI 系统而言，模型的能力随着
演讲嘉宾｜张文涛
编辑 ｜ Kitty
策划 ｜QCon 全球软件开发大会
在深度学习领域中，数据是基石，算力是引擎。训练一个模型，需要大量的数据和算力 ，并且需要反复迭代和验证才能得到想要的模型。 为了提升训练效率，缩短训练时间，所有组件之间都需要快速响应，这其中就包括了计算和存储之间的交互。对于⼀个 AI 系统而言，模型的能力随着模型尺寸和训练数据的增加而显著提升，但随着数据集和模型规模不断增加，训练任务载⼊训练数据所消耗的时间越来越长，进而影响了训练效率，缓慢的 IO 严重拖累 GPU 的强大算力。
在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，焱融科技 CTO 张文涛分享了“高性能全闪并行文件系统的设计和实践”，他介绍了焱融的全闪文件存储的整体架构和技术细节，并分享了 YRCloudFile 是如何解决 AI 训练过程中遇到的海量小文件访问慢、 带宽峰值、 内存访问瓶颈和多任务并发访问性能干扰等问题的。
内容亮点
YRCloudFile 高性能文件系统的核心技术
在 AI 训练场景中遇到的疑难问题和解决方案
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
大模型时代的存储挑战
今天我给大家带来的分享主题是高性能全闪存储。刚才几位老师在讲解对象存储时，大多是站在降低成本的视角来设计系统，然后再考虑性能优化。而我们则是反其道而行之，先从性能角度出发，再设法降低成本。这两种视角存在明显差异，下面我将分享我们在这一领域所开展的工作以及设计理念。
大模型时代的存储面临着诸多挑战。从下图可以看出，黑色图是去年 Meta 公布的数据，其中绿色线代表过去两年其容量的增长情况，橙色线则表示性能的增长情况。在过去两年里，尽管 Meta 的数据量基数已经很大，但其容量仍翻了一番。而橙色线所显示的吞吐情况，相比之前已接近原来的四倍。白色图展示的是我们一个大客户的存储情况，仅代表他在我们 YRCloudFile 中的存储数据量。我们统计了他这四年里的数据增长情况，发现在 2020 年到 2022 年之间，每年数据量增长接近 20T。但从 2022 年年底开始，到 2024 年年底，其数据量增长愈发迅猛，基本以每年 60T 的速度增长。这一增长情况与大模型时代到来的时间点相契合，即 2022 年下半年，尤其是年底 ChatGPT 爆发时，国内的大模型厂商纷纷跟进，数据量也随之飞速增长，这便是数据增长方面所面临的挑战。
在 AI 的全流程中，与存储相关的环节主要有四个。首先是数据采集环节，主要是将各种原始数据收集过来，方式多种多样，比如编写脚本爬取数据、从公共数据网站下载数据、购买数据，或者收集本行业及企业内部的数据等。在这个过程中，需要运用各种协议来同时访问数据。第二个环节是数据处理，主要是针对数据进行清洗、格式转换以及集成，为后续的数据训练做好前期准备。这个流程较长，涉及多个类型的存储挑战，包括多种协议访问、数据快速检索以及 I/O 大小和读写方式的混合等。虽然该环节对存储的挑战是全方位的，但由于它不影响 GPU 的利用率，所以往往容易被大家忽视。第三个环节是数据训练，这在 AI 存储中是大家较为关注的场景。AI 训练场景对存储的挑战主要体现在高并发场景的性能上，它的 IO 类型其实很简单，主要有几种情况：第一种是启动训练时模型的加载，属于大量并发的顺序读；第二种是读取数据集，又分为两类，若数据集较小，会将数据集预热到内存中，同样是顺序大 I/O 读，若数据集过大，内存无法缓存，则更多采用直接访问存储的方式，此时为大量随机小 I/O 读；此外，还有 Checkpoint 本身，属于大并发的顺序大 I/O 写。对于多模态情况，会增加一些特殊的小文件，如图文对、视频文本对、语音文本对等，从而产生海量小文件问题；第四个环节是推理，其对存储的需求也很简单，类型较少，主要有两种。第一种是模型分发，第二种是最近很火的 KVCache，二者都属于吞吐型，而 KVCache 还增加了延迟敏感，因为其以存代算，访问延迟不能过高；最后是数据归档，需要进行数据的全生命周期管理，以降低整个存储成本。
我们将 AI 存储面临的主要挑战归纳为四种：第一种是高性能，各种场景都对存储性能有较高要求，包括高 IOPS、高读带宽、高写带宽等；第二种是海量小文件问题，这同样是性能问题，不过由数据 I/O 性能转变为元数据性能。由于文件系统中元数据操作相对复杂，所以这一挑战较为棘手；第三种是横向扩展，大模型时代存储容量增长迅速，同时对性能的诉求也日益强烈，这就要求存储能够支撑大集群，实现容量和性能的线性扩展，以跟上计算能力的增长；第四种则是容量与成本问题，即在实现高性能的前提下，如何降低成本。如果成本降不下来，使用成本就会过高，这无疑会限制存储技术的应用和发展。
YRCloudFile 的设计方案
YRCloudFile 在设计方案上进行了精心的取舍。文件系统本身在结构上大同小异，通常包含几个关键模块。首先，有一个提供 POSIX 私有客户端的模块，这是实现文件语义的入口。接着是 MGR（集群管理服务）和 MDS（元数据服务），MDS 负责存储元数据信息。最后是数据管理服务，用于管理数据。这些组件共同构成了文件系统的基本架构。
针对性能问题，我们深知 I/O 路径越简单，效率越高。因此，我们采用了一种非常简单的数据路由算法。在文件创建时，系统会划分一组 OSD（数据存储服务），确定文件将被打散并存储在哪些磁盘上。这一过程是静态的，在文件创建时就已固化。这种设计带来了两个显著优势。首先，在访问文件数据时，无需频繁访问元数据服务或数据服务，我们可以通过计算快速确定文件位于哪个磁盘的哪个位置。其次，由于文件被打散到多个磁盘上，能够充分利用这些磁盘的能力。在 AI 场景中，常常涉及大量计算节点同时访问某个大文件，因此大文件能够提供的带宽至关重要，这也是并行文件系统和分布式文件系统存在一些细微区别的原因之一。
除了简化 I/O 路径外，我们还做了其他工作，以将性能提升到更高水平。我们挑选了几个具有借鉴意义的优化措施。首先是 Multi-Channel 技术。对于全闪存储而言，单盘带宽本身很高，但如何充分发挥一个拥有十几盘位或 24 盘位的全闪存储设备的全部带宽能力呢？网卡就成为了一个很大的瓶颈。我们需要进行网卡聚合，但 InfiniBand 网络和 RoCE 网络与以太网有所不同。以太网可以进行 bond 操作，但 InfiniBand 无法进行 bond，需要存储系统做额外工作才能实现多网卡带宽聚合，我们将其称为 Multi-Channel。通过这种方式，可以将单个节点的吞吐量翻倍甚至翻四倍，极大地提升单节点的吞吐能力。其次是 NUMA 亲和性，在高性能场景中，这一点至关重要。其核心问题是避免跨 NUMA 的内存访问。以 AMD 平台为例，如果发生跨 NUMA 访问，带宽将无法超过 15GB。只有避免跨 NUMA 访问，才能充分发挥整个节点的带宽能力。第三是 RDMA 的单边编程模式。在 RDMA 中，有两种编程模式，一种是 send-receive 方式，另一种是 read-write 单边方式。单边方式的核心优势在于减少内存拷贝。采用这种方式可以减少一次内存拷贝，从而带来更稳定的读写延迟和更低的 CPU 负载。
去年，我们发布了 F9000X 全闪一体机产品。该产品配备了第五代 Intel CPU 系列，4 张 400Gb 的 InfiniBand 网卡，以及 16 块全闪盘。需要注意的是，由于 CPU 插槽数量的限制，我们只能插入 16 块磁盘。这种配置下，一个三节点集群能够达到 480GB/s 的带宽和 750 万的 IOPS，相比上一代 F8000X 产品，每 GBps 带宽成本下降 60%。
在海量小文件问题上，各种解决方案都有其对应的场景和不适用的场景。存储领域没有一种架构能够解决所有问题，只有场景适用与不适用之分。在文件系统中，常见的解决方案包括静态子树目录哈希或动态子树等架构。我们采用的是基于 Dentry Hash 的方式，它遵循三个原则。第一，在集群格式化时，根目录会被固定下来。第二，在创建子目录时，会重新进行哈希选择 MDS，这样随着集群中目录数量的增加，能够保证目录和文件均匀地分布在各个 MDS 中。第三，文件和根目录位于同一节点，这保证了一定的本地性。在文件系统中，许多元数据操作，如 find 或者 ls 查询等操作，都涉及到 readdir。如果缺乏本地性，很多优化工作将难以开展。有了本地性后，我们可以进行一些预取等优化操作。
除了架构层面，文件系统还有很多细节需要注意，其中包括缓存等。在访问小文件时，主要涉及的元数据操作包括 lookup、getattr 获取元数据、getxattr 获取扩展属性、open 打开文件、读取和 close 关闭文件。对于小文件而言，真正读取数据的 RPC 只有一次，其余的都是元数据操作。因此，在小文件场景中，元数据的重要性不言而喻。针对 AI 场景，我们进行了许多优化。首先，我们有元数据缓存，它可以省去 getattr 或 getxattr 等 RPC 操作。其次，在训练过程中，读取文件时通常是只读的，我们可以将 POSIX 语义弱化。因为在文件系统中，open 操作本身是一个很重的写操作，我们可以将其变为一个轻量级的读操作，从而实现 10 倍以上的性能提升。还有 close 操作，它也是一个很重的写操作，因为它需要更新元数据信息，如文件大小等。我们可以将 close 操作变为异步的，以进一步优化性能。
在项目早期，我们进行了一系列测试，主要针对不同数量的元数据服务（MDS）节点，如 1 个、2 个、3 个和 4 个节点时的性能表现。测试结果显示，性能增长基本呈线性趋势，这为我们后续的研发工作奠定了良好的基础。在实际应用中，当客户进行概念验证（POC）测试时，他们也会关注元数据扩容后的性能表现，例如在元数据操作的 OPS（每秒操作次数）方面，是否会随着扩容而实现成倍增长等。对此，我们进行了相应的测试，并与开源的 CephFS 进行了性能对比。在对比测试中，我们重点关注了两个关键指标：creation（元数据写操作）和 stat（元数据读操作）。测试从一个空集群开始，逐步增加数据量，直至达到 1 亿、10 亿甚至 100 亿的规模。结果显示，YRCloudFile 在元数据 OPS 方面表现稳定，波动较小。而 CephFS 在数据量达到 1 亿后，性能衰减较为严重，当数据量增至几十亿时，其性能几乎无法满足实际使用需求。这一对比结果充分证明了 YRCloudFile 在处理海量元数据时的优越性能。
针对 AI 场景中的存储需求，我们进行了深入研究和优化。通常情况下，AI 存储集群的规模可能在几百台服务器左右，而客户端数量可能在几千台左右，这已经是一个相当大规模的集群了。在这样的集群环境中，我们开展了一系列工作，这些工作具有一定的借鉴意义。
首先，我们注意到集群规模较大的一个重要因素是心跳管理。为了确保集群中各节点的状态能够及时准确地被监控和管理，我们设计了一种汇聚式的心跳上报机制，有效减轻了管理节点（MGR）的压力。同时，我们还将心跳服务独立管理，避免了在心跳上报过程中可能出现的阻塞问题，从而提高了整个集群的稳定性和可靠性。
其次，我们采用了 UDP 协议进行集群事件同步，即事件通知。UDP 协议本身是无状态的，可以批量发送大量数据，并且能够实现高效的同步操作。然而，UDP 协议的一个缺点是数据包容易丢失。为了解决这一问题，我们采用了推拉结合的方式。一方面，我们会主动将事件推送给相关的客户端或其他组件，使它们能够及时感知到事件的变化；另一方面，如果数据包丢失，客户端或其他组件会主动拉取事件信息，从而确保了事件通知的可靠性和及时性。
此外，管理节点（MGR）在集群中扮演着仲裁者的角色，负责管理和协调元数据服务（MDS）和数据存储服务（OSD）。这种设计避免了引入外部仲裁者所带来的复杂工程实践问题，使得 MGR 能够站在一个客观的角度，准确地判断各个服务节点的主从关系，从而提高了整个集群的管理效率和稳定性。
我们的产品规格能够支持 200 多台全闪存储节点的集群规模。这样的集群能够提供 TB 级别以上的带宽，接近 10TBps，能够满足大规模 AI 计算的需求。在客户端支持方面，针对 RDMA 协议，我们可以支持 2000 个客户端；而对于基于 TCP 的以太网的客户端，我们能够支持的规模可达 10 万个。这些性能指标充分展示了 YRCloudFile 在大规模集群环境下的强大性能和高扩展性。
我们的设计理念是先确保性能达到要求，然后再通过各种手段降低成本。具体来说，我们采用了智能数据分层的策略。YRCloudFile 本身作为一个高性能的热层存储空间，主要用于存储频繁访问的热点数据。而对象存储则作为大容量、低成本的冷存储空间，用于存储不那么频繁访问的冷数据。对于业务应用来说，它们并不需要感知后端存储的具体实现，它们看到的仍然是一个统一的文件系统视图。
在智能数据分层功能中，管理员可以根据实际需求自定义冷热数据的划分策略。策略的定义主要基于两个维度：时间和大小。从时间维度来看，管理员可以设定一个时间阈值，例如一天、一周或一个月，如果数据在设定的时间内没有被访问，那么这些数据就会被自动下沉到冷存储中。从大小维度来看，对于小文件，由于它们本身占用的空间较小，可以一直保留在热层存储中，以避免小文件对对象存储的访问压力。此外，智能数据分层还具备业务透明无感的特点，管理员可以通过命令行或者界面实时查看数据下沉的进度，并且后端存储支持多种对象存储类型。在 AI 场景中，数据预热功能至关重要。这是因为 GPU 在进行计算时，无法等待从冷存储中加载数据，因此我们需要提前将数据预热到热层存储中，以确保 GPU 能够快速访问所需数据，从而提高整个 AI 计算的效率。
除了智能数据分层，我们还实现了数据智能加载功能。这一功能同样有助于降低成本。在实际应用中，用户可以将数据集或原始数据存储在对象存储中，无论是公有云的对象存储服务，还是私有云的对象存储系统都可以。当需要进行训练时，再将这些数据加载到全闪文件系统中。传统的做法可能是通过编写脚本来实现数据的上传和下载，但这种方式效率较低。而我们的数据智能加载功能则提供了一种更加高效的方法。它可以将对象存储桶与文件系统的目录进行映射，并允许用户自定义加载策略。例如，用户可以先将元数据预热到文件系统中，使用户能够快速看到对应的数据，然后在后台异步地将实际数据加载过来。此外，我们还支持对象存储的变更订阅功能。当对象存储中的数据集发生变化时，我们可以及时将这些变更同步到全闪文件系统中，确保数据的一致性和实时性。
下图是 YRCloudFile 的整体架构。在最上层是协议层，我们提供了多种协议支持，包括 POSIX 私有客户端、大数据接口、CSI、NFS 以及 SMB 等。中间部分是我们的后端存储服务，每个组件都采用了高可用架构，确保了整个系统的稳定性和可靠性。在最底层，我们提供了数据生命周期管理的解决方案，包括智能数据加载和智能数据分层等功能。这些功能共同构成了 YRCloudFile 的完整架构，使其能够满足不同用户在不同场景下的多样化存储需求。
高级运维特性
在存储系统的构建和优化过程中，稳定性和可运维性是两个至关重要的考量因素。今天，我将向大家详细介绍我们在这些方面所采取的一些高级运维特性。这些特性可以大致分为几个类别：首先是多租户管理，这在 AI 训练和推理场景中尤为重要；其次是数据访问安全；最后是我们在构建底层技术设施时，针对多个网络平面以及客户现场棘手问题所提出的系统优化方案。
多租户管理的实现涉及到空间隔离、流量隔离和访问隔离这三个关键方面。在空间隔离方面，我们通过配额管理来让管理员能够为不同的租户分配不同的存储空间。对于流量控制，我们设置了相应的目录级别的 QoS，以此来限制某个租户的流量上限，防止其对其他用户造成影响。而在访问隔离上，我们采用了基于 IP 白名单或 token 的认证挂载方式，确保租户只能访问自己的存储空间。
在数据访问安全方面，我们采取了多种措施。首先是访问权限控制，我们实现了标准的 POSIX ACL，用户可以通过 ACL 跟 LDAP 或 AD 这样的域控服务来实现全局的用户权限统一管理。其次是日志审计，这对于管理员来说极为重要，它能够记录用户的高危操作，如 unlink（删除链接）、rmdir（删除目录）、rename（重命名）以及 open（打开文件）等操作。日志审计可以记录下是哪个用户在什么时间、使用哪个节点、通过什么工具针对哪些文件进行了操作，这些信息还可以对接到 ELK 平台，实现高效的审计检索。最后是回收站功能，它主要用于应对用户或管理员可能发生的误操作。我们设计的回收站允许每个目录自定义回收站，并且每个回收站都可以自定义清理策略，还可以动态开关。虽然回收站本身会对性能产生 5% 以内的影响，但它为数据安全提供了最后一道防线。
弹性数据网络的本质是帮助用户打通多个网络平面，同时访问一套存储。在 AI 领域，这种需求非常常见。例如，训练集群和推理集群对网络的要求不同，训练集群通常需要 200Gb、400Gb 的 IB 或 RoCE 高速无损网络，而推理集群则一般使用 25Gb 或 100Gb 的以太网网络。这两种网络在物理层面上是隔离的，如果想要实现数据共享，要么通过存储系统本身支持多任务、多网络平面的访问，要么就需要进行额外的数据同步操作，这无疑增加了系统的复杂度。有了弹性数据网络，就可以简化存储基础设施，提高系统的灵活性和效率。
在特定场景下的性能优化方面，由于文件系统是存储领域中最为复杂的类型，其语义丰富，且性能与用户的编码水平直接相关，因此我们挑选了几个在 AI 领域中典型的优化案例。首先是针对单流业务的优化。单流业务是指只有一个线程在工作的业务，如数据拷贝或解压缩等。为了提升这类业务的性能，我们主要依赖缓存机制，通过预取、预读或缓存写操作来显著提高性能。其次是 Cache 的 HardLimit（硬限制），在 AI 训练中，尤其是训练小模型时，如果数据集非常大，PageCache 可能无法完全缓存数据，这对 AI 训练非常不利。因为训练过程中每个数据集都要被读取一遍，虽然是随机读取，但对 Cache 来说并不友好。此外，当缓存数据需要被置换时，如果数据量很大，会导致延迟抖动非常严重，这对 GPU 的效率非常不利。为此，我们设置了 Cache 的 HardLimit，例如对于一个 1TB 的 GPU 服务器，我们允许其使用的缓存最多为 100GB 或 200GB 的数据，这样可以避免触发 PageCache 本身的阈值，从而减少抖动。最后是客户端限速。这与前面提到的 QoS 有所不同，主要是为了解决在 IB 网络场景中，当多个用户共享一个集群时，某些计算节点的网络带宽过高会导致拥塞的问题。这种拥塞会扩散，影响整个集群的网络带宽。我们的解决方案是限制某些客户端的速度，通过牺牲少量客户端的峰值带宽，来实现整个网络的高吞吐量。
A 训练推理解决方案
在 AI 训练阶段，性能是至关重要的。我们通过多种技术手段来提升性能，包括 Multi-Channel 技术、支持 GPU Direct Storage 以降低延迟、内核私有客户端以及支持 400Gb 的 Infiniband 或 RoCE 无损网络。此外，我们还提供了分布式元数据集群来进一步增强性能表现。在数据生命周期管理方面，我们实现了分层存储和数据加载功能，这不仅有助于降低成本，还能打通混合云环境中的数据流转。而在运维方面，我们提供了一系列功能，如 QoS、Quota、子目录挂载、ACL、审计、回收站以及弹性数据网络等，以确保整个大模型训练过程的稳定性和高效性。在智算中心的整体存储架构中，对象存储作为数据底座，而 YRCloudFile 则作为训练存储的加速层，为训练阶段提供高效支持。
在推理阶段，我们的解决方案主要围绕提升推理效率展开。我们针对 KVCache 进行了优化，通过以存换算的方式提高推理效率。我们提供了一个 PB 级的 KVCache 缓存空间，这有助于提高 Cache 命中率，从而节省算力。由于 KVCache 本身是一个吞吐且延迟敏感型的应用，我们确保单个计算节点能够提供 40GBps 的带宽能力，并保证了 KVCache 访问的低延迟。
在测试数据方面，我们在两种场景下进行了性能对比。第一种场景是在长上下文情况下，使用 KVCache 后，TTFT 延迟显著下降，性能提升了约 13 倍。第二种场景是在高并发情况下，针对不同上下文长度的对比测试。我们将使用 vLLM 原生方案与加入 YRCloudFile 后的数据进行对比，结果显示，当上下文长度越长时，使用 KVCache 的效果越好。
我们在推理场景中还提供 DataInsight 的解决方案。目前，DataInsight 主要应用于知识库平台，当前许多知识库平台在数据层面存在最后一公里的问题。DataInsight 能够帮助企业用户从海量历史数据中快速检索出有价值的数据。它支持多种数据源，包括 S3、NAS 或 HDFS 等，并能够实现百亿级数据的秒级检索返回。DataInsight 还支持多维度组合查询，使管理员能够精准检索所需数据，并通过 DataFlow 按需将数据流转到知识库平台中。同时，我们还实现了对第三方存储增量数据的感知功能，这对于企业来说非常有用，因为它能够确保知识库平台的信息保持更新，而无需侵入业务平台。当业务数据写入原有位置时，我们能够自动感知这些增量数据，并将其同步到向量数据库中，从而使知识库平台的用户能够及时获取最新信息，如产品发布参数和最新行业法规等。
总结和未来规划
总结一下，我们在性能方面主要关注元数据性能和数据性能两大块。在元数据性能上，我们采用了分布式元数据架构，并针对元数据操作进行了优化。在数据性能层面，我们引入了 GPU Direct Storage、NVMe SSD、RDMA、Multi-Channel 以及 NUMA 亲和性等多项优化技术。
在运维层面，我们涵盖了多租户管理、数据安全访问、弹性数据网络以及监控告警等功能，以确保系统的稳定性和可维护性。在成本控制方面，我们通过智能数据分层和数据加载等功能来降低成本。
关于未来规划，我们有以下几个方面的考虑：
在推理侧，我们会继续增强相关功能。目前我们已经实现了 KVCache 解决方案，未来将从“有到优”进行进一步优化，提升性能和效率。
在降低成本方面，我们会采取两种策略。一方面，我们引入 EC（Erasure Coding，纠删码）技术，并将其作为产品路线图中的重点。另一方面，在存储介质层面，我们将逐步采用 QLC SSD，因其单盘容量较大，目前已有 32TB 的产品，很快将推出 64TB 的 QLC SSD，这将有助于提高存储密度并降低成本。
在客户端方面，我们会将工作负载卸载到 DPU 中。对于 GPU 服务器而言，其 CPU 和内存资源非常宝贵，因此我们将尽可能减少对这些资源的占用，把相关工作负载转移到 DPU 上，以提高整体效率。
在运维方面，我们会继续增强系统的可运维性。对于存储系统来说，性能、稳定性和可运维性都是非常关键的指标。通过提升可运维性，能够帮助管理员更高效地管理和使用存储系统。
嘉宾介绍
张文涛，毕业于华中科技大学计算机专业硕士，专注于分布式存储领域，拥有超过 15 年的大规模公有云存储架构开发和 AI 存储架构设计，参与主导了 YRCloudFile 高性能分布式文件存储系统从 0 到 1 的设计研发及产品落地工作，并在 AI 场景应用落地方面具备一定的实战经验。在 AI 及高算力场景项目交付上，有着丰富的整体架构设计和性能优化经验。中国智能计算产业联盟专委会技术专家组，上海 TGO 鲲鹏会成员。
会议推荐
来源：极客邦科技