モデルサーバーの設定#
単一モデルの提供は、OpenVINO™ モデルサーバーをデプロイする最も簡単な方法です。単一モデルのみが提供され、構成全体が CLI パラメーターを介して渡されます。単一モデルを提供している間は、実行時に構成を変更できないことに注意してください。複数のモデルを提供するには、すべてのモデルの設定を保存する構成ファイルが必要です。構成ファイルを使用してモデルをデプロイする場合、サーバーを再起動することなく、モデルを追加、削除したり、実行時に構成を更新することができます。
単一モデルのサービング#
コンテナを開始する前に、モデルを提供する準備ができていることを確認してください。
パラメーターを指定し次のコマンドを実行して、モデルサーバーを起動します:
docker run -d --rm -v <models_repository>:/models -p 9000:9000 -p 8000:8000 openvino/model_server:latest \ --model_path <path_to_model> --model_name <model_name> --port 9000 --rest_port 8000 --log_level DEBUGResNet モデルを使用した例:
mkdir -p models/resnet/1
wget -P models/resnet/1 https://storage.openvinotoolkit.org/repositories/open_model_zoo/2022.1/models_bin/2/resnet50-binary-0001/FP32-INT1/resnet50-binary-0001.bin
wget -P models/resnet/1 https://storage.openvinotoolkit.org/repositories/open_model_zoo/2022.1/models_bin/2/resnet50-binary-0001/FP32-INT1/resnet50-binary-0001.xml
docker run -d --rm -v ${PWD}/models:/models -p 9000:9000 -p 8000:8000 openvino/model_server:latest \ --model_path /models/resnet/ --model_name resnet --port 9000 --rest_port 8000 --log_level DEBUG必要なモデルサーバーのパラメーターを以下に示します。追加の構成オプションについては、モデルサーバーのパラメーターを参照してください。
オプション |
説明 |
|---|---|
|
Docker コンテナを終了するときにコンテナを削除します |
|
コンテナをバックグラウンドで実行します |
|
Docker コンテナにモデルフォルダーをマウントする方法を定義します |
|
モデルの提供ポートを Docker コンテナ外部に公開します |
|
イメージ名を表します。ovms バイナリーは Docker エントリーポイントです |
|
モデルの場所を指定します |
|
model_path 内のモデル名を指定します |
|
gRPC サーバーのポートを指定します |
|
REST サーバーのポートを指定します |
可能なモデルの場所 (--model_path):
起動時にマウントされる Docker コンテナのパス
Google Cloud Storage のパス
gs://<bucket>/<model_path>AWS S3 path
s3://<bucket>/<model_path>Azure blob のパス
az://<container>/<model_path>
openvino/model_server:latest はタグとビルドプロセスによって異なります - 完全なタグリストについては、タグ: https://hub.docker.com/r/openvino/model_server/tags/ を参照してください。
コンテナのポートを公開して、ホストまたは仮想マシンのポートを開きます。
上記のコマンドでは、ポート 9000 が gRPC 用に公開され、ポート 8000 が REST API 呼び出し用に公開されます。
クライアント gRPC/REST API 呼び出しの model_name を追加します。
複数モデルのサービング#
同じコンテナから複数のモデルを提供するには、各モデルを定義する JSON 構成ファイルが別途必要になります。そして、複数のモデルでコンテナを使用するには、各モデルを定義する JSON 構成ファイルが必要です。model_config_list 配列には、各モデルの構成オブジェクトのコレクションが含まれます。name と base_path 値は、構成オブジェクトそれぞれに必要です。
{
"model_config_list":[
{
"config":{
"name":"model_name1",
"base_path":"/opt/ml/models/model1",
"batch_size": "16"
}
},
{
"config":{
"name":"model_name2",
"base_path":"/opt/ml/models/model2",
"batch_size": "auto",
"model_version_policy": {"all": {}}
}
},
{
"config":{
"name":"model_name3",
"base_path":"gs://bucket/models/model3",
"model_version_policy": {"specific": { "versions":[1, 3] }},
"shape": "auto"
}
},
{
"config":{
"name":"model_name4",
"base_path":"s3://bucket/models/model4",
"shape": {
"input1": "(1,3,200,200)",
"input2": "(1,3,50,50)"
},
"plugin_config": {"PERFORMANCE_HINT": "THROUGHPUT"}
}
},
{
"config":{
"name":"model_name5",
"base_path":"s3://bucket/models/model5",
"nireq": 32,
"target_device": "GPU"
}
}
]
}Docker コンテナに構成ファイルへのパスがマウントされると、起動できるようになります。これにより、構成ファイルから引数が読み取られるため、docker run コマンドを簡素化できます。config.json の base_path にクラウド URI プリフィクスまたは / 文字が含まれていない場合、パスは構成ファイルへの相対パスになります。これは、パスを調整する必要がないため、モデルが構成ファイルと一緒に配布される場合に役立ちます。