How to Get Data Between Storage and the GPU at the Speed of Light

CJ Newburn (Distinguished Engineer, NVIDIA GPU Cloud), Vikram Maddimedi (Senior Researcher, NVIDIA Research), Prashant Pralhad (Senior Engineer, NVIDIA GPU Cloud)

目录

1. 核心信息与趋势
   1. 核心信息
   2. 趋势
2. GPU与数据：从计算中心到数据中心
   1. GPU：传统与新兴应用的核心引擎
   2. 应用分类：瓶颈、动态性、粒度
   3. 新型 GPU 涵盖计算中心和数据中心型计算
   4. 数据层次结构
3. 新兴数据密集型应用
   1. 新的应用类别
   2. 大语言模型（LLM）训练
   3. 大语言模型（LLM）推理
   4. Nemo Retriever - 加速 RAG 推理
   5. 向量搜索/数据库
   6. 图神经网络 (GNN
4. GPU数据访问技术深度解析：GPUDirect Storage 与 SCADA
   1. 数据访问技术概述
   2. NVIDIA GPUDirect Storage (GDS) - CPU发起的加速
   3. SCADA - GPU发起的规模化数据访问
5. 生态系统、未来展望与行动倡议
   1. 合作伙伴与认证计划
   2. 下一代存储 (Storage-Next
   3. 行动倡议

---

1. 核心信息与趋势

1.1 核心信息

• NVIDIA GPU 不仅能加速计算密集型应用，也能加速数据密集型应用。
• 新的生成式 AI（GenAI）应用带来了快速变化的新需求，从“将数据为ID加载到我的内存中”转变为“通过 API 访问数据”。
• 存储需求差异巨大且存在细微差别。
• NVIDIA 展望未来，与合作伙伴共同开发和推动领先的技术和系统架构，以应对存储领域的新挑战。

1.2 趋势

当前系统架构中正在出现的一些值得注意的考虑因素：

• 规模化数据集：数据集的规模已经大到无法装入单个 GPU 甚至多个节点的内存中，这导致需要对比 NVMe 加载和直接访问。
• 数据访问方式：无法通过加载和存储来访问所有数据，需要新的数据访问 API，而不是内存映射文件。
• 新工作负载瓶颈：新的工作负载瓶颈在于数据访问而非计算，需要数据访问引擎。
• CPU 存储访问的局限性：当前基于 CPU 的存储访问是受限的，将在新的 GPU 发起的存储抽象下得到改进。
• 键值（Key-value）存储：键值对象存储作为一种数据访问方式正获得越来越多的关注，需要为对象提供自定义 API。
• 数据管理：数据量过大，应用难以追踪，催生了无服务器（serverless）架构、数据集服务和编排。
• 存储提供商的演进：存储提供商正在创建更智能的平台，带来了新的交互方式，例如更粗粒度、带宽/延迟/IOPS的权衡。

2. GPU与数据：从计算中心到数据中心

2.1 GPU：传统与新兴应用的核心引擎

• 对于并发、规模化的工作负载，GPU 的速度远超 CPU。
• 关键挑战：识别并缓解瓶颈，以满足 GPU 的数据需求。
• 避免通过受限的 CPU 产生额外的跳数。
• GPU 缓存和直接 GPU-GPU 通信：
  • PCI-e、CPU->GPUDirect vs. 通过 CPU 的 bounce buffer。
  • 拥有非常宽的到 CPU 和 CPU 内存的路径，例如 Grace-Blackwell 架构。
• 软件开销：RDMA vs. TCP。

2.2 应用分类：瓶颈、动态性、粒度

构建存储解决方案的重点在于理解应用需求。应用可以根据瓶颈和存储访问模式进行分类：

• 瓶颈：
• 计算密集型：如模型训练。
• 数据密集型：如推理。
• 存储访问模式：
• CPU 发起：可预测的、粗粒度的访问。
• GPU 发起：动态的、细粒度的访问。

传统上，GPU 的重点是计算密集型应用。而推理领域的创新爆炸式增长正在推动新技术来填补空白。

2.3 新型 GPU 涵盖计算中心和数据中心型计算

计算密集型和数据密集型应用对 GPU 架构的不同部分提出了要求。下表对比了这两种模式下的关键技术点：

• 计算密集型应用将继续存在，例如模型训练。
• 数据密集型应用正在快速增长，例如推理、检索增强生成（RAG）、向量搜索、大语言模型+图神经网络（LLM+GNN）。

2.4 数据层次结构

数据的位置、访问方式和引用方式构成了复杂的数据层次结构。

• 硬件视角：从本地高速缓存（纳秒级延迟）到远程存储（毫秒级延迟），数据容量从 GB 级别扩展到 PB 级别。
• 软件与抽象视角：从本地加载/存储指令到跨越多节点的复杂通信库（如 NCCL/NVSHMEM），再到针对本地、远程或内存中数据的访问 API。

3. 新兴数据密集型应用

3.1 新的应用类别

• 计算密集型，粗粒度：传统的 HPC 和 AI 训练。
• 数据密集型，细粒度：新兴的 AI 推理、数据分析等。
• 存储访问特征：需要根据不同应用类别来表征其存储访问模式。

3.2 大语言模型（LLM）训练

LLM 训练是大型系统的主要消费者。

• 示例：
• Llama2：70B 参数，2T tokens 数据集，200K 次迭代。
• Megatron-Turing：530B 参数，0.15T tokens 数据集。
• 不同类型 LLM 训练的特点：
• 预训练：初始构建，可能需要数万个 GPU，耗时数月。
• 微调：调整模型。
• 两次计算：例如在推理期间。
• 检查点（Checkpoint）：对于预训练和微调，检查点大小适中且不断减小。
• GPU 数量的选择更多地取决于计算强度，而非数据容量或带宽。

3.2.1 LLM 训练中的存储

LLM 训练的存储特征在集群层面聚合，而在节点层面影响很小。

• 数据移动形式：
• Ingest：流式输入，每个 GPU 约 1 GByte/秒，与模型大小无关。
• Checkpoint：保存/恢复的大小与模型大小成正比（可以是 TB 级别）。恢复的 I/O 可以来自 CPU、本地、远程或对等设备。
• 访问模式：
• Ingest：粗粒度读取。
• Checkpoint：粗粒度写入（从 CPU 发起，耗尽 GPU），粗粒度读取（来自 CPU）。
• 相关技术：
• GPUDirect Storage：用于将检查点直接写入 GPU，以提高性能和能效。
• 网络拥塞管理：通过 Spectrum-X 实现与远程存储的拥塞管理。
• 对象存储：正成为检查点数据的一种日益流行的方式。

3.2.2 LLM 训练的检查点（Checkpointing）

存储在 TB/s 级别、节点级别和非常大的规模下面临性能挑战。

• 挑战：在训练期间进行检查点保存会导致 GPU 空闲，降低计算效率。
• 解决方案与要点：
• 检查点保存所需的带宽应在集群级别提供，而非节点级别。
• 异步写入：可以将检查点写入操作移出关键路径，减少 GPU 等待时间。
• 读取是关键：检查点读取可能位于关键路径上，并在大规模下压缩检查点间隔。
• 示例：Megatron-LM 在 12K 个 GPU 上训练 1T 参数模型，151秒的间隔中，保存需要 9.5秒，恢复需要 9.2秒（@10Gbps/GPU）。
• 多模态工作负载：1 Gbps/GPU 的带宽可能导致 60% 的 GPU 闲置，将带宽提升 4 倍可以缓解此瓶颈。

3.3 大语言模型（LLM）推理

推理的瓶颈遍布整个网络、系统、存储和上下文利用。

• 分离式服务（Disaggregated serving）：
• Prefill 阶段：计算密集型，摄入（Ingest）带宽为 Gbps 级别。
• Decode 阶段：带宽密集型，使用 NVLink 进行扩展。
• 用户体验：首个 Token 生成时间（TTFT）和端到端（E2E）时间至关重要。
• KV 缓存：其大小随着并发用户数（# concurrent users）和用户会话窗口（user session window）的增加而增长。KV 缓存的传输会影响 TTL（1-2个 token）。

3.3.1 推理中的 KV 上下文

• 目标: 提升吞吐量 (token/用户)、降低延迟，并满足用户体验的服务等级目标 (SLO)。
• KV 上下文缓存: 缓存 KV (Key-Value) 上下文比重新计算更快。
• HBM 内存: 仅用于活跃的 token。
• CPU 内存: 将被逐出的 token 写到磁盘上，为随机访问保留 KV 上下文。

3.3.2 NVIDIA Dynamo

NVIDIA Dynamo 是一个用于大语言模型推理的动态调度系统。其架构如下图所示：

• API 服务器: 与 OpenAI API 兼容，提供外部接口。
• 中央路由器: 采用先进的 KV 缓存驱逐算法进行智能路由。
• 推理引擎 (前端/后端节点):
• Prefill 引擎: 处理初始输入。
• Decode 引擎: 生成后续 token。
• 分布式 KV 缓存: 在多个 GPU 间共享和管理 KV 缓存。
• 数据处理引擎: 用于预处理、后处理和高吞吐量的数据加载。
• KV 缓存管理器: 负责 KV 缓存的异地加载 (offloading)。
• 数据 I/O: 连接数据源和数据接收端，处理服务/检查点等组件。

3.3.3 KV 缓存内存分层

通过平衡延迟、用户体验和总拥有成本 (TCO) 来实现。

• 容量 - KV 缓存大小:
• 大小取决于模型和 KV 缓存的表示方式（例如，空间占用或稀疏性）。
• 每个 token 的 KV 缓存大小: 2 * L * H * D_h * S_e / T_p (其中 L=层数, H=头数, D_h=头维度, S_e=元素大小, T_p=张量并行度)。
• 示例:
  • Llama 7B: 700KB/token, 对于 128k 上下文，需要约 85GB。
  • Llama 70B: 2.7MB/token, 对于 128k 上下文，需要约 330GB。

• 大型的地理空间定位 (GSL) 模型会导致每个请求产生巨大的 KV 缓存。

• 推理引擎的首选访问粒度:

• 将 KV 缓存作为一组 token 进行管理（通常一组超过 512 个 token）。
• 传输粒度（层级或 token）取决于内存层级和临界延迟。
• 吞吐量受到每个 token 计算与内存传输重叠能力的限制。
• 示例: GSL R1 - 3MB/层 @ 5μs，54GB/token -> 1MB/组 32 token。
• 在一个请求内部，访问模式是可预测的；但跨请求的访问是随机的。

3.4 Nemo Retriever - 加速 RAG 推理

该系统通过测量 RAG+LLM 集成模型的运行时间和内存使用来进行优化。

工作流程:
1. 数据摄入: 从企业数据源（如文档、图片、表格）提取信息。
2. 嵌入与索引: 使用嵌入模型 (Embedding Model) 将数据转换为向量，并构建索引 (Vector DB)。
3. 检索: 当用户提出查询时，首先对查询进行嵌入，然后通过检索器 (Retriever) 从向量数据库中找到最相关的上下文。
4. 生成: 将原始查询和检索到的上下文一起输入到大语言模型 (LLM) 中，生成最终的、包含企业知识的洞察。
5. 核心理念: 为数据消费、索引和 LLM 提供一个合理的上下文。

3.5 向量搜索/数据库

3.5.1 索引与搜索

• 搜索:
• 应用场景：RAG、主题建模、语义搜索。
• 高节点搜索速度快，通常推理时间的 10s of ms。分数可能会随数据库之一而变化。

• 并发搜索的目标是构建/索引过程中的 10s of ms。

• 构建图和索引:

• 基于 kNN 图进行数据分析、聚类和可视化。
• 制作稀疏、分层、结构化的范围索引——需要重新优化或全局索引——可动态更新。

• 仅追加模式更新，更新成本来自图写入或最小化图写入。

• 构建与搜索的权衡:

• 最快构建: 盲分割，搜索速度较慢，因为必须搜索每个段。
• 基于聚类的分区: 构建速度较慢，但由于更好的局部性，搜索速度更快。
• 对于内存中和小型图，这种权衡不那么重要；但对于磁盘上的大型图，则非常关键。

3.5.2 基础设施与数据粒度

• 基础设施支持与分层:
• NVIDIA GPU 加速数据分析 (cuDF)
• 目前大部分向量数据库可以装入内存，但已经开始出现瓶颈。

• RAG 的日益普及、加速摄取和多媒体内容将增加向量数据库的规模。

• 粒度:

• 节点数据: 256 B-1 KB，包含块嵌入、邻居列表的压缩表示。
• 粗粒度: 段（>100MB）用于顺序访问，块用于上下文一致性。
• 细粒度: 分层/全局索引用于增量、就地更新。

3.6 图神经网络 (GNN)

SCADA 可用于从磁盘上的文件系统数据库加载节点嵌入，以构建一个 GNN。

• 规模 (Size):
• 初始图结构：倾向于是稀疏的节点集，例如 1T 边可能为 7TB。
• 总嵌入数据：对于需要 8 个 GPU 进行推理或 GNN 训练的应用程序，可能超过 100M 节点 * 4KB。示例：1T 边 * 4KB = 4PB，50M 节点 * 4KB = 20GB。

• 带有节点嵌入数据的采样图：用于零拷贝聚合的采样图可能为 5M 节点 * 1KB + 元数据 = 5GB。

• 粒度 (Granularity):

• 图结构数据：8-32字节。
• 嵌入数据：通常为 4KB。

3.6.1 GNN 模型构建

• SCADA 的相关性: 输入数据工作、采样、节点聚合，可用于训练、推理、异常检测和 LLM。
• 解决了超出内存容量的数据访问问题。
• 已解决的问题和衡量指标:
• 固定大小 GNNs: 准确率与吞吐量；例如用于动态延迟、历史长度、客户数量的准确率。
• 社交网络: 准确率与吞吐量；而图的准确率是根据关系部分与吞吐量的杰克卡德相似性来分割的。
• 基础设施支持与分层: WholeGraph，通过 SCADA 启用。
• 上层是用于图结构和 DGL 的 cuGraph-PyG for graph structure 和 DGL for graph structure and embeddings。
• 用于金融科技领域的 TigerGraph 也很常见。

3.6.2 GNN+LLM

• LLMs (大语言模型):
• 模型规模大。
• 单跳关联记忆，例如成对关系。
• 但存储成对关系的能力可能会耗尽。
• 编码关系的开销占用大量空间。

• 计算复杂度非常高。

• GNNs (图神经网络):

• 图规模小。
• 多跳、复杂的多跳关系。
• 关系编码非常密集。

• 计算复杂度相对较低。

• LLM + GNN:

• GNNs 能以最小的计算开销显著提高准确性。
• 这是一个充满潜力的新领域。
• SCADA 的相关性: 如前所述，为 GNN 子结构和向量数据库提供支持。

3.6.3 GNN+LLM RAG (GNN 为 LLM 提供信息)

在推理时，给定一个查询：
1. 分词与编码: 使用 LLM 编码器对查询进行分词和编码。
2. 检索: 从知识图谱 (KG) 中检索与查询相关的子图，并使用 GNN 对其进行编码。
3. 联合嵌入: 将 GNN 的节点嵌入与 LLM 的嵌入联合起来。
4. 解码与生成: 让 LLM 解码器对联合嵌入进行解码，并生成响应。

4. GPU数据访问技术深度解析：GPUDirect Storage 与 SCADA

4.1 数据访问技术概述

4.1.1 PCIe 数据路径概览

数据从存储到 GPU 的路径有多种，其效率直接影响整体性能。

• 网络访问: GPU 通常挂载在网络接口卡（NIC）或 PCIe 总线上。
• 本地传统访问: NVMe 存储设备挂载在 CPU 下。数据传输需要经过 CPU 的一个“反弹缓冲区”（bounce buffer），这会导致 PCIe 带宽限制加倍，并增加 CPU 的利用率开销。
• 本地直接访问 (GPUDirect): 使用 BlueField-3 DPU 作为 PCIe 交换机或使用一个独立的 PCIe 交换机，可以实现 GPU Direct 技术。这使得数据可以直接从 NVMe 传输到 GPU 内存，从而最大化带宽，并将 CPU 利用率降低 3-10 倍。

4.1.2 数据访问的发起者：CPU vs. GPU

数据访问可以由 CPU 或 GPU 发起，两种模式适用于不同的场景。

• CPU 发起 (GPUDirect Storage):
• 可预测: 访问模式提前已知。
• 页大小的倍数: 几十个线程即可饱和 PCIe 带宽。
• 低 IOPS 需求: 使用较少的线程和较大的 I/O 尺寸。

• 预取: 在 GPU 对当前批次数据进行计算时，可以预取下一批次的内容到 GPU 内存。

• GPU 发起 (SCADA - Scaled Data Architecture):

• 数据驱动: 访问模式仅对每个 GPU 线程可知。
• 细粒度: 需要大量线程（例如 O(100K)）来饱和 PCIe 带宽。
• 高 IOPS 需求: I/O 尺寸小，导致极高的 IOPS。例如，在 100 GB/s 的 Gen5 带宽下，使用 512B 的 I/O 尺寸需要 200 MIOPS（每秒百万次 I/O 操作）。

4.1.3 数据访问的粒度：粗粒度 vs. 细粒度

饱和 PCIe 带宽所需的 IOPS 是数据访问粒度的函数。

• 粗粒度 (Coarse-grained):
• 示例: 深度学习训练。
• 低 IOPS: 例如，在 50 GB/s 的 Gen5 带宽下，使用 32KB 的 I/O 尺寸仅需 1.6 MIOPS。

• 应用: 网络（如 SNAP）、远程存储/NVMe。

• 细粒度 (Fine-grained):

• 示例: 推理中的 tokens、向量搜索、数据库、图结构和嵌入。
• 高 IOPS: 例如，在 50 GB/s 的 Gen5 带宽下，使用 512B 的 I/O 尺寸需要 100 MIOPS。
• 应用: 在网络场景中，需要将数据捆绑后发送到远程存储服务器（>10 MIOPS）。这种模式下，需要的队列深度比粗粒度模式大 10-100 倍。

4.2 NVIDIA GPUDirect Storage (GDS) - CPU发起的加速

GDS 是一套旨在加速数据在存储和 GPU 之间传输的技术。

4.2.1 GDS 的关键技术与优势

GDS 的核心是建立一个从存储到 GPU 的直接数据路径，从而带来多重好处。

• 高带宽直接路径: 通过 PCIe 交换机放大，数据直接传输到 GPU。
• 降低 CPU 利用率: 数据传输无需 CPU 介入。
• 降低延迟: 减少了数据在系统内存中的拷贝环节。
• 技术对比: 支持 RDMA（远程直接内存访问），优于传统的 TCP。支持动态连接（DC）和可靠连接（RC）。
• 其他优势: 包括 GPU 端的优化和更高的能效。

4.2.2 GDS 的两种接口：cuFile 和 cuObject

NVIDIA 为 GDS 提供了两种主要接口以适应不同应用场景。

• cuFile: 主要用于本地（On-prem）和云环境。
• 已集成到众多 AI/ML I/O 库中，通过标准文件系统启用。
• 高性能计算（HPC）中间件 HDF5 已启用该接口，可带来高达 4 倍的加速。
• S3 over RDMA / cuObject (研究中):
• 针对在本地对象存储中使用高速存储和 RDMA 的增长趋势。
• 旨在保留标准 S3 协议（安全 HTTP）的优势，同时利用 RDMA 的高性能。

4.2.3 GDS - cuObject/S3oRDMA 性能评估

cuObject 是一项提议中的技术，目前正处于产品评估阶段，主要面向本地部署。

• 特点: 无需特权访问，但需要重新编译应用。
• 早期结果: 与 Cloudian 合作的早期数据显示，与客户端和服务器计算驱动的 TCP 相比，硬件卸载的 RDMA 在带宽和 CPU 负载降低方面有显著改进。

性能对比 (数据由 Cloudian 提供)

指标	TCP	RDMA	加速比
吞吐量 S3oRDMA	1x	2x	2x
CPU 使用率 (% logical cores)	11	5.7	47% 降低

测试环境: 分布式 S3 性能基准测试。配置: GPU-Mellanox (1 个服务器节点 vs 1 个客户端节点), 200Gbps NICs, RDMA, MTU of 4096.

4.2.4 应用案例：使用软件定义对象存储加速推理

在推理任务中，上下文的构建依赖于输入 token 序列的长度。当序列变长时，存在一个权衡：是重新计算还是将状态溢出（spill）到磁盘/KV 存储。

• 权衡: 对于短序列，重计算很快。但超过某个点后，从存储中重新加载状态会更快。
• 存储加速: 存储可以是文件或对象。使用 S3 over RDMA 可以加速这一过程。图表显示，随着数据量的增加，从存储加载（特别是对象存储）的性能优势愈发明显。

4.2.5 GDS - cuFile 的启用效果

下表展示了在不同工作负载下，启用 GDS cuFile 带来的性能提升。

工作负载	OEM H100 with PCIe Gen 5e	GH200
模型加载: TRT-LLM	2.12x	1.0x
检查点保存: PyTorch (RAC)	6x	1.61x
Tensor 加载/存储: PyTorch	5.23x / 1.53x	3.19x / 1.00x
基因组学: Parabricks	1.41x	1.00x
HPC: HDF5 in Legate, 8 way	4.2x

4.3 SCADA - GPU发起的规模化数据访问

4.3.1 SCADA 核心理念与架构

SCADA（Scaled, Accelerated Data Access）使成千上万的 GPU 线程能够以细粒度的方式加速对存储中无边界数据的访问，旨在将 GPU 转变为一个自主的、高度并行的数据访问引擎。

• 问题：巨大的数据集太大，无法通过传统的加载和存储指令访问。这带来了分区、缓存、通信的复杂性，以及规模化下的错误处理问题。因此，需要新的 API 系列来覆盖任何地方的数据。
• 解决方案：SCADA
• 访问由 GPU 发起：与适用于批量 CPU 请求的 GPUDirect Storage 不同，SCADA 是一种 GPUDirect 异步内核级存储，专为 GPU 发起的访问设计。
• 海量访问：每个 GPU 线程可以发起一个或多个访问请求，粒度越细，收益越大。
• 核心理念: 请求的生成、发起、服务和消费全部在 GPU 内核中完成。
• GDA KI Storage: 使得数据 I/O 可以由 GPU 发起和触发。
• 可信服务器: 请求在一个可信的、具有存储访问权限的特权服务器中处理。
• Magnum IO 的关键支柱: 提供灵活的抽象。

4.3.2 SCADA 服务的演进

SCADA 的服务从基础功能开始，逐步扩展。

• 通用基础设施:
• 头文件驱动的客户端库。
• 内存由 SCADA 通过 API 进行分配和释放。
• 演进路径:
• 从一个简单但关键的服务（如交换，swap）开始。
• CPU 上的应用像往常一样将所有数据从存储读入 GPU。
• 当 GPU 内存不足（OOM）时，GPU 线程可以将数据溢出到 SCADA 或从 SCADA 重新填入，从而获得无限容量。
• 提供连续数组的 API。
• 未来方向: 期待社区反馈，以开发新的 API、服务和功能，例如：Key-Value、VectorDB、数据帧（dataframe）、从持久存储批量加载等。

4.3.3 性能结果：GPU 作为数据访问引擎

• 数据查找加速: 通过减少到（特征）数据的 I/O 瓶颈来提高吞吐量。
• 透明数据重用: 缓存（400-600 GB/s）带来了显著效益，可以将 PCIe 带宽（对于 Gen4 为 24 GB/s）饱和到 GPU。
• I/O 处理: 10 MIOPS 的处理能力可以跟上饱和 PCIe 的 NVMe IOPS 速率（对于 Gen4 为 6 MIOPS）。
• 并发性: 根据利特尔法则（Little's Law），6.25k 线程和 125us 的访问延迟，在 512B I/O 尺寸下可达到 25 GB/s。
• 队列深度: 来自 GPU 的请求队列深度可以是 CPU 请求的 10-100 倍。

4.3.4 客户端/服务器拓扑

SCADA 采用客户端/服务器架构。

• 客户端（计算节点）: 实现缓存，为缓存未命中生成存储请求。
• 服务器（存储节点）: 拥有对存储和内存的特权访问，负责建立连接。
• 存储类型: 可以是专用的本地存储，也可以是解耦的块存储。

4.3.5 存储服务器配置示例

• 驱动器数量:
• IOPS per GPU = Gen5 PCIe bandwidth / IO size
• 100 GB/s / 512B ≈ 200 MIOPS/GPU
• IOPS per Gen5 NVMe ≈ 7 MIOPS
• 因此，大约需要 30 个 NVMe 驱动器来实现本地解耦存储。
• 计算元件: 运行 SCADA 服务器，接收捆绑的请求束，并将它们引导到相应的 NVMe。这需要高度的并发性，预计需要一个 GPU，而不仅仅是几个 CPU。
• 连接: 需要使用 fabric 模式的 PCIe 交换机来连接 GPU 和 NVMe，而无需 CPU 的介入。

4.3.6 客户端到服务器的批量 IOPS 性能

• 性能表现:
• SCADA 可以在 32 个以上的缓冲区中轻松生成 64K 请求。
• IOPS 和带宽随着缓冲区深度的增加而提高。
• 在 4KB I/O 尺寸下，网络饱和度可达约 90%。
• 在 512B 尺寸下的 IOPS 远高于 4KB 尺寸。
• 实验设置: 客户端和服务器均为 H100，网络接口卡为 CX7 1x200。

4.3.7 SCADA 的应用适用性

SCADA 并非适用于所有场景，以下是其最适合的应用特征：

• GPU 发起、动态、每线程:
• 每个 GPU 线程动态地形成并发出自己的请求。
• （如果可以提前知道整个批次的请求，应使用 CPU 发起的 GPUDirect Storage）
• 细粒度、高吞吐量:
• I/O 尺寸可能在 4B 到 4KB 之间。
• （如果访问是粗粒度的，用很少的线程就可以饱和带宽）
• 无界数据大小:
• 数据无法可靠地放入 GPU 的高带宽内存（HBM）中。
• （如果数据能放入 HBM，直接使用 load/store 指令即可）
• 数据访问受限:
• 应用的瓶颈在于数据访问。
• （如果应用是计算受限的，那么在许多节点上使用 HBM 是“免费”的）

4.3.8 SCADA 的优势：规模、TCO与性能

规模 (Scale)

• 0 -> 1: 解决以前少量GPU无法完成的问题。
• 即使速度稍慢（例如，使用少量NVMe），也需要考虑可接受的性能下降阈值是多少。

总拥有成本 (TCO)

• 在给定的性能水平下，与NVMe对比HBM或DDR的方案相比，SCADA提供了更高的成本效益。

性能 (Performance)

• 如果数据集完全在HBM中，API和3级查找的性能无法与直接的加载/存储操作竞争。
• 如果数据集在系统内存中，其性能接近于通过PCIe使用cudaMallocHost。
• 如果数据集必须溢出到磁盘，从GPU直接访问NVMe的性能远优于通过CPU访问。
• 利用线程并发和HBM带宽，可以从GPU使用块（block）来访问，而不是依赖CPU的文件系统。
• 我们观察到性能随着磁盘数量线性扩展，这对存储架构具有重要意义。

4.3.9 SCADA 的总拥有成本 (TCO)

SCADA 的 TCO 比密集本地内存或估算方案低了两个数量级。

基准测试情景：

图中比较了三种配置下的训练时间（每个epoch的小时数）与问题规模（TB）的关系：
1. Vanilla（无SCADA）: 仅使用GPU内存和DRAM。
2. SCADA Cache: 使用带缓存的SCADA方案。
3. SCADA Remote Storage: 使用远程存储的SCADA方案。

系统配置案例：

覆盖了三种基于类DGX计算节点的案例：
* Vanilla SCADA: 基于问题容量/TB/DDR的模型。
* driveHEAVY SCADA: 基于驱动器容量的模型，每1 GPU配备8个驱动器，其他工作负载预计也需为GPU付费。
* driveLIGHT/disaggregated: 每个客户端DIMM中仅有1个GPU，远程存储盒中有24个驱动器。

核心假设：

• 在没有SCADA的情况下，每个epoch的时间为75秒/TB；使用带缓存的SCADA为180秒/TB。
• 每增加8个GPU线性增加1个驱动器（尚未实测）。
• 存储节点成本：$7k/15.3TB E1/E3驱动器。 * 计算节点成本：$200k。
• NVMe成本：$2k。 ## 5. 生态系统、未来展望与行动倡议 ### 5.1 合作伙伴与认证计划 #### 5.1.1 网络的作用 解决远程存储和 GDS (GPUDirect Storage) 中的网络拥塞问题。 - **NVLink**: 用于服务器机架内的 GPU-GPU 通信。 - **东西向流量**: 节点到节点，可能使用专用存储。 - **南北向流量**: 存储、外部用户、外部内容。 - **多作业/多租户**: 通过基于 Spectrum-X 的拥塞控制实现高效的多作业/多租户环境。 - **性能**: 在 NVL-1 上，读取性能提升高达 1.48 倍，写入性能提升高达 1.41 倍。 - 更多信息可参考 NVIDIA、DDN、VAST 和 Weka 的技术博客。 #### 5.1.2 存储认证 NVIDIA 认证和 NCP (NVIDIA Cloud Partner) 存储认证计划，专为 AI 工厂设计。 - 支持安全性、RAS (可靠性、可用性、可服务性)、多租户、数据服务和自动化。 - 现在支持 NCP 上的 53 个论坛和一致性 IOps。 - 涵盖从 HPC、大数据分析、经典 ML/DL 到微调和推理，再到代理推理等企业级用例。 - **NVIDIA Cloud Partner (NCP)**: - 为生成式 AI 提供高性能、可扩展和安全数据中心的参考架构蓝图。 - 数据架构基于数据湖和 GPS 文件系统。 - 目前，CSP 数据湖与 33 个 NFS、HFS 和认证文件系统集成。 #### 5.1.3 倡议与合作伙伴 - **NVIDIA AI 数据平台**: - NVIDIA 正在推出一个参考设计，用于构建智能 AI 数据平台，以满足新一代企业存储、集成存储解决方案，从而加速要求苛刻的推理、代理和报告工作负载。 - SIR 组件：NVIDIA AI Enterprise、NVIDIA Blueprints with e.g. D.O、NetApp、PaloAlto、Pure、Dell、VAST、Weka。 - HIB 组件：GPUs、Spectrum-X 和 BlueField DPUs。 - **Storage-Next (由 NVIDIA 领导)**: - 行业联盟，旨在弥合第一代 GPU 加速存储和 NVMe 在总拥有成本（TCO）和可选电源方面的差距。 - 最佳合作伙伴如下。 - **存储提供商**: - 与 Spectrum-X 网络平台合作的合作伙伴：DDN、Pure Data、WEKA。 - AI 数据平台与 10 个供应商合作：Dell、DDN、HPE、IBM、NetApp、Pure、VAST、Weka 等。 - KV 缓存分层将通过所有存储合作伙伴启用。 - VAST 在 Storage-Next 中的开创性兴趣：Dell、DDN、HPE、IBM、NetApp、Pure、VAST Data、WEKA。 ### 5.2 下一代存储 (Storage-Next) #### 5.2.1 共同打造社区驱动的下一代存储 通过EURC（有效利用率）、容量、功耗和组件改进TCO，实现GPU与TCO的平衡。 ##### 协作路径： 上图展示了一个多方协作的路线图，涉及云服务提供商（CSP）、原始设备制造商（OEM）、NVIDIA/WEKA以及存储控制器和介质厂商。路径分为几个阶段： 1. **概念 (Concept)** -> 分享/设计 (Share/design) 2. **提炼/分享想法 (Refine/Share ideas)** -> 分享 (Share) 3. **实验 (Experiments)** -> 分享/仿真 (Share/simulation) 4. **评估 (Evaluation)** -> 评估 (Evaluation) 5. **提炼/分享需求 (Refine/Share requirements)** -> 提炼需求 (Refine requirements) 整个过程围绕为TCO进行**搜索 (Search)**、**开发 (Dev)**和**评估 (Eval)**。 ##### 参与方： * 欢迎有兴趣的各方在工作负载、基础设施、特性描述、评估、需求和TCO方面进行合作。 * 向所有直接贡献者开放：介质供应商、存储控制器供应商、OEM、消费者。 #### 5.2.2 下一代存储的早期需求 ##### IOPS (每秒输入/输出操作次数) * **计算目标**: 对于Gen5接口和512B的传输大小，100 GB/s 相当于每个GPU 2亿IOPS，8个GPU则需要16亿IOPS。 * **理由**: GPU上的新应用程序各自都会进行大量的随机细粒度访问。 ##### 粒度 (Granularity) * **需求**: 小于当前介质码字（codeword）的4K，可能小于NVMe标准的512B。 * **理由**: 嵌入（Embeddings）大小为512B-4KB，图结构可能小至8B-128B。 ##### 引用 (References) * **模式**: 大部分是读取，少量写入；访问模式大多是随机且不可预测的。 ##### 延迟 (Latency) * **需求**: 最小化最坏情况延迟与平均延迟的比率。 * **理由**: 这在同步点至关重要，同步点之间的距离取决于并发度/线程数。 ##### 容量 (Capacity) * **目标**: 追求极高的IOPS和IOPS/VM，而不是每美元的GB数（GB/$）。

功耗 (Power)

• 理由: 需求量巨大，且关注写放大问题（例如从512B放大到4KB）。

5.3 行动倡议

让我们共同为展示CPU角色不再具有广泛单一权威性的发展奠定基础。

致存储介质技术专家：

• 提供亿级（O(100M)）IOPS、高能效、更低的尾延迟以及高效的请求/响应机制。
• 加入我们，共同定义“Storage-Next”。

致存储提供商和云服务提供商 (CSP)：

• 仔细研究访问模式和特性，帮助推动“Storage-Next”的需求定义。
• 探索并帮助推动能够利用数据摄取、索引和拆分的洞察平台。

致应用程序开发者和用户：

• 分享对计算所需数据容量超出GPU+CPU内存的需求。
• 明确产品栈支持和部署模型的细节。

致基础设施开发者：

• 在SCADA之上进行分层，从缓冲加载模型转向直接访问模型。
• 寻找实现计算与通信细粒度交错的新途径。