Accelerating data movement between GPUs and storage or memory

Chris J. Newburn (CJ), Distinguished Engineer, NVIDIA, cnewburn@nvidia.com
Magnum IO architect. Ph.D., Carnegie Mellon University 1997

Da Zheng, Sr. Applied Scientist, AWS, dzzhen@amazon.com
ML framework/algo leads; DGL/DGL-KE/DistDGL/TGL Ph.D. Johns Hopkins 2016

Harish Arora, Principal Product Manager, NVIDIA, hararora@nvidia.com
Magnum IO product mgr, Storage/Networking for DGX. MS IMT, MBA Cornell

Mar 22, 2023, 1pm

---

目录

• 引言

• NVIDIA® Magnum IO

  • NVIDIA GPUDirect™

• NVIDIA Magnum IO GPUDirect Storage

  • 概述
  • 合作伙伴更新

  • 用例

    • 用于逆时偏移 (RTM
    • 用于逆时偏移结果
    • 最新评估 (KAUST PSTM
    • 用于叠前时间偏移 (PSTM
    • 用于叠前时间偏移 (PSTM) 结果和优化机会
    • 其他用例

  • 用户经验教训

  • 推理与训练 - DeepCAM 和 Cosmoflow

  • NVIDIA的存储空间创新

    • 兼容性
    • 融合DPU-GPU
    • 批处理 - CUDA 12.0.1中的新功能
    • 批处理结果
    • 异步 - 未来功能
    • 控制源

  • 新功能 (即将推出

• GPU发起的存储

  • 问题：大量随机细粒度访问
  • 使用模型

  • 图机器学习中的应用

    • 工业中的图机器学习
    • 图神经网络 (GNN
    • 图上的Mini-batch训练
    • 使用DistDGL进行多机分布式训练

  • 分布式 GNN 训练

    • CPU-based 分布式训练
    • NVMe-based 分布式训练
    • 扩展 GNN 训练和内存需求
    • 分布式 GNN 训练管道

  • 设计目标和要求

  • 架构
  • NVIDIA GNN 性能结果与我们的 POC
  • GNN 性能
  • 当前 POC 限制
  • AWS 适用性

• 安全

  • 考虑点
  • 信任区域
  • 权衡
  • DPU 作为授权的关口
  • 动态数据和静态数据

• 鸣谢

• 行动呼吁

---

引言

NVIDIA在加速存储I/O方面的新发展：
* Magnum IO
* GPUDirect
* NVIDIA的存储空间创新
* GPUDirect Storage
* GPU发起的存储
* 安全性

NVIDIA® Magnum IO

数据中心和边缘的优化数据移动、访问、管理I/O子系统。

• 存储

  • 存储与GPU之间的直接数据路径
  • 未来：由GPU发起的存储
  • 未来：通过将存储客户端从计算节点移动到DPU来提高安全性

• 网络

  • InfiniBand, Ethernet
  • MPI, NCCL, NVSHMEM, UCX, GDA KI Network

• 管理

  • 网络：UFM, NetQ
  • 未来：数据编排

NVIDIA GPUDirect™

关于谁决定做什么以及何时做的工作变体，以增加GPU的自主性。

GPUDirect 异步与非异步模式：

	GPUDirect (非异步)	GPUDirect 异步
CPU发起 (准备, 触发)	CPU准备, GPU触发	GPU内核发起
视频	GPUDirect Video	Stream triggered GDA-ST
本地GPU	GPUDirect Peer-Peer P2P	Graph triggered GDA-GT
远程主设备	GPUDirect RDMA	Kernel triggered GDA-KT
存储	GPUDirect Storage GDS

• GPUDirect支持GPU之间直接数据移动，无需在CPU中进行中间暂存。
• 随着内存变得可迁移，源/目标可能位于GPU或CPU中。
• 网络和存储I/O涉及：
  • 准备：为I/O设备创建工作请求，例如命令队列上的工作队列条目。
  • 触发：将工作请求传递给/同步I/O设备，例如按门铃。

NVIDIA Magnum IO GPUDirect Storage

概述

GPUDirect Storage将文件I/O作为CUDA的一部分。

• 传统文件系统访问

  • 2次DMA操作
  • 需要跳动缓冲区
  • 将CPU <=> PCI带宽减半

• GPUDirect Storage 访问

  • 单次DMA操作
  • 无跳动缓冲区
  • 独立于CPU <=> PCI
  • 类似于Posix的API：cuFileRead, cuFileWrite

合作伙伴更新

合作伙伴生态系统正在响应客户需求而扩展。

所有通用合作伙伴：NVIDIA GPUDirect Storage 集成解决方案已投入生产，包括DDN, DellEMC, Hewlett Packard Enterprise, Hitachi Vantara, IBM, KIOXIA, LIQUID, Micron, NetApp, Samsung, Scaleflux, SUPERMICRO, ThinkParQ, VAST, WEKA。

文件系统合作伙伴：

• 开源Lustre 2.15支持GPUDirect Storage。
• 通过参加S52331会议了解更多关于HPE Ezmeral的信息。

用例

用于逆时偏移 (RTM)

逆时偏移（RTM）用例总结。

• 一种地震偏移技术。
• 尝试NVIDIA的CPU加速RTM实现 - Energy SDK Samples。

• 工作流程

  • 通过在GPU上计算正向和反向波传播来生成地震图像。
  • 关键指标 = 单次偏移时间（正向传播 + 反向传播 + 成像）。
  • 单次偏移会生成TB级数据，必须快速保存/写入。
    • 在反向传播期间以相反顺序读回。

• 用于存储/保存快照的后端

  • 系统DRAM
  • 通过GPUDirect Storage在NVMe（本地文件系统）上
  • 通过POSIX在NVMe（本地文件系统）上

用于逆时偏移结果

• 小问题规模

  • imageGrid.size.y=201 在2个GPU + 2个NVMe上
  • 总快照数据大小 = 1.3TB
  • 端到端时间（秒，越少越好）显示GPUDirect Storage比内存快1.9倍，比磁盘（fwrite/fread）快1.1倍。
  • 总结
    • GPUDirect Storage优于系统内存。
    • GPUDirect Storage比系统内存更经济。

• 大问题规模

  • imageGrid.size.y=960 在8个GPU + 8个NVMe上
  • 总快照数据大小 = 5.9TB
  • 端到端时间（秒，越少越好）显示GPUDirect Storage比磁盘（fwrite/fread）快4.5倍。
  • 总结
    • 系统内存（>2TB）对于大型问题不是一个选择。
    • 数据压缩将提高性能。

最新评估 (KAUST PSTM)

KAUST的PSTM基准测试。

• 使命

  • KAUST超级计算实验室（KSL）的使命是通过开发和应用HPC解决方案，通过与KAUST研究人员和合作伙伴的合作，以及通过提供世界一流的计算系统和服务，激发并实现科学、经济和社会进步。
  • 了解更多关于KSL - https://www.hpc.kaust.edu.sa/

• KAUST超级计算机

  • 基于CPU的Shaheen II超级计算机。
  • 带有GPU和Weka IO存储的IBEX集群，用于科学计算和AI应用。
  • Shaheen III计划于2023年底推出，基于NVIDIA Grace Hopper，性能达100 PFlops/s。

• 成就

  • KAUST与石油和天然气行业合作，在地震成像、油藏模拟和工程领域打破了3项世界纪录。

用于叠前时间偏移 (PSTM)

用例亮点 – KAUST的PSTM基准测试。

• 叠前时间偏移 (PSTM)

  • 地震偏移是一组将记录的地震反射数据转换为地球内部反射边界图像的技术。
  • PSTM基于计算地下点能量散射的走时曲面。

• PSTM工作流程特点

  • 简单而并行地在GPU上计算。
  • 大数据集 → I/O密集型。
  • 行业标准数据文件格式 → SegY (Media header, File header, Chunk, Bulk Data, Chunk, Bulk Data)。

• PSTM工作流程分析

• I/O瓶颈：读取炮点数据占用端到端时间的79%。

用于叠前时间偏移 (PSTM) 结果和优化机会

• GPUDirect Storage加速

  • PSTM完整应用加速显示：基线为1.00，GDS-Naive-Integration为0.39，Batch Without GDS为1.05，Batching GDS为1.19。
  • 使用GPUDirect Storage Batch API实现1.2倍增益。

• 进一步优化机会

  • 大型I/O请求。
  • 4KB对齐I/O。
  • 将GDS与WekaFS结合使用。
  • 优化写入路径。
  • 评估新的GPUDirect Storage功能：
    • 系统内存支持
    • 异步API
    • 批处理API

其他用例

许多用例和应用配置文件已证明成功。

• I/O性能提升

  • RAPIDS/cuCIM: 11倍
  • HPC可视化: 8倍
  • 基因分型: 6倍
  • HDF5: 5倍
  • DeepCAM推理: 4.6倍
  • KvikUII/Zarr: 2.9倍
  • 地震模拟: 2.5倍
  • Merlin: 1.4倍
  • Cosmoflow DL训练: 1.2倍

• 保持工作流程和数据在GPU上

  • 优点

    • CUDA中的文件I/O。无需特殊硬件。
    • 2倍-8倍带宽提升。
    • 更快的I/O到GPU内存。
    • CPU利用率最高降低3倍。

  • 要求

    • 使用CTK。
    • 系统拓扑（PCIe交换机）。
    • 仅限于GPUDirect / Vidmem。
    • 仅限于O_DIRECT。

• 许多GPU应用对I/O敏感，并处理大量数据。

用户经验教训

应用开发者喜欢GPUDirect Storage的性能，但有额外的要求。

• 混合数据处理

  • 元数据在CPU中处理，批量数据在GPU中处理。

• 异步I/O与GPU上的计算重叠

• 统一API更易于采用/使用

  • POSIX用于元数据，GDS API用于批量数据。

• CSP环境

  • 系统拓扑不理想，存储无RDMA。

• 行业标准文件格式和读取器

  • SegY, HDF5, Zarr, Tiff, 其他。

推理与训练 - DeepCAM 和 Cosmoflow

本次内容探讨了午餐时间与全天候推理（Inference over lunch vs. all day）对简单模型训练的显著影响。

下表详细比较了DeepCAM推理、DeepCAM训练和CosmoFlow训练在不同IO模式、DNN层数和GDS增益（加速比）下的表现：

要点：

• GDS仅在存储I/O是关键路径时才提供帮助。
  • 推理或层数较少的训练。
  • 随着批处理量（batch size）增大，每个样本的计算量减少。
  • 总数据量随批处理量线性增长。
  • 对于推理，更大的批处理量会受限于带宽 (~50 GB/s)。

NVIDIA的存储空间创新

NVIDIA在存储空间方面持续创新，为未来奠定了坚实基础。主要方向包括：

• 兼容性：驱动存在、平台变体方面（CUDA 12.2+）。
• 集合（Sets）：从实例到批处理的转换（CUDA 12.0.1）。
• 同步性（Synchrony）：从同步到异步的流/图处理（CUDA 12.2, 实验性）。
• 控制源：控制权从CPU转移到GPU、DPU（CUDA POC）。

兼容性

旨在实现同步提交、异步完成，并分摊用户-内核开销。

• 单一简单的文件I/O API，适用于任何类型的内存。

  • 类似于POSIX。

  • 无需为不同类型的内存（GPU内存、CPU内存、可迁移内存）使用单独的I/O代码路径。

    • GPU内存 (例如 cudaMalloc, cuMemMap)
    • CPU内存 (例如 malloc, cudaHostMalloc)
    • O_DIRECT 或 Page Cache
    • 可迁移内存 (例如 cudaMallocManaged/staged, malloc + HMM, malloc on Grace-Hopper)

  • 新功能将在CUDA 12.2中推出。

• 实现通用性。

  • 未对齐的缓冲区和过大的缓冲区无法通过GPU BAR1孔径。
  • 在CSP实例中工作 (ACS, IOMMU)。
  • 融合的GPU-DPU卡。
  • Grace-Hopper统一内存。

融合DPU-GPU

将远程存储的数据通过NIC传输到GPU，且数据流不离开卡。

要点：

• 设置

  • A100T=BF2@200Gbps+A100 GPU
  • 远程存储

• 有/无Arm核负载

  • DPU上的可选负载 = Stream

• 使用GDS的加速比

  • 无负载时为1.1x-1.7x
  • 有负载时为1.3x-1.6x

• 使用GDS的CPU利用率降低

  • 无负载时降低1-8x
  • 完全由Stream加载

批处理 - CUDA 12.0.1中的新功能

实现同步提交、异步完成，并分摊用户-内核开销。

• 一次提交读/写混合操作到1个以上的文件。

• 异步完成。

  • 应用程序线程提交、返回、轮询。
  • 请求的I/O向量在内核内部串行提交，但完成顺序可能乱序（OOO）。

• 批处理的性能优势。

  • 相较于多线程：更低的性能开销。

    • 每个请求批处理只需1个IOCTL。
    • 小I/O的IOPS高于多线程。

  • 相较于Linux AIO：更低的CPU利用率，更低的延迟。

    • 批处理：回调更新向量完成；应用程序轮询。
    • AIO：内核轮询持续进行 (CPU%) 或触发中断 (更长延迟)。

• 支持单线程模拟多线程执行；多线程可以进一步提升吞吐量。

• 行动号召：尝试新的生产API。

批处理结果

在略微牺牲吞吐量的情况下，显著降低CPU利用率。

• 批处理性能：在1个主机线程下，批处理性能为非批处理性能的75-90%。
• CPU利用率降低：特别是在32KB以下的I/O大小，CPU利用率更低。
  • 企业级系统可降低达5倍。
  • 消费级系统可降低9倍。

异步 - 未来功能

在流中实现异步提交、异步完成。

• 读/写/注册/注销API获得流参数。

• 支持流有序提交以实现延迟执行。

  • 可以快速提交大量I/O，无需等待阻塞API完成。
  • CPU-GPU切换硬件中的同步可以实现比CPU上的软件更高的IOPS。

• 为使用CUDA Graphs和CUDA Streams的代码打开大门。

行动号召：
* 对（公开）实验性API提供反馈。
* 在即将发布的版本中试用它们。

控制源

CPU、DPU、GPU都可以控制NVMe存储。

新功能 (即将推出)

• GPUDirect Storage

  • 现在可用

    • GPUDirect (GPU内存)
    • GPUDirect模式
    • 兼容模式

  • 2023年6月

    • GPUDirect (GPU内存)
    • GPUDirect模式
    • 兼容模式
    • • 系统内存
      • 页面缓存支持

    • 异步API支持

    • 启用：
      • 混合数据处理
      • 单一I/O API
      • CSP环境
      • 标准文件格式
      • 读取器库

• 新工作负载 (2023年下半年)

  • MONAI
  • NVIDIA RAPIDS
  • NVIDIA Data Loading Library (DALI)
  • NVIDIA Merlin
  • MPI-IO, PHDF5, PnetCDF
  • 许多其他...

• 分发 (2023年下半年)

  • NVIDIA虚拟机镜像 (VMI)
  • NVIDIA DGX Pod
  • NVIDIA DGX Cloud
  • NVIDIA AI Enterprise
  • NVIDIA DGX解决方案
  • NVIDIA CUDA Toolkit

请联系我们 - GPUDirectStorageExt@nvidia.com

GPU发起的存储

问题：大量随机细粒度访问

GPU并发性是实现吞吐量的关键。

• 大量随机细粒度访问 → 大量并发以最大化吞吐量。

  • GPU >> 并发 CPU；控制和数据路径将在CPU上成为瓶颈。

• GPU上消耗的数据；请求也可能在那里生成。

  • 通过CPU馈送数据成为瓶颈。

• 关于速率的关键假设。

  • 吞吐量 = min(GPU请求生成, $ bw, NVMe未命中访问, GPU上的数据消耗)。

• GPU相对于CPU的优势：

  • 生成请求：更多的线程生成请求。
  • 请求本地缓存：更多的线程并行访问，容忍延迟。
  • 向NVMes发出请求：更多的线程生成NVMe请求。
  • 消耗数据：更多的线程和其他加速功能，如Tensor Cores。

使用模型

需要高效键值API来处理大量小I/O到GPU内存的批处理。

• 图神经网络

  • 广泛用于欺诈检测、虚假评论、追踪机器人攻击、推荐系统。
  • 节点（数百万到数十亿）和边（数十亿到数万亿）的图。
  • 每个节点和每条边都有大小达4KB（>10TB）的嵌入。

• 推荐系统

  • 训练管道 - 10-100 TB的嵌入模型，需要细粒度访问。
  • 数据摄取管道 - 需要高效的预处理，如过滤和重建。

• 数据分析 (cuDF, Spark from RAPIDS)

  • 溢出管理、数十亿行数据的混洗管理。
  • 成本降低。

• Omniverse

  • 低延迟持久纹理对象，支持多个同时客户端。

• 向量搜索

  • 数十亿文档表示为向量 (~20PB)。

• ML中的图分析 - 当前cuGraph仅在图存储在内存中时支持。

  • 节点（数百万到数十亿）和边（数十亿到数万亿）。
  • 要求图位于内存地址空间中。

图机器学习中的应用

工业中的图机器学习

图机器学习在工业中主要应用于节点级预测和边级预测。

图神经网络 (GNN)

图神经网络是一系列学习节点、边和图嵌入的（深度）神经网络。

GNN如何工作？

• 每个节点周围的自我网络（ego-network）用于学习捕获任务特定信息的嵌入。
• 嵌入使用图的结构和节点与边的特征。
• 嵌入以端到端的方式学习；因此，预测是目标节点自我网络的函数。

图上的Mini-batch训练

一个mini-batch表示针对某些目标节点的计算图。

• 采样用于预测的目标节点。
• 采样目标节点的邻居。

使用DistDGL进行多机分布式训练

设计：
* 在机器间划分图。
* 数据并行mini-batch训练。
* 同步GNN模型参数更新。
* 异步稀疏嵌入更新。

分布式 GNN 训练

CPU-based 分布式训练

本架构展示了基于 CPU 的分布式训练，其核心思想是协同放置数据与计算，以减少网络通信。每个 GPU 实例都有一个与其关联的服务器进程，该进程负责处理节点/边特征。采样器从服务器进程获取数据，然后由训练器进程在 GPU 上执行计算。不同服务器进程之间通过网络交换节点/边特征。

NVMe-based 分布式训练

此架构图与前一页类似，但明确指出节点/边特征存储在 NVMe 存储上。通过将数据与计算协同放置，利用 NVMe 的特性，旨在减少网络通信，并可能提高数据访问效率。

扩展 GNN 训练和内存需求

该幻灯片展示了在大规模 GNN 训练中，NVMe 如何显著降低 CPU 内存消耗，并强调了 NVMe 在成本效益上的优势。

Graph Size	Total memory size	Node feature size	Reduce CPU memory consumption with NVMe by (%)
OGBN-papers100M #100M nodes #1.6B edges 128 node features	100 GB	52 GB	52%
MAG-LSC #240M nodes #3.4B edges 768 node features	224 GB	174 GB	78%
Future target O(10-100B) nodes O(100B-1T) edges	100 TB to >1 PB	100 TB to >1 PB > feature richness	improves with > nodes, compression

• 将节点/边特征存储在 NVMe 上可以显著减少 CPU 内存消耗。
• NVMe 比 CPU 和 GPU 内存便宜得多，且容量更大。
• 如果 NVMe 性能能够跟上 GPU 训练速度，这将是扩展 GNN 训练更具成本效益的方法。

分布式 GNN 训练管道

分布式 GNN 训练管道的迷你批次训练步骤包括：
- 采样迷你批次
- 复制节点/边特征
- 迷你批次计算

下表展示了每一步所需的数据复制吞吐量：

• AWS 系统信息: g4dn.metal with T4 GPUs (2560 CUDA cores @ 585MHz)
• 结论：当前的 CPU 和 NVMe 无法跟上，需要更好的解决方案。足够快的 NVMe 可以减少内存消耗，并降低成本。

设计目标和要求

此项工作目前处于研究中的概念验证 (POC) 阶段，并非已承诺的产品。

设计目标:
- 提供新的 API 以从 GPU 访问存储 IO。
- 最大化大批量数据访问的吞吐量。
- 扩展处理无法完全适应 GPU HBM 或 CPU DDR 的超大数据集，利用更便宜的 NVMe。
- 缓解 NVMe IOPs 成为 GPU 与 CPU 瓶颈的问题。

满足要求的设计选择:
- 在数据存在临时或空间局部性时：
- GPU 内部缓存的带宽应远大于 PCIe 进入 GPU 的带宽。
- 使缓存行大小与块大小匹配，以便聚合为块访问。

• NVMe 提供的存储容量。
• 通过在丰富的 GPU 线程上发出并发访问来最大化 NVMe 带宽。

架构

该架构旨在最终消除 CPU 作为存储瓶颈。

• 请求的生成、发起、服务和消费都发生在 GPU 上。
• GDA KI 存储允许由 GPU 发起和触发的存储 IO 访问。
• 这是 Magnum IO 的一个关键支柱：灵活的抽象。

NVIDIA GNN 性能结果与我们的 POC

平衡的端到端系统达到了最佳可用吞吐量。

• 每 GPU 吞吐量 (在 A100 上):

  • 6910 CUDA cores @1.41GHz
  • 传输大小 = 4KB

• 数据查找加速通过减少 IO 瓶颈（到特征数据）来提高吞吐量。

• 透明的数据重用效益：缓存带宽 (400-600 GB/s) 远大于 PCIe 进入 GPU 的带宽 (24 GB/s)。
• IO 处理 (48 MIOPs) 跟上了 PCIe 饱和的 NVMe IOPs 速率 (6-48 MIOPs)。
• GPU 具有延迟容忍性 - 硬件上下文切换覆盖了未命中延迟。

GNN 性能

GPU 发起的 IO 可以轻易饱和存储吞吐量。

• MAG240M 数据集，GraphSAGE 模型运行在 NVIDIA A100 GPU 和 8 块 Samsung 17XX SSDs 上。
  图表显示，IO 带宽持续保持在约 25 GBps，IOPS 持续保持在约 6 Million。

当前 POC 限制

这是一个具有可扩展架构的有效概念验证。

限制：
- 规模: 仅限于带 CPU/GPU/NVMe 的单节点。
- 访问 API: 内存数组抽象。
- NVMe 加载:
- NVMe 已预加载。
- 请求总是命中 NVMe 层。

• 尚未集成到 AWS 的端到端 (E2E) 系统中。

AWS 适用性

下表比较了不同节点特征复制方法在 AWS 上的吞吐量表现：

• 原型的相关性:

  • 带宽显著超过当前通过 CPU 访问 CPU 和 NVMe 的替代方案。
  • 训练成本大大降低。
  • 提供巨大的内存地址空间并随图大小进行扩展。
  • 简化了存储编程。
  • 最大限度地降低了图分区成本。

• GPU 发起的存储未来方向的优先级:

  • 分布式支持。
  • 统一数据访问 API 以隐藏所有复杂性。
  • 预取数据以重叠计算和通信。

安全

考虑点

安全方面的考虑点包括：

• 攻击
• 分离，最小权限原则
• 信任中介

信任区域

• 控制路径由受信任的基础设施（DPU）启用。
• 数据路径（RDMA）不受限制。

权衡

该部分旨在提出问题并作为一个社区来探索技术。

• 在何处实现解决方案的选择:

  • 将客户端工作外包给 DPU（左侧）。
  • 在计算主机阈值处代理文件服务器的操作（右侧）。

• 关于解决方案的努力、鲁棒性、通用性的权衡。

DPU 作为授权的关口

凭据发送到由更受信任的 DPU 而非计算节点使用。

此图展示了 DPU 如何作为授权的关口。来自节点1（用户A，用户B）和节点2（用户C）的请求通过 DPU 路由到文件服务器。DPU 还能与调度器进行用户-节点映射。通过 DPU，可以实现更细粒度的访问控制和授权。

动态数据和静态数据

密钥分发给 DPU 而非不受信任的计算节点。

此图说明了 DPU 如何处理数据的加密和解密，无论数据是动态的（in motion）还是静态的（at rest）。节点处理明文数据，而 DPU 执行加密/解密操作。文件服务器接收加密的数据，并通过文件命令与 DPU 交互。这确保了即使文件服务器存储的数据也是加密的，增强了安全性。

鸣谢 (Credits)

• GPUDirect Storage 团队

  • Kiran Kumar Modukuri, Zhen Zeng, Sourab Gupta, Rebanta Mitra, Prashant Prabhu, Aniket Borkar, Vahid Noormofidi, Sandeep Joshi, Salah Chaou

• NVIDIA 研究团队

  • Wen-mei Hwu, Isaac Gelado, Vikram Sharma Mailthody, Zaid Qureshi

• NVIDIA GNN 团队

  • Kyle Kranen, Nicolas Castet, Onur Yılmaz, Joe Eaton

• NVIDIA GPU 通信团队

  • GPUDirect 技术: Davide Rosetti, Pak Markthub
  • 库: Jim Dinan, Sreeram Potluri

• UIUC

  • Arpandeep Khatua, Jeongmin Park

• 东京大学

  • Kazuo Goda, Tsuyoshi Ozawa, Yuya Miura

行动呼吁 (Call to action)

• 尝试 CUDA 12.2 以获取新功能

  • 更新: Batch API - 更好的性能和更低的 CPU 利用率。适用于小型 IO。
  • 新功能: 多功能 cuFile API - 适用于所有文件 IO 需求，可在 CSP 环境中使用。
  • 新功能: 异步 API - 与 CUDA 流和 CUDA 图对齐，应用程序无需等待 IO 完成即可继续工作。

• HPC 阅读器库开发者 - 请联系我们以启用 GPU IO。

• 与我们互动，分享您的使用模型和反馈
  • GPU 启动的存储
  • 存储安全合作伙伴实现