Proteus: A High-Throughput Inference-Serving System with Accuracy Scaling

文章标题: Proteus: 一种具有精度缩放功能的高吞吐量推理服务系统
作者: Sohaib Ahmad, Hui Guan, Ramesh K. Sitaraman
机构: University of Massachusetts, Amherst
作者: Brian D. Friedman, Thomas Williams, Thomas Woo
机构: Nokia Bell Labs

A1 主要贡献

核心问题：现有的机器学习推理服务系统主要依赖硬件扩展（增加设备或使用更强大的加速器）来应对增长的查询需求。然而，对于资源有限的固定规模边缘集群或私有云，硬件扩展并不可行。

研究目标：本文研究一种替代方案——精度缩放（accuracy scaling），即通过调整模型的精度而非硬件资源来应对变化的查询需求。目标是构建一个基于异构集群的推理服务系统，该系统利用精度缩放来满足变化的查询需求，并实现高系统精度（system accuracy）。系统假定每个查询都倾向于使用最精确的模型变体，但在资源紧张时愿意接受较低的精度以换取及时的响应。

创新点与核心贡献：
* 理论框架：提出了一个用于推理服务系统资源管理的理论框架。该框架利用精度缩放来确保系统吞吐量足以满足查询需求，同时最大化系统精度。为了确定合适的精度缩放量，该框架将资源分配问题分解为三个子问题：模型选择（选择合适的模型变体及其副本数）、模型放置（在异构设备上部署所选模型）和查询分配（将各查询类型的负载分配给特定设备上的模型），并通过混合整数线性规划（MILP）进行联合优化。
* 自适应批处理算法：提出了一种新颖的主动式、非“功守恒”（non-work-conserving）自适应批处理算法。该算法能有效处理查询到达时间的微观波动，通过在不违反服务等级目标（SLO）的前提下，适当延迟请求以累积更大的批次，从而提高吞吐量并减少SLO违规。该算法易于实现，无需修改底层机器学习框架。
* Proteus系统设计：设计并实现了一个名为Proteus的高吞吞吐量推理服务系统。Proteus将控制路径（资源分配）与数据路径（查询服务）分离，使得资源分配可以在不影响查询服务的关键路径上异步进行。据我们所知，Proteus是第一个在集群环境中研究精度缩放的系统。
* 系统评估：在一个企业内部实际用户使用的生产系统上对Proteus进行了评估，并进行了基于真实轨迹的模拟。实验表明，与基线方案相比，Proteus能将精度下降减少高达3.2倍，将SLO违规减少2.8至10倍，同时满足吞吐量要求。

A3 背景知识、关键观察与设计原则

2.1 动机

硬件扩展的局限性与精度缩放的可行性。许多现有的推理服务系统依赖于横向扩展（增加更多设备）或纵向扩展（使用更快的设备）来处理日益增长的查询需求。然而，在某些场景下，如拥有有限设备的边缘云系统或企业为内部用户维护的固定规模集群，这种硬件扩展并不可行。一个可行的替代方案是精度缩放，它利用了推理工作负载中吞吐量与精度之间的天然权衡。这种权衡之所以存在，是因为精度较低的模型通常是较小的神经网络（例如，参数和层数较少），因此需要较少的计算量，允许在给定时间内服务更多请求，从而提供更高的吞吞吐量。如图1a所示，在三种不同类型的设备上，对于给定的设备类型，精度较低的EfficientNet模型变体可以实现更高的吞吐量。推理服务系统可以在查询负载增加时，用精度较低的对应模型替换托管的模型变体，待查询负载恢复正常后再切换回更精确的模型变体。

图1. 不同资源分配配置如何影响系统吞吐能力和精度的图示。模型为EfficientNet变体，批处理大小为1。(a) EfficientNet变体在三种不同设备上的精度-吞吐量权衡。(b) 五种EfficientNet变体和五台设备所有可能配置的精度-吞吐量权衡。
图1. 不同资源分配配置如何影响系统吞吐能力和精度的图示。模型为EfficientNet变体，批处理大小为1。(a) EfficientNet变体在三种不同设备上的精度-吞吐量权衡。(b) 五种EfficientNet变体和五台设备所有可能配置的精度-吞吐量权衡。

