モデルの提供

Red Hat OpenShift AI Cloud Service 1

Red Hat OpenShift AI Cloud Service でモデルを提供する

概要

Red Hat OpenShift AI Cloud Service でモデルを提供します。トレーニングされたモデルを提供すると、それらをテストしてインテリジェントなアプリケーションに実装できるようになります。

第1章 モデルサービスについて

Red Hat OpenShift AI でトレーニングされたモデルを提供するということは、モデルを OpenShift クラスターにデプロイしてテストし、インテリジェントなアプリケーションに統合することを意味します。モデルをデプロイすると、API を使用してアクセスできるサービスとして利用可能になります。これにより、API 呼び出しを通じて提供したデータ入力に基づいて、予測を返すことができます。このプロセスはモデル 推論 として知られています。OpenShift AI でモデルを提供すると、デプロイされたモデルに対してアクセスできる推論エンドポイントが、ダッシュボードに表示されます。

OpenShift AI は、次のモデルサービスプラットフォームを提供しています。

シングルモデルサービスプラットフォーム
OpenShift AI には、大規模言語モデル (LLM) などの大規模モデルをデプロイするために、KServe コンポーネントをベースとした シングルモデルサービスプラットフォーム が組み込まれています。各モデルが独自のモデルサーバーからデプロイされるため、シングルモデルサービスプラットフォームは、多くのリソースを必要とする大規模なモデルのデプロイ、監視、スケーリング、および保守に役立ちます。
マルチモデルサービスプラットフォーム
OpenShift AI には、小規模および中規模のモデルをデプロイするために、ModelMesh コンポーネントをベースとした マルチモデルサービスプラットフォーム が組み込まれています。マルチモデルサービスプラットフォームでは、同じモデルサーバーに複数のモデルをデプロイできます。デプロイされた各モデルはサーバーリソースを共有します。このアプローチは、有限のコンピュートリソースまたは Pod を持つ OpenShift クラスターで有利です。

第2章 中小規模のモデルの提供

OpenShift AI には、小規模および中規模のモデルをデプロイするために、ModelMesh コンポーネントをベースとした マルチモデルサービスプラットフォーム が組み込まれています。マルチモデルサービスプラットフォームでは、複数のモデルを同じモデルサーバーからデプロイし、サーバーリソースを共有できます。

2.1. モデルサーバーの設定

2.1.1. マルチモデルサービスプラットフォームの有効化

マルチモデルサービスプラットフォームを使用するには、まずプラットフォームを有効にする必要があります。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift の管理者グループ (rhoai-admins など) の一員となります。
  • クラスター管理者は OpenShift AI ダッシュボード設定を編集しておら 、ModelMesh コンポーネントを使用するマルチモデル提供プラットフォームを選択する機能を無効にしていません。詳細は、ダッシュボード設定オプション を参照してください。

手順

  1. OpenShift AI ダッシュボードの左側のメニューで、SettingsCluster settings をクリックします。
  2. モデルサービスプラットフォーム セクションを見つけます。
  3. Multi-model serving platform チェックボックスをオンにします。
  4. Save Changes をクリックします。

2.1.2. マルチモデルサービスプラットフォーム用のカスタムモデルサービスランタイムの追加

モデルサービスランタイムは、指定されたモデルフレームワークのセット (つまり、形式) のサポートを追加します。デフォルトでは、マルチモデルサービスプラットフォームには OpenVINO Model Server ランタイムが含まれています。ただし、このランタイムがニーズを満たさない場合 (たとえば、特定のモデル形式をサポートしていない場合)、独自のカスタムランタイムを追加できます。

管理者は、Red Hat OpenShift AI ダッシュボードを使用して、カスタムのモデルサービスランタイムを追加して有効にすることができます。その後、マルチモデルサービスプラットフォーム用の新しいモデルサーバーを作成する際に、カスタムランタイムを選択できます。

注記

OpenShift AI を使用すると、独自のカスタムランタイムを追加できますが、ランタイム自体はサポートされません。カスタムランタイムを正しく設定して維持することは、お客様の責任となります。また、追加するカスタムランタイムを使用するライセンスの取得について確認することも、お客様の責任となります。

前提条件

  • OpenShift AI に管理者としてログインしている。
  • モデルサーバーをプロジェクトに追加 する方法を理解している。カスタムのモデルサービスランタイムを追加した場合は、そのランタイムを使用するように新しいモデルサーバーを設定する必要があります。
  • kserve/modelmesh-serving リポジトリー内のサンプルランタイムを確認している。これらの例を開始点として使用できます。ただし、各ランタイムを OpenShift AI にデプロイするには、さらにいくつかの変更が必要です。必要な変更は、次の手順で説明します。

    注記

    OpenShift AI には、デフォルトで OpenVINO Model Server ランタイムが含まれています。このランタイムを OpenShift AI に追加する必要はありません。

手順

  1. OpenShift AI ダッシュボードから、Settings > Serving runtimes をクリックします。

    Serving runtimes ページが開き、すでにインストールされ有効になっているモデルサービスランタイムが表示されます。

  2. カスタムランタイムを追加するには、次のオプションのいずれかを選択します。

    • 既存のランタイム (OpenVINO Model Server ランタイムなど) で開始するには、既存のランタイムの横にあるアクションメニュー (⋮) をクリックしてから、Duplicate をクリックします。
    • 新しいカスタムランタイムを追加するには、Add serving runtime をクリックします。
  3. Select the model serving platforms this runtime supports リストで、Multi-model serving platform を選択します。

    注記

    マルチモデルサービスプラットフォームは、REST プロトコルのみサポートします。つまり、Select the API protocol this runtime supports リスト内のデフォルト値は変更できません。

  4. オプション: (既存のランタイムを複製するのではなく) 新しいランタイムを開始した場合は、次のオプションのいずれかを選択してコードを追加します。

    • YAML ファイルをアップロードする

      1. Upload files をクリックします。
      2. ファイルブラウザーで、コンピューター上の YAML ファイルを選択します。このファイルは、kserve/modelmesh-serving リポジトリーからダウンロードしたサンプルランタイムの 1 つである可能性があります。

        埋め込み YAML エディターが開き、アップロードしたファイルの内容が表示されます。

    • エディターに YAML コードを直接入力する

      1. Start from scratch をクリックします。
      2. 埋め込みエディターに YAML コードを直接入力または貼り付けます。貼り付ける YAML は、kserve/modelmesh-serving リポジトリー内のサンプルランタイムの 1 つからコピーされる場合があります。
  5. オプション: kserve/modelmesh-serving リポジトリーにサンプルランタイムの 1 つを追加する場合は、次の変更を実行します。

    1. YAML エディターで、ランタイムの kind フィールドを見つけます。このフィールドの値を ServingRuntime に更新します。
    2. kserve/modelmesh-serving リポジトリーの kustomization.yaml ファイルで、追加するランタイムの newNamenewTag の値をメモします。これらの値は後の手順で指定します。
    3. カスタムランタイムの YAML エディターで、containers.image フィールドを見つけます。
    4. kustomization.yaml ファイルで前にメモした値に基づいて、containers.image フィールドの値を newName:newTag 形式で更新します。以下に例を示します。

      Nvidia Triton Inference Server
      image: nvcr.io/nvidia/tritonserver:23.04-py3
      Seldon Python MLServer
      image: seldonio/mlserver:1.3.2
      TorchServe
      image: pytorch/torchserve:0.7.1-cpu
  6. metadata.name フィールドで、追加するランタイムの値が一意であることを確認します (つまり、その値がすでに追加したランタイムと一致しないこと)。
  7. オプション: 追加するランタイムのカスタム表示名を設定するには、次の例に示すように、metadata.annotations.openshift.io/display-name フィールドを追加し、値を指定します。

    apiVersion: serving.kserve.io/v1alpha1
    kind: ServingRuntime
    metadata:
      name: mlserver-0.x
      annotations:
        openshift.io/display-name: MLServer
    注記

    ランタイムのカスタム表示名を設定しないと、OpenShift AI には metadata.name フィールドの値が表示されます。

  8. Add をクリックします。

    Serving runtimes ページが開き、インストールされているランタイムの更新されたリストが表示されます。追加したランタイムが自動的に有効になることを確認します。

  9. オプション: カスタムランタイムを編集するには、アクションメニュー (⋮) をクリックし、Edit を選択します。

検証

  • 追加したカスタムモデルサービスランタイムは、Serving runtimes ページに有効な状態で表示されます。

関連情報

2.1.3. マルチモデルサービスプラットフォーム用のモデルサーバーの追加

マルチモデルサービスプラットフォームを有効にした場合は、モデルをデプロイするようにモデルサーバーを設定する必要があります。大規模なデータセットを使用するために追加のコンピューティング能力が必要な場合は、モデルサーバーにアクセラレーターを割り当てることができます。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用する場合は、OpenShift のユーザーグループ、または、管理者グループ (rhods-usersrhods-admins など) に属している。
  • モデルサーバーを追加できるデータサイエンスプロジェクトを作成している。
  • マルチモデルサービスプラットフォームを有効化している。
  • モデルサーバーにカスタムのモデルサービスランタイムを使用する場合は、ランタイムを追加して有効にしている。カスタムモデルサービスランタイムの追加 を参照してください。
  • モデルサーバーでグラフィックスプロセッシングユニット (GPU) を使用する場合は、OpenShift AI で GPU サポートを有効にしている。OpenShift AI での GPU サポートの有効化 を参照してください。

手順

  1. OpenShift AI ダッシュボードの左側のメニューで、Data Science Projects をクリックします。

    Data science projects のページが開きます。

  2. モデルサーバーを設定するプロジェクトの名前をクリックします。

    プロジェクトの詳細ページが開きます。

  3. Models タブをクリックします。
  4. 次のいずれかの操作を実行します。

    • ​Multi-model serving platform タイルが表示された場合は、タイル上の Add model server をクリックします。
    • タイルが表示されない場合は、Add model server ボタンをクリックします。

    Add model server ダイアログが開きます。

  5. Model sever name フィールドに、モデルサーバーの一意の名前を入力します。
  6. Serving runtime リストから、OpenShift AI デプロイメントにインストールされ有効になっているモデルサービスランタイムを選択します。

    注記

    モデルサーバーで カスタム モデルサービスランタイムを使用していて、GPU を使用したい場合は、カスタムランタイムが GPU をサポートし、GPU を使用するように適切に設定されていることを確認する必要があります。

  7. Number of model replicas to deploy フィールドに値を指定します。
  8. Model server size リストから値を選択します。
  9. オプション: 前の手順で Custom を選択した場合は、Model server size セクションで次を設定して、モデルサーバーをカスタマイズします。

    1. CPUs requested フィールドで、モデルサーバーで使用する CPU の数を指定します。このフィールドの横にあるリストを使用して、値をコアまたはミリコアで指定します。
    2. CPU limit フィールドに、モデルサーバーで使用する CPU の最大数を指定します。このフィールドの横にあるリストを使用して、値をコアまたはミリコアで指定します。
    3. Memory requested フィールドに、モデルサーバーに要求されたメモリーをギビバイト (Gi) 単位で指定します。
    4. Memory limit フィールドに、モデルサーバーの最大メモリー制限をギビバイト (Gi) 単位で指定します。
  10. オプション: Accelerator リストからアクセラレーターを選択します。

    1. 前述の手順でアクセラレーターを選択した場合は、使用するアクセラレーターの数を指定します。
  11. オプション: Model route セクションで、Make deployed models available through an external route チェックボックスをオンにして、デプロイされたモデルを外部クライアントが利用できるようにします。
  12. オプション: Token authorization セクションで、Require token authentication チェックボックスをオンにして、モデルサーバーにトークン認証を要求します。トークン認証の設定を完了するには、次のアクションを実行します。

    1. Service account name フィールドに、トークンが生成されるサービスアカウント名を入力します。生成されたトークンは、モデルサーバーの設定時に作成され、Token secret フィールドに表示されます。
    2. 追加のサービスアカウントを追加するには、Add a service account をクリックし、別のサービスアカウント名を入力します。
  13. Add をクリックします。

    • 設定したモデルサーバーは、 Models and model servers 一覧のプロジェクトの Models タブに表示されます。
  14. オプション: モデルサーバーを更新するには、モデルサーバーの横にあるアクションメニュー () をクリックし、Edit model server を選択します。

