Alluxio + OCI:为 AI 工作负载实现亚毫秒访问延迟与可扩展吞吐

本文作者:

Pinkesh Valdria - OCI 全球 AI/ML/GPU/ 存储基础设施专家团队总监

Bin Fan -Alluxio 创始成员、技术副总裁

企业在建设人工智能与机器学习基础设施时,往往希望控制基础设施与数据访问成本,同时通过提升 GPU 利用率,实现更好的投入产出比。

甲骨文云基础设施(OCI)能够为高要求的 AI 工作负载提供高性能 GPU 算力。但对于 I/O 密集型作业,计算节点与远端对象存储之间的访问延迟、有限的网络带宽会直接拉低 GPU 的实际利用率。当 GPU 因等待数据而空闲时,算力计费并不会停止,企业相当于为没有发挥价值的算力持续付费。

本篇参考架构将介绍,在 OCI 环境中把 Alluxio 部署为计算侧分布式缓存加速层,可以实现以下价值:

  • 提升 GPU 实际利用率;
  • 降低训练、推理类业务的实际基础设施成本;
  • 减少高频数据集的数据访问延迟;
  • 兼容 OCI 对象存储,同时支持其他主流对象存储后端。

通过消除存储带来的性能瓶颈,这套架构将给 AI 工作负载带来 AI 基础设施投入产出比的显著提升。

业务目标:提升 AI 基础设施投入产出比

GPU 集群是 AI 基础设施成本占比最高的组成部分。想要提升整体性价比,需要同时达成下面几个目标:

  • 维持较高的 GPU 利用率;
  • 消除 I/O 读写瓶颈;
  • 减少不必要的数据远程传输;
  • 保障持久化存储本身的成本可控。

在计算侧部署 Alluxio 缓存加速层,可以持续稳定地向 GPU 供给高频访问数据集,以此提升 GPU 利用率,优化基础设施整体使用效率。

基准测试范围与说明:H100 GPU 利用率采用 MLPerf Storage v2.0 标准加速器仿真方法完成评估,本次测试未使用物理 H100 硬件;存储 I/O、网络流量、缓存能力在真实物理环境中完成验证,同时采集了延迟、IOPS、吞吐量指标。

架构概述

该架构图仅作为原理演示,不等同于 WARP 真实测试平台。Alluxio 基于前端 TCP/IP 网络通信;本次测试使用 100GbE 网络,未启用 RDMA 能力。

1. 计算侧加速

新一代 GPU 实例普遍配备高性能本地 NVMe 磁盘。Alluxio 是一套软件形态的分布式缓存层,可以和 OCI GPU 计算服务协同部署,聚合各个计算节点的本地 NVMe 资源构建统一缓存池。针对反复读取的数据集,该架构能够大幅降低业务对远端存储延迟、计算与持久化存储之间网络带宽的依赖。

2. 兼容多类型存储后端

原始业务数据依旧保存在后端对象存储中,支持的存储类型包含:OCI 对象存储、亚马逊云对象存储 AWS S3、谷歌云存储(GCS)、微软 Azure Blob 存储、HDFS、阿里云OSS、腾讯 COS、火山引擎 TOS、百度 BOS、NAS 等等。该模式支持计算与持久化存储两套资源独立运维管理的架构方案。

3. 吞吐量可横向扩展

AI 工作负载普遍属于 I/O 密集型。Alluxio 采用分布式架构,新增 Worker 节点即可同步扩容缓存容量与业务吞吐能力。本文后续测试环境中,集群吞吐量会随节点数量增加同步提升。

4. 无需大规模迁移数据,不绑定私有存储格式

在 PB 级海量数据场景,全量数据集迁移会带来高昂的成本与巨大运维复杂度。采用本架构,对象存储依旧作为业务的权威数据源(system of record),Alluxio 仅把高频访问的数据缓存到靠近计算的一侧。客户不需要为了使用缓存层,对原始数据集做批量迁移或者格式改造。

