【企业级AI infra】IBM Vela系统：AI计算的革新之路

数据存储前沿技术

发布于 2025-03-10 11:27:48

570

全文概览

随着AI模型规模的指数级增长，企业面临计算与存储的双重挑战。IBM通过Vela系统和Granite系列模型，重新定义了AI基础设施的标准。本文深入解析其架构设计、性能优化及存储解决方案，揭示如何在云环境中实现高效、可扩展的AI计算。从基础模型的演进到Vela系统的网络与存储创新，再到IBM Storage Scale的突破性改进，内容覆盖AI基础设施的全生命周期，为企业构建下一代AI平台提供关键洞察。

阅读收获

掌握Vela系统的创新设计：理解其如何通过网络优化（如GDR）、虚拟化与存储架构提升AI计算效率。
解析Granite模型的应用场景：学习其在代码生成、语言处理和时间序列预测中的实际价值。
洞察存储优化策略：IBM Storage Scale如何解决大规模训练的存储瓶颈，实现高效数据管理。
获取AI基础设施设计原则：从硬件配置到自动化运维，构建可扩展的AI平台。

关于作者

职业生涯的经验

幻灯片描述了演讲者在20多年职业生涯中的关键阶段和经历。每个阶段的重点是学习新的技术和技能，推广工作，并帮助他人。演讲者还强调了社区服务和领导力的重要性，以及通过帮助他人获得成长的经验。

===

20+年职业旅程

2003-2012
- 构建面向高性能计算（HPC）和企业应用程序的优化系统
- 经验：深入技术工作，拓展同事、导师和社区的圈子
2013-2020
- 构建云服务
- 经验：不要害怕学习新事物，让世界了解你的工作
2021-2025
- 构建HPC和AI系统作为云服务
- 经验：质疑传统智慧，通过将技能应用到新问题中来增长自己的能力
社区服务与领导力
- 辅导、教学（纽约大学和哥伦比亚大学）、教练：外语学习（FLL）、数学、科学
- 经验：帮助他人会帮助自己

人工智能的新进展

基础模型的兴起

图片展示了从传统AI领域模型（模型1、模型2、模型3）到新兴的基础模型的转变。

基础模型通过自监督训练和数据预处理在数据选择和整理方面具有更多的集中和大规模的特性。与传统模型不同，基础模型更加注重大规模的自我训练与数据预处理，从而适应不断变化的应用需求。

===

模型1、模型2、模型3：

部署（Deployment）
验证（Validation）
训练（Training）
模型开发（Model development）
数据工程与标注（Data Eng & Labeling）
数据选择与整理（Data selection & curation）

这些模型都需要大量的数据（日志、表格、社交、视频、图像等）。

基础模型（右侧）：

大规模自监督训练（Large-scale self-supervised training）
数据整理与预处理（Data curation and pre-processing）
数据选择与整理（Data selection & curation）
同样需要大量的数据（日志、表格、社交、视频、图像等）

企业中基础模型的应用

代码助手 (Code Assistants)：
- 显示了一个从COBOL代码到生成的Java代码的转换过程。
- 提供了一个功能来调整和定制代码，以满足用户的需求。
客户服务助手 (Customer Service Assistants)：
- 提供了一个人工智能助手，帮助人力资源管理，处理职位招聘等任务。
- 还能回答有关销售报告的相关问题，并提供查询和建议功能。
工作流程编排助手 (Workflow Orchestration Assistants)：
- 该助手帮助用户通过创建任务、发送邮件等操作来简化工作流程。
- 包括与Google Sheets的集成，支持自动化发布工作岗位等任务。

IBM Granite Models 驱动企业应用

幻灯片介绍了IBM Granite系列模型在企业中的应用，主要分为三个方向：代码生成、语言处理和时间序列预测。Granite模型在不同的任务中都展现了优化的性能，特别是在提高准确度、吞吐量和资源效率方面，适用于企业级的各种应用场景。

===

