机器学习正在越来越多的应用程序中进行部署这些应用程序需要在繁重的查询负载下进行实时，准确和可靠的预测 但是，大多数机器学习框架和系统仅针对模型训练洏非部署

  在本文中，我们介绍了Clipper一种通用的低延迟预测服务系统。Clipper介绍了最终用户应用程序和各种机器学习框架它引入了模块化架構，以简化跨框架和应用程序的模型部署此外，通过引入缓存批处理和自适应模型选择技术，Clipper可以减少预测延迟并提高预测吞吐量准确性和健壮性，而无需修改底层机器学习框架我们在四个常见的机器学习基准数据集上评估Clipper
并展示其满足在线服务应用程序的延迟，准确性和吞吐量需求的能力最后，我们将Clipper与Tensorflow服务系统进行比较并证明我们能够实现可比的吞吐量和延迟，同时使模型组合和在线学习能够提高准确性并提供更可靠的预测

    在过去的几年中，机器学习驱动的应用程序爆炸式增长包括推荐系统[28,60]，语音助理[18,26,55]和广告定位[3,27]这些应用程序依赖于机器学习的两个阶段：训练和预测。 训练是根据数据（例如电影评级）构建模型的过程。推断是使用模型在给定输入嘚情况下进行预测的过程（例如预测用户对电影的评级）。虽然训练通常在计算上很昂贵但需要多次通过潜在的大型数据集，因此通瑺认为推断是便宜的 相反，尽管培训需要数小时到数天才能完成但推理必须实时进行，通常比培训期间的查询数量级多并且通常是媔向用户的应用程序的一部分。例如考虑想要部署内容推荐服务以个性化内容呈现的在线新闻组织。理想情况下该服务应该能够以交互延迟（<100ms）[64]推荐文章，扩展到庞大且不断增长的用户群体维持突发新闻驱动的闪光人群的吞吐量需求，并作为新闻提供准确的预测 周期囷读者兴趣的演变

    开发这些服务的挑战在训练和预测阶段之间存在差异。 在培训方面开发人员必须从一系列令人眼花缭乱的机器学习框架中进行选择，这些框架具有不同的API模型，算法和硬件要求此外，随着新的更精确的技术的发展，他们可能经常需要在模型和框架之间进行迁移 一旦经过训练，必须将模型部署到预测服务系统以提供大规模的低延迟预测。

    与由复杂的基础设施理论和系统支持嘚模型开发不同，模型部署和预测服务受到的关注相对较少开发人员必须拼凑来自各种系统组件的必要部分，并且必须在多个不断发展嘚框架中集成和支持预测同时满足对可扩展性和响应性不断增长的需求。 因此机器学习服务的部署，优化和维护很困难且容易出错

    為了应对这些挑战，我们提出了Clipper一种分层架构系统（图1），可降低实现预测服务堆栈的复杂性并实现预测服务系统的三个关键属性：低延迟，高吞吐量和更高的准确性

Clipper分为两层：（1）模型抽象层，（2）模型选择层 第一层公开了一个通用API，它抽象出现有ML框架和模型的異构性因此，可以透明地修改或交换模型到应用程序模型选择层位于模型抽象层之上，并在竞争模型之间动态选择和组合预测以提供更准确和稳健的预测。

    为了实现低延迟高吞吐量预测，Clipper实现了一系列优化 在模型抽象层中，Clipper以permodel为基础缓存预测并实现自适应批处悝，以在给定查询延迟目标的情况下最大化吞吐量 在模型选择层中，Clipper实现了提高预测准确性和延迟的技术为了提高准确性，Clipper利用强盗囷集合方法来稳健地选择和组合来自多个模型的预测并估计预测不确定性 此外，Clipper能够为每个用户或会话独立调整模型选择为了改善延遲，模型选择层采用了一种拖延缓解技术来渲染预测而无需等待慢速模型。 由于这种分层设计最终用户应用程序和底层机器学习框架嘟不需要进行修改以利用这些优化。

    我们使用四个常见的机器学习基准数据集评估Clipper并证明Clipper能够呈现低和有限的延迟预测（<20ms），甚至跨机器扩展到许多部署模型快速选择和调整最佳模型组合，并动态交易 在严重查询负载下的精度和延迟我们将Clipper与Google TensorFlow服务系统[59]进行了比较，这昰一个与TensorFlow培训框架紧密集成的工业级预测服务系统 我们证明了Clipper的模块化设计和广泛的功能可以降低性能成本，实现与TensorFlow服务相当的预测吞吐量和延迟同时支持更多功能。总之我们的主要贡献是：

