介绍

Nvidia在《A GPU-specialized Inference Parameter Server for Large-Scale Deep Recommendation Models》提出了面向大规模深度推荐模型的GPU专用推理参数服务器。

摘要

推荐系统对于各种现代应用和网络服务至关重要，例如新闻推送、社交网络、电子商务、搜索等。为了实现最高的预测准确性，现代推荐模型结合深度学习和数万亿级别（terabyte）的嵌入表，以获得底层数据的细粒度表示。传统的推理服务架构需要将整个模型部署到独立的服务器上，但在这种大规模下这是不可行的。

在本文中，我们提供了关于在线推荐系统的有趣且具有挑战性的推理领域的见解。我们提出了HugeCTR分层参数服务器（HPS:Hierarchical Parameter Server），一种行业领先的分布式推荐推理框架，结合了高性能GPU嵌入缓存和分层存储架构，以实现在线模型推理任务的低延迟检索嵌入。HPS的特点包括：

• （1）冗余的分层存储系统；
• （2）一种新颖的高带宽缓存，以加速NVIDIA GPU上的并行嵌入查找；
• （3）在线训练支持；
• （4）轻量级API，便于轻松集成到现有的大规模推荐工作流程中。

为了展示其能力，我们使用合成工程和公共数据集进行了广泛的研究。我们发现，HPS可以显著降低端到端推理延迟，根据batch-size大小，相较于CPU基线实现，为流行的推荐模型实现了5~62倍的加速。通过多GPU并发部署，HPS还可以大大提高推理QPS。

1 引言

推荐系统（RS）广泛应用于各种应用和在线服务中，例如新闻推送、电子商务、社交网络、搜索等。为了提供准确的预测，最先进的算法依赖于基于embedding的深度学习模型。图1展示了一个深度推荐模型（DLRM）的典型架构。输入包括dense特征（例如，年龄、价格等）和sparse特征（例如，用户ID、类别ID等）。sparse特征通过在嵌入表中查找转换为dense的embedding向量，以便将这些向量与dense特征结合后输入到一些dense连接的深度学习模型（例如，多层感知机MLP、Transformer等[38, 39]）中，从而预测点击率（CTR）。

图1

embedding可能会占用数据中心内存容量的很大一部分。通常，从集中式参数服务器中检索这些embedding会花费大量时间，这增加了延迟，从而拖慢了后续的计算。与面向吞吐量的训练系统[5, 7, 12–14, 16, 17, 22, 42]不同，在线推理系统严格受限于延迟要求[40]。因此，embedding查找速度对于深度推荐模型的推理性能至关重要。

在推理过程中，每个小batch的数据通常引用数万个embedding。通过键值对每个embedding进行穷举搜索，需要参数服务器遍历某些内部数据结构。从嵌入表中查找单个embedding通常是独立的，因此很容易并行化。同时，现代GPU架构允许调度数千个线程并发运行，其内存子系统采用了特殊的内存技术，提供比同等CPU内存更高的带宽和吞吐量[27]。这些特性使得GPU架构非常适合处理embedding向量查找的工作负载。

挑战。最先进的推荐模型中使用的嵌入表规模可能非常庞大，通常从数十GB到数TB不等，这远远超出了大多数GPU的内存容量。此外，在线推理期间的batch-size通常太小，无法有效利用单个GPU的大规模并行处理优化的计算资源。因此，嵌入查找工作负载需要大量的GPU内存，但只需要很少的计算资源。这种需求的不平衡与现有硬件显著偏离，降低了GPU在推理系统中的吸引力。因此，大多数现有解决方案将嵌入查找操作与dense计算（即模型的其余部分）解耦，后者在GPU中执行，而将嵌入查找操作移至CPU[21]。这样一来，它们放弃了GPU的内存带宽优势，而CPU以及CPU与GPU之间的通信带宽成为主要瓶颈。结果，GPU的不成比例的处理能力在这种设置中大多处于闲置状态（=资源浪费）。

方法。通常无法将所有嵌入表完全保留在GPU内存中。然而，实际推荐数据集的实证研究表明，在CTR和其他推荐任务的推理过程中，嵌入键(embedding key)的访问通常表现出很强的局部性，并且大致遵循幂律分布[5, 7, 12, 17]。因此，每个小batch中的大部分嵌入键仅引用一小部分热门嵌入。将这些热门嵌入缓存在GPU内存中（模型的其余部分也在GPU中处理），可以实现部分GPU加速的嵌入查找。基于这些观察，我们构建了一个推理框架，即HugeCTR分层参数服务器（HPS），以充分利用GPU资源，同时不受GPU内存限制的约束。特别是，HPS引入了一种GPU嵌入缓存数据结构，试图将热门嵌入保留在GPU内存中。该缓存由一个参数服务器补充，该服务器保存所有嵌入表的完整副本。我们的贡献可以总结如下：

• 分层数据库架构：允许利用集群内存资源，并提供异步更新机制，以在在线推理期间保持较高的GPU嵌入缓存命中率。
• 高性能动态GPU嵌入缓存：通过跟踪并缓存高频出现的嵌入到高吞吐量的GPU内存中，同时重叠主机/设备数据传输，从而最大化吞吐量。
• 在线模型更新机制：支持分布式推理部署（即实时更新）。
• 可定制的HPS后端：为NVIDIA Triton GPU推理服务器[31]提供并发模型执行、混合模型部署和集成模型管道服务。

本文的结构如下。在第2节中，我们对支撑我们方法的核心概念进行了基础性讨论。随后，在第3至第5节中，我们介绍并讨论了HPS的各个组件及其交互方式。在第6节中，我们讨论了HPS如何实现实时模型更新。最后，在第7节中，我们通过实验研究评估了HPS的性能，并在第8节中提供了结论性意见。

2 背景

2.1 嵌入表

当前广告、推荐和搜索领域的主流算法采用了一种将嵌入表与深度神经网络结合的模型结构，形成深度学习推荐模型（DLRM）[24]。这类模型的基础是嵌入 $e$，它表示用户或物品特征的学习数值表示，以dense向量的形式在某个 $d$ 维空间中对齐（$e \in \mathbb{R}^d$）。我们用 $E_j = {e^0_j, e^1_j, \dots, e^n_j}$ 表示某个特征 $j$ 的嵌入的离散子集。为了在模型中方便访问，我们将这些嵌入组织为嵌入特征表，形式如下：

其中：

• 每个元组 $\langle k^i_j, e^i_j \rangle$ 包含一个键 $k^i_j$，用于标识和引用第 $i$ 个嵌入表条目 $e^i_j$。
• 键空间 $K_j = {k^0_j, k^1_j, \dots, k^n_j}$ 是离散的，且满足 $\forall k^i_j, k^z_j \in K_j$ （$i \neq z \rightarrow k^i_j \neq k^z_j$）。每个键的值取决于底层数据或任务。通常，键空间是稀疏的。

为了评估DLRM的CTR（参见图1），驱动应用程序必须首先从嵌入表中选择与预测相关的条目。这可以通过从每个嵌入特征表的查询键子集 $Q_j$ 中查找键来完成（即 $Q = {Q_0 \subseteq K_0, Q_1 \subseteq K_1, \dots}$）。因此，$ Q_j = {q^0j, q^1_j, \dots, q^m_j} $表示从$ T_j $中查找$ m $个对应嵌入条目的查询。对应的结果集为$ R{Q_j} = {q^0_j \mapsto e^0_j, q^1_j \mapsto e^1_j, \dots, q^m_j \mapsto e^m_j} $。我们的主要目标是加速大规模检索此类结果集。

2.2 去重与偏斜性

为了避免在多次需要相同嵌入表条目时进行不必要的重复查找，HugeCTR 在执行任何后续步骤之前始终应用去重操作（即 $Q^* = \text{dedup}(Q)$）。这对于小batch处理尤为重要，其中： $Q$ 是许多输入样本的拼接。自然，如果查询分布 $Q$ 的偏斜性增加，去重的效果会更加显著。

理解并利用数据集的偏斜特性对于实现峰值效率至关重要。许多现实世界中的推荐数据集（例如 Criteo [6]）呈现出幂律分布 [3]。也就是说，某些键子集比其他键更频繁地被引用，使得从 $Q_j$ 中采样 $q_j$ 最终近似满足 $p(x) \propto x^{-\alpha}$。图 2 展示了一个场景，其中嵌入键的召回统计量近似于幂律分布。

图2

键空间可以分为三类：

1. 频繁嵌入：这些嵌入几乎出现在每个batch中，占据了召回/更新请求的很大一部分。频繁集通常很小，即使对于大型嵌入语料库，也只有几千个嵌入会如此频繁地出现。
2. 随机嵌入：这些嵌入每隔几个batch出现一次（即随着时间的推移相对规律地出现）。
3. 稀有嵌入：这些嵌入位于分布的另一端，在查询中出现的频率非常低。

由于请求会反复引用频繁和随机嵌入，对它们应用高效的缓存方法可以最大程度地提高整体系统性能。我们的 HPS 设计（见第 3 节）正是基于这一观察。

如果查询数据集是固定的，嵌入的类别划分是绝对确定的。在训练 HugeCTR 模型时，我们利用这一点来实现世界级的模型收敛速度 [8, 19]。在在线推理过程中，召回统计量取决于实际传入的用户请求，这些请求无法被预先预测。由于突发事件、趋势或时尚的变化，单个嵌入的类别划分可能会随时间而变化。对于大多数推荐任务而言，运行时统计量处于不断变化中。因此，推理系统必须具备自适应性。

2.3 GPU加速推理架构

用于机器学习推理工作负载的参数服务器，主要依赖于可以轻松与GPU并行化的数据库操作[35, 37, 41]。需要快速响应时间的应用，例如在线事务处理（OLTP），通常能够从GPU加速中受益匪浅[1]。然而，GPU内存限制带来了严峻的挑战。为了实现可扩展性，许多现有的GPU加速数据库系统以及我们的方法都采用了分层存储架构，通过其他存储资源扩展可用的GPU内存。由于外部内存资源的访问效率无法与本地GPU内存相媲美[27]，因此在这些系统中，与主机系统的数据交换性能被特别强调[23]。为了实现峰值性能，必须将重叠查询处理与高效的通信模式和数据放置策略结合使用，并在运行时动态优化[1, 2, 20]。

为机器学习平台构建参数服务器面临许多挑战[2, 5, 7, 12–14, 16, 17, 20, 22, 42]。在设计用于推理生产环境的混合GPU/CPU架构时，至少需要克服两个主要瓶颈：

1. 高延迟：由于CPU和GPU之间通信时的DRAM带宽限制[18, 40]。
2. 部署延迟：由于在线训练导致的模型规模和复杂性增加，因为快速的增量模型更新在数据一致性和带宽方面提出了巨大挑战。

为了解决这些瓶颈，我们的HPS专门设计为用于大规模推荐模型的GPU推理参数服务器。它处理数据同步和通信，以在不同推理节点之间共享模型参数（嵌入表）[26]，并执行各种优化以提高并行多模型/多GPU推理期间的GPU利用率，包括将分布式嵌入表组织为分区[25]、GPU友好的缓存[30]以及异步数据移动机制[29]。

3 分层参数服务器

我们的分层参数服务器（HPS）使HugeCTR能够使用具有巨大嵌入表的模型进行推理。这是通过利用集群中的CPU内存资源扩展嵌入存储空间，超越GPU的限制来实现的。HPS的设计目标是解决传统CPU参数服务器方法通常面临的三个主要挑战：

1. 模型参数的下载/流式传输：从CPU内存中集中维护的嵌入表分区到各个GPU计算设备上的模型实例。如果嵌入表无法完全装入GPU内存，这个问题会被放大。HPS通过利用数据分布的局部性的GPU缓存机制，极大地缓解了这一问题。

2. 因推理平台高可用性需求和带宽限制而增加的部署成本：通过联合组织和使用推理集群的分布式CPU内存，HPS节省了资源，并实现了即时在线模型更新（即从训练到推理的更新）。

3. GPU缓存与参数服务器之间的参数更新和刷新：如果仅将模型的一部分加载到GPU内存中，则在查找期间GPU上可能会遗漏参数，这尤其具有挑战性。HPS通过异步插入和刷新机制处理CPU和GPU之间的额外参数交换，以保持参数的一致性。

3.1 存储架构

我们的HPS实现为一个3级分层内存架构（参见图3），利用GPU的GDDR和/或高带宽内存（HBM）、分布式CPU内存以及本地SSD存储资源。

图3

这些组件之间的通信机制确保：最频繁使用的嵌入驻留在GPU嵌入缓存中，较为频繁使用的嵌入缓存在CPU内存中，而所有模型参数的完整副本（包括那些很少出现的参数）始终保存在硬盘/SSD上。为了最小化延迟，我们将参数更新以及从更高存储级别（SSD → CPU内存 → GPU内存）迁移缺失参数的过程与密集模型计算重叠。HPS的三级内存架构定义如下：

GPU嵌入缓存（第1级）：这是一个为推荐模型推理设计的动态缓存。它通过巧妙地利用数据局部性，将频繁使用的特征（即热门特征）保留在GPU内存中，从而减少额外/重复的参数移动，以提高嵌入查找性能。GPU缓存支持多种操作符（见第4节），以及动态插入和异步刷新机制（见第6节），以保持较高的缓存命中率。

参数分区（第2级）：在CPU内存中存储嵌入参数的部分副本。它们作为GPU嵌入缓存的扩展，当缓存中不存在所需的嵌入时会被查询。根据应用场景，用户可以选择独立部署或集群部署。在独立部署中，分区可以放置在优化的并行哈希映射（无服务器部署）或本地Redis实例中。分布式部署可以利用多节点Redis配置。每个分区的内容会根据部署中所有推理节点处理的查询异步调整。为了接收在线更新，参数分区可以订阅分布式事件流中的主题。

参数副本（第3级）：为了确保容错性，HPS在每个推理节点的基于磁盘的RocksDB键值存储中保留所有模型参数的完整副本（即模型副本）。如果对相应参数分区的查找请求失败，则会访问此备用存储。因此，如果给定足够的时间预算，HPS部署始终能够为每个查询提供完整的答案。为了保持最新状态，每个节点单独监控分布式事件流，并以其自己的节奏应用在线更新。

4 推理GPU嵌入缓存

在处理在线推理工作负载时，通常无法预知接下来需要哪些嵌入表子集。因此，我们的GPU嵌入缓存被设计为一个通用的动态缓存，它可以通过淘汰旧嵌入来接受新嵌入。

4.1 缓存数据模型

GPU嵌入缓存由如图4所示的三级分层结构组成：槽（slots）、板（slabs）和板集（slabsets）。

图4

• 槽（Slots）：槽是GPU嵌入缓存的基本存储单元。每个槽包含一个嵌入键、相关的嵌入向量以及一个访问计数器。
• 板（Slabs）：现代GPU架构以warp（32个线程的组；[28]）为单位管理和执行代码。通过编写warp感知的程序可以实现峰值性能。因此，我们将32个槽分组为一个板，以便每个warp线程被分配到一个独立的槽。在搜索匹配的嵌入键时，我们使用warp线性探测板。为了确定键是否在板中找到以及找到的位置，我们执行寄存器级的warp内通信（如shuffle、ballot等），以消除分支和内存分歧。
• 板集（Slabsets）：类似于N路组相联缓存中的缓存行被分组为缓存集，板被打包成板集。为了充分利用GPU的大规模并行计算能力，每个嵌入键首先被映射到一个特定的板集，但随后可以占据该板集中的任何槽。这样，线性探测被限制在单个板集内，而不会与独立的板集发生冲突。较小的板集大小可以减少键搜索延迟，但也会导致冲突未命中增加。找到最佳的板集大小以平衡这两个因素非常重要。我们根据经验将板集大小设置为2，适用于当代NVIDIA GPU架构（如Ampere）。

为了最大化GPU资源利用率和推理并发性，推理工作器可以共享同一个嵌入缓存。通过仅允许单个warp对特定缓存操作（如查询和替换）独占访问板集，可以防止竞争条件。这种方法还隐式地确保了线程安全性。由于板集的总数通常远高于每个GPU的最大warp数（数百万对数千），因此互斥不会导致显著的停顿。

4.2 GPU嵌入缓存API

GPU嵌入缓存支持四种API：

• 查询（Query，算法2）：检索嵌入键集合对应的嵌入向量。缺失的键会以列表形式返回，可用于尝试从参数分区中获取这些嵌入。
• 替换（Replace，算法3）：尝试通过先填充空槽来插入嵌入。如果空槽数量不足，则替换最近最少使用（LRU）的嵌入。已存在的嵌入将被忽略。
• 更新（Update，算法4）：首先确定输入键与已缓存键的交集，然后替换相应的嵌入向量。
• 批量导出（Dump batch）：输出当前存储在缓存中的所有嵌入键。

算法2

算法3

