従来モデル・オプティマイザーの拡張性#

モデルのロード#

モデル・オプティマイザーは、トレーニングされたモデルファイルを入力として取得します。モデル・オプティマイザーのモデル・ローダー・コンポーネントは、フレームワークで提供される Python バインディングを使用してモデルファイルを読み取り、計算グラフのメモリー内表現を構築します。サポートされているフレームワークごとに個別のローダーがあります。これらのローダーは、モデル・オプティマイザーの extensions/load/<FRAMEWORK>/loader.py ファイルに実装されています。

モデルの読み込みステップの結果は Graph オブジェクトであり、次の例のように表すことができます:

モデル・オプティマイザーのローダーは、入力モデルの各操作に対して、操作インスタンスのフレームワーク記述 (通常は Protobuf メッセージ) を、通常 pb という名前でノード属性に保存します。フレームワーク固有の操作の説明であることが重要です。これは、操作 (畳み込みなど) は、Caffe フレームワークと TensorFlow フレームワークなどでは異なる方法で表現される可能性がありますが、数学的な観点からは同じ計算を行います。

上の画像では、操作 2 には 1 つの入力と 2 つの出力があります。出力ポート 0 から生成されたテンソルは、操作 5 (入力ポート 0) と操作 3 (入力ポート 1) で消費されます。出力ポート 1 から生成されたテンソルは、操作 4 (入力ポート 0) で消費されます。

各エッジには 2 つの属性があります: in と out。これには、コンシューマー・ノードの入力ポート番号とプロデューサー・ノードの出力ポート番号が含まれます。これらの属性は、ノードがいくつかの入力テンソルを消費し、いくつかの出力テンソルを生成する操作であることを説明します。モデル・オプティマイザーの観点から見ると、ノードには実行する操作に必要な情報が含まれていないため、ノード自体はブラックボックスです。

操作属性の抽出#

次のステップでは、ノード属性に保存されたフレームワーク依存の操作表現を解析し、操作固有の属性でノード属性を更新します。これを行うには 3 つのオプションがあります。

1. エクストラクター拡張アプローチ (操作の属性を抽出する推奨方法)。操作のエクストラクターで詳しく説明されています。

2. ビルトインのエクストラクターを使用した従来のアプローチ。mo/front/<FRAMEWORK>/extractor.py ファイル (例えば、Caffe 用のファイル) は、特定の操作タイプのエクストラクターを含む辞書を定義します。辞書内のキーは抽出関数をトリガーする操作タイプであり、値は関数です。この関数にはパラメーターが 1 つあり、それは属性を抽出するノードです。これは従来の拡張不可能なアプローチであるため、回避する必要があります。このメカニズムは、モデル・オプティマイザーの将来のバージョンで削除される予定です。

エクストラクターの実行順序は次のとおりです:

• CustomLayersMapping.xml (Caffe モデルのみ)。

• モデル・オプティマイザー拡張。

• ビルトインのモデル・オプティマイザー・エクストラクター。

操作属性抽出ステップの結果は、次のように表すことができます:

前のステップとのグラフの唯一の違いは、モデル・オプティマイザーに必要な、抽出された属性と操作固有の属性を含む辞書がノードに含まれていることです。ただし、このステップ以降、モデル・オプティマイザーは操作/モデルの元の表現を必要とせず、モデル・オプティマイザーの表現のみを使用します (モデル・オプティマイザーが引き続き pb 属性を使用する特殊なケースもありますが、この記事では部分的に説明します)。一般的なノード属性とその値の詳細なリストは、モデル・オプティマイザーの操作で提供されています。

フロントフェーズ#

従来の理由から、完全に定義されていないすべてのモデルの入力に対して形状を指定する必要があります。対照的に、TensorFlow などの他のマシンラーニング・フレームワークでは、未定義または部分的に定義された入力形状を使用してモデルを作成できます。例えば、未定義の次元は、TensorFlow モデルでは整数値 -1 でマークされるか、ONNX モデルでは何らかの文字列名が付加されます。

フロントフェーズでは、モデル・オプティマイザーはモデルの入力と定数の形状のみを認識し、中間テンソルの形状 (さらにランクも) を認識しません。ただし、形状に関する情報は、特定の変換を実装するのに必要ない場合があります。例えば、変換 extensions/front/TopKNormalize.py は、TopK ノードから属性 k を削除し、値 k を持つ入力定数を追加します。変換は、TopK 操作を変換するために必要です。これはフレームワークに由来しており、多くの出力要素が OpenVINO TopK 操作のセマンティクスに対する操作属性として定義されており、この値を別の入力にする必要があります。

