冬青的个人主页
文章 标签 分类 关于我 简体中文
冬青的个人主页

目录

SoCC'20 | InferLine: latency-aware provisioning and scaling for prediction serving pipelines

 收录于 论文笔记
   约 5823 字   预计阅读 12 分钟 

./image-20210418141904167.png

概要

在本文中介绍了 InferLine ，一个提供和管理预测流水线各个阶段的系统，以满足端到端的尾部延迟（tail latency）约束，同时最小化成本。InferLine 由一个低频组合规划器（low-frequency combinatorial planner）和一个高频自动缩放调谐器（high-frequency auto-scaling tuner）组成。Planner 利用阶段分析、离散事件模拟和受限组合搜索，为流水线中的每个阶段自动选择硬件类型、副本和批处理参数。Tuner 使用网络演算自动缩放每个阶段，以满足尾部延迟目标，从而响应查询到达过程中的变化。本文展示了 InferLine 在成本上比现有方法 reduce 7.6x，同时在实际工作负载上具有34.5x lower的延迟SLO未命中率，并在最先进的模型服务框架中进行了推广。

./image-20210418170200192.png

研究背景

背景

预测流水线结合了多种机器学习模型和数据转换，以支持复杂的预测任务。例如，最先进的可视化问答服务将语言模型与视觉模型结合起来回答问题。预测流水线可以表示为有向无环图（DAG），其中每个顶点对应于模型（例如，将图像映射到图像中的对象）或数据变换（例如，从视频中提取关键帧），边表示顶点之间的数据流。

./image-20210418143559837.png

本文研究了几种（图2）有代表性的流水线。图像处理流程包括基本的图像预处理（例如裁剪和调整大小），然后使用深度神经网络进行图像分类。视频监控流水线，使用目标检测模型来识别车辆和人员，然后对任何相关图像执行后续分析，包括车辆和人员识别和车牌提取。社交媒体流水线将计算机视觉模型与多阶段语言模型相结合，根据文本和链接图像对帖子进行翻译和分类，以识别源语言，并在必要时翻译帖子。TensorFlow（TF）级联流水线结合了快速和慢速TensorFlow模型，仅在必要时调用慢速模型。

挑战

预测流水线对预测服务系统的设计和提供提出了新的挑战。本文首先讨论如何增加专用硬件加速器以及满足端到端延迟约束的需求导致如何组合配置空间。本文其次讨论了在突发性随机查询负载下，满足尾延迟SLO的一些复杂性。本文之后将这项工作与数据流处理文献中的观点进行对比，后者在结构上有一些相似之处，但针对的是根本不同的应用和性能目标。

组合配置空间（Combinatorial Configuration Space）

  1. 许多机器学习模型可以是计算密集型的，有大量的并行机会。在某些情况下，这种并行性可以导致吞吐量和延迟的数量级改进。例如 TensorFlow 可以在CPU上以每秒0.6个查询（QPS）和NVIDIA Tesla K80 GPU上以每秒50.6个QPS的速度对相对较大的ResNet152神经网络进行预测，吞吐量相差84倍。然而，并非所有模型都能从硬件加速器中同等受益。比如说决策树就没有什么并行空间，很难使用GPU加速。

  2. 在许多情况下，为了充分利用可用的并行硬件，查询必须成批处理（例如，ResNet152需要32的批大小以最大限度地提高K80上的吞吐量）。然而，批量处理查询也会增加延迟。最大批处理大小的选择取决于硬件和型号，并影响流水线的端到端延迟。

  3. 在繁重的查询负载设置中，通常需要复制流水线中的单个 operator 以提供工作负载所需的吞吐量。当我们通过复制来扩展流水线时，每个 operator 的扩展都不同，通过在流水线中使用条件控制流可以放大这种影响，从而导致某些组件比其他组件更频繁地被查询。低成本配置需要对每个 operator 进行细粒度扩展。

将并行硬件资源分配给单个模型会在成本、吞吐量和延迟之间产生一个复杂的依赖于模型的权衡空间。这种权衡空间随着预测流水线中的每个模型呈指数增长。在流水线的一个阶段，关于硬件选择、批处理参数和复制因子的决策会影响其他阶段的可行选择集，因为需要满足端到端延迟限制。例如，在一个模型上，通过增加批处理大小来用延迟换取吞吐量的增加，可以减少流水线中其他模型的延迟预算，因此也限制了可行的硬件配置。