Granite for Code 训练于116种编程语言，Granite代码模型（3b、8b、20b、34b）针对企业级软件开发工作流进行了优化。
Granite for Language Granite语言模型（7b开源，13b英语，20b多语言，8b日语）展示了更高的准确度和吞吐量，同时在低延迟的情况下，仅消耗极少量的GPU资源。
Granite for Time Series Granite时间序列是一系列轻量级的预训练模型，用于时间序列预测，训练于涵盖多个业务和工业应用领域的数据集。

如何理解这里的时间序列模型？

与传统的大模型（如基础模型、语言模型等）相比，时间序列预测模型在结构上有几个明显的不同之处，主要体现在以下几个方面：

1. 数据依赖性：

时间序列模型：时间序列模型的数据依赖性非常强，数据是按照时间顺序排列的，因此时间序列模型必须能够捕捉时间上的相关性。它们特别注重数据的时序性，即当前的数据点通常与之前的数据点有显著的关系。
传统大模型：传统的大模型（如语言模型或图像处理模型）虽然也可能包含一定的时序信息（例如，视频处理或文本生成），但这些模型的结构更多地关注特征的表达和复杂的模式识别，而不一定强烈依赖时间顺序。

2. 输入数据的顺序处理：

时间序列模型：时间序列模型的输入数据必须按照时间顺序进行处理。常见的时间序列模型，如ARIMA（自回归积分滑动平均模型）、LSTM（长短期记忆网络）和GRU（门控循环单元）等，都会将过去的时间步的数据作为输入来预测未来的值。因此，时间序列模型往往需要具备记忆能力，以便捕捉时间上的长远依赖关系。
传统大模型：大部分传统的大模型通常不需要显式地处理时间顺序，除非其应用本身涉及时间序列（如视频分析）。例如，语言模型处理的是文本的上下文关系，但文本的处理不总是严格按照时间顺序。

3. 模型的处理方式：

时间序列模型：这些模型特别适合捕捉时序数据中的季节性、趋势性和周期性变化等特征。因此，很多时间序列模型包括季节性组件和趋势组件，可以处理周期性变化（例如，某些商品的销售数据会在每年的某些时间点有所波动）。
传统大模型：通常关注全局的特征学习，例如，语言模型会学习语法结构和词汇关系，图像模型会关注像素间的空间关系等，重点不在捕捉周期性和时间相关性。

AI工作负载对 Infra 的要求

幻灯片描述了AI工作负载的不同阶段（数据准备、分布式训练、模型调优、推理）以及每个阶段所需的基础设施类型和时间要求。

不同阶段的任务需要不同规模的计算资源，且根据任务的复杂性和时间要求，可能需要本地部署、公共云或边缘计算环境。推理阶段特别关注延迟和吞吐量的需求，通常要求更高的实时性。

大模型对算力的需求

幻灯片展示了基础模型的训练过程是如何与数据量、模型参数和计算需求紧密相关的。

随着数据量和模型参数的指数增长，所需的计算资源也呈指数级增长。通过该公式，可以看出，训练大规模的基础模型需要巨大的计算能力，这也解释了为什么随着模型规模的增大，所需的计算能力和硬件资源需求也随之提高。

Vela 系统

幻灯片展示了Vela系统的各个阶段发展。

从2022年到2024年，Vela系统逐步增强了网络性能、硬件配置和可用性。

2022年主要集中在基本的单区可用性和网络支持，
2023年加入了更高效的RDMA网络和更密集的机架配置，
2024年进一步发展为多区支持、更高的GPU网络带宽和多租户解决方案。此外，Vela还可以在客户现场进行部署，支持高端的H100 GPU。

Vela系统与云平台&HPC平台的比较

Vela 系统、虚拟化平台和 HPC 的差异：