2.1.4. モデルサーバーの削除

モデルをホストするためにモデルサーバーが必要なくなった場合は、データサイエンスプロジェクトからモデルサーバーを削除できます。

注記

モデルサーバーを削除すると、そのモデルサーバーでホストされているモデルも削除されます。その結果、アプリケーションはモデルを利用できなくります。

前提条件

  • データサイエンスプロジェクトと関連するモデルサーバーを作成している。
  • モデルにアクセスするアプリケーションのユーザーに、モデルが利用できなくなることを通知している。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。

手順

  1. OpenShift AI ダッシュボードから、Data Science Projects をクリックします。

    Data science projects のページが開きます。

  2. モデルサーバーを削除するプロジェクトの名前をクリックします。

    プロジェクトの詳細ページが開きます。

  3. Models タブをクリックします。
  4. 削除するモデルサーバーを持つプロジェクトの横にあるアクションメニュー()をクリックし、Delete model server をクリックします。

    Delete model server ダイアログが開きます。

  5. テキストフィールドにモデルサーバーの名前を入力して、削除することを確認します。
  6. Delete model server をクリックします。

検証

  • 削除したモデルサーバーは、プロジェクトの Models タブに表示されなくなります。

2.2. プロイされたモデルの使用

2.2.1. マルチモデルサービスプラットフォームを使用したモデルのデプロイ

OpenShift AI にトレーニングされたモデルをデプロイし、それらをテストしてインテリジェントなアプリケーションに実装できます。モデルをデプロイすると、API を使用してアクセスできるサービスとして利用可能になります。これにより、データ入力に基づく予測を返すことができます。

マルチモデルサービスプラットフォームを有効にすると、プラットフォーム上にモデルをデプロイできます。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-users など) に属している。
  • マルチモデルサービスプラットフォームを有効化している。
  • データサイエンスプロジェクトを作成し、モデルサーバーを追加している。
  • S3 互換オブジェクトストレージにアクセスできる。
  • デプロイするモデルについて、S3 互換オブジェクトストレージバケット内の関連フォルダーパスを把握している。

手順

  1. OpenShift AI ダッシュボードの左側のメニューで、Data Science Projects をクリックします。

    Data science projects のページが開きます。

  2. モデルをデプロイするプロジェクトの名前をクリックします。

    プロジェクトの詳細ページが開きます。

  3. Models タブをクリックします。
  4. Deploy model をクリックします。
  5. モデルをデプロイするためのプロパティーを次のように設定します。

    1. Model name フィールドに、デプロイするモデルの一意の名前を入力します。
    2. Model framework リストから、モデルのフレームワークを選択します。

      注記

      Model framework リストには、モデルサーバーの設定時に指定したモデルサービスランタイムによってサポートされるフレームワークのみが表示されます。

    3. S3 互換オブジェクトストレージからデプロイするモデルの場所を指定するには、次の一連のアクションのいずれかを実行します。

      • 既存のデータ接続を使用するには

        1. Existing data connection を選択します。
        2. Name リストから、以前に定義したデータ接続を選択します。
        3. Path フィールドに、指定したデータソース内のモデルを含むフォルダーパスを入力します。
      • 新しいデータ接続を使用するには

        1. モデルがアクセスできる新しいデータ接続を定義するには、New data connection を選択します。
        2. Name フィールドに、データ接続の一意の名前を入力します。
        3. Access key フィールドに、S3 互換オブジェクトストレージプロバイダーのアクセスキー ID を入力します。
        4. Secret key フィールドに、指定した S3 互換オブジェクトストレージアカウントのシークレットアクセスキーを入力します。
        5. Endpoint フィールドに、S3 互換オブジェクトストレージバケットのエンドポイントを入力します。
        6. Region フィールドに、S3 互換オブジェクトストレージアカウントのデフォルトのリージョンを入力します。
        7. Bucket フィールドに、S3 互換オブジェクトストレージバケットの名前を入力します。
        8. Path フィールドに、データファイルが含まれる S3 互換オブジェクトストレージ内のフォルダーパスを入力します。
    4. Deploy をクリックします。

検証

  • デプロイされたモデルがプロジェクトの Models タブと、ダッシュボードの Model Serving ページで Status 列にチェックマークが表示されていることを確認します。

2.2.2. デプロイされたモデルの表示

作業の結果を分析するために、Red Hat OpenShift AI にデプロイされたモデルのリストを表示できます。デプロイされたモデルとそのエンドポイントの現在のステータスも表示できます。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。

手順

  1. OpenShift AI ダッシュボードで、Model Serving をクリックします。

    Deployed models ページが開きます。

    このページには、モデルごとに、モデル名、モデルがデプロイされているプロジェクト、モデルが使用するサービスランタイム、デプロイメントステータスなどの詳細が表示されます。

  2. オプション: 特定のモデルの場合は、Inference endpoint 列のリンクをクリックして、デプロイされたモデルの推論エンドポイントを表示します。

検証

  • 以前にデプロイされたデータサイエンスモデルのリストが、Deployed models ページに表示されます。

2.2.3. デプロイされたモデルのデプロイメントプロパティーの更新

以前にデプロイされたモデルのデプロイメントプロパティーを更新できます。これにより、モデルのデータ接続および名前を変更できます。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。
  • OpenShift AI にモデルをデプロイしている。

手順

  1. OpenShift AI ダッシュボードで、Model serving をクリックします。

    Deployed models ページが開きます。

  2. 更新するデプロイメントプロパティーを持つモデルの横にあるアクションメニュー () をクリックし、Edit をクリックします。

    Deploy model ダイアログが開きます。

  3. 次のようにモデルのデプロイメントプロパティーを更新します。

    1. Model Name フィールドに、モデルの一意の名前を新たに入力します。
    2. Model framework リストから、モデルのフレームワークを選択します。

      注記

      Model framework リストには、モデルサーバーの設定時に指定したモデルサービスランタイムによってサポートされるフレームワークのみが表示されます。

    3. モデルの場所の指定方法を更新するには、次の一連のアクションのいずれかを実行します。

      • 既存のデータ接続を指定した場合

        1. Path フィールドで、指定したデータソース内のモデルを含むフォルダーパスを更新します。
      • 以前に新しいデータ接続を指定した場合

        1. Name フィールドで、データ接続の一意の名前を更新します。
        2. Access key フィールドで、S3 互換オブジェクトストレージプロバイダーのアクセスキー ID を更新します。
        3. Secret key フィールドで、指定した S3 互換オブジェクトストレージアカウントのシークレットアクセスキーを更新します。
        4. Endpoint フィールドで、S3 互換オブジェクトストレージバケットのエンドポイントを更新します。
        5. Region フィールドで、S3 互換オブジェクトストレージアカウントのデフォルトのリージョンを更新します。
        6. Bucket フィールドで、S3 互換オブジェクトストレージバケットの名前を更新します。
        7. Path フィールドで、データファイルを含む S3 互換オブジェクトストレージ内のフォルダーパスを更新します。
    4. Deploy をクリックします。

検証

  • デプロイメントプロパティーを更新したモデルは、ダッシュボードの Model Serving ページに表示されます。

2.2.4. デプロイされたモデルの削除

以前にデプロイしたモデルを削除できます。これにより、不要になったデプロイ済みのモデルを削除できます。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。
  • モデルをデプロイしている。

手順

  1. OpenShift AI ダッシュボードで、Model serving をクリックします。

    Deployed models ページが開きます。

  2. 削除するデプロイモデルの横にあるアクションメニュー () をクリックし、Delete をクリックします。

    Delete deployed model ダイアログが開きます。

  3. テキストフィールドにデプロイしたモデルの名前を入力し、削除することを確認します。
  4. Delete deployed model をクリックします。

検証

  • 削除したモデルは、Deployed models ページに表示されなくなります。

2.3. マルチモデル提供プラットフォームのモデル提供ランタイムメトリクスの表示

クラスター管理者がマルチモデル提供プラットフォームのモニタリングを設定した後、管理者以外のユーザーは OpenShift Web コンソールを使用して、ModelMesh コンポーネントのモデル提供ランタイムメトリックを表示できます。

前提条件

手順

  1. OpenShift Web コンソールにログインします。
  2. Developer パースペクティブに切り替えます。
  3. 左側のメニューで、Observe をクリックします。
  4. 開発者が 行うユーザー定義プロジェクトのメトリクスのクエリー(Red Hat OpenShift Dedicated)または開発者と しての ユーザー定義プロジェクトのメトリクスのクエリー (Red Hat OpenShift Service on AWS)で説明されているように、Web コンソールを使用して modelmesh_* メトリクスのクエリーを実行します。

2.4. モデルのパフォーマンスのモニタリング

2.4.1. モデルサーバー上のすべてのモデルのパフォーマンスメトリクスの表示

OpenShift AI では、モデルサーバー上にデプロイされているすべてのモデルについて、次のメトリクスを監視できます。

  • HTTP リクエスト - サーバー上のすべてのモデルで失敗または成功した HTTP リクエストの数。

    注記: デプロイされたモデルの HTTP リクエストメトリクスの表示 で説明されているように、特定のモデルで失敗または成功した HTTP リクエストの数を表示することもできます。

  • 平均応答時間 (ミリ秒) - サーバー上のすべてのモデルについて、モデルサーバーがリクエストに応答するのにかかる平均時間。
  • CPU 使用率 (%) - サーバー上のすべてのモデルで現在使用されている CPU 容量の割合。
  • メモリー使用率 (%) - サーバー上のすべてのモデルで現在使用されているシステムメモリーの割合。

これらのメトリクスの時間範囲と更新間隔を指定すると、使用量のピーク時間帯や、指定した時間におけるモデルのパフォーマンスなどを判断するのに役立ちます。

前提条件

  • Red Hat OpenShift AI をインストールしている。
  • OpenShift AI がインストールされている OpenShift クラスターで、ユーザーのワークロードモニタリングが有効化されている。
  • OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。
  • マルチモデル提供プラットフォームにモデルをデプロイしている。

手順

  1. OpenShift AI ダッシュボードのナビゲーションメニューから、Data Science Projects をクリックします。

    Data science projects のページが開きます。

  2. 監視するデータサイエンスプロジェクトを含むプロジェクトの名前をクリックします。
  3. プロジェクトの詳細ページで、Models タブをクリックします。
  4. 関心のあるモデルサーバーの行で、アクションメニュー (⋮) をクリックしてから、View model server metrics を選択します。
  5. オプション: モデルサーバーのメトリクスページで、次のオプションを設定します。

    • 時間範囲 - メトリクスを追跡する期間を指定します。1 時間、24 時間、7 日、30 日のいずれかの値を選択できます。
    • 更新間隔 - (最新のデータを表示するために) メトリクスページのグラフを更新する頻度を指定します。15 秒、30 秒、1 分、5 分、15 分、30 分、1 時間、2 時間、1 日の値のいずれかを選択できます。
  6. 下にスクロールして、HTTP リクエスト、平均応答時間、CPU 使用率、およびメモリー使用率のデータグラフを表示します。