业务数据流

  • AI/ML 工作负载运行在 OCI GPU 实例之上;
  • 工作负载通过 Alluxio 访问数据;
  • 如果请求的数据尚未缓存,Alluxio 会从后端对象存储拉取对应数据;
  • 拉取完成的数据,会分布式缓存到集群各个 Worker 节点的 NVMe 本地盘;
  • 后续再次读取这份已缓存数据,直接从计算侧缓存返回,相比远端存储访问可以获得极低的延迟。

架构组件

1. OCI 可用区

全部计算资源部署在同一个 OCI 可用区内,以利用区域网络。

2. GPU 计算层

OCI GPU 机型(包含 H100 系列实例)可以承载:

  • 训练工作负载;
  • 微调工作负载;
  • 推理工作负载;
  • 支持 Kubernetes 容器部署、裸金属直接部署两种形态。

3. Alluxio 集群

Alluxio 集群由多个 Worker 进程组成,所有 Worker 共同提供分布式缓存的容量与带宽。Worker 支持两种部署模式:

  • 独立部署模式:运行在专门用于缓存的 OCI DenseIO 实例节点上;
  • 混合部署模式:直接部署在承载 AI 作业的 OCI GPU 节点上。

Worker 节点可以调度的资源包含本地 NVMe 磁盘、内存、网络带宽、CPU 资源。

工作负载可通过 Alluxio 提供的 POSIX 接口、S3 兼容接口访问数据。将热点数据缓存至计算侧,能够有效降低远端读取带来的延迟。本次测试使用 Alluxio Enterprise 3.6 版本,采用去中心化架构,数据与元数据分布在各个 Worker 节点;本次基准测试未覆盖节点故障场景验证。

4. 持久化对象存储层

原始持久化数据存放在 OCI 对象存储或者其他兼容的对象存储后端,作为权威数据源。数据被缓存之后,重复读取操作不再强依赖后端存储的部署位置与访问时延。

Alluxio 两种部署模式在 OCI 上如何选择

混合部署模式:高性价比方案

Alluxio 直接部署在业务使用的 GPU 实例上。

适用场景:

  • GPU 服务器节点有大量闲置的 NVMe 盘资源;
  • 需要快速上线部署;
  • 对成本敏感的业务环境。

核心优势:

  • 不需要额外采购专门的缓存节点;
  • 充分复用 GPU 实例自带的 NVMe 本地存储资源;
  • Alluxio 所需的 CPU、内存、NVMe 资源可与 AI 作业灵活分配共享;

混合部署模式:Alluxio Worker 与 AI 工作负载共同运行在同一批 OCI GPU 实例中

独立部署模式:极致性能方案

Alluxio 部署在专属的 OCI DenseIO 实例集群,和 GPU 计算节点物理分离。

适用场景:

  • GPU服务器本地没有NVMe盘或者可用磁盘容量比较小,不足以缓存热数据集;
  • 多业务共享一套基础设施;
  • 业务对吞吐能力要求很高。

核心优势:

  • 提供更大的缓存容量与吞吐上限;
  • 缓存层集群、GPU 计算集群可以独立扩缩容;
  • 在已验证的配置下,能够长期维持更高的 GPU 利用率。

独立部署模式:Alluxio Worker 运行在独立 DenseIO 实例,GPU 工作负载运行在单独的 OCI GPU 实例。

基准测试环境配置

本文全部测试结果基于 Alluxio Enterprise 3.6 版本。物理 WARP 测试环境采用 OCI BM.DenseIO.E5.128 实例;WARP 压测客户端以 Kubernetes 任务形式运行,对接 Alluxio 集群 Worker,后端持久化存储使用 OCI 对象存储。

WARP 性能测试框架

性能测试结果

  • 使用仿真 H100,MLPerf Storage v2.0 测试得到加速器利用率可达 90‐98%;
  • WARP 压测,热缓存场景平均数据访问延迟约为 0.3‐0.6ms;
  • 6 节点集群、100Gbps 网络环境下,聚合 I/O 吞吐量最高可达 57GB/s。

核心结论:减少 GPU 等待热点数据的耗时,能够持续拉高 GPU 利用率,对受 I/O 瓶颈约束的工作负载,可以显著提升 GPU 实际性价比。