2.2 挑战与机遇

构建一个推理服务系统主要面临以下两大挑战。

挑战1：“适量”的精度缩放。第一个挑战在于确定适量的精度缩放以满足目标查询需求。与传统的硬件扩展类似，精度缩放也存在缩放不足或过度的风险。系统可以始终托管最精确的模型变体以最大化精度，但这会导致吞吐量相对较低，并有高SLO违规率的风险；或者，系统可以始终托管最不精确的模型变体以最大化吞吐量，但这会造成不必要的精度下降。确定适量的精度缩放意味着系统需要在合适的设备上托管合适的模型变体集合，并为每个设备分配适量的查询。解决这个资源分配问题非常复杂，因为它受到三个因素影响的巨大配置空间：众多模型变体、异构设备和多种应用。

  • 因素1：众多模型变体。一个查询可以由同一模型的多个变体提供服务，导致吞吐量和精度的范围很广。如图1a所示，即使只考虑一台设备（如NVIDIA GTX 1080 Ti），五种不同的EfficientNet变体选择也会导致吞吐量相差3.3倍，精度相差约8%。当设备集群化时，问题变得更加困难。
  • 因素2：异构设备。现代计算集群通常由不同类型的硬件设备组成。由于每个模型变体在不同设备上的吞吐量特性不同，配置空间变得更大。对于给定的模型变体选择，将其放置在N个不同设备上有N!种方式。图1b展示了5个EfficientNet变体和5个设备之间所有可能映射的系统吞吐能力和精度。在所有3125种可能的配置中，只有帕累托前沿（Pareto frontier）上的配置是我们感兴趣的，因为对于给定的吞吐量要求，这些配置能产生最高的系统精度。这表明确定适量的精度缩放需要协同优化模型选择和模型放置。
  • 因素3：多种应用。推理服务系统的多租户特性进一步加剧了优化问题的复杂性。系统通常为多个应用提供服务，每个应用对应一个特定的查询类型。在这种情况下，为每个查询类型选择的模型变体及其到设备的映射，还取决于为每个查询类型分配了多少以及何种类型的设备。

机遇1：将资源分配问题公式化。上述挑战可以被构想为资源分配的三个子问题：模型选择、模型放置和查询分配，这些问题可以使用混合整数线性规划（MILP）联合求解。由于解决MILP问题需要时间，而查询有严格的延迟要求，因此我们将资源分配从查询服务中解耦。资源在宏观查询需求发生变化时重新分配，以确保系统有足够的吞吐能力处理传入的查询。而每个设备则可以通过自适应批处理来处理非均匀的查询到达，以避免SLO违规。这促使我们设计一个将管理资源的控制路径与服务查询的数据路径分离的推理服务系统。

挑战2：自适应批处理。解耦的资源分配和查询服务在很大程度上依赖于自适应批处理来处理查询到达时间的微观波动。将多个查询一起批处理可以提高吞吐量，但也可能增加查询的等待时间。由于查询到达不均匀，我们需要根据查询到达时间动态调整批处理大小以最小化SLO违规。尽管先前的工作研究了自适应批处理，但我们发现它们的方法效率不高：Clipper【索引9，Clipper: A Low-Latency Online Prediction Serving System，2017，NSDI】是被动调整；Nexus【索引36，Nexus: A GPU Cluster Engine for Accelerating DNN-Based Video Analysis，2019，SOSP】在负载波动时表现不佳；Lazy Batching【索引8，Lazy Batching: An SLA-aware Batching System for Cloud Machine Learning Inference，2021，HPCA】需要对底层ML框架进行重大修改。

机遇2：采用非“功守恒”的自适应批处理方法。我们发现，在查询到达间隔不均匀时，非“功守恒”（non-work-conserving）的自适应批处理方法比“功守恒”（work-conserving）方法更能稳定系统。非“功守恒”方法会尽可能地等待以累积更多查询，然后再执行批处理。我们证明，这种方法可以提高系统吞吐量并减少SLO违规。此外，主动的批处理大小调整方法比被动方法（如Clipper）能显著减少延迟SLO超时。我们提出了一种新颖的自适应批处理算法，它遵循主动、非“功守恒”的方法，且无需修改ML框架。