検証

モデルサーバーのメトリクスページでは、パフォーマンスメトリクスデータのグラフが表示されます。

2.4.2. デプロイされたモデルの HTTP リクエストメトリクスの表示

マルチモデル提供プラットフォームにデプロイされた特定のモデルについて、失敗または成功した HTTP 要求を示すグラフを表示できます。

前提条件

  • Red Hat OpenShift AI をインストールしている。
  • OpenShift AI がインストールされている OpenShift クラスターで、ユーザーのワークロードモニタリングが有効化されている。
  • クラスター管理者が OpenShift AI ダッシュボード設定を編集しておら Model Serving ページの Endpoint Performance タブを非表示にしている。詳細は、ダッシュボード設定オプション を参照してください。
  • OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。
  • マルチモデル提供プラットフォームにモデルをデプロイしている。

手順

  1. OpenShift AI ダッシュボードのナビゲーションメニューから、Model Serving を選択します。
  2. Deployed models ページで、モデルを選択します。
  3. オプション: Endpoint performance タブで、次のオプションを設定します。

    • 時間範囲 - メトリクスを追跡する期間を指定します。1 時間、24 時間、7 日、30 日のいずれかの値を選択できます。
    • 更新間隔 - (最新のデータを表示するために) メトリクスページのグラフを更新する頻度を指定します。15 秒、30 秒、1 分、5 分、15 分、30 分、1 時間、2 時間、1 日の値のいずれかを選択できます。

検証

Endpoint performance タブには、モデルの HTTP メトリクスのグラフが表示されます。

第3章 大規模モデルの提供

Red Hat OpenShift AI には、大規模言語モデル (LLM) などの大規模モデルをデプロイするために、KServe コンポーネントをベースとした シングルモデルサービスプラットフォーム が組み込まれています。各モデルが独自のモデルサーバーからデプロイされるため、シングルモデルサービスプラットフォームは、多くのリソースを必要とする大規模なモデルのデプロイ、監視、スケーリング、および保守に役立ちます。

3.1. シングルモデルサービスプラットフォームについて

OpenShift AI には、大規模言語モデル (LLM) などの大規模モデルをデプロイするために、KServe コンポーネントをベースとした シングルモデルサービスプラットフォーム が組み込まれています。各モデルが独自のモデルサーバーからデプロイされるため、シングルモデルサービスプラットフォームは、多くのリソースを必要とする大規模なモデルのデプロイ、監視、スケーリング、および保守に役立ちます。

3.1.1. コンポーネント

  • KServe : あらゆるタイプのモデルに対するモデルサービスを調整する Kubernetes カスタムリソース定義 (CRD)。これには、指定されたモデルサーバータイプの読み込みを実装するモデルサービングランタイムが含まれます。KServe は、デプロイメントオブジェクト、ストレージアクセス、およびネットワーク設定のライフサイクルを処理します。
  • Red Hat OpenShift Serverless: モデルのサーバーレスのデプロイメントを可能にするクラウドネイティブ開発モデル。OpenShift Serverless は、オープンソースの Knative プロジェクトをベースにしています。
  • Red Hat OpenShift Service Mesh: トラフィックフローを管理し、アクセスポリシーを適用するサービスメッシュネットワーキングレイヤー。OpenShift Service Mesh は、オープンソースの Istio プロジェクトをベースにしています。

3.1.2. インストールオプション

単一モデルのサービスプラットフォームをインストールするには、次のオプションがあります。

自動インストール

OpenShift クラスターに ServiceMeshControlPlane または KNativeServing リソースをまだ作成していない場合は、KServe とその依存関係をインストールするように Red Hat OpenShift AI Operator を設定できます。

自動インストールの詳細は、KServe の自動インストールの設定 を参照してください。

手動インストール

OpenShift クラスターに ServiceMeshControlPlane または KNativeServing リソースをすでに作成している場合は、KServe とその依存関係をインストールするように Red Hat OpenShift AI Operator を 設定できません。この状況では、KServe を手動でインストールする必要があります。

手動インストールの詳細は、KServe の手動インストール を 参照してください。

3.1.3. モデル提供ランタイム

KServe をインストールすると、OpenShift AI ダッシュボードを使用して、カスタムまたはプリインストールされたモデル提供ランタイムを使用してモデルをデプロイできます。

OpenShift AI には、次の KServe 用のプリインストールされたランタイムが組み込まれています。

  • スタンドアロンの TGIS ランタイム
  • 複合 Caikit-TGIS ランタイム
  • OpenVINO Model Server
注記
  • Text Generation Inference Server (TGIS) は、Hugging Face TGI の初期のフォークに基づいています。Red Hat は、TGI モデルをサポートするスタンドアロン TGIS ランタイムの開発を継続します。モデルが OpenShift AI の現在のバージョンで機能しない場合、今後のバージョンでサポートが追加される可能性があります。それまでの間は、独自のカスタムランタイムを追加して TGI モデルをサポートすることもできます。詳細は、シングルモデルサービスプラットフォーム用のカスタムモデルサービスランタイムの追加 を参照してください。
  • 複合 Caikit-TGIS ランタイムは、Caikit および Text Generation Inference Server (TGIS) に基づいています。このランタイムを使用するには、モデルを Caikit 形式に変換する必要があります。例については、caikit-tgis-serving リポジトリーの Converting Hugging Face Hub models to Caikit format を参照してください。

3.1.4. 認可

Authorino をシングルモデル提供プラットフォームの承認プロバイダーとして追加できます。認可プロバイダーを追加すると、プラットフォームにデプロイするモデルのトークン承認を有効にすることができます。これにより、承認された当事者のみがモデルへの推論リクエストを送信できるようになります。

Authorino をシングルモデル提供プラットフォームで承認プロバイダーとして追加するには、以下のオプションがあります。

  • 単一モデル提供プラットフォームの自動インストールがクラスターに可能な場合は、自動インストールプロセスの一部として Authorino を含めることができます。
  • シングルモデル提供プラットフォームを手動でインストールする必要がある場合は、Authorino を手動で設定する必要があります。

シングルモデル提供プラットフォームのインストールオプションを選択する方法については、インストールオプション を参照してください。

3.1.5. Monitoring

単一モデル提供プラットフォームのモニタリングを設定し、Prometheus を使用して、事前にインストールされた各モデル提供ランタイムのメトリクスを収集できます。

3.2. KServe の自動インストールの設定

OpenShift クラスターに ServiceMeshControlPlane または KNativeServing リソースをまだ作成していない場合は、KServe とその依存関係をインストールするように Red Hat OpenShift AI Operator を設定できます。

重要

クラスター上に ServiceMeshControlPlane または KNativeServing リソースを作成している場合、Red Hat OpenShift AI Operator は KServe とその依存関係をインストールできず、インストールは続行されません。この状況では、手動のインストール手順に従って KServe をインストールする必要があります。

前提条件

  • OpenShift クラスターのクラスター管理者権限を持っている。
  • クラスターには 4 つの CPU と 16 GB のメモリーを備えたノードがある。
  • OpenShift コマンドラインインターフェイス (CLI) をダウンロードしてインストールしている。詳細は、OpenShift CLI のインストール (Red Hat OpenShift Dedicated) または OpenShift CLI のインストール (Red Hat OpenShift Service on AWS) を参照してください。
  • Red Hat OpenShift Service Mesh Operator と依存する Operator が インストール されています。

    注記

    KServe の自動インストールを有効にするには、Red Hat OpenShift Service Mesh に必要な Operator のみ をインストールします。追加の設定を実行したり、ServiceMeshControlPlane リソースを作成したりしないでください。

  • Red Hat OpenShift Serverless Operator が インストールされている

    注記

    KServe の自動インストールを有効にするには、Red Hat OpenShift Serverless Operator のみ をインストールします。追加の設定を実行したり、KNativeServing リソースを作成したりしないでください。

  • Authorino を認可プロバイダーとして追加し、デプロイされたモデルのトークン認証を有効にできるようにするには、Red Hat - Authorino Operator がインストールされている。Authorino Operator のインストール を 参照してください。

手順

  1. OpenShift Web コンソールにクラスター管理者としてログインします。
  2. Web コンソールで、OperatorsInstalled Operators をクリックし、Red Hat OpenShift AI Operator をクリックします。
  3. 次のように OpenShift Service Mesh をインストールします。

    1. DSC Initialization タブをクリックします。
    2. default-dsci オブジェクトをクリックします。
    3. YAML タブをクリックします。
    4. 以下に示すように、spec セクションで、serviceMesh コンポーネントの managementState フィールドの値が Managed に設定されていることを検証します。

      spec:
       applicationsNamespace: redhat-ods-applications
       monitoring:
         managementState: Managed
         namespace: redhat-ods-monitoring
       serviceMesh:
         controlPlane:
           metricsCollection: Istio
           name: data-science-smcp
           namespace: istio-system
         managementState: Managed
      注記

      デフォルトで serviceMesh コンポーネントに指定されている istio-system namespace を変更しないでください。他の namespace 値はサポートされていません。

    5. Save をクリックします。

      DSCInitialization オブジェクトに追加した設定に基づいて、Red Hat OpenShift AI Operator は OpenShift Service Mesh をインストールします。

  4. (Red Hat OpenShift Service on AWS のみ): OpenShift クラスターが Red Hat OpenShift Service on AWS (ROSA) で実行している場合は、サービスメッシュコントロールプレーン設定を機能させるために追加の設定が必要です。この設定を追加するには、data-science-smcp サービスメッシュコントロールプレーンオブジェクトを次のように編集します。

    1. Web コンソールで、OperatorsInstalled Operators をクリックし、Red Hat OpenShift Service Mesh Operator をクリックします。
    2. Istio Service Mesh Control Plane タブをクリックします。
    3. data-science-smcp オブジェクトをクリックします。
    4. YAML タブをクリックします。
    5. 以下に示すように、spec.security.identity セクションに type というフィールドを追加し、値を ThirdParty に設定します。

       security:
          dataPlane:
            mtls: true
          identity:
            type: ThirdParty
    6. Save をクリックします。
  5. 次のように、KServe と OpenShift Serverless の両方をインストールします。

    1. Web コンソールで、OperatorsInstalled Operators をクリックし、Red Hat OpenShift AI Operator をクリックします。
    2. Data Science Cluster タブをクリックします。
    3. default-dsc DSC オブジェクトをクリックします。
    4. YAML タブをクリックします。
    5. spec.components セクションで、次のように kserve コンポーネントを設定します。

      spec:
       components:
         kserve:
           managementState: Managed
           serving:
             ingressGateway:
               certificate:
                 secretName: knative-serving-cert
                 type: SelfSigned
             managementState: Managed
             name: knative-serving
    6. Save をクリックします。

      前述の設定では、OpenShift Service Mesh からトラフィックを受け取るための OpenShift Serverless の Ingress ゲートウェイを作成します。この設定では、次の詳細を確認してください。

      • ここに示す設定では、OpenShift クラスターへの受信トラフィックを保護するための自己署名証明書を生成し、その証明書を secretName フィールドで指定された knative-serving-cert シークレットに保存します。独自の 証明書を提供するには、secretName フィールドの値を更新してシークレット名を指定し、type フィールドの値を Provided に変更します。

        注記

        独自の証明書を提供する場合、その証明書には、OpenShift クラスターの Ingress コントローラーによって使用されるドメイン名が指定されている必要があります。この値は、次のコマンドを実行して確認できます。

        $ oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}'

      • kserve コンポーネント と serving コンポーネントの両方について、managementState フィールドの値を Managed に設定する必要があります。kserve.managementStateManaged に設定すると、KServe の自動インストールがトリガーされます。serving.managementStateManaged に設定すると、OpenShift Serverless の自動インストールがトリガーされます。ただし、kserve.managementStateManaged に設定されていない場合、OpenShift Serverless のインストールはトリガー されません