算法4

查询、替换和更新共享相同的核心算法（参见算法2、3和4）。对于每个键，分配的处理warp首先使用哈希函数定位包含该键的板集，然后线性探测该板集中的板，以找到匹配的键槽或确定用于插入的空槽/可替换槽（仅适用于替换和更新）。批量导出API较为简单，它只是将当前缓存中的所有键复制到CPU内存中。

所有API都启动异步执行的CUDA内核，即控制流会立即返回到CPU。由于它们在板集级别上是线程安全的（见第4.1节），因此允许并发调用所有API。为了避免频繁启动CUDA内核并提高GPU资源利用率，所有API都接受小批量输入。相应的输入键会公平地分配给warp，并推入warp工作队列中。

4.3 嵌入插入

对于查找失败的情况（即键当前不在GPU嵌入缓存中），会触发缓存插入操作，从CPU内存中的参数分区或本地SSD上的副本中获取缺失的嵌入。如算法1所示，HPS有两种插入模式，GPU嵌入缓存根据当前缓存命中率与用户定义的命中率阈值之间的关系在这两种模式之间切换：

算法1

• 异步插入：如果缓存命中率高于预定义的阈值，则激活异步插入。对于任何缺失的键，立即返回默认的嵌入向量（其值可由用户配置）。实际的嵌入会从更高级别的存储中异步获取并插入到GPU嵌入缓存中，以便在未来的查询中使用。这种惰性插入机制确保了在高命中率的情况下，预测精度损失可以忽略不计。

• 同步插入：同步插入会阻塞管道的其余部分，直到获取到缺失的嵌入。在合理的阈值设置下，同步插入通常仅在预热阶段或模型更新后发生。

5 CPU内存与SSD存储层

为了处理超出GPU内存容量的模型，除了GPU嵌入缓存（第4节）外，HPS在其存储层次结构中还包含了两层额外的存储层。这些层基于系统内存、SSD或网络存储构建，并且高度模块化，以支持各种后端实现。

易失性数据库（VDB）层（图3中的第2层）

VDB层位于易失性内存（如系统内存）中，需要通过NVLink或PCIe总线从GPU访问。与GPU内存相比，系统内存可以以更低的成本扩展。为了进一步扩展，VDB可以利用推理集群中的多个低延迟系统内存。例如，使用我们的RedisClusterBackend VDB模板实现，用户可以将分布式Redis实例用作嵌入的存储后端。因此，VDB实现可以但不限于机器边界。为了分配工作负载，VDB将嵌入表存储组织为分区。分区是嵌入表的非重叠子集，存储在同一物理位置。它们根据共享VDB访问的所有节点处理的推理查询稀疏填充。每个嵌入表的最大大小（=溢出边界）和分区数量是可配置的，并需要权衡。更多较小的分区可以实现更平滑的负载均衡，但每个分区都会增加少量的处理开销。

VDB作为异步缓存运行。如果GPU嵌入缓存报告缺失的键，HPS会接下来查询VDB。与嵌入缓存类似，每个VDB条目包含一个时间戳，指示该条目上次被访问的时间。对于成功检索到的嵌入向量，VDB在返回结果后异步更新此时间戳。缺失的嵌入向量会被调度插入到VDB中，以加速潜在的未来查询。因此，每个嵌入的分区分配是固定的，并由键的XXH64哈希值[4]确定。插入操作是异步进行的，以避免阻塞挂起的查找过程，并随后填充VDB分区。每个分区的逐出策略决定了如果分区超出其溢出边界时应采取的措施。我们实现了多种逐出策略。例如，evict oldest策略会找到并修剪不常访问的键。

持久性数据库（PDB）层（图3中的第3层）

PDB层使用硬盘或SSD永久存储整个嵌入表（即所有模型参数）。因此，PDB有助于提高具有极端长尾分布的数据集的预测精度。PDB层可以作为任意数量模型的备份和最终真实数据源。为了避免键冲突，PDB实现为每个唯一的嵌入表形成单独的键命名空间。

我们的模板实现将嵌入表映射到RocksDB数据库中的列组，存储在每个推理节点的本地SSD上。因此，整个模型数据在每个推理节点中都有副本。通过这种方式，我们实现了最大的容错能力，因为节点故障不会影响其他推理节点完全回答每个查询的能力。即使邻居节点的故障导致附加的Redis VDB宕机，仍可以继续运行。如果没有VDB作为中间缓存，当然可能需要更长的时间才能将缺失键的嵌入向量异步迁移到GPU嵌入缓存中（另见第7节）。然而，假设GPU嵌入缓存能够保持足够高的命中率，客户端应该只会看到推理性能的微小偏差。

6 在线模型更新

到目前为止，我们已经描述了HPS如何组织资源以实现预训练模型的推理。在图5中，我们用红色（→）突出显示了数据流图的这一部分。然而，在许多场景中，推荐依赖于最新信息（例如，社交网络中的用户交互）。在完成训练周期后，增量更新必须传播到所有推理节点以改进推荐。我们的HPS通过专用的在线更新机制实现了这一功能。

图5

易失性与持久性数据库更新

模型训练是资源密集型的，因此由一组与推理集群不同的节点执行。HugeCTR模型的训练集被分割为文件，以最大化嵌入缓存中的局部性。模型通过依次将这些文件加载到缓存中并处理训练片段来进行训练。我们的在线更新机制围绕HugeCTR模型训练构建。它被设计为一个辅助进程（图5中的蓝色[→]数据流图），可以在任何时间点开启或关闭。

一旦训练取得进展，训练节点会将其更新转储到基于Apache Kafka的消息缓冲区[36]。这是通过我们的Message Producer API完成的，该API负责序列化、批处理以及将更新组织到每个嵌入表的独立消息队列中。加载了受影响模型的推理节点可以使用相应的Message Source API来发现并订阅这些消息队列。如图5所示，可以为不同的VDB分区创建单独的订阅。这使得共享VDB的节点也可以在它们之间分担更新工作负载。如果某个节点无响应，其当前分配的任务会转移到其他节点。

应用在线更新不可避免地会增加开销。因此，我们允许每个节点通过后台进程以惰性方式消费更新。更新进程的执行与其他I/O请求对齐。为了控制和调整对在线推理的影响，用户可以限制更新的摄取速度和频率。通过消息缓冲区订阅，更新保证是有序且完整的。因此，在完全处理所有挂起的消息（同步）后，各个数据库级别保证是一致的（即我们保证最终一致性）。我们以惰性方式应用更新意味着在模型更新期间可能会出现轻微的不一致性。然而，在实践中这并不重要，因为模型重新训练的学习率通常非常小。只要优化过程相对平稳，预测性能不应显著下降[2, 20]。请注意，同样的假设也支撑了GPU嵌入缓存查询API的工作原理，如果满足命中率标准，它会为缺失的键返回默认的嵌入值（见第4节）。然而，由于摄取更新不需要停机，因此可以实现持续的模型改进，这使得HPS特别适合与高度活跃的数据源一起使用。

异步GPU嵌入缓存刷新

当推理请求到达时，GPU嵌入缓存需要随时可用。从消息缓冲区到GPU嵌入缓存的持续小更新流会创建难以预测的GPU负载峰值，可能会降低响应时间。因此，我们允许GPU嵌入缓存定期轮询VDB/PDB以获取更新，并在必要时替换嵌入，而不是直接从Kafka摄取更新。刷新周期可配置，以最好地适应训练计划。在使用在线训练时，GPU嵌入缓存可以配置为定期（分钟、小时等）刷新其内容。在使用离线训练时，刷新通过Triton模型管理API[9]发送的信号触发。图3展示了模型更新在GPU嵌入缓存中生效的整个流程：

1. 监控消息流：将更新分发并应用到CPU内存分区（VDB）和SSD（PDB）。
2. 批量导出GPU嵌入缓存键（大小可配置）并将其写入导出键缓冲区。
3. 从CPU内存分区和/或SSD中查找写入导出键缓冲区的嵌入键，
4. 并将相应的嵌入键-向量复制到查询键-向量缓冲区。
5. 将查询键-向量缓冲区下载到GPU设备并刷新GPU嵌入缓存。

7 效果评估

（略）

参考

• 1.https://arxiv.org/pdf/2210.08804

meta在《Software-Hardware Co-design for Fast and Scalable Training of Deep Learning Recommendation Models》提出了DLRM的工程实现。

摘要

深度学习推荐模型（DLRMs）在Meta的许多关键业务服务中得到应用，并且是其数据中心基础设施需求方面最大的AI应用。在本文中，我们介绍了Neo，这是一个软硬件共同设计的系统，用于大规模DLRMs的高性能分布式训练。Neo采用了一种新颖的4D并行策略，结合了表格级（table-wise）、行级（row-wise）、列级（col-wise）和数据并行策略，用于训练DLRMs中的大规模embedding操作（embedding operators）。此外，Neo通过包括混合内核融合、软件管理缓存和质量保持压缩在内的多种关键系统优化，实现了极高的性能和内存效率的embedding计算。最后，Neo与ZionEX配对，ZionEX是一个新的硬件平台，与Neo的4D并行策略共同设计，用于优化大规模DLRM训练的通信。我们在128个GPU上使用16个ZionEX节点的评估表明，Neo在训练已部署生产的12万亿参数DLRM模型方面，性能超过了现有系统高达40倍。

1 引言

深度学习推荐模型（DLRMs）被在线公司广泛使用，包括亚马逊用于其目录中选择商品[35, 37, 58]，Netflix用于展示电影选项[13, 29]，以及谷歌用于显示个性化广告[7, 9, 19]。它们还被标准基准测试组织采用，如MLCommons (MLPerf) [38, 52]。在Meta，我们已经在排序和点击通过率（CTR）预测中广泛使用推荐模型，包括新闻推送和搜索服务[15, 17, 42, 47]。DLRMs是数据中心基础设施需求方面最大的AI应用。

与传统的深度神经网络（DNNs）不同，DLRMs主要包含计算密集型操作（例如，卷积和矩阵乘法），DLRMs结合了计算密集型组件和多达数千个数据密集型嵌入操作符，每个操作符都有不同的资源需求和性能特性[43]。因此，与计算机视觉[8, 18, 59]、自然语言处理[5, 10, 61]和强化学习的同类模型相比，DLRMs通常表现出更低的算术强度和更大的模型大小，实际部署的模型拥有数万亿参数，如图1所示。

图1 在总计算量上比较深度学习模型，以拍拉浮点运算/天(petaflop/s-days)为单位（上部）[45]和模型容量（下部）

现有的针对DNN的软件和硬件解决方案在DLRMs上只能实现次优性能和有限的可扩展性，这是由于以下软件/硬件限制造成的。

在软件方面，现有的深度学习框架通常使用数据、模型或流水线并行化来并行化DNN训练[3, 32, 48]。支持这些策略组合的框架通常为特定的DNN应用而设计[16, 22, 41, 50]。然而，为计算密集型DNN模型设计和优化的现有并行化策略在DLRMs上实现有限的性能和可扩展性。特别是:

• 数据并行化要求每个设备保存整个模型的副本，因此不支持拥有数万亿参数的DLRMs[32]。
• 此外，由于其嵌入操作符的数据依赖行为，DLRM不能直接使用模型并行化或流水线并行化。具体来说，处理不同的训练样本可能需要根据每个样本的分类输入访问不同的嵌入参数。这种数据依赖行为使得在满足所有样本的数据依赖性的同时，静态地将DLRM的可训练参数划分为不相交的子集变得不可行，这是使用模型和流水线并行化的必要条件。

此外，当今的DNN框架旨在优化计算密集型（compute-intensive) DNN计算，忽视了对数据密集型（data-intensive）嵌入操作符的关键优化。具体来说，DLRM包含多达数千个嵌入操作符。这些嵌入操作符的前向处理、反向传播和梯度同步需要在训练迭代中启动数千个CUDA内核，并消耗高达数TB的累积GPU设备内存，引入了显著的运行时开销和内存需求。

在硬件方面，现代硬件平台，如基于GPU的集群，提供了显著的能力提升，但它们并不是为了匹配DLRMs的性能特性而设计的。具体来说，DNN训练的硬件平台通常针对集中式节点间通信（例如，参数服务器[3]）和/或AllReduce通信（例如，Horovod[54]和NCCL[1]）进行优化。然而，如第3节所确定的，高性能和可扩展的DLRM训练需要有效硬件支持多种不同的通信模式，包括AllReduce、AlltoAll、ReduceScatter、OneToMany和ManyToOne。

1.1 我们的方法

我们提出了Neo，这是一个软硬件共同设计的系统，用于快速且可扩展的DLRM训练，它基于三个关键技术构建。

4D并行

为了在DLRM中快速且可扩展地训练大规模嵌入操作符，有效地平衡GPU之间的工作负载分配并最小化通信成本至关重要。我们引入了一种4D并行策略，结合了表格级、行级、列级和数据并行策略，共同优化嵌入操作符的并行性能。此外，Neo还支持在不同级别的硬件层次结构中以递归方式应用4D并行，以进一步提高负载平衡和硬件效率。

高性能嵌入计算

Neo采用了两项新的优化技术，以最小化嵌入操作符的计算成本和内存需求。

• 首先，我们引入了一种混合内核融合技术：将（1）多个嵌入操作符和（2）嵌入计算及其参数更新全部融合在一个CUDA内核中。这是通过共同设计嵌入操作符的优化算法和软件实现来实现的。
• 其次，为了提供足够的内存容量以支持DLRM训练，Neo使用软件管理的缓存机制来利用现代硬件平台的内存层次结构。
• 最后，进一步应用了多种压缩技术[29, 63]来最小化内存需求。

硬件平台设计

我们介绍了ZionEX，这是一个与Neo的4D并行共同设计的新型硬件平台，用于优化分布式DLRM训练的节点间通信。ZionEX通过使用专用的基于融合以太网的RDMA（RoCE）扩展网络，支持集群中所有GPU的全连接拓扑。这种拓扑设计促进了分布式DLRM训练中性能主导的通信工作负载（例如，AlltoAll和ManyToOne）的高性能数据传输。同时，ZionEX支持RDMA和GPUDirect通信协议，并保留了灵活的节点内GPU织物。这使得在ZionEX上能够进行高性能的DLRM训练，同时确保与现有数据中心基础设施的兼容性，允许ZionEX的广泛部署。

结果

我们已经在三个生产环境中部署的不同任务的DLRM上评估了Neo，包括点击通过率预测、排序和参与度，代表了多样化的生产级推荐模型。我们在16个ZionEX节点上的128个A100 GPU上的评估表明，Neo能够处理高达每秒170万次查询，用于训练具有12万亿参数的DLRM，与现有生产中的DLRM训练解决方案相比，速度提升了40倍。消融研究表明，4D并行、高性能嵌入计算和新的ZionEX平台对于实现快速且可扩展的DLRM训练至关重要。

总结来说，我们的贡献是：

• 我们提出了Neo，一个软硬件共同设计的系统，用于快速且可扩展的DLRM训练。Neo在训练具有12万亿参数的大规模DLRM方面，性能超过了现有系统高达40倍。
• 我们提出了4D并行，这是一种结合了表格级、行级、列级和数据并行策略的训练嵌入操作符的方法。
• 我们开发并实现了使用混合内核融合、软件管理缓存和质量保持压缩的高性能嵌入操作符。
• 我们构建了ZionEX，一个与Neo的4D并行共同设计的新型硬件平台，以加速DLRM训练中的多种通信模式。

2 背景

DLRMs通常有两种训练模式——离线和在线，每种模式都有不同的要求。离线训练可以被视为预训练，其中候选模型在足够大的历史数据上进行训练，并期望在部署到当前/未见过的样本时能够泛化。一旦部署，DLRMs继续使用它已经服务过的数据进行在线训练。离线训练受到吞吐量限制，符合更传统的“尽可能快地训练尽可能多的数据”的范式，而在线训练对延迟更敏感，重新训练和更新的频率是一个重要因素。对于在线训练，吞吐量要求较低，因此可能希望使用相对较少的资源。这创造了一个独特的需求，即在能够容忍较低吞吐量的较小规模上训练非常大的模型。

本文专注于对训练吞吐量需求更高的离线训练——每秒处理多达数百万样本（查询），这些样本来自于在合理时间内处理数十PB训练数据。这推动了训练平台的需求，如表1所总结。

嵌入操作符

DLRMs与传统深度神经网络之间的一个主要区别是利用类别型特征（如用户、帖子或页面）。生产中使用的DLRMs通常包含多达数千个类别型特征，每个特征对应一个专用的嵌入操作符。嵌入操作符以一个multi-hot向量作为输入，向量中的每个非零元素触发嵌入表中的完整行检索，其中输入向量的每个索引对应表中的一行。最后，对于给定的输入向量，所有嵌入行通过element-wise pooling组合，如图2所示。

图2 一个embedding operator的Workflow

