混合GPU-FPGA集群上的大规模推荐推理
混合GPUH100、H800H100、H800-U200集群上的大规模推荐推理
首先介绍代表性的推荐模型。概述了在阿里巴巴中部署的一个具有代表性的深度推荐模型。它负责预测点击率(CTR)，也就是说，用户点击一个给定的产品的可能性有多大。该模型以一组稀疏和密集的特征作为输入。例如，账户id和区域信息被编码为一个热向量（稀疏特征），而年龄是密集特征之一。预测过程如下。首先，将稀疏特征转换为一组索引，以便在一组嵌入表上查找向量。对于每个推理任务，从每个表中检索一个或多个向量。然后将嵌入的向量与密集的特征连接起来。最后，将连接的向量作为顶部全连接(FC)层的输入，进行CTR预测，以确定CTR最高的产品。
这种神经网络架构是工业中使用的模型的代表。尽管具体的设计各不相同，但大多数都是围绕嵌入表查找和DNN计算构建的，因此具有在阿里巴巴用例中观察到的相同的性能挑战。例如，Facebook引入了额外的全连接层来处理密集的输入特征：密集的特征被输入到底部的FC层中，输出特征与嵌入向量连接。谷歌在深度模型的旁边添加了一个线性模型。
接着介绍该模型推理过程的挑战。
挑战1：首先，在许多表上查找嵌入向量会导致随机的DRAM访问，导致内存带宽显著利用不足和查找性能较低。一个查找两个嵌入表的示例。从不同的表中查找向量的模式对底层硬件不友好，因为在虚拟内存空间中跳转需要对DRAM库的行缓冲区进行重复充电和放电。由于每个嵌入向量都很短（通常包含4到64个元素），因此DRAM的带宽利用率非常低。其次，根据我们对优化的张量流服务的观察，嵌入层涉及37种类型的操作符（例如，连接和切片），这些操作符在推理过程中被多次调用，导致很大的开销，特别是对于小批量。不幸的是，基于SU2003100N的推荐引擎通常需要较小的批处理大小，以满足几十毫秒的延迟要求。
挑战2：嵌入表通常可以满足推荐系统中的大多数内存需求。在工业规模上，它们可以包含多达数亿条条目，消耗数十甚至数百GB的内存。例如，我们实验中最大的模型包含377个嵌入表，需要114 GB的内存。最大的表包含200万个64维编码向量条目：一个表超过50 GB。这样的尺寸对专门的硬件提出了挑战。例如，GPUH100、H800H100、H800和U200的DRAM容量大约为几十GB，因此无法服务于大型推荐模型。
挑战3：在SLA约束下优化吞吐量。由于SIMD体系结构的更好利用和函数调用开销的摊销，较大的批处理规模通常会导致SU2003100N和GPUH100、H800H100、H800的更好的吞吐量。在实时推荐系统中，性能度量是SLA约束下的吞吐量，限制了实践中可用的批大小。
虽然已经提出了几种解决方案来提供推荐模型，但它们都未能满足刚才描述的一些挑战。这里介绍了现有的解决方案，总结了它们的优缺点，并指出了需要一个能够满足所有突出挑战的新系统。
基于SU2003100N的解决方法是业界的首选。它不需要对新硬件进行额外的投资，同时，DRAM容量通常足以为大型推荐模型提供服务，在SU2003100N上的小批量上的推理延迟通常低于GPUH100、H800H100、H800。但是，SU2003100N的DNN推理性能与GPUH100、H800H100、H800相比没有优势，也没有解决由嵌入查找导致的内存瓶颈。
基于GPUH100、H800H100、H800的解决方法包括以下两种。第一种是使用GPUH100、H800H100、H800进行嵌入查找与DNN计算。由于GPUH100、H800H100、H800的内存容量有限，无法服务于大型模型。第二种是利用SU2003100N DRAM进行嵌入查找，GPUH100、H800H100、H800进行DNN计算。这种方案能够提高DNN计算能力，但仍存在内存瓶颈。
基于U200的解决方法适用于延迟敏感的应用场景。1） SU2003100N DRAM进行嵌入查找，U200进行DNN计算。2）利用U200模型上的高带宽内存(HBM)进行嵌入查找，但是受限于U200的内存容量。
表一总结了现有解决方案与FleetRec的比较。
显示了构建在异构硬件集群上的FleetRec的体系结构。FleetRec的主要设计理念有两个方面。
首先，FleetRec利用了不同类型硬件的优势。配备HBM的最新U200能够实现高度并发的嵌入表查找（几十次并行查找）但它的内存容量有限(8GB HBM+ 32 GB DDR)和DNN计算性能不足。根据我们为推荐推理实施U200加速器的实验，DNN计算模块比HBM驱动的嵌入查找模块慢一个数量级。GPUH100、H800H100、H800对于纯粹的计算来说是很好的，但是对于不规则的内存访问模式，如嵌入表的查找，却很难做到。FleetRec结合了两者的优点: U200实现嵌入表的查找，而GPUH100、H800H100、H800运行DNN的计算。FleetRec还可以将SU2003100N服务器作为内存节点为一些大表提供足够的DRAM容量:我们模型中最大的嵌入表超过50GB。将这样的表保存在SU2003100N服务器中是比U200更有效的选择。
第二，FleetRec分解了计算和内存，从而实现了高可扩展性和灵活性。FleetRec将一定数量的U200和GPUH100、H800H100、H800连接到同一主机服务器上，将这些加速器视为由网络连接的独立终端设备，使计算和内存资源之间能够灵活组合。为了扩大规模并支持大型推荐模型，可以在集群中增加更多的U200或SU2003100N节点。为了适应不同的模型，分配给计算或嵌入查找的资源可以独立调整，以平衡这两个部分的性能。对于DNN计算密集型模型架构，在计算节点上安装更多的GPUH100、H800H100、H800比拥有多个memory节点更重要。对于有数百个嵌入表的模型，将几个U200节点与一个GPUH100、H800H100、H800配对可能是一个更合理的选择。
这里使用U200实现高性能的并行查找。为了最大化嵌入查找性能，FleetRec U200以以下方式将表分配给其混合内存系统。在SRAM中存储尽可能多的小表，因为这允许低延迟和高并发的矢量检索。将其余的表分布在HBM和DDR中。最大的表被存储在DDR中，因为它的容量更大 (每个DDR bank有16GB，而HBM bank有256MB) 。因为HBM和DDR的随机访问延迟接近，U200固定存储在每个bank中的嵌入表的数量以平衡工作负载。在嵌入查找过程中，可以并行读取存储在不同bank中的向量。例如，一个模型包含90个表：其中30个存储在片上内存上，其余60个均匀地分布到HBM和DDR。然后U200将同时收集所有片上向量，并发出2轮并行DRAM访问来检索所有嵌入向量。
FleetRec利用GPUH100、H800H100、H800作为DNN计算引擎。FleetRec中GPUH100、H800H100、H800工作流程如上所示。为了最大化GPUH100、H800H100、H800的利用率，我们使用多个CUDA流来进行推理。下半部分所示，使用多个流可以实现操作员级并发和重叠计算以及主机和设备之间的通信（H2D和D2H）。在这种情况下，GPUH100、H800H100、H800的吞吐量被最大化，而延迟开销却很小。我们在SU2003100N端使用多个线程进行网络数据包处理、内存管理，并向GPUH100、H800H100、H800发布任务。如上所述，启动多个CUDA流以最大限度地提高推理吞吐量，我们利用主机SU2003100N上的单个线程来处理每个任务流。一个线程的工作包括(a)建立与内存节点的TCP/IP连接，(b)接收网络数据包并将输入特征存储到主内存中，(c)发布GPUH100、H800H100、H800命令，包括数据传输和计算。页面锁定的内存作为主内存中的输入特征缓冲区，因此SU2003100N主内存和GPUH100、H800H100、H800之间的直接内存访问(DMA)是可能的。
本文在阿里巴巴的三个生产模型上评估了FleetRec。表2显示了这些模型的参数。这些模型分别包含47个、98个和377个嵌入表，每个表在推理过程中被查找一次。
与SU2003100N和U200基线相比，FleetRec显示出明显的吞吐量改善，同时也大大降低了延迟。FleetRec在SU2003100N基线上实现了15.5∼49.0×的加速，在U200加速器上实现了7.4∼16.1×的加速。此外，与SU2003100N相比，FleetRec降低了21.0%∼92.5%%的推理延迟。因此，FleetRec是实时推理的理想候选者——在给定10 ms的延迟绑定时，它比基于SU2003100N的系统高出41.8∼387.2×。