検証

  • 次のように OpenShift Service Mesh のインストールを確認します。

    • Web コンソールで、WorkloadsPods をクリックします。
    • プロジェクトリストから istio-system を選択します。これは、OpenShift Service Mesh がインストールされるプロジェクトです。
    • サービスメッシュコントロールプレーン、Ingress ゲートウェイ、および Egress ゲートウェイの実行中の Pod があることを確認します。これらの Pod には、次の例に示す命名パターンがあります。

      NAME                                      		  READY     STATUS    RESTARTS   AGE
      istio-egressgateway-7c46668687-fzsqj      	 	  1/1       Running   0          22h
      istio-ingressgateway-77f94d8f85-fhsp9      		  1/1       Running   0          22h
      istiod-data-science-smcp-cc8cfd9b8-2rkg4  		  1/1       Running   0          22h
  • 次のように OpenShift Serverless のインストールを確認します。

    • Web コンソールで、WorkloadsPods をクリックします。
    • プロジェクトリストから、knative-serving を選択します。これは、OpenShift Serverless がインストールされるプロジェクトです。
    • knative-serving プロジェクト内に、アクティベーター、オートスケーラー、コントローラー、ドメインマッピング Pod、および Knative Istio コントローラー (OpenShift Serverless と OpenShift Service Mesh の統合を制御する) の Pod を含む多数の実行中の Pod があることを確認します。一例を示します。

      NAME                                     	READY     STATUS    RESTARTS  AGE
      activator-7586f6f744-nvdlb               	2/2       Running   0         22h
      activator-7586f6f744-sd77w               	2/2       Running   0         22h
      autoscaler-764fdf5d45-p2v98             	2/2       Running   0         22h
      autoscaler-764fdf5d45-x7dc6              	2/2       Running   0         22h
      autoscaler-hpa-7c7c4cd96d-2lkzg          	1/1       Running   0         22h
      autoscaler-hpa-7c7c4cd96d-gks9j         	1/1       Running   0         22h
      controller-5fdfc9567c-6cj9d              	1/1       Running   0         22h
      controller-5fdfc9567c-bf5x7              	1/1       Running   0         22h
      domain-mapping-56ccd85968-2hjvp          	1/1       Running   0         22h
      domain-mapping-56ccd85968-lg6mw          	1/1       Running   0         22h
      domainmapping-webhook-769b88695c-gp2hk   	1/1       Running   0         22h
      domainmapping-webhook-769b88695c-npn8g   	1/1       Running   0         22h
      net-istio-controller-7dfc6f668c-jb4xk    	1/1       Running   0         22h
      net-istio-controller-7dfc6f668c-jxs5p    	1/1       Running   0         22h
      net-istio-webhook-66d8f75d6f-bgd5r       	1/1       Running   0         22h
      net-istio-webhook-66d8f75d6f-hld75      	1/1       Running   0         22h
      webhook-7d49878bc4-8xjbr                 	1/1       Running   0         22h
      webhook-7d49878bc4-s4xx4                 	1/1       Running   0         22h
  • 次のように KServe のインストールを確認します。

    • Web コンソールで、WorkloadsPods をクリックします。
    • プロジェクトリストから、redhat-ods-applications を選択します。これは、KServe を含む OpenShift AI コンポーネントがインストールされるプロジェクトです。
    • 次の例のように、プロジェクトに KServe コントローラーマネージャーの実行中の Pod が含まれていることを確認します。

      NAME                                          READY   STATUS    RESTARTS   AGE
      kserve-controller-manager-7fbb7bccd4-t4c5g    1/1     Running   0          22h
      odh-model-controller-6c4759cc9b-cftmk         1/1     Running   0          129m
      odh-model-controller-6c4759cc9b-ngj8b         1/1     Running   0          129m
      odh-model-controller-6c4759cc9b-vnhq5         1/1     Running   0          129m

3.3. KServe を手動でインストールする

すでに Red Hat OpenShift Service Mesh Operator をインストールして ServiceMeshControlPlane リソースを作成している場合、または、Red Hat OpenShift Serverless Operator をインストールして KNativeServing リソースを作成している場合は、Red Hat OpenShift AI Operator は KServe とその依存関係をインストールできません。この状況では、KServe を手動でインストールする必要があります。

重要

このセクションの手順は、KServe とその依存関係の 新規 インストールを実行する方法を示しており、完全なインストールと設定のリファレンスとして意図されています。すでに OpenShift Service Mesh または OpenShift Serverless をインストールして設定している場合は、すべての手順に従う必要はない場合があります。KServe を使用するために既存の設定にどの更新を適用すればよいかわからない場合は、Red Hat サポートにお問い合わせください。

3.3.1. KServe 依存関係のインストール

KServe をインストールする前に、いくつかの依存関係をインストールして設定する必要があります。具体的には、Red Hat OpenShift Service Mesh および Knative Serving インスタンスを作成し、Knative Serving 用にセキュアゲートウェイを設定する必要があります。

3.3.1.1. OpenShift Service Mesh インスタンスの作成

次の手順は、Red Hat OpenShift Service Mesh インスタンスを作成する方法を示しています。

前提条件

  • OpenShift クラスターのクラスター管理者権限を持っている。
  • クラスターには 4 つの CPU と 16 GB のメモリーを備えたノードがある。
  • OpenShift コマンドラインインターフェイス (CLI) をダウンロードしてインストールしている。OpenShift CLI のインストール (Red Hat OpenShift Dedicated) または OpenShift CLI のインストール (Red Hat OpenShift Service on AWS) を参照してください。
  • Red Hat OpenShift Service Mesh Operator と依存する Operator が インストール されています。

手順

  1. ターミナルウィンドウで、クラスター管理者として OpenShift クラスターにまだログインしていない場合は、次の例に示すように OpenShift CLI にログインします。

    $ oc login <openshift_cluster_url> -u <admin_username> -p <password>
  2. Red Hat OpenShift Service Mesh に必要な namespace を作成します。

    $ oc create ns istio-system

    以下のような出力が表示されます。

    namespace/istio-system created
  3. smcp.yaml という名前の YAML ファイルに次の内容の ServiceMeshControlPlane オブジェクトを定義します。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: minimal
      namespace: istio-system
    spec:
      tracing:
        type: None
      addons:
        grafana:
          enabled: false
        kiali:
          name: kiali
          enabled: false
        prometheus:
          enabled: false
        jaeger:
          name: jaeger
      security:
        dataPlane:
          mtls: true
        identity:
          type: ThirdParty
      techPreview:
        meshConfig:
          defaultConfig:
            terminationDrainDuration: 35s
      gateways:
        ingress:
          service:
            metadata:
              labels:
                knative: ingressgateway
      proxy:
        networking:
          trafficControl:
            inbound:
              excludedPorts:
                - 8444
                - 8022

    YAML ファイルの値の詳細は、Service Mesh コントロールプレーン設定リファレンス を参照してください。

  4. サービスメッシュコントロールプレーンを作成します。

    $ oc apply -f smcp.yaml

検証

  • 次のようにサービスメッシュインスタンスの作成を確認します。

    • OpenShift CLI で、次のコマンドを入力します。

      $ oc get pods -n istio-system

      前述のコマンドは、istio-system プロジェクト内で実行中の Pod 一覧を表示します。これは、OpenShift Service Mesh がインストールされるプロジェクトです。

    • サービスメッシュコントロールプレーン、Ingress ゲートウェイ、および Egress ゲートウェイの実行中の Pod があることを確認します。これらの Pod には次の命名パターンがあります。

      NAME                                          READY   STATUS   	  RESTARTS    AGE
      istio-egressgateway-7c46668687-fzsqj          1/1     Running     0           22h
      istio-ingressgateway-77f94d8f85-fhsp9         1/1     Running     0           22h
      istiod-data-science-smcp-cc8cfd9b8-2rkg4      1/1     Running     0           22h

3.3.1.2. Knative Serving インスタンスの作成

次の手順は、Knative Serving をインストールしてインスタンスを作成する方法を示しています。

前提条件

  • OpenShift クラスターのクラスター管理者権限を持っている。
  • クラスターには 4 つの CPU と 16 GB のメモリーを備えたノードがある。
  • OpenShift コマンドラインインターフェイス (CLI) をダウンロードしてインストールしている。OpenShift CLI のインストール (Red Hat OpenShift Dedicated) または OpenShift CLI のインストール (Red Hat OpenShift Service on AWS) を参照してください。
  • Red Hat OpenShift Service Mesh インスタンスが 作成 されている。
  • Red Hat OpenShift Serverless Operator が インストールされている

手順

  1. ターミナルウィンドウで、クラスター管理者として OpenShift クラスターにまだログインしていない場合は、次の例に示すように OpenShift CLI にログインします。

    $ oc login <openshift_cluster_url> -u <admin_username> -p <password>
  2. Knative Serving に必要なプロジェクト (つまり namespace) がすでに存在するかどうかを確認します。

    $ oc get ns knative-serving

    プロジェクトが存在する場合は、次の例のような出力が表示されます。

    NAME              STATUS   AGE
    knative-serving   Active   4d20h
  3. knative-serving プロジェクトがまだ存在 しない 場合は、作成します。

    $ oc create ns knative-serving

    以下のような出力が表示されます。

    namespace/knative-serving created
  4. 以下の内容で、default-smm.yaml という YAML ファイルに ServiceMeshMember オブジェクトを定義します。

    apiVersion: maistra.io/v1
    kind: ServiceMeshMember
    metadata:
      name: default
      namespace: knative-serving
    spec:
      controlPlaneRef:
        namespace: istio-system
        name: minimal
  5. istio-system namespace に ServiceMeshMember オブジェクトを作成します。

    $ oc apply -f default-smm.yaml

    以下のような出力が表示されます。

    servicemeshmember.maistra.io/default created
  6. knativeserving-istio.yaml という YAML ファイルに次の内容の KnativeServing オブジェクトを定義します。

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
      annotations:
        serverless.openshift.io/default-enable-http2: "true"
    spec:
      workloads:
        - name: net-istio-controller
          env:
            - container: controller
              envVars:
                - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
                  value: 'true'
        - annotations:
            sidecar.istio.io/inject: "true" 1
            sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
          name: activator
        - annotations:
            sidecar.istio.io/inject: "true"
            sidecar.istio.io/rewriteAppHTTPProbers: "true"
          name: autoscaler
      ingress:
        istio:
          enabled: true
      config:
        features:
          kubernetes.podspec-affinity: enabled
          kubernetes.podspec-nodeselector: enabled
          kubernetes.podspec-tolerations: enabled

    前述のファイルは、KnativeServing オブジェクトのカスタムリソース (CR) を定義します。CR は、アクティベーター Pod とオートスケーラー Pod のそれぞれに次のアクションも追加します。

    1
    Istio サイドカーを Pod に注入します。これにより、Pod がサービスメッシュの一部になります。
    2
    Istio サイドカーが Pod の HTTP liveness プローブと readiness プローブを書き換えられるようにします。
    注記

    Knative サービスのカスタムドメインを設定する場合、TLS 証明書を使用してマップされたサービスを保護できます。これを行うには、TLS シークレットを作成してから、作成した TLS シークレットを使用するように DomainMapping CR を更新する必要があります。詳細は、Red Hat OpenShift Serverless ドキュメントの Securing a mapped service using a TLS certificate を参照してください。

  7. 指定された knative-serving namespace に KnativeServing オブジェクトを作成します。

    $ oc apply -f knativeserving-istio.yaml

    以下のような出力が表示されます。

    knativeserving.operator.knative.dev/knative-serving created

