当前位置: 代码迷 >> 综合 >> 基于openvino 2019R3的推理性能优化的学习与分析 (五) 基于CPU/GPU混合运算的推理(inference)性能分析
  详细解决方案

基于openvino 2019R3的推理性能优化的学习与分析 (五) 基于CPU/GPU混合运算的推理(inference)性能分析

热度:77   发布时间:2024-01-12 21:17:38.0

最近读到这么一篇文章 Automatic Multi-Device Inference with Intel? Distribution of OpenVINO? toolkit ,号称使用CPU/GPU协同运算做推理,可以大幅度提高推理能力。

以mobilenet-ssd为例,文中附上了一个性能数据对比

CPU/GPU一起推理后的性能相对只用CPU推理,性能提高了到了0.79/0.64=1.234 也就是提高了大约23.4%

下面我们来实测一下

 

所谓的混合模式,实际就是在step 7的时候,调用ie.LoadNetwork时参数device_name传进去的参数为"MULTI:CPU, GPU", 这样LoadNetwork会把模型数据同时加载进CPU, GPU或者其他指定的硬件里。

        // ----------------- 7. Loading the model to the device --------------------------------------------------------next_step();std::map<std::string, std::string> config = {
   { CONFIG_KEY(PERF_COUNT), perf_counts ? CONFIG_VALUE(YES) :CONFIG_VALUE(NO) }};startTime = Time::now();ExecutableNetwork exeNetwork = ie.LoadNetwork(cnnNetwork, device_name, config);duration_ms = float_to_string(get_total_ms_time());slog::info << "Load network took " << duration_ms << " ms" << slog::endl;if (statistics)statistics->addParameters(StatisticsReport::Category::EXECUTION_RESULTS,{{"load network time (ms)", duration_ms}});

首先是FP32模型, 当Batch size =1时

  • benchmark_app设置CPU_THROUGHPUT_STREAMS = CPU_THROUGHPUT_AUTO,GPU_THROUGHPUT_STREAMS = GPU_THROUGHPUT_AUTO时,得到openvino建议的CPU的nstream数为4, GPU的nstream数为2, 下面对应的number of ireq并发数为8 , 即同时并发8个推理请求

此时FPS为102, 相对与CPU的97FPS, 性能提升并不大,同时可以看到统计8路infer request的latency时间明显不一样,有4路比较慢,有4路比较快,速度基本相差1倍左右,应该是CPU和GPU推理的速度不同;同时也可以看出,8个infer request推理的时间也是动态变化的,并不是某个infer request句柄就是固定对应的CPU推理,某个句柄就是固定对应的GPU推理。

 

接下来是FP16模型, 当Batch size =1时

  • benchmark_app设置CPU_THROUGHPUT_STREAMS = CPU_THROUGHPUT_AUTO,GPU_THROUGHPUT_STREAMS = GPU_THROUGHPUT_AUTO时,得到openvino建议的CPU的nstream数为4, GPU的nstream数为2, 下面对应的number of ireq并发数为8 , 即同时并发8个推理请求

114FPS, 好于FP32模型推理,应该是GPU部分节省了一部分内存带宽的开销导致性能提升。但是和纯GPU FP16模型推理的133FPS还差很多。

为了找原因,祭出一个免费大杀器 Intel? Graphics Performance Analyzers, 这个工具可以实时看到CPU,GPU里各种资源占用的情况。先看看默认的CPU_THROUGHPUT_STREAMS = CPU_THROUGHPUT_AUTO,GPU_THROUGHPUT_STREAMS = GPU_THROUGHPUT_AUTO模式, 这里的cpu:4 gpu:4指的是cpu有4路并发,gpu有4路并发,一共8路

可以看到推理时 CPU已经100%耗干了,但是GPU的频率还在500Hz左右晃悠,同时占用率也就在50%左右。说明推理计算的主力还在CPU这边,GPU只是抽空来干点活,不知道是内存带宽不够还是没有CPU资源给GPU喂数据了,导致基本半闲置状态。所谓的性能提升从CPU FP32 97FPS到Multi FP32 102FPS, 也就是GPU帮忙干了点活;同时Multi FP16的114FPS 高于Multi FP32的102FPS, 也就是因为GPU在FP16计算的效率更高而已。

 

再试试把并发数降下来,从1路推理,到2路推理并发再到4路推理并发,GPA输出如下

非常有趣,可以看到随着并发数的增加,CPU的占用率逐渐升高,GPU一直在闲置

 

再增加并发数

当并发数从5开始,GPU开始参与到推理计算里。

