阿里云PAIx达摩院GraphScope开源基于PyTorch的GPU加速分布式GNN框架

本文涉及的产品
模型在线服务 PAI-EAS,A10/V100等 500元 1个月
交互式建模 PAI-DSW,5000CU*H 3个月
模型训练 PAI-DLC,5000CU*H 3个月
简介: 阿里云机器学习平台 PAI 团队和达摩院 GraphScope 团队联合推出了面向 PyTorch 的 GPU 加速分布式 GNN 框架 GraphLearn-for-PyTorch(GLT) 。

作者:艾宝乐

导读

近期阿里云机器学习平台 PAI 团队和达摩院 GraphScope 团队联合推出了面向 PyTorch 的 GPU 加速分布式 GNN 框架 GraphLearn-for-PyTorch(GLT) 。GLT 利用 GPU 的强大并行计算性能来加速图采样,并利用 UVA 来减少顶点和边特征的转换和拷贝。对于大规模图,GLT 使用了生产者-消费者的架构,通过异步并发的分布式采样和特征查找以及热点缓存功能支持在多个 GPU 或多个机器上进行高效的分布式训练。接口上,GLT 保持了 PyTorch的风格,并且和 PyG 兼容,只需少量代码修改就可以加速 PyG 的单机训练程序,或者将 PyG 单机模型改成分布式训练。此外,GLT 还提供了灵活的分布式训练部署以满足不同的需求。

开源地址:https://github.com/alibaba/graphlearn-for-pytorch

文档地址:https://graphlearn-torch.readthedocs.io/en/latest/index.html

背景介绍