検証

  • istio-system namespace のデフォルトの ServiceMeshMemberRoll オブジェクトを確認します。

    $ oc describe smmr default -n istio-system

    ServiceMeshMemberRoll オブジェクトの説明で、Status.Members フィールドを見つけて、それに knative-serving namespace が含まれていることを確認します。

  • 次のように、Knative Serving インスタンスの作成を確認します。

    • OpenShift CLI で、次のコマンドを入力します。

      $ oc get pods -n knative-serving

      前述のコマンドは、knative-serving プロジェクト内で実行中の Pod 一覧を表示します。これは、Knative Serving インスタンスを作成したプロジェクトです。

    • knative-serving プロジェクト内に、アクティベーター、オートスケーラー、コントローラー、ドメインマッピング Pod、および OpenShift Serverless と OpenShift Service Mesh の統合を制御する Knative Istio コントローラーの Pod を含む多数の実行中の Pod があることを確認します。一例を示します。

      NAME                                     	READY       STATUS    	RESTARTS   	AGE
      activator-7586f6f744-nvdlb               	2/2         Running   	0          	22h
      activator-7586f6f744-sd77w               	2/2         Running   	0          	22h
      autoscaler-764fdf5d45-p2v98             	2/2         Running   	0          	22h
      autoscaler-764fdf5d45-x7dc6              	2/2         Running   	0          	22h
      autoscaler-hpa-7c7c4cd96d-2lkzg          	1/1         Running   	0          	22h
      autoscaler-hpa-7c7c4cd96d-gks9j         	1/1         Running   	0          	22h
      controller-5fdfc9567c-6cj9d              	1/1         Running   	0          	22h
      controller-5fdfc9567c-bf5x7              	1/1         Running   	0          	22h
      domain-mapping-56ccd85968-2hjvp          	1/1         Running   	0          	22h
      domain-mapping-56ccd85968-lg6mw          	1/1         Running   	0          	22h
      domainmapping-webhook-769b88695c-gp2hk   	1/1         Running     0          	22h
      domainmapping-webhook-769b88695c-npn8g   	1/1         Running   	0          	22h
      net-istio-controller-7dfc6f668c-jb4xk    	1/1         Running   	0          	22h
      net-istio-controller-7dfc6f668c-jxs5p    	1/1         Running   	0          	22h
      net-istio-webhook-66d8f75d6f-bgd5r       	1/1         Running   	0          	22h
      net-istio-webhook-66d8f75d6f-hld75      	1/1         Running   	0          	22h
      webhook-7d49878bc4-8xjbr                 	1/1         Running   	0          	22h
      webhook-7d49878bc4-s4xx4                 	1/1         Running   	0          	22h

3.3.1.3. Knative Serving 用の安全なゲートウェイの作成

Knative Serving インスタンスとサービスメッシュ間のトラフィックを保護するには、Knative Serving インスタンス用のセキュアゲートウェイを作成する必要があります。

次の手順では、OpenSSL を使用してワイルドカード証明書とキーを生成し、それらを使用して Knative Serving のローカルゲートウェイと Ingress ゲートウェイを作成する方法を示します。

重要

ゲートウェイの設定時に指定する独自のワイルドカード証明書とキーがある場合は、この手順のステップ 11 に進んでください。

前提条件

  • OpenShift クラスターのクラスター管理者権限を持っている。
  • OpenShift コマンドラインインターフェイス (CLI) をダウンロードしてインストールしている。OpenShift CLI のインストール (Red Hat OpenShift Dedicated) または OpenShift CLI のインストール (Red Hat OpenShift Service on AWS) を参照してください。
  • Red Hat OpenShift Service Mesh インスタンスが 作成 されている。
  • Knative Serving インスタンスが 作成 されている。
  • ワイルドカード証明書とキーを生成する場合は、OpenSSL を ダウンロードしてインストール している。

手順

  1. ターミナルウィンドウで、クラスター管理者として OpenShift クラスターにまだログインしていない場合は、次の例に示すように OpenShift CLI にログインします。

    $ oc login <openshift_cluster_url> -u <admin_username> -p <password>
    重要

    ゲートウェイの設定時に指定する独自のワイルドカード証明書とキーがある場合は、この手順のステップ 11 に進みます。

  2. 環境変数を設定して、ゲートウェイのワイルドカード証明書とキーを生成するためのベースディレクトリーを定義します。

    $ export BASE_DIR=/tmp/kserve
    $ export BASE_CERT_DIR=${BASE_DIR}/certs
  3. 環境変数を設定して、OpenShift クラスターの Ingress コントローラーで使用される共通名を定義します。

    $ export COMMON_NAME=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}' | awk -F'.' '{print $(NF-1)"."$NF}')
  4. 環境変数を設定して、OpenShift クラスターの Ingress コントローラーによって使用されるドメイン名を定義します。

    $ export DOMAIN_NAME=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}')
  5. 以前に設定した環境変数に基づいて、証明書の生成に必要なベースディレクトリーを作成します。

    $ mkdir ${BASE_DIR}
    $ mkdir ${BASE_CERT_DIR}
  6. ワイルドカード証明書を生成するための OpenSSL 設定を作成します。

    $ cat <<EOF> ${BASE_DIR}/openssl-san.config
    [ req ]
    distinguished_name = req
    [ san ]
    subjectAltName = DNS:*.${DOMAIN_NAME}
    EOF
  7. ルート証明書を生成します。

    $ openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 \
    -subj "/O=Example Inc./CN=${COMMON_NAME}" \
    -keyout $BASE_DIR/root.key \
    -out $BASE_DIR/root.crt
  8. ルート証明書によって署名されたワイルドカード証明書を生成します。

    $ openssl req -x509 -newkey rsa:2048 \
    -sha256 -days 3560 -nodes \
    -subj "/CN=${COMMON_NAME}/O=Example Inc." \
    -extensions san -config ${BASE_DIR}/openssl-san.config \
    -CA $BASE_DIR/root.crt \
    -CAkey $BASE_DIR/root.key \
    -keyout $BASE_DIR/wildcard.key  \
    -out $BASE_DIR/wildcard.crt
    
    $ openssl x509 -in ${BASE_DIR}/wildcard.crt -text
  9. ワイルドカード証明書を確認します。

    $ openssl verify -CAfile ${BASE_DIR}/root.crt ${BASE_DIR}/wildcard.crt
  10. スクリプトによって作成されたワイルドカードキーと証明書を新しい環境変数にエクスポートします。

    $ export TARGET_CUSTOM_CERT=${BASE_CERT_DIR}/wildcard.crt
    $ export TARGET_CUSTOM_KEY=${BASE_CERT_DIR}/wildcard.key
  11. オプション: 独自の ワイルドカードキーと証明書を新しい環境変数にエクスポートするには、次のコマンドを入力します。

    $ export TARGET_CUSTOM_CERT=<path_to_certificate>
    $ export TARGET_CUSTOM_KEY=<path_to_key>
    注記

    提供する証明書では、OpenShift クラスターの Ingress コントローラーで使用されるドメイン名を指定する必要があります。この値は、次のコマンドを実行して確認できます。

    $ oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}'

  12. ワイルドカード証明書とキーに設定した環境変数を使用して、istio-system namespace に TLS シークレットを作成します。

    $ oc create secret tls wildcard-certs --cert=${TARGET_CUSTOM_CERT} --key=${TARGET_CUSTOM_KEY} -n istio-system
  13. 次の内容を含む gateways.yaml YAML ファイルを作成します。

    apiVersion: v1
    kind: Service 1
    metadata:
      labels:
        experimental.istio.io/disable-gateway-port-translation: "true"
      name: knative-local-gateway
      namespace: istio-system
    spec:
      ports:
        - name: http2
          port: 80
          protocol: TCP
          targetPort: 8081
      selector:
        knative: ingressgateway
      type: ClusterIP
    ---
    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: knative-ingress-gateway 2
      namespace: knative-serving
    spec:
      selector:
        knative: ingressgateway
      servers:
        - hosts:
            - '*'
          port:
            name: https
            number: 443
            protocol: HTTPS
          tls:
            credentialName: wildcard-certs
            mode: SIMPLE
    ---
    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
     name: knative-local-gateway 3
     namespace: knative-serving
    spec:
     selector:
       knative: ingressgateway
     servers:
       - port:
           number: 8081
           name: https
           protocol: HTTPS
         tls:
           mode: ISTIO_MUTUAL
         hosts:
           - "*"
    1
    Knative ローカルゲートウェイの istio-system namespace にサービスを定義します。
    2
    knative-serving namespace で Ingress ゲートウェイを定義します。ゲートウェイは、この手順の前半で作成した TLS シークレットを使用します。Ingress ゲートウェイは、Knative への外部トラフィックを処理します。
    3
    knative-serving namespace で Knative のローカルゲートウェイを定義します。
  14. gateways.yaml ファイルを適用して、定義されたリソースを作成します。

    $ oc apply -f gateways.yaml

    以下のような出力が表示されます。

    service/knative-local-gateway created
    gateway.networking.istio.io/knative-ingress-gateway created
    gateway.networking.istio.io/knative-local-gateway created

検証

  • 作成したゲートウェイを確認します。

    $ oc get gateway --all-namespaces

    次の例に示すように、knative-serving namespace で作成したローカルゲートウェイと Ingress ゲートウェイが表示されていることを確認します。

    NAMESPACE         	NAME                      	AGE
    knative-serving   	knative-ingress-gateway   	69s
    knative-serving     knative-local-gateway     	2m

3.3.2. KServe のインストール

KServe の手動インストールを完了するには、Red Hat OpenShift AI Operator をインストールする Red Hat OpenShift Data Science アドオンをインストールする必要があります。その後、Operator を使用して KServe をインストールできます。

前提条件

  • OpenShift クラスターのクラスター管理者権限を持っている。
  • クラスターには 4 つの CPU と 16 GB のメモリーを備えたノードがある。
  • OpenShift コマンドラインインターフェイス (CLI) をダウンロードしてインストールしている。OpenShift CLI のインストール (Red Hat OpenShift Dedicated) または OpenShift CLI のインストール (Red Hat OpenShift Service on AWS) を参照してください。
  • Red Hat OpenShift Service Mesh インスタンスが 作成 されている。
  • Knative Serving インスタンスが 作成 されている。
  • Knative Serving 用の セキュアなゲートウェイが作成 されている。
  • Red Hat OpenShift AI アドオンが OpenShift クラスターにインストールされている。これにより、Red Hat OpenShift AI Operator がインストールされ、デフォルトの DataScienceCluster オブジェクトが作成されます。

