Nanily: A QoS-Aware Scheduling for DNN Inference Workload in Clouds阅读

1. 概述

论文设计并构建了一个调度，以提高GPU吞吐量，自动扩展应对变化的工作负载。提高单个工作负载下满足延迟SLO的吞吐量。

论文主要挑战：
DNN推断工作负载调度必须包括自适应的批处理（batching）和自动缩放，来平衡延迟和资源效率。

论文主要贡献：

1. 一种基于自适应批处理的延迟调度方法
2. 一种新的基于预调度算法的自动缩放策略
3. 与最先进的技术相比，减少了45%资源数量

2. 背景

DNN模型性能好，但计算和内存开销大，部署在终端困难，因此，由云计算提供服务。

其主要系统架构：

客户端发送连续流式的DNN推断请求，由云上的GPU服务器处理。请求附带应用指定的延迟，调度模块将请求打包为批处理并选择合适的云托管GPU服务器来处理。处理模块是一个GPU集群，每个云托管的GPU服务器依次处理一批请求并返回推断结果。因此，部署DNN推断模型的GPU服务器必须根据不断变化的请求，按资源比例自动缩放。

批处理大小的影响（batch size）：

B是批处理大小，T是处理B请求的时间。根据MNIST部署一个DNN模型作为服务器，调整B从1到69并记录时间T。可知T和B关系式一个近似线性的，斜率明显小于1，因为B较大时会并行计算。每秒请求的吞吐量（QPS）随B增大而增大，最终保持一个相对稳定的值。表示：批处理有效提高了吞吐量。

权衡亚秒延迟和资源效率：
要实现亚秒延迟，由于服务和系统的高度波动的负载，过度配置在经济上是不可行的。DNN推断工作负载必须选择最佳batch size和自动缩放来实现延迟和资源效率的平衡。

3. Nanily设计

目的：满足请求延迟并提高吞吐量和资源利用率。

包括四个模块：请求接收器、自适应批处理调度、预测器、自动缩放器。

请求接收器和自适应批处理调度程序一起工作，以维护请求队列。请求接收器将请求放入请求队列，自适应批处理调度程序根据实时情况从队列取出请求，形成一批请求（batch），发送给实例处理。

预测器与自动缩放器有一个连接。因为设置实例需要的时间远多于需要的延迟，所以要在设置下一个实例之前预测请求率，然后预先确定最适合的实实例的数量。我们也使用线性回归来预测。然后自动缩放器根据请求速率确定当前实例数量是否满足需求，然后执行适当的操作：放大，缩小，或者什么都不做。

Nanily有三个同时执行的线程。

1. 接收器接受请求并放到请求队列。
2. 调度程序计算批处理大小并发送到实例中处理。
3. 预测器预测请求速率然后自动缩放器进行缩放。

自适应分批调度

通常，一个请求的响应时间包括两部分：请求在队列中等待的时间和在实例上处理的时间。

研究表明，batch size和在GPU上的处理时间呈现稳定的线性关系，即，在特定的推断服务确定后，我们可以通过batch size获得请求组在GPU上的处理时间。

因为Nanily使用自适应批处理调度，而不是固定大小的batch，因此请求等待时间是不固定的。排在队列中最前面请求具有最长的等待时间。只要能满足第一个请求的，也能满足其他请求的SLO。

假设每个请求的延迟相同，按一下公式计算每个调度的batch size：
$$BS=f_{RBD}(l-(t_2-t_1)$$