KServe API を介したバイナリー入力の予測¶
GRPC¶
KServe API を使用すると、モデル入力データを InferTensorContents オブジェクト内または ModelInferRequest の raw_input_contents フィールドでさまざまな形式で送信できます。
データが 4 (逆多重化の場合は 5) 形状次元を持つモデルまたはパイプラインに送信され、入力 datatype が BYTES に設定されている場合、そのような入力はバイナリーエンコードされたイメージとして解釈されます。このような入力データは、bytes_contents または raw_input_contents に配置する必要があります。
データが raw_input_contents にある場合は、各バッチのデータの前に、このバッチのサイズを含む 4 バイト (リトル・エンディアン) を置く必要があります。例えば、バッチにサイズ 370、480、500 バイトの 3 つの画像が含まれる場合、raw_input_contents[index_of_the_input] の内容は次のようになります。
<0x72010000 (=370)><最初のイメージの 370 バイト><0xE0010000 (=480)><2 番目のイメージの 480 バイト> <0xF4010000 (=500)><3 番目のイメージの 500 バイト>
モデルのメタデータは NHWC レイアウトの入力形状をレポートしますが、バイナリーデータは形状: [N]、データタイプ: BYTES で送信する必要があることに注意してください。ここで、N は文字列バイトに変換された画像の数を表します。
データを配列形式で送信する場合、形状とデータタイプによって、内容のバイトを解釈する方法に関する情報が得られます。バイナリーエンコードされたデータの場合、shape フィールドによって与えられる情報は、バッチ内の画像の量だけです。サーバー側では、各バッチのバイトがロードされ、モデルの入力形状に一致するようにサイズ変更されて、OpenCV によって OpenVINO に適した配列形式に変換されます。
HTTP¶
JPEG/PNG エンコードされた画像¶
KServe API を使用すると、エンコードされた画像を HTTP インターフェイス経由で 4 (逆多重化の場合は 5) の形状次元を持つモデルまたはパイプラインに送信することもできます。GRPC 入力と同様に、このようなデータタイプの datatype は BYTES である必要があります。テンソル・バイナリー・データは、要求本文の JSON オブジェクトの後に提供されます。JSON にはデータをターゲットモデルにルーティングし、推論を適切に実行するために必要な情報が含まれていますが、データ自体はバイナリー形式で JSON の直後に配置されます。したがって、すべての画像のデータの前に、この画像のサイズを含む 4 バイト (リトル・エンディアン) を置き、binary_data_size パラメーターでそれらの結合サイズを指定する必要があります。
バイナリー入力の場合、JSON 部分の parameters マップには、入力上のデータのサイズを示す各バイナリー入力の binary_data_size フィールドが含まれます。画像の解像度と形式には厳密な制限がないため (OpenCV でロードできる限り)、画像のサイズは異なる場合があります。画像のバッチを送信するには、各バッチのデータの前に、このバッチのサイズを含む 4 バイト (リトル・エンディアン) を付けて、それらの結合サイズを binary_data_size で指定する必要があります。例えば、バッチにサイズ 370、480、500 バイトの 3 つの画像が含まれる場合、バイナリー拡張内の入力バッファーの内容は次のようになります。
<0x72010000 (=370)><最初のイメージの 370 バイト><0xE0010000 (=480)><2 番目のイメージの 480 バイト> <0xF4010000 (=500)><3 番目のイメージの 500 バイト>
その場合、binary_data_size は 1350(370 + 480 + 500) になります。REST サンプルで使用する triton クライアント・ライブラリーの関数 set_data_from_numpy は、指定された画像をこの形式に自動的に変換します。
要求に入力 binary_data_size が 1 つだけ含まれている場合は、パラメーターを省略できます。この場合、バッファー全体が入力イメージとして扱われます。
HTTP 要求ヘッダーの場合、JSON オブジェクトの長さを指定するには、Inference-Header-Content-Length ヘッダーを指定する必要があります。また、Content-Length は引き続き (HTTP の要求に応じて) 本文の長さを指定します。要求ヘッダーとバッチ内の複数の画像を使用した拡張例を参照してください。
サーバー側では、バイナリーエンコードされたデータが OpenCV を使用してロードされ、推論のため OpenVINO に適したデータ形式に変換されます。
応答の構造は推論応答仕様で指定されます。
生データ¶
上のセクションでは、REST インターフェイスを介して JPEG/PNG エンコードされた画像を送信する方法を説明しました。このように送信されたデータは OpenCV によって処理され、OpenVINO に適した形式に変換されます。多くの場合、データは OpenVINO に適した形式ですでに利用可能であり、必要なことはそれを送信して予測を取得することだけです。
KServe API を使用すると、REST インターフェイス経由で生データをバイナリー表現で送信することもできます。そうすることで要求が小さくなり、サーバー側での処理が容易になるため、RESTful API を使用する場合は、入力データを JSON オブジェクトで提供するよりもこの形式を使用するほうが効率的です。生データをバイナリー形式で送信するには、BYTES 以外の datatype とデータ shape を指定する必要があり、入力 shape と一致する必要があります (メモリーレイアウトにも互換性がある必要があります)。
生データバイナリー入力の場合、特定の入力のサイズはその形状から計算できるため、binary_data_size パラメーターを省略できます。
推奨¶
データをバイナリー形式で送信すると、クライアント・コードと前処理の負荷が大幅に軽減されます。REST API クライアントでは、curl または要求 Python パッケージのみが必要です。元の入力データが jpeg または png でエンコードされている場合、要求を送信するため前処理は必要ありません。
バイナリーデータにより、ネットワーク使用率が大幅に軽減される可能性があります。多くの場合、これにより、レイテンシーが短縮され、ネットワーク帯域幅が低い場合でも非常に高いスループットを達成できます。