所以可以基本认为,使用MULTI:CPU, GPU参数,并且全部使用XXX_THROUGHPUT_AUTO参数时,推理引擎的调度逻辑是先把CPU的资源跑满(并发<=4路)再开始使用GPU资源(并发>4路)

 

这在实际使用中是一个很麻烦的事情,我们没法知道当前创建的多个infer request的句柄哪个是对应CPU,哪个是对应GPU,完全是IE引擎自己控制

	for (int i = 0; i < nireq; i++){inferRequest[i] = exeNetwork.CreateInferRequest();}

所以只能想办法减少CPU infer request的数量,比如通过手工设置cpu_nstream的数量,先试试cpu nireq = 1, gpu nireq =4, FP16模型

// ----------------- 6. Setting device configuration -----------------------------------------------------------ie.SetConfig({ { CONFIG_KEY(CPU_BIND_THREAD), "NO" } }, "CPU");std::cout << " CPU_BIND_THREAD :" << ie.GetConfig("CPU", CONFIG_KEY(CPU_BIND_THREAD)).as<std::string>() << std::endl;// for CPU execution, more throughput-oriented execution via streams//ie.SetConfig({ { CONFIG_KEY(CPU_THROUGHPUT_STREAMS),"CPU_THROUGHPUT_AUTO" } }, "CPU");ie.SetConfig({ { CONFIG_KEY(CPU_THROUGHPUT_STREAMS),std::to_string(1) } }, "CPU");cpu_nstreams = std::stoi(ie.GetConfig("CPU", CONFIG_KEY(CPU_THROUGHPUT_STREAMS)).as<std::string>());std::cout << "CPU_THROUGHPUT_AUTO: Number of CPU streams = " << cpu_nstreams << std::endl;//for GPU inference//ie.SetConfig({ { CONFIG_KEY(GPU_THROUGHPUT_STREAMS),"GPU_THROUGHPUT_AUTO" } }, "GPU");ie.SetConfig({ { CONFIG_KEY(GPU_THROUGHPUT_STREAMS),"4" } }, "GPU");gpu_nstreams = std::stoi(ie.GetConfig("GPU", CONFIG_KEY(GPU_THROUGHPUT_STREAMS)).as<std::string>());std::cout << "GPU_THROUGHPUT_AUTO: Number of GPU streams = " << gpu_nstreams << std::endl;ie.SetConfig({ { CLDNN_CONFIG_KEY(PLUGIN_THROTTLE), "1" } }, "GPU");std::cout << "CLDNN_CONFIG_KEY(PLUGIN_THROTTLE), 1" << std::endl;

 

GPA输出

效果不是一般的好,GPU和CPU都跑满,FPS到了139

 

再增大cpu_nireq到2, gpu_nireq还是4路,总共6路并发

效果还不如上面的5路并发,可能是CPU只能做效率低下的FP32的推理,过多的CPU推理反而会拉低FPS, 同时可以看到红框部分有一个明显的帧率下降,这时候可以听到CPU的风扇开始狂响,应该是开始过热了。

 

经过反复测试并发数,在我这个4核CPU的笔记本上,测到了一个最高的值

FP16, CPU 1路并发, GPU 2路并发,最高可以到150FPS。看来堆数量不是重点,简单高效才是好

 

另外一个提高效率的方法是让IE引擎优先调度GPU资源,然后再CPU,具体的方法是调用ie.LoadNetwork时参数device_name传进去的参数为"MULTI:GPU, CPU"  并发数量上还是多GPU办事,少CPU填缝的原则

 

简单总结一下,OpenVINO的CPU/GPU混合推理

  1. 资源分配上优先使用GPU,CPU只用来做一些锦上添花的补充
  2. 尽量少用CPU,以免造成CPU过热引起的性能下降
  3. 尽量使用FP16模型,因为GPU喜欢
  4. 合理使用MULTI:CPU,GPU 和 MULTI:GPU,CPU参数来改变调度优先级
  5. 混合推理时,每路推理的完成时间会很不一样,有可能出现严重的后发先至或者先发后至。所以处理推理结果时候会更麻烦
  6. 在目前我看到的使用集成显卡的处理器上,尽量不要尝试CPU/GPU混合推理,首先是CPU/GPU是共享内存带宽,对于那些内存带宽密集型的模型性能提升不大,有2辆拉货的车,但是是单车道马路,只能大家排队一个一个走;其次是CPU和集成显卡共享TDP,处理器本身的TDP要被平均分开给CPU和集成显卡,一个硬件用的功耗大了,另一个硬件势必分配的功耗就会低,实际上有劲使不上。
  相关解决方案