Inference Engine Plugin usually represents a wrapper around a backend. Backends can be:

  • OpenCL-like backend (e.g. clDNN library) for GPU devices.
  • MKLDNN backend for Intel CPU devices.

The responsibility of Inference Engine Plugin:

  • Initializes a backend and throw exception in Engine constructor if backend cannot be initialized.
  • Provides information about devices enabled by a particular backend, e.g. how many devices, their properties and so on.
  • Loads or imports executable network objects.

In addition to the Inference Engine Public API, the Inference Engine provides the Plugin API, which is a set of functions and helper classes that simplify new plugin development:

  • header files in the inference_engine/src/plugin_api directory
  • implementations in the inference_engine/src/inference_engine directory
  • symbols in the Inference Engine Core shared library

To build an Inference Engine plugin with the Plugin API, see the Inference Engine Plugin Building guide.

Plugin Class

Inference Engine Plugin API provides the helper InferenceEngine::InferencePluginInternal class recommended to use as a base class for a plugin. Based on that, declaration of a plugin class can look as follows:

namespace TemplatePlugin {
using Ptr = std::shared_ptr<Plugin>;
~Plugin() override;
void SetConfig(const std::map<std::string, std::string> &config) override;
void QueryNetwork(const InferenceEngine::ICNNNetwork &network,
const std::map<std::string, std::string>& config,
LoadExeNetworkImpl(const InferenceEngine::ICNNNetwork &network,
const std::map<std::string, std::string> &config) override;
void AddExtension(InferenceEngine::IExtensionPtr extension) override;
InferenceEngine::Parameter GetConfig(const std::string& name, const std::map<std::string, InferenceEngine::Parameter> & options) const override;
InferenceEngine::Parameter GetMetric(const std::string& name, const std::map<std::string, InferenceEngine::Parameter> & options) const override;
InferenceEngine::ExecutableNetwork ImportNetworkImpl(std::istream& model, const std::map<std::string, std::string>& config) override;
friend class ExecutableNetwork;
friend class TemplateInferRequest;
std::shared_ptr<ngraph::runtime::Backend> _backend;
Configuration _cfg;
} // namespace TemplatePlugin

Class Fields

The provided plugin class also has several fields:

  • _backend - a backend engine that is used to perform actual computations for network inference. For Template plugin ngraph::runtime::Backend is used which performs computations using ngraph reference implementations.
  • _waitExecutor - a task executor that waits for a response from a device about device tasks completion.
  • _cfg of type Configuration:
using ConfigMap = std::map<std::string, std::string>;
struct Configuration {
Configuration(const Configuration&) = default;
Configuration(Configuration&&) = default;
Configuration& operator=(const Configuration&) = default;
Configuration& operator=(Configuration&&) = default;
explicit Configuration(const ConfigMap& config, const Configuration & defaultCfg = {}, const bool throwOnUnsupported = true);
InferenceEngine::Parameter Get(const std::string& name) const;
// Plugin configuration parameters
int deviceId = 0;
bool perfCount = true;

As an example, a plugin configuration has three value parameters:

