facebook在2020年《Understanding Capacity-Driven Scale-Out Neural Recommendation Inference》提供了它们的可扩展inference方案。看下它的实现：
摘要
深度学习推荐模型已经发展到TB级别。传统的服务方案——将整个模型加载到单个服务器上——无法支持这种规模。支持这种规模的一种方法是采用分布式服务，即分布式推理，它将单个大模型的内存需求分散到多个服务器上。
这项工作为系统研究社区开发新型模型服务解决方案迈出了第一步，鉴于巨大的系统设计空间。大规模深度推荐系统是一种新颖的工作负载，并且至关重要，因为它们在数据中心中消耗了高达79%的推理周期。为此，这项工作描述并刻画了使用数据中心服务基础设施进行扩展的深度学习推荐推理。这项工作特别探讨了延迟受限的推理系统，与最近其他工作中以吞吐量为导向的训练系统进行了比较。我们发现，分布式推理的延迟和计算开销，主要是由于模型的静态嵌入表分布和输入推理请求的稀疏性造成的。我们进一步评估了三个类似DLRM模型的嵌入表映射策略，并详细说明了在端到端延迟、计算开销和资源效率方面具有挑战性的设计权衡。总体而言，我们观察到在数据中心规模的推荐模型以分布式推理方式提供服务时，延迟开销仅为边际——在最佳配置情况下，P99延迟仅增加了1%。延迟开销主要是由于所使用的商用基础设施和嵌入表的稀疏性造成的。更令人鼓舞的是，我们还展示了分布式推理如何能够提高数据中心规模推荐服务的效率。
I. 引言
深度学习推荐模型在提供高质量互联网服务方面发挥着重要作用，并且最近开始受到系统社区的关注 [1]–[8]。推荐工作负载已被证明在2019年占Facebook数据中心所有AI推理周期的79% [1]，并被纳入MLPerf基准测试工作 [9]–[11]。这一数据中心工作负载的重要性值得对其性能、吞吐量和可扩展性给予更多关注。这类独特的深度学习工作负载面临的一个主要挑战是其规模的不断增长。图1展示了Facebook推荐模型的增长率。此外，百度（Baidu）和谷歌（Google）也部署了规模为1-10TB的模型 [12]–[14]。这种增长是由对更高准确性的需求推动的。众所周知，增加模型参数数量可以提高泛化能力和准确性，并且在更大的训练数据集下是实现最佳结果的必要条件 [15]–[20]。这一现象在多种深度学习应用中普遍存在，包括具有大嵌入表的语言模型——类似于深度推荐系统。本文不探讨增加模型规模对准确性的影响，而是专注于支持生产环境中大规模深度推荐模型的系统和性能影响。
图1
深度推荐模型的规模（以及内存容量）主要由嵌入表（embedding tables）决定，嵌入表表示学习到的稀疏参数。每个稀疏输入通过哈希函数映射到其对应嵌入表中的一个或多个索引，每个索引映射到一个向量。索引到的嵌入向量随后通过池化操作（如向量求和）进行组合。增加哈希桶大小和嵌入表数量可以提高嵌入捕获的信息量，从而直接提升推荐模型的准确性，但这也会导致内存占用的相应增加 [21]。减少哈希桶大小可以限制模型规模，但必须谨慎操作以保持模型准确性。
随着大型推荐模型的内存需求超过单个服务器的内存容量，需要解决方案来限制模型规模或增加有效内存容量。模型压缩技术可以用于限制模型规模，但可能会降低模型准确性 [22]。增加DRAM容量也是一种方法，但在超过个位数TB范围后无法扩展。即使如此，支持大容量内存也需要更大的服务器机箱。另一种解决方案是从更高容量的存储设备（如固态硬盘SSD）中按需分页加载模型，但这需要快速的SSD来满足延迟要求。
在数据中心中，额外的硬件需求是不可取的，因为这会增加管理异构资源的复杂性。例如，具有特殊配置的集群在高活动期间无法轻松扩展资源，或在低活动期间无法高效缩减资源。这对于受昼夜流量模式影响的工作负载尤其明显 [23]。与上述方法相比，分布式服务范式可以在现有基础设施上实现，通过将模型拆分为独立子网络并在通用CPU平台上运行。当然，这种方法并非没有权衡。额外的网络延迟、网络负载以及对额外计算节点的需求都会随之而来。然而，在大型同构数据中心中，与定制化、非常规硬件平台相比，部署和扩展这些资源更为容易。
因此，我们为研究社区提供了深度学习推荐系统分布式推理的详细描述和特征分析。这是应对模型规模增长挑战的首个可扩展解决方案，并为进一步优化提供了基线系统。值得注意的是，它与最近以吞吐量为导向的训练系统不同，后者没有推理服务中的延迟限制 [12], [15]。该实现基于真实输入和缩放的深度学习推荐模型进行了特征分析。在此服务范式中探索了三种模型并行化策略。这一具有挑战性的新颖工作负载为系统研究社区在数据中心规模的机器学习领域提供了新的机会。
本文的贡献如下：
- 据我们所知，这是首个描述大规模神经推荐推理分布式服务基础设施的工作。
- 我们深入分析了分布式推理对端到端推荐服务延迟、尾部延迟和算子计算开销的影响。我们进一步研究了通过模型分片（sharding）进行嵌入表放置的影响，并将研究结果置于数据中心服务环境的背景下。
- 最后，我们设计了一个跨层的分布式检测框架，用于性能调试和优化分析，以量化远程过程调用（RPC）服务和机器学习框架的性能开销。
本文的结构如下：第二部分简要介绍深度学习推荐系统。第三部分描述分布式推理的应用和实现，特别关注用于生成分布式模型的分片策略。第四部分描述了用于收集工作负载测量的自定义跟踪框架。第五部分提供了我们特征分析中使用的模型、平台和输入的详细信息。第六和第七部分展示了我们的特征分析结果，并将其置于数据中心服务环境的背景下。我们为系统设计者提供了指导和建议。第八部分讨论了相关工作。最后，第九和第十部分总结了我们的结论。
II. 大规模推荐推理
推荐任务是从一组产品或内容中为用户推荐或建议可能感兴趣的项目。例如，服务可以根据用户明确喜欢的内容和隐式消费的内容推荐新的视频片段、电影或音乐。模型的准确性是衡量用户对推荐结果的兴趣和满意度的抽象指标。传统上，基于邻域的技术（如矩阵分解）通过提供基于与其他用户的相似性或偏好项目的相似性的推荐，取得了良好效果 [24], [25]。然而，最近的推荐系统使用深度神经网络将各种稠密（dense）和稀疏（sparse）输入特征组合成一个更通用的预测模型 [1], [3], [26]–[29]。稠密特征的一个例子是用户的年龄；稀疏或分类特征的一个例子是用户喜欢的网页，模型的输出是候选项目输入的排名。图2a展示了这种深度学习推荐模型架构的简化概述。
图2
目前，推荐推理主要在CPU上执行，与其他深度学习工作负载中流行的异构系统不同 [1], [2]。这是因为，与其他推理任务中使用的GPU和其他AI加速器相比，推荐模型中的（1）稀疏性，（2）推荐算法的不断演变，以及（3）延迟限制的吞吐量约束，使得推荐推理在大规模上难以高效地在AI加速器上运行。吞吐量（每秒查询数，QPS）是推理的关键目标，但延迟约束同样重要。为了提供令人满意的用户体验，推荐结果需要在规定的时间窗口内返回。这种严格的延迟约束定义了服务级别协议（SLA）[1]。如果无法满足SLA目标，推理请求将被丢弃，转而使用可能质量较低的推荐结果，这可能会恶化用户体验。为了在相应的SLA约束内最大化吞吐量，采用了各种技术，例如批量大小调整和模型超参数调优。
1) 稀疏特征操作
稠密特征通过全连接（FC）层进行处理，而稀疏特征（如图2a所示）在进一步特征交互之前会经过一次转换。稀疏输入被转换为访问ID列表或哈希索引，这些索引指向嵌入表。嵌入表的大小（桶的数量和向量维度）是一个可调的超参数。通常，每个稀疏特征有一个嵌入表，但为了节省内存资源，特征可以共享表。例如，在一个N × M的表中，嵌入维度为M，具有K个索引的稀疏特征输入将生成K个长度为M的嵌入向量。池化操作（如求和或拼接）将沿第一维度折叠矩阵，生成1 × M或1 × (MK)的结果，用于特征交互。在本工作使用的Caffe2框架中，嵌入表操作符称为SparseLengthsSum（SLS）。通常也将相关操作符家族称为SLS。由于可能的输入数量巨大，嵌入表的大小受到限制，可能会发生哈希冲突。例如，一个维度为32的FP32嵌入表，用于30亿唯一用户，将消耗超过347GB的内存。为了在单个服务器上可行地使用，需要减小表的大小。
2) 模型规模的显著增长与大嵌入表
为了提高模型准确性并利用稀疏特征中丰富的潜在信息，深度学习推荐模型的规模迅速增长，如图1和最近的研究所示 [12], [14]。嵌入表主导了推荐模型的大小，并推动了模型规模的显著增长。尽管这种增长迅速，但它仍然受到内存容量需求相应增加的限制。为了进一步提高推荐模型的准确性，嵌入表的总容量已经增长到无法在单个服务器节点上支持的程度，这促使了分布式服务范式的需求。
III. 分布式推理
这是首个详细描述分布式神经网络推理的工作，针对深度推荐系统的独特目标和特性。由于这一初始实现更注重可部署性和可扩展性，而非性能与效率，因此在系统设计空间中存在许多优化机会，包括算法、软件、微架构、系统配置和任务映射等方面。因此，在本节中，我们为研究社区提供了通用系统设计和结构的概述。至少，神经推荐系统的分布式推理解决方案必须实现以下目标：（1）支持更多种类和更大数量的稀疏特征；（2）支持更大的嵌入表，即更大的嵌入维度、更少的哈希冲突和/或更少的压缩。
A. 分布式模型执行
假设深度学习模型可以表示为有向控制和数据流图。分布式模型简单地将神经网络划分为多个子网，每个子网可以独立运行。将每个子网独立对待提供了部署中的灵活性，因为用于服务模型的基础设施已经存在。图2b展示了这种划分的示例。传统上，这被称为模型或层并行。
1) 模型分片
我们将每个独立的子网称为一个分片（shard），而创建分片的过程称为分片化（sharding）。分片化在训练之前和之后都会进行。在训练之前，生成参数服务器分片以保存分布式训练的模型参数。在训练之后，模型发布期间，参数会根据预先的划分阶段从参数服务器重新分片并序列化到相应的推理分片。在此阶段，还会执行其他模型转换（例如量化），并且所有训练元数据都已可用于分片决策。训练后直接重新分片避免了重新加载和重新分片TB级模型所需的额外存储、计算和复杂性。
在图2b中，主分片执行所有稠密层，而任何划分的子网都被自定义的远程过程调用（RPC）操作符取代，这些操作符调用远程分片。只有稀疏操作符（如SLS）及其嵌入表被放置在远程分片上。这种启发式方法直接解决了嵌入表带来的内存限制，并保留了主分片上的计算密度。因此，远程分片也被称为稀疏分片。图3展示了这种方案的示例分布式跟踪，其中主分片（位于顶部）在每个网络中执行大部分计算。
图3
由于嵌入表的巨大规模，单个表也可以被划分到多个分片上，如图2b所示。在这种情况下，稀疏特征ID会根据哈希函数拆分并发送到相应的RPC操作符。这是通过使用简单的模运算符将嵌入表行划分到多个分片上实现的。服务基础设施限制了分片之间不能存在图循环，因此每个分片都是无状态的，以避免进一步的复杂性。这一限制还在服务环境中提供了更大的灵活性，因为分片可能会失败并需要重启，或者可能需要添加副本。
2) 服务分片
分布式推理需要一个额外的特殊远程过程调用（RPC）操作符，它取代主分片中的子网并调用其相应的稀疏分片，如图2b所示。这种方案为大规模模型提供了直接的横向扩展支持。推理请求被发送到加载了主分片的服务器，当遇到RPC操作符时，会向相应的稀疏分片发出后续请求。所有分片上的推理服务由RPC服务处理程序（如Thrift或gRPC）和机器学习框架（如Caffe2、PyTorch或TensorFlow）组成 [30]–[32]。每个分片运行一个完整的服务处理程序和ML框架实例。
这种分布式架构支持与非分布式推理相同的复制基础设施。分片根据其负载和大规模部署的资源需求进行复制。例如，需要更多计算资源以满足QPS要求的分片将通过集群级管理程序在其集群上复制和部署副本。主分片和稀疏分片都运行完整服务堆栈的优势在于它们可以独立复制。每个单独的请求可以由与之前请求不同的机器组合处理，这进一步推动了无状态分片的需求。在我们的实验中未启用复制基础设施，因为使用了一组独立的服务器进行深入的每请求开销特征分析和分析。关于分布式推理对复制的预期影响和交互的讨论包含在第七节中。
B. 容量驱动的模型分片
最优的模型分片是一个具有挑战性的系统问题，因为配置数量众多且优化目标各异。虽然这一问题在训练背景下已被研究，但在推理背景下却带来了新的挑战。训练必须应对小批量大小和参数同步对准确性的影响，并旨在最大化单个实例上的吞吐量，该实例被输入大量数据 [33]。相比之下，数据中心推理必须在严格的延迟约束下应对不同的请求速率和大小，以及模型复制以满足这些需求的影响。此外，在推荐系统中，内存占用主要由计算稀疏的嵌入表主导。深度学习推荐推理的模型分片是为了支持大规模模型，因此我们将这一新挑战称为容量驱动的分片。
由于分片配置的数量众多，穷举搜索最优分片方案是不可行的。因此，我们使用启发式方法，这些方法依赖于模型架构，并包括对模型容量、计算资源和通信成本的测量或估计。简单来说，启发式方法应旨在最小化分片数量，因为更多的分片会消耗额外的计算和网络资源。我们在第六节中研究了这一假设的影响。启发式方法基于以下观察：
1) 稀疏层中使用的嵌入表占模型大小的绝大部分（> 97%）。
2) 稀疏层受内存和通信限制，而稠密层受计算限制。
3) 现有服务器基础设施无法支持稀疏层的内存需求，但可以支持稠密层的计算和延迟需求。
4) 深度推荐模型架构（如图2所示）可以并行执行稀疏操作符，这些操作符为后续的稠密层提供输入。
由于稠密层无法从分布式推理提供的额外计算或并行性中受益，因此我们的分片策略仅限于将稀疏层移动到远程分片。这是针对深度推荐模型架构的特定设计。图2显示，在嵌入表查找和池化之后，所有生成的嵌入向量和稠密特征在一系列特征交互层中组合。将交互层单独放置在自己的分片上会导致通信增加和计算密度降低。将该层与现有的稀疏分片放置在一起也会增加通信并违反无状态分片的约束。其他架构可能会从分片交互层中受益。例如，考虑一种模型架构，它为特定的嵌入表集提供了专用的特征交互层。这种架构可以将这些特征交互层与其相应的稀疏层分片，从而获得性能提升。尽管这是一种有趣的模型架构，但我们仅限于当前可用的模型，因此本工作选择专注于图2a中更传统的模型。
因此，分片稀疏层（1）直接解决了最大参数的容量问题，（2）有效地并行化了原本顺序执行的稀疏操作符，（3）通过隔离推理中受通信和计算限制的部分，实现了更好的资源分配。需要注意的是，推理传统上不是操作符并行的，因为操作符通常无法产生足够的工作量来抵消调度开销。额外的计算核心通过增加批处理级并行性来利用。
本工作评估了三种基于上述启发式的分片策略（表I）。这些策略应对了大规模深度学习推荐模型的新挑战：嵌入表的数量和大小各异、稀疏性的不均匀性以及实时服务环境的挑战。表I还展示了两种简单情况：（1）非分布式推理（单一分片）和（2）包含所有嵌入表的单一分片。
1) 容量均衡分片
一种直观的策略是将嵌入表均匀地分布在多个分片上。容量均衡分片确保每个稀疏分片具有相同的内存需求。这旨在最小化分片数量，目标是为单个服务模型实现最少的计算资源开销。
2) 负载均衡分片
每个稀疏特征表示为多热编码向量，该向量转换为嵌入表中的多索引查找和最终的池化操作。由于每个表的预期查找次数取决于特定特征及其在请求输入中出现的频率，容量均衡分片可能导致分片负载不均衡，从而执行显著不同的工作量。此外，查找次数与用于发送表索引的网络带宽成正比。这种总体不均衡可能导致某些分片成为关键路径瓶颈，与负载均衡分片配置相比，延迟会降低。
图3中展示的分布式跟踪示例说明了尽管网络延迟的不可预测变化也必须考虑，但一个稀疏分片可能会成为关键路径上的瓶颈。远程分片1和2是异步并行查询的。由于远程分片1执行了显著更多的工作，因此产生了更多的延迟开销。为了减少一个分片持续增加延迟的可能性，负载均衡策略根据嵌入表的池化因子（即预期查找次数）来放置嵌入表。池化因子通过从评估数据集中采样1000个请求并观察每个表的查找次数来估计。
3) 网络特定的装箱策略
推荐模型通常将用户特征和内容/产品特征分离到不同的网络中，以更有效地将用户-内容对批量处理 [1]。在本工作选择的模型中，用户网络的输出被输入到内容/产品网络中，因此它们必须顺序执行。图3展示了这一点，其中网络2依赖于网络1。当每个网络执行时，会调用单独的RPC操作符以访问其相应的嵌入表。如果表未按网络分组，则每个批次中可能会多次访问同一分片，以处理每个网络。这是不理想的，因为：1）在图3中，调用了三个RPC操作符，而如果按分片分组则只需调用两个（每个分片一个RPC）；2）在数据中心环境中，服务器被复制以处理增加的请求时，无论哪个网络接收更多输入，两个网络的表都会被复制。
如果图3中远程分片1的服务器复制是由网络1的池化操作的高计算特性触发的，那么这种情况尤其不理想。网络2的所有嵌入表（可能被分片为数十GB）将消耗额外的、未充分利用的内存资源。为了解决这一问题并实现更高效的资源利用，我们评估了一种网络特定的装箱策略（NSBP），该策略首先按网络对表进行分组，然后根据给定的大小约束将它们装入“箱子”中。为了减少分片过程中消耗的数据中心资源，每个“箱子”最初是训练期间使用的现有稀疏参数服务器。如果参数服务器的“箱子”已满，则将其视为一个完整的分片。这减少了分片所需的网络带宽和计算编排。
C. 分布式推理实现
我们详细介绍了本工作中使用的定制开源框架。这为读者提供了一个具体的实现框架，以便理解我们的结果，并为使用其他框架实现提供指导。在本工作中，分布式推理构建在高度定制的Thrift和Caffe2变体之上，但该方法可推广到任何RPC或ML框架 [30], [31]。尽管PyTorch已经吸收并取代了Caffe2作为未来的最先进框架，但本工作中使用的Caffe2基础设施在两者之间是共享的。Thrift通过加载模型并将接收到的请求适当地拆分为推理批次来处理排名请求。我们使用了一个修改版的Caffe2，其中包含了发出Thrift请求的RPC操作符。对稀疏分片的中间请求通过通用服务发现协议进行路由。所有服务器间的通信通过以太网上的标准TCP/IP协议栈进行。模型在训练后被转换为分布式推理格式。一个自定义的分区工具使用用户提供的配置来分组嵌入表及其操作符，插入RPC操作符，生成新的Caffe2网络，然后将模型序列化到存储中。
IV. 跨层ML操作符和通信感知的特征分析
分布式推理的性能由系统多个层次的选择决定，特别是数据中心服务层（调度、发现和网络）、机器学习框架层以及机器学习操作符本身。跨这些层次测量工作负载对于理解开销、归因成本、优化目标组件以及做出高层系统设计决策非常重要。由于没有现成的分析工具可以执行这种跨层特征分析，我们构建了一个自定义的跨层分布式跟踪框架来测量分布式推理工作负载。
A. 通过分布式跟踪捕获工作负载
分布式跟踪是一种经过验证的技术，用于调试和调查跨依赖服务的性能问题 [34], [35]。我们利用这种技术来研究分布式推理基础设施的性能影响。在生产服务堆栈的多个层次中添加了自定义检测，以提供请求/响应序列化、RPC服务样板设置以及每个请求的模型执行的完整成本视图。
Thrift 和 Caffe2 都提供了检测钩子（instrumentation hooks）来捕获执行中的关键点，而服务处理程序则需要更侵入式的修改，尽管仍然保持轻量级。我们选择了源代码检测而非其他二进制检测方法，因为它的开销更小，并且可以与 Thrift 的 1
RequestContext
图3展示了一个分布式跟踪的示例。分片通过水平切片分隔，主分片位于顶部处理请求。该示例跟踪表示单个批次的执行，但根据排名请求的数量和可配置的批次大小，通常会并行执行多个批次。此外，操作符的执行顺序是本工作中研究的推荐模型的典型顺序。操作符被调度为顺序执行——除非像 RPC 操作符那样明确是异步的——因为其他核心通过请求级和批次级并行性来利用。首先执行初始的稠密层，然后是稀疏查找，接着是后续的特征交互层和顶部的稠密层。
如第III-A节所述，每个稀疏分片都是一个完整的RPC服务，以实现部署的灵活性，因此与本地内联计算相比，会带来与服务相关的开销。图3展示了每个稀疏分片中未用于执行SLS操作符的时间即为延迟开销。在非分布式情况下，SLS操作符直接在主分片中执行。额外的延迟归因于网络链路、输入和输出的额外（反）序列化，以及准备和调度Caffe2网络所花费的时间。尽管存在这些开销，我们也看到分布式计算的异步特性使得稀疏操作符能够实现更多的并行化。这一特征分析的一个重要启示是，在增加并行化以减少延迟开销和减少并行化以降低计算和数据中心资源开销之间存在权衡。此外，这种权衡是特定于每个模型的。
B. 跨层归因
与简单的基于操作符的计算或端到端（E2E）延迟计数器相比，捕获跨层跟踪提供了计算和延迟的整体视图。图3中的示例流程展示了RPC序列化和反序列化以及软件基础设施的请求/响应处理带来的计算开销。每个线程在调度和记录异步RPC操作符时也会产生额外的计算。简单的端到端延迟开销可以轻松地在主分片中测量。然而，由于每个稀疏分片是并行执行的，延迟开销的归因更为复杂，涉及稀疏分片请求之间的重叠。为了简化分析，每个主分片请求中最慢的异步稀疏分片请求被用于延迟分解。使用相关稀疏分片中的网络、序列化和RPC服务延迟。由于不同服务器上的时钟可能存在偏差，网络延迟通过主分片中测量的未完成请求与稀疏分片中测量的端到端服务延迟之间的差异来计算。
V. 实验方法与工作负载
我们评估了生产级的分布式服务软件基础设施，以量化其对计算需求、延迟和分片效果的影响。本研究的目的是评估分布式推理作为支持大规模深度推荐模型的一种手段的实用性，并为这一新颖工作负载的进一步系统探索提供基础。在本节中，我们描述了为本研究选择的数据中心深度学习推荐模型以及底层硬件平台。
A. 推荐模型
本研究使用了三个类似DLRM的模型，分别称为DRM1、DRM2和DRM3，这些模型涵盖了一系列大型模型属性，例如不同的输入特征和嵌入表特性。前缀“D”用于区分这些分布式模型与最近深度学习推荐工作中讨论的特定模型 [1]–[3]。DRM*模型是众多可能的、不断演变的模型的一个子集，并因其稀疏特征特性而被选为分布式推理的早期候选。研究这些模型的目的是通过我们的跨层分布式跟踪分析为评估分布式推理的开销提供基础，它们不应被解释为像MLPerf基准测试套件 [9] 中包含的典型基准模型。
图4、图5和表II展示了大型神经推荐模型中的多样性。DRM1和DRM2有两个网络，每个网络都有其各自的稀疏特征，而DRM3只有一个网络。由于使用了每个模型的真实采样请求，推理请求的大小以及相应的计算和延迟在模型之间也有所不同。所有参数均以单精度浮点数形式存储，未进行压缩。第VII-D节讨论了压缩的影响。图4展示了每个模型的每操作符组归因，这是非分布式模型所有采样请求的简单平均值。DRM1和DRM2是最相似的架构，这反映在图4中。与DRM3相比，DRM1和DRM2具有更复杂的结构，这体现在额外的张量变换成本上。与本工作更相关的是，稀疏操作符在所有操作符中所占的比例远高于DRM3。具体而言，稀疏操作符在DRM1、DRM2和DRM3中分别占所有操作符时间的9.7%、9.6%和3.1%。尽管它们的计算比例较低，但稀疏操作符在DRM1和DRM2中占模型容量的>97%，在DRM3中占>99.9%。
图4
为了将所有模型适配到单个256GB服务器上，大于给定阈值的嵌入表按比例缩小。这为表I中列出的所有分片策略（包括单一分片）提供了计算和延迟开销的直接比较。原始数据中心规模的模型要大得多。
图5展示了每个模型中嵌入表大小的分布。DRM1的大小为200GB，包含257个嵌入表，最大的表为3.6GB。DRM2的大小为138GB，包含133个嵌入表，最大的表为6.7GB。最后，DRM3的大小为200GB，包含39个嵌入表，最大的表为178.8GB。与DRM3相比，DRM1和DRM2展示了嵌入表大小的长尾分布，这解释了图4中显示的额外稀疏操作符成本。相比之下，DRM3由一个单一的大表主导。这些嵌入表是先前深度学习推荐工作中讨论的表的代表性版本 [1], [3], [9]。
图5
对于DRM1和DRM2，评估了十种分片配置。表II描述了DRM1的分片策略结果。在负载均衡配置中，每个分片的容量差异高达50%，而在容量均衡配置中，每个分片的总容量相同。在容量均衡配置中，每个分片的估计负载差异高达371%（在8个分片的情况下，分片4和分片3之间），而在负载均衡配置中，每个分片的总池化因子相同。最后，网络特定的装箱策略（NSBP）将每个分片的表限制为单一网络。这在2分片配置中最为明显，其中每个网络被放置在自己的分片上。分片2消耗的内存容量是分片1的4.75倍，但估计仅执行分片1计算工作的6.3%。
由于分片超大表的技术挑战，DRM3仅使用NSBP策略进行分片，而未采用容量均衡或负载均衡策略。由于它由一个单一的大表主导，每增加一个分片，最大的表会进一步拆分，而较小的表则分组为一个分片。主导表的池化因子为1，因此只有跨越该表的一个分片会被访问。例如，给定四个稀疏分片，最大的表被划分为三个分片，其余的表分组为一个分片。每次推理仅会访问两个分片：一个用于分片的大表，另一个用于较小的表。
B. 测试平台
为了进行特征分析，我们使用了代表数据中心环境的两类服务器。SC-Large代表数据中心中的典型大型服务器，配备256GB DRAM和两个20核Intel CPU。SC-Small代表典型的更高效的Web服务器，配备64GB DRAM和两个时钟频率较低的18核Intel CPU，并且网络带宽低于SC-Large。由于SC-Small的DRAM容量有限，只能在该平台上测试部分配置。第六节中讨论的大部分结果是在SC-Large平台上收集的，以便与非分布式模型进行公平比较。关于服务器平台影响的讨论见第七节。
所有推理实验均在CPU平台上运行，如第二节所述。预留的裸金属服务器与生产推荐排名服务器位于同一数据中心，并使用相同的内部网络。它们在数据中心内的位置代表了典型的推理服务层。分片被分配到独立的服务器上，而不是共置。分片到服务器的映射在重复试验中随机分配。推荐排名请求从生产服务器中采样，并在测试基础设施上重放；去标识化的请求数据库在五天时间内均匀采样，以捕获请求中的昼夜行为。生产重放器在将请求发送到推理服务器之前对其进行预处理和缓存，使用与在线生产排名相同的网络基础设施。
在大多数实验运行中，推理的批次大小设置为生产默认值，其中每个批次代表要排名的推荐项目数量，并并行执行。在第六节中，请求被串行发送，以隔离固有开销。在第七节A部分中，请求被异步发送，以模拟更接近生产环境的更高QPS率。
VI. 分布式推理分片分析
在本节中，我们讨论了跨层分布式跟踪分析的结果。我们发现，在严格的延迟目标和数据中心环境的计算规模下，设计空间比简单地最小化分片数量更为复杂。我们的主要结论如下：
- 增加分片数量可以通过有效增加模型并行性来管理RPC操作符带来的延迟开销。
- 然而，增加分片也会因服务样板和调度而带来额外的计算成本。
- 串行发送的阻塞请求在分布式推理中的P50、P90和P99延迟表现总是更差，这是由于简单的Amdahl定律限制。深度推荐系统的嵌入查找在端到端延迟中占比不够大，无法从增加的并行性中受益。
- 与容量均衡策略相比，负载均衡策略对端到端延迟的影响不显著。网络特定的装箱策略（NSBP）在延迟方面表现最差，但在计算方面表现最佳。
- 某些模型的工作量不足以并行化，因此无法从额外的分片中减少开销。
研究结果表明，分布式推理是服务大规模深度学习推荐模型的实用解决方案，而现有的服务范式无法支持这些模型。研究结果还暴露了对分片之间网络链路和支持通信管理的软件基础设施进行针对性分析的需求，因为稀疏分片上执行的工作量较少。结果表明，自动分片方法是可行的，但需要足够的分析数据，因为嵌入表行为的多样性和分片策略的复杂权衡。
A. 分布式推理开销
图6和图7展示了所有模型在串行阻塞请求下，所有分片策略的P50、P90和P99端到端（E2E）延迟和总计算时间开销。每种分片策略的描述见表I。请注意，单一分片是非分布式情况，而1分片是所有嵌入表位于一个稀疏分片上的最坏情况。P90和P99延迟是推理服务的典型指标，因为如果推理请求未在SLA目标内处理完成，则会返回准确性较低的备用推荐结果。为了完整性，P50也被展示出来，以显示中位情况，而不是平均值，因为先前的工作中讨论了长尾延迟 [1]。
图6
图7
B. 延迟开销
1) 增加分片可以减少延迟开销：所有模型的分布式推理配置均出现了端到端延迟增加，如图6和图7所示。稀疏操作符的并行化与异步RPC操作符的结合不足以抵消增加的网络延迟和软件层开销。对于DRM1和DRM2，延迟表现最差的配置是一个稀疏分片，这是不切实际的最坏情况，所有嵌入表都放置在一个分片上，没有并行化工作。令人鼓舞的是，在2分片负载均衡配置下，DRM1的P99延迟开销仅为7.3%。在8分片负载均衡配置下，这一开销降至P99的1%，P50中位情况的11%。这表明，通过简单的分片策略可以实现最小且实用的延迟开销。出乎意料的是，2分片NSBP策略在DRM1的P99延迟中表现最差，在DRM2中几乎表现最差。回顾表II，大部分工作（池化因子）被分配到一个分片上，因此在P99情况下，2分片NSBP配置实际上类似于1分片配置的边界情况。
2) 恒定开销最终占据主导地位：随着分片数量的增加，每个分片的工作量减少，网络延迟和额外的软件层开销占据主导地位，如图8所示。网络延迟通过主分片的未完成请求时间与稀疏分片的总端到端时间之间的差异来测量。这个时间包括内核数据包处理和转发时间。对于所有分布式推理配置，网络延迟均大于操作符延迟。分布式推理总是会损害这些模型的延迟。换句话说，如果稀疏操作符平均产生足够的工作量，那么模型将适合分布式推理。并且，在稀疏操作符工作量足够的情况下，延迟可以得到改善。这为系统架构师、模型架构师和特征工程师提供了一个多学科合作的机会，以平衡模型资源消耗、性能和准确性。
3) 分片影响取决于模型架构：对于DRM3，分片数量没有显著影响。DRM3由一个单一的大表主导，如图5所示，该表在分片之间拆分。即使在8分片的情况下，每个推理请求也只访问2个分片——一个分片包含较小的表，另一个分片包含分片后的最大表的条目，如图11a所示。
4) 深入的延迟层归因：图8展示了跨跟踪层的P50（中位数）延迟的细分。图8a显示，只有工作负载的嵌入部分在不同分片策略下显著受到影响，这是意料之中的，因为这部分工作负载被卸载到稀疏分片上。Dense Ops是指所有非嵌入表查找和池化操作的ML操作符；Embedded Portion是指所有嵌入表查找和池化操作符。对于单一分片配置，这是操作符本身的时间，而对于分布式推理配置，这是等待稀疏分片响应的时间，如图8a所示。RPC Serde指所有序列化和反序列化请求时间，而RPC Service是指严格未花费在Caffe2网络或序列化/反序列化上的其他时间。最后，Net Overhead是指网络中未用于执行操作符的时间，例如异步操作符的调度。对于分布式推理配置，嵌入部分延迟的影响反映了图6和图7中显示的开销。
图8
在DRM1的单一分片配置中，嵌入部分仅占延迟的约10%，而在单分片配置中，这一比例为32%。在8分片负载均衡的最佳分布式推理情况下，嵌入部分占总延迟的15.6%。相比之下，DRM3的嵌入部分在分片增加时没有显著变化，因为只有主导的大表被进一步分区。DRM3的延迟和计算变化归因于缓存效应和与更多服务器节点通信的网络变异性。图8b进一步归因了嵌入部分内的延迟——每个条形堆栈代表图8a中的嵌入部分。对于P99，嵌入部分的重要性降低，而主分片上的稠密操作符和RPC反序列化开始占据主导地位，这是由于非常大的推理请求大小。这就是为什么P99延迟开销比P50更有利的原因。
C. 计算开销
理解计算开销对于最小化数据中心规模的额外资源需求至关重要。分片策略是系统设计者平衡延迟约束（如前一节所述）和影响资源需求的计算开销的一种方法。
1) 增加计算开销是减少延迟开销的权衡：高计算开销是灵活、易于部署系统的代价。如前一节所述，增加稀疏分片可以减少分布式推理的延迟开销。然而，计算开销也会增加，因为每个分片都会调用完整的Thrift服务。图9显示，对于所有模型，分布式推理总是会增加计算开销，因为需要额外的RPC操作。更重要的是，图9表明计算开销与RPC操作的数量成正比。NSBP策略的计算开销最小，因为它执行的RPC操作最少。回想一下，NSBP策略限制每个分片不混合来自不同网络的嵌入表，因此每个分片在每次推理中仅被调用一次。对于多个网络，每个网络的并行化程度较低。相比之下，其他分片策略可能会更多地并行化每个网络，从而调用更多的RPC操作，导致整体计算开销增加。
图9
2) 计算开销影响数据中心资源：当计算开销发生在主分片上时，问题尤其严重，因为它会增加计算驱动的复制和资源需求，以处理相同的QPS。当主分片上发出RPC操作所需的计算开销超过通过卸载嵌入部分节省的计算时，就会发生这种情况。对于具有许多大嵌入表和低池化因子的模型架构，这种情况更有可能发生。研究结果为探索这些拐点提供了动力，这些拐点应作为未来自动分片方法的输入，并依赖于模型属性和软件基础设施。这一点在第七节中进一步讨论。
D. 分片策略效果
前一节中已经确定了由于分片数量增加而导致的延迟增加或计算开销增加之间的权衡。分片数量是系统设计者平衡计算开销与延迟约束的一个直接调节手段。本节讨论的分片策略为设计者提供了另一个调节手段，但其对延迟和计算的影响更为微妙。
1) NSBP是最具可扩展性的策略：负载均衡和容量均衡配置之间的延迟开销没有显著差异。然而，网络特定的装箱策略（NSBP）因受额外分片影响较小而表现出不同。这一观察的最重要结论是，NSBP是评估中最具可扩展性的策略，因为它调用的RPC操作较少。
NSBP展示了最不平衡的每分片延迟。回想一下，在这种策略中，嵌入表首先按网络分组，然后根据网络和大小分配到分片。来自不同网络的表永远不会分配到同一分片。图10通过负载均衡和NSBP策略的每网络操作符延迟更清楚地展示了这一点。分片1和分片2包含执行最多工作但表大小最小的第一个网络，如图10b和表II所示。对于NSBP，这对延迟产生了负面影响，因为并行化的工作较少，但计算开销由于较少的并行化而受到较小的影响，因此调度和服务开销也较少。请注意，Net1和Net2是顺序执行的，因此它们对端到端延迟的累积影响是相加的。NSBP策略在资源利用率方面的优势将在第七节进一步讨论。
图10
2) 负载均衡和容量均衡策略之间的开销差异很小：图12展示了DRM1在所有请求下的8分片配置的每分片操作符延迟；DRM2显示出类似的趋势，为简洁起见省略。回想一下第III-B节，负载均衡策略预计通过消除任何分片成为关键路径来降低延迟开销。然而，与端到端延迟相比，两种策略的每分片操作符延迟都微不足道。此外，负载均衡和容量均衡策略之间的延迟差异并不显著，正如表II中估计的池化因子所暗示的那样。在这种规模下，池化因子太小，无法显示出明显的效果。对于DRM1和DRM2，负载均衡和容量均衡分片策略之间的最大影响来自分片数量的增加。
E. 模型多样性
模型属性也会影响分布式推理性能。网络数量、嵌入表数量、大小分布和相应的池化因子是最相关的模型属性，并在第V-A节中对评估模型进行了描述。与DRM1和DRM2中的长尾嵌入表相比，DRM3的稀疏操作符总计算量较少，并且由一个单一的大嵌入表主导。DRM1和DRM2的延迟受益于增加分片，但DRM3没有显示出这种优势，如图7和图8所示。
1) 分片效果取决于模型架构：图11单独展示了DRM3的每分片操作符延迟和嵌入部分细分，以显示增加分片不会改善延迟。主要原因有两个。(1) 增加分片只会分区一个容量主导的嵌入表，这不会并行化任何显著的计算。图11a显示分片1执行了大部分计算，因为它包含除最大表之外的所有嵌入表，而最大表在其他分片之间分区。(2) 即使较小的表被分区，相对较低的计算量仍然无法实现实际的延迟改进，因为网络延迟在端到端延迟开销中占据主导地位。因此，我们得出结论，只有像DRM1和DRM2这样具有长尾嵌入表和较高池化因子的模型才能从分片中受益。
图11
F. 批处理效果
推理的批处理大小将请求拆分为并行任务，是在满足SLA和QPS目标的前提下平衡吞吐量和延迟的关键。为了展示其与分布式推理的交互，我们将批处理大小人为设置为每个请求一个批次。较小的批处理大小增加了每个请求的任务级并行性，可以减少延迟，但会增加任务级开销并减少数据并行性，从而可能降低吞吐量。相比之下，较大的批次增加了稀疏操作符的工作量，并受益于分布式推理的并行化。深度学习推荐推理的批处理大小是一个正在进行的研究课题 [2]。
1) 分布式推理在足够大的批处理大小时可以改善延迟：图13显示，在使用8分片容量均衡或负载均衡配置时，分布式推理可以在DRM1单批次情况下改善延迟。这是因为稀疏操作符执行了足够的工作，从而充分受益于并行化，如图13b所示。DRM2显示出类似的趋势，但由于请求较小，影响不那么显著。在这种情况下，较大的批次可以被视为具有较大池化因子的嵌入表的代理，其显著特征是通过RPC发送的额外查找索引增加了稀疏操作符的工作量和网络需求。DRM3未显示，因为其请求通常足够小，默认批处理大小下每个请求只有一个批次。
图13
2) 批处理大小可以管理分布式推理的计算开销：图14强调了计算开销的倍增效应——每个额外的批次都会发出相应的RPC操作，从而增加计算需求。例如，由于DRM1的NSBP策略每个分片发出一个RPC，其计算开销随着分片的增加而增加的速度比负载均衡策略慢。在每请求一个批次的情况下，分片带来的计算开销的边际增加不那么严重。因此，在探索分布式推理计算开销时，必须考虑批处理大小。
图14
VII. 数据中心环境中的影响
在本节中，我们讨论了分布式推理对深度推荐系统在数据中心中的影响。分析延迟和计算开销对于理解分布式推理对SLA目标和额外计算资源的影响非常重要。然而，第六节中的分析集中于一个简化的场景，以归因每个请求的开销，其中（1）每个请求被串行处理，（2）服务器具有相同的SC-Large硬件配置，这些配置是过度供应的。为了模拟更具代表性的服务环境，我们在DRM1上进行了两个额外的实验，DRM1是计算最密集的模型。首先，我们以更高的25 QPS速率发送请求，覆盖所有分片策略，并使用相同的SC-Large硬件配置。其次，我们在更典型的Web服务平台SC-Small上重新运行负载均衡配置，与SC-Large进行比较，请求再次被串行发送。我们将结果置于一个服务环境中，其中模型实例被复制以处理实时流量。最后，我们讨论了当前在大型数据中心规模的深度推荐系统中实施的现有压缩技术。我们的主要观察结果如下：
- 以更高的QPS发送的请求（代表数据中心环境）在P99延迟下表现更好，因为资源可用性得到了改善。
- 在SC-Large和SC-Small之间，稀疏分片的每请求延迟没有显著差异，这为通过低功耗的稀疏分片服务提供了提高效率的机会。
- 分片复制通过独立分配模型的稠密和稀疏部分的资源，提供了提高服务效率的机会。
- 压缩是分布式推理的补充，本身无法解决模型的可扩展性问题。
A. 高QPS环境
请求重放器被配置为以25 QPS的速率向DRM1的主服务器发送请求，DRM1是所有评估模型中计算最密集的。每个DRM1配置的开销图与单一配置相比，如图16所示。在25 QPS实验中，所有配置的开销都比串行发送时的相同配置低，如图6所示。在几乎所有配置中，P99延迟都比单一配置有所改善，如图6所示。
此外，在某些配置中，例如8分片的容量均衡和负载均衡配置，P50延迟比单一配置有所改善，或者开销小于约0.05%。在具有足够稀疏操作符计算量的模型中，分布式推理在高QPS场景中具有更好的延迟特性。
B. 稀疏分片平台的效率
为了对分布式推理中增加服务器进行公平比较，稀疏分片使用了相同的硬件平台。然而，图8和图12显示，稀疏分片的计算需求远低于主分片，因为本工作中的分片是容量驱动的，而非计算驱动的。因此，我们使用较轻量级的SC-Small服务器运行了DRM1的额外配置，DRM1仍然是计算最密集的模型。图15显示，当在原始较重量级的SC-Large和较轻量级的SC-Small服务器上运行时，每分片操作符延迟几乎相同。回想一下，SC-Large服务器具有更多且更快的核心，以及4倍的内存容量，导致能耗增加。这表明，通过粗粒度的平台专业化，稀疏分片可以在集群级别提高服务效率和能源效率。
图12
图15
C. 数据中心中的复制
在本节中，我们简要讨论了分布式推理如何改善分片复制。支持具有数百GB内存占用的单一模型需要配置效率低下的服务器。例如，大部分内存容量将用于大型嵌入表，但大多数核心将用于使用显著较小的稠密参数。对于DRM1、DRM2和DRM3，大多数计算仅涉及模型内存占用的不到3%。这种低效性在动态复制推理服务器以支持数百万或数十亿用户的QPS时会被放大。在这种情况下，稠密层带来的大负载（如图4所示）将导致整个模型被复制到额外的服务器上，包括所有嵌入表。分布式推理通过允许为稠密层分配计算资源，为稀疏层分配内存资源，缓解了这种低效性。换句话说，复制的内存需求减少了。我们将模型的稠密层和稀疏层分片为独立组件的启发式方法简化了这种分配。最后，分片策略在复制中起到辅助作用。虽然分片稀疏操作符的决定对减少复制的内存需求影响最大，但表II显示分片策略可以进一步影响复制。回想一下，DRM1由两个主要网络组成，其中Net 2消耗的内存资源是Net 1的4.75倍，但计算资源仅为Net 1的6.3%。NSBP分片策略将每个分片限制为仅包含Net 1或Net 2，因此与网络无关的分片策略相比，其并行化效果较差。然而，NSBP可以通过将计算最密集的嵌入表分组在一起，进一步提高资源利用率，即使是在需要更多分片的大型模型中。这种在改善延迟和提高资源利用率之间的分片策略权衡需要基于每个模型的具体情况进行，并鼓励进一步研究分片自动化。
D. 模型压缩
模型压缩是限制模型容量的传统方法。我们在表III中展示了DRM1的压缩模型大小作为参考。当前数据中心模型中部署的所有压缩技术（包括量化和剪枝 [22]）被用于生成压缩模型。所有表均按行线性量化至至少8位，足够大的表被量化至4位。表根据模型架构师指定的阈值幅度或训练更新频率手动剪枝。量化和剪枝选项的选择是为了保持准确性和延迟。我们注意到，压缩后延迟和计算略有改善，但由于这不是本工作的重点，我们将此分析留待未来工作。我们推测原因是内存局部性的相对改善。更相关的是，表III显示压缩模型缩小了5.56倍。虽然显著，但即使有这些节省，大型模型仍然无法适配到一台、两台甚至四台配置了约50GB可用DRAM的商品服务器上。因此，仅靠压缩不足以支持新兴的大型深度推荐系统。