排队延迟

由于资源和模型的异构性，流水线的各个阶段可能以不同的速度运行，因此每个阶段都需要一个队列。队列还允许吸收查询到达时间间隔的不规则性，并且可能是端到端延迟的重要组成部分。在流水线配置过程中，排队延迟必须得到明确的考虑，因为它直接依赖于到达时间间隔过程和系统配置之间的关系。

随机和不可预测的工作负载

预测服务系统必须响应突发的、随机的查询流。在高层次上，这些随机过程的特征是其平均到达率 λ 和变异系数，即 $CV_A^2=σ2/μ2$ 定义的无量纲可变性度量，其中 $μ=1/λ$ 和 $σ$ 是查询到达时间的平均值和标准差。$CV_A^2$ 较高的过程具有更高的可变性，通常需要额外的过度配置来满足延迟目标。显然，在专用硬件上过度配置整个流水线可能会非常昂贵。因此，能够识别和配置流水线中的瓶颈以适应突发的到达过程是至关重要的。最后，随着工作负载的变化，我们需要监控、快速检测和调优流水线中各个阶段的机制。

与流处理系统的比较

在通用的数据流处理系统的背景下，已经研究了关于配置和扩展流水线的许多挑战。然而，这些系统主要致力于支持更传统的数据处理工作负载，包括有状态聚合 operators 和对各种windowing operations 的支持。这些系统倾向于最大化吞吐量，同时避免 backpressure，将延迟作为次要的性能目标，而没有考虑尾部延迟（tail latency）。

  • 本方法的 SLO 目标就是 P99 尾部延迟。

方法介绍

本文设计了一个系统 InferLine，InferLine 需要一个不经常操作的计划器（planner, Low-Frequency Planning）来重新配置整个流水线，和一个调谐器（tuner, High-Frequency Tuning）动态观察查询流量从而对流水线配置进行调整。

InferLine 可以运行在任何预测服务系统之上，但这些系统需要满足一定的要求。底层服务系统必须能

  1. 部署一个模型的多个副本，并运行在一个集群中有扩展副本的数量的能力；
  2. 允许批处理推理，并能够配置最大批处理大小；
  3. 使用集中的批处理排队系统在模型副本之间分发批处理。

前两个属性是InferLine配置服务引擎所必需的，集中式排队系统提供了可由估计器精确模拟的确定性排队行为。在本文的实验评估中，使用Clipper和TensorFlow服务运行 InferLine。这两个系统都只需稍作修改即可满足这些要求。

为了部署由InferLine管理的新预测流水线，开发人员提供了驱动程序、用于规划的示例查询跟踪以及延迟服务级别目标（SLO）。驱动程序函数将特定应用的代码与对托管在底层服务系统中的模型的异步调用交织在一起，以执行流水线

Low-Frequency Planning

Profiler

第一次执行计划时，InferLine 使用 Profiler 创建驱动程序引用的所有单个模型的性能配置文件。性能配置文件通过以硬件类型和最大批处理大小为参数的函数确定模型吞吐量。模型文件中的条目是通过使用样本跟踪中的查询在给定配置中单独评估模型来进行根据经验来测量的。单个模型配置对应于每个参数的特定值以及模型的复制因子。因为模型水平扩展，所以分析单个副本就足够了。对每个硬件和批大小对只需执行一次分析，并在随后的Planner运行中重复使用。

Estimator

Estimator 负责快速估计样本查询跟踪的给定流水线配置的端到端延迟。它将流水线配置、单个模型配置文件和查询工作负载的样本跟踪作为输入，并返回跟踪中每个查询延迟的准确估计值。Estimator 被实现为一个连续时间的离散事件模拟器[5]，模拟整个流水线，包括排队延迟和条件控制流（使用比例因子s）。Estimator 维护一个全局逻辑时钟，该时钟从一个离散事件提前到下一个事件，每个事件触发按时间顺序处理的未来事件。因为模拟只模拟离散事件，所以能够在数百毫秒内较为准确地模拟数小时的真实世界轨迹。

