このガイドでは、Tensorflow Serving の多数の構成ポイントについて説明します。
概要
ほとんどの構成はモデル サーバーに関連しますが、Tensorflow Serving の動作を指定するにはさまざまな方法があります。
- モデルサーバー構成: モデル名、パス、バージョンポリシーとラベル、ログ構成などを指定します。
- 監視構成: Prometheus 監視を有効にして構成します。
- バッチ設定: バッチ処理を有効にし、そのパラメータを設定します。
- その他フラグ: その他多数。 Tensorflow Serving デプロイメントの動作を微調整するために提供できるフラグ
モデルサーバー構成
モデルを提供する最も簡単な方法は、 --model_nameフラグと--model_base_pathフラグを指定することです (または、Docker を使用している場合はMODEL_NAME環境変数を設定します)。ただし、複数のモデルを提供したい場合、または新しいバージョンのポーリング頻度などのオプションを構成したい場合は、Model Server 構成ファイルを作成することでこれを行うことができます。
--model_config_fileフラグを使用してこの構成ファイルを提供し、 --model_config_file_poll_wait_secondsフラグを設定することで、指定されたパスでこの構成ファイルの更新バージョンを定期的にポーリングするように Tensorflow Serving に指示できます。
Docker を使用した例:
docker run -t --rm -p 8501:8501 \
-v "$(pwd)/models/:/models/" tensorflow/serving \
--model_config_file=/models/models.config \
--model_config_file_poll_wait_seconds=60
モデルサーバー構成の再ロード
モデル サーバー構成を再ロードするには、次の 2 つの方法があります。
--model_config_file_poll_wait_secondsフラグを設定して、--model_config_fileファイルパスにある新しい構成ファイルを定期的にチェックするようにサーバーに指示します。HandleReloadConfigRequest RPC 呼び出しをサーバーに発行し、新しいモデル サーバー構成をプログラムで提供します。
サーバーが新しい構成ファイルをロードするたびに、新しく指定された構成の内容を認識し、新しく指定された構成のみを認識するように動作することに注意してください。これは、モデル A が最初の構成ファイルに存在し、モデル B のみを含むファイルに置き換えられた場合、サーバーはモデル B をロードし、モデル A をアンロードすることを意味します。
モデルサーバー構成の詳細
提供される Model Server 構成ファイルは、 ModelServerConfigプロトコル バッファである必要があります。
最も高度な使用例を除くすべての場合は、 ModelConfigプロトコル バッファーのリストである ModelConfigList オプションを使用することをお勧めします。以下の高度なオプションに入る前に、基本的な例を示します。
model_config_list {
config {
name: 'my_first_model'
base_path: '/tmp/my_first_model/'
model_platform: 'tensorflow'
}
config {
name: 'my_second_model'
base_path: '/tmp/my_second_model/'
model_platform: 'tensorflow'
}
}
1 つのモデルの構成
上記の例に示すように、各 ModelConfig は、提供されるモデルを 1 つ指定します。これには、その名前と、Model Server が提供するモデルのバージョンを検索するパスが含まれます。デフォルトでは、サーバーは最大のバージョン番号を持つバージョンを提供します。このデフォルトは、model_version_policy フィールドを変更することで上書きできます。
モデルの特定のバージョンを提供する
モデルの特定のバージョンを提供するには、常に最大のバージョン番号を持つモデルに移行するのではなく、model_version_policy を「特定」に設定し、提供したいバージョン番号を指定します。たとえば、バージョン 42 を提供するものとして固定するには、次のようにします。
model_version_policy {
specific {
versions: 42
}
}
このオプションは、最新バージョンで問題が発見された場合に、正常なバージョンにロールバックするのに役立ちます。
モデルの複数のバージョンの提供
モデルの複数のバージョンを同時に提供するには、たとえばトラフィックのスライスで暫定的な新しいバージョンをカナリア処理できるようにするには、model_version_policy を「特定」に設定し、複数のバージョン番号を指定します。たとえば、バージョン 42 と 43 を提供するには、次のようにします。
model_version_policy {
specific {
versions: 42
versions: 43
}
}
カナリアとロールバックを簡素化するためのモデル バージョンへの文字列ラベルの割り当て
場合によっては、モデルのバージョンに間接的なレベルを追加すると便利です。すべてのクライアントにバージョン 42 をクエリする必要があることを知らせる代わりに、現在クライアントがクエリを実行するバージョンに「stable」などのエイリアスを割り当てることができます。トラフィックのスライスを暫定的な Canary モデル バージョンにリダイレクトする場合は、2 番目のエイリアス「canary」を使用できます。
これらのモデル バージョンのエイリアスまたはラベルを次のように構成できます。
model_version_policy {
specific {
versions: 42
versions: 43
}
}
version_labels {
key: 'stable'
value: 42
}
version_labels {
key: 'canary'
value: 43
}
上の例では、バージョン 42 と 43 を提供し、ラベル「stable」をバージョン 42 に関連付け、ラベル「canary」をバージョン 43 に関連付けます。クライアントにクエリを「stable」または「canary」のいずれかに送信させることができます。 (おそらくユーザー ID のハッシュに基づいて) ModelSpecプロトコル バッファーの version_label フィールドを使用して、クライアントに通知せずにサーバー上のラベルを転送します。バージョン 43 のカナリア化が完了し、安定版に昇格する準備ができたら、構成を次のように更新できます。
model_version_policy {
specific {
versions: 42
versions: 43
}
}
version_labels {
key: 'stable'
value: 43
}
version_labels {
key: 'canary'
value: 43
}
後でロールバックを実行する必要がある場合は、バージョン 42 が「安定」である古い構成に戻すことができます。それ以外の場合は、バージョン 42 をアンロードし、準備ができたら新しいバージョン 44 をロードし、カナリア ラベルを 44 に進めるなど、先に進むことができます。
ラベルは、すでにロードされて提供可能なモデル バージョンにのみ割り当てることができることに注意してください。モデルのバージョンが利用可能になると、その場でモデル構成を再ロードしてラベルを割り当てることができます。これは、上で説明したように、 HandleReloadConfigRequest RPC を使用するか、サーバーが構成ファイルのファイル システムを定期的にポーリングするように設定されている場合に実現できます。
まだロードされていないバージョンにラベルを割り当てたい場合 (たとえば、起動時にモデルのバージョンとラベルの両方を指定することによって)、 --allow_version_labels_for_unavailable_modelsフラグを true に設定する必要があります。これにより、新しいラベルがロードされるようになります。まだロードされていないモデル バージョンに割り当てられます。
これは新しいバージョン ラベル (つまり、現在バージョンに割り当てられていないラベル) にのみ適用されることに注意してください。これは、バージョンのスワップ中に、サーバーが時期尚早にラベルを新しいバージョンに割り当てないようにするためであり、その結果、新しいバージョンのロード中にそのラベル宛てのすべてのリクエストがドロップされます。
この安全性チェックに準拠するには、すでに使用されているバージョン ラベルを再割り当てする場合は、すでにロードされているバージョンにのみ割り当てる必要があります。たとえば、ラベルをバージョン N からバージョン N+1 に移動したい場合は、まずバージョン N と N+1 を含む構成を送信し、次にバージョン N+1 とラベルを含む構成を送信します。 N+1 を指しますが、バージョン N はありません。
RESTの使用法
REST API サーフェスを使用して推論リクエストを行っている場合は、
/v1/models/<model name>/versions/<version number>
次のようにリクエストパスを構造化し、ラベルを使用してバージョンをリクエストするだけです
/v1/models/<model name>/labels/<version label> 。
バージョン ラベルは、英数字とアンダースコアで構成される一連の Word 文字 (つまり[a-zA-Z0-9_]+ ) に制限されることに注意してください。
監視構成
--monitoring_config_fileフラグを使用して、 MonitoringConfigプロトコル バッファーを含むファイルを指定することで、サーバーに監視構成を提供できます。以下に例を示します。
prometheus_config {
enable: true,
path: "/monitoring/prometheus/metrics"
}
上記の監視 URL からメトリクスを読み取るには、まず--rest_api_portフラグを設定して HTTP サーバーを有効にする必要があります。その後、 --rest_api_portとpathの値を渡すことで、Model Server からメトリクスを取得するように Prometheus Server を構成できます。
Tensorflow Serving は、コア Tensorflow だけでなく Serving によってキャプチャされるすべてのメトリクスを収集します。
バッチ処理構成
Model Server には、より優れたスループットを実現するために、さまざまな設定でリクエストをバッチ処理する機能があります。このバッチ処理のスケジューリングは、サーバー上のすべてのモデルおよびモデル バージョンに対してグローバルに実行され、現在サーバーで提供されているモデルまたはモデル バージョンの数に関係なく、基になるリソースを最大限に活用できるようにします (詳細を参照)。 --enable_batchingフラグを設定することでこの動作を有効にし、構成を--batching_parameters_fileフラグに渡すことで制御できます。
バッチパラメータファイルの例:
max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }
詳細な説明についてはバッチ処理ガイドを参照し、パラメータの設定方法を理解するにはパラメータに関するセクションを参照してください。
その他のフラグ
このガイドでこれまで説明したフラグに加えて、ここではその他の注目すべきフラグをいくつかリストします。完全なリストについては、ソース コードを参照してください。
-
--port: gRPC API をリッスンするポート --rest_api_port: HTTP/REST API をリッスンするポート--rest_api_timeout_in_ms: HTTP/REST API 呼び出しのタイムアウト--file_system_poll_wait_seconds: サーバーが各モデルのそれぞれの model_base_path で新しいモデル バージョンのファイル システムをポーリングする期間--enable_model_warmup:assets.extra/ ディレクトリ内のユーザー提供の PredictionLogs を使用してモデルのウォームアップを有効にします。-
--mixed_precision=bfloat16: BF16 自動混合精度を有効にします。