特点	Vela 系统	虚拟化平台	HPC 平台
设计目标	专为 AI 和深度学习设计，优化 GPU 加速和分布式训练	提供硬件资源的虚拟化，支持多租户和灵活资源分配	提供极高性能的计算能力，专为大规模并行计算设计
硬件优化	专注于 GPU（如 H100）、高带宽低延迟网络（如 RDMA、RoCEv2）	通过虚拟化技术将硬件资源分配给多个虚拟机或容器	高性能计算节点、加速器（如GPU）、快速网络（如 Infiniband）
计算类型	高性能 AI 计算（深度学习模型训练和推理）	通用计算，适用于多种类型的工作负载	高度并行计算，处理科学计算、模拟等计算密集型任务
资源管理	高度集成的AI训练集群和多租户支持	支持多种虚拟机/容器和资源的动态分配与管理	集群管理，优化计算资源的分配，通常有专门的调度器
应用场景	AI训练、推理、深度学习、基础模型	云计算、开发/测试环境、Web服务、容器化部署等	科学计算、工程仿真、大数据分析、天气预测等
可扩展性	支持大规模并行计算和动态扩展	支持灵活的资源分配和弹性扩展，适合多样化需求	可扩展至大规模集群，适合大规模计算任务

总结：

Vela系统专注于为AI任务（特别是深度学习）提供优化的计算资源，适合高效训练和推理，尤其是大规模AI模型的计算集群。它具有高带宽、低延迟的网络连接和GPU支持，适用于特定的AI工作负载。
虚拟化平台更注重灵活性和资源共享，适用于多租户环境，允许多个虚拟机/容器共享硬件资源，主要面向通用计算需求。
HPC平台主要用于计算密集型的科学和工程计算任务，强调大规模并行计算，提供极高的计算能力，适合需要大量资源的传统科学计算和数据分析任务。

Vela AI 系统设计原则

Vela系统的设计目标是通过高效的以太网网络和灵活的云架构来优化性能，同时确保能够支持AI工作负载的整个生命周期。

系统设计考虑到了操作敏捷性和可扩展性，使其能够随着需求的变化进行弹性扩展。此外，Vela系统还特别关注能效，在功耗、空间使用和冷却方面进行了优化，以确保高效和环保的运行。

===

性能 (Performance)
- 通过以太网网络实现最先进的性能。
- 支持 AI 工作负载的整个生命周期。
云灵活性 (Cloud flexibility)
- 提供操作的敏捷性。
- 可弹性扩展，支持系统的增长和部署。
功耗、空间和冷却效率 (Power, Space, Cooling efficiency)
- 优化功耗、空间使用和冷却系统，以提高系统的整体能效。

图示：该图展示了Vela系统的架构，包括机架、节点、和机笼的布局，并标出了高速以太网连接（如 2x100Gbps），以确保高效的通信和数据流动。

Vela 系统架构

Vela 系统的架构强调高可用性、冗余设计和灵活的计算资源管理。通过双端口网卡、多层网络交换机、分层存储等设计，确保了系统在处理大规模 AI 和深度学习任务时能够提供高性能和高可靠性。这些设计增强了网络的容错能力，优化了数据流动，适应了大规模计算任务的需求。

===

计算以虚拟机（VMs）形式暴露
- Vela 系统中的计算资源以虚拟机的形式进行暴露，方便灵活调度和管理资源。
双端口网卡
- 系统中的每个计算节点使用双端口网络卡，增强了网络连接的冗余性和带宽。
每个端口连接到不同的机架顶端交换机
- 每个网卡端口连接到不同的机架顶端交换机（TOR），以提高网络的可靠性和数据传输效率。
多个骨干交换机（Spine switches）
- 系统架构中部署了多个骨干交换机，确保更高的网络吞吐量和可扩展性。
数据包可以通过多个路径从源到目标传输
- 系统支持网络中数据包在多条路径上传输，增强了网络的容错能力和传输效率。
分层存储和文件系统
- 采用分层存储系统，以优化数据存储和访问效率，并支持高效的文件管理。

IBM Vela 计算节点

Vela计算节点是为高性能计算、深度学习训练和推理优化的计算资源，每个节点具有强大的硬件配置，包括多个高性能GPU（如A100）、大容量内存和高速存储。客户可以通过虚拟系统实例（VSI）购买这些节点，并获得与IBM Cloud生态系统的集成，进一步提升灵活性和扩展性。

===

