---

知识点记录

推理服务

推理服务具有很大的挑战性，需要同时兼顾吞吐量和延迟。论文关注推理过程中的四个方面：

• 多样化请求：应用程序的查询具有不同的准确性、成本和延迟要求[1]。例如，推荐和提供广告有严格的延迟限制，可以容忍较低的预测精度，而语音识别可能愿意为了更高的精度而牺牲延迟
• 模型变体：同一模型的变体可能在大小、预测精度、推理延迟和资源使用占用方面有所不同[2]
  什么叫模型变体？通过模型压缩（剪枝，量化，蒸馏）获得的模型，源于同一个基础模型，但通过变换方法，它们的架构可能会有所不同
• 异构执行环境：使用不同的硬件集合，如cpu、gpu、tpu、fpga和其他asic
  类似于端侧或边缘服务器的存算资源
• 负载和计算环境的动态变化：(1) 随着时间的推移，请求会发生显著变化；（2）计算环境随着时间变化

在线推理特点

• 实时性：在线推理需要快速响应，通常用于需要即时反馈的应用，如实时语音识别、实时视频分析、在线推荐系统等。

• 低延迟：响应时间是关键指标，延迟需要尽可能低，以满足实时应用的需求。

• 持续加载：在线推理系统需要一直保持运行，随时准备处理输入数据。

• 高并发：可能需要处理大量并发请求，因此系统必须具备高并发处理能力

  语义通信模型需要在线推理

---

动机：为什么作者想要解决这个问题？

DNN模型具有两个阶段，训练和推理，在当时(2019年)，大部分文章专注于DNN模型的训练，对于推理服务的研究很少。
本文希望设计基于模型变体和硬件选择的优化策略，在负载动态变化场景下，满足多样化请求的服务目标水平。

下面详细分析一下提到的几个关键词:

• 模型变体：模型在准确性，推理延迟，吞吐量和资源使用方面不同

• 硬件选择：模型运行在异构硬件资源(CPU、GPU、TPU、FPGA和其他ASIC)上，具有不同的性能和成本

• 负载动态变化：①应用请求（一定时间内收到的请求数量）随时间显著变化，例如昼夜变化 ②计算环境的CPU、GPU、内存、网络带宽等随时间动态变化

• 多样化请求的服务目标水平：请求具有不同的准确性、成本和延迟要求。

---

贡献：作者在这篇论文中完成了什么工作(创新点)？

设想了一个推理服务系统，自动为模型提供资源，以满足用户的推理查询请求，该系统称为“管理推理服务系统”。为该系统设计一个接口，使用户能无需关注模型，称为model-less

---

规划：他们如何完成工作？

1.挑战

这部分分析一下文章的第二章，着重分析一下其中的图片，记录图中得到的结论

1.1 选择一个模型变体

图中展示的是在NVIDIA V100上的ResNet50的5个变体(变体在相同数据集上达到了相同的准确率)，推理时间与最大吞吐量的对比。首先分析图片：

• 横轴：在GPU上进行单次推理所需要的时间，单位是msec(毫秒)

• 纵轴：每秒钟能够处理的图片数量(吞吐量)，单位是每秒处理1000张图片

• 模型变体：

  • 有5种不同的模型变体，如Caffe2-default、TRT-batch1、TRT-batch1-fp16、TRT-batch64和TRT-batch64-fp16；
  • $TRT-batchX$表示对X的批量大小进行TensorRT优化【TensorRT使高性能深度学习推理优化库，提供了多种优化技术，以减少推理时间、提高吞吐量并降低计算资源消耗】；
  • $Caffe2-default$指的是在Caffe2框架中使用默认配置进行推理的模型实例
  • fp16表示精度，没有标注精度的默认是f32

• 圆圈大小：内存使用率，圆圈越大，内存使用的越多

然后分析一下可以得到的结论：

• 观察TRT-batch1和TRT-batch1-fp16(TRT-batch64和TRT-batch64-fp16)：变体在精度方面不同，TRT-batch1-fp16(TRT-batch64-fp16)的延迟比TRT-batch1(TRT-batch64)低，吞吐量稍高，表明使用低精度（fp16）可以提高效率
• 观察TRT-batch1和TRT-batch64(TRT-batch1-fp16和TRT-batch64-fp16)：变体在batch-size方面不同，batch-size增大，吞吐量增大，推理延迟也增大了。注意，批量(batch-size)大于1时，指的是处理整个批次的时间，例如TRT-batch64的横轴代表处理64张照片的时延。单张图片的时延要除64
  • 吞吐量与批量大小：批量(batch size)大小增加通常会提高模型的吞吐量，这是因为硬件资源利用效率更高，可以在相同时间内处理更多样本；
  • 推理延迟与批量大小：批量大小增加会导致推理延迟增加，因为每个批次的计算时间变长

看完上面这张图，总的来说，就是没有一个模型变体可以适用于所有情况。

现有的推理服务系统[11,49]将同一个查询发送到多个候选模型，每个模型都执行一次推理，然后选择最好的结果返回给用户，导致通信开销和资源消耗增加。

1.2 异构硬件

异构的硬件会带来模型性能和推理成本之间的权衡

现有系统[4,16]固定目标硬件并在服务时使用默认模型变体，这样的系统忽略了应用程序在推理延迟方面的需求。其他系统[11,40]默认使用支持所有批处理大小的模型变体，并使用动态批处理来平衡吞吐量和延迟约束。

1.3 资源提供

需要决定为模型提供多少资源。两个方面：