并行化策略

传统上，用于生产环境中训练DLRMs的是基于参数服务器（PS）的分布式CPU训练系统。具体来说：

• 一方面，MLP模块中的dense参数在训练器之间复制以利用数据并行性。它们的权重使用集中式dense参数服务器通过弹性平均方法SGD进行同步。
• 另一方面，embedding table中的参数被分割并放置在多个PS上以利用模型并行性，因为embedding参数的大小简单地阻止了模型复制。

为了最大化训练吞吐量，使用Hogwild!更新嵌入操作符的参数。此外，读者部署在单独的机器层上，为训练器提供训练批次，如图3所示：

图3 基于分离式参数服务器（Disaggregated parameter-server）的系统

这种基于PS的系统非常适合DLRMs，允许分别扩展不同的组件，并在训练具有不同训练器、参数服务器和读者配置的不同模型时实现平衡的资源利用。此外，系统中的资源在很大程度上是可替代的，这使得数据中心运营成本较低。

然而，需要支持具有数万亿参数的DLRMs，因此大小达到数TB，这对这种方法的可扩展性提出了严重挑战，需要大量增加训练器和参数服务器的数量以满足不断增长的训练需求。这很快变得不可行，由于在大量worker之间增加的异步更新，导致模型准确性因陈旧性而降低。为了解决这些问题，我们构建了一个用于大型DLRMs的高性能同步训练解决方案，将分布式扩展与统计质量解耦。

同步训练系统的高效设计，使我们使用一种新颖的4D并行组合（第4节）用于内存密集型嵌入表，数据并行性用于计算密集型DNN操作符，并在不同组件之间进行流水线处理。这种混合并行性需要AlltoAll通信来处理嵌入查找结果，以及如果输入是从数据库批量流式的，还需要重新分配嵌入表输入，这通常是情况。与用于梯度同步的AllReduce通信不同，AlltoAll通信由于数据依赖性而位于关键路径上，强调了互连和通信原语的性能。此外，DLRMs通常在非常大的数据量上进行训练，这些数据对应于来自各种应用的大多数非结构化和未标记的交互。典型的数据集大小在几个PB的范围内，需要使用常见的分布式网络存储，如Tectonic文件系统。对于训练，这些数据需要被流式传输进来，给主机网络和主机到设备带宽带来额外的压力。

3 概览

图4展示了Neo的概览，这是一个软硬件共同设计的系统，用于快速且可扩展的DLRM训练。本节简要描述了Neo的关键组件。

图4 Neo 概览。图中的每个框表示一个神经网络组件，而框之间的边表示不同组件之间共享的张量。

首先，Neo使用数据并行性来训练计算密集型的DNN层（以橙色显示），并切换到一个4D并行策略，该策略结合了表格级、行级、列级和数据并行性，以高效训练内存密集型的嵌入操作符。

其次，Neo配备了高性能的嵌入操作符实现。这是通过一系列关键的系统优化实现的，包括:

• （1）混合内核融合技术来减少嵌入操作符的计算成本，
• （2）软件管理的缓存机制来利用现代硬件平台的异构内存
• （3）多种质量保持压缩技术来最小化嵌入计算的内存需求

最后，Neo部署在ZionEX上，这是一个与Neo的4D并行共同设计的新型硬件平台，用于优化DLRM训练的节点间通信。

此外，数据I/O是任何训练系统的重要组成部分，特别是随着完全同步训练和加速器的采用。首先，主机到设备的数据传输应该是非阻塞的，并且足够快，不会限制整体训练吞吐量。理想情况下，使用双缓冲或流水线将输入数据传输与训练重叠。其次，尽管将输入数据分布映射到训练器之间的集体通信更快，但这为集体通信的输入和输出数据布局引入了额外的挑战。初步实验表明，这些可能会给关键路径增加显著的延迟。我们将在第7.1节中展示我们如何克服这些实际挑战。

4 4D并行策略

DLRM的一个关键组成部分是嵌入操作符，将在第5节中定义。为了实现嵌入操作符的高性能训练，有效地平衡GPU之间的工作负载分布并最小化通信成本至关重要。我们引入了4D并行策略，它结合了表格级、行级、列级和数据并行策略，共同优化嵌入操作符的并行性能。

图5 具有不同通信成本、负载均衡和内存需求影响的嵌入表分片方案。为了简化说明，此图中省略了底部的MLP（多层感知机）。

表格级并行策略。

最直接的并行方案是：跨GPU分割和并行化多个嵌入表，如图5a所示。表格级并行策略不会进一步分割嵌入表，因此此方案不需要额外处理嵌入表输入索引或聚合的嵌入结果，从而实现最佳的通信效率。然而，表格级并行策略无法处理超过单个GPU内存容量的大型嵌入表，且由于表大小的偏斜，实现的负载平衡通常有限。

行级并行策略。

此方案通过行来并行化大型嵌入表，并将不同的表片段分配给不同的训练器。由于嵌入表输入通过行来索引表，它们需要根据行级并行决策进行分桶并分发到相应的训练器，如图5b所示。此外，多个训练器上的部分结果需要被缩减然后分散到所有训练器以进行下游计算。这要求在前向传递中使用ReduceScatter通信模式。此方案能够很好地处理大型表，并带来更好的负载平衡。然而，通信成本与训练器的数量成线性关系。

列级并行策略。

列级并行策略沿嵌入维度划分嵌入表（见图5c），并将划分后的表视为具有较小嵌入维度的独立操作符。此方案需要为划分后的表复制输入索引。与表格级并行策略相比，它保持了相同的流程和通信模式（AlltoAll）。列级并行策略的一个关键优势是能够实现更细粒度的并行策略，特别是对于大型表。然而，它仅在大型嵌入维度下表现良好，并增加了输入索引的负载，这些索引必须复制到所有节点的列片段。此外，由于列级划分的表的行分布在不同的训练器上，使用这些表的独立行更新引入了额外的参数，每个行片段一个参数，而不是使用稀疏优化器时整个行只有一个单一值（见第5.1节了解更多细节）。

数据并行策略。

DLRM往往有广泛的表大小范围，而表格级、行级和列级并行策略适用于相对较大且无法复制的嵌入表。对于较小的表，数据并行策略能够实现更好的性能，因为数据并行策略在前向传递中不涉及任何通信（见图5d）。因此，对于小型嵌入表，Neo将embedding表视为dense参数并在所有训练器上复制它们。对于数据并行嵌入表的聚合嵌入，不再需要AlltoAll。相反，需要AllReduce来同步所有副本。因此，这取决于聚合嵌入的AlltoAll成本与整个表的AllReduce成本之间的权衡。通常，行数较少的小型嵌入表是数据并行策略的良好候选者。这些表的输入索引作为数据并行输入传递，不再需要重新分配。

4.1 并行化算法

Neo支持在单个嵌入操作符的粒度上应用4D并行策略，以最大化灵活性。实践者可以混合使用上述原语，以确定划分嵌入操作符的最佳策略。此外，Neo还支持在不同级别的硬件层次结构中以递归方式划分嵌入操作符，以进一步提高工作负载平衡和硬件效率。例如，表格级然后行级方案首先将一组表分配给特定节点，然后在该节点内按行划分表。这种层次并行方案通过充分利用快速的GPU互连并减少节点间通信，提高了硬件局部性。

为上述每种并行方案定义了成本函数，可以探索放置算法以最小化worker之间的成本差异。成本函数是通信开销和训练器之间的负载不平衡的组合。通信开销使用消息量作为代表性指标计算，消息量越大对应成本越高。这在很大程度上准确地捕捉了吞吐量成本，对于延迟测量值，作为固定附加成本纳入。我们通过使用每个训练器的嵌入访问大小来估计负载不平衡，这可以近似为每个训练器的嵌入表数量×全局批量大小×每个样本的平均索引数×嵌入维度。这两种成本的组合为我们提供了通信和负载不平衡的合理估计。进一步，我们为每个单独的成本引入了标量权重，可以根据不同的系统规格进行调整，以获得更准确的估计。

我们实现并评估了两种多项式时间启发式算法作为概念验证。第一个是一个简单的贪婪启发式算法，它将可用方案的成本按降序排序，并首先分配最大的片段，每个worker一个。然后，贪婪算法遍历所有剩余的片段，并将最高成本分配给成本总和最小的节点。第二个启发式是最大差分方法（也称为Karmarker-Karp算法[26]）。主要思想是从输入中取出两个最大的数字，并用它们的差替换它们。它直接减少了总和的差异，通常优于贪婪启发式。

4.2 流水线

尽管使用GPU作为主要计算资源在模型评估内提供了有限的流水线机会，我们通过流水线化批间数据移动并与计算重叠通信来提高GPU利用率。

当批次𝑖正在被评估时，相同的GPU可以开始使用单独的流接收和分发批次𝑖 + 1。为了最小化干扰，我们将批次𝑖 + 1的输入AlltoAll与批次𝑖的顶部MLP的前向传播重叠，其中不涉及通信。此外，我们将聚合的嵌入AlltoAll与底部MLP的前向传播重叠，以隐藏延迟。

5 嵌入优化

优化DLRM的嵌入操作符（见第2节）的运行时性能需要解决两个关键挑战。

• 首先，嵌入操作符的前向处理、反向传播和梯度更新需要在每次训练迭代中启动数千个GPU内核，引入了显著的GPU内核启动开销。
• 其次，一些嵌入操作符可能包含高达数十亿的参数，无法适应单个GPU的设备内存。

我们引入了三种新技术来减少嵌入操作符的计算成本和内存需求。

• 首先，我们引入了一种混合内核融合技术，以最小化CUDA内核启动开销，并允许每个GPU工作器只启动两个内核（即一个用于前向传播，一个用于反向传播和参数更新）。
• 其次，对于嵌入操作符的并行计算，我们提出了列级并行策略和行级并行策略，除了数据和模型并行策略之外。这四个并行维度的组合使Neo能够支持高达数万亿参数的嵌入表。
• 最后，Neo利用一系列内存节省技术，利用ZionEX平台的内存层次结构，确保DLRM有足够的内存容量。

5.1 内核融合

Neo使用混合内核融合机制来最小化执行嵌入计算的CUDA内核启动开销。

• 首先，与为每个嵌入表应用单独的嵌入查找不同，Neo将同一GPU上的多个嵌入查找融合到单个CUDA内核中（图6a），这提高了并行性和带宽利用率，并减少了在GPU上启动多个CUDA内核的开销。
• 其次，Neo还将反向传播与稀疏优化器融合，以进一步减少内核启动开销，并避免将梯度具体化到嵌入表中。这种融合的关键挑战是避免来自不同训练样本的梯度更新之间的潜在竞态条件，以及处理诸如AdaGrad[11]、LAMB[66]和Adam[27]等高级优化器中的非线性。例如，图2中的样本1和2都有助于嵌入向量1和6的梯度。如果不聚合直接将这些梯度发送到非线性稀疏优化器，将导致嵌入表的错误更新。为了保证正确性的同时最大化性能，Neo通过行对梯度进行排序，以便对同一嵌入行的梯度由单个CUDA线程块处理，如图6b所示。
• 随后在每个CUDA线程块内使用更快但更小的GPU共享内存进行梯度聚合。

图6

Neo的嵌入操作符混合融合技术带来了三个性能优势。

• 首先，Neo通过避免为嵌入梯度分配GPU设备内存来减少嵌入操作符的内存需求。
• 其次，通过使用GPU共享内存来保存中间嵌入梯度，最小化了对GPU设备内存的内存访问。
• 最后，内核融合通过高达7倍的性能提升，改善了嵌入计算的整体性能，与原生实现相比。

优化的嵌入操作符实现作为FBGEMM库∗的一部分开源，并与PyTorch集成。

5.2 管理内存层次结构

对于具有高达数万亿参数的DLRM，嵌入表太大，无法完全适应单个GPU。我们利用ZionEX平台的多个内存层次结构，包括HBM、DRAM和SSDs，以及扩展到多个节点以增加聚合容量，确保模型有足够的内存，更快的内存作为后续层的软件缓存。Neo的层次内存管理策略特别适用于DLRM的在线训练，由于吞吐量要求较低，因此可以使用较少的节点来训练原始的大型模型，如第2节所述。

管理内存层次结构的一种方法是CUDA的统一内存（UVM）[44]，它为不同类型的内存提供单一的内存地址空间，并自动替换和逐出未使用的页面。然而，嵌入操作符中的随机表查找需要在单个嵌入行的粒度上缓存和替换未使用的参数，这使得直接使用UVM对于DLRM来说是不够的。需要额外处理查找以确保性能不受频繁的主机到设备传输的限制。相反，Neo使用定制的32路集合关联软件缓存[64]，使用最近最少使用（LRU）或最少频繁使用（LFU）缓存替换策略，其中关联性与GPU的warp大小相匹配。这使得可以对缓存和替换进行细粒度控制，允许针对目标模型特性进行调整。请注意，UVM受PCIe带宽限制，而Neo的软件缓存可以弥补PCIe和HBM之间的带宽差距（50倍差异）。与UVM相比，软件缓存将DLRM工作负载的端到端性能提高了约15%。

为了进一步减少嵌入操作符的内存需求，Neo还采用了先前工作中引入的多种压缩技术，如逐行稀疏优化器[14, 62]、使用高精度缓存支持的低/混合精度训练[63]和高级分解技术[29]。

逐行稀疏AdaGrad首次在[14]中引入，然后在[62]中进一步阐述。在逐行稀疏AdaGrad中，每个元素的时刻估计应用于整个嵌入行。对于每一行，它是一个单一的缩放因子，通过添加行中梯度的平均平方和来更新。通过这种方式，我们将动量保持为一个1D张量，有H个元素，而不是H×D的2D张量，其中H和D分别是嵌入表中的行数和每行的元素数。

6 ZIONEX: 硬件平台设计

我们首先在第6.1节描述了我们之前用于DLRM的硬件平台的局限性。第6.2节介绍了ZionEX，一个为DLRM设计的新型硬件平台。我们还概述了在ZionEX开发中使用的设计原则。

6.1 之前的平台：Zion

2019年推出的Zion是我们之前针对DLRM训练的高性能硬件平台的工作。尽管Zion在单节点级别提供了显著改进的能力，但作为一个分布式平台，它未能扩展以满足迅速增长的DLRM训练需求。我们批判性地评估了它的局限性，但其他基于类似设计的平台也存在相同的局限性；我们在第9节讨论了这些平台。

图7a显示了一个Zion节点的架构，它有8个CPU插槽，1.5TB内存，8个GPU和8个网络接口卡（NIC）。它通过（1）将DLRM的计算密集层（例如，MLP）卸载到GPU上，以及（2）利用CPU处理大型嵌入操作符在相对便宜的DRAM上，而不是HBM，以在单个节点上容纳TB级DLRM，提供了强大的异构超级节点设计。

图7

然而，这种异构设计引入了许多软件设计和性能挑战。例如，平衡CPU和GPU上的工作负载以确保最大重叠至关重要。这需要在CPU和GPU之间进行精细的流水线处理，并使用精确的成本模型将DLRM划分为细粒度任务。此外，DLRM的异构训练还引入了非平凡的运行时开销，例如增加了CPU和GPU之间的数据传输和节点间通信。最后，Zion的一个关键缺失组件是每个NIC直接连接到一个CPU。因此，所有节点间通信（例如，梯度同步和张量转换）都需要CPU干预和额外的GPU-CPU传输。此外，这些NIC连接到常见的数据中心网络基础设施，引入了网络拥塞的开销和干扰，并且受限于使用更数据中心友好的拓扑结构和协议（TCP/IP），这对于分布式训练是次优的。尽管每个Zion节点都配备了8个100Gbps NIC带宽，但实际上我们发现由于网络开销，很难扩展到多个节点。随着DLRM模型大小需求的增加，Zion无法很好地扩展并充分利用强大的硬件资源。

6.2 ZionEX

为了解决这些不足，我们引入了ZionEX，我们已经设计它比之前的Zion平台更具可扩展性，并提高了网络能力，同时保留了其灵活性和核心优势，例如OAM外形因素、模块化设计和灵活的节点内加速器结构。通过所有这些改进，ZionEX在支持增加模型复杂性和提高训练性能方面带来了数个数量级更高的能力。这最好通过比较每个平台支持的最大模型复杂性（以FLOPS/样本计）和实现的训练吞吐量来说明，这可以被视为标准化的有效性能。对于ZionEX，实现了1.2 MQPS的吞吐量，模型复杂性为638 MFLOPS/样本（见表3），这转化为766 TFLOPS/s的有效性能，还有额外的余地上升到数PETAFLOPS/s。而Zion在ZionEX上支持的最大模型复杂性不到一半（约250 MFLOPS/样本），吞吐量更低（约0.25 MQPS），因此最大可实现的有效性能降低了10倍以上，仅为63 TFLOPS/s。图7b显示了整体系统架构。我们简要强调了ZionEX的核心技术原则：

