SLO 保护机制
DLRS 有两种主要的 SLO 类型：Freshness SLO 和 Quality SLO 。图 4 描述了推理服务器如何影响 SLO 的 freshness 和 quality。
一旦接收到请求，推理服务器就会选择相关用户和条目嵌入。然后聚合嵌入，并将聚合嵌入发送给 DNN，后者返回推荐条目分数，DLRS 最终返回一个按分数排序的条目列表。
在这种情况下，Freshness SLO 是根据推荐条目的最新时间戳来衡量的（在理想情况下，这个时间戳应该尽可能接近当前时间）。Quality SLO 可以根据条目的查看时间和点击数量来衡量。在实践中，Ekko 在线维护了大量的 Freshness SLO 和 Quality SLO。
Ekko 可以防止 Freshness SLO 、Quality SLO 受到网络拥塞的影响，这是通过 SLO 感知模型更新调度器以及将该调度器集成到 P2P 模型更新传播来实现的。
如下算法 2 描述了使用优先级调度器增强的 log-less P2P 同步：
Ekko 使用推理模型状态管理器来保护 SLO 免受有害的模型更新。该管理器监控推理模型的健康状况（即 quality SLO）并按需进行低延迟模型状态回滚。下图 5 说明了回滚模型状态的过程。
测试台实验
在评估部分，研究者首先在 30 台服务器集群中进行测试台实验，其中每台服务器包含一个 24 核心 CPU、64GB 内存和 5 Gbps 网络连接。他们将每 3 台服务器分组为一个 DC 以模拟多 DC 场景，因而最多可以构成 10 个 DC。研究者选取其中一个面向训练的 DC，其余皆为面向推理的 DC，将它们彼此连接。DC 间带宽为 4800 Mbps，模拟一个 WAN。
此外，测试台实验包含两个工作负载，其中一个用来训练研究者自身生产环境中通常使用的大型排序模型，另一个使用按时间先后排序的 Criteo Terabyte Click Logs 来训练 Wide & Deep 模型。
测试台实验细分为两个评估指标，分别为更新延迟和性能细分。
更新延迟
研究者分别在同构 WAN 和异构 WAN 中评估了 Ekko 的更新延迟，其中使用了两个基线——Adam 和 Checkpoint-Broadcast，后者是在 DLRS 终应用模型更新的实际方法。Ekko 和基线都使用 DRAM 存储，并采用相同的主要分配和负载平衡方案。
先来看同构 WAN，研究者对 Ekko 与 Adam 进行比较。具体地，研究者分别用 1 个 DC（3 副本）、5 个 DC（15 个副本）和 10 个 DC（30 个副本）来测量延迟。结果如下图 6a 和 6b 所示，在生产和 Criteo 工作负载中，Ekko 的延迟明显低于 Adam。并且，当使用运行生产工作负载的 10 个 DC 时，Ekko 实现了 2.6 秒的延迟，这要比 Adam 的 18.8 秒低了 7 倍。
此外，在 Ekko 与 Checkpoint-Broadcast 的比较中，研究者发现，Checkpoint-Broadcast 在 WAN 中同步 4GB 参数需要 7 秒以上，这要比 Ekko 的秒级延迟（如 2.6 秒）长了几个数量级。
接着来看异构 WAN，研究者同样将 Ekko 与基线进行了比较。在异构 WAN 中，他们将 DC 间带宽默认设置为 256 Mbps。结果如下图 7a 和 7b 所示，Ekko 可以有效缓解生产和 Criteo 工作负载中的缓慢异构链路，允许副本以独立速率同步，并维持秒级同步延迟。
性能细分
研究者同样想要了解 Ekko 同步中各个组件的有效性，因此对 10 个 DC 的生产工作负载进行了性能细分分析。他们首先在配置 Ekko 时仅在同步中使用分片知识，成为了实验的基线配置，等同于点对点同步中的 SOTA 系统版本向量（Version Vector, VV）。
结果如下图 8 所示，仅使用 VV，Ekko 需要 76.3 秒来同步所有参数。而当启用更新缓存后，Ekko 将延迟降低到了 27.4 秒，实现了 2.8 倍加速。
然后，通过进一步启用分片版本，Ekko 又将延迟从 27.4 秒降低到了 6.0 秒，实现了 4.6 倍加速。这意味着跳过未更新的分片可以减少同步引起的网络消耗。
最后，在启用 WAN 优化后，Ekko 再次将延迟从 6.0 秒降低到了 2.6 秒，实现了 2.3 倍加速。这表明点对点同步必须考虑 WAN 中每个链路的可用带宽。
生产集群实验
截止目前，腾讯已经在生产中部署 Ekko 长达一年多的时间。生产环境包括分布在 6 个地理分布式 DC 中的 4600 台服务器。今年以来，腾讯使用 Ekko 支持了广泛的推荐服务，包括视频推荐、搜索和广告。每天有超过 10 亿的用户使用这些推荐服务。
因此，研究者特别报告了 Ekko 在其生产环境的性能，同样使用两个评估指标，即模型更新和 SLO 保护机制。
模型更新
研究者选用的生产环境具有数百个 DLRS 模型，共 计40 TB 参数或 2500 亿个键值对。每个参数分片的范围从 0.1 MB 到 20MB，具体取决于模型大小。Ekko 每秒可以执行 10 亿次更新，速度为 212 GB/s。
关于延迟性能，Ekko 仅用 2.4 秒来同步所有 DC 中的参数，训练 DC 仅用了 0.7 秒。同步流量仅占了总网络流量的 3.0%，体现了 Ekko 在参数服务器上作为后台同步服务的有效性。此外，Ekko 的低延迟、高吞吐量性能不影响系统可用性。自部署以来，Ekko 已实现了大于 99.999% 的参数读写操作可用性。
关于更新缓存分析，实验表明：更新缓存只需要在缓存中保留 0.13%-0.2% 的参数，就可以达到 > 99.4% 的命中率（hit ratios）。
研究者选择更新密集型 DLRS 模型来揭示最坏情况下更新局部性的影响。下图 9 显示了在 480 分钟窗口中更新参数的比例。这个时间窗口涵盖了生产 DLRS 一天中最繁忙的时间。
SLO 保护机制的有效性
研究者还进行了 A/B 测试，以评估 Ekko SLO 保护机制的有效性。
A/B 测试结果表明，在实验组中，Ekko 将同步流量减少了 92%，并将重要更新的延迟保持在较低水平。相反，对照组无法区分模型更新，对照组对 SLO 关键更新进行了延迟，并且 SLO 指标下降了 2.32%。
关于在线模型状态回滚，研究者将 Ekko 与检查点恢复（checkpoint-recovery）方法进行比较。
在实验过程中，研究者告知 Ekko 模型状态管理器将 DLRS 模型的状态回滚到 1 分钟前的版本。然后管理器告知所有 witness 服务器识别最近 1 分钟更新的参数。因此，witness 服务器仅重新加载当前状态和早期状态之间的差异。整个回滚操作只需 6.4 秒即可完成。相比之下，检查点恢复方法与模型状态的最新更新无关，结果是检查点恢复方法必须重新加载整个状态，需要 1157 秒才能完成（比 Ekko 慢 180 倍）。
更多细节内容请阅读原论文。
