トラブルシューティング

モデルインポートの問題

OpenVINO™ モデルサーバーは、設定されたバージョンポリシーに従って、定義されたすべてのモデルのバージョンをロードします。モデルバージョンは、拡張子 .bin および .xml を持つ OpenVINO モデルファイルを含むモデルパス内の数値ディレクトリーによって示されます。

新しいモデルバージョンが検出されると、サーバーはモデルファイルをロードし、新しいモデルバージョンのサービスを開始します。この操作は、次の理由で失敗することがあります。

  • モデルファイルへのアクセスに問題がある場合 (リモートストレージへのネットワーク接続の問題または権限が不十分であるため)。

  • モデルファイルの形式が正しくないため、OpenVINO™ ランタイムでインポートできない場合。

  • モデルにカスタム CPU 拡張機能が必要な場合。

以下に誤った構造の例を示します。

models/
├── model1
│   ├── 1
│   │   ├── ir_model.bin
│   │   └── ir_model.xml
│   └── 2
│       ├── somefile.bin
│       └── anotherfile.txt
└── model2
    ├── ir_model.bin
    ├── ir_model.xml
    └── mapping_config.json

  • 上の例では、サーバーは model1 のディレクトリー 1 のみを検出します。ディレクトリー 2 には有効な OpenVINO モデルファイルが含まれていないため、有効なモデルバージョンとして検出されません。

  • model2 内のファイルは正当なものですが、数値ディレクトリーにないため、サーバーは model2 内のバージョンを検出しません。

  • 詳細な原因は、サーバーログまたは GetModelStatus 関数の呼び出しの応答で報告されます。

  • 検出されてもロードされていないモデルバージョンは提供されません。LOADING ステータスが次のエラーメッセージで報告されます: バージョンのロード中にエラーが発生しました。

  • モデルファイルがアクセス可能になるか修正されると、サーバーは次回のバージョン更新時にモデルファイルの再ロードを試みます。

  • OVMS プロセスにモデルファイルの読み取り権限と、モデルフォルダーおよびモデルバージョンのサブフォルダーのリスト権限がない場合、モデルのインポートは失敗します。

クライアント要求の問題

  • モデルサーバーが正常に起動し、すべてのモデルがインポートされると、リクエスト処理でエラーが発生する理由がいくつか考えられます。

  • 失敗の理由に関する情報は、応答でクライアントに渡されます。また、DEBUG モードでモデルサーバーにログオンします。

考えられる問題は以下です。

  • 入力データの形状が正しくありません。

  • テンソル名と一致しない間違った入力キー名が設定しているか、mapping_config.json で入力キー名を設定しています。

  • クライアント側でデータが正しくシリアル化されていません。

リソース割り当て

  • RAM の消費量は、サービスで構成されるモデルのサイズとボリュームによって異なる場合があります。実験的に測定する必要がありますが、各モデルはモデルの重み付けファイル (.bin ファイル) のサイズと同じ RAM サイズを消費すると考えられます。

  • バージョンポリシーで有効にされているモデルの各バージョンは、個別の OpenVINO™ ランタイム ov::Model オブジェクトと ov::CompiledModel オブジェクトを作成します。デフォルトでは、最新バージョンのみが有効になっています。

  • OpenVINO™ モデルサーバーは、オペレーティング・システム、Docker、または Kubernetes によって制限されない限り、利用可能なすべての CPU リソースを消費します。

注: コンテナに割り当てられたメモリーが十分でない場合、Docker エンジンの OOM Killer によってコンテナが終了される可能性があります。OVMS ログに終了の原因は示されませんが、そのような状況は、docker inspect <terminated_container> と状態 "OOMKilled": true の報告によって確認できます。また、Memory cgroup out of memory: Killed process のようにホストシステムのログにも記録されます。

使用状況の監視

  • Prometheus の標準メトリックは、REST /metrics エンドポイント経由で利用できます。

  • DEBUG モードが有効になっていると、処理時間を含むモデルの使用状況を追跡することができます。

  • この設定を使用すると、モデルサーバーのログには、すべての受信リクエストに関する情報が保存されます。

  • ログを解析して、リクエストの量、処理統計、最も使用されているモデルなどを分析できます。

プロキシーで使用する S3 ストレージの構成

  • プロキシーの背後で S3 ストレージを使用するには、環境変数を設定する必要があります。S3 ローダーモジュールは次の形式を使用しています。

    http://user:password@hostname:port
または
https://user:password@hostname:port

    ここで、ユーザーとパスワードはオプションです。OVMS は次の環境変数も使用します。

    https_proxy
HTTPS_PROXY
http_proxy
HTTP_proxy

    注: no_proxy または NO_PROXY も使用されないことに注意してください。

プロキシーの背後で GCS モデルを使用

  • 環境でプロキシーを使用して、http_proxy/https_proxy がサーバーコンテナに渡されない場合、GCS モデルにアクセスすると 15 分のタイムアウトが発生します。

  • その間、OVMS によってログはキャプチャーされません。現在、GCS のタイムアウト期間を変更するオプションはありません。

モデルキャッシュの問題

  • キャッシュフォルダー (デフォルトでは /opt/cache または --cache_dir で定義) は、読み取り/書き込みアクセス権を持つ Docker コンテナにマウントされる必要があります。docker run コマンドによって変更されない限り、モデルサーバーには、uid 5000 の ovms アカウントのセキュリティー・コンテキストがあります。

  • モデルのロード時間の高速化は、GPU デバイスで期待されます。CPU デバイスでは、ゲインはモデルトポロジーによって異なります。まれに、ロード時間が改善されないか、わずかに遅くなることがあります。