566
社区成员
发帖
与我相关
我的任务
分享基于openvino 2019R3的INT8推理(inference)性能的深入研究 (二) MobilenetV3
接下来是个失败的例子 MoiblenetV3
老规矩，先下模型，转换模型，再测benchmark
从这里下载模型https://github.com/tensorflow/models/tree/master/research/slim/nets/mobilenet 下载Large dm=1 (float)这个模型，然后转换成OpenVINO FP32模型
python "c:\Program Files (x86)\IntelSWTools\openvino\deployment_tools\model_optimizer\mo_tf.py" --reverse_input_channels --input_shape=[1,224,224,3] --input=input --mean_values=input[127.5,127.5,127.5] --scale_values=input[127.5] --output=MobilenetV3/Predictions/Softmax --input_model=v3-large_224_1.0_float.pb
Benchmark FP32模型
benchmark_app.exe -m mobilenetV3\FP32\v3-large_224_1.0_float.xml -nireq 1 -nstreams 1 -b 1 -pc
转换INT8模型
python "c:\Program Files (x86)\IntelSWTools\openvino\deployment_tools\tools\calibration_tool\calibrate.py" -sm -m v3-large_224_1.0_float.xml -e C:\Users\???\Documents\Intel\OpenVINO\inference_engine_samples_build\intel64\Release\cpu_extension.dll
Benchmark INT8模型
benchmark_app.exe -m mobilenetV3\u8\v3-large_224_1.0_float_i8.xml -nireq 1 -nstreams 1 -b 1 -pc
直接上结果吧
FP32的
Full device name: Intel(R) Core(TM) i5-7440HQ CPU @ 2.80GHz
Count: 7882 iterations
Duration: 60011.97 ms
Latency: 6.37 ms
Throughput: 131.34 FPS
INT8
Full device name: Intel(R) Core(TM) i5-7440HQ CPU @ 2.80GHz
Count: 3529 iterations
Duration: 60022.03 ms
Latency: 16.26 ms
Throughput: 58.80 FPS
这个可是真的是大踏步的倒退啊，不仅INT8的卷积时间长，而且增加了68层的Reorder层，说明推理时在不停的在INT8和FP32间反复切换。
没办法，一个问题一个问题的找原因。
INT8卷积时间长
把Convolution层的时间都拉出来，发现里面depthwise Convolution都是基于gemm_blas_I8的计算, 时间超长。查了下OpenVINO 2019 Release Notes Known issue 23有这个问题，估计在2020版本里会解决
增加了68层的Reorder层
参照一下卷积的计算类型，再查一下MKL-DNN的文档，MKL-DNN在做FP32卷积的时候，首选的内存排列方式是nChw8c，而INT8卷积喜欢的内存排列是nhwc，所以为了提高卷积计算的效率，不同精度的卷积计算间都要插入一个Reorder来重新调整数据格式。
为什么MobilenetV2没有这个问题？再对比一下mobilenet v2/v3的网络架构
原来是mobilnetV3换了新的激活函数 h-swish[x] (MobilenetV2是Relu6)
估计OpenVINO和MKL-DNN还没有对这种新的算法做处理，导致卷积出来的基于INT8的x不知道怎么加那个3 (同样需要转成INT8). 所以没办法， INT8的x只能转回到FP32域去继续做激活函数，没办法像mobilenetV2一样利用MKL-DNN的post-ops做合并和优化。
到这里，基本上就可以放弃了，看来OpenVINO 2019R3在算法上就缺少对mobilenetV3新激活函数算法的支持，只能等今后的更新了 :)
最后手欠了一下, 直接从官网下载了8-bit的模型Large dm=1 (8-bit) ，转出来看看效率，直接上结果：比calibration tool转出来的int8模型效率还低。一样的原因, 基于gemm_blas_I8的卷积和过多的Reorder层小号了大量的时间
tensorflow 8-bit模型直转:
最后总结一下目前看到的评估OpenVINO2019R3 INT8模型效率的基本逻辑
首先这个模型需要包含大量的卷积层，并且占模型推理的主要时间，这种模型才有转INT8提高性能的可能性
用calibration tool(calibrate.py -sm) 快速转出一个INT8模型
转换后网络层不能增加太多，标志着没有过多的FP32/INT8之间的数据转换，这样的模型通常比较适合INT8优化
用benchmark -api sync跑一下, 对比FP32模型实际看看有没有实际性能提升
3. 如果上述2步有很好的性能提升结果的话再做完整的calibrate转换，最终模型因为要保证精度，可能会有一些性能下降
4. 有时候直接转换原始的int8模型并不能带来太好的性能提升
5. 如果不介意OpenVINO版本，可以同步测试一下OpenVINO 最新版本的性能，从2020版的Release notes上看，INT8的部分的算法改动比较大，另外Calibration Tool也升级到了POT，需要重新学习, 那个Gemm_blas_l8卷积速度慢的问题可能也会在某个新版本里解决 (我个人喜欢用老的稳定版本，新版本出来以后通常等几个月再玩，以免趟雷）
6. 等OpenVINO支持GPU int8计算以后，需要重新研究一下性能，因为GPU做卷积可能不需要reorder, 也不需要那个gemm_blas_I8的算法
老规矩，先下模型，转换模型，再测benchmark
从这里下载模型https://github.com/tensorflow/models/tree/master/research/slim/nets/mobilenet 下载Large dm=1 (float)这个模型，然后转换成OpenVINO FP32模型
python "c:\Program Files (x86)\IntelSWTools\openvino\deployment_tools\model_optimizer\mo_tf.py" --reverse_input_channels --input_shape=[1,224,224,3] --input=input --mean_values=input[127.5,127.5,127.5] --scale_values=input[127.5] --output=MobilenetV3/Predictions/Softmax --input_model=v3-large_224_1.0_float.pb
Benchmark FP32模型
benchmark_app.exe -m mobilenetV3\FP32\v3-large_224_1.0_float.xml -nireq 1 -nstreams 1 -b 1 -pc
转换INT8模型
python "c:\Program Files (x86)\IntelSWTools\openvino\deployment_tools\tools\calibration_tool\calibrate.py" -sm -m v3-large_224_1.0_float.xml -e C:\Users\???\Documents\Intel\OpenVINO\inference_engine_samples_build\intel64\Release\cpu_extension.dll
Benchmark INT8模型
benchmark_app.exe -m mobilenetV3\u8\v3-large_224_1.0_float_i8.xml -nireq 1 -nstreams 1 -b 1 -pc
直接上结果吧
FP32的
Full device name: Intel(R) Core(TM) i5-7440HQ CPU @ 2.80GHz
Count: 7882 iterations
Duration: 60011.97 ms
Latency: 6.37 ms
Throughput: 131.34 FPS
INT8
Full device name: Intel(R) Core(TM) i5-7440HQ CPU @ 2.80GHz
Count: 3529 iterations
Duration: 60022.03 ms
Latency: 16.26 ms
Throughput: 58.80 FPS
这个可是真的是大踏步的倒退啊，不仅INT8的卷积时间长，而且增加了68层的Reorder层，说明推理时在不停的在INT8和FP32间反复切换。
没办法，一个问题一个问题的找原因。
INT8卷积时间长
把Convolution层的时间都拉出来，发现里面depthwise Convolution都是基于gemm_blas_I8的计算, 时间超长。查了下OpenVINO 2019 Release Notes Known issue 23有这个问题，估计在2020版本里会解决
增加了68层的Reorder层
参照一下卷积的计算类型，再查一下MKL-DNN的文档，MKL-DNN在做FP32卷积的时候，首选的内存排列方式是nChw8c，而INT8卷积喜欢的内存排列是nhwc，所以为了提高卷积计算的效率，不同精度的卷积计算间都要插入一个Reorder来重新调整数据格式。
为什么MobilenetV2没有这个问题？再对比一下mobilenet v2/v3的网络架构
原来是mobilnetV3换了新的激活函数 h-swish[x] (MobilenetV2是Relu6)
估计OpenVINO和MKL-DNN还没有对这种新的算法做处理，导致卷积出来的基于INT8的x不知道怎么加那个3 (同样需要转成INT8). 所以没办法， INT8的x只能转回到FP32域去继续做激活函数，没办法像mobilenetV2一样利用MKL-DNN的post-ops做合并和优化。
到这里，基本上就可以放弃了，看来OpenVINO 2019R3在算法上就缺少对mobilenetV3新激活函数算法的支持，只能等今后的更新了 :)
最后手欠了一下, 直接从官网下载了8-bit的模型Large dm=1 (8-bit) ，转出来看看效率，直接上结果：比calibration tool转出来的int8模型效率还低。一样的原因, 基于gemm_blas_I8的卷积和过多的Reorder层小号了大量的时间
tensorflow 8-bit模型直转:
最后总结一下目前看到的评估OpenVINO2019R3 INT8模型效率的基本逻辑
首先这个模型需要包含大量的卷积层，并且占模型推理的主要时间，这种模型才有转INT8提高性能的可能性
用calibration tool(calibrate.py -sm) 快速转出一个INT8模型
转换后网络层不能增加太多，标志着没有过多的FP32/INT8之间的数据转换，这样的模型通常比较适合INT8优化
用benchmark -api sync跑一下, 对比FP32模型实际看看有没有实际性能提升
3. 如果上述2步有很好的性能提升结果的话再做完整的calibrate转换，最终模型因为要保证精度，可能会有一些性能下降
4. 有时候直接转换原始的int8模型并不能带来太好的性能提升
5. 如果不介意OpenVINO版本，可以同步测试一下OpenVINO 最新版本的性能，从2020版的Release notes上看，INT8的部分的算法改动比较大，另外Calibration Tool也升级到了POT，需要重新学习, 那个Gemm_blas_l8卷积速度慢的问题可能也会在某个新版本里解决 (我个人喜欢用老的稳定版本，新版本出来以后通常等几个月再玩，以免趟雷）
6. 等OpenVINO支持GPU int8计算以后，需要重新研究一下性能，因为GPU做卷积可能不需要reorder, 也不需要那个gemm_blas_I8的算法
...全文
