前言

下面我们来一一了解这些特性和变化。

在以往的OpenVINO^™ 工具套件安装过程中，自动安装脚本会下载若干用于图像处理的第三方库，如OpenCV, DL Streamer等。当我们完成安装，我们将会得到由MO^[注1], Inference Engine Runtime, OpenCV, DL Streamer等一系列组件组成的“全家桶”合集，这样的安装方式虽然能减少开发环境的配置工作量，但同时也会带来如下的问题：

因此在2022.1新版本中，OpenVINO^™ 工具套件团队改进了这个问题，包括如下变化：

                                                      表一 OpenVINO^™ 工具套件组件对比

其中Inference Engine Runtime到OpenVINO^™ Runtime的变化，主要是指模块名称的变化，Inference Engine重命名为OpenVINO^™ Runtime，此举是为了与主流的深度学习框架保持一致的开发体验。

安装包简化后，会带来安装时间的缩短以及占用空间的明显缩小。开发者需要注意的是，像DL Streamer, OpenCV等模块，需要自己再额外安装，不再默认包含在安装包内。

此外，针对旧版本中OpenVINO^™ 工具套件的库杂乱的问题，2022.1中将原先的inference_engine,ngraph, transformations,lp_transformation,frontend_common这些库合并成了统一的runtime库，以方便开发者在应用程序中引用。

在OpenVINO^™ 工具套件的展历程中，改进易用性，做到开箱即用，一直是非常重要的发力点。在2022.1中，这一特点表现得更为明显，主要进行了performance hints, Auto-Device Plugin, MO三个方面的改进，具体说明如下：

从字面上理解，performance hints即性能提示，旨在给予开发者更友好的编程引导，以帮助开发者设置或获取与性能相关的参数。通常，我们会对应用程序的性能指标，如latency和throughput较为敏感，且以此作为优化目标；但与硬件相关的配置参数，比如CPU核数、并行处理的通道数等，则不甚了解，且这些配置参数比较抽象，较难理解，有一定的学习门槛。

借助performance hints功能，开发者无需关心配置参数，只需要设置latency或throughput的性能目标，即可由OpenVINO^™ 工具套件代劳，自动设置一系列的优化参数，以保证latency或throughput为最优解。

详细的解释大家可以上OpenVINO^™ 工具套件的开源仓库上查看benchmark tool的说明文档，其中有一个小细节，即在benchmark tool的输入参数中增加了hint参数，如下

此处的hint参数，即为performance hints功能在benchmark tool工具中的具体应用。2022.1版本中的performance hints功能支持CPU和GPU设备，也支持通过Auto-Device Plugin进行管理和调用，该功能后续还会进一步完善和发展。

从2021.4起，OpenVINO^™ 工具套件引入了Auto-Device Plugin。Auto-Device是一个全新的“虚拟”或是“代理”设备，它的其中一个功能就是帮助开发者简化开发流程，比如，将设备名称指定为“AUTO:CPU,GPU”，那么CPU和GPU（本文中的GPU均指代Intel显卡，包括iGPU和dGPU^[注4]，下同）则被添加到Auto-Device的列表中，在执行ie.load_network(model, “AUTO:CPU,GPU”)后，交由Auto-Device Plugin来智能的选择推理设备和策略。开发者甚至可以不指定具体的设备，直接在加载模型时使用”AUTO”的设备名称，则可由Auto-Device Plugin来根据模型进行硬件平台的智能匹配。

在2022.1中，”AUTO”为加载模型时的默认设备。如果开发者在加载模型阶段不指定任何的设备，则会自动采用”AUTO”作为加载设备。除此之外，AUTO-Device Plugin还增加了如下的主要功能特性：

功能1：First Inference Latency优化

对于GPU和VPU^[注5]的开发者，相信都体验过加载网络模型卡顿的问题。尤其对于GPU，执行ie.load_network(model, GPU)的操作，相比CPU而言会较为耗时，从而导致从程序的初始化到第一次完成推理的延时较长。由于2022.1中的API发生了变化，为了避免读者混淆，我们姑且不区分”load network”和”inference”这两个具体的操作，而是将应用从启动到完成第一次推理的阶段统称为“First Inference”，将这一阶段的耗时称为”First Inference Latency”。通俗的讲，First Inference Latency即是应用程序的启动时间（含初始化、加载、第一次完成推理等所有时间的总和）。

在2022.1中，Auto-Device plugin采取了一系列策略对GPU和VPU的First Inference Latency进行了优化。以GPU举例，当开发者通过GPU插件难以获得满意的First Inference Latency时，可简单将加载的设备修改为auto插件，如”AUTO“，从而达到延时的明显改善。虽然在之前的版本中，OpenVINO^™ 工具套件也提供了cache的功能来解决load_network耗时较长的问题，但相比较而言，Auto-Device plugin的方式更为简单友好，开发者不用关心具体的调用逻辑，大量的优化工作都由Auto-Device插件完成。