每个物理节点配置：
- 2个24核处理器
- 8个A100 80GB GPU
- 4个3.2 TB NVMe OPAL驱动器
- 1.5 TB DDR4内存
- 2个2x100 Gbps CX-6 网络接口卡（NIC）
客户购买的VSI配置：
- 80个虚拟CPU（vCPUs），1280GB内存
- 4个3.2 TB NVMe实例存储驱动器
- 4个100 Gbps SR-IOV虚拟网络接口卡（vNICs）
销售方式：
- 这些配置以“完整系统VSI”销售，整个系统由单一租户购买。
VSI使用说明：
- 作为VSI（虚拟系统实例）使用，客户可以访问更广泛的IBM Cloud生态系统。

AI智算与云平台

值得思考的是：IBM Vela 系统的商务模式和虚拟化平台（VMware、私有云等）是非常相似的，AI平台在企业IT的存在方式，究竟是独立的独立的高性能单元，还是和通用IT相耦合的综合平台，这个问题值得长期关注和思考。

IBM Cloud Vela (2021-2022)

IBM Cloud Vela 在2021到2022年期间，提供了接近裸机性能的云计算服务，特别在AI训练和深度学习任务中优化了GPU资源的利用率，保持了极低的虚拟化开销，确保了高效的计算性能。

===

裸机性能在云中 (Bare-metal performance in the cloud)：Vela 系统提供接近裸机的计算性能，适用于需要高计算能力的工作负载，特别是在AI训练和深度学习任务中。
虚拟化开销小于5% (< 5% virtualization overhead)：Vela 系统通过高效的虚拟化技术，保持了极低的虚拟化开销，确保性能接近物理裸机资源。
GPU效率超过90% (90%+ GPU efficiency)：Vela 系统实现了高达90%以上的GPU计算效率，最大化了GPU资源的利用率，尤其是在AI和深度学习任务中。

对AI平台性能的思考

综合的虚拟化云计算平台提供丰富、灵活、高可用的IT基础设施服务，但虚拟化层的资源消耗也非常惊人，这是软件定义工程的必然结果，然而在AI计算平台中，当前的核心关切是对极致性能的需求，所以更希望提供轻量化的软件定义能力，可以预想到的是：随着AI与业务系统的深度整合，软件定义的AI能力也将促成厚重的软件层技术栈。

模型训练与算力

数据增长 (Data Growth)：从2015年到2024年，数据量以指数级增长，尤其在2022年迎来快速增长。
参数增长 (Parameter Growth)：随着数据量的增加，参数数量也在快速增长，2022年出现显著提升。
计算需求增长 (Compute Growth)：为了支持如此大规模的数据和参数，所需的计算能力也呈指数级增长，尤其是到2022年时，计算需求显著上升。
结论：
- 需要至少2倍的计算资源（Need at least 2x more compute）；
- 并且在6个月内需要至少4倍的性能提升（at least 4x higher performance in 6 months）。

Note

企业测的模型再训练短期来看，能真正落地的不多，因为性价比可能并不如RAG来的高效，但长期RAG也讲造成企业知识库的分散，是否存在一种模式：基础模型+分库RAG增强问答+阶段性微调，来循环、多代次更新企业智能体。

IBM Cloud Vela (2023)

提高工作负载性能至少2倍
- 相较于Vela第一阶段，第二阶段旨在提高至少两倍的工作负载性能。
双倍容量
- 第二阶段将系统的计算能力和容量提高到原有的两倍。
提升操作效率2倍
- 优化了系统操作，使其在效率上提升至少两倍。

究竟系统性能提升是如何实现的呢？

GPU Direct RDMA 在 IBM Cloud 加速 Vela

IBM Cloud 计算、SDN 和底层网络优化以支持 RDMA 和 GDR
- 该系统优化了计算、软件定义网络（SDN）和底层网络，以支持远程直接内存访问（RDMA）和 GPU 直接 RDMA（GDR）。
改进：
- 2到4倍的网络吞吐量 (2-4x network throughput)：提高了网络数据传输的效率，使得多个节点间的数据传输速度大幅提升。
- 6到10倍的网络延迟降低 (6-10x network latency)：优化了数据的传输路径，显著减少了网络延迟。
高效训练模型：
- 成功训练了Granite-20B和其他模型，并将效率提升了2倍，特别是在使用 Watsonx 代码助手（Watsonx code assistant for Z）时。