图神经网络作为一种图数据上表示学习的方法已经被广泛应用在图相关的各个领域,在电商推荐、安全风控、生物分子等领域取得了实际落地。图神经网络由于其独特的数据处理逻辑和神经网络计算逻辑,需要有专门的学习框架来支持训练。PAI团队之前开源了大规模工业级分布式图学习框架 GraphLearn(https://github.com/alibaba/graph-learn)。GraphLearn 以 TensorFlow 1.x 系列为主,采用 ps 架构的异步训练模式,支持十亿节点,百亿边规模的大规模异构图分布式训练,应用于阿里内外部若干业务场景。随着PyTorch 的流行,其更加灵活的贴近 Python 的接口,简单易调试等特性使得算法开发者更倾向于使用 PyTorch 开发模型。DGL 和 PyG等基于PyTorch的开源GNN框架以单机为主,无法支持大规模图的分布式训练。

此外,由于 GPU 并行计算的优势,图神经网络使用 GPU 训练比 CPU 训练有数倍的提升。然而常见的图神经网络框架将图拓扑数据和特征存在内存里,使用CPU进行采样和特征查找并将数据拷贝到GPU进行神经网络训练,这个过程中图采样和特征查找部分很容易成为整体训练的瓶颈。下面我们以大规模图上典型的训练流程为例对训练过程的性能瓶颈进行分析说明。

一个典型的GNN训练流程[1] 包括:

  1. 子图拓扑采样,采样多跳邻居并组成子图;
  2. 查询子图里节点或者边的特征;
  3. 将子图格式转换成神经网络训练需要的格式并且拷贝到GPU显存中;
  4. 对原始特征进行处理,比如离散特征进行embedding lookup;
  5. 邻居聚合;
  6. 节点更新。

其中,3和4为可选步骤。常见的 GNN 模型神经网络参数相对来说比较小,因此计算量也比较小,瓶颈通常在1-4步,具体来说主要是I/O操作,包括通信,数据拷贝和格式转换。这导致即使使用GPU进行训练,GPU的资源利用率也很低,整体吞吐以及扩展性很难提高。

综上所述,我们需要一个高效的基于PyTorch 的分布式 GNN 训练框架,能够充分利用 GPU 等硬件资源,能够基于图的数据分布性质,结合不同算法模型和并行策略做相应优化,减少通信和数据转换耗时,提升整体吞吐。

关键设计

设计初期,我们和 Quiver[2] 团队合作针对 GPU 采样的可行性进行了初步探索,发现 GPU 采样相比 CPU 能够带来数量级的提升。此外,为了减少特征在 CPU 内存和 GPU 显存之间的拷贝开销,特征可以直接存储在 GPU 显存里。然而对于规模比较大的数据来说,显存无法存储所有特征数据,因此我们用 UVA 技术来进行特征的存储,相比直接内存存储也有数量级的性能提升。工业界的图规模很容易突破单机的极限,因此我们进一步设计了分布式训练框架。具体来说,我们使用生产者-消费者范式来处理分布式图采样和特征查找以及模型训练的关系,将图采样、特征查找与训练进行解耦,使用多进程并行和协程异步并发来加速采样和特征查找,并使用预取和热点缓存的方式进一步减少训练端的等待,提升端到端吞吐。考虑到用户迁移成本和易用性,在接口上我们保持了和 PyG 的兼容,只需少量改动 PyG 代码就可以加速 PyG 的训练,或者将其迁移到 GLT 的分布式训练上。以下为我们具体阐述几个关键的设计点。

GPU采样

GLT 将图拓扑使用 CSR 格式存储在 GPU 显存或者 pin memory里,实现了 CUDA 采样算子来进行 GPU 并行采样。使用 CSR 存储可以很容易得到每个节点的邻居,并且独立对每个节点进行采样,因此可以方便地利用 GPU 多线程进行并行采样。我们使用了蓄水池算法来进行无放回随机采样。在batch size大的情况下,GPU 比 CPU 采样能有数量级的提升。

UnifiedTensor

为了消除CPU 内存到 GPU 显存的拷贝开销,一个比较直观的方法是将特征存放在 GPU 显存里,然而由于单卡的显存有限,在特征数据比较大的情况下也很难完全把特征存到显存里。因此,在GLT中我们利用图自身的特性如power law分布和采样访问特性如有些度比较高的节点被访问的概率高,将部分热点特征存放在 GPU 显存里,其他特征存在内存,同时需要利用 UVA 让 GPU 访问内存里的特征。GLT 设计了 UnifiedTensor 将 CUDA Tensor 和 CPU Tensor 统一管理起来,以提供简洁高效的数据访问。进一步,如果 GPU 之间可以直接进行 peer2peer 访问(具有NVLink),这些 GPU 的显存也可以被统一管理,从而扩大特征在显存的存储。GLT 使用UnifiedTensor 将这些不同硬件设备上的存储统一管理起来,提供直接访问 CUDA Tensor,通过 NVLink 访问其他 GPU 上的 CUDA Tensor,并通过 UVA 进行 ZERO-COPY 访问 CPU Tensor的能力,上层查找元素接口就像普通 Tensor 一样,底层会自动去对应的设备上进行访存操作。

1.jpg

Feature

Feature 由 UnifiedTensor 构成,具有硬件拓扑感知功能。具体来说,首先,按照用户指定 CPU/GPU 内存大小,对特征进行划分,分为 GPU(hot) 部分和 CPU(cold) 部分。其次,对 GPU 部分,根据用户指定的 replica 策略,进行 replica,包括每个卡 replica 和每个 NVLink 连接的 GPU group 之间的 replica。GPU group replica 的方式,相比卡间 replica, 可以有更多的 hot data 存在 GPU 上,因为 GPU group 里 GPU 之间都是可以 p2p 访问的。实现上GLT抽象出 DeviceGroup 来统一表示卡间 replica 和组间 replica。一个 DeviceGroup 表示一组 NVLink 连接的 GPUs。假设8卡没有 NVLink,那么会对应8个 DeviceGroup,如果 GPU 0-3 两两 NVLink 连接,GPU 4-7 两两 NVLink 连接,那么 GPU 0-3 为一组 DeviceGroup, GPU 4-7 为一组 DeviceGroup。实际测试中,使用UnifiedTensor 的Feature性能比 CPU Tensor的查找(包括拷贝到GPU) 快1个数量级,而且可以通过控制 GPU 存储部分的比例来灵活达到速度和显存占用的平衡。

2.jpg

3.jpg

分布式设计

GLT分布式GNN训练主要分成:分布式采样,特征查找, 模型训练3部分。一次采样的结果一般比较小(最大为十几MB),特征查找的结果比较大(百MB),训练时使用特征查找的结果进行神经网络计算。对特征查找来说需要考虑减少和训练任务之间的数据转换和拷贝。采样和训练之间是典型的生产者和消费者关系,因此可以分成不同任务,通过缓冲区连接,平衡生产者和消费者的处理能力,起到一个数据缓存的作用,同时也达到了一个解耦的作用。基于生产者-消费者方式,GLT的分布式训练有两种基本类型的进程:采样进程和训练进程。

采样进程:负责分布式邻居采样和特征收集。采样结果将被发送到采样消息通道,该通道将进一步用于训练任务。

训练进程:对应于PyTorch DDP的分布式训练进程,通常,每个训练进程将占用一个GPU进行训练。

这些进程可以灵活地分布在不同的机器上,为了更好地管理分布式进程部署,GLT的分布式训练提供了两种参考部署模式:Worker 模式和 Server-Client 模式。

Worker模式里,数据切分后,每个机器持有一个分片,采样进程和训练进程一起部署在这些机器上。每个训练进程可以spawn出多个采样子进程,采样进程通过一个共享内存的消息通道将采样结果传递给训练进程。对于采样进程来说,可以使用多进程进行采样,并且每个分布式采样算子都使用Python协程来并发执行,将结果放到消息通道里。为了减少消息通道到训练进程 GPU 的拷贝耗时,消息通道也可以放到pin memory上。

4.jpg

Server-Client模式下,集群中存在两种类型的机器节点,即 Server 节点和 Client 节点。采样进程部署在 Server 节点,训练进程分布在所有 Client 节点上。采样进程生成的样本结果将通过一个RPC实现的远程消息通道发送到当前训练进程进行训练。Server-Client 模式可以将采样和训练不同 workload 的任务放到不同机器,进行资源上的解耦。

5.jpg

总体架构

6.jpg

GLT 的主要目标是充分利用 GPU/NVLink/RDMA 等硬件资源和 GNN 模型的特性,加速单机和分布式环境下的端到端 GNN 训练。

存储:在 GPU 训练场景,图采样和 CPU-GPU 数据传输很容易成为主要性能瓶颈。为了加速图采样和特征查找,GLT 实现了 UnifiedTensor 统一 CPU 和 GPU 的内存管理。为了减少特征收集引起的 CPU-GPU 数据传输开销,GLT 支持将热点特征缓存在 GPU 显存中,并通过 UVA 访问其余特征数据。我们还利用高速 NVLink 在GPU 之间扩展 GPU 缓存的容量。

图操作算子:存储之上,GLT 实现了包括邻居采样、负采样、特征查找、子图采样等同时支持 CPU 和 GPU 图操作算子。

分布式算子:对于分布式训练,为防止远程数据访问阻塞模型训练进程,GLT 在 PyTorch RPC 之上封装了一个高效的 RPC 框架,并采用多进程并行和异步并发的图采样和特征查找操作来隐藏网络延迟并提高端到端训练吞吐量。

接口:为了降低 PyG 用户的学习成本,GLT 的上层 API,如Sampler, DatasetLoader,接口上都与PyG兼容。因此,PyG 用户只需修改很少的代码即可充分利用 GLT 的加速能力。

模型:由于 GLT 与 PyG 兼容,你可以使用几乎任何 PyG 的模型作为基础模型,此外我们也提供了丰富的分布式训练示例。

系统性能

我们在一台配备A100 GPU的机器进行单机扩展性测试,测试环境为 CUDA 11.4、PyTorch 1.12 和 GLT 0.2.0rc2,下图展示了邻居采样和特征查找的总吞吐量。可以看出 GLT 有线性的扩展性(由于有NVLink,多卡的缓存容量更多,因此会存在超线性加速)。

7.jpg

此外,我们还测试了多机的分布式采样和特征查找的扩展性。下图展示了每个机器配备2个A100 GPU的环境下,2个机器和4个机器相比单个机器的吞吐量加速比。测试使用 CUDA11.4、PyTorch 1.12和 GLT 0.2.0rc2 进行。可以看出,2机到4机也有近线性的扩展性。

8.jpg

最后,我们测试了分布式e2e的性能。我们在2机每机2卡A100的设置下和DGL做了初步对比(DGL版本0.9.1,GLT版本0.2.0).

9.jpg

结语

本文介绍了基于PyTorch的GPU加速分布式GNN框架GraphLearn-for-PyTorch(GLT),GLT提供了分布式 GPU 训练的优化加速能力,能够充分利用 GPU 等硬件资源进行图采样和特征查找等操作,具有线性扩展性。上层接口上和 PyG 兼容,可以很容易地加速 PyG 已有模型或者将已有模型改成分布式版本。GLT 已经开源并且在PyG, GraphScope中都有示例,后面我们会持续开发优化,欢迎使用和贡献!

[1] P3: Distributed Deep Graph Learning at Scale

[2] Quiver: Supporting GPUs for Low-Latency, High-Throughput GNN Serving with Workload Awareness

免费领取 交互式建模PAI-DSW、模型训练PAI-DLC 5000CU*H计算资源包,以及价值500元模型在线服务 PAI-EAS 抵扣包。

相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
相关文章
|
2月前
|
人工智能 自然语言处理 文字识别
MinerU-大语言语料处理神器,CPU/GPU均可跑,开源免费“敲”好用
在7月4日举行的WAIC 2024科学前沿主论坛上,书生·浦语2.5正式发布,面向大模型研发与应用的全链条工具体系同时迎来升级。
MinerU-大语言语料处理神器,CPU/GPU均可跑,开源免费“敲”好用
|
3月前
|
人工智能 Java 语音技术
开源上新|FunASR离线文件转写GPU软件包1.0
开源上新|FunASR离线文件转写GPU软件包1.0
|
3月前
|
并行计算 算法 调度
自研分布式训练框架EPL问题之提高GPU利用率如何解决
自研分布式训练框架EPL问题之提高GPU利用率如何解决
|
4月前
|
存储 关系型数据库 MySQL
深度评测:PolarDB-X 开源分布式数据库的优势与实践
本文对阿里云开源分布式数据库 PolarDB-X 进行了详细评测。PolarDB-X 以其高性能、强可用性和出色的扩展能力在云原生数据库市场中脱颖而出。文章首先介绍了 PolarDB-X 的核心产品优势,包括金融级高可靠性、海量数据处理能力和高效的混合负载处理能力。随后,分析了其分布式架构设计,包括计算节点、存储节点、元数据服务和日志节点的功能分工。评测还涵盖了在 Windows 平台通过 WSL 环境部署 PolarDB-X 的过程,强调了环境准备和工具安装的关键步骤。使用体验方面,PolarDB-X 在处理分布式事务和实时分析时表现稳定,但在网络问题和性能瓶颈上仍需优化。最后,提出了改进建
6980 2
|
4月前
|
分布式计算 API 对象存储
Ray是一个开源的分布式计算框架,用于构建和扩展分布式应用。它提供了简单的API,使得开发者可以轻松地编写并行和分布式代码,而无需担心底层的复杂性。
Ray是一个开源的分布式计算框架,用于构建和扩展分布式应用。它提供了简单的API,使得开发者可以轻松地编写并行和分布式代码,而无需担心底层的复杂性。
715 11
|
4月前
|
关系型数据库 分布式数据库 数据库
PolarDB,阿里云的开源分布式数据库,与微服务相结合,提供灵活扩展和高效管理解决方案。
【7月更文挑战第3天】PolarDB,阿里云的开源分布式数据库,与微服务相结合,提供灵活扩展和高效管理解决方案。通过数据分片和水平扩展支持微服务弹性,保证高可用性,且兼容MySQL协议,简化集成。示例展示了如何使用Spring Boot配置PolarDB,实现服务动态扩展。PolarDB缓解了微服务数据库挑战,加速了开发部署,为云原生应用奠定基础。
289 3
|
4月前
|
关系型数据库 分布式数据库 PolarDB
**PolarDB开源指南:构建分布式数据库集群**踏上PolarDB开源之旅,了解如何从零开始搭建分布式集群
【7月更文挑战第3天】**PolarDB开源指南:构建分布式数据库集群**踏上PolarDB开源之旅,了解如何从零开始搭建分布式集群。采用存储计算分离架构,适用于大规模OLTP和OLAP。先准备硬件和软件环境,包括Linux、Docker和Git。然后,克隆源码,构建Docker镜像,部署控制节点和计算节点。使用PDCli验证集群状态,开始探索PolarDB的高性能与高可用性。在实践中深化学习,贡献于数据库技术创新。记得在安全环境下测试。
185 1
|
5月前
|
存储 NoSQL Java
HBase是一个开源的、分布式的、面向列的NoSQL数据库系统
HBase是一个开源的、分布式的、面向列的NoSQL数据库系统
90 0
|
22天前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
103 2
基于Redis的高可用分布式锁——RedLock