目前依赖机器学习的推理服务的应用的数量已经相当的大且正在不断的增长，例如Facebook应用程序每天发出数十万亿次具有不同的性能、准确性和成本限制的推理查询。然而，目前的推理服务系统的易用性和效益都难以让人满意，应用的开发者需要自行决定这些推理查询的需求和限制，并与推理系统使用的模型、采用的硬件架构等进行匹配，使得推理系统能够满足自己的需求。由于应用程序负载的变化、应用程序的演变、可用资源的变化等原因，这些交互性决策是难以人为决定的
如果我们期望有更多的应用可以应用上推理服务，则我们必须将影响性能、准确性和成本限制的系统决策自动化，使得模型、硬件资源分配等决策不需要用户自己决定，简化系统的使用。本文定义和提出了托管和无模型推理服务的案例，确定并讨论了实现这一愿景的开放研究方向
目前，需要利用机器学习模型的预测功能的应用已经逐渐增加，例如利用深度神经网络进行图像识别、语音分析、自然语言处理等。这种神经网络的训练主要分为两个阶段：训练和推理。目前而言，在加速算法收敛方面的研究已经相当的多，成果已经较为成熟，且在产业界已经有许多利用数据集训练模型的框架，如TensorFlow、PyTorch等。训练花费的时间比较长(几小时乃至几天)，但一旦模型训练完成，它就可以被用于推理阶段，供终端用户发出查询请求
在模型训练已经有比较丰硕的成果下，模型推理服务的实现仍旧是具有挑战性的，因为推理服务需要与延迟、开销等因素联系在一起。本文重点讨论了在资源管理方面使推理服务具有挑战性的四个问题，包括了
-
Diverse requirements(需求多样性)：
应用的推理请求往往具有众多的精确度、开销和延迟等的需求。例如推荐和投放广告的请求具有严格的延迟限制，但是可以相对降低预测的准确度。相比之下，语音识别需要更高的准确度，但是可以相对放宽延迟限制。应用的请求数量、在线/离线请求、请求模式变更等众多因素，都需要系统进行资源的动态调整，以适应这些难以预测的需求和请求变化，这使得服务系统的设计非常具有挑战性
-
Model-variants(模型变体)：
功能和需求的多样性导致了对不同模型的需求以及产生多种模型变体(模型变体指的是通过不同的训练方法、不同的参数等训练出来的具有相同架构的模型)。例如一个教师模型相比一个学生模型，其精确度更高，但需要更大的内存和更长的推理时间。不同的模型、不同的模型变体的推理结果会有不同的精确性、时延、资源利用情况等，其适用的功能也有所不同。因此，我们期望模型推理系统能够根据用户需求自行选择合适的模型和模型变体，使得用户只需要关注于请求的发出，而忽略底层的详细设计
-
Heterogeneous execution environments(异构运行环境)：
多样化的硬件是满足多样化需求的重要方法。不同的硬件和硬件加速器，如CPU、GPU、TPU等，具有不同的开销和性能。例如，对于一个大型的请求批处理作业，GPU相比CPU有更好地性能，但它需要更多的开销以及更长的模型加载时间。合理地选择异构运行部件，能够更好地满足各种需求
-
Dynamic changes in application load and compute environments(负载和计算环境的变化)：
模型变体和底层计算环境的选择由于应用负载的时刻变化以及计算环境的变换变得更加复杂。根据模型的状态以及应用负载的变更，资源管理的决策需要时刻变更
就目前而言，尽管以及在推理服务上做了许多研究，仍然没有一个系统能够真正做到易于使用且具有成本效益。已有的系统或是需要用户自行设置和管理资源，或是需要用户在使用的硬件资源、使用的模型变体等重大决策上做出自己的决定。部分系统为了满足用户在性能上的需求，通过预分配的方式给用户预留资源，以便及时运行推理任务，这导致了大量的资源浪费，且在出现负载尖峰时不具备可扩展性。鉴于这些目前存在的问题，本文旨在提出一个managed and model-less inference serving system的愿景，描述该系统应具备的功能，包括自动化根据用户需求决定异构资源和模型变体的使用，调整系统资源的分配(managed特性)，并提供一个易于使用的用户接口，使用户可以不需要考虑模型变体等决策(model-less特性)。该系统期望能够简化用户的使用，并能够节省提供者和用户的开销。
本节旨在指出现有的推理服务解决方案与用户的期望之间的差距
-
Selecting a model-variant(选择合适的模型变体)：
问题：不同模型在精确度、推理延时、吞吐量和资源利用率等指标上有所不同。由于存在不同的性能需求，需要选择合适的模型来满足用户需要。但即使选择了一个模型，其模型变体依然是需要考虑的问题，因为同一模型的不同模型变体在性能指标上也有所不同(文中举了一个ResNet50的例子，ResNet50的大小为64的批处理优化版本比大小为1的批处理优化版本有更高的吞吐量，但是其内存占用和时延较差，且使用了低精度的优化版本能具有更低的时延和更高的吞吐量)
目前的解决方案：将同一个请求发送给不同的模型变体处理，忽略了模型变体的选择，但是浪费了计算资源和增加了通信开销。部分系统还要求用户自行选择模型变体进行请求处理
用户期望：模型变体的选择能够被隐藏，只对用户暴露出一个易用的API，使得用户能够清晰且简便地表达自己在性能和开销上的需求
-
Heterogeneous hardware architectures(异构的硬件架构)：
问题：目前，各厂商已经为ML推出了多种适用于ML的硬件，如GPU、TPU等。对硬件的选择以及对某一硬件采用的精度的选择等，会影响推理服务的延迟、精确度、资源利用等。例如，相比于CPU服务器，NVIDIA Tesla V100 GPU在批处理上能提供47×的吞吐量，而Xilinx U250 FPGA在非批处理推理服务上降低了20×的延时。文中也对比了GPU和CPU在不同模型和batch大小上的加载延时和计算延时，发现对于不同的模型，batch的变化对性能的影响情况不同，且两者在batch大小上的性能边界也不同。因此，不同模型的加载和推理时延依赖于底层使用的硬件，并随batch大小的变化而改变。此外，由于存在编译技术能够优化不同底层硬件的推理延时，且优化模型也有适用于不同batch大小和精度的变体，使得选择最优的底层硬件，选择采用的batch大小和精度等参数，选择具有合适优化版本的模型变体变得非常复杂(本小节不仅对硬件的选择做出了要求，还期望硬件能与模型变体具有协同，个人推测是先确定模型变体再决定底层硬件)
目前的解决方案：多数已存在的系统通过确定一个目标硬件以及使用默认的模型变体，对外提供模型推理服务，这种系统直接忽略了应用在模型推理服务方面的需求，主要目的在于简化系统的设计。部分系统使用默认的模型变体，并允许动态地修改batch大小。由于请求的batching操作会带来排队延时，这种系统可能会出现违背SLO准则的问题
用户期望：底层硬件的选择能够被隐藏，系统能够自行根据用户通过API传达的需求选择合适的硬件类型进行请求处理
-
Varying load and query patterns(可变的负载和查询模式)：
问题背景：由于应用的不同(不同应用性能、开销等的要求不同)以及其查询模式(昼夜模式)的不同，引发了多样的负载情况和查询模式，对供应商提出了不同的需求。例如，延时敏感型应用只需要小部分的资源和少量的运行时间，但是要求快速的应答；吞吐密集型应用需要大量的资源和运行时间，且可能扩展到不同的机器上处理
问题描述：可变负载和查询模式给我们带来了几个值得探讨的问题
- 负载和查询模式的动态变化，为我们的资源分配提出了要求，期望系统能够在保持处理已发出的请求的性能下，能够动态进行资源的分配来应对不同的请求尖峰(如何动态调整资源)
- 目前的许多云提供商为用户分别提供了延时敏感型、吞吐密集型等满足不同需求的服务，要求用户自行配置服务以满足自身需求。然而，我们希望能够简化用户的操作，使得用户不需要关心资源分配等问题，由系统自动进行调节(降低用户的使用门槛，往往与第一个问题相结合)
- 资源利用率也是非常值得关注的问题。目前，一个普遍的资源分配的解决方案是为每个用户预留出需要的资源和模型实例，供用户进行模型推理。然而，这种方法造成了很低的资源利用率，并增加了管理的开销(需要为用户划分边界)，且可扩展性很差。我们希望能够将实例进行多路复用(单个实例能处理不同请求)，并在单GPU上同时运行多个实例(实例共享资源)，从而大幅度提升资源的利用率。这种方案经过调查是可行的，作者通过使用GPU和CPU的组合，并进行了多路复用和多实例共享GPU资源，使得开销远小于单CPU、Lambda等供应方式。然而，资源共享也给我们带来了问题，即在同一GPU中的不同实例，它们处理的负载大小不同，需要的内存大小也不同，如何在同一GPU中协调资源分配。同时，多路复用也要求我们能够将某个模型实例在多个用户中共享
将上述几个问题进行总结，就获得了最终的用户期望：资源的管理和分配应当与用户操作分离，由系统根据性能需求和负载情况进行动态调整。为了降低开销和资源利用率，系统应当做到(1)不同模型实例共享资源(2)不同用户能共享同个模型实例副本(3)基于观察到的负载进行模型复制和驱逐，执行内存管理和分配(即对于负载高的模型应当增加副本，负载低的应减少副本)
-
Start-up latency(冷启动时延)：
问题：冷启动时延指的是将一个模型变体加载到一个特定的硬件平台上所花费的时间。与VM、容器等的可预测的启动时延不同，模型变体的加载时延往往依赖于硬件资源、系统状态、加载的框架等，是难以预测的。冷启动时延不仅出现在实例复制的过程，还与新模型的加载有关。冷启动时延与性能和开销等息息相关，例如在出现请求尖峰时，新实例的冷启动时延往往造成了短时间内请求处理时延达不到要求的情况。减轻冷启动时延带来的影响是我们必须考虑的问题
目前的解决方案：一个普遍的解决方案是预加载后直接通过维持已加载的模型，使模型实例始终处于运行的状态，从而避免请求到来时需要冷启动。然而，这种方法会带来巨大的开销，且在出现请求尖峰时依然需要冷启动新的实例处理，造成较高的延迟
用户期望：模型冷启动的时延(模型加载到硬件存储中，或构建优化的模型变体带来的延时)应当被透明地处理，且为了防止资源利用率低下，提供者不应当持续保持模型变体运行
根据上一节描述的用户期望，模型推理系统应当能够做到易于用户使用，且对于用户和供应商而言都是具备成本效益的，这样的系统的特点被总结为managed和model-less。在理想的模型推理系统的帮助下，用户只需要向推理系统发送相应的预测请求(如图像识别请求)，并说明可选的SLO约束(如90%的请求能够在200ms内响应)，即可获得推理服务。而推理系统将自动化完成其余工作，包括模型变体和硬件选择、模型变体生产、负载感知的自适应扩展、错误容忍、资源监控、日志记录等
论文其余部分描述了多个可行的研究方向
-
Automatic model-variant and hardware selection：
由于我们的需求在于使用户不需要考虑硬件、模型变体的选择，因此一个好的解决方案在于，对一个提交了的模型(模型设计出来就决定了它是用于做nlp或是图像识别等，模型变体是在这个功能的基础上具有不同的性能等)，模型推理系统能够自动化生成该模型的多个变体，用于满足不同的需求。具有不同性能、开销的模型变体可以由多种方法生成，如利用模型压缩或知识蒸馏对已有模型进行修改、采用编译器对已训练好的模型进行优化、用不同的框架训练模型
模型变体的选择对资源消耗和开销有重大的影响。我们在基于对模型变体的特点的了解下，将其与合适的底层硬件映射在一起，构成能够满足某种特定需求的二元组，并根据服务的需求选择合适的二元组提供推理服务。另外，对模型变体的精确度的考量也是需要解决的问题。这可能可以通过要求用户向系统提交一组具有代表性的测试数据的方式，或者获取查询结果的反馈，进行推理精确度的考察
-
Dynamic placement of inference queries：
由于模型和资源的状态可能会动态改变，某一类的请求(需求相同)不会一直被提交到同一个(模型变体,硬件)二元组，而是根据模型变体状态的修改和资源的可用性等进行动态变化。对于一个新进入的请求，我们可能会构建新的模型变体、加载已有的模型变体、或使用正在运行的模型变体，对其进行处理。为了使请求能够被提交到最合适的环境中处理，保障其在性能和开销上的需求，我们必须考虑模型和资源的动态变化，斟酌请求的placement问题(例如，延时敏感的请求我们倾向于将其放置在正在运行的模型变体上，而离线请求我们更倾向于构建最优模型变体供其运行)
个人对这点的理解是，某一类型的请求在最初被映射到某个处理环境时，不能建立简单的哈希映射，使所有这类请求都发送到同个处理环境，而是应该时刻监控资源和模型变体状态，并对每个新加入的请求重新进行映射的考虑
-
Proactive start-up optimization：
根据我们的提交策略，我们可能需要加载模型，启动额外的资源进行请求处理，或是卸载模型，令更多资源变得可用。加载模型乃至构建模型，往往带来了冷启动延迟(卸载模型可能不会引入延迟)，影响请求的处理。因此，如何去减轻冷启动延时带来的影响，是我们值得关注的问题。受已有的文献的启发，应当采用主动进行优化的方式，如设置触发器在资源利用率较高时主动进行扩展，或通过对未来负载的预测预先进行资源扩展，利用提前量降低冷启动延时带来的影响。如何通过预测请求模式的负载和变化以设计合适的扩展/卸载策略仍需要探索
-
Supporting fast and efficient decisions：
综上所述，对于每一条指令的处理，我们都需要根据需求在模型变体和硬件资源中选择合适的处理环境。这种选择具有很大的选择空间(模型变体和硬件资源多样，且具有可修改的配置属性)，且需要对系统动态变化的状态进行考察，例如某个模型变体是否已经被加载、模型变体的处理效率等。如何获取和组织相关的数据，从而进行快速的选择是值得探索的问题
-
Geo-distributed infrastructure for inference serving：
目前，边缘计算和中间计算的出现，使得基础设施可以建立在临近终端用户的位置，给模型推理服务带来了新的机遇和挑战。基础设施所处的区域的分层，带来了对时延、精确度、资源容量、能源效率等方面的权衡。模型变体为支持具有不同推理要求的应用程序，可以在这三层中选择合理的位置进行配置。例如，设置在边缘的低精度、小型的模型变体可以降低查询延迟，而设置在中心的大型模型变体可以提供高精度、大规模的查询
然而，模型推理服务系统要用上这种地理分布优势，还有许多问题需要解决，如模型应当加载到什么位置、查询请求应在哪里被处理、资源如何进行管理等。根据应用程序的要求，系统应该在低延时(地理接近)和核心资源高容量之间权衡(核心基础设施能力更强)
-
Security and privacy：
如果一个模型推理服务系统为多个用户提供推理服务，那么安全和隐私是必须需要解决的问题，需要避免未经授权的对其他用户和提供者的查询、提交模式和推理结果的访问。然而，安全机制的实施往往带来了性能上的开销，增长了查询处理的时延。因此，在选择合适的模型变体时，实施安全机制所带来的开销也应当考虑在内(论文中提及了一种通过分层定制模型的方法，通过将用户的特定层搭建在公有层上，使需求类似的用户共享公有层内容和结果，进而减小了模型的内存开销和推理时延。然而，这种方法对具有不同隐私要求的用户可能不可行)