• 一种分层体系结构，它抽象出与在现有机器学习框架中提供预测相关的复杂性
• 一组新技术用于减少和限制延迟，同时最大化跨机器学习框架的吞吐量
• 模型选择层支持在线模型选择和组合，为交互式应用程序提供强大而准确的预测

    机器学习生命周期（图2）可分为两个不同的阶段：训练和测试 训练是根据数据估算模型的过程。 训练通常在计算上佷昂贵需要多次通过大型数据集，并且可能需要数小时甚至数天才能完成[11,29,41] 机器学习系统的大部分创新都集中在模型培训上，开发了Apache Spark

    已經开发了各种机器学习框架来应对训练的挑战 许多人专注于特定的模型，如用于深度学习的TensorFlow [1]或用于大型线性模型的Vowpal Wabbit [34] 其他专门针对特定應用领域，如用于计算机视觉的Caffe [31]或用于语音识别的HTK [63] 通常，这些框架利用并行和分布式系统的进步来扩展训练过程

    预测是评估模型以呈現预测的过程。与训练相反预测不涉及复杂的迭代算法，因此通常被认为是容易的 因此，很少有研究推理过程的研究大多数机器学習框架只提供基本支持用于离线批量推断 - 通常具有评估模型训练算法的单一目标。然而可扩展，准确和可靠的推理提出了基本的系统挑戰随着机器学习采用的增加，这些挑战可能会主导训练的挑战在本文中，我们关注的是较少的学习但越来越重要的预测的挑战

为了說明推理的挑战并提供评估Clipper的基准，我们描述了机器学习的两个规范的现实应用：目标识别和语音识别

 深度学习的进步促进了计算机视覺的快速进步，特别是在物体识别问题中 - 识别和标记图像中的对象的任务 物体识别模型是许多计算机视觉应用中的重要组成部分，从图潒搜索到自动驾驶汽车当用户与这些应用程序交互时，他们通过明确地标记图像（例如在图像中标记用户）或者通过指示所提供的预測是否正确（例如，点击建议的图像）来提供关于预测准确性的反馈 在搜索中）。 快速纳入这些反馈对于消除失败的模型和为用户提供哽个性化的体验至关重要

    我们使用经过充分研究的MNIST [35]，CIFAR-10 [32]和ImageNet [49]数据集来评估越来越困难的物体识别任务以及相应更大的输入 对于每个数据集，预测任务需要基于其像素值识别图像的正确标签 MNIST是用于展示新算法或技术潜力的常见基线数据集，深度学习和更经典的机器学习模型茬MNIST上表现良好 另一方面，对于CIFAR-10和Imagenet深度学习明显优于其他方法。 通过使用三个不同的数据集我们在为具有各种计算要求和精度的模型提供服务时评估Clipper的性能。

机器学习的另一个成功应用是自动语音识别 语音识别模型是从口述音频信号到相应的词序列的功能。 语音识别模型可能相对较大[10]并且通常由使用专门语音识别框架（例如，HTK [63]）训练的许多复杂子模型组成 语音识别模型通常也针对个人用户进行个性化以适应方言和口音的变化。在大多数应用程序中推断是在用户说话时在线完成的。 提供实时预测对于用户体验至关重要[4]并支持实時翻译等新应用[56]。 然而语音模型中的推断可能是昂贵的[10]，需要在卷积神经网络中评估大张量积

    当用户与语音服务交互时，它们提供关於语音预测质量的隐含信号其可用于识别方言。 通过允许我们选择专门针对用户方言的模型结合此反馈可以快速改善用户体验。

    为了評估个性化和在线模型选择对具有真实用户数据的数据集的好处我们构建了语音识别服务TIMIT语音语料库[24]和HTK [63]机器学习框架。 该数据集由八个渶语八种方言的630个发言者组成 我们从测试语料库中随机抽取用户，并使用他们预先录制的语音数据模拟他们与我们的语音识别服务的交互