需要注意的是，此优化策略需要CPU的参与，其基本原理为：Auto-Device会缺省在GPU或者VPU进行网络加载的过程当中，利用CPU进行初始的推理运算，实现对第一帧推理的快速响应。当GPU或者VPU网络加载成功后，推理运算会自动迁移到GPU或者VPU上进行。因此该优化适用于看重应用程序启动时间且CPU有空闲算力的场景，开发者可尝试使用此功能改进在GPU和VPU上的首次推理响应时间。

功能2：完全支持performance hints功能

performance hints功能在Auto-Device插件上得到了完全支持。

功能3：集成dynamic shape, auto-batching功能

dynamic shape即动态输入，在本文的第3小节”动态输入支持”中会进行说明。除CPU插件外，Auto-Device 插件也已支持此功能。

auto-batching即自动批处理，对于GPU尤其是dGPU上的开发者，选择合适的batch size以充分发挥GPU性能是非常重要的部分。如果batch size过小，则无法将GPU性能跑满；但是如果将batch size设得过大而内存不够，则会发生代码崩溃等异常。除此之外，不同的设备往往需要设置不同的batch size，因此比起将batch size设置为固定值，需要一种更加灵活的方式来方便设置不同的batch size。而auto batching的设计理念就是为了解决上述问题。目前auto-batching的支持为雏形状态，在Auto-Device中，提供了开关对于auto-batching进行设置。这一特性会在后续版本中进行优化和改进。

MO作为模型转换工具，需要指定的转换参数较多且繁琐，对比其它同类型工具，对开发者的要求较高。目前存在于开源项目issue里的问题，超60%为MO的问题^[注6]。因此在2022.1中，针对MO不易于上手的问题，对转换参数进行了一系列简化，比如开发者不需要再指定”input_shapes”和”disable_nhwc_to_nchw”，同时针对tensorflow 模型的转换参数也有所简化。更多的细节，可待正式版本发布后读者们自行探索。

阶段性总结一下，易用性提升是OpenVINO^™ 工具套件发展的一个大方向，在今后的版本中，还会继续对包括安装、使用参数、示例等帮助开发者迅速上手的方向发力，改善用户体验。

这应该是目前为止在OpenVINO^™ 工具套件2022.1新特性中大家讨论最为热烈也最为期待的特性了。动态输入（dynamic shape）是深度学习框架的一个很重要的特性：在模型训练时，某些维度不是固定大小，而是用’-1’或’?’来表示；在推理阶段根据实际输入的大小去动态的调整模型大小，进行结果预测，即模型具有自适应性。主流的深度学习框架，如Tensorflow, PyTorch均支持这个特性。

而OpenVINO^™ 工具套件由于底层插件的限制，一直无法很好的支持动态输入，在MO转换阶段就要求所有的张量尺寸必须是固定大小的；在推理阶段，虽然也可以通过’reshape’功能改变模型的尺寸，但存在速度慢、算子不支持等诸多限制因素，因此也制约了OpenVINO^™ 工具套件在需要动态输入的场景如OCR下的应用与发展。

激动人心的是，动态输入将会从2022.1版本开始支持，分阶段开发及实施。首先，在2022.1版本中会在CPU插件上支持这一功能，之后逐步发展到其它插件上。这个特性的支持分为两个部分，一个是MO的变化，另一个是Runtime的变化，请看如下的解析。

旧的MO需要通过--input_shape来固定模型的尺寸为静态尺寸，而在新MO中，这一步不是必须的。开发者可以选择不指定--input_shape，则原始模型中的’?’会予以保留；或者通过--input_shape [1..10,224,224]的写法，将第一个维度(一般是batch size)的值限定在1-10之间。同时，开发者也会观察到IR文件版本发生了变化，由2021的version 10进化为2022的version 11.

Runtime的变化主要体现在API上。具体来讲会引入ngraph的partial shape概念，动态可变的shape将会通过partial shape这个类来操作，关于partial shape，请详见下列的说明：

https://github.com/openvinotoolkit/openvino/blob/master/docs/nGraph_DG/nGraph_Python_API.md

另外，如果对runtime输入的是旧版本的IR文件，即IR版本号小于或等于10，OpenVINO^™ 工具套件仍然可以正常推理，但dynamic shape的功能不会启动。因此如果想使用到dynamic shape功能，一定要使用新版本的MO重新将原始模型进行转换，转换后的IR版本号为11。

从OpenVINO^™ 工具套件2022.1开始，官方将开启Paddle Paddle模型的正式支持。此前OpenVINO^™ 工具套件对Paddle Paddle的支持需要借助于ONNX，即需要先将Paddle Paddle模型转换为ONNX格式，再走OpenVINO^™ 工具套件中的ONNX支持通道。而在2022.1中，不再需要ONNX作为媒介，OpenVINO^™ 工具套件可以直接支持Paddle Paddle，具体有如下两种路径：

上述路径与ONNX的支持路径是相似的。这也展示了OpenVINO^™ 工具套件的发展理念，即加强与其它深度学习框架的合作，创建更为包容、多样化的生态，方便开发者接入自己的模型及应用程序。

