mlperf Inference Benchmark -论文总结_mlperf inference benchmark

目前有超过100家企业杂研发人工智能推理芯片，目前的系统有包括至少三种能效等级和5个等级的性能表现，从嵌入式设备到数据中心。推动硬件发展的是十几个或更多的软件框架和库。ML硬件和ML软件的无数组合使得对ML新性能表现中立可复现，系统化的评估充满困难。
Mlperf解决了这个问题。MLPerf规定了一套规则和最佳实践，以确保各部门之间的可比性具有截然不同的体系结构的系统。

1介绍

目前有100多家公司研发推理芯片，而只有20多家公司研发训练芯片。
每个ML系统都采用独特的推理方法，可以权衡延迟，吞吐量，功能和模型质量。但是ML系统有不同的任务，模型，数据集，框架，工具集，库，体系结构和 推理引擎，使得评估推理性能的任务几乎难以完成。任务的范围很广，包括但不限于图像分类和定位，对象检测和分割，机器翻译，自动语音识别，文本到语音以及推荐。即使对于特定任务，例如图像分类，许多ML模型也是可行的。这些模型可用于多种情况，从在智能手机上拍摄一张照片到通过
自动驾驶汽车中的多个摄像头。因此，ML任务具有非常不同的质量要求和实时处理要求。即使是模型的功能和操作可能是高度特定于框架的，并且增加了设计任务的复杂性。为了要量化这些性能，ML领域需要一个在架构上中立，代表性和可再现性的基准。

目前有许多需多测试标准，但是它们是在没有ML系统设计人员在行业范围内投入的情况下开发的（以我的认识来看，是由于基本都是学界作出的标准，没有工业应用参与）。 结果，在代表性的机器学习模型，指标，任务和规则上没有达成共识。

• 1选择了具有代表性的工作负载来实现可重复性和可访问性

机器学习生态系统中有着各种模型。它们在模型复杂性和执行特性方面有很大的不同。 此外，诸如ResNet-50之类的名称无法唯一或可移植地描述模型（初始权重 batch size等的不同）。 因此，很难用不稳定的基线来量化系统性能的改进。
MLPerf选用的模型可以进行复现。MLPerf推理包括成熟的模型并赢得了社区的支持。 因为业界已经研究了它们并且可以构建有效的系统，所以可以使用基准测试，并且可以提供ML系统技术的概况。 MLPerf模型也是开源的，使其成为潜在的研究工具。

• 2确定实际评估的场景

MLPerf推理包含四个评估场景：single-stream, multistream, server, and offline。
这些场景代表了许多关键的推理应用程序。 我们表明，在这些情况及其相应的指标下，性能可能会发生巨大变化。 MLPerf推理提供了一种方法来模拟被测推理系统的实际行为。 这项功能在AI基准测试中是独一无二的。

• 3 根据实际使用情况规定目标质量和尾部延迟范围

所有形式的ML的质量和性能都息息相关。 系统架构有时会牺牲模型质量，以减少延迟，降低总拥有成本（TCO）或增加吞吐量。 精度，延迟和TCO之间的权衡是针对特定应用的。 将1％的模型精度换成50％识别猫照片时，较低的总体拥有成本是谨慎的做法，但是在检测自动驾驶行人时有危险。

• 4 设置了允许用户展示的宽松规则硬件和软件功能。

我们的基准测试使提交者可以优化参考模型，通过首选的软件工具链运行参考模型，并在所选的硬件上执行参考模型。 因此，MLPerf推理分为两个部分：closed和open。 严格的规则支配着closed，这解决了缺乏标准的基准测试流程的问题。 另一方面，open允许提交者更改模型并演示不同的性能和质量目标。

• 5我们提出了一种推理基准测试方法，该模型可以在保持上述贡献的同时频繁更改模型

ML迅速发展，因此任何基准测试的挑战不是执行任务，而是实现一种可以承受快速变化的方法。MLPerf Inference专注于基准测试的模块化设计，以在保持使用场景的同时，降低添加新模型和任务的成本， 目标质量和基础架构。 如第VI-E节所示，我们的设计使用户可以轻松添加新模型。 我们计划扩大范围，以包括更多领域和任务。 我们正在努力添加新模型（例如，推荐和时间序列），新方案（例如“突发”模式），更好的工具（例如移动应用程序）和更好的指标（例如定时预处理）更好地反映整个ML管道的性能。

2推理的挑战

• A 不同模型的选择

不同的任务场景需要的精确度不同，行人检测的准确率要远高于动物图像分类

• B 部署方案多样性

除了准确性和计算复杂性外，代表性的ML基准还必须考虑各种输入数据的可用性和到达模式应用程序部署方案。 例如，在离线状态下批处理，例如照片分类，所有数据（网络）存储中可能随时可用，从而可以加速达到并保持最佳性能的速度。 相比之下，翻译，图像标记和其他任务会根据最终用户流量遇到可变的到达模式。类似地，诸如增强现实和自动驾驶汽车之类的实时应用程序会处理恒定的数据流，而不是将其全部存储在内存中。 虽然型号相同。架构可以在每种情况下使用，数据批处理和类似的优化可能不适用，从而导致截然不同的性能。 定时设备上的推理
仅延迟就不能反映实际需求。