图示：左侧是传统的节点间通信架构，右侧是启用了 GPU Direct RDMA (RoCE/GDR) 技术的优化架构，展示了如何通过低延迟和高吞吐量的网络连接加速计算和数据交换。

TCP vs GDR 性能对比

GDR (GPU Direct RDMA) 显示出比 TCP 更高的性能，尤其在大规模GPU集群和处理大模型时，GDR能够提供更高的带宽和更低的延迟。

具体来说，在32个GPU上，GDR的性能比TCP好1.4到2.6倍，适用于需要高吞吐量和低延迟的计算任务，特别是在大规模深度学习模型的训练中。

===

测量的聚合带宽 (Measured Aggregate Bandwidth)：
- 图1 显示了不同通信协议（GDR、RoCE 和 TCP）的性能对比，随着数据集大小的增加，GDR 和 RoCE 提供了明显更高的带宽，尤其是在处理大规模数组时，GDR表现最为优秀。
全减少缩放性能 (All Reduce Scaling Performance)：
- 图2 展示了使用 GDR 协议和不同数量的 GPU 时的性能。随着 GPU 数量的增加（256、512、1024 和 1752 GPUs），GDR 协议在处理大数据时提供了更高的带宽。
迭代时间改进 (Iteration Time Improvement)：
- 图3 展示了在32个GPU上，TCP和GDR的迭代时间比率。对于不同的模型（如 GPT2、BERT、T5、Granite等），GDR比TCP快1.4到2.6倍，表明GDR在大规模训练中能够显著加速模型训练。

分布式数据并行与完全分片数据并行的对比

在分布式数据并行中，整个模型的副本在每个GPU上存在，并通过全减少（All reduce）操作更新模型的权重。
在完全分片数据并行中，模型被分割为多个片段，每个GPU仅处理一部分，并通过全聚合（All Gather）和减少散播（Reduce Scatter）操作协调模型的计算。这种方法适用于处理非常大的模型，可以减少单个GPU的负载，适应更大规模的模型训练。

===

分布式数据并行 (Distributed Data Parallel) - 模型适合在GPU上运行

模型分布：每个GPU上都有一个完整的模型副本，数据被分割并在每个GPU上处理。
计算过程：每个GPU进行前向计算（Forward Compute）和反向计算（Back Compute）。
通信：每个GPU在训练后，通过全减少（All reduce）操作交换权重更新（Weight update）。
网络数据量：在网络上的数据量大约是2N（其中N是GPU的数量）。

完全分片数据并行 (Fully Sharded Data Parallel) - 用于大模型

模型分片：将模型切分为多个片段（Shard1, Shard2, ..., ShardN），每个GPU只处理一个片段。
计算过程：每个GPU进行前向计算（Forward Compute）和反向计算（Back Compute），但是每个GPU仅处理一个模型片段的计算。
通信：每个GPU通过全聚合（All Gather）和减少散播（Reduce Scatter）操作与其他GPU交换数据，以完成模型的更新。
网络数据量：网络上的数据量大约是3N（与GPU数量相关）。

模型推理过程的并行机制

模型推理过程也可以采用类似的并行和分片机制，尤其是在处理大型模型时。尽管训练过程和推理过程的需求和方法有所不同，但在推理时也可以通过多种并行化技术提高效率。以下是几种常见的推理并行和分片机制：

1. 数据并行 (Data Parallelism)

概念：在推理过程中，数据并行是将输入数据拆分为多个小批次，然后将它们分别送入不同的计算单元（如多个GPU或多个节点）进行处理。每个计算单元（GPU）独立计算它自己的数据子集，并生成部分推理结果。
应用：当批量推理数据较大时，数据并行能够有效地分散计算负载。例如，在批量图像分类时，可以将多个图像分配到不同的GPU上同时处理，最后聚合推理结果。
优势：可以加速推理过程，适合处理大规模输入数据。