除了与Paddle Paddle模型的集成更加方便之外，OpenVINO^™ 工具套件也着力于加强对Paddle Paddle模型的多样性支持。在2022.1版本中，Paddle Paddle的网络支持涵盖了视觉检测识辨，OCR，自然语言处理等类型的网络。在接下来的规划中，会进一步扩大网络支持的范畴以及不同硬件平台的支持。

现有的OpenVINO^™ API存在一系列问题，比如 OpenVINO^™ 工具套件有自己的一套tensor的命名规则，导致原生框架里读出的tensor可能叫output1，而OpenVINO^™ 工具套件里叫aaa/bbb/argmax1之类的名称，与原生框架不一致；再比如blob API存在一些不合理的地方，以c++为例，调用GetBlob会返回一个指向blob的指针，但是这个blob还需要被强转成MemoryBlob类型才可被使用，十分的别扭，代码详见object_detection_sample_ssd/main.cpp。这些只是若干问题中的一部分，为了改进这些不合理的地方，方便开发者更容易的将应用程序迁移到OpenVINO^™ 工具套件上，同时也为支持dynamic shape功能，2022.1进行了API的改进，主要包括：

old main.cpp（详见:

https://github.com/openvinotoolkit/openvino/blob/releases/2021/4/inference-engine/samples/object_detection_sample_ssd/main.cpp）              

new main.cpp （详见：

httphttps://github.com/openvinotoolkit/openvino/blob/master/samples/cpp/hello_reshape_ssd/main.cpp） 

old hello_reshape_ssd.py（详见：

https://github.com/openvinotoolkit/openvino/blob/releases/2021/4/inference-engine/ie_bridges/python/sample/hello_reshape_ssd/hello_reshape_ssd.py）     

new hello reshape_ssd.py（详见：

https://github.com/openvinotoolkit/openvino/blob/master/samples/python/hello_reshape_ssd/hello_reshape_ssd.py）

old hello_reshape_ssd.py（详见：

https://github.com/openvinotoolkit/openvino/blob/releases/2021/4/inference-engine/ie_bridges/python/sample/hello_reshape_ssd/hello_reshape_ssd.py）    

new hello reshape_ssd.py（详见：

https://github.com/openvinotoolkit/openvino/blob/master/samples/python/hello_reshape_ssd/hello_reshape_ssd.py）

从开发者层面来说，API改进会带来程序升级的麻烦，所以这并不是受欢迎的改进。正如我前面提到的，此次API改进，本质上是为了与其它深度学习框架更好的保持一致性，方便其它框架的程序能顺利的接入OpenVINO^™ 工具套件，所以长远来看是简化了开发集成工作的。

虽然引入了新的API，但2022.1仍可兼容旧的API，如果不需要dynamic shape功能，开发者可以继续使用旧的API，无需对已开发好的应用程序进行任何修改。同时，旧API会和新API并存一段时间（根据以往经验看，一般有一年左右的过渡期），为开发者从旧API往新API迁移提供足够的缓冲。

除以上四个主要特性，2022.1中还针对易用性增加了许多的小细节，比如会同步推出新API相关的notebook(https://github.com/openvinotoolkit/openvino_notebooks)，针对dynamic shape等重要的特性会开辟专门的文档版块进行介绍，敬请期待。

大家也可以给我们留言对哪些特性感兴趣，后续将会根据大家的留言有针对性的展开新特性的深入介绍。快来给我们留言吧！

注释：

注1：MO代表Model Optimizer, 即模型优化器。

注2：POT代表Post Optimization Tools，为OpenVINO^™ 工具套件中提供的模型低精度量化工具。DLWB为DL Workbench的缩写，为OpenVINO^™ 工具套件中提供的用于模型转换、评价、量化、调优的一站式图形化平台；OMZ为Open Model Zoo的缩写，为OpenVINO^™ 工具套件官方支持的模型及应用示例合集。

注3：One VPL代表Intel^® oneAPI Video Processing Library，即一套用于视频编解码处理的编程接口。

注4：iGPU代表Intel^® intergrated GPU，即集成显示；dGPU代表Intel® discrete GPU，即独立显卡。

注5：VPU指Intel^® Movidius^™ Vision Processing Units

注6：github上的issue

（https://github.com/openvinotoolkit/openvino/issues），截止到2021年12月20号为止，所有的包括已关闭的issue数量为1067个，其中被标记为MO的问题共有711个，MO问题占总issue数的66.6%。

参考链接：

• https://www.intel.com/content/www/us/en/develop/documentation/oneapi-programming-guide/top/api-based-programming/intel-oneapi-video-processing-library-onevpl.h^™l

• https://en.*********.org/wiki/List_of_Intel_graphics_processing_units

• https://github.com/openvinotoolkit/open_model_zoo

• https://github.com/openvinotoolkit/openvino

• https://www.intel.cn/content/www/cn/zh/products/details/processor***ovidius-vpu.h^™l

* 本文内容及配图均为“英特尔物联网”的原创内容。该公众号的运营主体拥有上述内容的著作权或相应许可。除在微信朋友圈分享之外，如未经该运营主体书面同意，请勿转载、转帖或以其他任何方式**、发表或发布上述内容。如需转载上述内容或其中任何部分，请留言联系。