可扩展性。Zion和ZionEX都支持DLRM的异构训练，但最显著的区别是ZionEX设计了足够的扩展和扩展网络能力。如图7b所示，ZionEX为每个通过PCIe交换机连接的GPU配备了专用的RDMA over Converged Ethernet (RoCE) NIC，以允许专用的节点间连接（与常见数据中心网络隔离），并重要地支持更高效的RDMA/GPUDirect通信协议。这些ZionEX节点可以通过专用后端网络连接，形成一个分布式可扩展训练的集群。ZionEX的可扩展设计允许扩展后端网络，连接数千个节点，形成一个数据中心规模的AI训练集群。

高性能。作为一个扩展解决方案，我们将整个DLRM卸载到GPU上，充分利用大规模并行性和高内存带宽来加速MLP和嵌入计算。为了传输张量和同步梯度，每个GPU都可以直接通过专用的低延迟高带宽RoCE NIC与不同节点上的GPU通信，不涉及主机CPU。此外，ZionEX还有一个前端NIC连接到每个CPU。数据摄取通过常规前端网络和PCIe进行，不干扰激活或梯度。主机CPU仅用于设置输入批次和组织训练过程。

能力。通过ZionEX，我们确保平台与现有基础设施兼容，并可以在我们的数据中心内广泛部署，不会造成重大中断。这对于能够有效利用平台的能力并使其随时可用于各种应用和用例至关重要。我们通过使ZionEX平台符合标准的Open Rack规范来实现这一点，这涵盖了与其他基础设施组件的兼容性，如电源、冷却、机械和布线。此外，设计平台为模块化，并依赖基于开放标准技术，例如基于以太网的网络结构，用于高性能扩展解决方案。

图7c显示了整体训练平台，以及分离的数据摄取服务。这支持从网络存储（如Tectonic）流式传输输入数据，并以分布式方式执行轻量级数据预处理操作。以便数据摄取不是端到端训练的瓶颈，并确保在向ZionEX训练器提供数据时有足够的吞吐量。

7 实现

我们详细描述了上述用于DLRM的高性能可扩展训练的实现。我们使用PyTorch [48]构建了一个高性能训练软件栈，通过ATen库为大多数深度学习操作提供高效的CUDA实现，并通过PyTorch DistributedDataParallel库自动处理参数复制和梯度同步，以及通过重叠反向传播和AllReduce实现。我们已经启用了以下组件以实现高效的DLRM训练。

7.1 数据摄取

数据摄取是确保端到端训练性能的关键组件，特别是对于DLRM，它们通常处理的数据量比其他典型的DNN模型大得多。我们观察到，如果未经优化，数据摄取可能会引入显著的延迟，并为流水线带来非平凡的开销。

最初为分布式异步CPU设置设计的我们的读取器和数据预处理模块将每个稀疏特征的偏移量和索引存储在单独的张量中，每个嵌入表一个。因此，具有数百个嵌入表的DLRM可以轻松地在每次迭代中获得数千个输入张量，这转化为从CPU ↔ GPU传输的重大开销，并且是之前Zion平台的主要瓶颈之一，如第2节所述。

为了克服这一实际挑战，我们共同设计了数据预处理模块，使用组合格式，其中使用长度而不是偏移量，并将不同嵌入表的输入简单地连接起来。使用组合格式的好处是两方面的：（1）它通过合并小传输来优化CPU-GPU传输；（2）它可以直接被嵌入内核消耗，无需额外的布局转换。我们进一步通过使用固定内存来优化输入数据传输，以避免额外的复制。

有了组合格式，我们开发了一个模块，根据分片策略高效地分发嵌入表输入。在表格级分片（如图5a所示）的情况下，需要一个AlltoAll来将全局批次分发给每个工作器的本地表。由于索引的大小取决于长度的值，通信实际上是先进行长度的AlltoAll，然后进行索引的AlltoAll。在有𝑊个工作器，𝑇个本地表和𝐵个本地批次大小的设置中，这给我们提供了（𝑊，𝑇，𝐵）顺序的索引，需要进一步排列为（𝑇，𝑊，𝐵）以供嵌入内核消耗。我们已经开发了自定义的GPU内核，用于排列、分桶和复制，以实现表格级、行级和列级分片方案的最大吞吐量。模型检查点也面临类似的挑战，需要足够频繁地能够写出更大的模型，同时不成为训练的开销，如这篇最近的论文[12]所概述的。

7.2 通信原语

高性能的集体通信是DLRM训练表现良好和可扩展性的关键。PyTorch提供了进程组（PG）接口，用于集体操作——一个抽象的平台/集体库不敏感的API。DLRM直接（对于Alltoall）或间接（通过DDP对于Allreduce）使用这个API[32]。我们使用NVIDIA的集体通信库（NCCL）作为我们的主要集体通信库，因为它有效地使用RDMA和NVLINK以获得最佳性能。我们将PyTorch NCCL进程组实现扩展到支持使用NCCL Send/Recv原语的Alltoall/Alltoallv集体操作（需要NCCL 2.7.3或更高版本）。

8 评估

我们提供了生产模型端到端训练的结果，以及操作级别的性能分解。

8.1 实验设置

表2总结了配备8个NVIDIA A100 GPUs的单个ZionEX节点的聚合能力。节点中的8个GPU提供了总共320GB的HBM，聚合内存带宽为12.4TB/s。4个插槽的CPU提供了1.5TB的内存和320GB/s的带宽。在网络能力方面，GPU通过高带宽NVLink进行节点内GPU通信，每个GPU都有一个专用的200Gbps RoCE NIC用于节点间通信。我们在实验中使用了16个ZionEX节点的集群，总HBM容量为5TB。

8.2 端到端训练

我们报告了三个在生产中部署的DLRM的结果，这些DLRM用于不同的任务，包括点击通过率（CTR）预测、排序和参与度。表3列出了这些候选模型的高级特性。模型A代表了大型和复杂的DLRM，它们强调了Neo的计算能力和通信带宽，每个样本使用显著更高的FLOPS和大量的嵌入。模型F提出了一个不同的实际挑战，尽管每个样本的FLOPS很低，嵌入表的数量很少，但它有一个巨大的单一表，无法适应单个GPU的设备内存。最后，模型I代表了中等规模的DLRM，它们通过高平均嵌入池大小强调内存带宽。这些目标模型在集群中最多在16个ZionEX节点（128个GPU）上进行训练。模型质量以归一化熵[20]评估，训练吞吐量以每秒查询数（QPS）衡量。

图8

首先，我们使用模型A来演示训练质量，因为它也可以在分布式CPU平台上训练。如图8所示，尽管使用了更大的批量大小（64K vs. ~150），在ZionEX上同步大批量训练提供了相当或更好的模型质量（两者都使用调整过的超参数）。在相同的配置下，Neo在16个节点上的128个GPU上实现了1.2 MQPS，与我们之前的一代分布式CPU异步训练平台相比，速度提升了40倍，后者使用了45个参数服务器和15个训练器。以前的解决方案在不损害训练质量的情况下无法进一步扩展，而在ZionEX上完全同步训练允许在16个节点之外进行扩展，甚至可以使用更大的批量大小。

8.3 扩展性能

图9显示了在保持每个GPU批量大小不变的情况下，使用多达16个节点的模型A和模型I的归一化训练吞吐量。虽然数据并行训练的工作负载随着扩展保持不变，但由于模型并行策略，每个GPU的嵌入表数量随着扩展而减少。出于同样的原因，每个GPU为其本地表处理整个全局小批量，这与扩展成比例增加，并补偿了减少的表，使得这仍然是一个弱扩展实验。要在较小的节点数量上运行，我们减少了嵌入表的基数，并散列输入以适应减少的行数。这个缩小版本的模型有效地减少了模型大小，对性能特性的影响最小/没有影响，因此用于研究扩展性能。

图9

从图中可以看到，在较大的节点数量上，模型A的扩展效率约为50%，模型I约为75%。尽管模型A和模型I在考虑目标本地批量大小时在有效FLOPS和内存需求方面非常接近，但模型A有更大的完全暴露的AlltoAll延迟。这是因为更多的嵌入表增加了AlltoAll负载，并且混合维度使得同时平衡嵌入计算和AlltoAll通信更加困难。因此，模型A在扩展时受到AlltoAll效率降低的影响更大。

为了更好地理解扩展性能，我们在图10中提供了模型A的序列化和暴露训练迭代延迟的分解。比较序列化和暴露延迟，CPU到GPU传输（即HtoD）完全隐藏，暴露的通信延迟远小于序列化AlltoAll和AllReduce延迟的总和。这证明了Neo的流水线优化有效性，可以重叠通信与计算（见第4.2节）。

图10

随着节点数量的增加，我们观察到AlltoAll和AllReduce延迟增加。由于大多数AlltoAll通信在关键路径上，增加的AlltoAll成本直接影响暴露的通信和整体训练延迟。虽然AllReduce在多达16个节点上大部分被隐藏，但增加的AllReduce延迟和不变的计算延迟表明，一旦后向传递中的松弛完全被更高节点数量和/或更快的计算用完，AllReduce可能成为瓶颈。

8.4 训练吞吐量优化

以模型A作为案例研究，我们详细说明了各种优化及其在实现高达1.5 MQPS（如图11所示）中的贡献。此外，我们使用附录B中描述的性能屋顶线建模方法来建立可实现性能的上限，并确认报告的吞吐量在理论估计的15%以内。模型A在128个GPU上的基线性能低于700 KQPS。进一步的分析揭示了不同GPU之间嵌入查找延迟的巨大差异，表明存在严重的负载不平衡。通过结合表格级、列级和数据并行策略来处理约1000个嵌入表的≈1000s，将它们分配到128个GPU上，从而缓解了这个问题。请注意，尽管列级并行策略引入了额外的输入AlltoAll成本，但更好的负载平衡的好处超过了开销，总体QPS提高了20%。然而，扩展效率仍比理想的线性扩展低约30%。

图11

如前所述，限制扩展效率的两个主要问题是：（1）负载不平衡和（2）增加的AlltoAll延迟。对于模型A，仅使用HBM进一步平衡负载特别具有挑战性，因为模型大小在TF32下接近128个GPU上的5TB聚合HBM容量。在扣除PyTorch框架和NCCL在每个等级上保留的内存后，Neo几乎没有空间探索放置策略。为了缓解这个问题，我们使用较低精度（FP16）的嵌入表，将模型大小减少了2倍。虽然这本身并不直接提供吞吐量好处，但Neo可以利用这个空间更好地平衡。结果，由于改善的负载平衡，训练吞吐量又增加了20%。

接下来，为了解决增加的AlltoAll延迟问题，我们采用了[65]中提出的量化集体通信，这直接减少了通信量。对于模型A，我们验证了在前向AlltoAll中使用FP16和在后向AlltoAll中使用BF16几乎提供了30%的速度提升，而没有训练质量损失。最后，我们将全局批量大小从64K增加到256K。这直接增加了激活大小，有助于更好地饱和GPU和通信带宽，同时与其他所有优化相辅相成。在适当调整优化器/超参数后，我们能够实现与训练质量相当的训练，但需要更全面的实验，因为DLRM的大批量训练研究得不够充分，将成为未来工作的一部分。总的来说，这些技术相比使用64K全局批量大小的TF32训练，训练吞吐量提高了87%。

8.5 模型容量限制研究

我们以模型F为例，在原型系统上推动模型容量。与模型A或模型I不同，有效训练模型F提出了2个不同的挑战。首先，模型F有12T参数，使用简单的训练方法，模型F很容易需要高达96TB的内存，远远超过了16个节点集群上的总内存。其次，模型只有几个巨大的嵌入表，每个表有约100B行和256列，每个表需要多节点的GPU和主机内存来训练。

为了将模型适配到16个节点上，我们首先应用逐行稀疏AdaGrad优化器到嵌入表，这将优化器状态从每个元素减少到每个嵌入行。然后我们在嵌入表上使用FP16精度[67]。这两个优化共同将模型内存占用从96TB降低到24TB，刚好适合4TB HBM + 24TB DRAM内存层次结构。在巨大的嵌入表上，我们启用逐行分片将表分布到多个节点，并调整训练流程使用AlltoAll与桶化和ReduceScatter，如图5b所示。在启用UVM并使用HBM作为缓存的情况下，我们能够以高达1.7 MQPS的吞吐量训练模型F，展示了我们HW/SW共同设计解决方案推动超越当前最先进技术的能力。

9 相关工作

研究人员提出了各种系统级创新来应对极大模型带来的挑战。

• DeepSpeed [50]在所有节点上完全分割模型参数、梯度和优化器状态，并使用检查点分区和重新物化[21, 28]来动态重建必要的状态，从而大幅减少内存使用。
• GShard [31]通过在张量级别标注并行策略，训练一个巨大的翻译模型，该模型跨加速器进行分割。
• FlexFlow [22]使用自动搜索来发现图中最佳的操作符并行策略。在自动并行化这一方向上，这些最近的论文[39, 60]使用最优合成和强化学习来找到优化的设备放置，以进一步提高并行性，无需手动干预。

然而，上述这些通用系统并非专门为高度稀疏的推荐模型设计。为此：

• 阿里巴巴引入了XDL [23]，这是一个为高维稀疏数据设计的工业级训练系统。XDL包含了诸如层次样本压缩、工作流流水线、零拷贝和CPU绑定等优化，以提高模型稀疏部分的训练效率。
• Kraken [62]针对更高效的在线训练，通过解耦键值获取和嵌入、与ML领域知识共同设计的缓存逐出策略、针对模型的稀疏和密集部分的内存高效优化器，以及允许推理服务器和参数服务器独立扩展的非共址部署模型。
• [25]通过无锁嵌入表更新、调整循环平铺来优化基于CPU的DLRM训练，AlltoAll通信原语，以及利用FP32和BFloat16中的位别名优势来减少内存占用的新split-SGD实现。
• 百度的AIBox [70]采取了不同的方法进行水平扩展，专注于在单个节点上适应大型推荐模型的训练。AIBox通过流水线网络、磁盘和CPU/GPU任务隐藏服务延迟，减少模型更新开销，并通过分组哈希方案和多级内存哈希系统提高SSD寿命。

由于通信性能已成为集群和数据中心规模分布式训练的主要瓶颈，因此对通信性能的关注越来越多。

• BytePS和ByteScheduler [24, 49]利用空闲CPU和网络资源以及更好的通信调度来提高参数交换效率。然而，在每个作业跨越多个节点的同质训练集群中，寻找和利用空闲网络资源的机会减少，导致这种方法的次优使用。
• SwitchML和ATP [30, 53]利用可编程网络交换机在数据中心环境中执行网络内聚合，以减少跨机架带宽。
• [6, 36]发现并利用数据中心网络的局部性，并通过学习和最优合成形成优化和动态的聚合路由。
• 这些论文[33, 34]通过使用各种量化方案来减少通信量，以解决通信开销问题。

参考

• https://arxiv.org/pdf/2104.05158

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的商品服务器上。因此，仅靠压缩不足以支持新兴的大型深度推荐系统。

参考

• 1.https://arxiv.org/pdf/2011.02084

华为在《DFFM: Domain Facilitated Feature Modeling for CTR Prediction》中提出了一种DFFM的多场景建模方法。

4.方法

4.1 整体结构

域辅助特征建模(DFFM：Domain Facilitated Feature Modeling)的总体框架可分为两个主要模块：

• 域辅助特征交叉(DFFI)：Domain Facilitated Feature Interaction
• 域辅助用户行为(DFUB)：Domain Facilitated User Behavior

我们提出的DFFM概述如图2所示。

图2

• DFFI模块：负责提供有价值的domain信息来支持特征交叉建模，
• DFUB模块：利用domain和目标知识来更好地建模用户行为。

这两个模块的详细设计将在下一小节中说明。

4.2 DFFI

特征交叉建模在CTR预测中是至关重要的，例如PNN、AutoInt和DCN。然而，所有这些模型都忽略了考虑领域（domain）信息的重要性。在不同领域中的特征交叉应该有不同的建模方式，例如，在某些领域中，一些特征交叉非常重要，而在其他领域中则毫无意义。因此，我们提出了域辅助特征交互(DFFI)模块，可以对任何特征交叉模型进行操作，引入领域（domain）信息来辅助交叉建模。

以PNN [18]中的内积为例，我们的域增强内积（domainenhanced inner product）可以表示为：

…(2)

其中：

• $e_i$和$e_j$是第𝑖个和第𝑗个字段的embedding；
• ⟨·，·⟩是内积；
• D(·)是用于融合domain信息的domain network，它是一个micro-MLP，可以表示为：

…(3)(4)(5)

其中：

• $h_{𝑖𝑛𝑝𝑢𝑡}$是输入向量
• 𝜎是激活函数
• 𝐿是领域网络（domain network）的深度

