多GPU集群时代的I/O优化：分布式缓存在AI基础架构中的关键作用

前言一、多GPU集群时代二、诊断GPU利用率低下问题模型训练中 GPU 利用率低的常见原因（1）基础设施瓶颈（2）代码瓶颈三、优化GPU 集群的数据加载如何应对 I/O 瓶颈选项1：直接访问云对象存储选项2：本地节点缓存（例如每个节点上使用 S3FS/FUSE）选项3：专用高性能存储选项4：Alluxio 分布式缓存四、Alluxio AI 概述1.Alluxio 在 AI 基础设施技术栈中的关键角色2.Alluxio AI 的关键特性（1）用于加速数据加载与模型Checkpointing的分布式缓存（2）缓存预加载与管理（3）统一命名空间 – 统一逻辑 “alluxio://” 命名空间（4）企业级安全特性（5）其他功能五、案例研究：全球前十电商巨头加速搜索和推荐 AI 模型训练1.面临的挑战2.Alluxio 的解决方案六、总结目录 01020510130312040604181605080808091213141717181920 AI时代，AI/ML基础设施团队肩负着异常艰巨的任务。他们需要为内部用户构建并交付可靠、高性能的基础设施，以支持模型训练、微调、分发以及服务，而这些任务往往依赖于TB级甚至PB级的数据。在如此庞大的规模上构建并管理基础设施已极具挑战，再加上预算限制、硬件短缺、混合/多云架构以及市场竞争压力，使得AI/ML基础设施成为技术领域名副其实的“硬核战场”。GPU是AI/ML基础设施拼图中不可或缺的一块。基于并行处理架构的GPU，因其能高效地利用海量数据同步执行多重复杂运算，现已成为训练和微调大模型的关键组件。尽管GPU 价格昂贵且供应紧张，各企业基础架构团队仍在争相采购跨云平台与本地数据中心的GPU，以满足AI/ML工程团队为试验和训练新模型而激增的需求。在多GPU环境中，团队必须利用任何可用的GPU资源, 而这些资源往往远离存储了海量训练数据的中央数据湖，这就需要跨区域和跨云迁移数据，或是远程访问数据。而这两种方式都存在速度慢、复杂度高、成本昂贵的问题。在AI/ML工程方面，尽管在GPU上已投入了大量资源，团队仍难以达到高效训练、调优以及测试AI模型所需的性能要求。这种情况会导致新模型或升级模型部署到生产时产生延迟，进而加剧竞争压力、对用户体验带来负面影响，同时阻碍了基于实际生产使用情况不断优化模型准确性和性能的反馈闭环。那么，能不能通过简单地增加GPU数量来解决问题？虽然这不失为一种解决方案，但团队首先需要确保现有GPU资源得到充分利用。最新调研显示，68%的企业其GPU峰值利用率不足70%。在这种情况下，盲目增加AI/ML基础设施中的GPU资源，不仅对性能提升收效甚微，更会大幅推高基础设施预算。本文将深入探讨AI工作负载缓慢与GPU利用率低下的常见诱因，提供根本原因的诊断方法，并针对GPU未充分利用的核心问题给出解决方案。前言 追求卓越AI能力的企业组织，如今正面临着GPU资源分散化的运营环境， GPU 资源分布在多个区域的云平台、多个公有云、私有数据中心以及专门的 AI 基础设施供应商之间。这种多GPU集群架构的形成并非主动设计，而是迫于现实：各行业爆发式的GPU需求导致GPU全球性短缺，迫使基础设施团队采取"哪里有算力就用哪里"的策略。与其等待数月才能在单一地点获得集中 GPU配置，企业如今更倾向于在不同环境中拼凑算力资源。这种模式带来了三大关键性数据挑战：1.训练任务延迟：中央数据湖与GPU资源之间的地理分隔会导致数据访问延迟，拖慢AI训练进程。2.成本高昂：跨云数据传输费用昂贵。当从云端读取数据时，会产生出口流量费用（即数据传输成本），随着数据量增大这项费用会急剧增加。3.数据管理复杂性：为避免高昂的出口流量费用，企业可能选择跨云环境复制数据，由此导致管理复杂性、数据一致性挑战及额外的数据延迟。一、多GPU集群时代 GPU利用率是衡量显卡计算资源使用效率的重要指标。当利用率维持高位（80%及以上），表明端到端的AI/ML工作负载能充分调用GPU算力执行复杂运算；反之则意味着工作流在抵达GPU计算环节前，已存在一个或多个性能瓶颈。根据最近一项关于 AI 基础设施的调研，多数AI/ML团队尚未释放其GPU的全部价值。数据显示，仅有7%的受访机构能在高峰期实现85%以上的GPU利用率，这使得提升GPU利用率成为企业首要的技术优化方向。二、诊断GPU利用率低下问题图 1：AI 基础设施调研模型训练中 GPU 利用率低的常见原因和其他复杂的软件系统一样，AI/ML 工作负载中 GPU 利用率不足、性能表现不佳的情况，往往基于多个因素。在深入分析这些常见原因之前，我们先从宏观角度了解一下 AI/ML 模型训练与 GPU 利用率相关的关键阶段：（1）训练数据加载：AI/ML 训练任务首先使用 CPU 资源从存储中定位并加载训练数据至 CPU 内存。（2）数据预处理：数据加载到 CPU 内存后，训练任务再次使用 CPU 资源对数据进行预处理，为后续模型训练做准备。 （3）训练计算：当数据准备好后，会从 CPU 内存复制到 GPU 内存，然后利用 GPU资源进行模型训练计算。基于上述理解，我们可以将造成 GPU 利用率不足的常见原因分为两大类：基础设施瓶颈与计算瓶颈。1.基础设施瓶颈如上所述，AI/ML 模型训练任务首先会从存储中定位并加载训练数据到 CPU 内存中，然后对数据进行预处理转换。当训练数据集的规模达到数百 TB 甚至更大时，在数据加载和转换阶段出现瓶颈是极为普遍的，常见原因包括：（1）存储系统与 GPU 集群之间的物理距离会带来带宽和延迟方面的限制，从而会对AI 工作负载的性能以及 GPU 资源的利用率产生负面影响。（2）存储系统无法满足 AI/ML 工作负载在数据加载阶段对 I/O 带宽和延迟的高要求。（3）存储系统与 GPU 服务器之间的网络无法提供AI/ML 工作负载所需的传输性能（4）可用的 CPU 资源对数据转化的处理速度无法满足AI/ML 工作负载的要求。（5）虽然不属于数据加载或转换阶段，但 AI/ML 工作负载在训练过程中会定期将模型检查点（checkpoint）文件写入存储系统，这一操作也常常成为性能瓶颈。2.计算瓶颈尽管基础设施瓶颈最为常见，但低效的编程实践会进一步放大基础设施限制，甚至引发新的系统瓶颈。最常见的计算相关瓶颈包括：（1）低效的数据转换计算：过度占用CPU资源的转换计算，会在数据拷贝至GPU内存前形成性能瓶颈。（2）未充分并行化的计算任务：未能有效并行化的计算负载会导致GPU闲置。GPU专为并行执行多线程计算而设计，应用程序需具备良好的并行计算结构才能发挥其优势。（3）训练批次过小：批大小（batch size）作为决定每个训练迭代数据量的超参数，若设置过小将导致GPU利用率低下。必须优化批次大小以确保每次迭代加载足够数据量，使GPU持续处于工作状态。 I/O 瓶颈降低 GPU 利用率并拖慢 AI 工作负载对于任何应用程序而言，存储层或网络层的瓶颈都会削弱计算层的效能。AI 训练应用也不例外，区别在于这种瓶颈带来的代价往往极为高昂，不仅体现在基础设施和生产效率上的损失，有时甚至还包括带来直接的营收损失。当存储或网络瓶颈导致无法将足够的训练数据及时传输到 GPU 时，就会发生“数据停滞（Data Stall）”。数据停滞是 GPU 利用率低下和 AI 工作负载性能不佳的主要原因。由于模型训练计算需要源源不断地将数据加载进 GPU 内存，因此消除 I/O 瓶颈是优化 GPU 利用率、提升端到端模型训练性能的关键。模型训练中涉及 I/O 操作的两个主要环节包括：1.数据加载（Data Loading），顾名思义，是指将训练数据集从存储系统加载到GPU 服 务 器 的CPU 内 存 中 的 过 程 。 数 据 加 载 过 程 （ 例 如 使 用PyTorch 的DataLoader）会向训练数据的存储系统发出顺序读和随机读 I/O 请求。由于模型训练通常需要多个 epoch（一个 epoch 表示对整个训练数据集完整运行一次训练），因此数据加载器在整个训练周期内会多次从存储系统读取训练数据。2.模型 Checkpointing是指训练定期将模型状态保存到磁盘的过程。这样一旦训练过程中发生故障，可以通过重新加载已保存的模型状态，从上一次中断的地方继续训练。Checkpointing是一项开销较大的操作，因为在模型状态写入磁盘期间，训练计算会被暂停。大多数训练任务会在每次迭代后进行一次Checkpointing。在一个epoch 的过程中，随着每次迭代的进行，模型状态文件会不断变大，最终可能达到数百 GB 甚至更大。三、优化GPU集群的数据加载 在更好地理解了模型训练应用程序、GPU 与存储系统之间的交互关系之后，我们可以进一步看看在模型训练过程中导致I/O 缓慢和数据停滞的一些常见因素：混合/多云架构：过去，通常将GPU计算与数据集部署在同一个位置优化性能。而在现代的数据架构中，尤其是在混合云或多云环境中，计算和存储往往是解耦的。由于 GPU 成本高且供应持续紧张，团队通常会选择在成本最低的 GPU 环境中运行训练任务。这意味着训练任务所在的 GPU 集群与训练数据所在的位置（数据中心、云平台或地区）会不同，从而导致数据访问变慢。存储吞吐能力不足：传统配备机械硬盘（HDD）的存储系统无法提供 AI 应用所需的高吞吐能力。相较于固态硬盘（SSD），HDD 的读写速度较慢，不适合执行大规模数据加载等高性能任务。存 储I/O 延 迟 高 ：从 对 象 存 储 系 统 （ 如Amazon S3 或Google CloudStorage）中访问数据会产生显著延迟。尤其当训练数据分布在地理位置较远的区域，或者在未缓存的情况下频繁访问时，这种延迟问题尤为严重。网络带宽受限：网络附加存储（NAS）或分布式文件系统被多个进程或用户同时访问时，可能面临带宽瓶颈。这种资源争用会显著拖慢数据传输速度。 如何应对I/O 瓶颈在设计 AI 训练基础设施时，平台工程师通常会考虑三种方式来存储和访问训练数据。每种方式在性能、成本和运维复杂性方面都有不同的权衡。目前在存储和访问 AI 训练数据方面有四种常见选项：选项1：直接访问云对象存储直接访问是最简单直接的方法，因为它不会引入中间层或涉及数据移动，确保训练任务访问的是最新数据。运行在 GPU 服务器上的训练应用程序通过对象存储的原生API 访问数据，而GPU服务器可能与云对象存储位于同一云或同一区域，也可能不在同一云或同一区域。每个 epoch 的训练过程都必须从云存储中读取数据。这种方式的优点是简单直接，但在大规模训练场景下，缺点也很明显：性能低下：由于网络延迟和总带宽受限，数据访问速度慢，容易造成 GPU“饥饿”状态（等待数据输入）。成本高：在云对象存储中，每次读取请求和数据出口（egress）都可能产生费用。并发访问受限：当多个节点同时访问云对象存储时，可能会触发云厂商的速率限制（rate limit），进一步引发 I/O 延迟和带宽问题。强耦合性：训练应用程序可能需要直接了解存储细节（如路径、API），一旦更换存储后端，工程师就需要修改所有训练任务的代码或配置，增加维护负担。选项2：本地节点缓存（例如每个节点上使用 S3FS/FUSE）这种方案是在每个训练节点上安装一个文件系统适配器（如用于 Amazon S3 的s3fs），可以将文件缓存在该节点的本地文件系统中。这样可以避免在同一个节点生命周期内重复下载相同的文件——从第二个 epoch 开始，数据可以直接命中本地磁盘缓存。同时，它也提供了标准的文件系统接口，代码可以像访问本地路径一样访问对象存储中的数据。虽然该方案比完全没有缓存要好，但仍然存在一些问题：节点之间无法共享缓存：假设有 8 个节点在读取相同的数据，每个节点都会单独下载一份副本并存入自己的缓存中，由此导致冗余的网络 I/O 和本地存储浪费。 每个节点的缓存容量有限：单个节点的缓存只能容纳该