C/C++教程

MLPerf Inference

本文主要是介绍MLPerf Inference,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

论文地址

https://arxiv.org/pdf/1911.02549.pdf

官网地址

https://mlcommons.org/zh/

github

https://github.com/mlcommons/inference

 

MLPerf是什么?

Fair and useful benchmarks for measuring training and inference performance of ML hardware software and service

用于机器学习(大部分是深度学习)的性能测试基准

 

相关概念

LoadGenerator:负载生成器,MLPerf使用它生成不同的测试场景对inference进行测试

SUT:被测试系统

Sample:运行inference的单位,一个image或者一个sequence

query:一组进行推理的N个样本

Latency:LoadGenerator将query传递到SUT,到Inference完成并收到回复的时间

Tail-latency:论文中并没有对Tail-latency的明确解释,我在网上找到了一段解释,

Tail latency is the small percentage of response times from a system, out of all of responses to the input/output (I/O) requests it serves, that take the longest in comparison to the bulk of its response times

尾部延迟是指在一个系统提供的所有输入/输出(I/O)请求的响应中,与大部分响应时间相比,花费时间最长的那一小部分。

就是说如果在系统中引入实时监控,总会有少量响应的延迟高于均值,我们把这些响应称为尾延迟(Tail Latency)

这大概能说明了tail-latency所代表的含义,只不过结合论文来看,本文所提到的tail-latency并不是一个表示延迟的数据,而是百分比

 

latency是一个数字,表示时间,tail-latency是一个百分比,我认为是所有latency中的后百分之几,还有一点,sample与latency应该是一一对应的,一个sample就有一个latency

 

设计Benchmark面临的问题

1.模型选择

横坐标表示运算能力,纵坐标表示置信度最高的类的准确率,面积越大表示参数量越大,模型各有优缺点,需要在各种因素之间需要权衡

2.部署场景的多样性

对于offline场景,比如图片分类,要求将图片在内存中随时可用才能保证加速器达到峰值性能。但是在实时程序中如自动驾驶,模型要持续处理数据流而不是一口气载入全部数据,只有在设备上的推理延迟并不能满足实际应用的需求。

3.推理系统的多样性

上层应用到底层设备的栈图,每一层都有多种组合,导致推理系统的基准很难确定

 

Benchmark设计

1.选取有代表性,泛用场景多的模型

2.健全的质量目标

不同应用领域对于模型指标的要求不一样,有的侧重准确率,有的侧重吞吐量有的侧重延迟

3.终端应用场景

MLPerf提供了四种inference的场景,四种测试场景的主要区别在于请求是怎样发送和接收的

a.single-stream

一次查询送入系统一个样本,到上个请求的响应之前不会发送下一个请求,性能指标是90%的延迟.请求是串行送入系统的,当一个请求处理完后,记录下他的处理时间并传入下一个请求,假如有1000个样本,90th-percentile latency我认为是将1000个样本的延迟记录下来从小到大排列,第900个样本的处理时间就是这个系统的性能指标

b.multi-stream

以固定的时间间隔发送请求(这个时间间隔就作为Multi-stream场景中的延迟边界,一般为50~100ms),一个请求中含有N个样本,当所有查询的(latency)延时都在(论文说99%)延迟边界中时,这时每个请求中包含的样本数N就是系统的性能指标。如对图像分类任务,正好50ms内处理完所有(论文说99%)query,query中的样本个数N再大就处理不完了(有1%处理不完),那么这个N就是系统的性能指标

c.server

为了模拟现实生活中的随机事件,请求将以泊松分布送入被测试系统中。每个请求只有一个样本,系统的性能指标是在延迟边界(latency bound)内每秒查询次数(QPS)。

延迟边界内每秒请求次数:服务器应用场景的性能指标是泊松参数(期望?),即满足要求下的qps(每秒查询次数)值。

这个要求是对于机器视觉任务最多只能有1%的请求超时,对于翻译任务最多只能有3%的请求超时

怎样才算超时:根据任务的不同,延迟的边界在15~250ms

 

以轻量级框架的图像分类任务来举例,他的性能指标是QPS,怎样找到这个QPS呢,当QPS正好有99%的请求server可以在10ms内处理过来,有1%会超时来不及处理,QPS再大的话就会有超过1%的请求超时,这时这个QPS就是系统的性能指标

个人想法:server场景下的query之间时间间隔服从泊松分布,因此假设query的发送是均匀的,那么他的周期就是泊松分布的期望E,频率就是1/E,正好就是QPS,所以我猜想server的inference测试就是通过不断调整泊松分布的期望,来找到系统的真实负载

d.offline

一次请求将所有的测试样本送入到被测试系统中,被测试系统可以一次或多次以任何顺序返回测试结果,Offline场景的性能评判标准是每秒推理的样本数(论文中的原话是throughput measured in samples per second,单位时间的吞吐量,也就是吞吐率,所以我认为它指的是每秒处理的样本数)

server场景和offline场景都是针对数据中心的,而single-stream和multi-stream是针对边缘计算和物联网的

 

统计学置信度上的尾部延迟边界

这段有什么用?其实就是根据tail-latency来计算出测试模型需要的最少样本数

按照统计学知识,通过置信区间和尾部延迟来得到满足系统的最小推理数量(要进行多少次inference)

 置信区间上的查询需求,所有结果必须满足系统对应应用场景的最小需求

置信区间我认为是latency的置信区间(99%,也就是latency的均值加减3倍标准差)

这个99%置信区间选取的有什么意义?我是这样认为的,系统存在一个性能指标(latency),这个性能指标是切实存在的,但是我们不知道,我们的目的就是通过测试来测出他,假设我们进行测试的样本的latency满足一个正态分布,那么根据区间估计,当取latency均值加减3倍标准差时,置信区间为99%,也就是说这个客观存在的性能指标有99%的概率在我们的数据中,换句话来说就是我们的测试结果有99%的置信度。

 公式1,2求出了错误边缘和请求次数,他们之间的关系:直观理解就是自变量为tail-latency,因变量是error margin和numqueries

如当tail-latency从90%变为99%表示可以用来测试inference的sample变多了,不合格样本表少了,所以他的错误边界就变小了,同时可以用来测试的inference变多也表示numqueries变多

结合表4当tail-latency取值为90%时,用于测试inference的样本数为23886,近似估计为3x2^13,tail-latency渠道99%时,测试inference的样本数为262742,近似估计为33x2^13或者270k

 不同任务的请求数量和请求中的样本个数

最后一些其他要求:

multi-stream和server要测试多次,multi-stream的测试时间要在2.5~7h,server的测试结果要测五次取最小值

所有的benchmark运行时间最小是60s

这篇关于MLPerf Inference的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!