3.11. シングルモデルサービングプラットフォームを使用したモデルのデプロイ
シングルモデルサービングプラットフォームでは、各モデルが独自のモデルサーバー上でデプロイされます。これにより、リソースの増加を必要とする大規模なモデルのデプロイ、監視、スケーリング、保守が容易になります。
3.11.1. シングルモデルサービングプラットフォームの有効化
KServe をインストールすると、Red Hat OpenShift AI ダッシュボードを使用して、シングルモデルサービングプラットフォームを有効にすることができます。ダッシュボードを使用して、プラットフォームのモデルサービングランタイムを有効にすることもできます。
前提条件
- OpenShift AI 管理者権限を持つユーザーとして OpenShift AI にログインしている。
- KServe をインストールしている。
- クラスター管理者は、OpenShift AI ダッシュボード設定を編集して KServe コンポーネントを使用するシングルモデルサービングプラットフォームを選択する機能を無効に していない。詳細は、ダッシュボード設定オプション を参照してください。
手順
次のようにシングルモデルサービングプラットフォームを有効にします。
-
左側のメニューで、Settings
Cluster settings をクリックします。 - Model serving platforms セクションを見つけます。
- プロジェクトに対してシングルモデルサービングプラットフォームを有効にするには、Single model serving platform チェックボックスをオンにします。
- Save changes をクリックします。
-
左側のメニューで、Settings
次のように、シングルモデルサービングプラットフォーム用のプリインストールされたランタイムを有効にします。
OpenShift AI ダッシュボードの左側のメニューで、Settings
Serving runtimes をクリックします。 Serving runtimes ページには、プリインストールされたランタイムと追加したカスタムランタイムが表示されます。
プリインストールされたランタイムの詳細は、サポートされているランタイム を参照してください。
使用するランタイムを Enabled に設定します。
これで、シングルモデルサービングプラットフォームをモデルのデプロイに使用できるようになりました。
3.11.2. シングルモデルサービングプラットフォーム用のカスタムモデルサービングランタイムの追加
モデルサービングランタイムは、特定のモデルフレームワーク群のサポートと、それらのフレームワークでサポートされるモデル形式のサポートを追加します。OpenShift AI に含まれている プリインストールされたランタイム を使用できます。デフォルトのランタイムがニーズを満たしていない場合は、独自のカスタムランタイムを追加することもできます。たとえば、TGIS ランタイムが Hugging Face Text Generation Inference (TGI) でサポートされているモデル形式をサポートしていない場合は、カスタムランタイムを作成してモデルのサポートを追加できます。
管理者は、OpenShift AI インターフェイスを使用して、カスタムのモデルサービングランタイムを追加して有効にすることができます。その場合は、シングルモデルサービングプラットフォームにモデルをデプロイする際に、カスタムランタイムを選択できます。
Red Hat はカスタムランタイムのサポートを提供しません。追加したカスタムランタイムを使用するライセンスがあることを確認し、お客様の責任で正しく設定および保守するようにしてください。
前提条件
- OpenShift AI 管理者権限を持つユーザーとして OpenShift AI にログインしている。
- カスタムランタイムをビルドし、イメージを Quay などのコンテナーイメージリポジトリーに追加している。
手順
OpenShift AI ダッシュボードから、Settings > Serving runtimes をクリックします。
Serving runtimes ページが開き、すでにインストールされ有効になっているモデルサービングランタイムが表示されます。
カスタムランタイムを追加するには、次のオプションのいずれかを選択します。
- 既存のランタイム (TGIS Standalone ServingRuntime for KServe など) で開始するには、既存のランタイムの横にあるアクションメニュー (⋮) をクリックしてから、Duplicate をクリックします。
- 新しいカスタムランタイムを追加するには、Add serving runtime をクリックします。
- Select the model serving platforms this runtime supports リストで、Single-model serving platform を選択します。
- Select the API protocol this runtime supports リストで、REST または gRPC を選択します。
オプション: (既存のランタイムを複製するのではなく) 新しいランタイムを開始した場合は、次のオプションのいずれかを選択してコードを追加します。
YAML ファイルをアップロードする
- Upload files をクリックします。
ファイルブラウザーで、コンピューター上の YAML ファイルを選択します。
埋め込み YAML エディターが開き、アップロードしたファイルの内容が表示されます。
エディターに YAML コードを直接入力する
- Start from scratch をクリックします。
- 埋め込みエディターに YAML コードを直接入力または貼り付けます。
注記多くの場合、カスタムランタイムを作成するには、
ServingRuntime
仕様のenv
セクションに新しいパラメーターまたはカスタムパラメーターを追加する必要があります。Add をクリックします。
Serving runtimes ページが開き、インストールされているランタイムの更新されたリストが表示されます。追加したカスタムランタイムが自動的に有効になることを確認します。ランタイム作成時に指定した API プロトコルが表示されます。
- オプション: カスタムランタイムを編集するには、アクションメニュー (⋮) をクリックし、Edit を選択します。
検証
- 追加したカスタムモデルサービングランタイムは、Serving runtimes ページに有効な状態で表示されます。
3.11.3. シングルモデルサービングプラットフォームへのテスト済みおよび検証済みのモデルサービングランタイム追加
プリインストールされたカスタムのモデルサービングランタイムに加えて、NVIDIA Triton Inference Server などの Red Hat でテストおよび検証されたモデルサービングランタイムを使用して要件に対応することもできます。Red Hat のテスト済みおよび検証済みのランタイムの詳細は、Red Hat OpenShift AI のテスト済みおよび検証済みのランタイム を参照してください。
Red Hat OpenShift AI ダッシュボードを使用して、シングルモデルサービングプラットフォーム用の NVIDIA Triton Inference Server ランタイムを追加して有効にできます。その場合は、シングルモデルサービングプラットフォームにモデルをデプロイする際に、ランタイムを選択できます。
前提条件
- OpenShift AI 管理者権限を持つユーザーとして OpenShift AI にログインしている。
手順
OpenShift AI ダッシュボードから、Settings > Serving runtimes をクリックします。
Serving runtimes ページが開き、すでにインストールされ有効になっているモデルサービングランタイムが表示されます。
- Add serving runtime をクリックします。
- Select the model serving platforms this runtime supports リストで、Single-model serving platform を選択します。
- Select the API protocol this runtime supports リストで、REST または gRPC を選択します。
Start from scratch をクリックします。
REST API プロトコルを選択した場合は、埋め込みエディターに次の YAML コードを直接入力または貼り付けます。
apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: triton-kserve-rest labels: opendatahub.io/dashboard: "true" spec: annotations: prometheus.kserve.io/path: /metrics prometheus.kserve.io/port: "8002" containers: - args: - tritonserver - --model-store=/mnt/models - --grpc-port=9000 - --http-port=8080 - --allow-grpc=true - --allow-http=true image: nvcr.io/nvidia/tritonserver@sha256:xxxxx name: kserve-container resources: limits: cpu: "1" memory: 2Gi requests: cpu: "1" memory: 2Gi ports: - containerPort: 8080 protocol: TCP protocolVersions: - v2 - grpc-v2 supportedModelFormats: - autoSelect: true name: tensorrt version: "8" - autoSelect: true name: tensorflow version: "1" - autoSelect: true name: tensorflow version: "2" - autoSelect: true name: onnx version: "1" - name: pytorch version: "1" - autoSelect: true name: triton version: "2" - autoSelect: true name: xgboost version: "1" - autoSelect: true name: python version: "1"
gRPC API プロトコルを選択した場合は、埋め込みエディターで次の YAML コードを直接入力または貼り付けます。
apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: triton-kserve-grpc labels: opendatahub.io/dashboard: "true" spec: annotations: prometheus.kserve.io/path: /metrics prometheus.kserve.io/port: "8002" containers: - args: - tritonserver - --model-store=/mnt/models - --grpc-port=9000 - --http-port=8080 - --allow-grpc=true - --allow-http=true image: nvcr.io/nvidia/tritonserver@sha256:xxxxx name: kserve-container ports: - containerPort: 9000 name: h2c protocol: TCP volumeMounts: - mountPath: /dev/shm name: shm resources: limits: cpu: "1" memory: 2Gi requests: cpu: "1" memory: 2Gi protocolVersions: - v2 - grpc-v2 supportedModelFormats: - autoSelect: true name: tensorrt version: "8" - autoSelect: true name: tensorflow version: "1" - autoSelect: true name: tensorflow version: "2" - autoSelect: true name: onnx version: "1" - name: pytorch version: "1" - autoSelect: true name: triton version: "2" - autoSelect: true name: xgboost version: "1" - autoSelect: true name: python version: "1" volumes: - emptyDir: null medium: Memory sizeLimit: 2Gi name: shm
-
metadata.name
フィールドで、追加するランタイムの値が、すでに追加されているランタイムと一致していないことを確認してください。 オプション: 追加するランタイムのカスタム表示名を使用するには、次の例に示すように、
metadata.annotations.openshift.io/display-name
フィールドを追加し、値を指定します。apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: kserve-triton annotations: openshift.io/display-name: Triton ServingRuntime
注記ランタイムのカスタム表示名を設定しないと、OpenShift AI には
metadata.name
フィールドの値が表示されます。Create をクリックします。
Serving runtimes ページが開き、インストールされているランタイムの更新されたリストが表示されます。追加したランタイムが自動的に有効になっていることを確認します。ランタイム作成時に指定した API プロトコルが表示されます。
- オプション: ランタイムを編集するには、アクションメニュー (⋮) をクリックし、Edit を選択します。
検証
- 追加したモデルサービスランタイムは、Serving runtimes ページに有効な状態で表示されます。
3.11.4. シングルモデルサービングプラットフォームへのモデルのデプロイ
シングルモデルサービングプラットフォームを有効にすると、カスタムまたはプリインストールされたモデルサービングランタイムを有効にして、プラットフォームへのモデルのデプロイを開始できます。
Text Generation Inference Server (TGIS) は、Hugging Face TGI の初期のフォークに基づいています。Red Hat は、TGI モデルをサポートするスタンドアロン TGIS ランタイムの開発を継続します。モデルが OpenShift AI の現在のバージョンで機能しない場合、今後のバージョンでサポートが追加される可能性があります。それまでの間は、独自のカスタムランタイムを追加して TGI モデルをサポートすることもできます。詳細は、シングルモデルサービングプラットフォーム用のカスタムモデルサービングランタイムの追加 を参照してください。
前提条件
- Red Hat OpenShift AI にログインしている。
-
OpenShift AI グループを使用している場合は、OpenShift のユーザーグループまたは管理者グループ (
rhoai-users
やrhoai-admins
など) に属している。 - KServe をインストールしている。
- シングルモデルサービングプラットフォームを有効にしている。
- デプロイされたモデルのトークン認可と外部モデルルートを有効にするために、Authorino を認可プロバイダーとして追加している。詳細は、シングルモデルサービングプラットフォームの認可プロバイダーの追加 を参照してください。
- データサイエンスプロジェクトを作成した。
- S3 互換オブジェクトストレージにアクセスできる。
- デプロイするモデルについて、S3 互換オブジェクトストレージバケット内の関連フォルダーパスを把握している。
- Caikit-TGIS ランタイムを使用するために、モデルを Caikit 形式に変換している。例は、caikit-tgis-serving リポジトリーの Converting Hugging Face Hub models to Caikit format を参照してください。
- モデルサーバーでグラフィックスプロセッシングユニット (GPU) を使用する場合は、OpenShift AI で GPU サポートを有効にしている。NVIDIA GPU の有効化 を参照してください。
- KServe ランタイムに vLLM ServingRuntime を 使用するには、OpenShift AI で GPU サポートを有効にし、クラスターに Node Feature Discovery Operator をインストールおよび設定している。詳細は、Node Feature Discovery Operator のインストール と NVIDIA GPU の有効化 を参照してください。
KServe ランタイムの Gaudi accelerators サポートで vLLM ServingRuntime を使用するには、OpenShift AI でハイブリッドプロセッシングユニット(HPU)のサポートを有効にしている。これには、Intel Gaudi AI アクセラレーターオペレーターのインストールやアクセラレータープロファイルの設定が含まれます。詳細は、Setting up Gaudi for OpenShift および Working with accelerators を参照してください。
注記OpenShift AI 2.16 では、Red Hat はモデル提供の NVIDIA GPU および Intel Gaudi アクセラレーターをサポートします。
RHEL AI モデルをデプロイする。
- KServe ランタイムの vLLM ServingRuntime を 有効にしている。
- Red Hat コンテナーレジストリーからモデルをダウンロードし、S3 互換オブジェクトストレージにアップロードしている。
手順
左側のメニューで、Data Science Projects をクリックします。
Data Science Projects ページが開きます。
モデルをデプロイするプロジェクトの名前をクリックします。
プロジェクトの詳細ページが開きます。
- Models タブをクリックします。
次のいずれかの操作を実行します。
- Single-model serving platform タイルが表示された場合は、タイル上の Deploy model をクリックします。
- タイルが表示されない場合は、Deploy model ボタンをクリックします。
Deploy model ダイアログが開きます。
- Model deployment name フィールドに、デプロイするモデルの一意の名前を入力します。
- Serving runtime フィールドで、有効なランタイムを選択します。
- Model framework (name - version) リストから値を選択します。
- Number of model server replicas to deploy フィールドに値を指定します。
- Model server size リストから値を選択します。
次のオプションは、クラスターで GPU サポートを有効にし、アクセラレータープロファイルを作成した場合にのみ使用できます。
- Accelerator リストからアクセラレーターを選択します。
- 前の手順でアクセラレーターを選択した場合は、Number of accelerators フィールドで使用するアクセラレーターの数を指定します。
- オプション: Model route セクションで、Make deployed models available through an external route チェックボックスをオンにして、デプロイされたモデルを外部クライアントが利用できるようにします。
デプロイされたモデルに対する推論リクエストにトークン認可を要求するには、次のアクションを実行します。
- Require token authorization を選択します。
- Service account name フィールドに、トークンが生成されるサービスアカウント名を入力します。
モデルの場所を指定するには、次の一連のアクションのいずれかを実行します。
既存の接続を使用するには
- Existing connection を選択します。
- Name リストから、以前に定義したデータ接続を選択します。
Path フィールドに、指定したデータソース内のモデルを含むフォルダーパスを入力します。
重要OpenVINO Model Server ランタイムには、モデルパスの指定方法に関する特定の要件があります。詳細は、OpenShift AI リリースノートの既知の問題 RHOAIENG-3025 を参照してください。
新しい接続を使用するには
- モデルがアクセスできる新しいコネクションを定義するには、New connection を選択します。
- Name フィールドに、接続の一意の名前を入力します。
- Access key フィールドに、S3 互換オブジェクトストレージプロバイダーのアクセスキー ID を入力します。
- Secret key フィールドに、指定した S3 互換オブジェクトストレージアカウントのシークレットアクセスキーを入力します。
- Endpoint フィールドに、S3 互換オブジェクトストレージバケットのエンドポイントを入力します。
- Region フィールドに、S3 互換オブジェクトストレージアカウントのデフォルトのリージョンを入力します。
- Bucket フィールドに、S3 互換のオブジェクトストレージバケットの名前を入力します。
Path フィールドに、データファイルが含まれる S3 互換オブジェクトストレージ内のフォルダーパスを入力します。
重要OpenVINO Model Server ランタイムには、モデルパスの指定方法に関する特定の要件があります。詳細は、OpenShift AI リリースノートの既知の問題 RHOAIENG-3025 を参照してください。
(オプション) Configuration parameters セクションでランタイムパラメーターをカスタマイズします。
- Additional serving runtime arguments の値を変更して、デプロイされたモデルの動作を定義します。
Additional environment variables の値を変更して、モデルの環境で変数を定義します。
Configuration parameters セクションには、事前に定義された提供ランタイムパラメーター(利用可能な場合)が表示されます。
注記ポートまたはモデル提供ランタイム引数は特定の値を設定する必要があるため、変更しないでください。これらのパラメーターを上書きすると、デプロイメントが失敗する場合があります。
- Deploy をクリックします。
検証
- デプロイされたモデルがプロジェクトの Models タブに表示され、ダッシュボードの Model Serving ページで Status 列にチェックマークが付いて表示されていることを確認します。
3.11.5. デプロイされたモデル提供ランタイムのパラメーターのカスタマイズ
特定のモデルをデプロイしたり、既存のモデルデプロイメントを強化したりするには、デフォルトのパラメーター以外のパラメーターが必要になる場合があります。このような場合は、デプロイメントのニーズに合わせて既存のランタイムのパラメーターを変更できます。
ランタイムのパラメーターをカスタマイズすると、選択したモデルデプロイメントにのみ影響します。
前提条件
- OpenShift AI 管理者権限を持つユーザーとして OpenShift AI にログインしている。
- 単一モデル提供プラットフォームにモデルをデプロイしている。
手順
OpenShift AI ダッシュボードの左側のメニューで、Model Serving をクリックします。
Deployed models ページが開きます。
カスタマイズするモデル名の横にあるアクションメニュー(⋮)をクリックし、Edit を選択します。
Configuration parameters セクションには、事前に定義された提供ランタイムパラメーター(利用可能な場合)が表示されます。
Configuration parameters セクションのランタイムパラメーターをカスタマイズします。
- Additional serving runtime arguments の値を変更して、デプロイされたモデルの動作を定義します。
Additional environment variables の値を変更して、モデルの環境で変数を定義します。
注記ポートまたはモデル提供ランタイム引数は特定の値を設定する必要があるため、変更しないでください。これらのパラメーターを上書きすると、デプロイメントが失敗する場合があります。
- ランタイムパラメーターのカスタマイズが完了したら、Redeploy をクリックして、変更内容でモデルを保存し、デプロイします。
検証
- デプロイされたモデルがプロジェクトの Models タブに表示され、ダッシュボードの Model Serving ページで Status 列にチェックマークが付いて表示されていることを確認します。
設定した引数と変数が、
spec.predictor.model.args
とspec.predictor.model.env
に表示されるのを、次のいずれかのメソッドで確認します。- OpenShift コンソールから InferenceService YAML を確認します。
OpenShift CLI で以下のコマンドを使用します。
oc get -o json inferenceservice <inferenceservicename/modelname> -n <projectname>
3.11.6. カスタマイズ可能なモデル提供ランタイムパラメーター
デプロイメントのニーズに合わせて、既存のモデル提供ランタイムのパラメーターを変更できます。
サポートされる各提供ランタイムのパラメーターの詳細については、次の表を参照してください。
提供ランタイム | リソース |
---|---|
NVIDIA Triton Inference Server | |
Caikit Text Generation Inference Server (Caikit-TGIS) ServingRuntime for KServe | |
Caikit Standalone ServingRuntime for KServe | |
OpenVINO Model Server | |
Text Generation Inference Server (TGIS) Standalone ServingRuntime for KServe | |
vLLM ServingRuntime for KServe |
3.11.7. モデル保存用の OCI コンテナーの使用
モデルを S3 バケットまたは URI に保存する代わりに、モデルを OCI コンテナーにアップロードできます。モデルの保存に OCI コンテナーを使用すると、次のことが可能になります。
- 同じモデルを複数回ダウンロードすることを回避し、起動時間を短縮します。
- ローカルにダウンロードされるモデルの数を減らすことで、ディスク領域の使用量を削減します。
- 事前に取得したイメージを許可することで、モデルのパフォーマンスが向上します。
このガイドでは、OpenVINO モデルサーバー上の OCI イメージに保存されている、ONNX 形式の MobileNet v2-7 モデルを手動でデプロイする方法を説明します。
モデルストレージに OCI コンテナーを使用する機能は、現在、Red Hat OpenShift AI 2.15 でテクノロジープレビュー機能として利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
- ONNX 形式のモデルがある。
3.11.7.1. OCI イメージを作成し、コンテナーイメージにモデルを保存する
手順
ローカルマシンから、ダウンロードしたモデルとサポートファイルの両方を保存して OCI イメージを作成するための一時ディレクトリーを作成します。
cd $(mktemp -d)
一時ディレクトリー内に
models
フォルダーを作成し、モデルをダウンロードします。mkdir -p models/1 DOWNLOAD_URL=https://github.com/onnx/models/raw/main/validated/vision/classification/mobilenet/model/mobilenetv2-7.onnx curl -L $DOWNLOAD_URL -O --output-dir models/1/
注記OpenVINO では、モデルのバージョン管理に使用する番号付きサブディレクトリーが必要なため、サブディレクトリー
1
が使用されます。OpenVINO を使用していない場合は、OCI コンテナーイメージを使用するために1
サブディレクトリーを作成する必要はありません。次の内容を含む Docker ファイルを
Containerfile
という名前で作成します。FROM registry.access.redhat.com/ubi9/ubi-micro:latest COPY --chown=0:0 models /models RUN chmod -R a=rX /models # nobody user USER 65534
注記-
この例では、
ubi9-micro
がベースコンテナーイメージとして使用されています。KServe はシェルを使用してモデルファイルがモデルサーバーにアクセスできることを確認するため、scratch
などのシェルを提供しない空のイメージは使用できません。 -
コピーされたモデルファイルの所有権と読み取り権限は、
root
グループに付与されます。OpenShift は、ランダムなユーザー ID とroot
グループ ID を使用してコンテナーを実行します。グループの所有権を変更すると、確実にモデルサーバーがグループにアクセスできるようになります。
-
この例では、
tree
コマンドを使用して、モデルが表示されているディレクトリー構造に従っていることを確認します。tree . ├── Containerfile └── models └── 1 └── mobilenetv2-7.onnx
Podman を使用して OCI コンテナーイメージを作成し、レジストリーにアップロードします。たとえば、レジストリーとして Quay を使用する場合は次のようになります。
podman build --format=oci -t quay.io/<user_name>/<repository_name>:<tag_name> . podman push quay.io/<user_name>/<repository_name>:<tag_name>
注記リポジトリーがプライベートの場合は、コンテナーイメージをアップロードする前に、レジストリーに対して認証されていることを確認してください。
3.11.7.2. パブリックリポジトリーから OCI イメージに保存されたモデルをデプロイする
KServe では、デフォルトでモデルはクラスター外部に公開され、認可によって保護されません。
モデルをデプロイするための namespace を作成します。
oc new-project oci-model-example
OpenShift AI アプリケーションプロジェクトの
kserve-ovms
テンプレートを使用してServingRuntime
リソースを作成し、新しい namespace で OpenVINO モデルサーバーを設定します。oc process -n redhat-ods-applications -o yaml kserve-ovms | oc apply -f -
ServingRuntime
がkserve-ovms
の名前で作成されたことを確認します。oc get servingruntimes NAME DISABLED MODELTYPE CONTAINERS AGE kserve-ovms openvino_ir kserve-container 1m
次の値を持つ
InferenceService
YAML リソースを作成します。apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: sample-isvc-using-oci spec: predictor: model: runtime: kserve-ovms # Ensure this matches the name of the ServingRuntime resource modelFormat: name: onnx storageUri: oci://quay.io/<user_name>/<repository_name>:<tag_name>
重要ServingRuntime
およびInferenceService
設定では、リソース制限は設定されません。
検証
InferenceService
リソースを作成すると、KServe は storageUri
フィールドによって参照される OCI イメージに保存されているモデルをデプロイします。次のコマンドを実行して、デプロイメントのステータスを確認します。
oc get inferenceservice NAME URL READY PREV LATEST PREVROLLEDOUTREVISION LATESTREADYREVISION AGE sample-isvc-using-oci https://sample-isvc-using-oci-oci-model-example.example True 100 sample-isvc-using-oci-predictor-00001 1m
3.11.7.3. OCI イメージに保存されたモデルをプライベートリポジトリーからデプロイする
プライベート OCI リポジトリーから保存されたモデルをデプロイするには、イメージプルシークレットを設定する必要があります。イメージプルシークレットの作成の詳細は、イメージプルシークレットの使用 を参照してください。
前のセクションの手順に従ってモデルをデプロイします。ただし、手順 3 で
InferenceService
を作成するときに、spec.predictor.imagePullSecrets
フィールドにプルシークレットを指定します。apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: sample-isvc-using-private-oci spec: predictor: model: runtime: kserve-ovms modelFormat: name: onnx storageUri: oci://quay.io/<user_name>/<repository_name>:<tag_name> imagePullSecrets: # Specify image pull secrets to use for fetching container images (including OCI model images) - name: <pull-secret-name>