NVIDIA：GPU作为数据访问引擎的计算架构设计

关键要点

• • 新的架构（BaM）可以将GPU转变为数据访问引擎，以解决大规模数据集无法放入内存的问题。
• • SCADA是一种新的接口，可以让应用程序轻松地与分布式存储系统交互，并提高数据处理效率。
• • GPU和NVMe之间的瓶颈限制了性能提升，需要更多的高速存储设备来支持高性能的数据访问。
• • 通过GPU初始化的动态请求和高效的NVMe存储技术，可以实现更高的数据吞吐量和更低的成本效益

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-1

趋势

随着场景规模扩大和拓展带来的新问题：

• • 扩展的数据集无法适应单个 GPU 或多个节点的内存 → 使用 NVMe。
• • 无法通过加载和存储访问所有数据 → 需要新的 API。
• • 新的工作负载在数据访问与计算之间存在瓶颈。
• • 键值/对象存储作为一种访问数据的方法正在获得关注 → 针对对象的定制 API。
• • 应用程序需要跟踪的数据量过大 → 无服务器架构，配备数据集服务和编排工具。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-2

在扩展数据上出现的新问题

GPU 不仅仅是一个计算怪兽，它也变成了一个细粒度的数据访问引擎。使用 O(100K) 线程来加速计算或 IO。

• • 无法通过加载和存储访问的庞大数据（数据重力 Data gravity）
  • • 分区、缓存、通信复杂性
  • • 规模化的错误处理问题
  • • NVSHMEM 用于内存；需要更适合内存+存储的方案 → 需要新的 API 系列来覆盖任意位置的数据
• • 访问由 GPU（或 CPU）发起
  • • GPUDirect 异步内核发起的存储，不仅是 GDS
  • • 示例：基于读取节点数据的图遍历
• • 海量访问量，每个 GPU 线程超过 1 次访问 → 细粒度实现最大收益

右侧图解: 描述了 GPU 与存储设备通过 PCIe 通道连接的问题，重点在于如何高效传输 O(100K) 的请求/响应通过 PCIe 引脚。

关于 NVSHMEM（Nvidia Shared Memory） NVSHMEM 是一种高性能的分布式内存库，专为 GPU 环境下的并行计算设计。它由 NVIDIA 提供，支持在 GPU 上实现共享内存编程模型，用于在多个 GPU 之间高效地共享和传递数据。 核心概念：

1. 1. 共享内存模型：
   • • NVSHMEM 提供了一个共享内存抽象，允许不同 GPU 直接访问共享内存中的数据，而无需通过传统的 CPU 中介操作。这种模型非常适合需要频繁通信的并行计算场景。
2. 2. 基于 RDMA 的通信：
   • • NVSHMEM 通过远程直接内存访问 (RDMA) 技术，绕过 CPU 直接在 GPU 之间传递数据，从而大幅降低延迟并提高带宽。
3. 3. 与 OpenSHMEM 的关系：
   • • NVSHMEM 的设计灵感来自 OpenSHMEM，它是 CPU 上广泛使用的一种共享内存库。因此，使用者如果熟悉 OpenSHMEM，能够更快上手 NVSHMEM。
4. 4. GPU 间高效协作：
   • • 它特别适合在多 GPU 系统（如 NVIDIA DGX 系列服务器）中进行大规模并行数据处理，例如深度学习、图计算和科学模拟。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-3

新计算场景催生新编程模式

快速、稀疏访问海量数据--快速要求高并行计算，稀疏访问对热数据管理提出挑战。

• • GPU 不仅是一个计算怪兽，还是一个数据访问怪兽
• • 每个 GPU 线程（O(100K)）都有大量的细粒度访问需求
• • 对于巨大的数据集，最终无法继续加载/存储，需要支持无限大小数据内存/存储的新 API
• • NVMe 带来比 HBM/DRAM 更具吸引力的总拥有成本 (TCO)
• • 让 1T 规模的图边问题可以在只有 1 个 GPU 或节点的情况下解决
• • 缓解“内存不足”问题管理，提升生产力