2. 模型并行 (Model Parallelism)

概念：模型并行是将模型本身拆分为多个部分，并将这些部分分配到不同的计算单元进行并行计算。每个计算单元处理模型的一部分计算并生成部分输出，最后合并这些输出生成最终结果。
应用：这种方法在模型非常大，单个设备无法存储完整模型时尤为重要。例如，对于极大的神经网络，可以将模型的不同层或模块分别放置在不同的GPU上进行计算。
优势：适用于非常大的模型，能够在内存有限的情况下执行推理。

3. 流水线并行 (Pipeline Parallelism)

概念：流水线并行将模型分解为多个阶段（如多个层或模块），并且每个阶段可以在不同的计算单元上运行。每个计算单元按顺序执行各自的计算任务，并将输出传递给下一个阶段。每个阶段的计算可以同时进行，因此不同的输入数据可以通过流水线并行处理。
应用：在深度学习推理中，特别是在大规模神经网络中，流水线并行可以在多个GPU或节点上并行执行不同阶段的推理。
优势：通过分阶段并行化，能够显著提高推理效率，尤其在多层神经网络中，能够避免各层计算的瓶颈。

4. 混合并行 (Hybrid Parallelism)

概念：混合并行结合了数据并行、模型并行和流水线并行的优势，通常用于处理非常大的数据集和模型。这种方法可以根据任务需求灵活地选择不同的并行策略，最大化硬件资源的利用率。
应用：当模型和数据都非常庞大时，混合并行可以通过同时利用多种并行化策略加速推理过程。例如，在推理时，一部分模型采用模型并行，另一部分采用数据并行，同时通过流水线方式处理不同的推理任务。
优势：能够应对复杂的计算需求，适用于处理超大规模的模型和数据。

5. 分布式推理 (Distributed Inference)

概念：分布式推理是在多个计算节点或数据中心中分配推理任务，通过网络进行协作计算。每个节点独立执行一部分推理任务，最终将结果聚合起来。
应用：对于需要高吞吐量或低延迟的推理场景，分布式推理能够加速模型的响应时间，特别适用于实时推理或需要快速响应的在线服务。
优势：可以扩展到大规模的分布式环境，支持多节点、多GPU的协作，从而提高推理速度和处理能力。

总结：

在模型推理过程中，确实可以采用类似于训练过程中的并行和分片机制，通过数据并行、模型并行、流水线并行等方式来优化推理性能。对于极大规模的模型，采用模型并行和分片方法是提高推理效率的关键。此外，混合并行和分布式推理也能在大规模数据和计算环境中提供显著的加速。

电力、空间和冷却效率

Vela 系统架构在容量增加后的变化：
- 每个机架中的服务器数量翻倍，但在同一空间、功率和网络配置下进行布局。
- 采用了“超配”（Overcommit）功率策略：部署了功率限制，以应对电源设备故障的情况。若电源供应单元（PSU）或电源分配单元（PDU）发生故障时，将限制功率使用。
- 这种策略的目的是避免始终使用额外的功率来应对故障，而是确保在故障时只需使用一半的功率，这样可以减少额外的功率需求。
电力中断（Power break）：
- 当电源供应单元（PSU）发生故障时，电力中断会在1.5秒内发生。
- 通常，电源分配单元（PDU）具有5秒的容错时间。
图示：
- 展示了Vela系统架构在增加容量后的布局，多个机架的服务器节点连接，并在每个机架顶部放置了交换机，确保电力和网络的高效分配。

改进的诊断与操作

为了应对AI服务器故障率高于传统云系统的挑战，Vela系统通过引入自动化诊断与操作工具，如警报和故障组件快速检测与隔离工具，显著提高了系统的维护效率。这些改进使得故障识别和解决的时间缩短了超过一半，增强了系统的可维护性和稳定性。

===

AI服务器故障率较传统云系统高
- 问题：
  - 组件故障
  - 性能下降
