再看看纯集成显卡GPU的mobilenet-ssd 的推理性能, 测试平台是i5 7440HQ, 4核4线程, GPU是Gen9 的GT2, 24EU, 属于纯大白菜集成显卡
首先是FP32模型
当Batch size =1时
- inference request(nireq) = 1时，即同时只有一个推理请求
Latency = 13.6ms, Throughtput = 73FPS, 性能还不错，是CPU的2倍多
- inference request(nireq) = 4时，即设置GPU_THROUGHPUT_STREAMS = GPU_THROUGHPUT_AUTO时，openvino建议number of stream数为2, 对应的number of ireq并发数为4 ， 同时并发4个推理请求
这个就有点尴尬了，Throughtput = 78FPS, 提升不大， 对应的CPU推理是96FPS。这时候的性能表现不如CPU。这时候每路推理的一致性还不错，每路的工作量基本一致
接下来看看batch size = 3，inference request(nireq) = 4时。即每次推理处理三张图片, 4路推理并发的情况
63FPS, 看来集成显卡资源有限，数据量一旦超出硬件的能力范围性能就会大打折扣
接下来是FP16模型
当Batch size =1时
- inference request(nireq) = 1时，即同时只有一个推理请求
Latency: 9ms, Throughtput: 113FPS, 这个数字大大高于CPU FP32的最好表现
- inference request(nireq) = 4时，即设置GPU_THROUGHPUT_STREAMS = GPU_THROUGHPUT_AUTO时，openvino建议number of stream数为2, 对应的number of ireq并发数为4 ， 同时并发4个推理请求
133FPS，看来GPU相对于CPU确实更适合做推理。同时相对于FP32的模型，因为FP16模型对内存带宽的需求减半，所以性能也是大大的提升。
还是看batch size = 3，inference request(nireq) = 4时。即每次推理处理三张图片, 4路推理并发的情况
看来还是硬件资源有限，数据一多以后处理能力就会大幅度下降。
前面都是用GPU_THROUGHPUT_STREAMS = GPU_THROUGHPUT_AUTO来测试，最后看一下手工设置GPU_THROUGHPUT_STREAMS = 1，即nstream = 1, nireq =2的情况，看看性能会不会减半
这个FPS几乎和GPU_THROUGHPUT_AUTO一样了，只有不到2%的下降，看来前2路的推理就占了GPU绝大多数的资源，GPU_THROUGHPUT_AUTO多出来的2路nireq就是为了再从蚊子腿里再找一些肉。
简单总结一下，OpenVINO的GPU推理
- 对GPU推理来说，FP16的性能大大好于FP32, 基本可以翻倍
- batch size一定要设为1，因为GPU的资源限制比CPU还多，所以一定要精打细算，少食多餐
- 推理并发数不一定非要按照GPU_THROUGHPUT_AUTO的建议值来设，并发数稍微少一些也能获得很好的性能，同时也能给其他系统应用保留更多的资源调度
- GPU推理不容易造成CPU过热降频而引起性能下降，同时也不怎么受Windows后台程序的影响。只要有足够的CPU资源给GPU喂数据，处理速度都会比较稳定
- GPU推理性能会受其他图形程序使用GPU而引起性能下降，比如推理同时调用OpenCV的imshow()显示会导致推理速度下降