右侧图示4种数据密集性计算场景，括号内为数据集体量，

Note：说明新计算范式的特征：高并行+内存密集型，反观当前内存应用面临的挑战：2D-DRAM难继续缩小制造尺寸，2.5D的HBM良品率低、价格高，难以支撑计算场景需求，关键是想说明使用NVMe介质来扩展内存。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-4

对上述4种场景的进一步介绍。

应用场景：

• • 图神经网络 (GNNs) – 图 + 特征存储
  • • 图或数据均无法容纳到 GPU 中（1T 边规模）
  • • 高价值的实体和关系嵌入
  • • 推荐系统和恶意行为检测系统的关键部分
  • • GNN 在嵌入类型上提高了准确性
• • 向量搜索/向量数据库 (vectorDB) – 向量存储
  • • NeMo Retriever，基于 NVIDIA RAFT 的 RAG-LLM
  • • 数据去重以准备支持数万亿令牌级 LLM 基础训练
  • • GNN 嵌入与大规模键值服务相结合，为 LLM 微调提供支持
• • 可用的图分析工具 (cuGraph):
  • • 个性化 PageRank，基于大型图的社区检测
  • • 为 GNN 模型提供分布式采样和训练

共同需求：简单管理大数据集

• • 避免 OOM（内存不足）错误
• • 通常需要缓存、分区，多 GPU/多节点通信
• • 需要跨每个应用创建统一的通用解决方案

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-5

图示新计算场景应用分层示意。

图示应从左到右进行拆解，左侧是业务系统，存储的数据经过cuGraph神经网络系统，存储到右侧高维向量数据库中，作为推荐系统的数据大脑。

通过使用 cuGraph 和嵌入向量数据库，将图神经网络（GNN）的训练和推理流程进行了模块化设计，显著降低了内存管理复杂性。数据从存储系统到推荐系统的整个流程实现了高效分层，支持了大规模图计算的可扩展性和维护性。这种设计尤其适用于需要高性能嵌入生成和查询的推荐系统。

关于cuGraph cuGraph 是 NVIDIA RAPIDS 开放式生态系统的一部分，是一个用于 GPU 加速图计算的高级库。它提供了一系列 API 和工具，能够帮助开发者高效地处理图形数据（如节点和边），从而支持机器学习、深度学习以及数据科学领域的大规模图计算任务。 典型应用场景：

1. 1. 推荐系统：
   • • 通过嵌入生成、用户-物品关系分析，构建高效的推荐引擎。
   • • 使用 cuGraph 的 GNN 框架，进一步提升推荐系统的个性化性能。
2. 2. 社交网络分析：
   • • 进行社区检测、影响力传播分析等，支持超大规模的社交网络图处理。
3. 3. 金融风控：
   • • 分析复杂的交易网络，发现异常交易和潜在风险。
4. 4. 知识图谱：
   • • 处理大规模知识图谱数据，支持实体关系推理和知识发现。
5. 5. 科学计算：
   • • 分析分子结构图（如药物开发）或大型物理模拟中的相互作用图。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-6

GPU 发起的数据访问架构使得 GPU 能够自主管理数据请求，从而避免传统的 CPU 中介，提高了并行数据处理效率。通过 GDA KI 存储和 NVMe 技术，数据请求可以在 GPU 内核中直接生成、提交、处理并消费。该架构不仅优化了数据 IO 性能，还通过可信的服务器环境确保了数据安全性，是高性能计算和大规模数据处理的核心支持技术。

关于GDA KI存储 GPU 主导的 IO 操作：

• • GDA 是 GPU Direct Access 的缩写，表示 GPU 可以直接访问存储数据，而不需要 CPU 的中介作用。
• • KI 是 Kernel Initiated 的缩写，说明 IO 操作是由 GPU 内核发起和管理的。