该 Estimator 模拟了通过集中成批排队系统的查询的确定性行为。它将此与模型配置文件信息相结合，模型配置文件信息通知模拟器在特定硬件配置上运行的模型处理给定大小的批需要多长时间。

Planning Algorithm

Planner 根据端到端延迟 SLO 和指定的到达过程，找到一个经济高效的初始流水线配置。它使用一个全局感知的、成本最小化的优化算法为流水线中的每个模型设置三个控制参数。在优化算法的每次迭代中，planner 使用模型配置文件来选择成本最小化步骤，同时依靠估计器（estimator）检查延迟约束冲突。在生成初始配置并部署流水线以服务于实时流量之后，计划器将定期（几小时到几天）在最近的到达历史上重新运行，以便为当前工作负载找到成本最优的配置。

在高层次上，规划算法是一个迭代约束优化过程，贪婪地最小化成本，同时确保满足延迟约束。该算法分为两个阶段。在第一种算法（算法1）中，在忽略代价的情况下，找到一个满足时延SLO的可行初始配置。在第二种算法（算法2）中，它贪婪地修改配置以降低成本，同时使用估计器来识别和拒绝违反延迟SLO的配置。当算法在不违反SLO的前提下，不能对配置进行任何降低成本的修改时，算法收敛。

算法1：初始化一个可用的配置
  1. 首先把流水线里地每一个模型地输入 batchsize 都设为1，并且不设置副本，选择模型中最好的硬件。
  2. ServiceTime 是当前硬件能够达到的时延下界（假设 pipeline 的每一个模型都部署在专用的、最优的硬件上，执行单个 request 所需要的时间。因此存在关系：service time <= any end-to-end latency，当 service time > SLO 时，必然有 100% end-to-end latencies > SLO）。如果 ServiceTime 大于等于 SLO，则配置无法进行下去。
  3. 如果 ServiceTime 小于 SLO，则判断现在流水线是否可用的（满足尾部延迟目标），如果不满足，则寻找流水线中是瓶颈的模型，增加该模型的副本，使得此处的吞吐量增加。一直重复该过程直到配置可用为止。
  4. 返回该可用的流水线配置。

./image-20210418205208940.png

算法2：寻找最低成本地配置
  1. 先使用算法1找到一个可用的配置，如果找不到就直接中止。
  2. 定义三个之后可能进行的操作：增加批处理大小、移除模型副本、降低硬件等级。
  3. 对流水线的每个模型都尝试第二点的三个操作，如果这些操作可以进行（减小了流水线的成本），则执行操作，直到对所有模型都无法进行操作为止。
  4. 返回现在贪心找到的最小成本的流水线。

./image-20210418205230361.png

High-Frequency Tuning

Tuner 监视到达过程的动态行为，以调整每种型号的复制因子，并以低成本保持高SLO实现。 InferLine 仅在调优期间调整每个模型的复制因子，以避免在实时服务期间进行昂贵的硬件迁移操作，并确保可以快速做出扩展决策，以保持延迟SLO(P99 latency)，即使在急剧爆发期间也是如此。Tuner 连续监视当前业务包络线，以同时在不同的时间尺度上检测与规划跟踪业务包络线的偏差。通过分析发生偏差的时间尺度，Tuner 能够在几秒钟内采取适当的缓解措施，以确保满足SLO 要求，而不会不必要地增加成本。它确保在Planner运行期间对到达工作负载进行意外更改期间，保持延迟 SLO。

算法3：反应式地扩展流水线
  1. 设置一定数量不同大小的时间窗口，遍历不同的窗口大小（line 3）：对于某个大小的时间窗口（Windows.size），在时间线上滑动，找到该时间窗口上最大的到达率（MaxQueries [i]/Windows [i] ）（line 4）与该窗口大小的示例到达速率（SampleRates）比较。如果满足条件：“该最大的到达率比相同窗口大小的示例到达速率大”（line 5），则记录下来不同时间窗口满足该条件的到达速率最大的一个。（line 6）
  2. 为了确定如何重新设置管道，Tuner 计算每个模型处理 $r_{max}$ 所需的副本数量，即 $k_m=\lceil\frac{r_{max}*s_m}{μ*ρ_m} \rceil$ （第9-10行）。$s_m$是模型m的比例因子（流水线中条件分支指向模型m的比例），它可以防止由于条件逻辑而只接收部分查询的模型的过度配置。$ρ_m$是最大供应比率，它确保模型中有足够的冗余来处理突发事件。
  3. 使用第二步算出来的结果，为每个模型增加副本。