A2 方法细节

3 Proteus概述

系统架构与组件。我们提出了Proteus，一个利用精度缩放处理不同查询需求的高吞吐量推理服务系统。图2展示了Proteus的整体系统架构，它包含三个主要组件：控制器（Controller）、负载均衡器（Load Balancers）和工作节点（Workers）。

图2. Proteus的系统架构。
图2. Proteus的系统架构。

两种交互类型。系统中有两种交互类型。第一种是开发者注册应用程序及其模型变体（图中虚线箭头所示）。控制器接收注册命令后，会为该应用创建一个新的负载均衡器，并设置工作节点。Proteus会自动管理使用哪个模型变体以及放置在何处。第二种是已注册应用发送推理查询并接收响应（图中实线箭头所示）。查询直接发送到应用的指定负载均衡器，后者将查询路由到工作机器上托管的相应模型变体进行执行。每个应用由其专用的负载均衡器处理，避免了单点性能瓶颈。控制器和负载均衡器的分离使Proteus更灵活、更健壮，允许它在不处于推理服务关键路径上执行资源分配。

控制器（Controller）。控制器负责接收应用和模型变体的注册。它包含四个模块：(1) 资源管理器，当查询需求变化时，确定资源分配策略（包括模型选择、放置和查询分配）；(2) 模型注册表，处理应用和模型变体注册；(3) 模型分析器，分析每个模型变体在不同类型设备上的性能；(4) 统计收集器，从所有负载均衡器收集查询需求统计数据，用于决定何时重新分配资源。模型分析器在注册新模型时以及周期性地被调用，以轮询当前托管模型变体的推理延迟，并将分析信息存储在内存键值存储中，键为(模型变体, 设备类型, 批大小)三元组，以确保O(1)的查找时间。

负载均衡器（Load Balancer）。负载均衡器从其指定的应用程序接收推理查询，并返回模型执行结果。不同应用的负载均衡器可以分布在多台机器上以避免网络拥塞。每个负载均衡器包括两个模块：(1) 请求路由器，根据查询分配策略将查询分派到工作机器上托管的模型变体；(2) 监控守护进程，实时监控查询需求并定期向控制器报告统计数据。当负载均衡器检测到请求突增或任何工作节点过载时，它会调用控制器重新分配资源。

工作节点（Workers）。每个工作节点执行其托管的模型变体，以服务由请求路由器分配的推理查询。工作节点包括两个模块：(1) 自适应批处理模块，动态确定合适的批大小以提高吞吐量，同时满足查询延迟约束；(2) 硬件执行器，管理模型变体的部署和执行。

4 资源管理

资源管理器的功能。资源管理器通过求解一个混合整数线性规划（MILP）优化问题，来确定最优的模型选择、模型放置和查询分配方案，从而在满足目标查询需求的同时最大化系统精度。根据解决方案，它可能会终止设备上当前托管的某些模型变体实例，并启动其他模型变体的实例。它还会将新的查询分配策略传播给请求路由器。在查询需求稳定的情况下，资源管理器会周期性地被调用。然而，如果需求在短时间内迅速变化，负载均衡器中的监控守护进程会调用资源管理器以响应突发情况。资源管理器响应的是宏观尺度的工作负载变化（以QPS衡量），而自适应批处理则响应微观尺度的变化（查询到达间隔的变化）。

资源管理问题公式化。我们使用MILP来公式化带有精度缩放的资源管理问题，目标是在满足目标服务吞吐量的同时最大化精度。下表总结了所用符号。

表1. 优化中使用的符号
表1. 优化中使用的符号