技术优势：

1. 1. 性能提升：
   • • 减少 CPU 参与，提高数据传输速度。
   • • 通过直接访问存储设备，实现更低的 IO 延迟。
2. 2. 资源利用最大化：
   • • 避免 CPU 成为瓶颈，充分利用 GPU 的并行计算能力。
   • • 支持大规模数据处理和训练任务，适应 PB 级别的数据需求。
3. 3. 扩展性：
   • • 可在多 GPU 系统或分布式集群中扩展，为大规模任务提供支持。
4. 4. 安全性和可信性：
   • • 请求在受信任的服务器中处理，确保数据访问的安全性。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-7

重新思考现代数据中心的接口

提出新的数据中心概念：SCADA（scaled accelerated data access）

如何理解呢？

• • 规模 (Scale)：为数据访问提供单一 API，与规模无关

支持之前无法支持的情况，例如在一个节点中处理 10TB 数据，避免 OOM（内存不足）问题

在数据集规模和计算集群规模上透明扩展

• • 更高抽象 (Higher abstraction)：“无服务器访问” 是现代数据中心的方向

前端：处理缓存，避免分区，支持多 GPU/多节点之间的通信

后端：应用访问数据集 X，将数据存储位置和方式的细节下放

数据平台工具可管理数据策展、本地化、分片和分阶段

利用 GPU 线程、内存管理和拓扑优化通信实现加速

• • 易用性 (Easy enablement)：提供低级接口，不影响应用层设计
• • 从根本上降低 TCO（总体拥有成本，Fundamentally-low TCO）：减少存储数据的成本
• • 大量数据 → 巨大内存需求 → 高成本
• • 对于计算复杂性较低的应用，仅使用 HBM（高带宽内存）作为内存，而非计算
• • 廉价 NVMe 存储使数据中心更高效

Note：早就听说Nvidia要进军CSPs市场，SCADA 下一代数据中心设计思想在这张胶片中，或许能窥探出一二端倪。

• • 更加重视节点内数据访问的缓存设计，避免因内存空间有限导致的分层内存，从而提高节点内的数据访问效率，同样对跨节点数据访问（通信）也提出要求；
• • 数据存储节点的计算型增强，将通用、常见的数据计算（压/解缩、加/解密、重删等）下沉到存储节点；
• • 数据平台加持自动标签、分层等功能，实现更高效的管理；
• • HBM的需求仍然在，并非短期市场；
• • 推广NAND在数据中心的使用。

SCADA 是Nvidia 在新型数据中心上的存储系统顶层设计。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-8

BaM 和 GIDS 是面向现代数据中心开发的两个 GPU 驱动的存储访问原型，强调了高吞吐量、易集成和高效 IO 管理。通过模板化的 C++ 库和缓存机制，这些原型降低了大规模 GPU 线程的 IO 复杂性，为高性能图计算和数据密集型任务提供了先进的存储解决方案。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-9

瓶颈在于 NVMe 和引脚带宽，而非 GPU

图的上半部分示意GPU直通模式下（BaM）的数据访问路径，经历：

GPU中的数据处理 -- 缓存数据 -- IO处理 -- NVMe SSD落盘（没有CPU调度参与）

下图示意每个环节的峰值IOPS和带宽：

• • 计算端IO和带宽是实际业务，反馈到缓存上，有明显的放大，这是因为实际计算的数据流往往仅为缓存中的一部分。凸显当前计算场景对内存的挑战：并行计算能力不断增加，但尚未出现有效的热数据调度机制，以满足计算侧性能，从而造成巨大的性能缺口（浪费）。
• • 由于远程存储的访问时延和片上通信技术受限，IO缓冲区和NVMe设备上的性能是逐渐收窄的。

Note：材料将计算系统的低效归因于NVMe设备或PCIe接线引脚，鹏弟认为这可能是不太准确的，或者换个说法，PCIe引角数量再怎么加也跟不上计算器的处理速度。