• C推理系统的不同

机器学习空间的广度和深度。 硬体和软件方面都表现出极大的复杂性。

3 benchmark设计

将模型多样性与软件范围相结合系统对获得强大的功能提出了独特的挑战
满足行业需求的ML基准。 为了克服那个挑战，我们采用了一系列原则来开发
基于社区意见的强大而灵活的产品。 在这个部分，我们描述基准，质量目标和
可以评估ML系统的方案。

3.1代表性的具有广泛访问的工作负载

设计ML基准不同于设计传统的非ML基准。 MLPerf定义了机器学习系统可以执行的高级任务。 对于每种工具，我们在一些广泛使用的框架中提供一个或多个规范参考模型。 在数学上等效于参考模型的任何实现均被视为有效，并且还允许某些其他偏差。 例如，可以使用不同的缓存阻止和评估策略来实现全连接的层。 因此，提交的结果需要进行优化才能获得良好的性能。

如表I所示，我们选择了一组初始的视觉和语言任务以及相关的参考模型。
视觉和翻译结合在一起，可以在整个计算中广泛使用系统，从边缘设备到云数据中心。还提供了具有不同架构的成熟且行为规范的参考模型（例如CNN和RNN）。

3.2鲁棒性

尽管推理的起点是达到目标质量的预训练参考模型，但许多系统体系结构可能会牺牲模型质量来减少延迟，降低总拥有成本（TCO）或增加吞吐量。 精度，延迟和总拥有成本之间的权衡是特定于应用的 。用1%的模型精度减少50%的TCO在识别猫照片上是合适的。但是行人检测无法使用。

3.3 现实中的场景

3.3.1Single-stream

single-stream为一个查询大小为1的推理查询流，反映了许多客户端应用程序在响应性至关重要的情况下。 一个例子是Google Pixel 4智能手机上的离线语音转录。 为了衡量性能，我们将一个查询插入到推理系统中。 查询完成后，我们记录完成时间并注入下一个查询。 指标是完成单次查询的90％延迟。

3 3.2Multistream

Multistream包含一系列查询，但每个查询都包含多个推理。反映了各种工业自动化和遥感任务。例如，许多自动驾驶汽车同时分析来自多个摄像机的帧。

为了建模并发场景，我们发送了一个新查询，其中包括以固定的时间间隔（例如50毫秒）进行的N次输入采样。 该间隔是特定于基准的，并且还充当了50到100毫秒的延迟范围。 如果系统可用，它将处理传入的查询。 如果它仍在一个时间间隔内处理先前的查询，它将跳过该时间间隔并将其余查询延迟一个时间间隔。 不超过1％的查询可能会产生一个或多个跳过的间隔。一个查询的N个输入样本在内存中是连续的，这可以准确反映生产输入管道，并避免惩罚系统，否则系统将需要在开始之前将样本复制到连续的内存区域推理。 性能指标是系统满足QoS（quality-of-service）要求时支持的流的最大个数。
下图是2080ti测试resnet-50的结果为4个sample，一张A100约为50个sample，是2080ti的11倍推理能力

(个人理解就是每次query会有很多samples，在内存中连续放置，先给定一个假定的stream数，然后在每次query的间隔时间内满足Qos的最大个数，这个最大个数用二分法进行确定)

3.3.3Server

服务器方案代表在线应用程序，其中查询到达是随机的，而延迟很重要。 几乎每个面向消费者的网站都是一个很好的例子，其中包括来自百度，谷歌和微软的在线翻译服务。 对于这种情况，根据泊松分布，每个查询都有一个样本。 被测系统在特定于基准的等待时间范围内响应每个查询，等待时间范围从15到250毫秒不等。 最多不超过1％的查询可能会超出视觉任务的延迟范围，而翻译不超过3％。 服务器方案的性能指标是Poisson参数，它表示在满足QoS要求的情况下可以实现的每秒查询（QPS）。
用户给出期望的QPS值，Inference系统使用QPS的泊松分布来生成query，进行吞吐量测试

3.3.4offline

offline表示批处理应用程序，其中所有数据都立即可用，并且延迟不受限制。 一个示例是识别相册中的人物和位置。 对于这种情况，我们发送一个包含所有要处理的样本数据ID的查询，并且系统可以按任何顺序自由处理输入数据。 与多流方案类似，查询中的相邻样本在内存中是连续的。 offline的度量标准是以每秒样本数衡量的吞吐量

3.4统计上可信的尾延迟界限