优化变量与约束。我们定义了两个优化变量：布尔变量$\{x_{d,m}\}$表示模型选择和放置策略（模型分配），如果模型变体$m$被托管在设备$d$上，则$x_{d,m}$为真；变量$\{y_{d,q}\}$表示查询分配计划，$y_{d,q} \in [0, 1]$表示类型为$q$的查询被路由到设备$d$的百分比。这两个变量必须满足三个约束条件：
1. 每个设备最多托管一个模型变体以避免干扰（公式1）。
2. 对于给定类型的查询，路由到所有设备的总比例不能超过1（公式2）。
3. 查询分配必须确保设备上托管的模型变体支持所分配的查询类型（公式3），其中$B_{m,q}$是一个布尔常量，表示模型变体$m$是否能服务查询类型$q$。

$$\sum_{m} x_{d, m} \leq 1$$


(1)

$$\sum_{d} y_{d, q} \leq 1$$


(2)

$$\sum_{m} \sum_{d} B_{m, q} \cdot x_{d, m} \cdot y_{d, q}=\sum_{d} y_{d, q}$$


(3)

服务吞吐量。设$z_{d,q}$为设备$d$服务的查询类型$q$的每秒查询数。系统服务吞吐量是所有设备服务的查询总数：$\sum_d \sum_q z_{d,q}$。$\sum_q z_{d,q}$不能大于分配给设备$d$的总查询数（公式4），也不能大于该设备的峰值吞吐能力（公式5）。此外，我们要求所有传入的需求都由系统服务（公式6）。设$s_q$为查询类型$q$的每秒查询数（QPS）。分配给设备$d$的总查询数为$\sum_q y_{d,q} \cdot s_q$。设$P_{d,m,q}$为模型变体$m$在设备$d$上为查询类型$q$分析出的峰值吞吐能力。设备$d$对查询类型$q$的峰值吞吐量则为$\sum_m P_{d,m,q} \cdot x_{d,m}$。设备$d$的服务吞吐量遵循以下三个约束：

$$\sum_{q} z_{d,q} \le \sum_{q} y_{d,q} \cdot s_{q}$$


(4)

$$z_{d,q} \le \sum_{m} P_{d,m,q} \cdot x_{d,m}$$


(5)

$$\sum_{d} z_{d,q} = s_{q}$$


(6)

有效精度（系统精度）。对于每个模型变体$m$，它服务的查询类型$q$的查询数量为$\sum_d \sum_q x_{d,m} \cdot z_{d,q} \cdot s_q$。设$A_m$为模型变体$m$的精度。我们可以得到所有类型为$q$的查询的精度为：$a_q = \sum_m A_m \cdot (\sum_d x_{d,m} \cdot z_{d,q} \cdot s_q)$。有效精度是所有被服务查询的平均精度，即$\sum_q a_q$。

MILP公式化。资源管理问题旨在找到最优的模型选择和放置$\{x_{d,m}\}^*$以及查询分配$\{y_{d,q}\}^*$，以最大化有效精度$\sum_q a_q$，同时达到一个足够高的目标服务吞吐量$\sum_d \sum_q z_{d,q}$来服务传入的查询$\{s_q\}$。该问题可以公式化为：

$$\max_{\{x_{d,m}\},\{y_{d,q}\}} \sum_{q} a_{q} \quad s.t. \text{ Constraints Eqs. 1-6}$$

求解MILP。资源管理器精确求解MILP以确定全局最优的模型分配和查询分配策略。解决MILP的时间开销不在查询服务的关键路径上，因为MILP是异步调用的。默认情况下，$s_q$被设置为需求。然而，如果需求增长到某个点，即使为每个查询类型使用最低精度的模型变体也可能无法满足吞吐量需求。在这种情况下，MILP求解器会立即报告约束不可行，然后我们通过减小$s_q$的一个小值来再次求解MILP。