手順

  1. OpenShift Web コンソールにクラスター管理者としてログインします。
  2. Web コンソールで、OperatorsInstalled Operators をクリックし、Red Hat OpenShift AI Operator をクリックします。
  3. KServe をインストールするには、OpenShift Service Mesh コンポーネントを次のように設定します。

    1. DSC Initialization タブをクリックします。
    2. default-dsci オブジェクトをクリックします。
    3. YAML タブをクリックします。
    4. spec セクションで、次のように serviceMesh コンポーネントを追加して設定します。

      spec:
       serviceMesh:
         managementState: Unmanaged
    5. Save をクリックします。
  4. KServe をインストールするには、KServe および OpenShift Serverless コンポーネントを次のように設定します。

    1. Web コンソールで、OperatorsInstalled Operators をクリックし、Red Hat OpenShift AI Operator をクリックします。
    2. Data Science Cluster タブをクリックします。
    3. default-dsc DSC オブジェクトをクリックします。
    4. YAML タブをクリックします。
    5. spec.components セクションで、次のように kserve コンポーネントを設定します。

      spec:
       components:
         kserve:
           managementState: Managed
    6. kserve コンポーネント内で、serving コンポーネントを追加し、次のように設定します。

      spec:
       components:
         kserve:
           managementState: Managed
           serving:
             managementState: Unmanaged
    7. Save をクリックします。

3.3.3. 承認プロバイダーの手動による追加

Authorino をシングルモデル提供プラットフォームの承認プロバイダーとして追加できます。認可プロバイダーを追加すると、プラットフォームにデプロイするモデルのトークン承認を有効にすることができます。これにより、承認された当事者のみがモデルへの推論リクエストを送信できるようになります。

Authorino を認可プロバイダーとして手動で追加するには、Red Hat - Authorino Operator をインストールし、Authorino インスタンスを作成してから、インスタンスを使用するように OpenShift Service Mesh および KServe コンポーネントを設定する必要があります。

重要

認可プロバイダーを手動で追加するには、OpenShift Service Mesh インスタンスに設定更新を行う必要があります。OpenShift Service Mesh インスタンスがサポート対象の状態のままになるようにするには、本セクションで説明する更新 のみ を行ってください。

前提条件

  • Authorino を認可プロバイダーとして追加するオプションを確認し、適切なオプションとして手動インストールを特定している。認可プロバイダーの追加 を 参照してください。
  • KServe とその依存関係(OpenShift Service Mesh を含む)を手動でインストールしました。KServe を手動でインストールする
  • KServe を手動でインストールした場合は、serviceMesh コンポーネントの managementState フィールドの値を Unmanaged に設定します。この設定は、Authorino を手動で追加するために必要です。KServe のインストール を参照してください。

3.3.3.1. Red Hat Authorino Operator のインストール

Autorino を認証プロバイダーとして追加する前に、Red Hat - Authorino Operator を OpenShift クラスターにインストールする必要があります。

前提条件

  • OpenShift クラスターのクラスター管理者権限を持っている。

手順

  1. OpenShift Web コンソールにクラスター管理者としてログインします。
  2. Web コンソールで OperatorsOperatorHub をクリックします。
  3. OperatorHub ページの Filter by keyword フィールドに Red Hat - Authorino と入力します。
  4. Red Hat - Authorino Operator をクリックします。
  5. Red Hat - Authorino Operator ページで Operator 情報を確認し、Install をクリックします。
  6. Install Operator ページで、Update channelVersionInstallation modeInstalled Namespace、および Update Approval のデフォルト値を保持します。
  7. Install をクリックします。

検証

  • OpenShift Web コンソールで、OperatorsInstalled Operators をクリックし、Red Hat - Authorino Operator が以下のいずれかのステータスを示していることを確認します。

    • Installing - インストールが進行中です。Succeeded が表示されるまで待機してください。これは数分の時間がかかる可能性があります。
    • Succeeded - インストールに成功しました。

3.3.3.2. Authorino インスタンスの作成

Red Hat - Authorino Operator を OpenShift クラスターにインストールしたら、Authorino インスタンスを作成する必要があります。

前提条件

手順

  1. 新しいターミナルウィンドウを開きます。
  2. 以下のように OpenShift コマンドラインインターフェイス(CLI)にログインします。

    $ oc login <openshift_cluster_url> -u <username> -p <password>
  3. Authorino インスタンスをインストールするための namespace を作成します。

    $ oc new-project <namespace_for_authorino_instance>
    注記

    自動インストールプロセスにより、Authorino インスタンスの redhat-ods-applications-auth-provider という namespace が作成されます。手動インストールに同じ名前空間名を使用することを検討してください。

  4. Authorino インスタンスの新規 namespace を既存の OpenShift Service Mesh インスタンスに登録するには、次の内容で新しい YAML ファイルを作成します。

      apiVersion: maistra.io/v1
      kind: ServiceMeshMember
      metadata:
        name: default
        namespace: <namespace_for_authorino_instance>
      spec:
        controlPlaneRef:
          namespace: <namespace_for_service_mesh_instance>
          name: <name_of_service_mesh_instance>
  5. YAML ファイルを保存します。
  6. クラスターに ServiceMeshMember リソースを作成します。

    $ oc create -f <file_name>.yaml
  7. Authorino インスタンスを設定するには、次の例に示すように新しい YAML ファイルを作成します。

      apiVersion: operator.authorino.kuadrant.io/v1beta1
      kind: Authorino
      metadata:
        name: authorino
        namespace: <namespace_for_authorino_instance>
      spec:
        authConfigLabelSelectors: security.opendatahub.io/authorization-group=default
        clusterWide: true
        listener:
          tls:
            enabled: false
        oidcServer:
          tls:
            enabled: false
  8. YAML ファイルを保存します。
  9. クラスターに Authorino リソースを作成します。

    $ oc create -f <file_name>.yaml
  10. Authorino デプロイメントにパッチを適用して、Istio サイドカーを挿入します。これにより、OpenShift Service Mesh インスタンスの Authorino インスタンスの一部になります。

    $ oc patch deployment <name_of_authorino_instance> -n <namespace_for_authorino_instance> -p '{"spec": {"template":{"metadata":{"labels":{"sidecar.istio.io/inject":"true"}}}} }'

検証

  • Authorino インスタンスが次のように実行されていることを確認します。

    1. 次の例に示すように、Authorino インスタンス用に作成した namespace で実行されている Pod (およびコンテナー)を確認します。

      $ oc get pods -n redhat-ods-applications-auth-provider -o="custom-columns=NAME:.metadata.name,STATUS:.status.phase,CONTAINERS:.spec.containers[*].name"
    2. 出力が次の例のようになっていることを確認します。

      NAME                         STATUS    CONTAINERS
      authorino-6bc64bd667-kn28z   Running   authorino,istio-proxy

      例に示されているように、Authorino インスタンスの 1 つの実行中の Pod があります。Pod には Authorino のコンテナーと挿入した Istio サイドカーのコンテナーがあります。

3.3.3.3. Authorino を使用するための OpenShift Service Mesh インスタンスの設定

Authorino インスタンスを作成したら、OpenShift Service Mesh インスタンスが Authorino を認可プロバイダーとして使用するように設定する必要があります。

重要

OpenShift Service Mesh インスタンスがサポート対象の状態のままになるようにするには、以下の手順で説明されている設定更新 のみ を行います。

前提条件

  • Authorino インスタンスを作成し、OpenShift Service Mesh インスタンスに Authorino インスタンスの namespace を登録している。
  • OpenShift Service Mesh インスタンスを変更する権限があります。OpenShift Service Mesh インスタンスの作成

手順

  1. ターミナルウィンドウで、OpenShift Service Mesh インスタンスを更新する権限を持つユーザーとして OpenShift クラスターにログインしていない場合は、以下の例のように OpenShift CLI にログインします。

    $ oc login <openshift_cluster_url> -u <username> -p <password>
  2. 以下の内容を含む新規 YAML ファイルを作成します。

    spec:
     techPreview:
       meshConfig:
         extensionProviders:
         - name: redhat-ods-applications-auth-provider
           envoyExtAuthzGrpc:
             service: <name_of_authorino_instance>-authorino-authorization.<namespace_for_authorino_instance>.svc.cluster.local
             port: 50051
  3. YAML ファイルを保存します。
  4. oc patch コマンドを使用して、YAML ファイルを OpenShift Service Mesh インスタンスに適用します。

    $ oc patch smcp <name_of_service_mesh_instance> --type merge -n <namespace_for_service_mesh_instance> --patch-file <file_name>.yaml
    重要

    パッチとして表示される設定は、OpenShift Service Mesh インスタンスに他の拡張プロバイダーを指定していない場合に のみ 適用できます。他の拡張プロバイダーがすでに指定されている場合には、ServiceMeshControlPlane リソースを手動で編集して設定を追加する必要があります。

検証

  • 以下のように、Authorino インスタンスが OpenShift Service Mesh 設定の拡張機能プロバイダーとして追加されていることを確認します。

    1. OpenShift Service Mesh インスタンスの ConfigMap オブジェクトを検査します。

      $ oc get configmap istio-<name_of_service_mesh_instance> -n <namespace_for_service_mesh_instance> --output=jsonpath={.data.mesh}
    2. Authorino インスタンスが拡張プロバイダーとして正常に追加されたことを示しています。次の例のような出力が表示されていることを確認します。

      defaultConfig:
        discoveryAddress: istiod-data-science-smcp.istio-system.svc:15012
        proxyMetadata:
          ISTIO_META_DNS_AUTO_ALLOCATE: "true"
          ISTIO_META_DNS_CAPTURE: "true"
          PROXY_XDS_VIA_AGENT: "true"
        terminationDrainDuration: 35s
        tracing: {}
      dnsRefreshRate: 300s
      enablePrometheusMerge: true
      extensionProviders:
      - envoyExtAuthzGrpc:
          port: 50051
          service: authorino-authorino-authorization.opendatahub-auth-provider.svc.cluster.local
        name: opendatahub-auth-provider
      ingressControllerMode: "OFF"
      rootNamespace: istio-system
      trustDomain: null%

3.3.3.4. KServe の承認の設定

Authorino を使用するようにシングルモデル提供プラットフォームを設定するには、モデルをデプロイする際に作成される KServe の予測者 Pod に適用されるグローバル AuthorizationPolicy リソースを作成する必要があります。さらに、モデルへの推論要求を行うときに発生する複数のネットワークホップに対応するには、HTTP ホストヘッダーを推論要求に最初に含まれるものに継続的にリセットする EnvoyFilter リソースを作成する必要があります。

前提条件

  • Authorino インスタンスを作成し、これを使用できるように OpenShift Service Mesh を設定しました。
  • クラスターでの KServe デプロイメントを更新する権限がある。
  • OpenShift Service Mesh インスタンスが作成されたプロジェクトにリソースを追加する権限があります。OpenShift Service Mesh インスタンスの作成

