加速GPU与存储或内存之间的数据传输
近年来，加速GPU与存储或内存之间的数据传输与访问取得了重大突破。跨多个领域，包括健康与生命科学、石油与天然气等，客户通过采用GPUDirect™ Storage技术，在可视化、数据分析、人工智能和机器学习等框架和应用中实现了显著性能提升。此外，新的数据访问方向不断涌现，包括在存储或内存中提取数据、从GPU启动存储传输，以及对象和密钥传输，而不仅仅是传输文件。本文将概述数据传输和访问的前景，分享概念验证结果，这些结果对于框架用户和开发人员具有吸引力。
我们将介绍早期原型工作，探讨从GPU发起大量小型传输的适用性，特别是在图机器学习中的应用。由Amazon即将推出的GraphStorm项目负责人Da Zheng博士和NVIDIA的杰出工程师CJ Newburn将共同分享他们的使用案例，并讨论NVIDIA原型在他们工作中的适用性。
CJ Newburn: 欢迎来到Spring'23 GTC会议，我们将讨论加速GPU与存储或内存之间数据传输的相关内容。我是NVIDIA的CJ Newburn博士。我们将讨论一些与Magnum IO相关的新存储方面的内容，我是Magnum IO的架构师之一。除此之外，我还担任数据中心和零信任架构师等多个工作。我很高兴和荣幸能与两位杰出的演讲者分享这个虚拟舞台。Da Zheng博士是AWS的高级应用科学家，负责ML框架和算法。他主导了诸如DGL、DGL-KE、DistDGL和TGL等框架的开发。我们的朋友Harish Arora是NVIDIA的首席产品经理，负责Magnum IO以及DGX系统的存储和网络。
在本次会议中，我们将讨论与NVIDIA加速存储IO相关的一些新进展。我们将首先简要介绍Magnum IO，并介绍Magnum IO的一个重要组成部分GPUDirect的一些关键更新。在过去的几年里，我开始对存储产生了一些兴趣，使用GPUDirect Storage的过程非常有趣。我将为你介绍一些与NVIDIA在存储领域的创新相关的内容。技术重点是GPU启动存储，这是一个我将介绍的新产品。最后，我们将讨论一些安全方面的考虑。
我们在Magnum IO的一个基础部分GPUDirect中有一些新的发展。顾名思义，GPUDirect为数据进出GPU内存提供了直接路径的机会。在CPU中进行分段是可选的，只有当它能够带来更好的性能时，我们才这样做。我们谈论的是GPU内存，但随着内存变得越来越可迁移，可移动页面可能在CPU或GPU时，我们仍然称之为GPUDirect。所以，GDS还为只能在CPU中的内存提供支持。GDS赢得了通用性奖，涵盖的内容比GPUDirect的其它部分更多。
网络和存储IO涉及两个组件。第一个是工作请求的准备或工作设备，例如wookiee和command cube，第二个是何时触发工作请求，即何时将工作请求交给或与IO设备同步。最常见的是我们按门铃。那么这些组件如何映射？最初，GPUDirect的准备和触发都在CPU上进行。
然后我们在GPU上启用了触发，同时CPU继续进行准备工作。最新的变化是在GPU上既准备IO，又触发IO。随着我们在这个表格系统中从左向右转移，GPU的自主性不断增加。由于在右边两列中至少有一个准备或触发发生在GPU上，因此我们称之为GPUDirect Async。GPUDirect Async（GDA）和GPUDirect Async Kernel Initiated（GDA-KI）分别用于网络和存储，都是新的。我们将在本次演讲中介绍GPUDirect Async Kernel Initiated Storage（GDA-KI Storage）。我们将看看GDA-KIs这个名字是否能够被接受。欢迎你点击以下链接查看与网络NVSHMEM和新产品GPU NetIO相关的GDA-KIN和GDA-KI Network的博客。
Harish Arora: 大家好，我叫Harish Arora。我负责Magnum IO的产品管理，其中包括GPUDirect存储。在本节中，我将简要介绍一下产品的概况和最新更新，以及我们不断扩大的合作伙伴生态系统以及一些客户的使用情况。这张幻灯片显示了GPUDirect Storage的核心原理以及对应用程序的好处。传统的GPU应用程序将数据传输到GPU的方式是一个两步过程，如左侧所示。这会产生两倍的DMA成本，并且需要使用系统内存中的bounce缓冲区。使用bounce缓冲区会降低系统内存带宽，因为它们会与其它应用程序竞争内存访问。而GPUDirect Storage，如右侧所示，创建了存储端点与GPU之间的直接DMA传输路径。这导致了单一的DMA传输，而不是两个。不再需要bounce缓冲区。系统内存可供其它应用程序进行常规使用。
GPUDirect存储是基于API的产品。它的API与Posix API类似，易于被使用Posix API的开发人员采用。我们与许多业界领先的存储公司合作开发了我们的合作伙伴生态系统。其中一些公司甚至共同开发了客户端软件，以集成GPUDirect Storage，并将他们的代码贡献给开源社区，以造福他人。感谢DDN团队，我们的合作伙伴生态系统不断增长，因为我们的共同客户要求这样做。随着客户采用GPU并扩展其使用NVIDIA软件进行加速和科学计算工作负载的范围，他们下一个瓶颈是IO。
我们已经将GPUDirect Storage与许多NVIDIA的软件产品集成在一起，这些产品都可以在NGC上免费使用。这些集成了GPUDirect Storage的容器为我们的存储合作伙伴提供了提供验证的存储解决方案的需求。我们非常感谢IBM的整个Spectrum Scale团队积极与我们合作。最近，我们为Spectrum Scale客户提供了GDS启用的权利支持。我们将继续执行共享的路线图。你还可以参加HPE Ezmeral团队的会议，了解我们与HPE Ezmeral团队的最新合作情况。最后但并非最不重要的是，我们很高兴与PureStorage的FlashBlade团队合作，以集成GPUDirect Storage。Pure团队已升级其硬件堆栈以支持GDS。双方现在正在共同升级软件堆栈。我们将很快分享更多详细信息和公告。
最后，我们很高兴报告，我们的存储合作伙伴正在采用支持RDMA的网络Fabric进行存储访问。支持RDMA的存储Fabric是许多加速和科学计算部署的关键区别。反向迁移是一种通过计算前向和后向波传播来创建地下的精确3D图像的地震成像技术。NVIDIA加速的RDM实现可通过NV在线作为Energy SDK Samples的一部分进行NDA提供。NVIDIA与许多石油和天然气组织合作，以使GPU在许多地震应用程序中得以使用。我们的客户报告说，他们的大型1000多个GPU集群上的RDM代码占据了超过90%的GPU时间。我们团队的性能取决于每小时或每天处理的业务数量。我们的团队在HPC代码中受到了严重的IO约束。因此，任何可以改善IO性能的技术也可以改善整体性能。在前向传播阶段生成的数据是临时的，并且在后向传播阶段很快被使用。
过去，小型问题的规模每帧只生成几千兆字节的数据。这就是为什么系统DRAM被认为是保存快照的有效选择。随着问题规模的增加，系统 DRAM 不再是一个可行的选择，正如我们将看到的。GPUDirect 存储提供了出色的加速效果，因此可以使用本地NVMe SSD来存储快照。
在这张幻灯片中，我们比较了用于RTM的各种存储后端。对于小规模问题，快照数据可以存储在系统DRAM中，但仍然太大了。将数据存储在系统DRAM中会产生两次缓冲区拷贝的成本 - 从GPU到一个bounce缓冲区通过拷贝，然后从bounce缓冲区到应用程序缓冲区通过内存拷贝。这两个操作都会增加保存快照所需的时间。如你所见，使用GPUDirect存储将快照存储在本地NVMe上是一个更好的选择。它需要的时间更少，而且比高价值的数据便宜得多。
随着问题规模的扩大，不再可能使用系统DRAM来保存快照。无论是由RTM代码实现还是在GPUDirect存储软件内部实现的数据压缩，都将进一步提高性能。我们正在开展相关工作。
GPUDirect存储已被许多科学和加速计算应用程序使用。我们将重点介绍两个最近的用例和客户评估。我们感谢KAUST超级计算核心实验室的Mohsin博士和Saber博士领导的工作，以及与Brightskies的Maryam Hashem和Ahmad Nasser的合作。在IBEX集群中对GPUDirect存储进行了评估。
KAUST使用预堆叠时间迁移（PSTM）成像技术将大型地震反射数据集转化为地球内部的图像。该成像技术在计算上很简单。但由于地震数据集的增加，需要处理存储在称为segy的行业标准文件格式中的大量数据。完整的迁移分析工作流需要读取快照，处理数据，并以TB级的速度将检查点写入segy文件。
KAUST和Brightskies团队分析了PSTM应用程序的运行时间，并发现大部分时间都用在将数据读入GPU进行计算上。该团队将GPUDirect存储与其PSTM应用程序集成，并观察到从存储中读取数据的速度提高了20%以上。他们与我们分享了他们的观察结果和改进方向。
他们的实验是在早期版本的批处理API上进行的。从那以后，我们已经显着提高了性能，并继续与他们合作提供额外的好处。GDS在大型IO请求大小方面表现最佳。将批处理IO大小从8千字节增加到156千字节，我们可以获得大约5倍的加速。KAUST团队将其应用程序更改为使用4千字节对齐的IO请求，并通过对齐获得了约15%的加速。
我们已经将GPUDirect存储与许多应用程序集成在一起。共同的主题是这些GPU应用程序存在IO瓶颈。必须将大量数据传输到GPU进行预处理、实际计算工作和后处理，然后再写回存储。从流程中去除系统内存bounce缓冲区对性能至关重要。
如果你发现GPU利用率很低，同时正在等待数据，请尝试GPUDirect存储。你可以使用像insight profiler这样的工具来测量GPU利用率。GPUDirect存储确实具有一定的要求。应用程序数据不得在系统内存中进行任何处理。IO逻辑不应使用系统页缓存。在包括PCI开关的系统上观察到了最佳性能，以便DMA传输可以在GPU和存储之间直接进行，无论是本地NVMe还是支持RDMA的高性能文件系统。
许多我们的合作伙伴应用团队希望他们的应用程序在CSP环境中运行，其中没有RDMA可用的存储，CSP实例是虚拟机而不是裸机实例。底层物理服务器可能没有PCI开关，始终由其超级管理器控制。应用程序通常需要使用标准文件格式和阅读器库。这些文件格式通常是为在CPU上处理而结构化的。所有这些因素的结合促使我们扩展了GPUDirect Storage的范围，加入了新功能。
目前，GPUDirect存储仅支持GPU内存。基于应用程序开发人员的反馈，我们正在扩展支持系统内存IO，作为POSIX的替代方案。有了今年晚些时候推出的新功能，你将能够使用单个API进行所有文件IO。相同的cuFile读取和cuFile写入API将接受使用malloc分配的系统内存指针。我们正在积极与各种NVIDIA团队和HPC社区合作，以集成GPUDirect Storage。我们希望通过集成到NVIDIA的VMIs中在CSP环境中提供IO加速。GPUDirect Storage已经是即将推出的DGX OS 6版本的一部分。它也包含在NVIDIA AI Enterprise 3.0中，随着3.1版本的发布，将很快提供更多更新。正在开发的多个以DGX为重点的垂直领域解决方案将包括GPUDirect存储作为关键差异化因素。
CJ Newburn: 你是不是很希望在午餐时间完成你的推理工作，而不是整天忙碌？或者在训练更简单的模型时获得更多的存储IO性能提升？GDS可能会有所帮助，但前提是存储IO在关键路径上。这在推理或层数较少的训练中更有可能，因为它们的计算与IO的比率较低。随着推理批处理大小的增加，收益也会增加，因为每个样本的计算量减少，总数据线性增加。这导致较大的批处理大小受到带宽限制，从用于推理存储的两个南北NIC的每秒50千兆字节开始。
存储空间，我们在GDS方面有了一个很好的开端，但还有更多的工作要做。Harish谈到了CUDA 12.2及更高版本中提供的兼容性增强功能。我们将详细介绍。另一个变化是在CUDA 12.0.1中将IO集合从单个实例移至批处理。我们正在CUDA 12.2中引入一些实验性异步API的支持。最后，我们将讨论存储IO的控制源，一度是CPU的专属权，现在正在转移到GPU和DPUs。我们有一个关于GPU启动存储的概念验证要介绍。
我们从GDS的首要关注点是获得性能提升。一旦人们开始使用cuFile API，他们会要求始终随时使用它们。但首先，我们需要确保它们始终正常工作。例如，不仅仅是对于在单个GPU的cudaMalloc中连续分配的缓冲区，还包括跨GPU设备进行分片处理的cuMemMap。不仅仅是与GPU内存一起使用，还包括CPU内存。现在，即使某些系统上仍然会分段内存，我们也必须处理内存变得越来越可移植的情况。还有一些其它形式的通用性实现，如非对齐缓冲区和过大以适应GPU Bar 1缝隙的缓冲区，使事情在像ACS和IO NMU这样的CSP实例中工作，以及使GPU-DPU卡收敛。最后，还有Grace-Hopper统一内存。
你听说过DPU（数据处理单元）吗？它们有一个网卡、SOC和一堆ARM核心。我们有一种叫做融合卡的GPU版本，也有一个GPU。除了GPU本身外，没有PCE开关。我们测量了通过NIC到GPU的远程存储的GDS和非GDS性能。根据IO大小，我们看到GDS在没有负载的情况下速度提高了1.1到1.7倍，CPU利用率负载减少了1-8倍，非常小。当我们同时添加来自流的负载时，吞吐量较低，但速度提高要更一致一些。
Magnum IO的一个重要特点是灵活的抽象。使用cuFile批处理API，我们邀请用户一次提交一堆请求。我们在这些接口中进行了效率优化。一个批次可以包括对一个打开文件或多个打开文件的任意混合的最多128次读取和写入。该API不支持CUDA流或CUDA图形异步，但在使用IOCTL快速到达NVIDIA内核驱动程序NVIDIA-fs.ko之后会迅速返回。该驱动程序在每个请求完成时收到回调，它在用户可以拉动的矢量中填充完成位。因此，这是同步提交，异步无序完成。这里有一些优点。首先，与每个IO使用线程相比，我们用一个批处理每个批次摊销了内核调用。当提交开销相对于传输成本较高时，也就是对于大量小IO时，这有助于减小开销。其次，相对于使用Linux AIO功能提交一批请求，我们让应用程序可以根据需要随时轮询用户空间，而不是持续轮询以完成，从而降低了CPU利用率。或者如果AIO已配置为使用中断而不是轮询，我们可以从更快的响应时间中获得较低的延迟。
一些GDS用户面临的一个关键挑战是通过线程生成并发的cuFile调用，这有点困难。但使用一个线程来提交多个请求可以使用非线程化的代码实现一些并发。顺便说一下，从CUDA 12.0.1版本开始，我们支持线程轮询在我们的实现中，可以将大型顺序IO无缝拆分为并发但高效的16兆字节的顺序块。请记住，如果我们使用cuFile批处理或大量cuFile线程提交了相同数量的工作，就没有并发性的神奇增益。但我们确实减少了开销。对于小IO来说，开销最重要。看看左图，你会发现我们在较小的IO大小下获得了较低的吞吐量，批处理和没有批处理的CPU利用率比率可以高达5倍。因此，在大小之间，我们目前可能会失去CPU重新利用效率。这是一个相对较新的功能。我们仍然在使用自适应和预测技术的轮询强度，所以你可以期望随着时间的推移而改进。因此，即使在小尺寸上吞吐量略有滞后，这对于整个系统吞吐量来说也是一个胜利。
东京大学的研究人员在仅有一台驱动器且容易饱和的消费者系统上尝试了cuFile批处理，没有PCIe交换机。他们将Linux AIO获取的数据直接存入CPU进行了比较，这是一种比GPU更短的路径。与Linux AIO相比，cuFile批处理的性能不太好。但请注意，CPU利用率慢了多达9倍。
我们谈到了批处理API，并指出它们具有同步提交但异步完成的特点，并且它们分离了提交轮询和完成轮询。cuFile API不与流绑定，因此如果它们依赖于在GPU中运行的内容，CPU必须首先与GPU进行显式同步。另一种选择是使用异步提交在流的上下文中排序工作。这有时被称为延迟执行，因为程序员告诉系统要做什么，系统可以耸耸肩，继续进行其它工作，直到该操作到达流工作队列的头部。使用流或更一般的图形，GPU之间的项目同步可以在靠近GPU硬件的地方发生，而无需进行完整的往返到CPU。正如我们一开始讨论的那样，异步意味着相对于CPU有更大的自主权。这些实验性API已经公开发布一段时间了。实现即将推出到你附近的CUDA。
好吧，让我们退一步，看看NVMe存储。谁来控制它？以及如何以及具有多大程度的异步性？让我们看看三种选择--CPU、DPU和GPU。
在第一种情况下，GDS，CPU准备并触发IO，编排将数据的NVMes DMAs到GPU。GDS绕过CPU，实现了更大的带宽和降低的CPU利用率。
在第二种情况下，只有一堆闪存，远程代理通过网络向DPU发送NVMe命令，DPU将命令放在NVMe可见的位置，并按门铃。NVMe DMA将数据读入DPU的内存中。DPU修复并将其通过网络运送。DPU正在替代NIC。PCA交换机、CPU以及作为DPU和NVMe之间的分段缓冲区的CPU内存。如果NVMe支持CMB（控制器内存缓冲区），甚至可以跳过使用DPU的内存，这将非常酷。DPU可能以较低的成本和更多的专业功能来最大化本地PCIe网络带宽。
最后，在右侧，我们有一个对推荐系统、图ML、图形神经网络等可能感兴趣的案例。GPU完全异步准备和触发操作，与CPU无关。你可以使用GPU来加速总吞吐量，并利用线程并发性来最大化应用程序到GPU的带宽，其数据由NVMe支持。
在许多应用程序中，需要大量的细粒度访问。如果我们想要最大化吞吐量，我们需要大量的并发性。GPU的线程并发性远远超过CPU。我们看到CPU利用率饱和，而试图向GPU提供数据。我们的客户最感兴趣的是将数据提供给最快的计算单元--GPU。数据不仅在那里消耗，而且还可能在那里生成数据请求。通过CPU将数据提供给GPU成为瓶颈，如Da很快将要展示的那样。整个系统的速度不能快于发生几件事的速度。数据被采样以生成数据请求，可以在GPU内部的高速缓存中查找引用，可以通过NVMe存储提供数据请求，以及计算获取的数据的速率。
GPU的优势是什么？让我们再次看看最大化各个阶段的吞吐量。
生成请求的线程更多，同时访问缓存的线程更多，且容忍延迟，生成NVMe请求的线程更多，以及消耗数据和其它加速功能，如张量核心的线程更多。因此，有许多需要大量来自GPU的细粒度访问的用例。我们是否甚至可以像之前提到的那样让GPU启动存储？我们列出了六种情况。这些情况通常需要大量的小IO。GNN和Rexus相似。其它用途跨度相当广泛。为了更好地理解好处和挑战，我们邀请了AWS ML框架和算法主管Da Zheng博士加入我们，讨论了第一种情况的示例，即GNNs。
在工业界有许多可以表示为图的应用程序。在欺诈检测的情况下，我们可以将所有客户、设备、信用卡和位置连接到一个图中。为了检测欺诈用户，这是一个节点分类问题。对于电影推荐，我们可以将用户和电影连接起来形成一个二部图。我们需要预测用户喜欢观看哪些电影。这是图建模中的典型链接预测问题。工业界的大多数图问题都是节点预测问题或边预测问题。而且，大多数工业界的图都非常大。因此，我们需要一种成本效益的方法来为这些任务训练图机器学习模型。图机器学习是从图数据中学习节点、边和图表示并进行预测的最先进的方法。要计算节点的表示，GNN查看节点的自我网络，即由从目标节点到K跳邻域内的顶点形成的诱导子图。在给定自我网络的情况下，GNN使用函数来计算目标节点的嵌入，方法是使用自我网络中的信息。该信息包括自我网络的图结构以及自我网络的节点和边的特征。
一些早期的GNN研究人员大约7到8年前开始。在过去的几年中，它们已经起飞。GNN已经成为深度学习研究中最热门的领域之一。这个图表分析了ICML 2020提交的关键字频率。如你所见，图神经网络是年度增长最快的主题。
谁使用GNN方法？第一个问题是，我们如何训练GNN模型？我们基本上使用GNN模型的培训小批量。然而，GNN的小批量采样与其它深度学习模型的小批量采样不同。在采样了一小部分微小节点以形成一个小批量后，我们需要提取其自我网络，这构成了我们针对目标节点的计算图。
为了计算具有两层GNN的节点1的最终表示，我们需要首先在第一层聚合其邻居2和4的消息。然而，为了计算节点2和4的第一层表示，并聚合其邻居1、7和8的消息，并输入表示。因此，这产生了一个三层树。这三个的联合构成了一个小批量。只要小批量涉及少量节点，我可以在GPU上高效地计算它们。
我们开发了一个名为DistDGL的系统，以支持在多台机器上进行GNN小批量训练，并将GNN训练扩展到非常大的图。当图太大而无法存储在单台机器上时，我们需要对图进行分区，并让每台机器存储一个图分区。DistDGL提供了两个组件，以分布式方式训练GNN模型。它具有从集群中分布式图中采样小批量的采样组件。它具有存储组件，该组件跨机器存储节点特征和边特征，并在构建小批量时获取这些特征。
有了分布式小批量采样和分布式节点和边特征存储，我们现在可以让训练者从每个GPU上获取并执行小批量计算，并估算模型参数的梯度。在实践中，我们在这种体系结构中部署DistDGL组件。我们在同一台机器上运行服务器进程和训练进程。服务器进程存储每个图分区的图结构以及相应的节点特征和边特征。
在先前的设计中，我们将所有数据存储在CPU内存中。为了减少内存消耗，我们可以将图数据的一部分潜在地存储在NVMe上。根据我们的设计，我们可以将节点和边的特征存储在服务器进程中的SSD上。我们可以突出显示小批量采样中数据访问的复杂性。使用此采样抽象，用户训练代码不需要告诉图数据是存储在GPU内存、CPU内存还是NVMe中。
我们使用一些真实世界的数据集来展示将节点特征和边特征存储在NVMe上的好处。OGBN-papers100M图是一个引用网络。它有1亿个节点和16亿条边。每个节点有128个特征。如果我们将节点特征存储在NVMe上，可以将CPU内存消耗降低52%。MAG-LSC图是另一个引用网络。它具有多个实体类型和关系类型。它有2.4亿个节点和34.4亿条边。每个节点有768个特征。如果我们将节点特征存储在NVMe上，可以将CPU内存消耗降低78%。因此，内存消耗的减少与节点和边特征的丰富程度密切相关。
在实践中，工业界的图要大得多。我们看到拥有数百亿个节点的图。每个节点都与非常丰富的特征相关，例如来自文本数据的嵌入。在未来，我们可能会看到更大的图。因此，我们期望将节点特征存储在NVMe上可以帮助我们减少可扩展的GNN培训的CPU内存消耗，因为NVMe比CPU内存或GPU内存便宜得多。如果其性能能够跟上GPU培训速度，那么我们可以在数十亿节点或甚至更大的图上实现更具成本效益的GNN培训解决方案。
GNN小批量训练通常包括三个步骤：采样小批量，从机群中的一组机器复制节点和边特征到GPU，以及小批量计算。数据复制吞吐量要求在每个步骤中测量。数据复制吞吐量基本上显示了如果我们要跟上小批量采样速度或小批量计算速度，我们需要多快地将数据复制到GPU。
有两种从网络复制数据到GPU的选项。第一种选项是将节点特征存储在CPU内存中，从网络复制数据到本地CPU内存，然后将所有数据复制到GPU。另一种选项是将节点特征存储在NVMe上，从网络复制数据到本地内存，然后将所有数据复制到GPU内存。第二列和第三列显示了这两个选项的实际数据复制吞吐量。我们可以看到数据复制是瓶颈。如果我们想要减少CPU内存消耗，将节点特征存储在NVMe上，并使用mmap，吞吐量实际上非常低，数据复制完全成为瓶颈。因此，如果我们真的想要使用NVMe进行分布式GNN培训并降低成本，我们需要一种更好的方法来将数据从NVMe复制到GPU内存以进行输入。
谢谢你这个激动人心的概述，Da。我们想介绍一个针对Da刚刚描述的问题的系统。目前，它只是一个概念验证，尚未成为一个确定的产品。我们有几个设计目标，我们正在追求。我们目前没有API来直接从GPU启动存储访问。如果你看一下上面讨论的各种用法的特征，我们真正需要的是IOP。最大化来自小数据项大量请求的整体吞吐量。感兴趣的应用程序的数据集已经很大，并且正在变得越来越大。它们不适合GPU高带宽内存，甚至不适合许多节点CPU内存的组合容量。我们希望能够透明地将数据存储在NVMe中。嘿，这便宜，更小，更冷。Da显示从NVMe获取数据通过CPU是一个瓶颈，我们想通过使用GPU来管理访问来减轻这个瓶颈。我们希望得到你的用例和意见，以完善这些目标。
因此，这些目标只是一些设计要求。我们正在尝试通过16 PCIe连接从外部将数据传送到GPU，这在Gen 4上约为25GB/秒。但是，如果我们可以将数据保留在缓存中，如果只有空间或时间局部性，它可以提供更高的吞吐量。这值得一试。如果使缓存行大小与块大小匹配，例如4KB，那么对同一缓存行的多个访问将合并为单个NVMe访问，从而提高了有效吞吐量。NVMe提供了廉价的存储容量。丰富的GPU线程帮助我们提高发出NVMe访问和隐藏长延迟的并发处理。
让我们来看看这个系统。这个简化的图表显示请求是在GPU上制定的，GPU准备好了引用并从GPU触发它们。你永远不需要离开GPU内核。GPU发起的存储体系结构迈出了朝着摆脱CPU的自主性的显着步伐。GPU应用程序找出了要请求的内容，并直接从GPU的缓存中读取。缓存用于尽可能多地提供请求的服务，为数据中可能存在的任何时间或空间局部性创造了机会。缓存未命中被组合、排序并提交到存储系统。私有NVMe重新存储。控制消息和数据消息都传递给存储系统。
我早些时候谈到过GPUDirect及其异步变种，特别是内核发起的那种，它可以从GPU触发存储IO。这是一个示例。我们称之为GPU启动存储。已实施并进行了测试，以确保它是平衡的，除了底层存储和GPU的性能之外，没有任何瓶颈。
让我们将其分解为各个阶段，并查看每个阶段的IOPs或数据带宽的测量。为了论证，我们将假设NVMes正在提供4K块，尽管我们也可以跟上512字节块大小。首先，我们询问Da所描述的采样阶段如何与管道的其余部分创建请求。Da在基于CPU的系统上以T4 GPU为特征显示了4.7GB/秒。在DGX A100上运行的NVIDIA GNN系统正在生成以每秒4500万个操作来消耗请求，这将转化为约4K的特征大小约为180GB。相当高。如果命中，缓存是否能跟得上？是的。它是每秒600GB。即使未命中，我们测得它以1亿IOPs的速度传递请求，不是瓶颈。
接下来是IO处理，它处理缓存未命中，创建NVMe引用并提交它们。它能跟上吗？是的，4800万IOPs大于初始提交的4500万IOPs，这还不包括缓存和合并的减少。我们只需要去NVMes。正如我们稍后将展示的，我们可以饱和Gen 4 PCIe企业级NVMes。仅仅是每秒6百万的IOPs在4K时达到24GB/秒的极限。即使我们使用512字节块大小，我们的IO处理仍然可以以4800万IOPs的速度跟上。NVMes将数据反馈到GPU，只有1 x 16连接，我们饱和了。这比NVIDIA GNN的应用程序能够消耗的要少得多，因此我们的原型系统的缓存集成到GPU中以最大化带宽，使用大量线程来增加并发处理，并且具有耐受延迟的核心，这些核心非常适合容忍不同的线程和停滞的线程，所有这些都将在廉价的NVME中提供一个令人瞩目的新的性能潜力。这是我们持续带宽的图片，将NVMes的PCIe最大化。
我们与你分享的只是一个早期的研究原型，具有GPU直接异步内核发起的存储。我们尚未扩展它。它只是一个节点。我们从一个简单的内存数组抽象开始访问缓存。就像Da的实现一样，我们预加载了所有需要的数据到NVMes中，以确保所有请求都肯定会命中NVMe层。其它一些用例将推动我们对其进行概括。最后，我们还没有将系统集成到完整的端到端应用程序中，但这是下一步。我们很高兴继续前进。那么，Da，你觉得这对你有用且有前途吗？
Da Zheng：通过NVIDIA的所有创新，我们现在可能可以使用GPU启动的存储系统来加速分布式GNN培训的特征复制。我们预计，通过这种创新，我们可以获得高达24GB的数据复制吞吐量。这对我们很重要，因为GPU-initiated存储生成的吞吐量超过了GPU中的小批量计算所需的吞吐量。因此，特征复制将不再成为分布式GNN培训系统的瓶颈。
这将为我们提供一种更具成本效益的大规模处理GNN模型的方法。NVMe具有非常大的容量，因此我们可以使用少量机器来扩展到非常大的图形。在某些情况下，这可能还可以避免大型图形的昂贵图形划分。它还提供了一个简单的编程接口，用于如何从NVMe访问数据。GPU启动存储仍然在不断改进中，因此我希望尽快支持分布式计算。我还希望能够获得统一的数据访问API和异步数据预取。
CJ Newburn: 现在我们要大幅转变话题，讨论与存储相关的安全问题。从安全角度来看，存储可能出现什么问题呢？事实证明，这是许多数据中心都关注的最大漏洞之一。让我们看看一些攻击以及在遵循零信任原则的最小权限情况下引入DPU作为受信任中介时我们可以采取的措施。NVIDIA是一家数据中心公司，所以让我们将存储放在数据中心的背景下看看。我们有计算主机、基础架构、网络和存储。用户代码在哪里运行？在计算主机上。我们信任吗？如果应用程序可以打破其容器并取得主机的root权限，那就不能信任。即使虚拟机也可能被打破。因此，如果它在那里获取了root权限，并且我们不小心的话，它可能会对整个数据中心的其余部分造成严重破坏。我们如何限制它？在过去，如果你是一位想要保护羊免受狼袭击的牧羊人，你会将它们放在一个畜栏中，并趴在入口处作为羊栅栏，狼必须跳过才能进入。不能偷羊。我们可以使用DPU这样的方式。它将成为最受信任的基础架构的一部分，不可从主机VMC访问，而是位于主机门槛的正前方，与其PCIe连接，具有一种单向镜子。然后，我们可以通过DPU运行所有外部连接的控制，以确保它们是安全的，但仍具有直接的无阻碍RDMA连接。NVIDIA有“RDMA无处不在”的口号。所以现在，主机除非正在执行DPU批准的操作，否则无法操作存储。
所以让我们看看与存储相关的交互。要与存储服务器通信，你需要建立连接。你可能要做的第一件事之一是挂载文件系统。一旦打开文件，你需要将文件描述符、偏移量和大小的元组映射到filer上的块或键中。所以如果我是用户A，并且我有权限访问文件X上的块17到34，该文件X属于该文件X，那么谁能阻止我将文件错误地翻译回块163，该块属于文件Y，并要求我提供它呢？在许多文件系统中，根本没有任何机制。即使访问是合法的，也可能存在要对文件进行加密的管理员策略。有什么阻止我与想要访问的人共享密钥，如果我是在进行加密操作的人？现在，假设为了成为数据中心的良好成员，我应该使用低于计算机网络IO的低优先级的存储IO服务级别。
在你的经验中，人们是否总是在要求降低优先级时都按要求操作？所以我们刚刚提出了许多情况，根据情况，一个具有root权限的主机或恶意行为者，或者可能只是一个贪婪的行为者，如果让他们自行其事，可能会规避政策和保护措施。好吧，我们为什么不将我们希望信任的活动从用户可能获得控制权的设备上移到更难为其获得控制权的DPU上呢？因此，我们可以使用一些解决方案，包括向filer添加技术。我们还可以减轻存储供应商的负担，一些供应商告诉我们，如果我们这样做，他们会非常高兴，并且在DPU上解决安全问题，以便他们可以最小化对其filer系统中的遗留代码的更改。一些供应商甚至正在考虑将filer的部分部署到DPU上，这也有助于降低bond成本。显然，这里存在许多关于工作量、稳健性、解决方案的通用性、可维护性的权衡。我们正在积极研究解决这些问题的以数据为中心的解决方案。我很愿意讨论客户内部的使用模型和优势，并积极参与合作伙伴的实现工作。
我将简要介绍存储安全性的两个示例。假设我们有两个节点。用户A和B被安排在节点1上运行，而用户C被安排在节点2上运行。用户A从节点1访问filer是完全合法的，用户C从节点2访问也是合法的。用户A从节点2访问？好吧，那就是钓鱼。调度程序更明智，它可以通知DPU检查合法性，并在到达filer之前阻止访问。对于许多文件系统，进程的保护和计算节点的完整性被视为安全性的依赖。我不想生活在那个世界中。我想要更稳健的东西。一个真正普遍的情况是随着机密计算的兴趣增加，你可能会听到关于这个问题。节点上的数据可能是明文的，但可能有一个管理策略，要求在传输过程中和存储期间对数据进行加密。你相信计算节点能够获得密钥并不会泄漏它们吗？越来越多地不信任。你是否更信任DPU，它是受信任基础架构控制计划的一部分来执行？是的，你可能选择使用不同的方法来处理数据有效负载，而不是处理命令。DPU可以知道如何做到这一点。
这只是两个示例。还有更多示例。很乐意与你讨论这些问题。我们要感谢许多为这里提出的工作做出贡献的人。我们已经列出了他们的名单。非常感谢你的所有工作。非常感谢你加入我们。
我们邀请你尝试CUDA 12.2以使用其新功能。它包括对批处理API的更新，具有更好的性能和更低的CPU利用率，非常适合小IO和一些新事物，例如用于所有文件IO需求的多功能cuFile API，可在CSP环境中使用，并与CUDA流和CUDA图对齐的异步API支持，使应用程序可以在等待IO完成之前继续工作。对于所有HPC读取器库开发人员，请与我们联系以启用GPU IO。并让我们分享你的使用模型和反馈，例如关于GPU-initiated存储、存储安全性使用模型和合作伙伴实施等。
谢谢大家的聆听，祝大家工作顺利，生活愉快！
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解