特别地，权重和偏置参数$W^{(k)}$和$b^{(k)}$是通过重塑(reshape)和分割(split)来将domain embedding进行concatenate来生成的。形式上，权重和偏置参数可以表示为：

…(6)

其中：

• $E_𝑑$是所有domain embedding的拼接。该过程的可视化示例如图2所示。需要注意的是，PNN仅对2阶特征交互进行建模。对于具有高阶特征交互的模型，如DCN和AutoInt，我们应该将domain network应用于每阶的特征交互的输入。

有了该 domain-enhanced inner product，接着我们可以生成 domain-enhance feature interaction layer：

…(7)(8)

其中：

• $h_{𝐷𝐹𝐹𝐼}$是DFFI模块的输出表示；
• 𝑛是字段的数量；
• E是所有字段的拼接嵌入。

通过动态加权网络，特征交互的建模考虑了领域知识。同样的方法不仅适用于内积，还适用于其他特征交互模型，例如AutoInt中的自注意机制或DCN中的交叉网络，这将在第5.4.2节中得到验证。

4.3 DFUB

用户行为建模在CTR预测中起着重要作用[12]。当前的方法，如DIN和CAN，侧重于建模目标物品（target items）和用户历史序列之间的co-action关系。尽管这些方法在特定领域取得了成功，但我们强调考虑建模用户行为的领域相关信息（domain related information）的重要性。例如，用户在售前（pre-sales）和售后领域（post-sales）之间的购买兴趣迅速变化，这表明他们的行为历史对点击行为的共同作用模式不同。为了明确考虑这种现象，我们提出了域辅助用户行为建模（Domain Facilitated User Behavior modeling），简称DFUB。

DFUB采用修改版的多头自注意机制（modified multi-head self-attention）来处理用户历史序列。

假设：

• 用户行为历史的embedding可以表示为：$E^h=\lbrace e_1^h，e_2^h，\cdots，e_n^h}$，其中𝑛是行为历史长度。
• 目标物品（target item）表示为：$E^t=\lbrace e^t \rbrace$
• 领域特征（domain features）可以表示为：$E^𝑑=\lbrace 𝒆^𝑑 \rbrace$

对于第𝑖个head，标准的self-attention模块处理可以表示为公式9。

…(9)

在公式9中：

• $𝑑_𝑖$是第𝑖个头的输出维度
• $Θ(E_𝑡，E_𝑑)$表示使用$E_𝑡$，$E_𝑑$来获取self-attention模块的参数。
• $Q_𝑖, K_i, V_i$分别表示：指query矩阵、key矩阵和value矩阵。这三个矩阵都是从行为序列embedding $E_𝒉$计算得出的，如公式10所示。

…（10）

其中，$W_𝑄^{(𝑖)}，W_𝐾^{(𝑖)}，W_𝑉^{(𝑖)}是转换矩阵(transformation matrix)。到目前为止，所呈现的计算过程都是关于序列行为items的内部交叉。该目标是与target item和历史行为items间充分交叉，并利用domain information来指导这种交叉。我们通过根据公式11将target item embedding$E_𝑡$和domain embedding$E_𝑑$直接整合到self-attention参数中来实现这一目标。

…(11)

如公式11所示，自注意力的参数可以分解为两部分。第一部分$(W_𝑄^{(𝑖)}′，W_𝐾^{(𝑖)}′，W_𝑉^{(𝑖)}′)$是自注意模块的固有参数。第二部分$(E_𝑄，E_𝐾，E_𝑉)$是从目标项和与领域相关的特征嵌入中重塑的。通过这种方式，目标项和领域特征的信息可以逐个元素地参与到交互过程中，并得到彻底的处理。多头拼接组成了一个综合的多头自注意层，可以拼接成DFUB模块的最终输出，如公式12所示，其中W𝑜𝑢𝑡是输出转换矩阵：

…(12)

4.4 Prediction Layer和Optimization

然后，我们可以将DFFI和DFUB模块的输出表示拼接在一起，以获得：

…（13）

使用带有Sigmoid函数的线性层来获得最终预测：

…(14)

其中，$W_𝑜$和$b_𝑜$是权重和偏置参数。我们采用广泛使用的交叉熵损失作为目标函数。

#

• 1.https://dl.acm.org/doi/pdf/10.1145/3583780.3615469

Anastasiia Klimashevskaia等人在《A survey on popularity bias in recommender systems》系统中介绍了近些年相关的Popularity Bias paper。我们看下相关的一些章节：

摘要

推荐系统以个性化的方式帮助人们找到相关内容。这类系统的主要承诺之一是：它们能够增加长尾items（即目录中不太知名的items）的可见度。然而，现有研究表明，在许多情况下，当今的推荐算法反而表现出流行度偏见，也就是说，它们在推荐中往往更关注较为流行的items。这种偏见不仅可能导致推荐对消费者和提供者的短期价值有限，而且随着时间的推移，它还可能引起不希望的强化效应。在本文中，我们讨论了流行度偏见的潜在原因，并回顾了检测、量化和减轻推荐系统中流行度偏见的现有方法。因此，我们的调查包括文献中使用的计算度量的概述，以及减少偏见的主要技术方法的综述。此外，我们批判性地讨论了当今的文献，我们观察到研究几乎完全基于计算实验和关于将长尾items纳入推荐的实际效果的某些假设。

1 引言

如今，许多在线平台都在使用推荐系统——包括大多数主要的电子商务和媒体流媒体网站——它们为消费者和提供者创造了巨大的价值（Jannach 和 Zanker，2021）：

• 从消费者的角度来看，这些系统可以支持他们在信息过载的情况下找到相关内容，或者帮助他们发现之前未知的内容。
• 另一方面，从提供者的角度来看，推荐可以有效地提高参与度，刺激交叉销售或帮助推广长尾（Anderson，2006）中的商品，这些商品不太受欢迎，可能难以找到。

在推荐系统的多种可能好处中，它们似乎特别适合支持长尾业务策略。通过以个性化的方式展示更多的长尾商品，它们既支持消费者发现新内容的目标，也为提供者带来了增益，例如提高用户参与度、客户留存、额外销售或改变需求曲线，参见Celma（2010）、Gomez-Uribe 和 Hunt（2015）、Oestreicher-Singer 和 Sundararajan（2012）。

毫无疑问，推荐系统能够有效影响消费者行为并改变销售分布（Lawrence 等人，2001；Zanker 等人，2006），但在实际应用中，这类系统可能会产生意想不到的效果。例如，对北美一家零售商网站进行的大规模实地测试结果显示，推荐系统确实对小众商品的销售产生了积极影响。然而，对于热门商品销量的增长更为显著。此外，在推荐系统存在的情况下，总体销售多样性实际上降低了（Lee 和 Hosanagar，2014，2019）。这种观察可以归因于底层算法中存在的某种流行度偏见（popularity bias），这意味着算法可能倾向于在其推荐中关注已经受欢迎的商品。结果，已经受欢迎的（“大片”）商品（Fleder 和 Hosanagar，2009）通过推荐获得了更多的曝光，这最终可能导致一个“富者愈富”的反馈循环。

总体而言，过分关注流行商品对于推荐系统在各种应用领域中的消费者和提供者都是不利的。消费者可能会发现推荐内容过于明显，缺乏新颖性，从而无法满足他们的发现需求。而提供者则不仅未能提供充分的发现支持，还错过了通过主要推广那些顾客可能无论如何都会购买或消费的商品来销售长尾商品的机会（Bodapati 2008）。鉴于这个问题在实践中的重要性，过去十年中越来越多的研究工作开始关注推荐系统中的流行度偏见问题。特别是，在公平性和推荐系统中的偏见问题日益受到关注的背景下，以及在潜在的有害推荐效应，如过滤泡沫、回声室效应、说服和操纵的背景下（Aridor et al. 2020; Elahi et al. 2021a），这个话题在最近几年变得尤为流行。

通过本文，我们的目标是：提供一份关于推荐系统中流行度偏见当前文献的多方面概述，这是一个近年来受到相当大关注的话题。为此目的，我们系统地回顾并按照不同维度对123篇论文进行了分类，例如，根据背后的研究动机、处理流行度偏见的技术方法和评估方法。在我们的分析中，得出了以下关键见解：

• 在背后的研究动机方面，大多数研究工作基于应用无关的假设，即关注流行商品本身就是有问题的，并可能导致诸如某些商品曝光有限、偏见强化和用户默认的推荐质量受限等潜在后果。当前文献中的很多研究似乎也受到了对推荐系统中公平性日益增长的兴趣的推动。特定于应用的考虑，例如，在特定使用情境中流行度偏见何时可能实际上有害或导致不公平，大多缺失。通过我们的工作，我们旨在提供对流行度偏见后果的更细致讨论，并提供一个新颖的、以影响为导向的流行度偏见定义。
• 文献中提出了丰富的计算方法，主要用于量化现有偏见或减轻偏见。减轻偏见的方法本身可以被归类为预处理、过程（建模）中和后处理方法。我们发现，支持竞争目标联合考虑的过程技术是文献中最常用的减轻偏见的形式。
• 从评估的角度来看，我们观察到文献严重依赖于离线实验和丰富多样的抽象和应用无关的计算度量。涉及用户或实地测试的研究非常罕见。这种现象，就像在推荐系统中的公平性研究和人工智能领域中的公平性研究一样，可能会导致某种“抽象陷阱”（Selbst 等人，2019），其中研究问题的运作化过于抽象，忽略了特定应用用例的特殊性。这可能导致学术研究与现实世界问题设置之间存在一定的差距。

本文的其余部分安排如下。我们首先在第2节详细阐述该概念的现有定义和可能的流行度偏见来源。在第3节描述了我们识别相关论文的研究方法后，我们在第4节提供有关我们在文献中观察到的不同类型贡献的统计数据。我们在第5节讨论处理流行度偏见的技术建议，并在第6节回顾评估方法。本文以第7节结束，讨论我们的见解以及对研究空白和可能的未来方向的展望。

2 背景

在本节中，我们定义了流行度偏见（popularity bias）这一术语，更深入地讨论了bias的可能来源，并概述了流行度偏见所带来的实际负面影响。

2.1 流行度偏见作为一种与曝光相关的现象

虽然我们观察到：研究社区对推荐系统中流行度偏见潜在危害的普遍共识，但迄今为止似乎并不存在一个独特的定义。最常见的是，流行度偏见（popularity bias）被认为是展示（曝光）给用户的推荐项的一个特性。

例如，在Abdollahpouri和Mansoury（2020）中，流行度偏见被描述为一种现象，其中“流行商品被推荐的频率甚至超过了它们的流行度所能保证的。” 在这种解释中，当系统过度推荐流行商品时，就存在偏见。在其他作品中也讨论了推荐中的差异，例如Lesota等人（2021）。然而，在其他定义中，这种比例并不在焦点中，而是将强调流行商品本身视为一种偏见。根据Abdollahpouri等人（2017a），“协同过滤推荐系统通常比其它‘长尾’商品更多地强调流行商品（那些拥有更多评分的商品）。”同样，Boratto等人（2021）指出，流行度偏见可以被描述为推荐系统可能“倾向于推荐流行商品而不是小众商品，即使后者也会感兴趣。”这样的概念也被Zhu等人（2021a）和其他作品采纳。

我们注意到，Boratto等人在他们的讨论中将观察到的推荐中的偏见与一个潜在原因联系起来，即当算法在数据集上训练时，其中观察到的互动并不是在所有items上均匀分布的，偏见就会发生。在一些工作中，这种倾斜的分布本身被称为流行度偏见，因此将流行度偏见框架化为推荐系统所捕捉到的训练数据的特征。例如，Zhao等人（2022）发现“观察数据通常表现出严重的流行度偏见，即items分布非常不平衡，甚至是长尾的。”

最后，一些工作在离线评估指标的背景下讨论了推荐系统中的流行度偏见。在这种情况下的一个特别挑战是，某些指标，特别是准确率（precision），可能偏爱推荐流行商品的算法。通过对用户进行平均，优化高精确度意味着试图满足大多数（以流行度为导向的）用户，而“不考虑少数群体的满意度”（Bellogín等人，2017）。这可能导致非个性化和以流行度为导向的方法的竞争性能（Cremonesi等人，2010），并提出了替代的评估协议来处理这类问题，参见Bellogin等人（2011）、Bellogín等人（2017）、Ekstrand等人（2018）、MenaMaldonado等人（2020）、Yang等人（2018b）。

在这项工作中，我们采用了先前讨论的观点和术语，其中流行度偏见是与推荐给用户的商品的流行度相关的现象。因此，我们将观察到的现象与流行度偏见的潜在来源分开。

2.2 偏见的来源和偏见放大

在大多数关于推荐系统的研究工作中，一个item的受欢迎程度，是通过观察数据集中用户互动（例如，评分、点击、购买）的数量来评估的。我们注意到，在推荐系统的大多数应用中，我们实际上并不期望有一个平衡的分布。在许多领域，有些items可能比其他items更受欢迎。例如，电子商务商店中的一些产品可能因为质量更好、价格更便宜或通过广告强烈推广，导致观察到的购买更多。另一方面，在娱乐领域，一些电影或音乐曲目可能只是吸引更广泛的受众，因此我们可能会记录更多的流媒体事件。我们将这种关于items受欢迎程度的预先存在、通常倾斜的分布称为数据中的“自然偏见(natural bias)”。

除了数据中可能存在的偏见外，我们注意到在选取用于训练推荐系统的数据时可能会引入额外的偏见（数据收集或代表性偏见）。例如，在创建训练数据集时，可能只考虑了用户基础的某个特定子集，但这个子集可能并不代表整个人群。

无论如何，虽然收集的数据集中的某种不平衡可能看起来是自然的，推荐系统的一个严重问题是：它们可能会加强这些预先存在的分布。最终，这种加强可能会导致长期的不利影响，系统中越来越重视已经受欢迎的items，从而减少了不太知名items被用户曝光的机会。Chen等人（2020）识别了可能导致推荐系统中反馈循环的各种因素，如图1所示。

图1 推荐系统中的Biases与feedback loop

内部而言，现今许多推荐系统都是基于某种类型的机器学习模型。任何机器学习算法的核心能力是从过去的经验（训练实例）中泛化，以应对新情况（未见过的实例）（Mitchell 1990）。因此，算法学到的内容总是在某种程度上反映了训练数据中的观察结果，特别是数据中存在的任何（预先存在的）偏见。我们在这里指出，每个算法可能都有自己的归纳偏见，即在从训练数据到通用模型的归纳飞跃中执行时的一组假设（Hüllermeier等人，2013）。

让我们考虑一个非常基础的场景，即推荐经常一起购买的商品，这在当今的主要电子商务平台上得到了实施。从技术上讲，这种类型的推荐可以被视为关联规则的一种基本形式（Agrawal等人，1993；Ludewig等人，2021）。在规则挖掘任务中，一个常见的挑战是，支持度最高的规则通常涉及非常受欢迎的商品，而且很难确定涉及小众商品的规则（Uday Kiran和Krishna Re，2009）。因此，可以直观地假设，基于“经常一起购买”统计数据的商品，建议倾向于进一步强化已经受欢迎商品的推广。

用户基于机器学习模型的推荐系统在一定程度上反映了系统从数据中学到的内容以及它是如何被优化的。特别是在训练过程中，根据所使用的优化指标，算法可能已经学会了——尽管不一定是显式地——推荐流行商品将根据该指标获得高的“奖励”。

最终呈现给用户的推荐通常被认为能在一定程度上影响他们的选择。推荐列表中排序较高的商品通常会获得更多的曝光和用户关注，因此更有可能被消费（例如，由于位置偏见）。结果，它们可能比其他items更频繁地被消费或购买。因此，如果推荐受到流行度偏见的影响，最终意味着已经流行的商品从这种增加的曝光中获益更多，而不是一些不太知名的商品。重要的是，当用户采纳（即消费或购买）一个被推荐的流行商品时，这一事实通常会以某种方式反映在用于重新训练底层模型的数据中。成功推荐一个流行商品，例如，将进一步增加一个商品的购买统计数据。此外，由于流行商品通常在一般质量和吸引力方面是很好的推荐，如果假设人们倾向于对他们喜欢的事物提供反馈，那么它们获得正面反馈（例如，以评分的形式）的机会也可能很高。这对应于已知的问题，即某些数据点是“非随机缺失的”，参见Marlin等人（2007）关于该主题的早期研究。

总体而言，我们观察到推荐系统中有多个阶段可以进入或加强流行度偏见。相应地，当目标是减轻推荐中可能不受欢迎的流行度偏见的影响时，存在不同的方法和起点。

2.3 流行度偏见可能带来的负面影响

