现代AI环境下的I/O挑战：多维性能需求
在本文中，我们将深入研究生成式AI（GenAI）环境中的数据I/O问题，以及通用AI环境中的数据处理。我们的目标是揭示多年来我们在为各种客户部署AI I/O解决方案中所积累的核心洞察。这些客户的范围非常广泛，从在大规模GPU环境中运行的租户，一直到全球一些最大的GPU集群，其中拥有超过1.2万个GPU。
让我们回溯至“创世纪”，早在那个时候，数据量相对较小，特别是按照现代HPC标准来看。我之所以强调HPC，是因为在现代AI兴起之前，这些环境对基础架构的演进产生了深刻的影响。回顾到2000年代初期，大规模的HPC部署可能仅拥有4-5PB的存储容量，而普通规模的部署可能还不到1PB。这些架构主要以HDD作为最快的存储层来设计。由于HDD的局限性，通常会调整作业大小，以尽量多地加载到内存中，避免进行交换操作。此外，为确保操作的连贯性，还需要创建检查点。这样，如果在将作业加载或写入速度较慢且相对脆弱的HDD时出现了任何问题，无需等待整个数据集重新加载和重新启动来纠正错误，从而避免了漫长的等待过程。
随着CPU和网络技术的不断提升，HDD存储I/O性能成为了一个显著的瓶颈。HDD无法满足CPU对I/O的高速需求。尽管出现了速度更快的SSD，但其高昂的价格使客户不得不采取分层和信息孤岛的策略，以在合理的成本下实现最佳性能。每个信息孤岛都被精心优化以满足特定需求，以在性能和成本之间取得最佳平衡。这些架构的设计大致如下：
数据通常被输入并存储在数据存储系统中，这些存储系统通常由HDD或某些基于闪存的NAS构成。接着，数据将经历预处理，然后被复制到计算节点的本地高性能硬盘中，或者进入更高性能的存储层，通常由某种并行文件系统提供支持。随后，数据会再次被复制回NAS设备，然后进入长期数据保留和保护的阶段。这种复制过程为了有效地使用数据并充分利用计算节点，引入了大量的操作成本，并带来了“数据停滞”问题。这个问题变得如此严重，以至于一些知名机构，如Google、Microsoft，以及一些研究型大学，都发表了重要研究论文来探讨这一挑战。
这种信息孤岛架构成为了HPC和早期AI部署的事实标准，导致CPU集群有时会空闲50%甚至更多的时间，等待作业数据的处理。这种情况发生在数据进入核心的训练或模拟处理阶段之前。即使随着时间的推移文件系统得到了改善，硬盘变得更快，但闲置问题仍然存在，并随着时间的推移变得更加严重。CPU逐渐将计算任务交给了GPU，网络速度也从10/25/40 Gbit升级到了100/200/400 Gbit，同时存储容量也大幅增加。这些改进超出了通常的NVMe SSD所能提供的性能。然而，随着企业数据的不断增长，数据停滞问题从50%上升到了高达90%。根据最近的标普全球市场财智报告，32%的AI从业者表示，数据管理和延迟问题是最需要解决的挑战。
因此，开始了整合的探索，以尽可能减少数据停滞和复制。
对比“创世纪”阶段，如今我们正经历从旧有信息孤岛架构向新的整合模式过渡的时刻，就像《出埃及记》中的叙事一般。整合是通过减少数据复制需求，将数据集中在一个统一平台上来解决数据停滞问题的关键一步。然而，随着整合的兴起，I/O问题变得更加复杂。虽然数据整合趋势初期具有明显的优势，但问题是，这些优势在今天是否依然存在？
整合、数据管道和I/O混合
GenAI和AI基础设施的趋势正在摒弃信息孤岛和分层部署的方式，其中每个处理步骤的数据都是独立管理的。取而代之，它们朝着一个整合的环境迈进，其中一个单一的存储平台处理整个数据管道。这种方法有助于更好地管理数据、防止“信息孤岛扩散”，并减轻资源可用性的压力。
尽管基础设施已经经历了改变，但AI数据管道中各个步骤的I/O需求并没有发生变化。通常情况下，每个AI管道步骤都具有不同的数据特性，这可能导致传统存储系统难以满足这些多样化的I/O需求。一些步骤需要低延迟和随机小I/O，而其它步骤需要大规模的连续带宽。此外，由于管道包含多个子步骤，有些步骤需要同时进行混合和并发操作。此处，我们所说的管道是指单个处理过程。此外，在许多情况下，同一系统可能同时运行多个重叠的管道。
单一管道使得为管道的任何特定阶段优化存储系统变得具有挑战性，而在整合环境中运行的多个重叠管道则带来了复杂的I/O混合问题。虽然最初是为虚拟机整合提出的，但这个概念同样适用于GenAI数据管道。
当GenAI管道重叠时，存储系统不再仅仅处理管道中每个步骤的离散I/O，而现在必须同时处理来自每个管道不同阶段的混合I/O。想象一下，各种研究人员或开发人员在不同时间启动训练和/或重新调整作业。这种重叠使I/O模式变得模糊，存储系统必须处理一种倾向于随机性的混合I/O配置文件。在GenAI环境中，这种混合I/O变得非常常见，它会对大多数最初设计用于处理一种或两种信息孤岛I/O类型的传统存储和文件系统造成压力。最终，混合I/O可能会减慢环境的速度，以至于客户会觉得整合的折衷可能不值得。
在GenAI环境中，混合I/O的性能问题中，有一些与其相关的隐藏问题，那就是元数据开销。
预处理、训练和元数据
通常被低估的领域是处理大量小文件（LOSF），这是许多AI工作负载的主要数据类型，同时也是整体元数据负担的主要来源。这个元数据问题贯穿于整个GenAI管道，但让我们重点关注对两个阶段影响较大的情况：数据预处理和深度学习训练。
在预处理阶段，摄入的数据经过处理，以满足模型训练所需的标准。这一过程可能包括注释、图像尺寸调整、对比度平滑、索引等等。然而，当多位研究人员或科学家处理相同的数据时，他们的预处理方法可能因其对模型训练或重新调整的需求而有所不同。即使使用相同的数据集，不同研究人员之间的预处理步骤也可能存在显著差异。
结果是，预处理的混合I/O环境可能占据一个epoch训练时间的高达50%。
I/O的影响是巨大的。处理大量小文件（LOSF）时，不仅会面临I/O混合问题，还会涉及数以百万计的文件操作、读取和写入，这些操作涉及各种不同大小和类型的I/O。
以我们所研究的一个案例为例，我们深入调查了一个客户的情况，该客户正在使用TensorFlow进行深度学习管道的训练，其训练数据库包括1400万张图片。
在预处理过程中，数据会被读取、修改，然后写回，因此会产生大量的小文件。正如前文所提到的，主要采用LOSF配置来存储AI数据集，这导致预处理与系统中的所有其它I/O混合在一起。尽管这种情况与一般I/O混合问题有所不同，但它会引发一些新的挑战：系统中的写入缓存可能会很快用尽，使其陷入一个恶性循环，需要执行额外的I/O来刷新缓存，这会导致系统减速，并延长了完成管道中这些元数据密集型阶段所需的时间。
对元数据影响较大的第二个阶段是深度学习训练阶段。虽然这个阶段通常不涉及大规模的写操作，但却频繁进行大量小文件的随机读取。数据处理在这个阶段通常遵循以下模式：
以随机子集进行小批量处理和迭代整个数据集 对每个小批量进行训练 对整个数据集进行完整epoch处理，通常是随机顺序 使用某种超参数设置来控制过程（例如所需的精度、epoch数量等）
这个过程（或其变化形式）会导致大量的文件打开操作、文件统计信息等，这些操作并不在传统I/O中直接显示。在下面的图中，我们可以看到一个客户使用TensorFlow在ImageNet上进行深度学习训练，其训练数据集包含了惊人的1400万张图像。在这个训练中，有约30%的读操作是与文件打开相关的。这种开销在深度学习训练、ResNet-50类型的负载以及迁移学习的特性中普遍存在，具体开销取决于所部署的训练类型和文件大小，可能介于25%到75%之间。这种“隐性的I/O”在工作负载扩展时对数据平台带来额外的负担。想象一下，如果训练环境需要处理每秒1000万次读I/O，那么将不得不额外处理500万次的文件操作。
文件的大小也是一个关键因素。在同一TensorFlow管道中，我们发现数据要么非常小（不到100字节），要么属于中到大范畴，大小在10KB到1MB之间。由于文件大小的差异，数据平台需要具备处理同时涉及非常小且随机的I/O和稍微更顺序的I/O的能力，以加速训练的epoch时间。
迄今为止，显而易见的是，多管道混合I/O和元数据问题构成了一个真正的挑战，需要一个高性能的数据平台，以同时满足多维性能需求。然而，这还未触及检查点训练周期引发的问题。然而，有些人可能会提出异议：“我没在使用ResNet-50和TensorFlow。”或者“我的深度学习批处理方式与你所描述的有所不同，所以你的场景对我不适用！”
不同类型的AI工作流中的I/O模式
接下来，我们将深入研究几个客户案例，分析其中的I/O情况，并得出一些重要结论。这些案例涵盖了多个行业和不同类型的AI/GenAI工作。我们所呈现的数据和图直接来源于我们的产品的遥测数据，这个基于云的支持和分析工具使客户能够有效管理他们的环境。
首先，让我们来看一个自然语言处理（NLP）的案例。在这个场景中，某个GenAI客户正在构建支持语音到文本和语音到操作转换的AI模型。
观察这个环境，我们可以看到它是一个典型的混合I/O管道，其中读操作数量相对稳定，而写操作存在I/O峰值。这些数据反映了我们后端服务器的负载状况。
在图中，深紫色和浅紫色代表最大和平均利用率。这显示了该客户的AI管道具有高度的爆发性特性。如果只看平均值，可能会认为系统的利用率很低，约为5%。然而，实际情况是，系统在短短几分钟内会发生强烈的爆发，使得利用率频繁波动，达到80-100%的峰值。
对于这个NLP管道，读/写比例为47/53，但需要注意的是I/O的大小差异：大I/O为读，而较小的I/O为写。在这个情况下，客户将一些通常不到100K大小的小样本拼接在一起，形成了一个较大的文件，并将其作为流式读取的方式。然而，为什么会出现如此多的小写操作呢？这不仅在GenAI和AI工作负载中常见，也在许多HPC工作负载中存在：检查点操作。
在此案例中，较小的写I/O毫无疑问地出现在NLP工作流程中，通常是由层检查点操作引起的。数据的多样性再次使数据平台面临重大挑战，因为需要适应工作流程中不同性能需求。
接下来，我们将进一步探讨AI/ML模型开发环境。在这一场景中，客户正致力于构建涵盖文本-文本和文本-操作能力的NLP和ML功能组合。相对于前述情形，这个数据管道较为分隔，重叠程度较低，因为它们还未得到广泛应用。我们可以观察到在读取和写操作之间出现混合I/O，其中读操作占48%，写操作占52%。此外，需要注意读操作的I/O大小通常较大。
需要特别强调的是预处理工作对I/O模式的影响。由于数据摄入经过大规模的预处理以规范化数据，因此读操作的I/O范围较窄，更具可预测性。这涉及在大量的预处理工作和简化训练I/O处理之间的权衡，以确保训练I/O处理既容易又高效，而不至过于复杂和难以应对。
最后，让我们观察一个图像识别训练的案例。在此案例中，自动图像预处理已经完成（值得注意的是，与前述的元数据案例不同，客户尚未提供关于是否使用TensorFlow、PyTorch等工具的详细信息）。客户已经创建了一个专门的读操作环境，用于图像训练，这是一个不太常见的做法。然而，在他们目前的操作规模下，他们已经决定将训练与除了每日批量图像传输到存储集群之外的其它所有工作流程进行隔离。
如预期，整体吞吐量主要由大小相对一致的读操作主导。然而，写操作存在较大的差异。这些写操作主要包括文件的元数据更新、处理数据的回写以及检查点操作。正如前文所述，虽然测量的数据包括实际的数据传输情况，但所有这些写操作的元数据更新并未显示为数据传输，但它们对模型训练性能可能产生显著的影响。
结论
在GenAI和AI环境中，I/O数据模式因其高度多样性，尤其是在大规模情景下，变得复杂而具有挑战性。重叠的数据管道引入了"I/O混合器"效应，显著加剧了这一问题。需要处理的I/O通常是突发的，读/写I/O的大小变化范围广泛，而与元数据问题结合在一起，低延迟成为必要。低延迟对系统整体性能至关重要，因为它直接影响每个操作。总体延迟越低，AI处理流程就能更快地进入模型工作流中的下一个迭代、epoch、重新调整、扩展或嵌入环节。
这些I/O配置要求数据平台具备多维性能需求的处理能力，以适应各种GenAI和AI环境。许多数据平台之所以难以实现这种性能，原因有几个，包括：
通过将RDMA与较旧的文件协议（如NFS）叠加以实现低延迟传输。尽管可以运行，但仍无法实现类似DPDK与NVMeoF等传输技术所实现的超低延迟。
文件系统延迟。如果文件系统本身未设计用于大规模并行处理元数据和数据操作，那么它会串行访问，导致在响应客户端I/O请求时出现延迟。
针对单一工作负载进行配置。许多平台在设计选择上优化了单一性能配置。这导致必须将数据从平台内部复制到专门调整的部分，从而导致数据停滞。
无法解决大量小文件（LOSF）问题。随着基础模型和其它大型学习模型摄取数百万甚至数十亿个训练数据文件，许多平台难以处理这些非结构化数据。虽然将数据连接成较少数量的大文件是一种解决方法，但这可能导致其它访问问题并可能增加延迟。
为应对这些挑战，数据平台需要整合多维性能、采用低延迟传输技术、改进文件系统，以及具备处理大量小文件（LOSF）的能力。成功的AI和GenAI工作负载需要全面考虑这些因素，以提供高效且高性能的数据存储和管理解决方案。
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解