MLPerf 基础知识笔记
机器学习性能标准基准套件,旨在衡量和比较机器学习推理和训练任务的性能。由一系列基准测试组成,涵盖多个应用领域和硬件平台。
MLPerf基准测试包括训练基准(Training Benchmark)和推理基准(Inference Benchmark)。
典型 ML 管道的各个阶段。机器学习基准测试侧重于两个阶段:训练和推理。原始数据通常在使用前进行清理和标准化。 在训练过程中,模型学习根据输入进行预测;例如,模型可以学习预测照片的主题或句子从英语到德语的最流畅翻译。 在推理过程中,模型对其输入进行预测,但它们不再学习。
MLPerf Training(训练)
Benchmark Definition(基准定义)
封闭划分,需要使用特定的模型进行直接比较;另一个是开放划分,允许使用任何模型来支持模型创新,要求使用相同的数据集解决相同的问题,允许使用任意预处理,模型或训练方法。
Metric Definition(指标定义)
吞吐量:每秒处理的数据数量;
训练时间:模型达到目标质量所需的时间。
MLPerf Training 选择使用训练时间作为指标,即模型训练到特定质量的时间。
Benchmark Selection(基准选择)
机器学习应用五个广泛的领域:
-
视觉:图像分类、目标检测、分割、医学成像。
-
语音:语音转文字、文字转语音。
-
语言:翻译、自然语言处理(NLP)。
-
商业:推荐、时间序列。
-
研究:游戏或机器人的强化学习(RL)、生成对抗网络(GAN)。
在每个领域选择一两个具体基准,根据四个特征选择模型:成熟度、多样性、复杂性、实用性。
MLPerf Inference(推理)
推理的挑战
-
模型的多样性
为基准选择正确的模型取决于应用,自动驾驶中行人检测的准确率要远高于动物图像分类。即使对于单个 ML 任务(例如图像分类),许多模型也会在准确性和计算复杂性之间进行不同的权衡。
-
部署场景的多样性
在照片分类等离线批处理中,所有数据都可以在(网络)存储中轻松获得,从而使加速器能够达到并保持峰值性能。 相比之下,翻译、图像标记和其他 Web 应用程序可能会根据最终用户流量而经历不同的到达模式。增强现实和自动驾驶汽车等实时应用程序处理持续的数据流,而不是将其全部存储在内存中。 仅对设备上的推理延迟进行计时并不能反映现实世界的要求
-
推理系统的多样性
推理应用程序、数据集、模型、机器学习框架、工具集、库、系统和平台的可能组合有很多,这使得系统性和可重复的基准测试进一步复杂化。
推理目标
-
具有代表性、可广泛访问的工作负载
图像分类、目标检测和机器翻译等。
-
使用现实场景进行评估
机器学习推理系统涵盖各种应用程序以及从深度嵌入式设备到智能手机再到数据中心的物理部署。 这些应用程序具有多种使用模型和许多品质因数,这反过来又需要多个性能指标。 例如,对摄像机输出进行分类的图像识别系统的品质因数将与基于云的翻译系统完全不同。为此,开发了负载生成器(LoadGen)工具。
-
灵活展示硬件和软件
分为封闭区和开放区。
Benchmark Definition(基准定义)
处理经过训练的模型的一系列输入,以产生满足质量目标的输出。
MLPerf Inference 有2个基本概念: sample
和query
。
- sample(样本)是运行inference的单位,例如一个image或sentence。
- query(查询)是一组进行Inference的N个sample。例如单个query包含8个image。
MLPerf推理提供了一种方法来模拟被测推理系统的真实行为:开发了负载生成器(LoadGen)工具,它是一个模拟现实系统行为的查询流量生成器,有以下四个测量场景,每个场景解决一类用例,模拟移动设备、自动驾驶车辆、机器人和基于云的设置的机器学习工作负载行为。
Load Generator是MLPerf的负载生成器,用于生成query,跟踪 query 的 Latency 并验证结果的准确性。每次运行 LoadGen 都会使用四种模式之一来评估系统的性能,最后提交的结果可以是{models, scenarios}的任意组合。
- Single stream 单流:一系列输入被依次处理,模拟例如用户使用智能手机拍照的真实场景。
- Multiple stream 多流:固定大小的一批输入被一个接一个地处理,例如检测障碍物的多摄像头汽车系统的真实场景。
- Server 服务器:输入根据泊松分布到达,例如在线翻译服务、评估在线请求数据中心服务,衡量服务器吞吐量这样的实际场景。
- Offline 离线:所有输入都可以立即使用,例如在照片标签应用程序、批处理系统中。
每次运行LoadGen都会使用四种模式之一来评估系统的性能,最后提交的结果可以是 {models, scenarios} 的任意组合。
为了反映现实世界部署,建立了每个模型和场景的推理延迟和模型质量目标。延迟界限和目标质量基于从最终用户收集的输入。
MLPerf Inference 也有一个封闭分区(Closed Division)和一个开放分区(Open Division)
-
封闭分区:要求使用特定模型来实现直接比较,需要使用等同于参考实现的预处理,后处理和模型。同时允许校准量化,但不允许任何再训练。
-
开放分区:允许更改模型并实现不同的性能和质量目标。只限制使用相同的数据集,它允许使用任意的预处理或后处理和模型,包括重新训练。
Metric Definition(指标定义)
MLPerf Inference为上述每个场景定义了一个基准。衡量推理系统性能的理想指标因用例而异, 例如,移动视觉应用程序需要低延迟,而离线照片应用程序则需要高吞吐量。
Latency被定义为从LoadGen将query传递到SUT(system under test),到Inference完成并收到回复的时间。
-
Single stream 单流:延迟;
-
此场景表示查询样本大小为 1 的一个推理查询流,反映了响应能力至关重要的许多客户端应用程序。如智能手机上的离线语音转录。
-
为了测量性能,Load Gen 注入单个query,每次查询只包含1个sample;在处理完上一个query后再发送下一个query,直到超过设定的query数 并且 达到设定的测试时间。query数量和测试时间的双重要求旨在能够同时适配大型和小型推理系统。
-
性能指标是查询流的第90百分位延迟,指在一组查询流中,按照延迟的升序排列后,处于第90%的延迟值。
-
注意,最后衡量的结果是Tail Latency而不是average Latency。
-
-
Multiple stream 多流:受延迟限制的流数量;
- 代表具有查询流的应用程序,但每个查询都包含多个推理。例如,许多自动驾驶车辆分析来自六到八个同时传输的摄像机的帧。
- 为了对并发场景进行建模,LoadGen 以固定时间间隔(例如 50 ms)发送包含 N 个输入样本的新查询。 该间隔是特定于基准的,并且还充当范围从 50 到 100 毫秒的延迟界限。 如果系统可用,它将处理传入的查询。 如果它仍在处理某个时间间隔内的前一个查询,则它会跳过该时间间隔并将剩余的查询延迟一个时间间隔。不超过 1% 的查询可能会产生一个或多个跳过的间隔。 查询的 N 个输入样本在内存中是连续的,这准确地反映了生产输入管道,并避免了惩罚系统,否则系统会要求在开始推理之前将样本复制到连续的内存区域。
- 性能指标:1.1 及更早版本是系统在满足 QoS 要求的同时支持每个查询的最大推理数(流的数量),每个query中的Sample的数量等于stream的数量。2.0 及更高版本是99%-ile 测量延迟
-
Server 服务器:每秒泊松到达查询数受延迟限制;
- 查询到达是随机的且延迟很重要的在线请求数据中心服务,包括百度、谷歌和微软的在线翻译等服务。
- 负载生成器根据泊松分布发送查询,每个query只包含1个Sample。 SUT 在 15 到 250 毫秒之间的基准特定延迟范围内响应每个查询。 不超过 1% 的查询可能会超过视觉任务的延迟限制,不超过 3% 的查询可能会超过翻译的延迟限制。
- 性能指标是支持的最大泊松吞吐量参数(QPS),表示在满足 QoS 要求的情况下每秒可实现的查询数。
-
Offline 离线:吞吐量。
- 代表批处理应用程序,其中所有输入数据立即可用且延迟不受限制。一个例子是识别相册中的人物和位置。
- LoadGen 向系统发送一个包含所有要处理的样本数据 ID 的单个查询,即一次发送所有query给Inference系统,系统可以自由地以任何顺序处理输入数据。
- 离线场景的指标是以每秒样本数衡量的吞吐量。
图:v0.5多流和服务器场景中每个任务的延迟限制。对于多流和服务器场景,延迟是系统行为的关键组成部分,并将限制各种性能优化
Benchmark Selection(基准选择)
在机器学习广泛应用的领域(视觉、语音、翻译等)以及广泛使用的框架(TensorFlow、PyTorch)中提供了一到两个规范的参考模型。
基准选择也是由成熟度、多样性、复杂性和实用性驱动的。还需要选择复杂程度适合从移动设备到服务器等一系列硬件的模型,并支持我们在多种场景中选择的任何模型。
对于视觉任务,定义了重量级和轻量级模型。 前者代表具有更大计算资源的系统,例如数据中心或自动驾驶汽车;后一种模型适用于计算资源有限和低延迟要求的系统,例如智能手机和低成本嵌入式设备。
Implementation Equivalence(实现等效性)
引入两个基本约束来处理实现等效性。
- 所有实现都必须使用标准化负载生成器(standardized load generator)来实现四种场景并测量相应的指标;
- 所有实现必须使用相同的参考权重。
设计与实现
完整的 MLPerf 推理系统包含多个组件:数据集、被测系统 (SUT)、负载生成器 (LoadGen) 和准确性脚本。
所有提交的数据集、LoadGen 和准确性脚本都是固定的,并由 MLPerf 提供。 提交者可以根据其架构的要求和工程判断来实施被测系统(SUT)。通过在提交者拥有的组件和 MLPerf 拥有的组件之间建立明确的界限,该基准保持了提交之间的可比性。
图:MLPerf 被测推理系统 (SUT) 以及组件的集成方式。
-
(1) LoadGen 请求SUT加载样本到内存中
某些数据集(例如 ImageNet)的许可限制,MLPerf 不直接托管它们,在运行基准测试之前下载数据
-
(2-3) SUT 将样本加载到内存中,并可按照规则执行操作;
-
(4) 当 SUT 准备就绪时,向 LoadGen 发出信号
当 SUT 准备好接收第一个查询(query)时,它会向 LoadGen 发出信号。 查询(query)是对一个或多个样本进行推理的请求
-
(5) LoadGen向SUT发出请求(query)
LoadGen 根据所选场景向 SUT 发送查询(query)请求。 根据该场景,它可以一次提交一个查询、定期提交查询或按照泊松分布提交查询等,以便在推理硬件上执行。
一旦超过设定的query数并且达到测试时间,LoadGen就会停止生成query。
-
(6) 基准测试处理结束并将结果返回给LoadGen
SUT 对每个查询运行推理,并将响应通过QuerySampleComplete的函数发送回 LoadGen。
-
(7) LoadGen 输出日志,然后准确性脚本读取并验证日志
LoadGen 会记录响应或丢弃响应。 运行后,准确性脚本会检查记录的响应以确定模型准确性是否在容差范围内。在基准测试运行结束时,它会输出一组报告性能和准确性统计数据的日志。
暂时不太理解:(在 SUT 和 LoadGen 之间提供了清晰的接口,因此可以在 LoadGen 中处理新的场景和实验,并将其推广到所有模型和 SUT,而无需额外的工作。此外,将性能测量代码置于提交者代码之外与 MLPerf 的端到端系统基准测试目标一致。 为此,LoadGen 测量整个 SUT 的整体性能,而不是任何单个部分。 最后,这种情况增强了基准测试的真实性:推理引擎通常充当大型系统的黑匣子组件。)
LoadGen 负载生成器
用于加载 SUT 并测量性能,它的行为由它在基准测试运行开始时读取的配置文件控制。 LoadGen根据前面描述的场景(即单流、多流、服务器和离线)的规则产生查询流量。 此外,LoadGen 还收集用于记录、调试和后处理数据的信息。 它记录来自 SUT 的查询和响应,并在运行结束时报告统计信息、汇总结果并确定运行是否有效。
下显示了 LoadGen 如何为每个场景生成查询流量。 例如,在服务器场景中,它根据泊松分布发出查询来模拟服务器的查询到达率。 在单流情况下,它向 SUT 发出查询并等待该查询完成,然后再发出另一个查询。
图:负载生成器 (LoadGen) 的查询时间和数量因基准场景而异。 所有五个 ML 任务都可以在四种场景中的任何一种中运行。
将 LoadGen 与基准测试解耦,LoadGen 作为一个独立的 C++ 模块实现,具有定义良好的 API; 基准测试通过这些 API 调用它(反之亦然通过回调)。 API 级别的这种解耦使其能够轻松支持各种语言绑定,从而允许使用任何语言进行基准测试。 目前,LoadGen 支持Python、C 和 C++ 绑定; 可以添加额外的绑定。
运行模式
LoadGen 有两种主要操作模式:精度模式和性能模式。
- 精度模式(Accuracy mode):LoadGen 会遍历 ML 任务的整个数据集, 该模型的任务是对完整的数据集进行推理。 随后,准确性结果将出现在日志文件中,确保模型满足所需的质量目标。
- 性能模式(Performance mode): LoadGen 避免遍历整个数据集,因为系统的性能可以通过对其进行足够的数据集样本来确定。
基准测试任务
v5.0 选择视觉和翻译,因为它们广泛应用于从边缘设备到云数据中心的所有计算系统,还可以使用具有不同架构(例如 CNN 和 RNN)的成熟且性能良好的参考模型。
图像分类
-
使用ImageNet 2012数据集,选择了两个模型:一个精度更高、计算成本更高的重量级模型,以及一个计算速度更快但精度较低的轻量级模型。
重量级模型:ResNet-50 v1.5, 直接来自 MLPerf 训练套件以保持对齐。 ResNet-50 是性能声明中最常见的网络,确保跨主要框架的有用比较和兼容性。
轻量级模型:MobileNets-v1 224, 围绕更小的、深度可分离的卷积构建的,以降低模型复杂性和计算负担
-
图像分类质量指标:分类器的 Top-1 accuracy(Top-1 准确率,只有当模型的预测完全与真实标签一致时才算作正确,即模型预测的结果与实际标签完全匹配的比例)。
目标检测
-
选择具有轻量级和重量级模型的 COCO 数据集。
重量级参考模型:是带有 ResNet34 主干的 SSD,这也来自 MLPerf 的训练基准。对于较大的模型,升级了数据集,以更接近地表示高清图像传感器的输出(总共 1.44 MP)。
轻量级参考模型:使用 MobileNet-v1-1.0 主干网,这对于受限计算环境更为典型,根据移动和嵌入式社区的反馈选择了 MobileNet 特征检测器。小型模型使用 300x300 图像尺寸,这是智能手机和其他紧凑型设备的典型分辨率。
-
目标检测的质量指标:平均精度 (mAP)。
翻译
-
神经机器翻译(NMT)模型将单词序列从源语言翻译为目标语言,并用于翻译应用程序和服务。
-
翻译数据集是 WMT16 EN-DE。
-
模型:GNMT,采用了完善的循环神经网络(RNN)架构,并且是训练基准的一部分
-
翻译质量衡量标准:Bilingual Evaluation Understudy Score(BLEU)。即双语评估替补,用于评估从一种语言翻译成另一种语言的文本的质量。给定一个机器生成的翻译,自动计算一个分数,衡量机器翻译的好坏。取值范围是[0, 1],越接近1,表明翻译质量越好。
场景和指标
为了能够对各种推理平台和用例进行代表性测试,MLPerf 定义了四种不同的场景,如下所述。 给定场景由标准负载生成器评估,以特定模式生成推理请求并测量特定指标。
场景 | query生成 | 持续时间 | Samples/query | 评价指标 |
---|---|---|---|---|
Single stream | SUT 完成前一个查询后,LoadGen 立即发送下一个查询 | 1024 queries and 60 seconds | 1 | 第90百分位延迟 |
Multiple stream (1.1 and earlier) | 如果 SUT 已完成前一个查询,则 LoadGen 在每个延迟约束下发送一个新查询,否则新查询将被删除并计为一个超时查询 | 270,336 queries and 60 seconds | Variable, see metric | 支持每个查询的最大推理数(流的数量) |
Multiple stream (2.0 and later) | 一旦 SUT 完成前一个查询,Loadgen 就会发送下一个查询 | 270,336 queries and 600 seconds | 8 | 99%-ile 测量延迟 |
Server | LoadGen 根据泊松分布向 SUT 发送新查询 | 270,336 queries and 60 seconds | 1 | 支持的最大泊松吞吐量参数 |
Offline | LoadGen 在启动时将所有查询发送到 SUT | 1 query and 60 seconds | 至少 24,576 | 以每秒样本数衡量的吞吐量 |
运行注意
tensorflow版本需要为TensorFlow v1,并且TensorFlow版本与python版本是适配的。
PyTorch版本运行是出现找不到 caffe2 模块。
onnxruntime-gpu 安装版本跟 cuda 和 cudnn 的版本有关,要根据onnxruntime-gpu, cuda, cudnn 三者对应关系组合测试。
参考链接
Benchmark MLPerf Inference: Edge | MLCommons V3.1 Results
[1911.02549] MLPerf Inference Benchmark (arxiv.org)
https://github.com/mlcommons/inference/tree/master/vision/classification_and_detection
https://github.com/mlcommons/inference/blob/master/vision/classification_and_detection/GettingStarted.ipynb
MLPerf-inference-resnet50_ml perf inference-CSDN博客
tree/master/vision/classification_and_detection
https://github.com/mlcommons/inference/blob/master/vision/classification_and_detection/GettingStarted.ipynb