演讲人：Dhabaleswar K (DK) Panda, Professor and University Distinguished Scholar, The Ohio State University
大家好，我是来自NVIDIA网络部门的Brian Sparks。今天，我非常荣幸地向大家介绍一位与我合作近二十年的杰出人物，俄亥俄州立大学的DK Panda博士。Panda博士将为大家分享关于BlueField的话题。他和他的团队从第一代开始就与BlueField DPU紧密合作。今天，他将重点探讨他们在大型系统上对BlueField二代和三代进行的优化和细化调整。让我们热烈欢迎Panda博士！
谢谢Brian的介绍。大家下午好。很高兴今天能够在这里与大家分享BlueField相关技术。
BlueField技术拥有卓越的性能，这在各个领域都有着巨大的应用潜力。今天，我将主要围绕HPC和AI这两个领域展开分享。
放眼当今的现代集群，各类通用集群普遍部署了多核处理器、高性能互联以及加速器技术。本次讲座将聚焦于InfiniBand技术，特别是DPU的应用和优势。
随着这类集群逐渐演变为通用集群，集成了CPU、GPU、DPU等多种处理器类型，形成异构集群的形态。那么，如何为兼顾HPC和AI应用的高性能计算系统设计高效的中间件，充分发挥各类型处理器的优势，将是我接下来要探讨的广泛性挑战。
下面是我本次演讲的主要内容：
首先，我将简要介绍MVAPICH项目，相信很多朋友已经有所了解，但对于不熟悉的朋友，我会进行更详细的介绍。
接下来，我将分享我和团队在BlueField方面所做的工作，正如Brian之前提到的，我们从第一代BlueField开始，一直到现在的第三代，经过多年的探索和实践，我们积累了丰富的优化经验，并取得了显著的性能提升。我将重点介绍与非阻塞集合相关的策略和优势，其中包括通信卸载和非阻塞点对点通信卸载等技术。通过实证数据，我将展示如何通过卸载通信以及减少或不减少计算等方式来提升性能。
最后，我将分享我们在DL训练方面的研究成果，重点介绍如何在CPU和DPU的角度来卸载DL训练的数据。
MVAPICH项目始于2000年10月，至今已近24年。我们团队是全球最早一批积极探索InfiniBand技术的团队。在此之前，我们使用的是Quadrics的专有技术。2002年，我们在Supercomputing大会上展示了基于InfiniBand的MPI工作版本，这也是近22年前的事了。
回首过去，我为团队取得的成就感到无比自豪。MVAPICH项目历经23年发展，如今已广泛应用于全球各地。来自91个国家/地区的约3400个组织都在使用我们的库，仅从官网下载量就已近200万次。此外，MVAPICH还集成于OpenHPC、Spack、RedHat、SuSE等多个项目中，其应用范围之广可见一斑。MVAPICH已成为全球顶级集群的有力竞争者之一。
这是我们软件库的整体架构。它涵盖了各种网络技术和多核或多架构场景，这也是DPU的应用领域。我们已经在MPI层面实现了该架构的内部设计，这构成了我们的基础。随后，我们又扩展到PGAS和混合MPI-PGAS架构。最近，基于MPI的堆栈开始出现，例如我正在讨论的融合软件堆栈。这类堆栈可以在MPI上运行DL/ML工作负载，例如TensorFlow和Spark。我们的目标是开发最佳的MPI转换软件堆栈，因为MPI在与GPU、DPU等互连技术配合时始终能提供高性能。
只要拥有了这一基础，所有其他堆栈都将受益。对于结合了HPC、AI和数据科学等复杂工作流程，我们的系统也能够平稳运行。这正是我们的愿景。
在这种背景下，让我解读一下我们开发的卸载策略。
许多人可能已经熟悉BlueField三代DPU的架构。从广义上讲，它是一种基于处理器、集成了ConnectX和RDMA技术的设置。与之前的版本不同，BlueField还包含一组ARM核心。
要理解DPU的范式，我们可以将其类比为高管及其助理，或经理及其下属的协作方式。假设有一台配备DPU的CPU服务器，那么这些主要核心（无论它们是AMD、Intel、GRACE还是其他架构）就相当于高管，而DPU核心则相当于助理。
想象一下，你是一位经理，聘请了一位拥有博士学位的助理。你可以将哪些工作任务卸载给他？你可以指示他撰写研究提案、争取资金、撰写论文、开发产品，只要最终成果署上你的名字即可。然而，这种做法在现实生活中并不经济。通常情况下，你会聘请一位拥有大学学历的秘书。根据他们的学历，他们能够胜任哪些工作？他们的薪资水平是多少？
我们在制定卸载策略时必须始终牢记全局观。只有这样，我们才能理解在特定情况下如何有效地运作，以及哪些情况下卸载策略能够带来效益，哪些情况下无法。
让我们从MPI的一个非常简单的例子开始，即集合通信操作。许多人熟悉MPI提供的各种集合操作，例如“全互连”（All-to-All）、“全规约”（All-Reduce）、聚集（Gather）和分散（Scatter）。传统上，这些操作被广泛应用于AI工作负载中。深入研究这些工作负载，会发现所有这些集合操作都发挥着重要作用，尤其是“全规约”和“全互连”的性能至关重要。
在MPI标准中，这些阻塞集合操作通常在程序开始阶段执行。以下是一个“全互连”操作的示例：每个进程先进行一些计算，然后启动该操作。假设在一个百万核系统上执行“全互连”，那么每个进程都必须将数据发送给所有其他进程。这是一个非常密集的通信操作，需要大量时间。
为了提高性能，现有的MPI实现通常采用了一些优化算法。例如，我可以从你这里获取一些数据，然后尝试从其他人那里获取其他数据，将它们组合在一起，然后再发送出去。这些优化算法虽然可以减少通信时间，但它们本身也需要进行一些计算。
现在，让我们分析一下阻塞集合操作的问题。假设执行一个MPI“全互连”操作。在执行过程中会发生什么？由于没有计算，只有通信（绿色部分代表计算，蓝色部分代表通信），所有进程都会处于等待状态。从竞争的角度来看，这是一种巨大的浪费，因为计算资源无法得到充分利用。
将这个现象类比为高管召开Zoom会议。假设你需要与1000人进行视频会议，需要找到一个所有参与者都方便的时间。如果你亲自安排会议，可能需要花一个小时来协调时间、发送邀请等，而这期间你的其他工作就无法进行。
为了提高效率，可以使用日程安排工具或其他方法来简化会议安排流程，从而将更多时间用于实际工作。对于高管而言，亲自决定会议时间和安排细节可能并非必要。
这些工作可以被卸载吗？这正是我们将要探讨的方向。传统上，MPI使用阻塞集合操作，导致计算和通信无法重叠，因此效率低下。为了解决这个问题，MPI标准引入了非阻塞集合操作。非阻塞集合操作的思路是：先进行计算，然后启动操作。在启动操作的过程中，我们可以将部分工作卸载给他人，由他们代为完成。
例如，我可以安排一些操作，并在这些通信操作进行时继续进行其他计算。与之前的图表相比，实现了计算和通信的重叠，从而提高了程序的效率和并行性能，并改善了整体的可伸缩性。总而言之，非阻塞集合操作能够带来诸多优势，因此它被引入MPI标准中。
然而，实现计算和通信的重叠也带来了一些新的挑战：谁来负责这些额外的任务？正如我之前提到的，像全局全收集这样的通信操作需要大量的消息传递和数据聚合工作。这些任务虽然相对简单，但也需要有人来完成。目前，主流的MPI实现和API库使用了一些专用线程来实现非阻塞集合操作。例如，他们会从应用程序中分配一部分核心，专门用于处理这些任务。我们可以继续探索其他方法来优化非阻塞集合操作的性能，例如使用额外的线程或其他并行技术。
存在一些解决办法。然而，在最坏的情况下，如果试图运行所有核心，现有的手段将无济于事，因为通信无法被有效控制。这正是DPU应运而生的背景。DPU提供了额外的核心资源，可以作为助力，就好比为高管配备了一组秘书团队。那么，如何充分发挥DPU的作用呢？主要途径是探究计算与通信的重叠可能性，以期缩短整体应用程序的执行时间。简而言之，目标是提升应用程序的运行效率。
但问题是有很多挑战。如何实际上管理DPU网络？如何规划这个通信机制？想象一下，假如你有一位秘书，之前并未有此安排，现在组织为你配备了这样一位助手。你感到非常高兴，但他们必须熟悉你的工作流程，无论过往你是如何操作的。比如，你原本打算全权处理所有事务，但现在你需要审视哪些任务可以分派出去。这意味着你的工作流程必须作出调整。如果你坚持沿用旧有的工作模式，那么新聘的秘书可能只能闲置一旁，无所作为，而你则继续独自承担所有工作，这显然是不划算的。因此，我们讨论的是如何重新设计这些应用程序，而一旦完成这一步，接下来便是考虑如何实现有效通信。例如，秘书需要能够访问所有必要的资源。或许你需要开放文件的访问权限，或是授权办公室的使用权，以便他或她能代你处理事务。若你每次都拒绝提供这样的访问权限，那么你就不得不亲自下载文件再交予他或她，这样一来，你又被卷入繁琐的事务中。
接下来，我们还将探讨负载均衡的问题。正如我之前所举的例子，一组高管在分享一组助理。因此，某种形式的负载均衡机制是必不可少的。
具体来说，假设我们以AMD的128核CPU为例，而有一个16核的DPU。这相当于128位高管需要共享16位秘书。在这种情况下，负载均衡就显得尤为重要。最终，正如我前面提到的，你需要对这些应用程序进行重新设计。这要求你在上述所有四个方面上共同努力，以期实现最佳效益。这就是我们的工作内容。接下来，我会尝试向你展示一些相关数据。
这是节点一。节点二最初在蓝色场一和蓝色场二使用状态传输作为通信机制。这表示这是主机内存。可以像使用RDMA一样读取DPU内存，然后写入主机内存。因此，需要提供所有指向DPU的指针，以便他们读取并发送数据。然而，对于大消息而言，这种方式效率低下，因为需要进行一次数据拷贝。需要将数据传输到DPU内存并存储在那里，这会导致一些性能损失。相比之下，InfiniBand可以直接从主机内存发送到主机内存，并带有RDMA输出，更加高效。
去年，GVMI技术应运而生。GVMI代表客户虚拟机ID，它支持直接指示GVMI内存从何处获取数据并将其放置在何处。这是一种最有效的方式，可以避免浪费时间。这就像指示秘书获取文件并将其复制到指定位置一样。只需提供指针，让秘书完成工作，无需亲自复制和发送数据，从而节省时间。
让我们来看看一些性能数据。首先，让我们探讨“重叠”（Overlap）的概念。其目标是考察高管如何与秘书协作，实现活动重叠。在Ialltoall操作中，我们希望确保通信得以卸载。那么，重叠究竟指的是什么呢？本文将展示一种应用于DPU的重叠技术。这里，可以实现98%到100%的重叠率。
让我们看一下在osu_Ialltoall级别所能获得的性能提升。数据分析方法与之前略有不同。再次回到高管和秘书的例子。有时作为高管，你可能拥有更快的完成任务能力。例如，在初期阶段，你有一位秘书。你可能会考虑：“我应该将此任务委派给秘书，还是亲自完成？我可以5分钟内完成它，但向秘书解释可能需要20分钟。”关键在于，在初期阶段，你可能会遇到抵触情绪，但实际上你需要培训秘书。一旦秘书掌握了处理此类任务的方法，你将在未来受益。评估效率的有效方法是查看总执行时间，包括计算和通信时间。你的秘书可能需要更长时间才能完成任务，但这并非关键所在。
在任务执行期间，你的周期处于空闲状态，因此你可以继续进行计算。这是一个可行的衡量标准。如果你遇到此类项目，我们可以使用微基准工具进行评估。无需重写代码，只需使用现有工具进行评估即可。我正在尝试展示一些数据。这些数据表明，对于512个进程和1000个进程的运行，osu_Ialltoall操作的不同消息大小（从64k到512k）可以带来20%到22%的“全互连”（All-to-All）加速。如果你的应用程序包含大量“全互连”（All-to-All）操作，那么该技术具有显著的潜力。
然而，关键在于应用程序需要进行相应的调整。正如我之前提到的，聘请秘书也需要改变工作流程。我们与圣地亚哥超级计算中心的P3DFFT团队合作，他们的库使用“全互连”（All-to-All），但初始版本采用了阻塞集合操作。
因此，我们协同合作，修改了他们的算法，使其能够在进行部分计算后执行非阻塞全互连通信。在非阻塞全互连通信进行期间，计算任务仍可继续进行。这需要一定的努力，并非易事。正如那些曾聘请秘书的人所了解的那样，工作流程会在您意识到这一点之前发生改变。否则，将无法获得收益。但一旦进行修改，您便可以见证这些数据。再次强调，在应用层面，512个进程运行和1000个进程运行情况下，能够在不同的网格大小下实现14%、12%和21%的性能提升。
前面是BlueField 2，这个是BlueField 3，16个节点的数据。
我们已经为不同类型的集体通信设计了相应的方案，例如非阻塞广播和广播。这在许多应用程序中也十分常见。因此，为了避免重复讲解设计细节，我将不再赘述相同的内容。在osu_Ibcast广播的情况下，如果将副本提供给DPU，DPU实际上可以立即开始复制数据。这就好指示秘书将一封电子邮件发送给一千人，而不是将同一封电子邮件发送给一个人一千次。正是由于这种机制，我们能够实现高达57%和58%的性能提升。
我们对高性能LINPACK进行了一些修改。正如部分用户所了解的，LINPACK中包含bcast。因此，我们修改了高性能LINPACK，使其能够利用非阻塞集体通信来实现重叠。在HPL级别，我们开发了一个名为XScaleHPL-DPU的软件包，并取得了16%到18%的性能提升。
这再次印证了我的观点：为了确保解决方案的有效运行，必须系统地处理所有相关事项。我们无法期望只需将BlueField-3 DPU添加到现有的集群中，即可自动获得所有性能提升。软件堆栈必须经过重新设计。这里展示的案例正是重新设计软件堆栈的示例。我们探讨了MPI的应用，除了工作负载等方面需要进行调整之外，最终应用程序无需更改。
现在让我们探讨点对点通信。对于熟悉MPI设计的人来说，应该了解MPI_Isend和MPI_Irecv等通信函数。遵循相同的思路，我们可以考虑将该任务卸载到DPU代码上。与其发送注册缓冲区和所有发送指针，不如让DPU代码自行处理。为此，我们进行了3D Stencil基准测试。结果表明，在12核环境下运行时，性能提升了近18%。
然后我们开始做一些更复杂的事情。这是一个PETSc。我们尝试看看是否可以取出PETSc核心然后尝试修改它。
再次，在这里你会看到类似的结果。我们对PETSc进行了卸载。这是在BlueField 3上，32 PPN，8个节点或256个代码。在APHC库级别上，实现了23%，24%的提升。
前面讲的是HPC方面的内容。我们同时也在关注DL训练。
你可以提出这样一个问题：作为高管，我能为秘书们提供哪些支持，尤其考虑到我的技术背景（代码能力）并非特别强大。大家还记得我举的例子，无论是博士、高中学历还是大学学历的秘书，都可能适用。因此，你需要判断哪些任务或负担应当“卸载”（这里指的是分配或调整任务分配），以便达到最佳的工作效率。我们认定这是一个理想的组合方案。
为此，我们进行了大量实验。这些实验在BlueField平台上进行，包括在CPU上进行训练过程，在DPU上执行数据增强和测试过程，这样的分工为我们提供了非常有效的组合，实现了工作的并行处理（或重叠执行）。
这是X-ScaleAI-DPU包，是一个CPU加DPU的组合，我们也在实现GPU加DPU的组合。它支持所有可用于MVAPICH库的功能，并支持PyTorch进行深度学习。
这是在CIFAR10数据集上运行ResNet-20v1模型的测试。可以看到，在最多16个节点上，实现了18%的性能提升。这表明我们能够有效地进行DNN训练。
这显示出，不仅HPC，对于AI工作负载也同样应该能够实现这一目标。
总结一下，关于DPU技术和这些新技术，提供了额外的算力，以进行一些计算任务，尽管不是大规模的。
基于这种“高管-秘书”的模型，我展示了如何利用这些技术的不同方式，无论是针对HPC还是深度学习应用，特别是通过使用GVMI接口。这使得我们能够在GVMI之前就能预见并享受到这些好处。因为一旦数据产生，特别是面对大数据时，如果选择先将数据复制到DPU内存，然后再传回，那么将失去所有的性能优势。因此，在获得这个接口之前，我们一度感到有些悲观。但自从他们提供了这个接口后，我们就能明显看到其带来的好处。这就是我们现在所看到的所有积极的结果数据，它们预示着加速应用程序性能的巨大潜力。当然，这些只是我们目前能够访问到的部分数据，我们已经在32个节点上进行了测试。
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/单位/关注领域）