手順

  1. ターミナルウィンドウで、KServe デプロイメントを更新する権限を持つユーザーとして OpenShift クラスターにログインしていない場合は、以下の例のように OpenShift CLI にログインします。

    $ oc login <openshift_cluster_url> -u <username> -p <password>
  2. 以下の内容を含む新規 YAML ファイルを作成します。

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: kserve-predictor
    spec:
      action: CUSTOM
      provider:
         name: redhat-ods-applications-auth-provider 1
      rules:
         - to:
              - operation:
                   notPaths:
                      - /healthz
                      - /debug/pprof/
                      - /metrics
                      - /wait-for-drain
      selector:
         matchLabels:
            component: predictor
    1
    指定する名前は、OpenShift Service Mesh インスタンスに追加した拡張プロバイダーの名前と一致する必要があります。
  3. YAML ファイルを保存します。
  4. OpenShift Service Mesh インスタンスの namespace に AuthorizationPolicy リソースを作成します。

    $ oc create -n <namespace_for_service_mesh_instance> -f <file_name>.yaml
  5. 以下の内容で別の新規 YAML ファイルを作成します。

    apiVersion: networking.istio.io/v1alpha3
    kind: EnvoyFilter
    metadata:
      name: activator-host-header
    spec:
      priority: 20
      workloadSelector:
        labels:
          component: predictor
      configPatches:
      - applyTo: HTTP_FILTER
        match:
          listener:
            filterChain:
              filter:
                name: envoy.filters.network.http_connection_manager
        patch:
          operation: INSERT_BEFORE
          value:
            name: envoy.filters.http.lua
            typed_config:
              '@type': type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
              inlineCode: |
               function envoy_on_request(request_handle)
                  local headers = request_handle:headers()
                  if not headers then
                    return
                  end
                  local original_host = headers:get("k-original-host")
                  if original_host then
                    port_seperator = string.find(original_host, ":", 7)
                    if port_seperator then
                      original_host = string.sub(original_host, 0, port_seperator-1)
                    end
                    headers:replace('host', original_host)
                  end
                end

    EnvoyFilter リソースは、HTTP ホストヘッダーを、推論要求の最初のものへ継続的にリセットします。

  6. OpenShift Service Mesh インスタンスの namespace に EnvoyFilter リソースを作成します。

    $ oc create -n <namespace_for_service_mesh_instance> -f <file_name>.yaml

検証

  • AuthorizationPolicy リソースが正常に作成されたことを確認します。

    $ oc get authorizationpolicies -n <namespace_for_service_mesh_instance>

    次の例のような出力が表示されることを確認します。

    NAME               AGE
    kserve-predictor   28h
  • EnvoyFilter リソースが正常に作成されたことを確認します。

    $ oc get envoyfilter -n <namespace_for_service_mesh_instance>

    次の例のような出力が表示されることを確認します。

    NAME                                          AGE
    activator-host-header                         28h

3.4. プラットフォームを提供するシングルモデル用の認可プロバイダーの追加

Authorino をシングルモデル提供プラットフォームの承認プロバイダーとして追加できます。認可プロバイダーを追加すると、プラットフォームにデプロイするモデルのトークン承認を有効にすることができます。これにより、承認された当事者のみがモデルへの推論リクエストを送信できるようになります。

Authorino を認可プロバイダーとして追加するために使用する方法は、シングルモデル提供プラットフォームをインストールする方法によって異なります。プラットフォームのインストールオプションは次のように記述されます。

自動インストール

OpenShift クラスターに ServiceMeshControlPlane または KNativeServing リソースをまだ作成していない場合は、KServe とその依存関係をインストールするように Red Hat OpenShift AI Operator を設定できます。自動インストールプロセスの一部として Authorino を含めることができます。

Authorino などの自動インストールの詳細は KServe の自動インストールの設定 を参照してください。

手動インストール

OpenShift クラスターに ServiceMeshControlPlane または KNativeServing リソースをすでに作成している場合は、KServe とその依存関係をインストールするように Red Hat OpenShift AI Operator を 設定できません。この状況では、KServe を手動でインストールする必要があります。Authorino も手動で設定する必要があります。

Authorino などの手動インストールの詳細は、手動で KServe をインストールする を 参照してください。

3.5. シングルモデルサービスプラットフォームを使用したモデルのデプロイ

シングルモデルサービスプラットフォームでは、各モデルが独自のモデルサーバー上でデプロイされます。これにより、リソースの増加を必要とする大規模なモデルのデプロイ、監視、スケーリング、保守が容易になります。

重要

単一モデルサービスプラットフォームを使用して、自己署名 SSL 証明書を使用する S3 互換ストレージからモデルをデプロイする場合は、OpenShift Container Platform クラスターに認証局 (CA) バンドルをインストールする必要があります。詳細は、証明書の使用 を参照してください。

3.5.1. シングルモデルサービスプラットフォームの有効化

KServe をインストールすると、Red Hat OpenShift AI ダッシュボードを使用して、シングルモデルサービスプラットフォームを有効にすることができます。ダッシュボードを使用して、プラットフォームのモデルサービスランタイムを有効にすることもできます。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift の管理者グループ (rhoai-admins など) の一員となります。
  • KServe をインストールしている。
  • クラスター管理者は OpenShift AI ダッシュボード設定を編集しておら 、KServe コンポーネントを使用するシングルモデル提供プラットフォームを選択する機能を無効にしていません。詳細は、ダッシュボード設定オプション を参照してください。

手順

  1. 次のようにシングルモデルサービスプラットフォームを有効にします。

    1. 左側のメニューで、SettingsCluster settings をクリックします。
    2. モデルサービスプラットフォーム セクションを見つけます。
    3. プロジェクトに対してシングルモデルサービスプラットフォームを有効にするには、Single model serving platform チェックボックスをオンにします。
    4. Save Changes をクリックします。
  2. 次のように、シングルモデルサービスプラットフォーム用のプリインストールされたランタイムを有効にします。

    1. OpenShift AI ダッシュボードの左側のメニューで、SettingsServing runtimes をクリックします。

      Serving runtimes ページには、追加したカスタムランタイムに加えて、次のプリインストールされたランタイムが表示されます。

      • Caikit TGIS ServingRuntime for KServe
      • OpenVINO Model Server
      • TGIS Standalone ServingRuntime for KServe
    2. 使用するランタイムを Enabled に設定します。

      これで、シングルモデルサービスプラットフォームをモデルのデプロイに使用できるようになりました。

3.5.2. シングルモデルサービスプラットフォーム用のカスタムモデルサービスランタイムの追加

モデルサービスランタイムは、指定されたモデルフレームワークのセット (つまり、形式) のサポートを追加します。OpenShift AI に組み込まれている プリインストールされたランタイム を使用するか、独自のカスタムランタイムを追加するかを選択できます。これは、プリインストールされたランタイムがニーズに合わない場合に役立ちます。たとえば、TGIS ランタイムが、Hugging Face Text Generation Inference (TGI) でサポートされている特定のモデル形式をサポートしていないことが判明する場合があります。この場合、カスタムランタイムを作成してモデルのサポートを追加できます。

管理者は、OpenShift AI インターフェイスを使用して、カスタムのモデルサービスランタイムを追加して有効にすることができます。その場合は、シングルモデルサービスプラットフォームにモデルをデプロイする際に、カスタムランタイムを選択できます。

注記

OpenShift AI を使用すると、独自のカスタムランタイムを追加できますが、ランタイム自体はサポートされません。カスタムランタイムを正しく設定して維持することは、お客様の責任となります。また、追加するカスタムランタイムを使用するライセンスの取得について確認することも、お客様の責任となります。

前提条件

  • OpenShift AI に管理者としてログインしている。
  • カスタムランタイムをビルドし、イメージを Quay などのコンテナーイメージリポジトリーに追加している。

手順

  1. OpenShift AI ダッシュボードから、Settings > Serving runtimes をクリックします。

    Serving runtimes ページが開き、すでにインストールされ有効になっているモデルサービスランタイムが表示されます。

  2. カスタムランタイムを追加するには、次のオプションのいずれかを選択します。

    • 既存のランタイム (KServe の TGIS Standalone ServingRuntime など) で開始するには、既存のランタイムの横にあるアクションメニュー (⋮) をクリックしてから、Duplicate をクリックします。
    • 新しいカスタムランタイムを追加するには、Add serving runtime をクリックします。
  3. Select the model serving platforms this runtime supports リストで、Single-model serving platform を選択します。
  4. Select the API protocol this runtime supports リストで、REST または gRPC を選択します。
  5. オプション: (既存のランタイムを複製するのではなく) 新しいランタイムを開始した場合は、次のオプションのいずれかを選択してコードを追加します。

    • YAML ファイルをアップロードする

      1. Upload files をクリックします。
      2. ファイルブラウザーで、コンピューター上の YAML ファイルを選択します。

        埋め込み YAML エディターが開き、アップロードしたファイルの内容が表示されます。

    • エディターに YAML コードを直接入力する

      1. Start from scratch をクリックします。
      2. 埋め込みエディターに YAML コードを直接入力または貼り付けます。
    注記

    多くの場合、カスタムランタイムを作成するには、ServingRuntime 仕様の env セクションに新しいパラメーターまたはカスタムパラメーターを追加する必要があります。

  6. Add をクリックします。

    Serving runtimes ページが開き、インストールされているランタイムの更新されたリストが表示されます。追加したカスタムランタイムが自動的に有効になることを確認します。ランタイム作成時に指定した API プロトコルが表示されます。

  7. オプション: カスタムランタイムを編集するには、アクションメニュー (⋮) をクリックし、Edit を選択します。

検証

  • 追加したカスタムモデルサービスランタイムは、Serving runtimes ページに有効な状態で表示されます。

3.5.3. シングルモデルサービスプラットフォームへのモデルのデプロイ

シングルモデルサービスプラットフォームを有効にすると、カスタムまたはプリインストールされたモデルサービスランタイムを有効にして、プラットフォームへのモデルのデプロイを開始できます。

注記

Text Generation Inference Server (TGIS) は、Hugging Face TGI の初期のフォークに基づいています。Red Hat は、TGI モデルをサポートするスタンドアロン TGIS ランタイムの開発を継続します。モデルが OpenShift AI の現在のバージョンで機能しない場合、今後のバージョンでサポートが追加される可能性があります。それまでの間は、独自のカスタムランタイムを追加して TGI モデルをサポートすることもできます。詳細は、シングルモデルサービスプラットフォーム用のカスタムモデルサービスランタイムの追加 を参照してください。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。
  • KServe をインストールしている。
  • シングルモデルサービスプラットフォームを有効にしている。
  • データサイエンスプロジェクトを作成している。
  • S3 互換オブジェクトストレージにアクセスできる。
  • デプロイするモデルについて、S3 互換オブジェクトストレージバケット内の関連フォルダーパスを把握している。
  • Caikit-TGIS ランタイムを使用するために、モデルを Caikit 形式に変換している。例については、caikit-tgis-serving リポジトリーの Converting Hugging Face Hub models to Caikit format を参照してください。
  • モデルサーバーでグラフィックスプロセッシングユニット (GPU) を使用する場合は、OpenShift AI で GPU サポートを有効にしている。OpenShift AI での GPU サポートの有効化 を参照してください。