./image-20210418205252109.png

算法4：反应式地缩减流水线
  1. 判断当前时间是否距离更新已经过去了15秒，避免振荡更改配置。
  2. 使用与算法3相同的方法，找出最近最新的到达速率，然后对每个模型删除一些不必要的副本。

./image-20210418205407714.png

实验部分

./image-20210419215116116.png

./image-20210419215243022.png

./image-20210419215544137.png

由上面三个图可以看出 ，InferLine 相比与 CG-Mean 和 CG-Peak 使用更低的成本达到了更低 P99 miss rate。

./image-20210419215605314.png

上面的图九表明，在所有四个实验中，估计和测量的P99潜伏期接近。此外，估计器具有确保可行配置的P99延迟低于延迟目标的关键性质。图6中接近零的SLO未命中率是估计器的进一步证明’检测不可行配置的能力。

./image-20210419215627614.png

上面图十表明 Planner 的敏感性：

  1. 成本随着SLO（P99 尾部延迟）的增加而降低
  2. 突发性更大的工作负载需要更高的成本配置
  3. 成本随着 λ （到达速率）的增加而增加。

./image-20210419215715644.png

上面图十一和图十二表明 Tuner 的敏感性：

  1. Planner Oracle 为一开始就知道整段请求但没有 Tuner，因此一直使用较高的成本以至于避免出现 SLO miss rate，而 Planner Base 一开始不知道后面到达的请求，因此请求增加时 SLO miss rate 会急剧增加。
  2. $τ$ 代表的是请求从150QPS增加到250QPS的速率。很明显，在请求变化速率不高时，Tuner 可以很好地扩展流水线，从而保证 SLO miss rate 稳定趋近于0，但是当请求暴增时，SLO miss rate 也出现了一定程度的上涨，但是 Tuner 很快就将流水线调整过来。
  3. 在请求曲线振荡时，Tuner 可以保持着流水线不会频繁伸缩，因此可以维持着很低的 SLO miss rate。

./image-20210419215831005.png

上面图十三表明与baseline相比：

  1. InferLine Plan 可以让系统一开始有更低的成本
  2. InferLine Tune 可以让系统在请求增加时，更有效地扩展流水线从而保证 SLO 目标，并且在请求减少时，可以缩减流水线的副本，从而让系统可以具有更低的成本。

./image-20210419215851566.png

上面图十四表明：InferLine 为两个预测服务框架实现了相同的低延迟SLO丢失率。 这表明用于在InferLine中配置各个模型的计划算法的一般性。 该图显示了在两个服务框架上运行InferLine时SLO的获得率和管道供应的成本。 由于Clipper中不存在一些额外的RPC序列化开销，因此在TFS上运行的成本略高。

优缺点

优点

  • InferLine 利用每个阶段的性能配置文件（Profiler）和基于仿真的性能估算器（Estimator）来快速探索配置空间，而无需运行流水线。
  • 像Dhalion和DS2等系统是面向吞吐量的，并且忽略考虑突然到达的流量，也有别的一些考虑延迟的系统像DRS、Elastic Stream Processing with Latency Guarantees、Nephele Streaming，但考虑的是平均延迟。而 InferLine 是以 P99 尾部延迟作为目标，并且考虑配置流水线以应对高峰负载。
  • 相比现有的一些相似的系统，比如 [Autoscale][13] , InferLine 具有更优的尾部延迟 SLO 和成本，并且支持批处理。
  • 本文提出的四个算法都自然而然地符合人的思维和直觉，比较容易理解，在这同时得到了不错的效果。

缺点

  • 该系统没有考虑到实际应用的一些场景，在机器学习中，延迟可能会受输入的影响；在一对特定的加速器AB中，可能A在小的 batch size会更快，在大的 batch size 中会更慢。

更新于 2021-12-27
 预测流水线系统
返回 | 主页