在上述应用的推动下，我们概述了关键预测的挑战并描述了Clipper如何应对这些挑战。

有越来越多的机器学习框架[1,7,13,16,31] 每个框架都经过精心設计和设计，以支持特定的模型或应用领域（例如计算机视觉）。 因此没有主导框架，并且通常可以将多个框架用于单个应用（例如自动字幕中的语音识别和计算机视觉）。 此外机器学习是一个迭代过程，并且随着应用程序随着时间的推移而发展最佳框架可能会發生变化（例如，随着训练数据集的增长需要进行分布式模型训练）。尽管已经提出了通用的模型交换格式[47,48]但由于最先进技术的快速囷根本性变化以及用于训练和服务的并行实现的其他错误来源，它们从未实施过 最后，机器学习框架通常由机器学习专家开发并用于机器学习专家 作为这些决策的结果，正在开发和实施多个机器学习框架的过程

Solution:Clipper引入了模型抽象层和通用预测接口，将应用程序与可变性隔离到机器学习框架（第4节）并简化了将新模型或框架部署到正在运行的应用程序的过程。

预测延迟是呈现预测所花费的时间 由于预測是一个关键途径，因此预测必须几乎并且具有约束延迟以满足服务水平目标[64] 虽然简单的线性模型更多，更复杂且通常更精确的模型被鼡作支持机器随机森林和深度神经网络计算密集程度更高，并且可能具有大量延迟（50-100ms）[13]（见图11详细信息）在许多情况下，可以通过以犧牲者为代价并增加尾部延迟来组合模型来改进 最后，大多数机器学习框架针对离线批处理而非单输入预测延迟进行了优化

此外，低延迟和有限延迟需求通常与机器学习框架的设计目标不一致复杂模型的计算成本可显着影响预测吞吐量。 例如比现代Web服务器慢的相对短期网络。 批处理预测请求可以显着提高吞吐量利用优化的BLAS库SIMD指令和GPU加速，它还可能对预测延迟产生不利影响 最后，在重负载下通瑺优选的是略微降低准确度而不是显着增加延迟或松散可用性[3,23]。

Clipper自动并自适应地批量预测请求以最大限度地在机器学习框架中使用面向批处理的系统优化，同时确保仍然满足预测延迟目标（§4.3） 此外，Clipper采用了散乱缓解措施减少和限制尾部延迟的技术使模型能够在不影響服务延迟的情况下试验复杂模型（第5.2.2节）。

模型开发是一个迭代过程产生许多模型，展示不同的特征表示建模假设和机器学习框架。 一些开发人员必须根据使用数字数据集的离线评估来决定部署哪些模型或者参与昂贵的在线A / B测试。 谈到未来的知识它可以被视为基於内容的工具。 或者A / B测试技术[2]已被证明在统计上是低效的 - 要求数据在候选模型的数量中呈指数增长。由此产生的模型选择是静态的因此很容易受到因素影响的模型性能的变化。 在一些情况下最佳模型可以在发起查询的上下文（例如，用户或区域）中不同 最后，来自哆个模型的预测通常可以组合成集合以提高预测准确性并提供具有置信界限的更稳健的预测

Clipper利用自适应在线模型选择和集合技术来交配反馈，并自动选择和组合跨越多个机器学习框架的模型的预测

因为我们在介绍它们时包含许多Clipper功能的微量标记，所以我们现在提供实验設置 对于三个对象识别基准中的每一个，预测任务是预测给予未标记图像的原始像素的正确标签作为输入 我们在每个对象识别基准测試中使用各种模型。对于语音识别基准预测任务是预测原始音频信号的语音转录。 对于这个基准测试我们使用HTK语音识别工具包[63]来学习隱藏马尔可夫模型的输出是语音，代表声音的转录 表1列出了每个数据集的详细信息。

对于每个网络所有服务器都位于同一交换机上。 兩种网络配置都进行了调查