研究流行度偏见的动机通常是由算法过度关注已经流行商品可能带来的潜在负面影响的例子所驱动的。有时，推荐流行商品被认为是有问题的，因为这可能会不公平地减少并阻止其他商品的曝光。在其他情况下，人们提到了随时间可能发生的潜在加强效应，这种情况通常被描述为“富者愈富”，这种现象有时被称为“马太效应”（Wang et al. 2018）或“前缀偏见”（Rashid et al. 2002）。

乍一看，人们可能会认为推荐流行商品并没有错。实际上，在线下世界中推荐畅销商品也是非常常见的，例如，《纽约时报》畅销书推荐就是这种形式。而且，在精英主义社会中，如果这些畅销商品因为质量更高或普遍吸引更多人而获得更多推荐，那么它们获得更多关注可能并不被认为是问题或不公平的。因此，上述关于流行度偏见潜在危害的说法有时似乎过于笼统。

然而，当我们更仔细地审视这个问题以及推荐系统预期的目的和价值（Jannach 和 Zanker 2021）时，我们可以很容易地推导出流行度偏见在哪些方面（a）限制了推荐对个别利益相关者的潜在价值，或者（b）偏见实际上是有害的。在价值受限方面，消费者可能会发现，受流行度偏见影响的推荐不能帮助他们发现新内容（因为缺乏新颖性）或符合他们个人偏好的内容（因为个性化程度有限）。这两个方面反过来可能会限制消费者与提供推荐服务的互动，或者通过失去对系统的信任完全使他们远离。在提供者方面，主要推荐流行商品还可能导致错失销售机会（因为流行商品无论如何都会被购买）。此外，它可能导致随时间销售多样性的减少（因为一小撮流行商品获得了所有曝光）。有关实地和模拟研究的相应报告可以在 Fleder 和 Hosanagar (2009)，Jannach 等人 (2015)，Ferraro 等人 (2020) 中找到。

在某些应用领域，受流行度偏见影响的系统实际上可能造成损害（而不仅仅是提供有限价值）的情况也可能出现。近年来，关于推荐系统中公平性的各种研究工作——参见 Ekstrand 等人 (2022)，Wang 等人 (2022b)，Deldjoo 等人 (2023) 的最新调查——认为流行度偏见可能导致不公平。例如，某些工作可能主要推荐给特定的种族群体，当推荐系统延续历史歧视时。或者，一个音乐推荐系统可能不公平地主要推广某些已经受欢迎的艺术家群体的音乐，限制了那些可能属于代表性不足的性别或流派群体的艺术家的曝光机会。

另一种完全不同的有害情况可能发生在一个受流行度偏见影响的系统推广有害内容时。我们记得，在许多应用中，受欢迎程度是根据与一个items观察到的互动来衡量的。特别是在社交媒体中，争议性内容（包括假新闻、错误信息和虚假信息）受到很多关注并不罕见，因为用户高度参与这类内容。因此，一个优化用户参与度的社交媒体推荐系统可能通过向越来越大的受众推荐这些可疑内容来进一步推广它们。此外，这样一个受流行度偏见影响的系统也可能容易推荐那些通过假用户、虚假评论/评分和自动化机器人获得很多互动的内容，参见例如 Lam 和 Riedl (2004)，这最终可能导致对系统的信任丧失。

总的来说，无论效用是减少还是实际造成伤害，调查流行度偏见问题时，考虑特定应用用例的具体性和特殊性是很重要的。一方面，推荐流行商品实际上可能是对提供者最有利的选项，例如，当畅销商品也是带来最高收入、利润率或其他业务关键绩效指标（KPI）的商品时。另一方面，推荐已经流行的商品本身不应被视为不公平，但我们必须审视哪些关于公平的潜在规范性主张受到流行度偏见推荐的影响。此外，我们必须记住，某些影响可能只有在长期内才变得明显。在新闻网站上推广最受欢迎和最新的名人八卦可能在短期内在点击率（CTR）方面带来积极效果；然而，从长远来看，它可能导致与服务的互动有限。

最后，我们注意到在某些情况下，关注流行商品也是一种有益和有帮助的方法。在对用户偏好知之甚少的冷启动情况下，推荐流行商品是一种非常常见的策略。例如，当一个新用户注册到推荐系统时，系统对用户的偏好一无所知或了解有限，因此可能无法为她生成相关的推荐。在这种情况下，可以采用基于流行度的主动学习策略，选择最受欢迎的商品向新用户推荐，并获取它们明确的评分（Rashid et al. 2002）。优势在于用户很可能对流行商品有所了解，因此实际上能够对这些商品进行评分。尽管有积极的一面，但流行商品通常受到用户的喜爱，因此，它们的评分往往不会为系统提供太多信息（Elahi et al. 2016）。

此外，也可能存在特定算法过于关注小众内容的情况。在这种情况下，推荐可能对用户来说显得过于晦涩，无法激发他们的兴趣，限制了他们对服务的满意度（Ekstrand et al. 2014）。包含一些流行的推荐可能有助于在用户方面建立对推荐一定程度的熟悉感，以及他们对一些推荐适合自己信任。在工业环境中，加入一定量的流行推荐也并不罕见，例如，在Netflix的个性化视频排序系统中（Gomez-Uribe 和 Hunt 2015）。

2.4 以影响为导向的流行度偏见定义及其与新颖性、多样性和公平性的关系

如本节开头所讨论的，文献中“流行度偏见”这个术语没有统一的定义。一些定义可能也不易解释或应用。例如，如果我们开发一个推荐系统，它简单地向每个人推荐最受欢迎的商品，可能很难判断这是否代表了一种商品被推荐“比它们的流行度所能证明的更频繁”的情况，如Abdollahpouri和Mansoury（2020）或Chen等人（2020）所描述的。此外，我们的讨论还表明，推荐流行商品本身并不一定是有害的，相反，这可能取决于特定用例的特殊性。

根据我们的讨论，并在假设“偏见”一词通常表示一个不期望或有问题的方面的前提下，我们建议将来使用一个以影响为导向的术语解释。因此，我们提议如下定义推荐系统中的流行度偏见。

当系统提供的推荐集中于流行商品，以至于限制了系统的价值或对某些相关利益相关者造成伤害时，推荐系统就面临流行度偏见问题。我们强调，我们的定义旨在具有通用性和包容性，因为它（a）不规定量化流行度的具体方式，（b）不假设偏见的来源，以及（c）可能包括流行度偏见的短期或长期影响。

推荐商品的流行度与推荐系统的一些“超越准确性”的质量特征相关，特别是与新颖性、多样性和意外性（Castells et al. 2021; Kaminskas and Bridge 2016; Ziarani and Ravanmehr 2021）相关。

与新颖性的关系。通常认为，如果用户之前不知道某个推荐内容，则该推荐对用户来说是新颖的（Castells et al. 2021; Kaminskas and Bridge 2016）。因此，新颖性是一个核心的期望特征，因为根据定义，新颖的推荐帮助用户发现新的（且希望是相关的）事物。一组推荐的感知新颖性可以通过用户研究来实证评估（Ekstrand et al. 2014; Pu et al. 2011）。在离线评估中，我们通常无法确定用户是否已经知道某个商品。因此，文献中常见的一种方法是假设，平均而言，不太流行的商品对用户来说有更高的概率是新颖的。因此，新颖性指标的技术实现通常被制定为与流行度指标成反比（Vargas and Castells 2011）。通常，在以新颖性为重点的研究中，一个共同的目标是在不牺牲准确性的情况下提高推荐内容的新颖性（或降低流行度）。在这种设置中，增强新颖性的方法也可以被视为减少流行度偏见的方法。

意外性是与新颖性相关的另一个概念。通常，意外性被视为意外性和相关性的结合（Ziarani 和 Ravanmehr 2021），但文献中也存在其他定义（Ziarani 和 Ravanmehr 2021）。显然，一个意外的items也必须是新颖的。然而，通常只有当一个items在某些方面与用户的常规口味档案不同，它才被认为是意外的。我们在这里指出，通过新颖或意外的items推荐支持的items发现是推荐系统的最常见目的之一。然而，也存在一些用例，推荐系统明确旨在建议已知的items，例如，为了在电子商务环境中刺激重复购买，或者在流媒体平台上提醒用户以前喜欢的内容（Kapoor 等人，2015；Lerche 等人，2016）。

与多样性的关系。多样性通常指的是一组推荐元素在某些方面彼此不同（Ziegler 等人，2005；Kaminskas 和 Bridge 2016）。根据选定的标准和用例，流行度偏见可能与多样性相关。在某些领域，例如在电影推荐中，建议广为人知的流行电影可能会导致一组在制作国家、制作预算或原始语言方面不太多样化的电影。如果这些建议的流行度水平降低，我们可能会观察到这些方面的多样性增加。

其他关于多样性的概念包括销售多样性（Fleder 和 Hosanagar 2009），它衡量特定商品上销售量的集中度，或者总体多样性（Adomavicius 和 Kwon 2011），这是一种覆盖度指标，衡量在前n名列表中推荐给用户的目录商品的比例。在总体多样性的情况下，对大多数流行商品的更强关注会导致个性化程度降低，并且可以预见地，会导致目录覆盖度更有限。关于推荐系统对销售和销售多样性影响的实地研究（Lee 和 Hosanagar 2019）得出了部分意想不到的结果。首先，观察到实施推荐系统导致销售多样性减少，这在某种程度上证实了推荐系统会导致集中效应的假设，这可能会加强流行商品。在绝对销售量方面，推荐系统为长尾商品带来了销售量的增加，这是推荐系统的一个预期好处。然而，对于流行商品的销售量增加更为显著。总的来说，我们得出结论，流行度偏见可能会影响多样性。然而，这种关系并不像新颖性的情况那样直接，观察到的效果取决于多样性的具体概念。

与公平性的关系。相当多的近期研究工作将减少流行度偏见等同于增加算法公平性，参见Deldjoo等人（2023）。当然，可能存在这种情况的用例。例如，在一个在线音乐平台上，可能存在一群艺术家，由于社会或历史原因，他们没有同样的机会接触到广泛的听众，例如，因为他们属于一个通常被代表不足的群体。一个通过这些艺术家给予不太流行内容更多曝光的推荐系统，可能被认为是支持对被代表不足群体的公平性的规范性主张（Dinnissen和Bauer 2023；Ferraro等人 2021）。然而，解决潜在的规范性主张的这一方面是至关重要的。简单地增加音乐平台上任意艺术家的曝光度，或者在电子商务平台上增加某些提供者的商品的曝光度，并不一定服务于公平目标。实际上，一些商品可能只是因为它们通常不吸引更广泛的受众，或者因为它们质量有限，所以才不受欢迎。

流行度偏见可能导致的不公平相关负面影响包括：

• 1.对不同用户群体的服务性能不一致：流行度偏见可能导致推荐系统在服务不同用户群体时性能表现不一致，这种不一致可能导致推荐质量的差异。这种性能的不一致可以被解释为系统性能的校准问题，并被视为不同用户群体利益代表不公的证据。
• 2.加剧现有不平等：一些最新的研究工作将减少流行度偏见等同于增加算法公平性。例如，在在线音乐平台上，可能存在一些艺术家群体，由于社会或历史原因，他们没有同样的机会接触到广泛听众，例如，因为他们属于一个通常被代表不足的群体。一个给予这些艺术家不太流行内容更多曝光的推荐系统可能被认为是支持对被代表不足群体的公平性的规范性主张。 3.潜在的负面影响：流行度偏见可能导致对某些商品或服务的不公平推广。例如，在社交媒体中，争议性内容（包括假新闻、错误信息和虚假信息）由于用户的高度参与而获得大量关注。一个优化用户参与度的社交媒体推荐系统可能通过向越来越大的受众推荐这些可疑内容来进一步推广它们。此外，这样的流行度偏见系统也可能容易推荐那些通过假用户、虚假评论/评分和自动化机器人获得很多互动的内容，这可能导致对系统的信任丧失。

综上所述，流行度偏见可能对不同概念的公平性产生负面影响。然而，减少流行度偏见并不一定普遍提高公平性，因为这取决于与特定公平考虑相关的特定潜在规范性主张。

3 方法论

论文检索方法。我们采用了一种半系统化的方法来识别相关研究工作。在我们的方法中，我们应用了Kitchenham（2004）中讨论的系统评审的原则，但我们还依赖额外的手段来发现这个不断发展的领域的更多论文。整个过程在图2中进行了说明。

图2

在第一步中，我们查询数字图书馆，以找到2000年1月1日至2024年1月31日之间发表的、在摘要或关键词中含有“popularity bias”和“recommender / recommendation / recommendations”的推荐系统相关研究工作的初始集合。在论文标题中查找这些术语已经被证明是一个过于狭窄的查询，同时搜索论文本身的文本返回了太多仅仅稍微提及“popularity bias”作为可能相关主题的不相关作品。因此，我们得出结论，通过摘要和关键词进行搜索应该是最精确的方法。我们使用了以下查询词：“popularity bias” AND (“recommender” OR “recommendation*”).1 最后一次搜索执行于2024年1月24日，搜索过程返回了129篇论文。

接下来，我们应用滚雪球程序，通过跟踪初始作品引用的参考文献来识别更多相关作品。此外，我们使用Connected Papers在线工具2来找到额外的相关作品，也使用了关键词“long tail”。在手动过程中去除重复项并筛选出与我们调查无关的作品后，我们最终得到了54篇论文，我们认为这些论文适用于我们研究中的后续分析。我们在线分享了考虑的论文的详细列表以供可重复性。3

总的来说，我们的搜索查询结果相当精确，通过查询检索到的大多数论文都是相关的。只有少数我们认为不相关的论文。这些论文的主要研究贡献不是关于流行度偏见的。例如，一些作品在文本中提到了流行度偏见这个术语——这就是为什么它们被我们的搜索返回——但然后提供了一个专注于不同方面的技术贡献，例如准确性。此外，我们不考虑现有的综述工作作为我们的分析。

与其他综述的关系。在先前关于相关主题的综述中已经考虑了流行度偏见的主题，例如一般推荐系统中的偏见（Chen et al. 2020）、推荐系统的不良效应（Elahi et al. 2021a）或推荐系统中的公平性问题（Abdollahpouri et al. 2020a）。虽然我们的工作与这些工作在一定程度上重叠，但我们的研究专门关注流行度偏见问题。考虑到Chen et al.（2020）提出的有影响力的综述，我们发现这个其他综述的范围比我们的要广泛得多。例如，他们明确地在他们的搜索查询中包含了“fairness”这个术语。此外，Chen et al.（2020）中讨论了反馈循环中的各种类型的偏见，例如用户一致性偏见。鉴于他们范围的广泛性，没有深入讨论专门处理流行度偏见的不同技术方法。相比之下，我们的工作旨在深入覆盖流行度偏见的主题，重点关注技术方法和常见评估方法的综述。

据我们所知，最近的会议论文（Ahanger et al. 2022）是唯一专门关注推荐系统中流行度偏见的工作。在他们的论文中，作者报告了一组最近算法方法的技术细节，以减轻流行度偏见。虽然我们的工作也涉及减轻偏见的技术方法，但我们目前工作的范围更广泛，我们还旨在反映该领域的发展趋势。此外，与之前的综述不同，我们的工作是基于我们通过上述结构化过程检索到的更大集合的研究作品。

4 调查结果：研究概况

在本节中，我们首先将提供更多关于出版渠道和随时间对主题兴趣的统计数据。接下来，我们将描绘现有研究的概况，包括学者如何描述问题以及我们可以在文献中找到哪些类型的贡献。

4.1 出版统计

我们研究中考虑的最早论文发表于2008年。我们注意到，这篇论文没有明确使用“流行度偏见”这个术语，但它专注于如何处理推荐系统中长尾中不太受欢迎的商品（Park 和 Tuzhilin 2008）。在接下来的几年中，只发现了少量相关论文。然而，自2018年左右以来，我们观察到对这个话题的研究兴趣显著增加，特别是也开始使用“偏见（bias）”这个术语。我们可以假设，这个领域的最近研究可能也受到了对公平推荐主题日益增长的意识和兴趣的推动，参见Wang等人（2022b）。因此，考虑的作品中绝大多数（约70%）是在最近五年内发表的。

图3显示了关于流行度偏见的识别研究作品发表在何处。我们将所有渠道归类为“其他”，对于我们只找到一篇相关论文的渠道。有多达48个这样的渠道。这48个渠道在不同维度上相当多样化。它们包括范围相当广泛的计算机科学期刊，以及相当专注的期刊，例如关于机器学习及其应用的期刊。此外，这些渠道包括既建立了一段时间、享有盛誉的期刊，也包括知名度和影响力较低的场所。总的来说，我们考虑了65个不同的渠道，其中发表了关于流行度偏见的论文。虽然在ACM RecSys上发表了十几篇论文，这是本次调查中最重要的渠道，但图表显示，这个话题的研究高度分散。这强调了像本文所呈现的综述的需求。

图3

4.2 问题特征和研究动机

