介绍

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 $ 的嵌入的离散子集。为了在模型中方便访问，我们将这些嵌入组织为嵌入特征表，形式如下：

\[T_j = \langle K_j, E_j \rangle = \{\langle k^0_j, e^0_j \rangle, \langle k^1_j, e^1_j \rangle, \dots, \langle k^n_j, e^n_j \rangle\}, \quad (1)\]

其中：

• 每个元组 $ \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