メディアパイプとの統合#

サポートされているグラフ入出力ストリームのパケットタイプ#

OpenVINO モデルサーバーは、グラフの入力および出力で複数のパケットタイプの処理をサポートします。次の表に、pbtxt グラフ定義でサポートされているタグとパケットのタイプを示します:

タグが欠落している場合、OpenVINO モデルサーバーはパケットタイプが `ov::Tensor' であると想定します。ストリーム名は任意に指定できますが、慣例として小文字を使用します。

MediaPipe IMAGE 変換に必要なデータレイアウトは HWC で、サポートされる精度は次のとおりです:

注: MediaPipe ImageFrame 形式への入力のシリアル化では、KServe リクエスト内のデータを KServe API GRPC に基づく raw_input_contents フィールド、KServe API REST に基づくバイナリー拡張にカプセル化される必要があります。これは、triton-client などのクライアント・ライブラリーのデフォルト動作です。

クライアントが gRPC/REST 要求で入力を numpy 配列として送信すると、その入力はモデルサーバー側でグラフで指定された形式に逆シリアル化されます。例えば、グラフの入力タイプが IMAGE である場合、gRPC/REST クライアントは形状 (300, 300, 3) と精度 INT8 の入力データを送信できます。例えば、(1,300,300,1) などの形状でデータを送信することは、レイアウトと次元数が正しくないため許可されません。

入力グラフが OVTENSOR として設定される場合、入力の任意の形状と精度が許可されます。これは ov::Tensor オブジェクトに変換され、グラフに渡されます。例えば、入力は形状 (1,3,300,300) と精度 FP32 を持つことができます。テンソルがモデルで受け入れられない場合、計算機とグラフはエラーを返します。

gRPC 単項呼び出しと gRPC ストリーミングのコード例を確認してください。

OpenVINO モデルサーバーによるシリアル化および逆シリアル化でデータ変換を回避するオプションもあります。入力ストリームのタイプが REQUEST である場合、計算機にパススルーされます。受信側の計算機は、それを逆シリアル化し、すべてのコンテンツを解釈します。同様に、出力形式 RESPONSE は、クライアントへの完全な KServe 応答メッセージを作成する計算機に委任されます。これにより、任意のデータを raw_input_content に保存し、後でカスタム計算機でデコードできるため、データ形式に柔軟性が与えられます。

注: OpenVINOInferenceCalculator でサポートされているパケットタイプとタグのリスト (グラフの例を含む) については、OpenVINO モデルサーバーの計算機のドキュメントを確認してください。

サイドパケット#

サイドパケットは、グラフ初期化の開始時に計算機に渡すことができる特別なパラメーターです。オブジェクト検出のしきい値や処理するオブジェクト数を設定するなど、計算機の動作を調整できます。KServe API を使用すると、副入力パケットをグラフにプッシュすることもできます。これらは、KServe 要求パラメーターとして渡されます。タイプは、string、int64 または boolean にすることができます。gRPC ストリーム接続では、ストリーム内の最初の要求のみにサイド・パッケージ・パラメーターを含めることができることに注意してください。クライアント側では、以下のコード例は定義方法を示しています:

client.async_stream_infer( 
    model_name="model_name",
     inputs=[infer_input], parameters={'SIDE_PACKET_NAME': 10})

デフォルト計算機のリスト#

OpenVINO 推論計算機のほかに、モデルサーバーのパブリック Docker イメージには、デモで使用されるすべての計算機も含まれています。含まれるすべての計算機、サブグラフ、入出力ストリームハンドラーのリストは、追加パラメーター --log_level TRACE で開始されるモデルサーバーでレポートされます。

CPU と GPU の実行#

現時点では、パブリック Docker イメージに含まれる計算機は CPU 実行のみをサポートしています。これらはノード間でオブジェクトとホストメモリーからのメモリーバッファーを交換します。MediaPipe グラフでは GPU バッファーはサポートされていませんが、GPU ターゲットデバイスで推論操作を実行することはできます。入力データと応答は、GPU とホストメモリーの間で自動的に交換されます。シナリオでは、インテルのディスクリート GPU と統合 GPU に必要な依存関係が含まれているため、タグに -gpu サフィックスが付いたビルドイメージを使用してください。

GPU での完全なパイプライン実行は、将来のリリースでサポートされる予定です。

グラフとモデルをパッケージ化する方法#

さまざまな環境でのグラフ・アーティファクトの配布と展開プロセスを簡素化するために、特定のフォルダー構造を作成することを推奨します:

mediapipe_graph_name/ 
├── graph.pbtxt 
├── model1 
│   └── 1
│       ├── model.bin 
│       └── model.xml 
├── model2 
│   └── 1 
│       ├── model.bin 
│       └── model.xml 
└── subconfig.json

graph.pbtxt には、メディアパイプ・グラフの定義が含まれる必要があります。subconfig.json は、メイン・モデル・サーバーの config.json 構成ファイルの拡張機能です。サブ構成には、グラフノードで使用されるモデルの定義が含まれている必要があります。これらはモデルサーバーの初期化中にロードされ、グラフの実行開始時に使用できるようになります。付属の OpenVINO 推論セッション計算ツールには、subconfig.json で構成されたモデル名への参照が含まれている必要があります。subconfig.json の例は次のとおりです:

{ 
    "model_config_list": [ 
        {"config": { 
            "name": "model1_name", 
            "base_path": "model1" 
           } 
        } 
    ] 
}

Mediapipe サーバブルを使用して OpenVINO モデルサーバーを起動#

MediaPipe サーバブル設定は、モデル設定ファイルと同様に同じ json ファイルに配置されます。モデルは model_config_list セクションで定義されますが、グラフは mediapipe_config_list セクションで設定されます。

MediaPipe グラフ・アーティファクトが上記のようにパッケージ化されている場合、OpenVINO モデルサーバーの構成は非常にシンプルです。デプロイするグラフのリストを含む config.json を準備するだけで済みます:

{ 
    "model_config_list": [], 
    "mediapipe_config_list": [ 
    { 
        "name":"mediapipe_graph_name" 
    }, 
    { 
        "name":"mediapipe2", 
        "base_path":"non_default_path" 
    } 
    ] 
}

MediaPipe グラフ内のノードは、model_config_list セクションとサブ構成で設定されたモデルの両方を参照できます。

MediaPipe 構成オプションの説明#

サブ構成ファイルには、モデル設定ファイル と同じ形式で、model_config_list セクションのみを含めることができます。

デバッグログ#

グラフの実行を検証する最も簡単な方法は、モデルサーバーの log_level を DEBUG に設定することです。 docker run --rm -it -v $(pwd):/config openvino/model_server:latest --config_path /config/config.json --log_level DEBUG

グラフの初期化と実行から mediapipe フレームワーク内のすべての操作を詳細にレポートします。モデルサーバーのログにより、グラフの正しい形式と、必要なすべてのモデルが読み込まれていることを確認できます。グラフ定義のロードでは、すべての計算機がモデルサーバーにコンパイルされたかは確認されないことに注意してください。これは、要求を KServe エンドポイントに送信した後にテストできます。要求の処理中に、ログには計算機の初期化とノードの処理の情報が含まれます。

MediaPipe は、グラフの初期化中は入力ハンドラー設定を検証せず、グラフ作成ステージ (要求処理時) で検証することに注意してください。したがって、展開前にサンプル要求を KServe エンドポイントに送信して構成をテストすることを推奨します。

追跡#

現在、モデルサーバー側でのグラフトレースはサポートされていません。メディアパイプ・トレースを利用してグラフのボトルネックを特定する場合、メディアパイプ・アプリケーション・レベルからグラフをテストします。mediapipe の追跡に記載されている手順に従って、総合アプリと同様のサンプル・アプリケーションを構築します。

ベンチマーク#

グラフを実装してデプロイしたときに、パフォーマンスをテストにはいくつかのオプションがあります。単項要求のスループットを検証するには、ベンチマーク・クライアントを使用できます。

gRPC 接続のストリーミングには、rtsp_client を使用できます。RTSP ビデオストリーム、MPG4 ファイル、またはローカルカメラからのコンテンツに基づいて、gRPC ストリームと mediapipe グラフへの負荷を生成できます。