根据我们上面的讨论，推荐流行商品本身并不一定是问题，实际上必须考虑到特定用例的具体性，例如，确定应该在多大程度上减轻某种偏见。在我们分析的第一步中，我们调查了研究人员如何激发他们的工作动机。为此，我们浏览了所有论文的摘要和引言，寻找描述流行度偏见现象以及推荐流行商品潜在危害的陈述。然后我们应用编码程序来识别这些陈述的不同类别。编码由两位研究人员完成。

图4显示了研究人员如何描述流行度偏见现象的主题。我们注意到，个别论文可能属于多个类别。在大多数情况下，研究人员主要以某种形式声明，流行度偏见主要或过分关注推荐中的流行商品。这通常符合我们在前一节中定义的核心部分，即流行度偏见是与向用户展示的推荐相关的现象。只有相对较少的论文将流行度偏见描述为底层数据的现象。然而，许多依赖于这种描述的论文隐含地假设，关注流行商品本身就被认为是有问题的，这可能代表了对问题的简化。

图4

第二频繁的特征是，在流行度偏见存在的情况下，长尾商品的曝光过于有限。虽然从某种意义上说，这可能被视为前一个方面的直接后果，即系统可能过分关注流行商品，但这种描述也指向了一个潜在的危害，根据我们的定义，这是一个关键方面。然而，只有少数作品提到流行度偏见可能阻碍相关长尾商品的推荐，这在现实中是一个极其关键的方面。一些其他作品在它们的特征描述中考虑了推荐质量的问题。在一些情况下，假设流行度偏见可以导致对流行商品的更好预测。其他作品则相反，担心偏见导致推荐不相关的流行商品。

潜在的加强效应被多次提及作为流行度偏见的一个主要方面。然而，考虑到这些论文中的许多提供的技术贡献和实验评估，加强效应实际上并没有被调查，例如，通过从纵向角度评估影响。

最后，在一定比例的论文中，我们无法识别出对研究的流行度偏见问题的清晰动机特征。例如，一些论文分析了推荐系统不同质量指标之间的关系（包括推荐的流行度），而没有深入阐述底层概念，例如Channamsetty和Ekstrand（2017）。其他如Wu等人（2019）在他们的算法设计中将数据分布的倾斜视为多个方面之一。最后，一些作品如Deldjoo等人（2021）为流行度偏见的特定概念提供了一个正式定义，但将流行度偏见视为多个变量之一，在推荐性能的定量分析中考虑。

接下来，我们浏览了摘要和引言，寻找描述偏见潜在负面影响的陈述。这种对负面影响的描述应该通常指导论文中提出的研究，例如，在评估指标方面。编码过程的结果如图5所示。

最常提到的一些危害涉及用户所体验到的推荐质量。流行度偏见可能表现为个性化质量有限、多样性或新颖性有限，或者在发现机会方面有限。然而，也有相当数量的作品提到了对推荐平台或商品提供者的潜在危害，包括某些商品的曝光有限、错过的商业机会或消费者信任度随时间降低。一些作品还提出了潜在的脆弱性问题，即攻击推荐系统可能将商品流行度作为高排序的主要因素。这些观察清楚地表明，社区意识到流行度偏见是一个可能影响多个利益相关者的问题。

我们将在第10节中讨论研究人员如何量化算法方法可能在多大程度上帮助减少或预防流行度偏见的潜在危害。

鉴于社区最近对推荐系统公平性问题的兴趣，我们最后扫描了我们在论文中找到的潜在危害描述中的“公平”一词。只有少数作品在此背景下明确提到公平或不公平，明确了他们对公平的定义以及他们针对的利益相关者。然而，考虑到论文涉及的更广泛的研究背景，我们发现123篇论文中有56篇（约三分之二）确实涉及了推荐系统的公平性问题。这证实了我们上面提到的直觉，即对推荐系统中流行度偏见的研究在很大程度上是由最近的公平性研究推动的。再次，鉴于推荐是一个多利益相关者问题（Abdollahpouri等人，2020a），在审查的作品中考虑了不同形式的公平性，包括用户公平性、商品公平性和提供者公平性，见Burke（2017）。

稍大的比例（60%）的这些作品关注用户公平性，而其余的作品考虑了商品及其提供者的角度。

4.3 应用领域

图6提供了在审查工作中考虑的应用领域的概览。应用领域主要是基于离线实验中使用的数据库来识别的。与其他调查工作类似，例如Quadrana等人（2018），我们将数据库归入如图6所示的更高层次的类别中。

我们可以观察到，绝大多数工作集中在媒体领域，包括电影、音乐、书籍和新闻。其中，电影领域占据主导地位，许多论文依赖于MovieLens数据库之一（Harper和Konstan 2015）。一系列工作解决了电子商务背景下的流行度偏见问题（Gupta等人 2019；Wang和Wang 2022；Luo和Wu 2023；Guo等人 2023；Liu等人 2023a），还有一些工作集中在与旅游相关的POI推荐问题（Banerjee等人 2020；Sánchez和Bellogín 2021；Rahmani等人 2022a，b）。对于其他一些应用领域，只确定了一项或几项研究工作。我们将它们归类为“其他”应用领域，例如包括时尚（Lee等人 2021）、科学文章（Yang等人 2018b）、笑话（Chong和Abeliuk 2019）或游戏（Jadidinejad等人 2019）。

在调查本次调查中考虑的论文时，我们注意到一些论文没有提供特定论证，说明为什么流行度偏见在给定应用领域可能是有害的，或者为什么使用特定数据库进行评估。在其他情况下，作者论证说，流行度偏见可能在某些领域特别有害，而在基于可能立即不清楚流行度偏见可能带来什么重大危害的数据领域的工作时，却没有明确说明，例如，电影推荐。根据我们在第4.1节上面的讨论，我们经常发现研究动机主要是以宽泛的术语给出的（例如，推荐包含太多流行商品，或者“富者愈富”）。

4.4 贡献类型

最后，为了更好地理解现有研究的概况，我们根据论文的主要新颖方面对确定的论文进行了贡献特征描述：

• 分析或量化可能存在的偏见的论文；
• 提出技术建议以减轻现有偏见的论文；
• 尝试利用流行度信息来改进推荐的论文。

图7

图7提供了按这种分类研究的论文的统计数据。在表1中可以找到分析作品的贡献方面的详细分类。我们注意到，一篇论文可以属于多个类别。不足为奇的是，由于我们关注计算机科学领域的论文，大多数论文提出了一种技术方法来减轻流行度偏见的一些潜在危害。较少数量的作品旨在主要量化和分析数据库中存在的偏见，并/或提出计算度量来评估偏见的程度。最后，有限数量的作品试图利用商品的一般流行度信息来改进推荐。我们将在接下来审查每个类别中的选定作品。

表1

5 处理流行度偏见的技术方法

在本节中，我们将更深入地讨论一些选定的方法，这些方法用于偏见量化、减轻和利用。

5.1 偏见量化方法

这类别的论文主要旨在了解可能存在的流行度偏见的程度和严重性，以及这种偏见可能对用户产生的影响。

在我们回顾量化不同目的的流行度偏见的现有工作之前，我们注意到任何量化方法——以及我们稍后讨论的减轻技术——都需要定义适当的度量标准。我们将在第6节中回顾多种度量标准。根据我们上述对流行度偏见的概念，这些度量标准主要量化推荐内容的流行属性，而不是例如底层数据的属性。然而，底层数据的属性在许多工作中是核心，例如，当决定一个商品是否被认为是流行的时候。文献中常见的策略是：将商品归类为流行（短头部）或不流行（长尾部），偶尔还将长尾部分为中间部分和远尾部，参见Abdollahpouri等人（2019b），Borges和Stefanidis（2020）。通常，这种分离是基于数据库中每个商品观察到的互动数量。相比之下，Yalcin（2021）使用的定义是，大片商品不仅要有大量的互动，还必须有高平均评分。无论如何，这些方法中的一个核心问题是如何选择适当的阈值。在现有文献中，大多数应用的是经验规则，没有提供明确的理由。

量化基于流行度现象的另一种方法是由Celma和Cano（2008）以及Celma和Herrera（2008）提出的。在他们在音乐领域的工作中，作者不仅使用播放次数作为流行度指标，还依赖于复杂网络分析的度量标准，根据商品的相似性建模商品之间的连接性。例如，这允许他们分析最受欢迎的商品是否主要与其他流行商品连接，并评估商品通过推荐被曝光和发现的机会。

量化对用户的影响。在这一领域的文献中，一个共同的目标主要是量化流行度偏见的程度，在许多情况下，这些观察结果随后与其他度量标准（如准确性）进行对比。在这些工作中，通常比较来自不同家族的多种算法，例如协同和基于内容的算法，参见例如Channamsetty和Ekstrand（2017），Chong和Abeliuk（2019），Vall等人（2019）。Jannach等人（2015）的分析进一步表明，即使是来自同一家族的算法，例如协同过滤，也可能表现出推荐流行商品的不同倾向。

虽然这些工作通常测量整个用户基础的流行度偏见，但也有一些工作单独考虑某些子群。一些工作根据人口统计学特征识别这样的子群，例如基于年龄和性别（Ekstrand等人 2018；Lesota等人 2021；Neophytou等人 2022）或语言（Elahi等人 2021b）。在这些工作中，目标通常是评估流行度偏见在多大程度上影响不同子群提供的推荐实用性。例如，Ekstrand等人（2018）的发现表明，人口统计学与流行度偏见之间存在非平凡的、可能是有害的相互作用。另一方面，Elahi等人（2021b）对流行度偏见进行了全面研究，研究了偏见效应的强度是否与用户的语言有关。他们基于Twitter数据的分析确实表明，语言可能起作用，某些效应对英语比其他语言更为明显。最后，Sánchez和Bellogín（2021）评估了流行度偏见在两个不同用户群体中对兴趣点推荐的影响：游客和当地人。他们的分析表明，对于后一组用户，推荐的实用性有所下降。

基于用户属性或人口统计学对用户进行分组的另一种方法是根据他们的偏好或行为对他们进行分组。例如，一些用户可能倾向于主要观看主流电影，而其他用户可能表现出对小众电影的偏好。推荐系统可以在这方面分析用户档案，并将它们根据它们的流行度倾向或主流性进行分类。考虑到这样的用户个人偏好对于校准方法是核心的，参见Oh等人（2011），Steck（2018），Abdollahpouri等人（2020b）。这些研究工作中的一个重要问题是，某些用户群体——特别是小众商品爱好者——是否从推荐中获得比其他群体更少的实用性。在一些工作中，这种现象被视为一种潜在的歧视，引发了推荐系统中的公平性问题及其与流行度偏见的关系（Abdollahpouri等人 2019b；Borges和Stefanidis 2020；Kowald和Lacic 2022；Kowald等人 2020；Naghiaei等人 2022；Rahmani等人 2022b）。理解纵向效应。到目前为止讨论的大多数工作采用静态视角，例如，通过评估某个算法在某个时间点的流行度偏见。然而，流行度偏见的一个主要问题：在于它可能创建的反馈循环，这不能直接用这种形式的“一次性”评估来直接评估。因此，一些研究工作尝试研究有偏见推荐的纵向效应。在文献中解决这类问题的常见方法是依赖于模拟方法。例如，在Jannach等人（2015）中，假设推荐系统的用户以一定的概率接受一些商品建议，然后他们以评分的形式向系统提供反馈，这些反馈被反馈到训练数据和推荐模型中，参见Adomavicius等人（2021）。模拟的结果表明，不同的算法可以随着时间加强或减少流行度偏见。后来的模拟方法遵循类似的想法，参见Chong和Abeliuk（2019）和Mansoury等人（2020b）。

在Heuer等人（2021）中，采取了一种非常不同的方法来研究随时间变化的流行度偏见。在他们的工作中，作者使用审计方法来评估YouTube上的偏见放大效应。从技术上讲，他们使用机器人模拟用户体验，这些机器人在某个主题的推荐视频上执行随机游走。他们的发现的一部分表明，“YouTube越来越推荐越来越流行但主题无关的视频”。总的来说，这项工作是在野外研究流行度偏见的少数工作之一。

将流行度方面作为性能预测器。最后，一些研究者量化给定数据库中的流行度偏见，目标是预测不同推荐算法的性能。例如，在Deldjoo等人（2021）中，商品的流行度分布作为几个可能影响模型准确性的数据特征之一被检查。实验分析确实表明，捕捉流行度分布特征的各种度量标准可以帮助做出准确的预测。这似乎特别是对于那些已知对流行商品有某种倾向的算法，如贝叶斯个性化排序（Rendle等人 2009）。关于数据库特征对算法性能影响的相关分析可以在Adomavicius和Zhang（2012）中找到，其中评分分布被用作基尼指数形式的预测器。

5.2 减轻偏见的方法

在这里，我们首先将根据减轻偏见的处理阶段对现有工作进行分类。接下来，我们将更深入地审查一些技术方法。

5.2.1 按处理阶段分类

如图7所示，大多数发表的论文都致力于减轻现有偏见的问题。在本节中，我们将更深入地讨论这些技术方法。受到Adomavicius和Tuzhilin（2015）关于上下文感知推荐系统的工作启发，我们根据减轻策略在推荐算法中实施的处理阶段对现有方法进行分类。我们区分了预处理、处理中和后处理方法。粗略地说，预处理意味着在学习阶段之前以某种方式调整或过滤底层数据集。在一种简单的方法中，例如，可以事先禁止某些非常流行的商品被推荐。在处理中方法中，减轻技术是学习过程的一部分，例如，通过在损失函数中考虑商品流行度。最后，在后处理方法中，通常适应一个经过优化的准确度列表来考虑偏见，例如，通过重新排列items，使不太流行的商品被带到列表的前面。

图8显示了根据处理阶段提出减轻策略的论文的分布。每篇论文的详细分类可以在表2中找到。我们在这里注意到，在某些情况下，将个别论文分配到某些类别是有一定解释空间的。特别是在区分处理中和后处理方法时。甚至更多，当从完全以系统输出为导向的角度来看时，几乎可以将每种方法都视为处理中类型。我们在表2中选择的个别论文的分类，一篇论文也可以被分配到多个类别。以下，我们审查不同类别中的选定方法。

表2

5.2.2 预处理方法

在我们调查中，减轻偏见的预处理方法是最少见的技术。此外，在许多情况下，这种预处理技术与额外的处理中减轻步骤相结合。因此，区分预处理和处理中技术通常留有一些解释的空间。然而，至少有一些方法——特别是那些在模型训练之前应用某些形式的数据集操作的方法——可以明确地被认为是预处理。典型的预处理步骤包括数据采样、商品排除或为学习创建正负样本对的特定形式。例如，在Cremonesi等人（2014）中，作者描述了一个实验，其中从目录中移除了高度流行商品的“短头部”。他们工作的目标是通过用户研究调查当这些高度流行商品不被推荐时，用户体验和推荐系统的感知效用如何变化。

Seki和Maehara（2020）应用了一种更轻微形式的数据采样。这里，预处理步骤的目标是创建一个平衡的数据集，以减轻不同的公平问题，其中之一就是流行度偏见。最终，通过平衡过程，作者旨在创建更公平的模型。然而，必须注意，这样的数据采样和平衡必须小心进行，特别是要确保剩余数据仍然具有代表性。

而不是通过采样减少数据，一些作者提议通过预处理步骤扩充现有数据，通过额外的信息扩展原始数据集。这种扩充可能包括：

• 将某些类型的items元数据纳入多模态（Cagali等人 2021）；
• 添加来自外部来源的用户信息，如他们的社交联系（Li等人 2021），
• 或结合隐式和显式反馈，如在Jadidinejad等人（2019）中所做的。

在这项后续工作中，考虑评分数据被认为有助于（a）更频繁地推荐高质量商品，无论它们（当前）的流行度如何，以及（b）更好地利用模型训练期间的现有用户反馈。

Park和Tuzhilin（2008）提出了一种非常不同的方法，专注于丰富与尾部商品相关的数据。根据这种方法，商品目录被划分为头部商品和尾部商品，并对每个部分分别进行推荐。对于尾部商品，推荐是通过一种称为总聚类（TC）的方法进行的，该方法对尾部商品应用聚类技术，然后根据每个聚类内的评分生成推荐。另一方面，对于头部商品，遵循一种称为每个商品（EI）的方法，该方法不应用聚类，仅根据单个商品的评分生成推荐。

Boratto等人（2021）描述了一种减轻偏见方法的例子，根据作者的说法，这种方法既有预处理元素也有处理中元素。在被认为是预处理操作的部分，作者提出了特定的采样策略，用于点式和成对优化设置。例如，在成对采样的情况下，创建用于学习的item pair对不是随机进行的，而是根据item的流行度进行的。类似的方法在Jannach等人（2015）中更早地被提出，用于贝叶斯个性化排序方法。

5.2.3 处理中/建模方法