吞吐能力的估计。求解MILP问题需要我们估计每个$P_{d,m,q}$，即每个模型变体在设备上对某个查询类型的吞吐能力。增加批处理大小会提高模型变体的吞吐量，但也会增加处理延迟。因此，我们首先估计每个模型变体在不违反查询延迟SLO的情况下可以使用的最大批处理大小，然后使用该批处理大小来分析吞吐能力。具体来说，我们遵循【索引36，Nexus: A GPU Cluster Engine for Accelerating DNN-Based Video Analysis，2019，SOSP】的观察，即为防止延迟超时，任何模型的最大推理延迟不应超过其延迟SLO的一半。利用这一观察，我们计算每个$(d, m, q)$对满足SLO要求的最大批处理大小。除了延迟约束，最大批处理大小还受到每个设备内存约束的限制。因此，最大允许批处理大小是以下两者中的较小值：(i) 满足SLO的最大批处理大小，(ii) 适合设备$d$内存的最大批处理大小。我们使用每个$(d, m, q)$对的最大允许批处理大小以及模型变体$m$在设备$d$上对查询类型$q$的分析延迟来计算该对的吞吐能力$P_{d,m,q}$。

$$P_{d, m, q}=\frac{\text { Maximum allowed batch size for } d, m, q}{\text { Profiled latency (seconds) }}$$

5 自适应批处理

算法核心思想。虽然资源管理器根据目标服务吞吐量做出模型分配和查询分配决策，但每个设备都有责任在不违反延迟约束的情况下服务分配给它的查询。自适应批处理根据队列状况动态确定要使用的最佳批处理大小，以最小化SLO违规。Proteus的自适应批处理算法基于两个关键思想：首先，它是一个主动算法，通过在队列中第一个查询即将违反其延迟SLO之前主动开始处理查询，确保队列中没有查询会不必要地超时；其次，它是非“功守恒”的，如果这有助于在开始批处理执行前累积更多查询，它可能会让设备暂时空闲。

算法工作流程。图3说明了该方法。假设队列中有$q$个查询，并且第一个查询将在$T_{exp}(1)$时刻过期。处理一个大小为$q+1$的批次需要$T_{process}(q+1)$的时间。我们定义$T_{max\_wait}(q+1) = T_{exp}(1) - T_{process}(q+1)$，换句话说，这是我们等待第$q+1$个查询到达的最晚时间点。如果我们还没有到达$T_{max\_wait}(q+1)$，我们就可以等待更多查询进入队列，因为我们没有违反任何查询延迟SLO的风险。在等到$T_{max\_wait}(q+1)$以填充批次的过程中，可能出现两种情况：

图3. Proteus中的自适应批处理
图3. Proteus中的自适应批处理
  • 情况1：直到$T_{max\_wait}(q+1)$也没有收到任何新查询。在这种情况下，我们将在$T_{max\_wait}(q+1)$时刻以大小为$q$的批次开始执行当前队列中的查询。因为如果在此时间之后有任何查询到达，并且我们以大小为$q+1$的批次执行，那么到批次处理完成时，队列中的第一个查询将会过期。
  • 情况2：在$T_{max\_wait}(q+1)$之前我们收到了第$q+1$个查询。在这种情况下，我们计算$T_{max\_wait}(q+2)$。请注意，$T_{max\_wait}(q+2) < T_{max\_wait}(q+1)$，因为$T_{process}(q+2) > T_{process}(q+1)$。如果我们已经过了$T_{max\_wait}(q+2)$，那就意味着我们不能再等待第$q+2$个查询了，否则我们的第一个查询将过期，所以我们以大小为$q+1$的批次执行，这不会导致任何超时，因为我们在$T_{max\_wait}(q+1)$之前执行。如果我们还没有过$T_{max\_wait}(q+2)$，那么我们就等待在队列中累积更多查询，并用$q' = q+1$重复同样的过程。

性能优势。如第6.4节所示，所提出的批处理算法性能优于被动方法（例如Clipper的AIMD批处理）以及主动的“功守恒”方法（例如Nexus的提前丢弃批处理）。

A4 实验环境

基线系统

