GNNAdvisor —— 一个针对 GNN 在 GPU 上加速训练的自适应的和高效的运行时系统

⚠ 转载请注明出处:作者:ZobinHuang,更新日期:Mar.19 2022


知识共享许可协议

    本作品ZobinHuang 采用 知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议 进行许可,在进行使用或分享前请查看权限要求。若发现侵权行为,会采取法律手段维护作者正当合法权益,谢谢配合。


目录

有特定需要的内容直接跳转到相关章节查看即可。

正在加载目录...

    本篇文章是对发表在 OSDI'21 的论文「GNNAdvisor: An Adaptive and Efficient Runtime System for GNN Acceleration on GPUs」gnnadvisor 的阅读和总结。

Motivation

    常见地,GNN 系统相关的论文都喜欢从 Graph Processing System 和基于常见 DL 框架的系统两个角度进行 Motivation 的分析。这篇文章也是,具体如下。

Graph Processing System

    基于现有的 Graph Processing System 出发:

    首先它们的重点在于对传统的图算法的 Optimization,例如针对 BFS 拥有的动态的 Frontier 集合 (i.e. Active Neignbor),因此就有像 Push-pull Traversal 和 Frontier Filtering 等优化,而 GNN 所依赖的底层图结构与图算法所考虑的底层结构不同,它考虑的是一个节点的所有 Neighbor,因此传统系统的算法优化在 GNN 上是无效的,甚至是有负优化作用的。

    其次,传统的 Graph Processing System 中每个 Vertex 只会有一个标量的属性,而在 GNN 中每个 Vertex 有一个 Embedding 的向量属性。基于 Embedding 的向量属性可能会很大,因此底层系统需要就此进行优化。

    最后,传统的 Graph Processing System 中并没有对 NN 提供支持,这使得在 Update 阶段的前向传播和复杂的反向梯度传播过程在传统系统上是需要重新实现的。因此本文的工作并没有基于 Graph Processing System 来重新设计系统,而是基于 Deep Learning Framework (i.e. Pytorch) 出发进行系统设计。

Deep Learning Framework

    现有的 DL 框架对欧拉数据集提供了很好的训练和推理支持,它支持多种线性的和卷积的 Operatores,但是基于这些 DL 框架,实现将 NN 计算在图数据集 (i.e. 非欧拉数据集) 上的扩展会有如下挑战:

    之前的基于 DL 框架扩展的 GNN 处理系统 (NN-extended GNN computing platform) 的出发点都是面向可编程性和通用性,提供了一个很好的前端编程支持,但是在后端的性能优化上存在欠缺。比如 Pytorch-Geometric (PyG) pyg 使用了基于 CUDA 实现的 torch-scatter 库来支持 Graph Aggregation Operations,这个库的可扩展性是不够的,因为它使用了过多的高开销的原子操作来支持 Vertex Embedding 的 Propagation。DGL dgl 也有同样的扩展性问题。

    并且,上述系统的 Computation Kernels 都是写死的,GNN Model 编程人员在外部调用这些 Computation Kernels,而不允许他们基于已知的 GNN 模型结构、GPU 硬件和图的参数对这些 Kernel 进行定制。

    另外,在 GNN 的训练过程中,与性能相关的关键信息是在运行起来 (i.e. Runtime) 之后才能获取的,之前的工作没有进行 Runtime Adative 的设计。

对 GNN Input Information 的分析

    由于文章 argue 的一个重点就是要基于 GNN 的输入数据来进行 System Optimization,因此文章对 GNN 的输入进行了分析,分为两个方面: GNN Model 和 Graph 本身。下面分别进行阐述

GNN Model

    文章认为,对于不同的 GNN Model 来说,它们在 Update 阶段的模型大同小异,而在 Aggregation 阶段则显现出区别,所以文章重点对不同模型的 Aggregation 阶段进行了分析。主要可以分为两类。

    只使用邻居 Vertex 的 Embeddings 进行汇聚: 基于这一类的 Aggregation 模型,常见优化方法是: 在每一轮的 Update 阶段减少 Vertex Embedding 的维度,以减少在下一轮 Aggregation 阶段需要传输的数据。在这种优化条件下,强调 Memory Locality 是有意义的,因为 Embadding 变小了,可以被缓存在 GPU Cache 中。

    使用邻居 Vertex 的 Embeddings,以及 Edge Vector、Edge Weight 等进行汇聚: 基于这一类的 Aggregation 模型,由于计算 Edge Vector 需要使用全维度的 Vertex Embeddings,所以没有办法向上面那样实现逐层的 Vertex Embedding 压缩。这样一来,由于 Embedding 的大小太大,所以强调 Memory Locality 的意义不大。在这种情况下则更应该关注计算的并行性。

Graph Information

    TODO

Design

    

粗粒度的 Neighbor Partitioning

    TODO