处理中方法在文献中是减轻流行度偏见的最常见技术。虽然针对不同的应用领域和场景提出了各种处理中技术，但它们共享一个共同原则，即干预推荐模型，以最小化流行商品的影响，以便预计通过推荐传播的偏见会减少。以下，我们讨论最常见的处理中偏见减轻方法家族。

基于正则化的方法是控制流行度影响的一组突出方法（Abdollahpouri等人 2017a；Kiswanto等人 2018；Boratto等人 2021；Zhu等人 2021b；Kamishima等人 2014；Seymen等人 2021）。正则化通常涉及在优化目标中添加一个项，以降低商品流行度对预测商品评分的影响。在学习过程中，正则化项因此惩罚推荐流行商品和/或帮助推广不太流行的商品。通常添加一个特定的权重因子（或：系数）到正侧项中，以调整正则化的强度，从而平衡准确性和流行度偏见的竞对目标。

在该领域的早期工作中，Kamishima等人（2013）例如，提出了在优化目标中使用特定的正则化项来构建“信息中性”的推荐系统。信息中性意味着某些由用户指定的预定义特征不会显著影响推荐输出。这个最初在过滤泡沫现象的背景下开发的想法，随后被应用于Kamishima等人（2014）中的流行度偏见问题，其中相应的目标是最终得到一个流行度中性的推荐系统。

后来，受到早期处理准确性-多样性权衡工作的启发，Abdollahpouri等人（2017a）提出了通过正则化项平衡流行度和准确性，该正则项在Learning2Rank方法中惩罚推荐流行商品。我们注意到，他们的工作中将流行度偏见视为一个公平性问题，并且在推荐中考虑不太流行的商品主要等同于增加公平性。

Boratto等人（2021）和Zhu等人（2021b）最近提出了“基于相关性的”正则化方法，结合预测评分和商品流行度值。在这些方法中，通过在商品的相关性评分主要由于其流行度而被预测为高时施加惩罚，从而减少流行度的影响。从技术上讲，这些方法基于Beutel等人（2019）早期提出的想法，用于增加推荐系统公平性。

基于约束的方法通常考虑一组规则（约束），以限制解决方案的空间，并将模型的学习过程引导到更有效和准确的结果。例如，Wang和Wang（2022）引入了（α，β）-公平性的概念，该概念认为“相似的商品应在推荐中获得相似的覆盖度”。在这种方法中，参数α和β确定商品相似度和覆盖相似度，目标是使相似商品的曝光水平均等化。通过将此约束嵌入到深度学习推荐模型的随机策略中，可以减少流行度偏见。

另一个值得注意的基于约束的方法是由Seymen等人（2021）提出的，在推荐框架中采用了结合约束和优化任务的技术。特别是，提出的技术通过一组定义各种约束的决策变量扩展了推荐优化目标，例如，上限和下限、辅助变量和加权总和，以调整和控制推荐的各种特征。例如，可以通过上限控制推荐的整体流行度，强制推荐包含不太流行的商品。该框架在各种类型的约束可以轻松整合的意义上是多功能的。在他们的论文中，作者使用该框架解决了不同的问题和任务，包括提供者公平性、流行度偏见和多样化。重新加权方法通过以某种方式调整推荐模型中的权重来控制流行度的影响（Gharahighehi等人 2021；Steck 2011；Zhao等人 2013；Gangwar和Jain 2021；Bedi等人 2014）。Steck（2011）提出了一种早期的重新加权方法。在这项工作中，检查了推荐长尾商品和准确性之间的权衡。为了解决这个问题，作者建议了一个新的度量标准，称为“流行度分层召回”，它以一种将长尾推荐视为更有价值的方式来结合两个目标。在训练期间，可以减少（许多）观察到的流行商品的评分权重，或增加排序过程中的（缺失的）评分权重，参见Steck（2010）。Steck（2011）的工作的一个值得注意的方面是，它报告了与用户的初步研究结果。研究表明，至少对于这个特定的研究设置，用户只欣赏对不太流行商品的轻微偏见。

Zhao等人（2013）也提出了降低流行商品权重的方法，其中作者提出了一个可以利用反映收集的用户数据的许多因素的权重调整机制，例如，用户的意见、共同评分信息和用户提供的评分值。Gangwar和Jain（2021）中找到了使用相反方法的上权重长尾商品的工作的例子，其中使用了受Schapire（1999）启发的提升算法来调整权重，以增加不太流行商品的曝光。

我们在这里注意到，上述讨论的许多重新加权工作采用了静态方法来评估流行度偏见的影响，而Zhu等人（2021a）则采取了纵向视角来观察随时间发展的流行度偏见，参见Jannach等人（2015）、Ferraro等人（2020）。这项工作背后的理念是，在真实的推荐系统中，用户反复收到的推荐并不一定是他们感兴趣的，因此从未被消费过。这些推荐代表了误报错误，因此可以用作负反馈数据的来源。结果，用户喜欢这样的推荐的概率随着每次向用户展示的新推荐而降低。基于这一理念和相应的模拟结果，作者提议通过动态变化的超参数，逐步增加底层重新加权（或重新缩放）的去偏见强度。

可以被视为重新加权特殊情况的是基于逆倾向得分（IPS）的方法（Schnabel等人 2016；Huang等人 2022；Lee等人 2021）。逆倾向的概念从统计学中借鉴，并在几项先前工作中用于减少流行度的影响。在推荐系统的背景下，倾向得分可以被定义为用户基于观察到的用户特征和行为，发现特定商品有趣、因此喜欢它的概率。倾向得分通常基于商品的流行度（Lee等人 2021），因为用户通常更有可能与流行商品互动。然后，将这个得分的倒数作为惩罚应用，有助于避免推荐模型对通常流行商品的观察结果的关联性高估。

Schnabel等人（2016）是最早考虑倾向得分以增加某些商品群体的曝光度，从而减轻选择偏见的。这种现象通常被认为与流行度偏见紧密相关。此外，这项工作利用因果推断和反事实推理进行无偏推荐质量估计。Huang等人（2022）后来描述了一种相关方法，该方法还考虑了倾向得分的动态方面。作者认为，推荐算法应该考虑用户偏好随时间的变化。上述讨论的两项工作都基于显式用户评分。相比之下，Lee等人（2021）基于隐式反馈（点击数据）提出了他们的倾向得分方法。这种方法通过考虑缺失数据中的负倾向，扩展了通常采用的正倾向。作者建议，缺失反馈的含义最初是模糊的——不清楚它是否是负面反馈或只是一个尚未看到的商品。因此，学习以无偏的方式从点击和缺失数据中估计真正的正面和负面偏好，有潜力显著提高推荐准确性。

更准确的，无偏推荐也是Wan等人（2022）研究的重点。在这项工作中，Wan等人提出了一个修改后的损失函数，名为“交叉成对损失（cross pairwise loss）”。作者认为，交叉成对损失比pairwise或pointwise loss方法更不容易受到偏见的影响，因为它可以更好地优化预测分数朝向真正的相关性分数。此外，假设提出的技术可以克服基于IPS的方法的一些限制，即，消除了定义倾向以描述推荐模型曝光机制的需要。通常，基于倾向的技术的一个限制是，倾向的实际值最初是未知的，因此需要近似。这使得这些技术对倾向估计器的选择变得敏感，因此可能受到估计偏见、估计误差和倾向设定错误的影响（Yang等人 2018b）。因此，Saito（2020）建议了一个与倾向无关的损失函数，以解决基于IPS方法的这些潜在限制。

基于图的相似性调整用于控制基于图的推荐系统中流行度偏见的影响，例如在Hou等人（2018）、Chen等人（2014）中，通过“纠正”商品或用户相似性的定义方式。Chen等人在Chen等人（2014）中提出了一种替代余弦相似性的新相似性度量，这通常用于基于图的协同过滤算法。新的相似性度量考虑了两个重要因素：用户口味，由用户节点度表示，商品流行度，由商品节点度测量。将这两个术语包含在新的相似性度量中，并用可调系数控制这些术语，可以定义这些因素对预测分数的影响程度。这反过来有助于减轻流行度偏见，减少流行度的影响力。另一项使用商品节点度的工作是Hou等人（2018），他们也提出了使用一种新的相似性度量。作者将其命名为“平衡相似性指数”，并表示他们的方法能够更多地关注既不是非常流行也不不流行的商品。上述两种方法都使用系数来控制去偏见强度，这需要微调以找到推荐准确性和流行度偏见减轻之间的最佳权衡。

在推荐过程中整side info是另一种用来解决流行度偏见问题的方法。遵循这种方法的策略最初可能旨在关注不同的目标，例如，用户偏好满足度、推荐新颖性和多样性。然而，它们在减轻流行度偏见方面也表现出有效性。考虑侧信息(side info)的理念是，缺乏足够的互动数据，例如，在协同过滤技术中，可能会更多地影响不受欢迎的（长尾）商品，并导致它们在推荐中被低估。例如，已经表明流行商品往往比不流行商品有更多的邻域关系（Hou等人 2018）。这可能导致不流行商品之间的相似度较低，导致它们在基于邻域的协同过滤生成推荐时被忽视。实际上，纯协同过滤技术通常被认为更倾向于加强流行度偏见，因为它们仅依赖于用户互动数据（Jannach等人 2015）。通过在推荐过程中整合额外特征来扩展这些技术可能有助于解决问题并补偿缺失的数据。这在计算基于商品或基于用户的关系时特别有用，通过整合这样的额外信息，例如，用户的社交联系或商品产品的描述。因此，整合侧信息可能有助于更好地平衡推荐中流行和不流行商品的包含，并减轻流行度偏见。

我们注意到，我们使用“侧信息(side info)”这个术语既指结构化的商品元数据，也指与商品相关的文本信息，如内容描述或评论。由于文本侧信息通常使用特定的自然语言处理（NLP）算法进行处理，我们将在后面单独讨论这些方法。

因果推断方法通常尝试更深入地探究流行度偏见的本质及其成因。例如，Wei等人（2021）将排序预测建模为因果关系，并确定商品流行度和用户从众行为在这种关系中的作用。作者提议采用反事实推断来减轻不受欢迎的流行度效应。应用反事实方法的基本理由是，传统的非因果学习方法会加强观察到的用户行为，结果会越来越多地推荐因为它们流行而不是因为商品属性符合特定用户偏好的商品。他们因此寻求回答的反事实问题是，如果模型只关注用户和商品之间的匹配，排序分数将是多少。这些信息最终用于在推荐过程中消除或减少流行度效应。

He等人（2022）讨论了一种基于反事实推断的不同因果模型的方法，两项工作都引入了一个反事实世界来减少流行度对最终推荐的影响。

在相关研究中，Zheng等人（2021）采用因果模型来描述用户互动的发生，并尝试将这些互动归因于用户从众或用户的真实偏好。Zhang等人（2021）也寻求在考虑推荐的时间维度和商品流行度不恒定的事实的同时，消除流行度在因果关系中的影响。作者引入了称为“流行度漂移”的度量来描述商品流行度的变化，并预测未来的流行度趋势。作者声称，了解这些趋势，实际上可以保留一部分流行度偏见，以推广有潜力变得流行但尚未达到并且需要曝光提升的商品。

5.2.4 后处理方法

后处理技术在偏见减轻中非常流行。后处理方法的主要优点包括实施成本通常较低、多功能性以及侵入性低，即后处理技术通常应用于底层推荐模型之上。此外，一些现有方法非常通用，可以应用于多个应用领域。

从技术上讲，文献中的主要后处理形式包括：

• 重新缩放（得分调整），
• 重新排序（重新排列），
• 排序聚合。

所有这些方法通常基于一个由准确性得分排序的给定推荐列表，然后在后处理阶段加入额外信息。

重新缩放（或：得分调整）通过更新给定推荐列表的相关性得分来补偿流行度偏见，通过提升某些商品或惩罚其他商品。然后使用更新后的得分重新排序推荐商品列表。在重新排序的情况下，商品顺序也会改变，但在某些情况下，原始的相关性得分被认为不太相关并被丢弃。相反，这些方法通常仅基于商品排序，交换或交换商品以满足某些标准。排序聚合后处理涉及由不同模型为同一用户产生的多个推荐列表，并基于融合这些列表的排序聚合方法。最后，除了上述三种方法外，后过滤技术可能简单地从推荐列表中移除某些（流行）商品。在重新缩放中，目标是提升或惩罚推荐列表中的某些商品。在考虑流行度的情况下，这可以被视为一种偏见校正方法。因此，典型的目标是：

-（a）包括对用户可能感兴趣的更多或更少的流行商品， -（b）排除用户不感兴趣或已经知道的流行商品， -（c）不包括对用户既不流行又不感兴趣的商品。

Zhu等人（2021b）中可以找到最近的后处理方法工作的例子，其中作者提议以适当的方式向预测偏好得分添加补偿得分以考虑上述目标。我们注意到，在同一工作中也提出了基于正则化的处理中方法。在另一种后处理方法中，Zhu等人（2021a）也应用了偏见校正，但是从动态的角度出发，其中偏见减轻是迭代且重复地随时间应用的。

重新排序似乎是审查工作中最常见的后处理技术。通常，这些方法试图以优化某个特定目标度量的方式重新排序推荐列表中的商品。例如，Abdollahpouri等人（2021）描述的方法旨在平衡列表中商品的相关性和流行度，具有一个灵活的参数，使这些特征中的任何一个更具重要性。相同的目标函数早已由Steck（2011）用于处理中减轻方法。Klimashevskaia等人（2022）后来复制了这种方法，证明尽管该方法能够根据用户流行度偏好调整推荐，但这并不一定能显著减轻整个平台的流行度偏见。在早期工作中，Abdollahpouri等人（2019a）提出了xQuAD查询多样化算法的改编，用于减轻流行度偏见。在相关工作中，作者还从纵向角度研究了这种方法的性能（Abdollahpouri和Burke，2019）。

一些基于重新排序的工作将流行度偏见与新颖性概念紧密联系起来。Oh等人（2011）和Bedi等人（2014）建议在推荐列表中包括更多新颖和曝光不足的商品，以提高推荐实用性。其他工作旨在仅惩罚特定类型的流行商品，例如Yalcin和Bilge（2022）中的“大片”商品，或在Wang等人（2022a）的背景下实施某些应用特定特征或度量，以众包工作者推荐为背景。

最后，一些工作依赖于图和网络科学技术来重新排列推荐列表，以实现某些分布目标。Mansoury等人（2020a）考虑了通过二分图的商品可见性，并在Eskandanian和Mobasher（2020）中使用了稳定匹配算法。这两种方法都将商品和/或用户表示为图中的节点，并使用此模型来调查和增加重新排列推荐列表中商品的曝光度。与此相反，Zanon等人（2022）描述了一种基于图的方法，通过额外的相似性信息进行重新排序。

排序聚合通过结合替代排序来抵消模型训练期间引入的流行度偏见。例如，Dong等人（2019）建议通过双向排序聚合将给定排序与反向推荐排序结合起来。或者，商品排序也可以与用户或用户组的反向流行度排序结合起来，如Yalcin和Bilge（2021）所提议的。Yalcin（2022）提出了一种非常特别的依赖多个排序列表的方法。在这里，想法不是生成多个列表并结合它们，而是基于预定义的标准，如偏好匹配、多样性或流行度分布，选择多个预先生成的列表中的一个。

5.3 偏见利用方法

有一些工作尝试利用流行商品实际上受到许多人喜爱这一事实——因此也是“安全”的推荐，参见我们上面关于Netflix在视频排序中加入流行度信号的讨论。

例如，Zhao等人（2022）声称，并不是所有的商品流行度都是一样的，它可能源于商品的真实质量，因此可以导致高质量的推荐。作者建议利用这种“真实质量流行度”，同时减轻其他流行度偏见的影响，将它们相互分离。在新闻推荐领域，商品的（近期）流行度可能是一个非常重要的信号。例如，Qi等人（2021）的工作表明，使用文章流行度实际上可以带来足够的主题多样性和覆盖率。一些早期的工作也证明了，考虑文章的近期流行度对于提高推荐准确性至关重要（Hopfgartner等人 2016；Tavakolifard等人 2013；Garcin等人 2013）。对于电子商务领域，Jannach等人（2017）报告了关于短期流行趋势重要性的类似观察。

Zhang等人（2022）讨论了一种非常不同且恶意的使用某些算法现有流行度偏见的方式。在这里，作者描述了如何滥用流行度偏见进行攻击，以人为提升目标商品的流行度，利用有偏见推荐系统的可预测行为。这种脆弱性可能会进一步错误地扭曲流行度分布，可能导致信任度的丧失，以及对平台上提供者公平性的损害。总的来说，这项后续工作是一个关键的例子，展示了研究、理解和能够控制推荐系统流行度偏见的重要性。

附录

https://link.springer.com/article/10.1007/s11257-024-09406-0