Clipper分为模型选择和模型抽象层（见图1）。 模型抽象层负责提供通用预测接口确保资源隔离，并优化面向批处悝的机器学习框架的查询工作负载 模型选择层负责调度和评估预测。

在介绍详细的Clipper系统之前我们首先描述对系统的请求。应用程序通過面向REST或RPC API的应用程序向Clipper发出预测请求 预测请求首先由模型选择层处理。 模型抽象层基于预测请求和最近反馈的属性

在将查询分配给与所需模型相关联的自适应批处理队列之前，模型抽象层首先检查预测高速缓存的查询 自适应批处理队列构造针对机器学习框架和模型调整的批量查询。跨语言RPC用于将模型批量查询发送到模型容器中将模型发送到其本机机器学习框架中。为了简化部署我们将每个模型容器分开托管Docker容器。 在对一批查询评估模型之后将预测发送回模型抽象层，模型抽象层填充预测缓存并将结果返回到模型选择层

然后，模型选择层将一个或多个预测组合成最终预测和置信估计 预测和置信度估计被返回给最终用户应用程序。这同样适用于通过相同的面向應用程序的REST / RPC接口的模型选择层 模型选择层将此反馈与相应的预测结合起来以改进它并选择未来的预测。 我们现在更详细地介绍模型抽象層和模型选择层

模型抽象层（图1）提供了跨机器学习框架的通用接口。 它由预测缓存自适应查询匹配组件和一组通过轻量级RPC系统连接箌Clipper的模型容器组成。模块化体系结构使缓存和批处理机制能够跨框架共享同时还可扩展到许多并发模型并简化新框架的添加。

模型抽象層的顶部是预测缓存（第4.2节） 预测高速缓存为频繁查询提供了部分预实现机制，并通过在最近的预测和反馈之间实现有效连接来加速第5節中描述的自适应模型选择技术

批处理组件（第4.3节）位于预测缓存之下，并将点查询聚合为为每个模型容器动态调整大小的小批量以朂大化吞吐量。 一旦构建了小批量就通过RPC系统将其发送到容器进行评估。

部署在Clipper中的模型每个都封装在它们自己的轻量级容器（第4.4节）Φ与Clipper通信到RPC机制，为Clipper提供统一的接口并简化新模型的部署 轻量级RPC系统最大限度地减少了基于容器的体系结构的开销，并简化了跨语言集成

在以下部分中，我们将更详细地描述这些组件中的每一个并讨论与每个组件相关的一些关键算法创新。

对于许多应用（例如内嫆推荐），经常请求关于流行项目的预测 通过维护预测缓存，Clipper可以在不评估模型的情况下提供这些查询 通过消除模型评估的额外成本，这大大减少了延迟和系统负载此外，Clipper中的缓存在模型选择中起着重要作用（§5） 要智能地选择模型，Clipper需要加入原始预测 [39]，即使不瑺见或独特的查询也可以从缓存中受益

例如，即使是四个模型的小型组合预测缓存使Clipper中的反馈处理吞吐量从每秒大约6K到11K的观测值增加叻1.6倍。

预测缓存充当通用预测函数的函数缓存：

将模型与查询x一起计算并计算相应的模型预测y 缓存公开了一个简单的非阻塞请求和提取API。 当需要预测时调用请求函数，其通知高速缓存计算预测条目是否在缓存中 fetch函数检查缓存并返回查询结果（如果存在）。

Clipper采用LRU的驱逐筞略进行预测缓存使用标准的CLOCK [17]缓存逐出算法。 使用足够大小的缓存它不希望被驱逐，缓存充当热门项目的部分预实现机制 但是，由於自适应模型选择发生在Clipper中的缓存之上因模型选择导致的预测更改不会使缓存条目无效。

Clipper批处理组件转换由机器学习框架接收的并发预測查询流同时分摊RPC和系统开销。 批处理可以提高吞吐量和利用通常代价高昂的物理资源（如GPU）的利用率但这需要付出代价在批处理中唍成单个预测。

延迟服务级别目标（SLO）以增加延迟以换取显着提高的吞吐量 延迟交互式应用程序的延迟要求。 例如
以足够大的批量请求预测可以将吞吐量提高到26x（图4中的Scikit-Learn SVM），同时满足20ms的延迟SLO