我们选择了一系列基线系统进行对比，涵盖从完全静态到完全动态的范围。
* Clipper【索引9，Clipper: A Low-Latency Online Prediction Serving System，2017，NSDI】：一个基础性的推理服务系统，但不支持在异构集群中动态放置模型或进行精度缩放。我们实现了两个版本：Clipper-HT（高吞吐量），使用最低精度模型；Clipper-HA（高精度），使用最高精度模型。它使用AIMD（加性增加、乘性减少）启发式算法进行自适应批处理。
* Sommelier【索引17，Sommelier: Curating DNN Models for the Masses，2022，SIGMOD】：能够在单个服务器设备上建议替代模型以满足吞吐量要求，但不支持集群级别的资源分配。它被视为部分动态。我们为其扩展了我们的自适应批处理算法和MILP以进行初始模型放置。
* INFaaS【索引35，INFaaS: Automated Model-less Inference Serving，2021，USENIX ATC】：一个完全动态的基线，能动态改变模型选择和放置。它默认不进行精度缩放，而是将精度视为约束来最小化成本。我们将其调整为INFaaS-Accuracy版本，以最小化精度下降为目标，使其与Proteus直接可比。INFaaS使用贪心启发式算法进行资源分配。

表2. Proteus与基线系统功能对比
表2. Proteus与基线系统功能对比

模型与工作负载

  • 模型变体：实验中使用了多种DNN模型家族及其变体，涵盖计算机视觉（分类、目标检测）和自然语言处理（情感分析、翻译、问答）任务。模型来自ONNX Model Zoo和HuggingFace等，并统一转换为ONNX格式。为了设定合理的延迟SLO，我们以模型家族中最快变体在CPU上以最小批次大小运行的延迟的2倍作为该家族的SLO。
  • 工作负载：
    • 真实世界轨迹：使用了一个公开的Twitter轨迹【索引1，Twitter Streaming Traces，2018，https://archive.org/details/archiveteam-twitter-stream-2018-04】，该轨迹具有代表性的昼夜模式和流量尖峰。我们使用泊松过程生成秒内的查询到达间隔，并使用Zipf分布将请求分配给不同的模型家族 。
    • 合成轨迹：生成了合成轨迹来对系统进行压力测试，以评估其对宏观和微观尺度突发流量的响应。
表3. 使用的模型家族及其变体
表3. 使用的模型家族及其变体

硬件与软件配置

  • 硬件配置：实验在一个企业级推理服务系统的集群上进行，该集群包含：

    • 20台 Intel(R) Xeon(R) Gold 6126 @ 2.60GHz CPU工作节点。
    • 10台 NVIDIA GeForce GTX 1080 Ti GPU工作节点。
    • 10台 NVIDIA V100 GPU工作节点。

  • 软件配置：

    • 使用Docker容器在Kubernetes上托管模型。
    • 扩展Kubernetes实现我们的资源管理器。
    • 使用ONNX runtime执行模型，GPU使用CUDA执行提供程序，CPU使用CPU执行提供程序。
    • 使用Python接口的Gurobi来求解MILP。
    • 同时实现了一个基于Python的事件驱动模拟器，用于进行高效的深入分析。

评估指标

  • 吞吐量 (Throughput)：每秒服务的查询数（QPS）。
  • 有效精度 (Effective Accuracy)：系统成功服务的所有查询的平均精度。
  • 最大精度下降 (Maximum Accuracy Drop)：在整个轨迹中，有效精度的最大下降幅度。
  • SLO违规率 (SLO Violation Ratio)：延迟SLO违规的查询数除以总查询数。

A4 实验结果

端到端性能比较 (图4)
* 实验内容：在集群测试平台上，使用真实世界的Twitter轨迹评估Proteus和基线系统的端到端性能。
* 实验结果：
* Proteus在满足查询需求的同时，实现了最低的精度下降（最大精度下降4.85%）和最低的SLO违规率。
* 与同样进行精度缩放的INFaaS和Sommelier相比，Proteus的精度下降分别减少了2.8倍和3.2倍，SLO违规分别减少了4.3倍和2.8倍。
* 与不进行精度缩放的Clipper相比，Proteus将吞吐量提高了60%，并将SLO违规减少了10倍以上。
* Clipper-HA虽然精度最高，但SLO违规最严重；Clipper-HT则相反。INFaaS因其贪心启发式算法易陷入局部最优，在高峰期性能下降。

  • 分析结论：Proteus通过MILP实现的最优资源分配和高效的自适应批处理算法，在精度、吞吐量和SLO合规性方面均优于所有基线系统。模拟器结果与集群测试平台结果高度吻合。
