3.4. シングルモデルサービングプラットフォームにデプロイされたモデルに対する推論リクエストの実行
シングルモデルサービングプラットフォームを使用してモデルをデプロイすると、そのモデルは、API リクエストを使用してアクセスできるサービスとして利用できます。これにより、データ入力に基づく予測を返すことができます。API リクエストを使用してデプロイされたモデルと対話するには、モデルの推論エンドポイントを知っておく必要があります。
さらに、トークン認可を有効にすることで推論エンドポイントを保護した場合は、推論リクエストで認可トークンを指定できるように、認可トークンへのアクセス方法を理解する必要があります。
3.4.1. デプロイされたモデルの認可トークンにアクセスする
トークン認可を有効にすることで推論エンドポイントを保護した場合は、推論リクエストで認可トークンを指定できるように、認可トークンへのアクセス方法を理解する必要があります。
前提条件
- Red Hat OpenShift AI にログインしている。
-
特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (
rhoai-users
、rhoai-admins
など) に属している。 - シングルモデルサービングプラットフォームを使用してモデルをデプロイした。
手順
OpenShift AI ダッシュボードから、Data Science Projects をクリックします。
Data Science Projects ページが開きます。
デプロイされたモデルが含まれるプロジェクトの名前をクリックします。
プロジェクトの詳細ページが開きます。
- Models タブをクリックします。
Models and model servers リストで、モデルのセクションを展開します。
認可トークンは、Token authorization セクションの Token secret フィールドに表示されます。
- オプション: 推論リクエストで使用する認可トークンをコピーするには、トークン値の横に表示される Copy ボタン ( ) をクリックします。
3.4.2. デプロイされたモデルの推論エンドポイントにアクセスする
デプロイされたモデルに対して推論リクエストを行うには、利用可能な推論エンドポイントへのアクセス方法を知っておく必要があります。
サポートされているランタイムとコマンド例で使用するパスのリストは、推論エンドポイント を参照してください。
前提条件
- Red Hat OpenShift AI にログインしている。
-
特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (
rhoai-users
、rhoai-admins
など) に属している。 - シングルモデルサービングプラットフォームを使用してモデルをデプロイした。
- デプロイされたモデルに対してトークン認可を有効にしている場合は、関連付けられたトークン値があります。
手順
OpenShift AI ダッシュボードで、Model Serving をクリックします。
モデルの推論エンドポイントは、Inference endpoint フィールドに表示されます。
- モデルで実行するアクション (およびモデルがそのアクションをサポートしているかどうか) に応じて、表示されている推論エンドポイントをコピーし、URL の末尾にパスを追加します。
- エンドポイントを使用して、デプロイされたモデルに API リクエストを送信します。
関連情報
3.4.2.1. KServe の raw デプロイメントモードを使用してシングルノードの OpenShift にモデルをデプロイする
シングルノードの OpenShift で KServe の raw デプロイメントモードを使用して機械学習モデルをデプロイできます。raw デプロイメントモードには、複数のボリュームをマウントする機能など、Knative に比べていくつかのメリットがあります。
シングルノード OpenShift で KServe の raw デプロイメントモードを使用して機械学習モデルをデプロイすることは、限定提供機能です。限定提供とは、Red Hat AI Business Unit からの特別な承認を得た場合にのみ、対象となる機能をインストールしてサポートを受けることができることを意味します。このような承認がない場合、この機能はサポートされません。
前提条件
- Red Hat OpenShift AI にログインしている。
- OpenShift クラスターのクラスター管理者権限を持っている。
- 少なくとも 4 つの CPU と 16 GB のメモリーを備えたノードを持つ OpenShift クラスターを作成している。
- Red Hat OpenShift AI (RHOAI) Operator がインストールされている。
- OpenShift コマンドラインインターフェイス (CLI) がインストールされている。OpenShift コマンドラインインターフェイス (CLI) のインストールに関する詳細は、OpenShift CLI のスタートガイド を参照してください。
- KServe をインストールしている。
- S3 互換オブジェクトストレージにアクセスできる。
- デプロイするモデルについて、S3 互換オブジェクトストレージバケット内の関連フォルダーパスを把握している。
- Caikit-TGIS ランタイムを使用するために、モデルを Caikit 形式に変換している。例は、caikit-tgis-serving リポジトリーの Converting Hugging Face Hub models to Caikit format を参照してください。
- モデルサーバーでグラフィックスプロセッシングユニット (GPU) を使用する場合は、OpenShift AI で GPU サポートを有効にしている。OpenShift AI での GPU サポートの有効化 を参照してください。
- vLLM ランタイムを使用するには、OpenShift AI で GPU サポートを有効にし、クラスターに Node Feature Discovery Operator をインストールして設定しておく。詳細は、Node Feature Discovery Operator のインストール および OpenShift AI での GPU サポートの有効化 を参照してください。
手順
コマンドラインターミナルを開き、クラスター管理者として OpenShift クラスターにログインします。
$ oc login <openshift_cluster_url> -u <admin_username> -p <password>
デフォルトでは、OpenShift はネットワークトラフィック管理にサービスメッシュを使用します。KServe の raw デプロイメントモードではサービスメッシュは必要ないため、Red Hat OpenShift Service Mesh を無効にします。
Red Hat OpenShift Service Mesh を無効にするには、次のコマンドを入力します。
$ oc edit dsci -n redhat-ods-operator
YAML エディターで、
serviceMesh
コンポーネントのmanagementState
の値を次のようにRemoved
に変更します。spec: components: serviceMesh: managementState: Removed
- 変更を保存します。
プロジェクトを作成します。
$ oc new-project <project_name> --description="<description>" --display-name="<display_name>"
プロジェクトの作成に関する詳細は、プロジェクトの使用 を参照してください。
データサイエンスクラスターを作成します。
-
Red Hat OpenShift Web コンソールの Administrator ビューで、Operators
Installed Operators をクリックし、Red Hat OpenShift AI Operator をクリックします。 - Data Science Cluster タブをクリックします。
- Create DataScienceCluster ボタンをクリックします。
- Configure via フィールドで、YAML view ラジオボタンをクリックします。
YAML エディターの
spec.components
セクションで、kserve
コンポーネントを次のように設定します。kserve: defaultDeploymentMode: RawDeployment managementState: Managed serving: managementState: Removed name: knative-serving
- Create をクリックします。
-
Red Hat OpenShift Web コンソールの Administrator ビューで、Operators
シークレットファイルを作成します。
コマンドラインターミナルで、シークレットを格納する YAML ファイルを作成し、次の YAML コードを追加します。
apiVersion: v1 kind: Secret metadata: annotations: serving.kserve.io/s3-endpoint: <AWS_ENDPOINT> serving.kserve.io/s3-usehttps: "1" serving.kserve.io/s3-region: <AWS_REGION> serving.kserve.io/s3-useanoncredential: "false" name: <Secret-name> stringData: AWS_ACCESS_KEY_ID: "<AWS_ACCESS_KEY_ID>" AWS_SECRET_ACCESS_KEY: "<AWS_SECRET_ACCESS_KEY>"
重要切断されたデプロイメントで機械学習モデルをデプロイする場合は、
metadata.annotations
セクションにserving.kserve.io/s3-verifyssl: '0'
を追加します。- ファイルを secret.yaml というファイル名で保存します。
secret.yaml ファイルを適用します。
$ oc apply -f secret.yaml -n <namespace>
サービスアカウントを作成します。
サービスアカウントを格納する YAML ファイルを作成し、次の YAML コードを追加します。
apiVersion: v1 kind: ServiceAccount metadata: name: models-bucket-sa secrets: - name: s3creds
サービスアカウントの詳細は、サービスアカウントの理解と作成 を参照してください。
- ファイルを serviceAccount.yaml というファイル名で保存します。
serviceAccount.yaml ファイルを適用します。
$ oc apply -f serviceAccount.yaml -n <namespace>
モデルの予測を提供するコンテナーイメージを定義するために、サービングランタイム用の YAML ファイルを作成します。以下は OpenVINO Model Server の使用例です。
apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: ovms-runtime spec: annotations: prometheus.io/path: /metrics prometheus.io/port: "8888" containers: - args: - --model_name={{.Name}} - --port=8001 - --rest_port=8888 - --model_path=/mnt/models - --file_system_poll_wait_seconds=0 - --grpc_bind_address=0.0.0.0 - --rest_bind_address=0.0.0.0 - --target_device=AUTO - --metrics_enable image: quay.io/modh/openvino_model_server@sha256:6c7795279f9075bebfcd9aecbb4a4ce4177eec41fb3f3e1f1079ce6309b7ae45 name: kserve-container ports: - containerPort: 8888 protocol: TCP multiModel: false protocolVersions: - v2 - grpc-v2 supportedModelFormats: - autoSelect: true name: openvino_ir version: opset13 - name: onnx version: "1" - autoSelect: true name: tensorflow version: "1" - autoSelect: true name: tensorflow version: "2" - autoSelect: true name: paddle version: "2" - autoSelect: true name: pytorch version: "2"
- 上記の OpenVINO Model Server の例を使用している場合は、YAML コード内のプレースホルダーに必要な正しい値を挿入していることを確認してください。
- 適切なファイル名でファイルを保存します。
サービングランタイムを含むファイルを適用します。
$ oc apply -f <serving run time file name> -n <namespace>
InferenceService カスタムリソース (CR) を作成します。InferenceService CR を含むための YAML ファイルを作成します。以前使用した OpenVINO Model Server の例を使用する場合の対応する YAML コードは、次のとおりです。
apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: annotations: serving.knative.openshift.io/enablePassthrough: "true" sidecar.istio.io/inject: "true" sidecar.istio.io/rewriteAppHTTPProbers: "true" serving.kserve.io/deploymentMode: RawDeployment name: <InferenceService-Name> spec: predictor: scaleMetric: minReplicas: 1 scaleTarget: canaryTrafficPercent: serviceAccountName: <serviceAccountName> model: env: [] volumeMounts: [] modelFormat: name: onnx runtime: ovms-runtime storageUri: s3://<bucket_name>/<model_directory_path> resources: requests: memory: 5Gi volumes: []
YAML コードで、次の値が正しく設定されていることを確認します。
-
serving.kserve.io/deploymentMode
には、RawDeployment
の値が含まれている必要があります。 -
modelFormat
には、onnx
などのモデル形式の値が含まれている必要があります。 -
storageUri
には、モデルの s3 ストレージディレクトリーの値 (例s3://<bucket_name>/<model_directory_path>
) が含まれている必要があります。 -
runtime
には、ovms-runtime
など、サービングランタイムの名前の値が含まれている必要があります。
-
- 適切なファイル名でファイルを保存します。
InferenceService CR を含むファイルを適用します。
$ oc apply -f <InferenceService CR file name> -n <namespace>
クラスター内のすべての Pod が実行されていることを確認します。
$ oc get pods -n <namespace>
出力例:
NAME READY STATUS RESTARTS AGE <isvc_name>-predictor-xxxxx-2mr5l 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165m
すべての Pod が実行中であることを確認したら、サービスポートをローカルマシンに転送します。
$ oc -n <namespace> port-forward pod/<pod-name> <local_port>:<remote_port>
<namespace>
、<pod-name>
、<local_port>
、<remote_port>
(これは8888
などのモデルサーバーのポート) を、デプロイメントに適した値に置き換えてください。
検証
-
好みのクライアントライブラリーまたはツールを使用して、
localhost
推論 URL にリクエストを送信します。