トレーニング済みモデルからオンライン推論を取得するには、モデルをエンドポイントにデプロイする必要があります。これを行うには、 Google Cloud コンソール、Google Cloud CLI、または Vertex AI API を使用します。
このドキュメントでは、モデルをエンドポイントにデプロイするプロセスについて説明します。
モデルのデプロイによる影響
モデルをデプロイすると、物理リソースがモデルに関連付けられ、低レイテンシでオンライン推論を提供できるようになります。
1 つのエンドポイントに複数のモデルをデプロイすることも、複数のエンドポイントに同じモデルをデプロイすることもできます。詳細については、同じエンドポイントに複数のモデルをデプロイする理由をご覧ください。
エンドポイントにモデルをデプロイする準備をする
モデルのデプロイ時に、オンライン推論の実行について次の重要な決定を行います。
| 作成したリソース | リソース作成時に指定する設定 |
|---|---|
| エンドポイント | 推論を実行するロケーション |
| モデル | 使用するコンテナ（ModelContainerSpec） |
| DeployedModel | オンライン推論に使用するコンピューティング リソース |
モデルがエンドポイントにデプロイされた後、これらのデプロイ設定を変更することはできません。変更するには、モデルを再度デプロイする必要があります。
デプロイ プロセスの最初のステップは、使用するエンドポイントのタイプを決定することです。詳細については、エンドポイント タイプを選択するをご覧ください。
次に、モデルが Vertex AI Model Registry に表示されていることを確認します。これは、モデルをデプロイ可能にするために必要です。モデルのアーティファクトをインポートする方法や、Model Registry で直接作成する方法など、Model Registry の詳細については、Vertex AI Model Registry の概要をご覧ください。
次に、モデルのサービングに使用するコンピューティング リソースを決定します。モデルのトレーニング タイプ（AutoML またはカスタム）と（AutoML）データ型によって、モデルで使用可能な物理リソースの種類が決まります。モデルのデプロイ後、新しいデプロイを作成せずに、これらのリソースの一部を mutate できます。
エンドポイント リソースによって、推論をリクエストするために使用するサービス エンドポイント（URL）が提供されます。例:
https://us-central1-aiplatform.googleapis.com/v1/projects/{project}/locations/{location}/endpoints/{endpoint}:predict
エンドポイントにモデルをデプロイする
モデルをエンドポイントにデプロイするには、 Google Cloud コンソールを使用するか、gcloud CLI または Vertex AI API を使用します。
Google Cloud コンソールを使用してモデルをパブリック エンドポイントにデプロイする
Google Cloud コンソールでは、既存の専用または共有のパブリック エンドポイントにモデルをデプロイできます。また、デプロイ プロセス中に新しいエンドポイントを作成することもできます。詳細については、 Google Cloud コンソールを使用してモデルをデプロイするをご覧ください。
gcloud CLI または Vertex AI API を使用して、モデルをパブリック エンドポイントにデプロイする
gcloud CLI または Vertex AI API を使用してモデルをデプロイする場合は、まず専用または共有のエンドポイントを作成してから、モデルをデプロイする必要があります。詳細は下記のページをご覧ください。
Private Service Connect エンドポイントにモデルをデプロイする
詳細については、オンライン推論に Private Service Connect エンドポイントを使用するをご覧ください。
ローリング デプロイを使用してデプロイされたモデルを更新する
ローリング デプロイを使用して、デプロイされたモデルを同じモデルの新しいバージョンに置き換えることができます。新しいモデルは、以前のモデルのコンピューティング リソースを再利用します。詳細については、ローリング デプロイを使用してデプロイされたモデルを置き換えるをご覧ください。
モデルのデプロイを解除してエンドポイントを削除する
モデルのデプロイを解除してエンドポイントを削除できます。詳細については、モデルのデプロイを解除してエンドポイントを削除するをご覧ください。
同じエンドポイントに複数のモデルをデプロイする理由
2 つのモデルを同じエンドポイントにデプロイすると、1 つのモデルを段階的に別のモデルに置き換えることができます。たとえば、モデルを使用しており、新しいトレーニング データでモデルの精度を向上させる方法を見つけたとします。ただし、新しいエンドポイント URL を指すようにアプリケーションを更新する必要がなく、アプリケーションを急に変更することを避ける必要があります。新しいモデルを同じエンドポイントに追加すると、トラフィックのごく一部を処理できます。新しいモデルへのトラフィック分割は、すべてのトラフィックがトラフィックを処理するまで、段階的に増やしていくことになります。
リソースは、エンドポイントではなくモデルに関連付けられているため、さまざまなタイプのモデルを同じエンドポイントにデプロイできます。ただし、特定の種類のモデル（AutoML 表形式、カスタム トレーニングなど）をエンドポイントにデプロイすることをおすすめします。この構成は管理が簡単です。
複数のエンドポイントにモデルをデプロイする理由
テスト環境や本番環境などのアプリケーション環境ごとに異なるリソースを使用してモデルをデプロイすることが必要になるかもしれません。また、推論リクエストでさまざまな SLO をサポートする必要がある場合もあります。おそらく、アプリケーションの中には他のアプリケーションよりもパフォーマンス ニーズがはるかに高いものがあります。この場合、より多くのマシンリソースを持つ高パフォーマンス エンドポイントにこのモデルをデプロイできます。コストを最適化するために、マシンリソースが少ない低パフォーマンスのエンドポイントにモデルをデプロイすることもできます。
スケーリング動作
オンライン推論用のモデルを DeployedModel としてデプロイすると、推論ノードを自動スケーリングするよう構成できます。これを行うには、dedicatedResources.maxReplicaCount を dedicatedResources.minReplicaCount より大きい値に設定します。
DeployedModel を構成する場合は、dedicatedResources.minReplicaCount を 1 以上に設定する必要があります。つまり、使用されていない DeployedModel を 0 個の推論ノードにスケーリングするように構成することはできません。
デフォルトでは、デプロイ リクエストのタイムアウト値の前に推論ノードの数が dedicatedResources.minReplicaCount に達した場合にのみ、デプロイ オペレーションは成功と見なされます。それ以外の場合、デプロイは失敗としてマークされ、基盤となるリソースが解放されます。
デプロイとミューテーションの部分的成功
デフォルトのデプロイ動作を変更するには、dedicatedResources.requiredReplicaCount を dedicatedResources.minReplicaCount より小さい値に設定します。この場合、推論ノードの数が dedicatedResources.requiredReplicaCount に達すると、デプロイ オペレーションは完了していなくても成功としてマークされます。デプロイは dedicatedResources.minReplicaCount に達するまで続行されます。デプロイ リクエスト時刻までに dedicatedResources.minReplicaCount に達しなかった場合でも、オペレーションは成功しますが、失敗したレプリカのエラー メッセージが DeployedModel.status.message で返されます。
カスタムモデル サービングの割り当ては、デプロイされたモデルのリアルタイムのコンピューティング リソース使用量に基づいて計算されます。たとえば、プロジェクト内のすべてのデプロイメントの maxReplicaCount の合計が、プロジェクトの割り当てを超えている場合、使用可能な割り当てがないために自動スケーリングに失敗することがあります。
エンドポイントはマシンごとにスケールアップとスケールダウンが行われますが、割り当ては CPU または GPU ごとに計算されます。たとえば、モデルが a2-highgpu-2g マシンタイプにデプロイされている場合、アクティブなレプリカごとにプロジェクトの割り当てに対して 24 個の CPU と 2 個の GPU がカウントされます。詳細については、割り当てと上限をご覧ください。
バッチ推論の推論ノードは自動的にスケーリングされません。Vertex AI は BatchDedicatedResources.startingReplicaCount を使用し、BatchDedicatedResources.maxReplicaCount を無視します。
ターゲット使用率と構成
デフォルトでは、専用の GPU リソースなしでモデルをデプロイすると、Vertex AI は CPU 使用率がデフォルトの 60% のターゲット値と一致するように、レプリカの数を自動的にスケールアップまたはスケールダウンします。
デフォルトでは、専用の GPU リソースを使用してモデルをデプロイすると（machineSpec.accelerator_count が 0 より大きい場合）、CPU 使用率または GPU 使用率のいずれか高い方がデフォルトの 60% のターゲット値と一致するように、Vertex AI は自動的にレプリカ数をスケールアップまたはスケールダウンします。そのため、推論スループットで GPU 使用率が高くても CPU 使用率が高くない場合、Vertex AI がスケールアップを行い、CPU 使用率は非常に低くなります。これは、モニタリングで確認できます。逆に、カスタム コンテナの GPU 使用率が低いものの、CPU 使用率が 60% を超える原因となる関連性のないプロセスが存在する場合は、QPS とレイテンシの目標を達成するために必要でない場合でも、Vertex AI はスケールアップを行います。
デフォルトのしきい値指標とターゲットは、autoscalingMetricSpecs を指定してオーバーライドできます。CPU 使用率のみに基づいてスケーリングするようにデプロイが構成されている場合、GPU 使用率が高い状態でも、スケールアップは行われません。
リソース使用量を管理する
エンドポイントをモニタリングして、CPU とアクセラレータの使用率、リクエスト数、レイテンシ、レプリカの現在の数とターゲット数などの指標を追跡できます。この情報は、エンドポイントのリソース使用量とスケーリング動作の理解に活用できます。
各レプリカではコンテナが 1 つしか実行されないことに注意してください。つまり、推論コンテナが選択されたコンピューティング リソース（マルチコア マシンのシングル スレッドコードなど）や、推論の一環として別のサービスを呼び出すカスタムモデルを十分に利用できない場合は、ノードがスケールアップされない可能性があります。
たとえば、FastAPI、またはワーカー数やスレッド数が構成可能なモデルサーバーを使用する場合は、リソース使用率を引き上げることができる複数のワーカーが存在すると、サービスがレプリカ数を自動的にスケーリングするための機能が改善されるケースが多数存在します。
通常は、コアごとに 1 つのワーカーまたはスレッドから始めることをおすすめします。CPU 使用率が低い場合（特に負荷が高い状況下で）、または CPU 使用率が低いためにモデルがスケールアップされない場合は、ワーカー数を引き上げる必要があります。一方、使用率が過剰に高く、負荷が生じた状態でレイテンシが予想以上に増加した場合は、使用するワーカーの数を削減してみてください。すでに 1 つのワーカーのみを使用している場合は、より小さなマシンタイプを使用してみてください。
スケーリングの動作とラグ
Vertex AI は、過去 5 分間のデータを使用して 15 秒ごとにレプリカの数を調整します。15 秒サイクルごとに、サーバー使用率が測定され、次の式に基づいてレプリカのターゲット数が生成されます。
target # of replicas = Ceil(current # of replicas * (current utilization / target utilization))
たとえば、2 つのレプリカが 100% 使用されている場合、ターゲットは以下のとおり 4 になります。
4 = Ceil(3.33) = Ceil(2 * (100% / 60%))
別の例として、10 個のレプリカがあり、使用率が 1% に低下した場合、ターゲットは以下のとおり 1 になります。
1 = Ceil(.167) = Ceil(10 * (1% / 60%))
15 秒の各サイクルの終了時に、過去 5 分間の最大ターゲット値に一致するようにレプリカの数を調整します。最大ターゲット値が選択されているため、全体の使用率が非常に低い場合でも、該当する 5 分間に使用率が急増しても、エンドポイントはスケールダウンされません。一方、システムをスケールアップする必要がある場合は、平均ではなく最大ターゲット値が選択されるため、15 秒以内にスケーリングが行われます。
Vertex AI がレプリカの数を調整しても、レプリカの起動または停止には時間を要することに注意してください。このため、エンドポイントがトラフィックに調整されるまでに、さらに遅延が発生します。この時間の原因となる主な要因は次のとおりです。
- Compute Engine VM のプロビジョニングと起動に要する時間
- レジストリからコンテナをダウンロードするために必要な時間
- ストレージからモデルを読み込むために必要な時間
モデルの実際のスケーリング動作を理解する最善の方法は、負荷テストを実施し、モデルとユースケースにとって重要な特性を最適化することです。オートスケーラーのスケールアップ速度がアプリケーションに対して十分でない場合は、予想されるベースライン トラフィックを処理するのに十分な min_replicas をプロビジョニングします。
スケーリング構成を更新する
モデルのデプロイ時に DedicatedResources または AutomaticResources を指定した場合は、mutateDeployedModel を呼び出してモデルを再デプロイすることなくスケーリングの構成を更新できます。
たとえば、次のリクエストでは max_replica と autoscaling_metric_specs が更新され、コンテナ ロギングが無効に設定されます。
{
"deployedModel": {
"id": "2464520679043629056",
"dedicatedResources": {
"maxReplicaCount": 9,
"autoscalingMetricSpecs": [
{
"metricName": "aiplatform.googleapis.com/prediction/online/cpu/utilization",
"target": 50
}
]
},
"disableContainerLogging": true
},
"update_mask": {
"paths": [
"dedicated_resources.max_replica_count",
"dedicated_resources.autoscaling_metric_specs",
"disable_container_logging"
]
}
}
使用上の注意:
- マシンタイプの変更や、
DedicatedResourcesからAutomaticResources（またはその逆）への切り替えはできません。変更できるスケーリング構成フィールドは、min_replica、max_replica、required_replica、AutoscalingMetricSpec（DedicatedResourcesのみ）のみです。 - 更新するフィールドはすべて
updateMaskにリストする必要があります。リストにないフィールドは無視されます。 - DeployedModel は
DEPLOYED状態である必要があります。デプロイされたモデルごとに、存在できるアクティブな変更オペレーションは 1 つのみです。 mutateDeployedModelを使用すると、コンテナ ロギングを有効または無効にすることもできます。詳細については、オンライン推論のロギングをご覧ください。
次のステップ
- エンドポイントのタイプを選択する。
- Google Cloud コンソールを使用してモデルをデプロイする。
- 専用エンドポイントと Private Service Connect エンドポイントの推論リクエスト / レスポンスのロギングについて確認する。
- オンライン予測の取得方法を確認する。
- 予測ロギングのデフォルト設定を変更する方法を確認する。