图4. 端到端性能比较。在进行精度缩放的方法中，Proteus提供了最低的精度下降和最低的SLO违规率，同时满足了查询需求。与不进行缩放的方法相比，Proteus将吞吐量提高了60%，并将SLO违规减少了10倍。
图4. 端到端性能比较。在进行精度缩放的方法中，Proteus提供了最低的精度下降和最低的SLO违规率，同时满足了查询需求。与不进行缩放的方法相比，Proteus将吞吐量提高了60%，并将SLO违规减少了10倍。

突发工作负载响应 (图5)
* 实验内容：使用合成的宏观突发工作负载评估Proteus和基线系统资源分配的响应能力。
* 实验结果：
* INFaaS对需求突发的反应最快，因为它在查询服务的关键路径上进行资源分配。
* Proteus在突发开始时会经历短暂的SLO违规增加，随后其资源管理器会调整分配，通过精度缩放来满足突发需求，从而使SLO违规再次下降。
* 在调整分配后，Proteus的SLO违规和精度下降均显著低于INFaaS。

  • 分析结论：Proteus将资源分配从关键路径解耦的设计，在响应速度上略有延迟，但一旦调整完成，其性能（更低的SLO违规和更高的有效精度）远优于其他系统。
图5. 对突发工作负载的响应性比较。Proteus在最初的SLO违规峰值后调整分配，但在重新分配后提供了最低的SLO违规和精度下降。
图5. 对突发工作负载的响应性比较。Proteus在最初的SLO违规峰值后调整分配，但在重新分配后提供了最低的SLO违规和精度下降。

自适应批处理算法评估 (图6)
* 实验内容：在Proteus框架下，分别使用其自身的批处理算法、Clipper的AIMD批处理和Nexus的提前丢弃批处理，在三种不同查询到达分布（均匀、泊松、Gamma）的合成轨迹上进行比较。
* 实验结果：
* 在均匀到达的轨迹上，所有算法表现良好。
* 在具有突发性的泊松和Gamma轨迹上，Proteus的算法将SLO违规率比Nexus降低了2-3倍，比Clipper降低了3.8-4倍。

  • 分析结论：Proteus的非“功守恒”和主动式批处理方法在处理不均匀的查询到达时，比Nexus的“功守恒”方法和Clipper的被动式方法更有效，能显著减少SLO违规。
图6. Nexus和Clipper批处理与Proteus的比较。所有方法在均匀轨迹上表现良好，但Proteus在泊松和Gamma轨迹上将SLO违规减少了2-4倍。
图6. Nexus和Clipper批处理与Proteus的比较。所有方法在均匀轨迹上表现良好，但Proteus在泊松和Gamma轨迹上将SLO违规减少了2-4倍。

消融研究 (图7)
* 实验内容：通过移除Proteus的单个组件（模型放置MP、模型选择MS、自适应批处理AB、查询分配QA）来量化各组件的性能贡献。
* 实验结果：
* 移除模型选择（w/o MS）导致SLO违规率最高（0.18），因为它无法通过精度缩放来适应变化的需求。
* 移除模型放置（w/o MP）导致最大的精度下降（16%），效果与Sommelier基线相同。
* 移除自适应批处理（w/o AB）和查询分配（w/o QA）也显著损害了性能，分别导致高峰期SLO违规激增和整体SLO违规率高企（0.1）。

  • 分析结论：Proteus的每个组件——模型选择、模型放置、查询分配和自适应批处理——都是其卓越性能不可或缺的部分。模型选择对满足吞吐量和控制SLO违规至关重要，而模型放置对最大化精度至关重要。
图7. Proteus消融研究。移除模型选择导致SLO违规增加最多，而移除模型放置则使有效精度下降最严重。
图7. Proteus消融研究。移除模型选择导致SLO违规增加最多，而移除模型放置则使有效精度下降最严重。

对延迟SLO的敏感性 (图8)
* 实验内容：通过改变延迟SLO的倍数（从1倍到3.5倍），研究其对所有方法性能的影响。
* 实验结果：
* 随着SLO的增加，所有方法的SLO违规率都下降，吞吐量增加。
* Proteus在所有SLO设置下，始终保持最低的精度下降和最低的SLO违规率。

  • 分析结论：Proteus的性能在不同的SLO约束下都保持稳健和领先，显示了其方法的普适性。