• 水平扩展（Horizontal Scaling）：增加或减少模型实例的数量，以应对负载变化。例如，在高峰期增加实例数量，在低谷期减少实例数量。【模型实例：部署在硬件（如GPU）上的相同模型的独立副本的数量，每个实例可以单独处理请求】
• 垂直扩展（Vertical Scaling）：增加或减少单个模型实例的资源配置，如CPU核心数和内存大小。

1.4 启动时延

将模型变体加载到目标硬件的内存中会带来启动时延。
减轻启动延迟的一种常用方法是预加载和持久化模型[11,19,40]，但是会带来资源的浪费和成本的增加。

2.Managed and model-less inference serving

用户发送一个或多个请求，并带有可选的SLO约束。推理系统完成以下工作：

2.1 模型变体自动选择和硬件选择

模型变体在性能、成本和资源使用方面有所不同。模型变体的选择会影响资源消耗和推理性能。
因此，有几个问题需要解决：

• 我们首先需要了解不同模型变体的特征
• 然后，我们需要将模型变体和目标硬件组合，映射到其对性能和成本的影响
• 如何分析准确性，可能需要对服务的质量进行反馈

2.2 推理查询的动态放置

需要解决的问题：

• 需要考虑资源可用性的动态变化，即选模型的时候结合资源配置

2.3 启动时延约束

模型推理时可能需要加载一个模型，启动额外的硬件资源，或者退出加载的模型以使资源可用。这引入了启动延迟。如何设计机制和策略来避免或减少启动延迟仍然是一个悬而未决的问题。
具体来说，根据现有的资源管理的文章[15,22]，需要设计一些基于启发式或基于学习的优化，解决一些问题：

• 设定一个条件，根据系统当前的使用情况(也可能根据对未来系统使用情况的预测，比如双十一前，增加资源)，动态调整硬件资源和机器学习模型实例数量。
• 系统通过监控查询日志和统计数据，识别哪些模型在特定时间段内被频繁访问。根据识别出的流行模型，系统自动调整这些模型的实例数量。
• 需要设计模型驱逐策略

  1. 为什么需要模型驱逐

     • 资源有限性：服务器的内存和存储是有限的，不可能加载所有的模型
     • 流行性波动：对模型的需求是随着时间而变化的

  2. 设计策略的关键点

     • 模型使用频率：优先保留使用频率高的模型
     • 模型加载时间：尽量避免移除重新加载成本高的模型
     • 预测：根据历史数据和预测的负载情况，提前规划哪些模型可能在未来某段时间需求增加，哪些需求减少

2.4 快速有效的模型选择决策(重点！！)

• 实时监控系统状况，包括系统的负载情况，模型加载情况，每个模型实例当前处理的请求数量
• 基于收集到的动态数据，系统做出决策，例如将新的查询分到负载较低的节点上，或高峰期来临时时候，提前部署更多的实例

2.5 在分布式节点上的模型推理

在边缘维护具有低精度和内存占用的模型，以改善延迟。如果应用程序需要高精度的预测，我们可以将查询定向到核心中更准确和资源较多的模型，代价是增加延迟

• 面临的挑战：
  • 模型应该加载到哪里？
  • 如何做出查询分配决策？
    • 根据需求：系统需要根据应用的具体需求来决定查询应该分配到哪里。例如，实时视频分析可能更适合在边缘设备上处理，以减少延迟，而复杂的图像处理任务可能更适合在核心数据中心处理。
    • 动态调整：系统需要具备动态调整能力，根据实时负载和资源可用性来分配查询
  • 资源管理决策应该如何以及在哪里做出？
    • 集中式管理：所有资源管理决策在一个中央位置（如云数据中心）做出，便于统一管理和控制。
    • 分布式管理：在多个位置（如边缘和核心）分布式地做出决策，可以更灵活地响应局部的资源需求和负载变化。

---

自己的看法(作者如何得到的创新思路)

• 选模型+选硬件+选batchsize+资源分配

• 模型可以复用，即模型实例，就是resource provisioning
  水平扩展（Horizontal Scaling）：增加或减少模型实例的数量。例如，从10个实例增加到20个实例，或者从20个实例减少到10个实例。
  垂直扩展（Vertical Scaling）：增加或减少单个模型实例的资源配置（如CPU和内存）

• 数据：YOLOBench
  YOLOBench提供了基于YOLO架构的高效目标检测模型在不同嵌入式硬件平台上的基准测试数据。它包括了多种YOLO模型变体在不同硬件（如NVIDIA Jetson Nano GPU、Khadas VIM3 NPU、Raspberry Pi 4 Model B CPU、Intel Core i7 CPU）上的准确性和延迟数据【79】【80】。

• 决策的整个过程有静态属性和动态属性；模型的属性简单起见可以视为静态，但是系统负载是动态变化的

---

参考文献

[1] Kim Hazelwood, Sarah Bird, David Brooks, Soumith Chintala, Utku Diril, Dmytro Dzhulgakov, Mohamed Fawzy, Bill Jia, Yangqing Jia, Aditya Kalro, James Law, Kevin Lee, Jason Lu, Pieter Noordhuis, Misha Smelyanskiy, Liang Xiong, and Xiaodong Wang. 2018. Applied Machine Learning at Facebook: A Datacenter Infrastructure Perspective. In Proceedings of the 2018 IEEE International Symposium on High Performance Computer Architecture (HPCA) (HPCA ’18). IEEE.

[2] Gao Huang, Danlu Chen, Tianhong Li, Felix Wu, Laurens van der Maaten, and Kilian Weinberger. 2018. Multi-Scale Dense Networks for Resource Efficient Image Classification. In International Conference on Learning Representations. https://openreview.net/forum?id= Hk2aImxAb

---