编者按:英伟达2024 GTC 大会近日正在美国加州召开中,星辰天合 CTO 王豪迈在大会现场参与了 GPU 与存储相关的最新技术讨论,发回了本篇评论文章。
随着 GPU 单卡算力的不断提升,以及 GPU 集群规模的扩大,伴随着 Scaling Law (规模法则) 的信仰, 对于 AI 基础设施带来两个不言而喻的趋势:规模化的数据集和集群扩展 。 最近的热点主要围绕 LLM (大型语言模型)为主,但实际上 AI 在不同行业的应用场景丰富,带来了多样化的数据访问需求。
大数据集的挑战
同样对于非 LLM 的场景来说,在不断扩展的数据集下,GPU 不仅是计算“怪兽”,也是一个针对细粒度数据的高强度存储访问引擎。我们过去在互联网经常谈到 100K 问题,意味着要提供面向 10 万用户(客户端)的并发访问能力,但对于 GPU 计算场景来说,特别是每年都实现算力指数级增长的情况下,单一 GPU 集群提供 10 万的并发能力会成为常态,不管是计算和存储都会面对。
可以通过 Nvidia 对于 GPU 应用的分类来了解相应的数据集情况:
在单机 CPU/GPU 内存足以容纳的数据,在规模化数据集面前已经无法被内存容纳后,意味着每个大规模数据集的集群都需要面对大数据集的分区、缓存和节点通讯协同问题,更不用提其中的错误处理,意味着要像传统大数据系统一样构建(但完全不同的性能需求)。
GPU 的存储访问
在数据访问上,在几年前就拥有了 GPUDirect Storage,意味着 GPU 可以直接通过 NVMe over Fabric 协议访问存储,而不需要通过 CPU 参与并带来额外的内存拷贝。在去年开始,GPUDirect Async Kernel Initiated Storage (GPUDirect 异步内核启动的存储)技术更进一步减少了 CPU 和 GPU 的同步开销,使得 GPU 可以直接向内核发起请求,而不需要 CPU 代理发起。因此, GPU 对存储的单次访问来说,已经非常高效 。
在 Nvidia CUDA 生态中,已有 NVSHMEM(如下图所示)实现了 GPU 之间的内存数据通信,屏蔽了 NVLink/PCI/Infiniband/RoCE/Slingshot/EFA 的具体传输实现,极大帮助了 GPU 集群协同计算的效率,而在存储方面仍旧没有对应的 API 和实现,使得 GPU 总要面对十分具体的存储传输和协同。 这意味着需要提供一套新的 API 来处理大数据集的访问问题。
每个 GPU 线程都是存储访问的单元,意味着随着 GPU 并发度的不断提高,在一些场景,例如目前 GPU 已经直接支持的基于图的数据节点遍历,通过 PCIe 的存储 IO 处理需要高效的手段才能应对。
GNN 训练的限制
例如现有的 GNN 框架在遇到无法完全放入内存的数据集时,会直接通过内存映射特征向量文件到 CPU 虚拟地址空间,提供一种无限虚拟内存的概念,使得 CPU 上的节点特征聚合计算可以在所请求的特征向量不在 CPU 内存中时触发 page fault。如下图所示,在节点特征聚合阶段,CPU 访问映射在其虚拟内存空间的节点特征,当这些特征不在 Page Cache 中时,OS 会从存储中将包含被访问特征的页面带入 CPU 内存。
不幸的是,MMAP 方法使得特征聚合成为整个训练流程中最糟糕的瓶颈。针对 GNN 训练执行的每个阶段的性能分析显示,迭代时间明显受到节点聚合阶段的限制,正如下图所示。例如在评估中使用的最大的两个图—— IGB-Full 和 IGBH-Full,其训练阶段几乎看不见。这是因为对于大规模图,OOM 的额外成本加剧了数据准备吞吐量和模型训练吞吐量之间的差距。因此, 改善 GNN 训练性能的关键是大幅加速特征聚合阶段(即数据准备阶段) 。
随着新兴的应用领域拓展,更多的应用场景都在面对类似的问题:
向量搜索/向量数据库中的存储
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论