对业务性价比的影响

如果没有计算侧缓存,I/O 受限的 AI 工作负载通常会遇到这些问题:

  • GPU 大量时间在等待远端存储返回数据;
  • 完成同等有效计算工作量,实际基础设施成本更高。

当加入 Alluxio 缓存集群之后:

  • GPU 等待重复读取数据的耗时大幅降低;
  • 重复访问远端对象存储的频次下降,对应存储访问开销随之减少;
  • 基础设施资源利用率提升,带来实际的性价比改善。

性能指标对比

* 注1:GPU 利用率为模型仿真输入参考值;存储性能指标基于上表 WARP 测试环境得出。

* 注2:由于warp client不支持http 307 redirect,Alluxio Enterprise

3.6版本的测试性能会因此受到折损(大概50%);当前最新Alluxio Enterprise 3.8版本已经优化该问题,不论S3 SDK是否支持 HTTP 307 redirect,都能达到吞吐上限,即在该环境中达到60GB/s+吞吐量。

部署前需要考虑的事项

缓存容量规划

Alluxio 集群规模需要结合工作负载、目标吞吐速率来规划。

  • 业务工作集大小:尽量把高频访问的数据集全部放入分布式 NVMe 缓存池;命中缓存读取可以避开远端对象存储的延迟;
  • 网络带宽:高吞吐工作负载,需要配置足够的 Worker 节点与网络带宽来承载业务速率;
  • 并发访问量:高并发工作负载需要扩充 Worker 算力与 I/O 并行能力,避免缓存争抢和网络瓶颈。

多云架构适配

Alluxio 兼容多种存储后端,企业可以基于支持的配置实现:

  • 原始持久化数据保存在 OCI 对象存储、本地对象存储或者其他公有云对象存储;
  • 在 OCI 平台运行 GPU 计算业务;
  • 不再需要为了让数据靠近算力,执行大规模数据集迁移。

热点数据进入缓存之后,重复读取性能不再高度依赖原始持久化数据的部署位置。

运维监控重点

建议持续监控以下关键指标:

  • GPU 利用率;
  • 缓存命中率;
  • 网络饱和度;
  • 后端存储访问延迟。

对于能够从缓存获益的工作负载,当缓存命中率得到提升,通常会同步带来 GPU 利用率与基础设施性价比的提升。

总结

想要提升 AI/ML 基础设施的投入产出比,核心在于消除 I/O 瓶颈,保障 GPU 可以持续高效地获取所需数据。

在 OCI GPU 环境部署 Alluxio 作为计算侧缓存加速层,能够降低数据访问延迟、提升 GPU 硬件利用率。对于受 I/O 瓶颈约束的业务场景,可以实实在在改善基础设施的性价比。

相关推荐
johnsong35 分钟前
Claude Fable 5.2 登顶:65 分、单发做游戏,和一份 $26.54 一单的账单
人工智能·游戏
凌杰42 分钟前
AI 学习笔记:Transformer 架构详解
人工智能
硅谷秋水1 小时前
扩展机器人智能体的在线探索能力
人工智能·语言模型·机器人
Eyfcom1 小时前
〖高级算法实战 04〗物流定价博弈论:动态定价算法如何平衡运力供需与利润?
人工智能·物流管理系统·高级算法实战·众包物流
锋行天下1 小时前
服务器 Python 2.7 装不了 langgraph-cli?用本地生成 Dockerfile 曲线救国
人工智能·后端·python
一条大祥脚1 小时前
深入理解 PyTorch FlexAttention:从 Score Mod 到 Mask Mod 的稀疏加速之道
人工智能·pytorch·python·注意力机制·flex attention·可编程注意力
机 _ 长1 小时前
03 智算运维|丢 0.1% 的包,8 卡训练为什么会崩
人工智能·模型部署·智算运维
汤姆宝库2 小时前
权重量化的实现:从absmax到GPTQ与AWQ
人工智能
wflynn2 小时前
Genie 4新增原生音频,实时世界模型加入声音生成
ai·技术