HPE SLINGSHOT将平面计算交由GPU控制

在现代系统架构中，存在着大量不断变化的系统软件（主要集中在控制平面内），相应的工作负载则随时游走在芯片之间，借此获得更高收益、改善系统整体安全性。但究其根本，计算引擎再怎么交替加载，其实际计算任务仍需要在某个位置实际完成。

借助“Cassini”Slingshot 11网卡配合“Rosetta”Slingshot以太网交换机ASIC，HPE已经把一部分计算和通信控制平面中的消息传递接口管理（MPI）协议任务剥离出去。相较于由网卡本身负责处理，HPE对于这些常用于分布式HPC应用程序和CPU到GPU AI训练框架的通信负载，显然有着自己的改造规划。

HPE工程师们将这项技术称为流触发通信，其已经被应用在橡树岭国家实验室“Frontier”百亿亿次超级计算机当中。在这里，无数设备共同为百亿亿级恐怖算力提供芯片支持。在最近一篇论文中，HPE展示了新的MPI转移方法，借此将典型的GPU感知MPI通信与GPU流感知/触发方法明确区分了开来。

总体来讲，对于常规的GPU感知MPI软件，英伟达与AMD两家大厂会在节点之内使用自己的GPU间点对点通信机制——一方是NVLink，另一方则是Infinity Fabric。但对位于不同节点的GPU间的MPI数据交换（常见于大型模拟/模型运行及大型AI训练任务），MPI数据的移动则仍在沿用几十年前由InfiniBand适配器开创的远程直接内存访问方法。具体来讲，这种方法允许在GPU和网卡之间直接传输数据，无需与主机CPU的网络堆栈进行任何交互。

这些都是不错的方案，但即使是在现代MPI堆栈当中，要想使用上述GPU感知方法，仍然需要由CPU线程来同步各节点间的操作、设置数据在计算引擎间的移动。论文作者写道，“这就意味着所有通信和同步操作，都将发生在GPU的内核边界。”

整个过程如下图所示：

而HPE为Cassini适配器和Rosetta ASIC设计的流触发技术则不同，GPU内核操作将被纳入队列并放进并发流中，相当于把GPU内核操作流打包成命令描述符以供稍后触发，再为其附加上控制操作。最重要的是，现在这些操作将由GPU控制处理器执行，不再依赖于CPU。

下图所示，为整个流触发过程：

这就是超级计算机的秘诀所在：整个系统中无数增量变化相加，即可在性能和规模上实现阶跃函数级的改进。正是这种对细节的关注和把控，才让HPC和AI能够充分发挥每个网络堆栈、每个计算框架的能力，真正让性能得到跨越式发展。这种新式流触发技术的重要性，绝不只是让HPC和AI应用程序的性能翻倍；更关键的是，它证明了少量多次增量步骤原理，让我们了解到超级计算机系统正是由硬件架构和系统软件层面的点滴设计堆砌而来。

为了测试MPI的这项流触发GPU加载技术，HPE从能源部CORAL-2超级计算机采购软件堆栈中借来了Nekbone基准测试方案（能源部也正是借这套基准测试工具，建立起三台百亿亿次超算设备）。Nekbone是Navier-Stokes求解器Nek5000中的关键内核之一。从Nekbone中提取出来的，用于性能测试的微基准内核之一则名为Faces。HPE正是使用Faces来测试基于AMD Epyc处理器和AMD Instinct GPU的节点内核，但论文并未明确提到测试的具体执行地点。可以肯定的是，Faces测试分两个场景进行：首先采用八节点集群，每个节点包含八个MPI进程；第二轮测试同样是八节点，但每节点只对应一个MPI进程。

在八进程每节点场景下，Faces测试性能比普通MPI高出10%，如下图所示：

而在每节点单MPI进程时，性能增幅则为4%到8%：

HPE指出，目前这项研究才刚刚起步，他们正努力“尝试全面转移ST通信语义选项，希望能充分发挥新接口的性能优势。”

但让我们好奇的是，把MPI负载交给DPU不是更合理吗？也许从长远来看，终极答案确实如此。但目前还有相当一部分架构并不包含DPU，所以把部分MPI负载分流给GPU应该是个不错的过渡性思路。