批处理通过两种机制增加吞吐量。 首先将RPC调用和内部框架开销的成本批量复淛为将内存复制到GPU内存。 其次批处理使机器学习框架能够通过同时对许多输入执行批量推断来利用现有的数据并行优化（例如，通过使鼡GPU或BLAS加速）

当模型选择层调度用于模型评估的查询时，它们被放置在与模型容器相关联的队列上 每个模型容器都有自己的自适应批处悝队列，调整到该容器的延迟配置文件和相应的线程来处理预测 通过从队列中删除尽可能多的查询到该模型容器的最大批量大小并将查詢作为单个批量预测发送，批量处理预测 批处理中的第一个查询。

利用GPU加速的框架寻求TensorFlow通常在模型的评估中强制执行一致的数据集 这些框架通常将批量大小直接编码到模型定义中，以便充分利用GPU并行性 当渲染的预测少于批量大小时，输入量将减少到定义的大小从而降低模型吞吐量，而不会改善预测延迟 应该仔细调整批量大小以最大化推理性能，但是这种调整必须离线完成并且在部署模型时得到修複

但是，大多数机器学习框架都可以有效在交付时处理可变大小的批次框架实现与模型和推理算法的选择之间的差异可导致模型吞吐量和延迟的数量级变化。 因此延迟概况 - 评估给定数量批次的预期时间。 例如在图3中，SLM在线性SVM和执行序列的内核SVM之间相差241倍线性SVM执行非常简单的矢量矢量乘法以执行推理。 用于评估内核的最近邻计算因此，线性SVM可以实现近30,000 qps的吞吐量而内核SVM在此SLO下限制为200 qps。 Clipper不需要应用程序开发人员手动调整每个新模型的批量大小而是采用简单的自适应批处理方案来动态查找和调整最大批量大小。

我们将最佳批量大小萣义为批量大小以最大化吞吐量，使批量评估等待时间低于目标SLO 为了自动找到我们采用的添加 - 增加 - 乘法减少（AIMD）方案的每个模型容器嘚最佳批量大小。 在此方案下我们将批量大小增加一个固定的数量，直到处理延迟 此时，我们执行小的乘法补偿将批量大小减少10％。 添加剂增加乘法 - 减少方案[15]。

早期的性能测量（图3）表明在几个建模框架中，批量大小和延迟之间存在稳定的线性关系因此，我们探索了使用分位数回归来估计作为批量大小函数的第99百分位数（P99）潜伏期并相应地设置最大批量大小。图4中的Spark和Scikit-Learn模型这两种策略相比於无批处理的基线策略提供了显着的性能改进，在scikit-learn的情况下吞吐量增加了线性SVM，展示了批处理提供的性能提升虽然两种批处理策略几乎完全相同，但AIMD方案更简单更容易调整。此外AIMD策略的持续适应使得其对于模型的吞吐量容量的改变（例如，在Spark中的垃圾收集中断期间）是稳健的因此，Clipper采用AIMD方案作为默认方案

在中等或突发加载时，当准备分派下一批时批处理队列可能包含的查询少于最大批量大小。 对于某些模型短暂延迟调度以允许更多查询到达可以显着提高突发负载下的吞吐量。 类似于Nagle算法的动机[44]效率的提高是发送批次的固萣成本与增加批量大小的可变成本之比的结果。在图5中我们比较了两种模型的延迟批量效率增益（以增加的吞吐量衡量）。 延迟批处理鈈会增加Spark SVM的吞吐量因为Spark在处理小批量时已经相对有效，并且可以使用远小于最佳批量大小的批次来跟上中等服务工作量 相比之下，Scikit-Learn SVM处悝批处理的固定成本较高但是使用BLAS库可以同时对许多输入进行有效的并行推理。 因此2ms批处理延迟可使吞吐量提高3.3倍，并使Scikit-Learn模型容器能夠满足吞吐量需求同时远低于交互式应用程序所需的10-20ms延迟目标。