图8. 改变SLO对Proteus和基线系统的影响。
图8. 改变SLO对Proteus和基线系统的影响。

性能分解 (图9)
* 实验内容：分析Proteus在Twitter轨迹上针对不同模型家族的端到端性能。
* 实验结果：
* 不同模型家族的吞吐量不同，符合工作负载的Zipf分布。
* 由于Proteus优化的是系统级的有效精度，不同模型家族的精度变化也不同。T5模型由于请求率较低，在整体优化中的权重较小，因此精度变化最大。GPT-2模型最重，只能加载到内存最大的加速器上，因此精度变化最小。
* 各模型家族的SLO违规行为相对一致，因为自适应批处理是在每个设备级别上执行的。

  • 分析结论：系统级优化可能导致不同应用间的性能差异，这引出了关于公平性的讨论。
图9. Proteus性能按模型家族分解。
图9. Proteus性能按模型家族分解。

决策开销 (图10)
* 实验内容：测量Proteus的决策开销，包括请求路由器的开销和资源管理器的开销。
* 实验结果：
* 请求路由器位于关键路径上，其路由查询的延迟小于1毫秒。
* 资源管理器中的MILP求解器是异步的，在实验配置下平均求解时间为4.2秒。
* MILP求解时间随设备数、模型变体数和查询类型数的增加而增加，但在60秒内可扩展至160个设备、450个模型变体或17个查询类型。

  • 分析结论：Proteus的决策开销很低。关键路径上的开销可忽略不计，而异步的资源分配开销在可接受范围内，能够快速适应工作负载变化。
图10. MILP相对于输入参数（d, m, q）的可扩展性
图10. MILP相对于输入参数（d, m, q）的可扩展性

A7 补充细节

本节讨论了工作的局限性和未来可能的研究方向。

可变输入大小。本工作中的模型涵盖了计算机视觉和自然语言处理等多个领域。虽然计算机视觉模型通常具有固定大小的输入，但许多自然语言模型可以处理可变大小的输入，其吞吐量可能因输入大小而异。尽管我们的MILP在计算模型变体吞吐量（$P_{d,m,q}$）时未考虑可变的输入大小，但自适应批处理确实考虑了实时的查询执行情况。然而，本工作范围并未深入探讨可变大小输入对推理服务的影响，这为未来的工作留下了空间。

公平性。本工作在系统层面考虑精度缩放。这意味着尽管大多数请求满足延迟SLO和吞吐量要求，但有时某些请求可能会比其他请求体验到更高的精度。这为将公平性作为推理服务系统优化的另一个目标打开了大门。然而，同时优化公平性和精度并非易事。系统可以通过将资源从精度下降程度较低的查询类型重新分配给精度下降程度较高的查询类型来提高公平性；然而，这会降低系统层面的整体有效精度。因此，公平性与系统范围内的有效精度之间存在权衡，这仍然是一个值得未来探索的有趣方向。

硬件扩展。在这项工作中，我们将精度缩放作为资源受限的推理服务系统中硬件扩展的替代方案。然而，对于有能力增加硬件资源的系统，精度缩放也可以与硬件扩展协同工作。由于硬件扩展涉及配置和启动新服务器，这需要时间，因此精度缩放可以在更细的时间粒度上使用，通过在等待新服务器分配期间短暂降低精度来吸收突发的意外负载。

A5 结论

我们提出了Proteus，一个利用精度缩放来处理查询工作负载变化的高吞吐量推理服务系统。我们将Proteus中的资源管理问题公式化为一个混合整数线性规划优化问题，以适应宏观尺度的变化，并通过求解它来保证最优解。我们还提出了一种新颖的自适应批处理算法，以提高吞吐量并吸收微观尺度的变化。我们在真实世界的工作负载轨迹上对Proteus进行了评估，结果表明，它在减少SLO违规和提高系统吞吐量方面优于最先进的基线系统，同时将精度下降降至最低。