- 解决措施：
  - 警报：通过设定警报机制，及时发现潜在问题。
  - 快速检测与隔离问题组件的工具：提供针对问题组件的快速检测与隔离工具，减少故障排除时间。
- 效果：
  - 这些自动化措施将识别和解决这些问题的时间减少了一半以上。

图示：展示了Vela计算节点的架构，包含CPU、GPU、存储、网络接口等，展示了如何高效配置硬件资源以支持高性能的计算。

Cite

与传统云平台相比，AI服务器的故障率呈现出不同的特点。传统云平台通常采用虚拟化技术，将多个虚拟机部署在物理服务器上，通过资源隔离和迁移来提高可靠性。然而，虚拟化层和宿主机内核的额外复杂性可能引入新的故障模式。但通过内核隔离硬件故障、热迁移规避故障隐患，以及监控故障率并主动下架不良厂商机型等手段，云平台的故障率可以被优化至接近零的水平。 developer.aliyun.com+1[1]

在AI服务器领域，故障率的高低取决于硬件配置和运维管理。由于AI工作负载对计算资源要求高，通常配置高性能的GPU等硬件。然而，GPU的故障率相对较高，特别是在大规模应用场景下，故障风险也随之提升。因此，针对AI服务器的故障检测和自愈能力显得尤为重要。通过AI技术对服务器运营数据进行实时分析，实现对CPU、内存、硬盘、PCIe等设备的自动化预警，能够将服务器故障诊断的明确化率提升至95%以上。

GPU 系统故障处理机制

为了应对GPU系统中的硬件和软件故障，Vela系统引入了多种监控与恢复机制。

通过自动化的健康检查和故障响应（如警报和任务重启），能够及时发现并解决潜在问题，确保系统运行的稳定性和高效性。同时，与调度器的集成优化了资源的分配，避免了因故障或性能下降的资源影响整个工作负载的执行。

===

故障类型	根本原因	缓解措施
硬件故障（主机崩溃）	GPU HGX 主板故障、内存 DIMM 故障、NVLink/交换机故障	Slack 警报（主机崩溃时），自动重启虚拟机，自动重启任务
细微硬件故障（无主机崩溃）	GPU 故障，GPU HBM 内存损坏，PCI-E 链路故障，端口故障，电源故障	Slack 警报（主机、GPU、其他关键组件故障），基于主机 BMC 日志的警报，增强的指标收集（通过 Autopilot）
软件故障	PCI-E 链接退化，CUDA 内存分配错误，HBM 内存行映射	检查 PCI-E 链接，基于应用程序日志的警报，定期重启虚拟机

Vela 数据架构

AI 存储的思考

针对AI的存储方案，通常采用对象存储、分布式文件存储和本地存储的组合。

每种存储方式有其特定的应用场景，并通过自动化同步技术与云对象存储（COS）保持一致。为确保存储层之间的数据迁移对用户透明，同时避免影响系统性能，需要开发弹性的存储架构，并提升数据迁移的自动化和透明度。

===

对象存储 (Object Storage)：
- 用途：大多数数据的来源。
- 关键驱动因素：成本、规模、性能。
分布式文件存储 (Distributed File Storage)：
- 用途：用于“热”数据的缓存。
- 应用：输入数据、检查点、临时数据。
- 自动化同步到COS：自动与云对象存储同步。
本地存储 (Local Storage)：
- 用途：用于频繁变化的数据缓存（如KV缓存）。
- 应用：缓存模型状态，支持多租户。
- GPU直接存储：直接与GPU进行数据交互。
- 自动化同步到COS：自动与云对象存储同步。

研究挑战：

使数据在各个存储层之间的迁移对用户透明：避免用户感知数据在不同存储层之间的迁移。
避免干扰作业：确保数据迁移不影响网络和计算性能。
使分布式文件存储（DFS）层具有弹性：根据需求动态调整存储层，保证资源的灵活性。

Note

文中对AI存储面临挑战的总结，值得软硬件供应商一起思考，例如：