每个任务和方案组合都需要最少数量的查询，以确保结果在统计上可靠并且可以充分捕获稳态系统的行为。 该数字由尾部等待时间百分位数，所需的边距和所需的置信区间确定。 置信度是潜伏期限制在报告结果的特定范围内的概率。 我们选择了99％的置信区间，并将边距设置为远远小于尾部等待时间百分比与100％之间的差的值。 从概念上讲，该裕度应该相对较小。 因此，我们的选择是尾部等待时间百分比与100％之间差异的二十分之一。 公式如下：

表IV显示了查询要求。 查询总数和尾部等待时间百分位数是特定于场景和任务的。 single stream方案需要1,024个查询，而offline方案则需要1个查询，其中至少有24,576个样本。 前者要执行的查询最少，因为我们希望运行时间足够短，以使嵌入式平台和智能手机可以快速完成基准测试。

对于具有延迟约束的方案，我们的目标是确保约束保持99％的置信区间。 结果，具有更严格的延迟约束的基准测试需要以高度非线性的方式进行更多查询。 查询数量基于上述统计信息，并四舍五入为2^13的最接近倍数

99％的保证要求262,742个查询，其中四舍五入为33×2^13或270K。 对于mulit stream和server，如表V所示，对视觉任务的保证需要270K查询。 因为多流基准测试将每个查询处理N个样本，所以样本总数将为N×270K。 机器翻译具有97％的延迟保证，仅需90K查询

为了实现可重复性，我们多次运行多流和服务器方案。 但是多流方案的到达率和查询数量可确保运行2.5到7.0小时。 为了在可重复性和运行时间之间取得平衡，对于服务器方案，我们需要进行五次运行，结果是这五次中的最小值。 其他方案需要运行一次。 我们希望在将来的MLPerf版本中重新考虑此选择。
所有基准测试还必须至少运行60秒，并根据情况需要处理其他查询和/或示例。 最小运行时间可确保我们测量电源管理系统和支持动态电压和频率缩放（DVFS）的系统的平衡性能，尤其是对于查询很少的单流方案。

4推理系统

MLPerf推理提交系统包含被测系统（SUT），负载生成器（LoadGen），数据集和准确性脚本。 在本节中，我们描述这些不同的组件。 数据集LoadGen和准确性脚本对于所有提交都是固定的，由MLPerf提供。 提交者可以根据架构要求和工程判断来自由决定实施SUT。 通过在提交者拥有的组件和MLPerf拥有的组件之间建立清晰的界限，基准保持了提交之间的可比性

Load Generator

LoadGen是MLPerf推理的流量生成器，它加载SUT并衡量性能。 它的行为由运行开始时读取的配置文件控制。 LoadGen根据前述方案的规则（single-stream, multistream, server, and offline）产生查询流量。 此外，它收集信息以进行日志记录，调试和后处理。 它记录来自SUT的查询和响应，并在运行结束时报告统计信息，汇总结果并确定运行是否有效。 图4显示了LoadGen如何为每种情况创建查询流量。 例如，在服务器场景中，它根据Poisson分布发出查询，以模仿服务器的查询到达率。 在single-stream情况下，它将向SUT发出查询，并等待该查询完成，然后再发出另一个查询
在启动时，LoadGen请求SUT将数据集样本加载到内存中。 SUT可以将它们作为非定时操作加载到DRAM中，并按照规则规定执行其他定时操作。 这些未定时的操作包括但不限于编译，缓存预热和预处理。 当准备接收第一个查询时，SUT向LoadGen发信号； 查询是对一个或多个样本进行推理的请求。 LoadGen根据所选方案将查询发送到SUT。 根据这种情况，它可以一次，定期或以Poisson分布提交一个查询。 SUT对每个查询运行推理，并将响应发送回LoadGen，LoadGen记录响应或将其丢弃。 运行后，准确性脚本检查记录的响应，以确定模型准确性是否在公差范围内。

LoadGen具有两种主要的操作模式：准确性（accuracy）和性能（performance）。 两者都是验证MLPerf提交所必需的。 在准确性模式下，LoadGen将遍历ML任务的整个数据集。 该模型的任务是对完整的数据集进行推断。 之后，准确性结果将显示在日志文件中，以确保模型满足所需的质量目标。 在性能模式下，LoadGen避免遍历整个数据集，因为可以通过对数据集进行足够的采样来确定系统的性能。

我们设计了LoadGen以灵活地处理对基准套件的更改。 MLPerf Inference在SUT和LoadGen之间具有接口，因此它可以处理LoadGen中的新方案和实验，并将它们推广到所有模型和SUT，而无需付出额外的努力。 这样做还有助于合规性和审计，因为有关查询到达，时间和准确性的许多技术规则是在提交者代码之外实现的。 我们通过将LoadGen与基准测试和内部表示（例如模型，方案以及质量和延迟指标）分离开来，实现了这一壮举。 LoadGen实现是一个独立的C ++模块。
此外，将性能评估代码置于提交者代码之外符合MLPerf的端到端系统基准测试目标。 因此，LoadGen会衡量整个SUT而不是任何单个部分的整体性能。 最后，这种情况增强了基准的真实性：推理引擎通常充当大型系统的黑匣子组件