  • deviceId - particular device ID to work with. Applicable if a plugin supports more than one Template device. In this case, some plugin methods, like SetConfig, QueryNetwork, and LoadNetwork, must support the CONFIG_KEY(KEY_DEVICE_ID) parameter.
  • perfCounts - boolean value to identify whether to collect performance counters during Inference Request execution.
  • _streamsExecutorConfig - configuration of InferenceEngine::IStreamsExecutor to handle settings of multi-threaded context.

Engine Constructor

A plugin constructor must contain code that checks the ability to work with a device of the Template type. For example, if some drivers are required, the code must check driver availability. If a driver is not available (for example, OpenCL runtime is not installed in case of a GPU device or there is an improper version of a driver is on a host machine), an exception must be thrown from a plugin constructor.

A plugin must define a device name enabled via the _pluginName field of a base class:

Plugin::Plugin() {
// TODO: fill with actual device name, backend engine
_pluginName = "TEMPLATE";
// create ngraph backend which performs inference using ngraph reference implementations
_backend = ngraph::runtime::Backend::create("INTERPRETER");
// create default stream executor with a given name
_waitExecutor = ExecutorManager::getInstance()->getIdleCPUStreamsExecutor({"TemplateWaitExecutor"});


Implementation details: The base InferenceEngine::InferencePluginInternal class provides a common implementation of the public InferenceEngine::InferencePluginInternal::LoadNetwork method that calls plugin-specific LoadExeNetworkImpl, which is defined in a derived class.

This is the most important function of the Plugin class and creates an instance of compiled ExecutableNetwork, which holds a backend-dependent compiled graph in an internal representation:

const ConfigMap &config) {
auto cfg = Configuration{ config, _cfg };
InferenceEngine::InputsDataMap networkInputs;
InferenceEngine::OutputsDataMap networkOutputs;
// TODO: check with precisions supported by Template device
for (auto networkOutput : networkOutputs) {
auto output_precision = networkOutput.second->getPrecision();
if (output_precision != Precision::FP32 &&
output_precision != Precision::FP16) {
THROW_IE_EXCEPTION << "Template device supports only FP16 and FP32 output precision.";
for (auto networkInput : networkInputs) {
auto input_precision = networkInput.second->getTensorDesc().getPrecision();
if (input_precision != InferenceEngine::Precision::FP32 &&
input_precision != InferenceEngine::Precision::FP16 &&
input_precision != InferenceEngine::Precision::I16 &&
input_precision != InferenceEngine::Precision::U8) {
THROW_IE_EXCEPTION << "Input image format " << input_precision << " is not supported yet.\n"
<< "Supported formats are: FP32, FP16, I16 and U8.";
auto function = network.getFunction();
if (function == nullptr) {
THROW_IE_EXCEPTION << "TEMPLATE plugin can compile only IR v10 networks";
return std::make_shared<ExecutableNetwork>(function, cfg, std::static_pointer_cast<Plugin>(shared_from_this()));

Before a creation of an ExecutableNetwork instance via a constructor, a plugin may check if a provided InferenceEngine::ICNNNetwork object is supported by a device. In the example above, the plugin checks precision information.

The very important part before creation of ExecutableNetwork instance is to call TransformNetwork method which applies ngraph transformation passes.

Actual graph compilation is done in the ExecutableNetwork constructor. Refer to the ExecutableNetwork Implementation Guide for details.

NOTE: Actual configuration map used in ExecutableNetwork is constructed as a base plugin configuration set via Plugin::SetConfig, where some values are overwritten with config passed to Plugin::LoadExeNetworkImpl. Therefore, the config of Plugin::LoadExeNetworkImpl has a higher priority.


The function accepts a const shared pointer to ngraph::Function object and performs the following steps:

  1. Deep copies a const object to a local object, which can later be modified.
  2. Applies common and plugin-specific transformations on a copied graph to make the graph more friendly to hardware operations. For details how to write custom plugin-specific transformation, please, refer to Writing ngraph transformations guide. See detailed topics about network representation:
std::shared_ptr<ngraph::Function> TransformNetwork(const std::shared_ptr<const ngraph::Function>& function) {
// 1. Copy ngraph::Function first to apply some transformations which modify original ngraph::Function
std::vector<::ngraph::element::Type> new_types;
std::vector<::ngraph::PartialShape> new_shapes;
for (const auto &parameter : function->get_parameters()) {
auto transformedNetwork = ngraph::clone_function(*function);
// 2. Perform common optimizations and device-specific transformations
ngraph::pass::Manager passManager;
// Example: register CommonOptimizations transformation from transformations library
// Example: register plugin specific transformation
// Register any other transformations
// ..
// After `run_passes`, we have the transformed function, where operations match device operations,
// and we can create device backend-dependent graph
return transformedNetwork;

NOTE: After all these transformations, a ngraph::Function object cointains operations which can be perfectly mapped to backend kernels. E.g. if backend has kernel computing A + B operations at once, the TransformNetwork function should contain a pass which fuses operations A and B into a single custom operation A + B which fits backend kernels set.


Use the method with the HETERO mode, which allows to distribute network execution between different devices based on the ngraph::Node::get_rt_info() map, which can contain the "affinity" key. The QueryNetwork method analyzes operations of provided network and returns a list of supported operations via the InferenceEngine::QueryNetworkResult structure. The QueryNetwork firstly applies TransformNetwork passes to input ngraph::Function argument. After this, the transformed network in ideal case contains only operations are 1:1 mapped to kernels in computational backend. In this case, it's very easy to analyze which operations is supposed (_backend has a kernel for such operation or extensions for the operation is provided) and not supported (kernel is missed in _backend):

  1. Store original names of all operations in input ngraph::Function
  2. Apply TransformNetwork passes. Note, the names of operations in a transformed network can be different and we need to restore the mapping in the steps below.
  3. Construct supported and unsupported maps which contains names of original operations. Note, that since the inference is performed using ngraph reference backend, the decision whether the operation is supported or not depends on whether the latest OpenVINO opset contains such operation.
  4. QueryNetworkResult.supportedLayersMap contains only operations which are fully supported by _backend.
void Plugin::QueryNetwork(const ICNNNetwork &network, const ConfigMap& config, QueryNetworkResult &res) const {
Configuration cfg{config, _cfg, false};
auto function = network.getFunction();
if (function == nullptr) {
THROW_IE_EXCEPTION << "Template Plugin supports only ngraph cnn network representation";
// 1. First of all we should store initial input operation set
std::unordered_set<std::string> originalOps;
for (auto&& node : function->get_ops()) {
// 2. It is needed to apply all transformations as it is done in LoadExeNetworkImpl
auto transformedFunction = TransformNetwork(function);
// 3. The same input node can be transformed into supported and unsupported backend node
// So we need store as supported ether unsupported node sets
std::unordered_set<std::string> supported;
std::unordered_set<std::string> unsupported;
auto opset = ngraph::get_opset4();
for (auto&& node : transformedFunction->get_ops()) {
// Extract transformation history from transformed node as list of nodes
for (auto&& fusedLayerName : ngraph::getFusedNamesVector(node)) {
// Filter just nodes from original operation set
// TODO: fill with actual decision rules based on whether kernel is supported by backend
if (contains(originalOps, fusedLayerName)) {
if (opset.contains_type_insensitive(fusedLayerName)) {
} else {
// 4. The result set should contains just nodes from supported set
for (auto&& layerName : supported) {
if (!contains(unsupported, layerName)) {
res.supportedLayersMap.emplace(layerName, GetName());


Adds an extension of the InferenceEngine::IExtensionPtr type to a plugin. If a plugin does not support extensions, the method must throw an exception:

void Plugin::AddExtension(InferenceEngine::IExtensionPtr /*extension*/) {
// TODO: add extensions if plugin supports extensions


Sets new values for plugin configuration keys:

void Plugin::SetConfig(const ConfigMap &config) {
_cfg = Configuration{config, _cfg};

In the snippet above, the Configuration class overrides previous configuration values with the new ones. All these values are used during backend specific graph compilation and execution of inference requests.

NOTE: The function must throw an exception if it receives an unsupported configuration key.


Returns a current value for a specified configuration key:

InferenceEngine::Parameter Plugin::GetConfig(const std::string& name, const std::map<std::string, InferenceEngine::Parameter> & /*options*/) const {
return _cfg.Get(name);

The function is implemented with the Configuration::Get method, which wraps an actual configuration key value to the InferenceEngine::Parameter and returns it.

NOTE: The function must throw an exception if it receives an unsupported configuration key.


Returns a metric value for a metric with the name name. A device metric is a static type of information from a plugin about its devices or device capabilities.

Examples of metrics:

  • METRIC_KEY(AVAILABLE_DEVICES) - list of available devices that are required to implement. In this case, you can use all devices of the same Template type with automatic logic of the MULTI device plugin.
  • METRIC_KEY(FULL_DEVICE_NAME) - full device name. In this case, a particular device ID is specified in the option parameter as { CONFIG_KEY(KEY_DEVICE_ID), "deviceID" }.
  • METRIC_KEY(SUPPORTED_METRICS) - list of metrics supported by a plugin
  • METRIC_KEY(SUPPORTED_CONFIG_KEYS) - list of configuration keys supported by a plugin that affects their behavior during a backend specific graph compilation or an inference requests execution
  • METRIC_KEY(OPTIMIZATION_CAPABILITIES) - list of optimization capabilities of a device. For example, supported data types and special optimizations for them.
  • Any other device-specific metrics. In this case, place metrics declaration and possible values to a plugin-specific public header file, for example, template/template_config.hpp. The example below demonstrates the definition of a new optimization capability value specific for a device:
* @brief Defines whether current Template device instance supports hardware blocks for fast convolution computations.

The snippet below provides an example of the implementation for GetMetric:

InferenceEngine::Parameter Plugin::GetMetric(const std::string& name, const std::map<std::string, InferenceEngine::Parameter> & options) const {
std::vector<std::string> supportedMetrics = {
std::vector<std::string> configKeys = {
auto streamExecutorConfigKeys = IStreamsExecutor::Config{}.SupportedKeys();
for (auto&& configKey : streamExecutorConfigKeys) {
if (configKey != InferenceEngine::PluginConfigParams::KEY_CPU_THROUGHPUT_STREAMS) {
} else if (METRIC_KEY(AVAILABLE_DEVICES) == name) {
// TODO: fill list of available devices
std::vector<std::string> availableDevices = { "" };
} else if (METRIC_KEY(FULL_DEVICE_NAME) == name) {
std::string name = "Template Device Full Name";
// TODO: fill actual list of supported capabilities: e.g. Template device supports only FP32
std::vector<std::string> capabilities = { METRIC_VALUE(FP32) /*, TEMPLATE_METRIC_VALUE(HARDWARE_CONVOLUTION)*/ };
// TODO: fill with actual values
using uint = unsigned int;
IE_SET_METRIC_RETURN(RANGE_FOR_ASYNC_INFER_REQUESTS, std::make_tuple(uint{1}, uint{1}, uint{1}));
} else {
THROW_IE_EXCEPTION << "Unsupported device metric: " << name;

NOTE: If an unsupported metric key is passed to the function, it must throw an exception.


The importing network mechanism allows to import a previously exported backend specific graph and wrap it using an ExecutableNetwork object. This functionality is useful if backend specific graph compilation takes significant time and/or cannot be done on a target host device due to other reasons.

Implementation details: The base plugin class InferenceEngine::InferencePluginInternal implements InferenceEngine::InferencePluginInternal::ImportNetwork as follows: exports a device type (InferenceEngine::InferencePluginInternal::_pluginName) and then calls ImportNetworkImpl, which is implemented in a derived class. If a plugin cannot use the base implementation InferenceEngine::InferencePluginInternal::ImportNetwork, it can override base implementation and define an output blob structure up to its needs. This can be useful if a plugin exports a blob in a special format for integration with other frameworks where a common Inference Engine header from a base class implementation is not appropriate.

During export of backend specific graph using ExecutableNetwork::Export, a plugin may export any type of information it needs to import a compiled graph properly and check its correctness. For example, the export information may include:

  • Compilation options (state of Plugin::_cfg structure)
  • Information about a plugin and a device type to check this information later during the import and throw an exception if the model stream contains wrong data. For example, if devices have different capabilities and a graph compiled for a particular device cannot be used for another, such type of information must be stored and checked during the import.
  • Compiled backend specific graph itself
  • Information about precisions and shapes set by the user
InferenceEngine::ExecutableNetwork Plugin::ImportNetworkImpl(std::istream& model, const std::map<std::string, std::string>& config) {
// TODO: Import network from stream is not mandatory functionality;
// Can just throw an exception and remove the code below
Configuration exportedCfg;
// some code below which reads exportedCfg from `model` stream
// ..
auto cfg = Configuration(config, exportedCfg);
auto exec_network_impl = std::make_shared<ExecutableNetwork>(model, cfg, std::static_pointer_cast<Plugin>(shared_from_this()));
return make_executable_network(exec_network_impl);

Create Instance of Plugin Class

Inference Engine plugin library must export only one function creating a plugin instance using IE_DEFINE_PLUGIN_CREATE_FUNCTION macro:

static const Version version = {{2, 1}, CI_BUILD_NUMBER, "templatePlugin"};

Next step in a plugin library implementation is the ExecutableNetwork class.

Optimal implementation of IInferencePlugin interface to avoid duplication in all plugins.
Definition: ie_plugin_internal.hpp:51
virtual void getOutputsInfo(OutputsDataMap &out) const noexcept=0
virtual std::shared_ptr< ngraph::Function > getFunction() noexcept=0
#define METRIC_KEY(name)
#define IE_DEFINE_PLUGIN_CREATE_FUNCTION(PluginType, version,...)
Defines the exported CreatePluginEngine function which is used to create a plugin instance.
Definition: ie_iplugin_internal.hpp:286
#define CONFIG_KEY(name)
Defines the not implemented message.
Definition: exception2status.hpp:132
Defines IStreamsExecutor configuration.
Definition: ie_istreams_executor.hpp:50
std::shared_ptr< ExecutableNetworkInternal > Ptr
A shared pointer to ExecutableNetworkInternal object.
Definition: ie_executable_network_internal.hpp:31
std::shared_ptr< ITaskExecutor > Ptr
Definition: ie_itask_executor.hpp:51
#define IE_SET_METRIC_RETURN(name,...)
Return metric value with specified name and arguments .... Example:
Definition: ie_metric_helpers.hpp:52
#define METRIC_VALUE(name)
virtual void getInputsInfo(InputsDataMap &inputs) const noexcept=0
bool contains(const C &container, const T &element)
Simple helper function to check element presence in container container must provede stl-compliant fi...
Definition: ie_algorithm.hpp:33