利用 NVIDIA GPUDirect Storage 充分发挥美光 SSD 对 AI/ML 工作负载的作用
简介
美光热切期待人工智能（AI）推动产生巨大创新成果。因此，我们一直在积极探索闪存技术对这一新型应用类别的影响，并研究如何与其他出色的软硬件技术相结合，通过 AI 加速创新进程。
我最近有机会在我们实验室测试了 NVIDIA GPUDirect Storage 软件的早期版本，测试结果十分惊人。然而，在深入说明测试结果之前，我想快速地介绍下相关背景。
自 2007 年以来，NVIDIA CUDA 已支持对许多不同的计算密集型任务进行 GPU 加速处理。2014 年，NVIDIA 引入了 GPUDirect RDMA，该技术允许 GPU 与网络接口卡、存储控制器和视频录制设备等各种 PCIe 适配器直接传输数据。GPUDirect Storage 在 GPUDirect RDMA 和 CUDA 的基础上进行了扩展，支持将数据直接从存储设备（例如 NVMe SSD）传输到 GPU 的内存空间。实际上，此更新减少了将数据移动到 CPU 系统内存（用于 I/O 缓冲）的步骤，这是传统存储 I/O 配置所需的步骤（图 1）。
图 1：使用和不使用 GPUDirect Storage 的数据路径比较
然而，直到最近，许多标准的数据科学库都缺乏 GPU 加速支持。事实上，常用的 Python 数据科学库（如 NumPy、Pandas、scikit-learn）都缺乏原生的 GPU 加速支持，有些甚至明确表示不打算开发 GPU 加速功能。
虽然其他库正在寻求以与 Pandas、NumPy 和 scikit-learn 兼容的方式实现 GPU 支持，但直到现在，还没有一套全面的、支持 GPU 的库集。随着基于 CUDA 的 RAPIDS 开源软件库的推出，我们现在拥有一套开源库和 API，能够完全在 GPU 上执行端到端的数据科学和分析流程。
随着这些新的 GPU 加速库（如 RAPIDS）的出现，与非加速库相比，计算性能得到了显著提升，但是我们发现存储 I/O 成为了新的瓶颈，GPUDirect Storage 就是专为解决这一问题而设计的。
尽管从逻辑层面来看，利用 NVMe 硬盘、NIC 和 HBA 内置的 DMA 引擎，直接将数据传输到 GPU 内存地址是一个简洁明了的解决方案，但其实际实施方式却有些复杂。请参阅 NVIDIA 的博客和企业通讯，特别是关于 GPUDirect Storage 的入门博客，以了解更多信息。此外，虽然 RAPIDS 是 GPUDirect Storage 的一个具体用例，但也仅仅是一个可能的实施方式。
现在，让我们在真实系统上进行一些真实的测试，探讨 GPUDirect Storage 是如何提升性能的。
测试配置
对于本文的所有测试，我采用的是 SuperMicro SYS-4029GP-TVRT，该服务器搭载了 8 块 NVIDIA V100 GPU、2 个英特尔至强 8180M CPU（每个 28 核）以及 8 块美光 9300 Pro 15.36 TB NVMe SSD。图 2 为系统的具体布局。
图 2：SuperMicro SYS-4029GP-TVRT 的 PCIe 布局
测试中使用的服务器具有一个有趣的架构特征，即 NVMe SSD 是直接连接到 CPU 的。与本地 NVMe 相比，如果使用远程存储（例如，通过 NVMe over Fabrics 访问），该系统的吞吐量可能更好。这是为什么呢？ NIC 使用的 PCIe 通道数量是 NVMe SSD 的两倍。由于 GPUDirect Storage 使用 DMA 将数据从存储设备直接移动到 GPU，因此它还可以使用 RDMA 和 NVMe-oF。如果更高性能的网络接口能够通过共同的 PCIe 交换机访问这些设备，那么相比这些存储设备直接通过 CPU 连接的方式，我们能够传输的数据量会更大，这正是该服务器所需要的。我们计划在未来深入研究 GPUDirect Storage 的性能，其远程存储设备可以通过与 GPU 连接在同一 PCIe 交换机上的网络适配器进行访问。然而，目前我们讨论的数据仅限于本地 NVMe。
性能结果
4 KB 随机读取性能
测试从一个典型的 4 KB 随机读取工作负载开始。在该测试中，每个 GPU 都从 Micron 9300 NVMe SSD 上的某个 1 TB 文件读取数据。存在一对一的关系——每个 GPU 专门从单个 NVMe 硬盘读取数据。这种关系不一定是生产系统的推荐配置方式，但在实验室中，它使不同数量的 GPU 和 SSD 的性能测试更容易。对于生产系统，可以将单个 CPU 上的所有硬盘配置为一个 RAID 组。
图 3：在 8 个 GPU 配置下，针对每对 GPU-NVMe 组合，以 4K I/O 传输大小为基准，工作线程数对 CPU 利用率和吞吐量的影响（按数据路径区分）
在图 3 中，我们发现 GPUDirect Storage 相比使用 CPU“反弹缓冲区”的传统数据路径，在性能上有显著优势。在工作程序数量较少时，GPUDirect Storage 路径虽然只是看起来略快，但 CPU 利用率也稍好一些。随着工作程序数量的增加，我们发现 GPUDirect Storage 的优势显著增加。在此配置中，当使用 64 个工作程序时，GPUDirect Storage 的吞吐量峰值达到了 8.8 GB/秒（见蓝条），同时保持 CPU 利用率相当于低于六个 CPU 内核的利用率（绿线，右轴）。相比之下，传统路径在 12 个工作程序时达到吞吐量峰值，即 2.24 GB/秒（见灰条）。然而，随着工作程序数量的增加，其性能开始下降，CPU 利用率显著上升。具体而言，在工作程序为 96 个时，CPU 利用率相当于 52 个满载的 CPU 内核的利用率（见黑线，右轴）。
数据传输大小对性能的影响
接下来，我们研究数据传输大小对性能的影响。对于此测试，每个 GPU-NVMe 对配置了 16 个工作程序。这个选择是基于之前的 4 KB I/O 测试的结果。选择 16 个工作程序是因为，这个数量恰好超过了传统数据路径的峰值性能点，但远低于 GPUDirect Storage 数据路径的峰值性能点。
图 4：在 8 个 GPU 配置下，针对每对 GPU-NVMe 组合使用 16 个工作程序时，I/O 传输大小对 CPU 利用率和吞吐量的影响（按数据路径区分）
通过图 4，我们发现，随着 I/O 传输大小的扩展，传统数据路径的固有限制得以缓解。在较大的传输规模下，吞吐量和 CPU 利用率变得相当接近。然而，确保所有访问存储的工作负载都一致地使用较大的数据传输大小通常具有挑战性。因此，对于小至中等规模的数据传输，情况与上述讨论相似，即使用 GPUDirect Storage 时，吞吐量会大幅增加，CPU 利用率也会相应地提升。
I/O 延迟
我们着眼于性能的一个更重要方面，即 I/O 延迟。对于此测试，我们再次关注 16 个工作程序，并扩展 I/O 传输大小。
图 5：在 8 个 GPU 配置下，针对每对 GPU-NVMe 组合使用 16 个工作线程时，I/O 传输大小对延迟和吞吐量的影响（按数据路径区分）
与吞吐量和 CPU 利用率一样，在处理小到中等规模传输时，GPUDirect Storage 数据路径的延迟有显著的改进。而在面对大规模传输时，其延迟表现则与传统数据路径基本持平（如图 5 所示）。此处讨论的延迟以微秒（μs）为单位，我们可以看到，GPUDirect Storage 的延迟值之低令人震惊。4 KB 传输的平均延迟为 116 μs，在 32 KB 传输时仅增加到 203 μs。对于对延迟敏感的工作负载，这种延迟特性可以显著提升应用性能。当传输大小超过 32 KB 时，延迟主要由数据传输时间主导，而不是像较小的 I/O 传输那样受到数据访问开销的显著影响。
结论
在处理中小型数据块时，GPUDirect Storage 可大幅提高总吞吐量，显著减少延迟以及所需的 CPU 内核数量。对于任何需要 GPU 加速的应用，这些改进中的任何一项都足以使该技术值得探索。当这些改进同时展现时，它们共同标志着 GPU I/O 领域的一次重大变革。在我的测试中，对于较大的数据块传输，GPUDirect Storage 并没有展现出相同的性能优势，但与传统数据路径相比，使用 GPUDirect Storage 没有缺点。
NVIDIA 的 GPUDirect Storage 技术与美光数据中心 SSD 相结合，能够加速您的 AI 解决方案，让您在更短的时间内完成更多任务。要了解美光和 NVIDIA 如何帮助您成功部署 AI 解决方案，请查看以下实用资源：