首先逻辑处理器电气设计（制造工艺）比存储器（RAM）要领先，后者需要持续供电（Fresh）以保留数据状态；

至于持久化的存储（NAND为例）更是要经历落盘等长周期操作。

核心还是要优化数据的IO路径，要么缩短IO路径，强化存储端计算能力，即计算型存储；

要么优化IO缓冲区、内核缓存（Page Cache）等热数据调度算法，只移动需要的数据。

不可否认，连接数据盘的PCIe接口，通道（引脚数量决定）和带宽是当前系统性能受限的客观原因。

更多关于服务器上PCIe引脚分配和设计，可参考黄亮总4年前整理的文章：

• • 直联还是交换？Intel、AMD服务器NVMe SSD IO拓扑速查手册

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-10

配图右侧说明：

基于BaM GPU直接访问NVMe设备，能在4块PCIe Gen4 X 4 NVMe 设备上，跑出超过 6 MIOPs，23+ GB/s 的 4KB 随机读取性能，达到PCIe通道理论峰值性能。

左侧配图显示：随NVMe设备增加，前期（1-4盘）性能成线性，从 4 个驱动器增加到 6 个驱动器，MIOPs 和 GB/s 略有增长（已不明显）。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-11

BaM 计算框架的适用性

• • GPU 启动，动态，每线程

每个 GPU 线程动态生成并提出自己的请求。

如果提前知道批处理数据大小，可以使用 GPU Direct Storage。

• • 细粒度，高吞吐量

数据大小可以是 4B-4KB。

如果是粗粒度，可以用极少的线程饱和数据引脚。

• • 无限数据大小

无法可靠地将数据完全容纳在 GPU 的高带宽内存中。

如果能容纳，那么可以直接使用加载/存储操作。

• • 数据访问受限

关注数据访问作为瓶颈的问题。

如果计算是瓶颈，许多节点的 HBM（高带宽内存）通常是充足的。

描述了适合 GPU 启动数据处理的几种场景和限制条件。特别强调了细粒度高吞吐的需求、对数据大小的灵活支持、以及在数据访问和计算瓶颈之间的平衡。通过利用 GPU Direct Storage 等技术，可以更好地适应批处理和动态数据请求场景，同时缓解数据访问限制对性能的影响。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-12

BaM (SCADA) 计算框架的优势

• • 扩展性（Scale）

通过将数据溢出到 NVMe 存储，将问题适配到少量 GPU 中。

即使速度稍慢（例如，使用 1 个 NVMe），需要了解您的性能减速阈值。

• • 总体拥有成本（TCO）

在相同性能水平下，与 HBM 或 DDR 相比，NVMe 提供了更高的成本效益。

• • 性能（Performance）

随着优化的深入，性能可能会进一步提升。

性能受到进入 GPU 的 PCIe 带宽和驱动器数量的限制。

NVIDIA：GPU作为数据访问引擎的计算架构设计-Fig-13

为 SCADA 行动起来

帮助推动 GPU 成为数据访问引擎的未来

1. 1. 存储技术人员（Storage technologists）
   • • 提供更多的 IOPs！
   • • 实现通过 PCIe 的细粒度传输。
2. 2. 应用开发者和用户（App developers and users）
   • • 反馈对超出 GPU-CPU 内存容量的更多数据容量需求，用于计算。
   • • 指定感兴趣的服务种类，例如数组（array）、交换（swap）、键值（key-value）、向量数据库（VectorDB）、数据帧（dataframe）？
   • • 提供关于产品栈支持和部署模型的具体细节。
3. 3. 基础架构开发者（Infrastructure developers）
   • • 基于 SCADA 构建，如 NVSHMEM 框架中的实现，例如 Kokkos 性能便携框架。
   • • 探索计算和通信细粒度交错的新途径，例如 LLNL（劳伦斯利弗莫尔国家实验室）。