模型容器在统一的“窄腰”远程预测API中封装了机器学习框架和模型实现嘚多样性 要向Clipper添加新类型的模型，模型构建器只需要实现清单1中的标准批量预测接口.Clipper包含特定于语言的容器C ++Java和Python的绑定。 本文中大多数模型的模型容器实现只需要几行代码

为了实现进程隔离，每个模型都在一个单独的Docker容器中进行管理 通过将模型放置在单独的容器中，峩们确保相对不成熟的最先进的机器学习框架的性能和稳定性的可变性不会干扰Clipper的整体可用性 与模型相关联的任何状态（例如模型参数）在初始化期间提供给容器，并且容器本身在初始化之后是无状态的 结果，资源密集型机器学习框架可以在多台机器上复制或者在需偠时可以访问专用硬件（例如，GPU）以满足服务需求

Clipper支持在本地和群集中复制模型容器，以提高预测吞吐量并利用其他硬件加速器 由于鈈同的副本可能具有不同的性能特征，特别是在跨群集传播时Clipper会为每个副本独立执行自适应批处理。

在图6中我们演示了Clipper可以通过在集群中复制模型容器来实现的线性吞吐量扩展。通过10Gbps以太网交换机连接四节点GPU集群当使用在不同机器上运行的四个副本时，使用在本地GPU上運行的单个模型容器时Clipper从19,500 qps增加3.95倍吞吐量增加到77,000 qps。由于此实验中的模型容器是计算密集型并且在GPU上运行因此GPU吞吐量是瓶颈，而Clipper的RPC系统可鉯轻松地使GPU饱和但是，当集群通过1Gbps交换机连接GPU的总吞吐量高于1Gbps，因此在复制到第二台远程机器时网络变得饱和随着机器学习应用程序开始消耗越来越大的输入，从手工制作的功能扩展到大型图像音频信号，甚至
视频网络将继续成为扩展预测服务应用程序的瓶颈。這表明需要研究有效的网络策略以便对大量输入进行远程预测。

模型选择层使用反馈来动态选择一个或多个部署的模型并组合它们的輸出以提供更准确和稳健的预测。 通过允许同时部署许多候选模型并依靠反馈来自适应地确定最佳模型或模型组合模型选择层简化了新模型的部署过程。 通过在应用程序的整个生命周期中不断学习反馈模型选择层可自动补偿失败的模型而无需人为干预。 通过组合来自多個模型的预测模型选择层提高了应用精度并估计了预测置信度。模型选择和组合有很多种技术可以跨越计算开销和应用精度的权衡空间 但是，大多数这些技术都可以通过简单的选择组合和观察API来表达。 我们在模型选择策略接口（清单2）中捕获此API该接口控制模型选择層的行为，并允许用户自己引入新的模型选择技术

模型选择策略（清单2）定义了四个必要条件功能以及一些基本类型。 除了查询和预测類型X和Y之外状态类型还对选择算法的学习状态进行了编码。 init函数返回选择策略状态的初始实例 我们隔离选择策略状态并要求初始化函數以有效地启用Clipper
为精细化的上下文模型选择（第5.3节）实例化选择策略的许多实例。 选择和组合功能负责选择要查询的模型以及如何组合结果 此外，组合功能可以计算有关预测的其他信息 例如，在§5.2.1中我们利用组合函数来提供预测置信度分数。 最后observe函数用于根据前端應用程序的反馈更新状态。

在Clipper的当前实现中我们提供了两种基于Auer等人开发的鲁棒强盗算法的通用模型选择策略。[6] 这些算法跨越了计算開销和准确性之间的权衡。 单一模型选择策略（第5.1节）利用Exp3算法以最小的计算开销基于噪声反馈最佳地选择最佳模型集合模型选择策略（第5.2节）基于Exp4算法，该算法自适应地组合预测以提高预测准确性并以评估每个查询的所有模型为代价增加计算成本来估计置信度通过实現提供不同的模型选择策略 成本 - 精度权衡，以及用户实施自己的策略的APIClipper提供了一种机制，可以在每个应用程序的基础上轻松导航精度和計算成本之间的权衡此外，随着应用程序工作负载的发展和资源或多或少受到限制用户可以随着时间的推移修改此选择。