入力または形状には実際の値が必要であるため、フロントフェーズでは変換を実行できないと思われる場合があることが重要です。形状や値の操作は、グラフに追加される操作で実装できます。extensions/front/onnx/flattenONNX_to_reshape.py の変換を考えてみましょう。これは、ONNX Flatten 操作を、以下を実行する操作のサブグラフに置き換えます (軸が 0 および 1 でない場合)。

1. ShapeOf 操作を使用して、Flatten 入力テンソルの形状を計算します。

2. Shape 操作の出力から最初の軸要素を取得し、ReduceProd 操作を使用してそれらの積を計算します。

3. ReduceProd の出力と定数を値 -1 で連結します (この値の説明については、Reshape 仕様のページを参照してください)。

4. 連結された値を Reshape 操作への 2 番目の入力として使用します。

モデルの再形状の問題を回避するため、形状に依存しない変換を行うことを強く推奨します。モデルの再形成に関する詳細については、形状推論の使用ガイドを参照してください。

フロントフェーズ変換の開発方法と専用 API の説明の詳細については、フロントフェーズ変換を参照してください。

部分推論#

モデル・オプティマイザーは、モデル変換中にモデルの部分的な推論を実行します。この手順には、モデル内のすべての操作の出力形状の計算と定数の折りたたみ (定数のサブグラフの値の計算) が含まれます。場合によっては、出力形状を計算するのに定数サブグラフの評価が必要となり、形状の推論には定数の折りたたみが必要です。例えば、Reshape 操作の出力形状は、ShapeOf 操作の出力を使用して数式として定義できます。

モデル・オプティマイザーは、モデル内のすべての操作の出力形状を計算して、中間表現ファイルに書き込みます。

モデル・オプティマイザーは、部分推論フェーズを開始する前に、計算グラフに データ ノードを挿入します。データノードは、操作で生成された特定のテンソルに対応します。各データノードには 2 つの属性が含まれます: 1 つはテンソルの形状を含む shape、もう 1 つはテンソルの実際の値を含む value です。このテンソル値を計算できない場合、value 属性の値は None に等しくなります。これは 2 つのケースで発生します。テンソル値がモデルの Parameter 操作に渡される値に依存している場合、またはモデル・オプティマイザーに操作の値伝播実装がない場合です。

部分推論を実行する前に、グラフを次の例のように描画ができます:

フロントフェーズのグラフとの構造の違いは、データノードだけでなく、エッジの属性にもあります。out 属性は操作ノードからのエッジのみに指定され、in 属性はデータノードからのエッジのみに指定されることに注意してください。これは、テンソル (データノード) が操作の特定の出力ポートから生成され、操作の特定の入力ポートで消費されます。また、操作の出力ポートごとに一意のデータノードが作成されます。このノードは、いくつかの操作ノードの入力ノードとして使用できます。データノード data2_0 と同様に、これは操作 3 の入力ポート 1 と操作 5 の入力ポート 0 で消費されます。

ここで、モデル・オプティマイザーが形状と値の伝播をどのように実行するかを考えてみます。モデル・オプティマイザーは、グラフノードのトポロジカル・ソートを実行します。グラフにサイクルが含まれる場合、エラーメッセージがスローされます。次に、トポロジー順序に従って、グラフ内の各ノードに対して形状推論関数が呼び出されます。グラフの各ノードには、形状推論関数を備えた infer 属性が必要です。これは、1 つのパラメーター (Node クラスのインスタンス) を持つ関数です。infer 属性は通常、操作エクストラクターで設定されるか、mo.pos.Op クラスから継承されたモデル・オプティマイザー操作クラスを使用して何らかの変換でノードが追加されるときに設定されます。形状推論関数を指定する方法の詳細については、モデル・オプティマイザー操作および操作エクストラクターを参照してください。

形状推論関数は、入力形状と操作 (ノード) 属性に基づいて操作 (ノード) 出力形状を計算し、対応するデータノードの shape とオプションで value 属性を更新する必要があります。Reshape 操作の形状推論関数の簡略化された例 (完全バージョンは mo/ops/reshape.py ファイルで入手可能):

 @staticmethod 
def infer(node: Node): 
     name = node.soft_get('name', node.id) 

     input_shape = node.in_port(0).data.get_shape() # get the input tensor shape 
     new_shape = node.in_port(1).data.get_value() # get the value defining the output tensor shape.This tensor may # have special values like 0 and -1 
     output_shape = ...# calculate output shape without special values like 0 and -1 

     if node.in_port(0).data.get_value() is not None: # if the input value is defined then calculate output value; # shape will be updated automatically with the value shape 

node.out_port(0).data.set_value(node.in_port(0).data.get_value().reshape(output_shape)) 
     else: # in the opposite case calculate the output shape only 
          node.out_port(0).data.set_shape(output_shape)