Alluxio 充当计算应用和底层存储系统之间的桥梁，将数据从存储层移动到离应用程序更近的位置，简化了数据访问过程。应用程序通过连接到 Alluxio，可以访问底层存储系统中的数据，而无需关心数据的实际存储位置或迁移过程。
DPU 能卸载专用数据的计算过程，结合GDR 访问，能有效改善网络传输和计算性能。

传统高性能存储系统的挑战

存储系统架构：
- 读操作：从 NFS 读取输入数据用于训练。
- 写操作：将检查点数据写入 云对象存储。
- 输入数据量：约 1TB，用于训练。
- 检查点数据：每个检查点数据大小为 100GB，每几个小时进行一次检查点存储。
主要问题：
- 写操作：检查点写入时间随着模型大小的增长而线性增加。例如，50B 参数的模型写入时间大约需要 3 到 5 分钟。
- 读操作：从 NFS 读取输入数据逐渐成为训练过程中的瓶颈。
- POSIX 文件系统：共享命名空间，强一致性语义对于 AI 应用来说可能会带来挑战。

IBM Storage Scale

引入 IBM Storage Scale 后，Cloud Vela 提供了更高效的存储和计算资源管理。通过使用 IBM Cloud 的专用存储集群和块存储，解决了存储的成本效益问题，并通过动态扩展 GPU 计算集群来满足高效训练和计算的需求。

===

架构介绍：
- GPU 计算集群：包括多个应用（如 AI/DA/HPC 平台）和 Cloud-Native Scale 客户端集群（CNSA）。
- IBM Cloud 存储集群：使用 IBM Cloud 的专用存储集群，集成了 Acadia（Ceph）块存储。
- Cloud-Native Scale Access (CNSA)：部署于 GPU 计算集群，支持超过 200 个节点。
- GPU 节点池：支持动态扩展与收缩，专门为 Quorum 提供了 CPU-only 节点池。
存储解决方案：
- IBM Cloud Object Storage：作为大型共享且具成本效益的数据存储库，采用双层架构：AFM 无缝地将数据从对象存储移动到文件系统（FS）。
- IBM Cloud Block Storage Acadia：用于高效的块存储，支持高速文件系统。
- 共享 POSIX 文件系统：按需提供。
- 检查点和训练数据存储：一个卷用于检查点数据，另一个卷用于训练数据。
  - 可以存储大约 10 天的检查点数据。
  - 可以容纳完整的训练数据集。

主要特点：

GPU 计算集群的动态扩展：可以根据需求扩展或缩小 GPU 节点池。
高效的存储架构：利用 IBM Cloud 的对象存储和块存储提供大规模、成本效益高的数据存储解决方案。
高效的检查点管理和数据存储：通过共享 POSIX 文件系统和适当的存储卷划分，管理大量的训练数据和检查点。

Note

从左侧的示意图来看，IBM Storage Scale 底层是有2套存储的，对象存储和块存储，通过块存储挂载文件系统，以实现高效数据临时写入，再通过网关（AFM）将块存储转化为对象存储。

测试结果

引入 IBM Storage Scale 后，检查点时间显著缩短，输入读取时间更加稳定，迭代性能的波动减少，尤其是在大模型训练中，性能和效率得到了提升。

===

检查点时间的改善：
- 检查点时间与云对象存储（COS）相比，缩短了3倍。
- 例如，50B 参数的模型，在 IBM Storage Scale 上完成一个检查点大约需要 50秒，而在 COS 上则需要 3分钟。
输入读取时间：
- 输入读取时间在 IBM Storage Scale 上更加稳定，提高了整体性能的一致性。
迭代时间（NFS vs Spectrum Scale）：
- 左侧图示 Granite-13B-4K 使用 NFS 的迭代时间 显示出较大的波动，步骤时间从 9 秒到 6 秒不等，且 波动达到50%。
- 右侧图示 Granite-8B-4K 使用 Spectrum Scale 的迭代时间 显示出更稳定的结果，步骤时间保持在 4.8 到 5.2 秒 之间，波动 低于10%。
作业重启与性能一致性：
- 作业重启 不再需要很长时间来达到稳定状态。
- 步骤时间波动 从 50% 降低到 10% 以下。