手順

  1. 左側のメニューで、Data Science Projects をクリックします。

    Data science projects のページが開きます。

  2. モデルをデプロイするプロジェクトの名前をクリックします。

    プロジェクトの詳細ページが開きます。

  3. Models タブをクリックします。
  4. 次のいずれかの操作を実行します。

    • ​​Single model serving platform タイルが表示された場合は、タイル上の Deploy model をクリックします。
    • タイルが表示されない場合は、Deploy model ボタンをクリックします。

    Deploy model ダイアログが開きます。

  5. Model name フィールドに、デプロイするモデルの一意の名前を入力します。
  6. Serving runtime フィールドで、有効なランタイムを選択します。
  7. Model framework リストから値を選択します。
  8. Number of model replicas to deploy フィールドに値を指定します。
  9. Model server size リストから値を選択します。
  10. デプロイされたモデルへの推論リクエストにトークン認証を要求するには、以下のアクションを実行します。

    1. Require token authorization を選択します。
    2. Service account name フィールドに、トークンが生成されるサービスアカウント名を入力します。
  11. モデルの場所を指定するには、次の一連のアクションのいずれかを実行します。

    • 既存のデータ接続を使用するには

      1. Existing data connection を選択します。
      2. Name リストから、以前に定義したデータ接続を選択します。
      3. Path フィールドに、指定したデータソース内のモデルを含むフォルダーパスを入力します。

        重要

        OpenVINO Model Server ランタイムには、モデルパスの指定方法に関する特定の要件があります。詳細は、OpenShift AI リリースノートの既知の問題 RHOAIENG-3025 を参照してください。

    • 新しいデータ接続を使用するには

      1. モデルがアクセスできる新しいデータ接続を定義するには、New data connection を選択します。
      2. Name フィールドに、データ接続の一意の名前を入力します。
      3. Access key フィールドに、S3 互換オブジェクトストレージプロバイダーのアクセスキー ID を入力します。
      4. Secret key フィールドに、指定した S3 互換オブジェクトストレージアカウントのシークレットアクセスキーを入力します。
      5. Endpoint フィールドに、S3 互換オブジェクトストレージバケットのエンドポイントを入力します。
      6. Region フィールドに、S3 互換オブジェクトストレージアカウントのデフォルトのリージョンを入力します。
      7. Bucket フィールドに、S3 互換オブジェクトストレージバケットの名前を入力します。
      8. Path フィールドに、データファイルが含まれる S3 互換オブジェクトストレージ内のフォルダーパスを入力します。

        重要

        OpenVINO Model Server ランタイムには、モデルパスの指定方法に関する特定の要件があります。詳細は、OpenShift AI リリースノートの既知の問題 RHOAIENG-3025 を参照してください。

  12. Deploy をクリックします。

検証

  • デプロイされたモデルがプロジェクトの Models タブと、ダッシュボードの Model Serving ページで Status 列にチェックマークが表示されていることを確認します。

3.6. シングルモデル提供プラットフォームにデプロイされたモデルへの推論リクエストの作成

シングルモデルサービスプラットフォームを使用してモデルをデプロイすると、そのモデルは、API リクエストを使用してアクセスできるサービスとして利用できます。これにより、データ入力に基づく予測を返すことができます。API リクエストを使用してデプロイされたモデルと対話するには、モデルの推論エンドポイントを知っている必要があります。

さらに、トークン認証を有効にして推論エンドポイントを保護した場合、推論要求でこれを指定できるように、認可トークンにアクセスする方法を知っている必要があります。

3.6.1. デプロイされたモデルの認可トークンへのアクセス

トークン承認を有効にしてモデルの推論エンドポイントを保護した場合は、推論リクエストで承認トークンを指定できるように、認可トークンにアクセスする方法を知っている必要があります。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。
  • シングルモデルサービスプラットフォームを使用してモデルをデプロイした。

手順

  1. OpenShift AI ダッシュボードから、Data Science Projects をクリックします。

    Data science projects のページが開きます。

  2. デプロイしたモデルを含むプロジェクトの名前をクリックします。

    プロジェクトの詳細ページが開きます。

  3. Models タブをクリックします。
  4. Models and model servers リストで、モデルのセクションを展開します。

    認可トークンは、Token secret フィールドの Token authorization セクションに表示されます。

  5. オプション:推論リクエストで使用する認証トークンをコピーするには、トークンの値の横にある Copy ボタン( osd copy )をクリックします。

3.6.2. デプロイされたモデルの推論エンドポイントへのアクセス

デプロイされたモデルへの推論リクエストを行うには、利用可能な推論エンドポイントにアクセスする方法を知っている必要があります。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift のユーザーグループ、または、管理者グループ (rhoai-usersrhoai-admins など) に属している。
  • シングルモデルサービスプラットフォームを使用してモデルをデプロイした。
  • デプロイされたモデルのトークン承認を有効にした場合には、関連付けられたトークン値があります。

手順

  1. OpenShift AI ダッシュボードから、Data Science Projects をクリックします。

    Data science projects のページが開きます。

  2. デプロイしたモデルを含むプロジェクトの名前をクリックします。

    プロジェクトの詳細ページが開きます。

  3. Models タブをクリックします。
  4. Models and model servers リストで、モデルのセクションを展開します。

    モデルの推論エンドポイントは、推論 endpoint フィールドに表示されます。

  5. モデルを使用して実行するアクション(およびモデルがそのアクションをサポートしている場合)に応じて、表示される推論エンドポイントをコピーし、次のパスのいずれかを URL の最後に追加します。

    Caikit TGIS ServingRuntime for KServe

    • :443/api/v1/task/text-generation
    • :443/api/v1/task/server-streaming-text-generation

    TGIS Standalone ServingRuntime for KServe

    • :443 fmaas.GenerationService/Generate
    • :443 fmaas.GenerationService/GenerateStream

      注記

      TGIS スタンドアロンランタイムのエンドポイントをクエリーするには、IBM text-generation-inference リポジトリーの proto ディレクトリーにファイルをダウンロードする必要もあります。

    OpenVINO Model Server

    • /v2/models/<model-name>/infer

    上記のパスで示されているように、シングルモデルサービスプラットフォームは、OpenShift ルーターの HTTPS ポート (通常はポート 443) を使用して、外部 API リクエストを処理します。

  6. 次のコマンド例に示すように、エンドポイントを使用して、デプロイされたモデルに API リクエストを作成します。

    Caikit TGIS ServingRuntime for KServe

    curl --json '{"model_id": "<model_name>", "inputs": "<text>"}' https://<inference_endpoint_url>:443/api/v1/task/server-streaming-text-generation -H 'Authorization: Bearer <token>'  1
    1
    Authorization ヘッダーを追加し、モデルのデプロイ時にトークン承認を有効にした場合に のみ トークンの値を指定する必要があります。

    TGIS Standalone ServingRuntime for KServe

    grpcurl -proto text-generation-inference/proto/generation.proto -d '{"requests": [{"text":"<text>"}]}' -H 'mm-model-id: <model_name>' -H 'Authorization: Bearer <token>' -insecure <inference_endpoint_url>:443 fmaas.GenerationService/Generate  1
    1
    Authorization ヘッダーを追加し、モデルのデプロイ時にトークン承認を有効にした場合に のみ トークンの値を指定する必要があります。

    OpenVINO Model Server

    curl -ks <inference_endpoint_url>/v2/models/<model_name>/infer -d '{ "model_name": "<model_name>", "inputs": [{ "name": "<name_of_model_input>", "shape": [<shape>], "datatype": "<data_type>", "data": [<data>] }]}' -H 'Authorization: Bearer <token>'  1
    1
    Authorization ヘッダーを追加し、モデルのデプロイ時にトークン承認を有効にした場合に のみ トークンの値を指定する必要があります。

3.7. シングルモデル提供プラットフォーム用のモデル提供ランタイムメトリクスの表示

クラスター管理者がシングルモデル提供プラットフォームのモニタリングを設定している場合、管理者以外のユーザーは OpenShift Web コンソールを使用して、KServe コンポーネントのモデル提供ランタイムメトリックを表示できます。

前提条件

手順

  1. OpenShift Web コンソールにログインします。
  2. Developer パースペクティブに切り替えます。
  3. 左側のメニューで、Observe をクリックします。
  4. ユーザー定義プロジェクトのメトリクスのクエリー(Red Hat OpenShift Dedicated)または開発者と しての ユーザー定義プロジェクトのメトリクスのクエリー (Red Hat OpenShift Service on AWS)で説明されているように、Web コンソールを使用して caikit_*、t gi_*、および ovms_* モデル提供のランタイムメトリクスのクエリーを実行します。OpenShift Service Mesh に関連する istio_* メトリクスのクエリーを実行することもできます。

3.8. 単一モデル提供プラットフォームでのパフォーマンスチューニング

特定のパフォーマンスの問題では、推論サービスまたはモデル提供ランタイムのパラメーターの調整が必要になる場合があります。

3.8.1. CUDA メモリー不足エラーの解決

場合によっては、使用されるモデルとハードウェアアクセラレーターによっては、TGIS メモリーの自動チューニングアルゴリズムが、長いシーケンスを処理するために必要な GPU メモリーの量を推定する可能性があります。この計算ミスにより、モデルサーバーからの Compute Unified Architecture (CUDA)のメモリー不足(OOM)エラーの応答が生じる可能性があります。このような場合は、以下の手順で説明するように、TGIS モデル提供ランタイムにパラメーターを更新または追加する必要があります。

前提条件

  • Red Hat OpenShift AI にログインしている。
  • 特殊な OpenShift AI グループを使用している場合は、OpenShift の管理者グループ (rhoai-admins など) の一員となります。

手順

  1. OpenShift AI ダッシュボードから、Settings > Serving runtimes をクリックします。

    Serving runtimes ページが開き、すでにインストールされ有効になっているモデルサービスランタイムが表示されます。

  2. モデルのデプロイに使用したランタイムに基づいて、次のいずれかのアクションを実行します。

    • 事前にインストールされた TGIS Standalone ServingRuntime を KServe ランタイムに使用した場合は、ランタイムを複製してカスタムバージョンを作成し、残りの手順に従います。プリインストールされた TGIS ランタイムを複製する方法の詳細については、シングルモデル提供プラットフォーム用のカスタムモデル提供ランタイムの追加 を参照してください。
    • すでにカスタム TGIS ランタイムを使用している場合は、ランタイムの横にあるアクションメニュー(⋮)をクリックし、Edit を選択します。

      埋め込み YAML エディターが開き、カスタムモデル提供ランタイムの内容が表示されます。

  3. BATCH_SAFETY_MARGIN 環境変数を追加または更新し、値を 30 に設定します。同様に、ESTIMATE_MEMORY_BATCH_SIZE 環境変数を追加または更新し、値を 8 に設定します。

    spec:
      containers:
        env:
        - name: BATCH_SAFETY_MARGIN
          value: 30
        - name: ESTIMATE_MEMORY_BATCH
          value: 8
    注記

    BATCH_SAFETY_MARGIN パラメーターは、OOM 状態を回避するために安全マージンとして保持する空き GPU メモリーの割合を設定します。BATCH_SAFETY_MARGIN のデフォルト値は 20 です。ESTIMATE_MEMORY_BATCH_SIZE パラメーターは、メモリーの自動チューニングアルゴリズムで使用されるバッチサイズを設定します。ESTIMATE_MEMORY_BATCH_SIZE のデフォルト値は 16 です。

  4. Update をクリックします。

    Serving runtimes ページが開き、インストールされているランタイムの更新されたリストが表示されます。更新したカスタムのモデル提供ランタイムが表示されていることを確認します。

  5. パラメーターの更新を有効にするためにモデルを再デプロイするには、以下のアクションを実行します。

    1. OpenShift AI ダッシュボードから、Model Serving > Deployed Models をクリックします。
    2. 再デプロイするモデルを見つけ、モデルの横にあるアクションメニュー(⋮)をクリックし、Delete を選択します。
    3. シングルモデル提供プラットフォームへのモデルのデプロイ の説明に従って、モデル を再デプロイします。

検証

  • モデルサーバーから正常な応答が表示され、CUDA OOM エラーは表示されなくなります。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.