Node クラスのメソッド in_port() および output_port() は、データノード属性を取得および設定するのに使用されます。ポートと接続の使用方法の詳細については、ポートと接続を使用したグラフの走査と変更を参照してください。

ミドルフェーズ#

ミドルフェーズは部分推論の後に始まります。このフェーズでは、グラフにはデータノードが含まれており、グラフ内のすべての操作の出力形状が計算されています。このステージで実装された変換は、新たに追加されたすべての操作の shape 属性を更新する必要があります。ポートと接続を使用したグラフの走査と変更で説明されている API を使用することを推奨します。この API を使用してグラフを変更すると、影響を受けるノードの自動再推論と必要なデータノードの作成が行われるためです。

ミドルフェーズ変換の開発方法と専用 API の説明の詳細については、ミドルフェーズ変換を参照してください。

NHWC か​​ら NCHW へレイアウト変更#

モデルレイアウトを NHWC か​​ら NCHW に変更する中間変換がいくつかあります。TensorFlow は NHWC レイアウトでの畳み込み走査をサポートしているため、これらの変換は TensorFlow モデルに対してデフォルトでトリガーされます。

OpenVINO™ が NCHW レイアウトで実行する必要がある操作 (NHWC レイアウトの畳み込みなど) がモデルにない場合、このレイアウト変更は自動的に無効になります。

動作の詳細については、以下のプロセスの概要で説明されている変換のソースコードを参照してください:

1. モデル・オプティマイザーは、4D および 5D (4 次元および 5 次元) テンソルを生成するほとんどの操作の出力形状を、NHWC レイアウトから NCHW レイアウトに変更します: 4D の場合は nchw_shape = np.array(nhwc_shape)[0, 3, 1, 2]、5D の場合は nchw_shape = np.array(nhwc_shape)[0, 4, 1, 2, 3] です。この順列は、モデル変換中に特定された特定の条件を持つ一部の操作では発生しません。

2. モデル・オプティマイザーは、正しいレイアウトで形状計算を実行するため、形状計算に関連するサブグラフに Gather 操作を挿入します。

3. モデル・オプティマイザーは、モデル変換中に特定された特定の条件を持つ一部の演算に対して転置操作を挿入し、正しい推論結果を生成します。

レイアウト変更の原因となる主な変換は次のとおりです:

• extensions/middle/ApplyPermutations.py

• extensions/middle/InsertLayoutPropagationTransposes.py

• extensions/middle/MarkSubgraphsWithCorrectLayout.py

• extensions/middle/ApplyNHWCtoNCHWpermutation.py

• extensions/middle/LayoutChangeForConstantShapePaths.py

バックフェーズ#

バックフェーズは NCHW へのレイアウト変更後に開始します。このフェーズには主に次の変換が含まれます。

1. NCHW レイアウトのグラフで機能するため、ミドルフェーズでは実装できない変換。

2. 内部のモデル・オプティマイザー操作に対応するノードを opset 操作に対応するノードに置き換える変換。

3. 仕様に従って操作入力を正規化する変換。

4. 最終的な最適化変換。

バックフェーズのグラフ構造はミドルフェーズと同じです。ミドルとバック変換の書き方に違いはありません。

バックフェーズ変換の開発方法と専用 API の説明の詳細については、バックフェーズ変換を参照してください。

中間表現の生成#

モデル変換の最後のフェーズは、中間表現の生成です。モデル・オプティマイザーは次の手順を実行します:

1. グラフ内のすべての操作ノードを反復処理し、すべてのノードに type 属性が設定されていることを確認します。この属性は操作タイプを定義し、ノードの version 属性で指定された opset から適切な操作のインスタンス化に OpenVINO で使用されます。ノードに属性タイプがない場合、またはその値が None に等しい場合、モデル・オプティマイザーはエラーで終了します。

2. 形状推論と同様に、グラフ操作のタイプ推論を実行します。推論されたデータタイプは、IR のポート属性に保存されます。

3. グラフのトポロジカル・ソートを実行し、すべての演算ノードの id 属性を 0 から始まる連続した整数値に変更します。

4. すべての定数値を .bin ファイルに保存します。同じ値を持つ定数は、異なる操作間で共有されます。

5. グラフ構造を定義する .xml ファイルを生成します。操作の入出力に関する情報は、操作のタイプに関係なく、すべての操作に対して一律に用意されます。.xml ファイルに保存される属性のリストは、グラフノードのインスタンス化に使用される Op クラスの backend_attrs() または supported_attrs() で定義されます。操作属性を XML に保存する方法の詳細については、mo/pipeline/common.py ファイルの関数 prepare_emit_ir() およびモデル・オプティマイザーの操作に関する記事を参照してください。