AI モデルの使用


Red Hat build of MicroShift 4.20

MicroShift で AI モデルを使用する

Red Hat OpenShift Documentation Team

概要

MicroShift エッジデプロイメントで人工知能 (AI) モデルを提供する方法を説明します。

第1章 Red Hat OpenShift AI を MicroShift で使用する

MicroShift エッジデプロイメントで人工知能 (AI) 機能を使用して、人工知能および機械学習 (AI/ML) モデルを提供する方法を説明します。

重要

Red Hat OpenShift AI はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、以下のリンクを参照してください。

1.1. MicroShift での Red Hat OpenShift AI の仕組み

エッジデプロイメントは、データが発生し、意思決定を行う必要がある場所です。Red Hat OpenShift AI (Red Hat OpenShift AI Self-Managed) を使用すると、MicroShift 駆動型エッジデバイスのフリートを人工知能および機械学習 (AI/ML) 運用サイクルに統合できます。MicroShift は、Kubernetes の KServe コンポーネントに基づくシングルモデルサービングプラットフォームと互換性があります。KServe は、モデルサービングをオーケストレーションするプラットフォームです。

Red Hat OpenShift AI Self-Managed は、データサイエンティストおよび AI/ML アプリケーション開発者向けのプラットフォームです。まず、クラウドまたはデータセンターで Red Hat OpenShift AI Self-Managed を使用して、AI モデルを開発、トレーニング、テストします。次に、MicroShift のエッジデプロイメントでモデルを実行します。

AI モデルをデプロイした後、アプリケーションデータをモデルに送信できるようになり、モデルは人間のユーザーなしでデータに基づく意思決定を行うことができます。これは、管理者とのやり取りが自然と制限されるエッジアプリケーションにとって理想的なシナリオです。

KServe での実装
KServe コンポーネントには、さまざまな種類のモデルサーバーの読み込みを実装するモデルサービングランタイムが含まれています。これらのランタイムは、カスタムリソース (CR) を使用して設定されます。KServe カスタムリソース定義 (CRD) は、デプロイメントオブジェクト、ストレージアクセス、およびネットワークセットアップのライフサイクルも定義します。
Red Hat OpenShift AI Self-Managed を MicroShift で使用する場合の詳細

エッジ最適化された Kubernetes デプロイメントである MicroShift では、Red Hat OpenShift AI Self-Managed を使用する場合、次の制限があります。

  • MicroShift での AI モデルサービングは、x86_64 アーキテクチャーでのみ利用できます。
  • Red Hat OpenShift AI Self-Managed Operator コンポーネントのサブセットが MicroShift でサポートされています。
  • MicroShift はシングルノードの Kubernetes ディストリビューションであるため、マルチモデルのデプロイメントをサポートしません。シングルモデルサービングプラットフォームを使用する必要があります。
  • クラウドまたはデータセンターの MicroShift モデルサービングプラットフォームで実行する AI モデルを開発する必要があります。MicroShift を AI モデルの開発プラットフォームとして使用することはサポートされていません。
  • AI モデルを提供するために必要な追加の RAM、ディスク領域、およびストレージ設定を計画する必要があります。
  • すべてのモデルサーバーが IPv6 ネットワークプロトコルをサポートしているわけではありません。各モデルサーバーのドキュメントをチェックして、ネットワーク設定がサポートされていることを確認してください。
  • 公開されたモデルサーバーのエンドポイントを、たとえば OAUTH2 を使用して保護する必要があります。
  • ClusterServingRuntimes CRD は Red Hat OpenShift AI Self-Managed ではサポートされていないため、microshift-ai-model-serving RPM に同梱されている ServingRuntime CR をワークロード namespace にコピーする必要があります。
  • MicroShift でモデルサービングを管理するには、CLI を使用する必要があります。Red Hat OpenShift AI Self-Managed ダッシュボードはサポートされていません。

1.2. Red Hat OpenShift AI Self-Managed を MicroShift で使用するためのワークフロー

Red Hat OpenShift AI Self-Managed を MicroShift で使用するには、次の一般的なワークフローが必要です。

AI モデルを準備する
  • エッジアプリケーションと MicroShift デプロイメントサイトで必要な意思決定に最適な人工知能 (AI) モデルを選択します。
  • クラウドまたはデータセンターで、モデルを開発、トレーニング、テストします。
  • AI モデルの実行に必要なシステム要件と追加リソースを計画します。
デプロイメント環境のセットアップ
  • Red Hat Device Edge を、ドライバーやデバイスプラグインを含めて、デプロイメントが実行される特定のハードウェアに合わせて設定します。
  • MicroShift で GPU またはその他のハードウェアアクセラレーターを有効にするには、使用しているエッジデバイスに特化したガイダンスに従い、必要なソフトウェアをインストールしてください。たとえば、NVIDIA GPU アクセラレーターを使用するには、まずは Running a GPU-Accelerated Workload on Red Hat Device Edge (NVIDIA ドキュメント) を参照してください。
  • トラブルシューティングは、デバイスのドキュメントまたは製品サポートを参照してください。

    ヒント

    Operator の代わりにドライバーとデバイスプラグインのみを使用すると、リソース効率が向上する可能性があります。

MicroShift Red Hat OpenShift AI Self-Managed RPM のインストール
  • microshift-ai-model-serving RPM パッケージをインストールします。
  • MicroShift の実行中に RPM を追加する場合は、MicroShift を再起動します。
デプロイの準備
  • AI モデルを OCI イメージ (ModelCar 形式とも呼ばれます) にパッケージ化します。S3 互換ストレージまたは永続ボリューム要求がすでにセットアップされている場合は、この手順をスキップできますが、MicroShift では ModelCar 形式のみがテストされ、サポートされています。
  • モデルサーバーとして機能するモデルサービングランタイムを選択します。サービングランタイムと推論サービスを使用して、ランタイムを設定します。

    • ServingRuntime カスタムリソース (CR) をデフォルトの redhat-ods-applications namespace から独自の namespace にコピーします。
    • InferenceService CR を作成します。
  • オプション: モデルがノードの外部に接続できるように、Route オブジェクトを作成します。
モデルの使用
  • モデルサーバーに対してリクエストを実行します。たとえば、カメラに接続された MicroShift デプロイメントで実行されている別の Pod は、モデルサービングランタイムにイメージをストリーミングすることができます。モデルサービングランタイムは、そのイメージをモデル推論用のデータとして準備します。そのモデルがハチの 2 値分類で学習されている場合、AI モデルはイメージデータがハチである確率を出力します。

1.3. Red Hat OpenShift AI RPM のインストール

MicroShift デプロイメントで AI モデルを使用するには、新しい MicroShift インストールで Red Hat OpenShift AI (Red Hat OpenShift AI Self-Managed) RPM をインストールします。システムを再起動すると、既存の MicroShift インスタンスに RPM をインストールすることもできます。

注記

microshift-ai-model-serving RPM には、raw デプロイメントモードが有効になっている kserve と、redhat-ods-applications namespace 内の ServingRuntimes オブジェクトをデプロイするマニフェストが含まれています。

重要

Red Hat OpenShift AI はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、以下のリンクを参照してください。

前提条件

  • MicroShift をインストールするためのシステム要件が満たされている。
  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。
  • ワークロードの PV に必要な容量を使用して LVM VG を設定している。
  • AI モデルに必要な RAM とディスク容量がある。
  • モデルに必要なリソースを提供するために、必要なアクセラレーター、ハードウェア、オペレーティングシステム、および MicroShift を設定している。
  • AI モデルをいつでも使用できる。

手順

  1. 次のコマンドを実行して、MicroShift AI-model-serving RPM パッケージをインストールします。

    $ sudo dnf install microshift-ai-model-serving
  2. root ユーザーとして、次のコマンドを入力して MicroShift サービスを再起動します。

    $ sudo systemctl restart microshift
  3. オプション: 次のコマンドを実行して、リリース情報パッケージをインストールします。

    $ sudo dnf install microshift-ai-model-serving-release-info
    注記

    microshift-ai-model-serving-release-info RPM には、オフラインでの手順や、bootc イメージビルド中に ServingRuntime カスタムリソースのコピーを namespace にデプロイする際に役立つイメージ参照が含まれる JSON ファイルが格納されています。

検証

  • 次のコマンドを入力して、kserve Pod が redhat-ods-applications namespace で実行されていることを確認します。

    $ oc get pods -n redhat-ods-applications

    出力例

    NAME                                        READY   STATUS    RESTARTS   AGE
    kserve-controller-manager-7fc9fc688-kttmm   1/1     Running   0          1h

次のステップ

  • AI モデルの namespace を作成します。
  • モデルを OCI イメージにパッケージ化します。
  • モデルサービングランタイムを設定します。
  • モデルが推論の準備ができていることを確認します。
  • モデルサーバーに対してリクエストを実行します。

1.4. MicroShift で AI モデルの namespace を作成する

AI モデルとその他すべてのリソースの namespace を作成します。

前提条件

  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを実行して新しい namespace を作成します。

    $ oc create ns <namespace_name> 
    1
    1
    <namespace_name> は、使用する namespace 名に置き換えます。以下の例では、ai-demo が使用されています。

検証

  • 次のコマンドを実行して、目的の namespace が作成されたことを確認します。

    $ oc get ns <namespace_name> 
    1
    1
    <namespace_name> は、使用する namespace 名に置き換えます。以下の例では、ai-demo が使用されています。

    出力例

    NAME                STATUS  AGE
    ai-demo   Active  1h

1.5. AI モデルを OCI イメージにパッケージ化する

モデルを OCI イメージにパッケージ化し、ModelCar アプローチを使用して、オフライン環境をセットアップすることができます。ModelCar アプローチを使用すると、モデルを他のコンテナーイメージと同じように埋め込むことができます。

注記

S3 互換のオブジェクトストレージまたは設定済みの永続ボリューム要求がすでにある場合は、AI モデルをそれらのリソースにアップロードできますが、ModelCar アプローチのみがテストおよびサポートされます。

前提条件

  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。
  • Podman がインストールされている。
  • モデルをいつでも使用できる。
  • vLLM モデルサーバーに適した OCI イメージの構築に関する記事 Build and deploy a ModelCar container in OpenShift AI の "How to build a ModelCar container" セクションの概念を理解している。

    注記

    正確なディレクトリー構造はモデルサーバーによって異なります。次の例では、OpenVINO Model Server OVMS と互換性のある ResNet-50 モデルを含む Containerfile を使用します。OVMS では通常、追加のハードウェアアクセラレーターは必要ありません。

手順

  1. 互換性のあるモデルとモデルサーバーを備えた Containerfile を準備します。

    OVMS で使用される ResNet-50 モデルを含む Containerfile の例

    FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
    RUN microdnf install -y wget && microdnf clean all
    RUN mkdir -p /models/1 && chmod -R 755 /models/1
    RUN wget -q -P /models/1 \
      https://storage.openvinotoolkit.org/repositories/open_model_zoo/2022.1/models_bin/2/resnet50-binary-0001/FP32-INT1/resnet50-binary-0001.bin \
      https://storage.openvinotoolkit.org/repositories/open_model_zoo/2022.1/models_bin/2/resnet50-binary-0001/FP32-INT1/resnet50-binary-0001.xml

  2. 次のコマンドを実行して、IMAGE_REF 環境変数を設定し、プロセスを簡素化します。

    $ IMAGE_REF=<ovms-resnet50:test> 
    1
    1
    <ovms-resnet50:test> は、イメージ参照の名前に置き換えます。この例では、<repo:tag> 形式が使用されています。イメージ参照名はユースケースに固有です。
  3. 次のコマンドを実行して Containerfile をビルドします。

    $ sudo podman build -t $IMAGE_REF 
    1
    1
    CRI-O と Podman はストレージを共有するため、イメージをルートのコンテナーストレージの一部にして MicroShift で使用できるようにするには、sudo を使用する必要があります。

    出力例

    STEP 1/4: FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
    Trying to pull registry.access.redhat.com/ubi9/ubi-minimal:latest...
    Getting image source signatures
    Checking if image destination supports signatures
    Copying blob 533b69cfd644 done   |
    Copying blob 863e9a7e2102 done   |
    Copying config 098048e6f9 done   |
    Writing manifest to image destination
    Storing signatures
    STEP 2/4: RUN microdnf install -y wget && microdnf clean all
    << SNIP >>
    --> 4c74352ad42e
    STEP 3/4: RUN mkdir -p /models/1 && chmod -R 755 /models/1
    --> bfd31acb1e81
    STEP 4/4: RUN wget -q -P /models/1   https://storage.openvinotoolkit.org/repositories/open_model_zoo/2022.1/models_bin/2/resnet50-binary-0001/FP32-INT1/resnet50-binary-0001.bin   https://storage.openvinotoolkit.org/repositories/open_model_zoo/2022.1/models_bin/2/resnet50-binary-0001/FP32-INT1/resnet50-binary-0001.xml
    COMMIT ovms-resnet50:test
    --> 375b265c1c4b
    Successfully tagged localhost/ovms-resnet50:test
    375b265c1c4bc6f0a059c8739fb2b3a46e1b563728f6d9c51f26f29bb2c87

  4. オプション: 次のコマンドを実行して、Containerfile をレジストリーにプッシュします。

    $ sudo podman push $IMAGE_REF
    重要

    オフラインで使用する場合は、latest 以外のタグを含めます。latest タグが使用されている場合、モデルを取得してセットアップするコンテナーは、imagePullPolicy: パラメーターが Always に設定されて構成されており、ローカルのイメージは無視されます。latest 以外のタグを使用する場合、imagePullPolicy: パラメーターは IfNotPresent に設定されます。

検証

  • 次のコマンドを実行して、イメージが存在することを確認します。

    $ sudo podman images ovms-resnet50

    出力例

    REPOSITORY                TAG   IMAGE ID        CREATED         SIZE
    localhost/ovms-resnet50   test  375b265c1c4b    3 minutes ago   136 MB

次のステップ

  • モデルサービングランタイムを設定します。
  • AI モデルが推論の準備ができていることを確認します。
  • モデルサーバーに対してリクエストを実行します。

1.6. MicroShift で AI モデルを提供する

ServingRuntime および InferenceService カスタムリソース (CR) を使用してモデルサービングランタイムを設定することにより、MicroShift の Red Hat OpenShift AI Self-Managed シングルモデルサービングプラットフォームでモデルを提供できます。

MicroShift の AI モデル向けモデルサービングランタイム
モデルサービングランタイムは、AI モデルをデプロイおよび管理するための環境であり、指定されたモデルサーバーとそれがサポートするモデルフレームワークとの統合を提供します。モデルサービングランタイムを作成するということは、デプロイメントに固有のその他の詳細な機能の中でも、AI モデルに適切なモデル形式を選択してクエリーを処理するオブジェクトを設定することを意味します。
ServingRuntime カスタムリソース
ServingRuntime CR は、AI モデル形式を動的にロードおよびアンロードできる Pod のテンプレートを定義し、API を介してモデルをクエリーするためのサービスエンドポイントを公開する YAML ファイルです。各 ServingRuntime CR には、ランタイムのコンテナーイメージや、モデルサービングランタイムがサポートするモデル形式のリストなど、AI モデルの実行に必要な情報が含まれています。モデルサービングランタイムのその他の設定は、コンテナー仕様で定義された環境変数を使用して設定できます。
InferenceService カスタムリソース
InferenceService CR は、推論クエリーを処理し、それをモデルに渡して、推論出力を返すサーバーまたは推論サービスを作成する YAML ファイルです。MicroShift では、出力は CLI で返されます。この推論サービス設定ファイルには、ハードウェアアクセラレーターの指定など、他の多くのオプションも含めることができます。
重要

MicroShift はシングルノードの Kubernetes ディストリビューションであるため、マルチモデルのデプロイメントをサポートしません。シングルモデルサービングプラットフォームを使用する必要があります。MicroShift の各デプロイメントでは、1 つの AI モデルを使用できますが、複数のモデルランタイムを使用する可能性もあります。

モデルサービングランタイムを設定するためのワークフロー
  • AI モデルの形式をサポートするモデルサービングランタイムを選択します。
  • ワークロード namespace に ServingRuntime CR を作成します。
  • MicroShift ノードがすでに実行されている場合は、必要な ServingRuntime CR をファイルにエクスポートして編集できます。
  • MicroShift ノードが実行されていない場合、またはマニフェストを手動で準備する場合は、microshift-ai-model-serving RPM の一部であるディスク上の元の定義を使用できます。
  • ワークロード namespace に InferenceService CR を作成します。

1.6.1. サポートされている Red Hat OpenShift AI Self-Managed カスタムリソース定義

次の Red Hat OpenShift AI Self-Managed カスタムリソース定義 (CRD) がサポートされています。

  • InferenceServices
  • TrainedModels
  • ServingRuntimes
  • InferenceGraphs
  • ClusterStorageContainers
  • ClusterLocalModels
  • LocalModelNodeGroups

1.6.2. サポートされている Red Hat OpenShift AI Self-Managed モデルサービングランタイム

MicroShift デプロイメントでは、次の Red Hat OpenShift AI Self-Managed モデルサービングランタイムが検証されています。

  • vLLM ServingRuntime for KServe
  • OpenVINO Model Server

    重要

    OpenVINO Model Server は、IPv6 ネットワークプロトコルをサポートしていません。使用前に各モデルサーバーをチェックして、ネットワーク設定をサポートしていることを確認してください。

MicroShift では、開発目的で次のランタイムが利用できます。

  • Caikit Text Generation Inference Server (Caikit-TGIS) ServingRuntime for KServe
  • Caikit Standalone ServingRuntime for KServe
  • Text Generation Inference Server (TGIS) Standalone ServingRuntime for KServe
  • vLLM ServingRuntime with Gaudi accelerators support for KServe
  • vLLM ROCm ServingRuntime for KServe
  • 作成してテストするカスタムランタイム

1.7. MicroShift で使用するための ServingRuntime CR の作成

インストールされたマニフェストとリリース情報に基づいて、ServingRuntime カスタムリソース (CR) を作成します。含まれている手順は、含まれている microshift-ai-model-serving マニフェストファイルを再利用して、ワークロード namespace で OpenVINO Model Server (OVMS) モデルサービングランタイムを再作成する例です。

注記

このアプローチではライブノードは必要ないため、CI/CD 自動化の一部にすることができます。

前提条件

  • microshift-ai-model-serving RPM と microshift-ai-model-serving-release-info RPM の両方がインストールされている。
  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、MicroShift リリース情報ファイルから、使用する ServingRuntime CR のイメージ参照を抽出します。

    $ OVMS_IMAGE="$(jq -r '.images | with_entries(select(.key == "ovms-image")) | .[]' /usr/share/microshift/release/release-ai-model-serving-"$(uname -i)".json)" 
    1
    1
    この例では、OVMS モデルサービングランタイムのイメージ参照が抽出されます。
  2. 次のコマンドを実行して、元の ServingRuntime YAML ファイルをコピーします。

    $ cp /usr/lib/microshift/manifests.d/050-microshift-ai-model-serving-runtimes/ovms-kserve.yaml ./ovms-kserve.yaml
  3. 次のコマンドを実行して、ServingRuntime YAML の image: パラメーターフィールド値に実際のイメージ参照を追加します。

    $ sed -i "s,image: ovms-image,image: ${OVMS_IMAGE}," ./ovms-kserve.yaml
  4. 次のコマンドを実行し、YAML ファイルを使用してカスタム namespace に ServingRuntime オブジェクトを作成します。

    $ oc create -n <ai_demo> -f ./ovms-kserve.yaml 
    1
    1
    <ai_demo> は、namespace の名前に置き換えます。
重要

ServingRuntime CR が新しいマニフェストの一部である場合は、kustomization.yaml ファイルで namespace を設定します。次に例を示します。

Kustomize マニフェストの namespace 値の例

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: ai-demo
resources:
  - ovms-kserve.yaml
#...

次のステップ

  • InferenceService オブジェクトを作成します。
  • モデルが推論の準備ができていることを確認します。
  • モデルをクエリーします。
  • オプション: モデルメトリクスを調べます。

1.8. InferenceService カスタムリソースの作成

InferenceService カスタムリソース (CR) を作成して、AI モデルを提供するためのデプロイメントを作成する方法を KServe に指示します。KServe は、InferenceService CR で指定された modelFormat 値に基づいて ServingRuntime を使用します。

前提条件

  • ServingRuntimes CR を設定している。
  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. InferenceService CR を作成します。

    openvino_ir モデル形式の InferenceService オブジェクトの例

    apiVersion: serving.kserve.io/v1beta1
    kind: InferenceService
    metadata:
      name: ovms-resnet50
    spec:
      predictor:
        model:
          protocolVersion: v2
          modelFormat:
            name: openvino_ir
          storageUri: "oci://localhost/ovms-resnet50:test"
          args:
          - --layout=NHWC:NCHW 
    1

    1
    OpenVINO Model Server (OVMS) が、モデルが元々エクスポートされたレイアウトとは異なるレイアウトで、要求入力データを受け入れるようにするための追加の引数。追加の引数は OVMS コンテナーに渡されます。
  2. InferenceService の例をファイルに保存してから、次のコマンドを実行してクラスター上に作成します。

    $ oc create -n <ai_demo> -f ./FILE.yaml 
    1
    1
    <ai_demo> は、namespace 名に置き換えます。

    出力例

    inferenceservice.serving.kserve.io/ovms-resnet50 created

    注記

    デプロイメントと Pod は、指定された namespace に表示されることが予想されます。ServingRuntime CR で指定されたイメージのサイズと ModelCar OCI イメージのサイズによっては、Pod の準備が完了するまでに数分かかる場合があります。

次のステップ

  • モデルサービングランタイムの準備ができていることを確認します。

1.8.1. Open Telemetry を使用してモデルサーバーメトリクスをエクスポートする

MicroShift 用の microshift-observability RPM をインストールした場合は、Open Telemetry を使用してモデルサーバーメトリクスをエクスポートできます。

注記

または、/metrics エンドポイントでリクエストすることで、モデルサーバーの Prometheus 形式のメトリクスを取得することもできます。詳細は、「モデルサーバーのメトリクスを取得する」を参照してください。

前提条件

  • ServingRuntimes CR を設定している。
  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。
  • microshift-observability RPM をインストールしている。
  • MicroShift Open Telemetry 設定には Prometheus Receiver が含まれている。詳細は、Prometheus Receiver を参照してください。

手順

  • InferenceService カスタムリソースに次の Open Telemetry アノテーションを追加します。

    Open Telemetry を使用した InferenceService オブジェクトの例

    apiVersion: serving.kserve.io/v1beta1
    kind: InferenceService
    metadata:
      name: ovms-resnet50
    #...
      annotations:
        prometheus.io/scrape: "true"
    #...

1.8.2. その他の InferenceService CR オプション

推論サービスの YAML ファイルには、さまざまなオプションを含めることができます。たとえば、最初にデプロイメントに渡され、次に Pod に渡される resources セクションを含めることで、モデルサーバーがデバイスプラグインを通じてハードウェアにアクセスできるようになります。

InferenceService CR 内の NVIDIA デバイス resources スニペットの例

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: is-name
spec:
  predictor:
    model:
      resources:
        limits:
          nvidia.com/gpu: 1
        requests:
          nvidia.com/gpu: 1
#...

完全な InferenceService 仕様については、Control Plane API Reference (KServe ドキュメント) を参照してください。

1.9. モデルサービングランタイムの準備ができていることを確認する

ダウンストリームの生成アクティビティーが完了していることを確認し、モデルサービングランタイムが使用できる状態であることを確認します。

前提条件

  • ServingRuntimes CR を設定している。
  • InferenceService CR を作成している。
  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、AI モデルがカスタム namespace にデプロイされていることを確認します。

    $ oc get -n ai-demo deployment

    出力例

    NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
    ovms-resnet50-predictor   1/1     1            1           72s

  2. 次のコマンドを実行して、デプロイメントが進行中であることを確認します。

    $ oc rollout status -n ai-demo deployment ovms-resnet50-predictor

    出力例

    deployment "ovms-resnet50-predictor" successfully rolled out

  3. 次のコマンドを実行して、AI モデルワークロード Pod がカスタム namespace にデプロイされていることを確認します。

    $ oc get -n ai-demo pod

    出力例

    NAME                                       READY   STATUS    RESTARTS      AGE
    ovms-resnet50-predictor-6fdb566b7f-bc9k5   2/2     Running   1 (72s ago)   74s

  4. 次のコマンドを実行して、作成されたサービス KServe を確認します。

    $ oc get svc -n ai-demo

    出力例

    NAME                      TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
    ovms-resnet50-predictor   ClusterIP   None         <none>        80/TCP    119s

次のステップ

  • アプリケーションが MicroShift ノードに到達できるように、Route オブジェクトを作成します。

関連情報

1.10. MicroShift で AI クエリーに使用するルートを作成する

AI モデルがクエリーを受信して出力できるようにルートを作成します。oc expose svc コマンドを使用するか、YAML ファイルで定義を作成して適用することができます。

前提条件

  • マシンへの root ユーザーアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを使用してルートを作成します。

    $ oc expose svc -n ai-demo ovms-resnet50-predictor

    出力例

    route.route.openshift.io/ovms-resnet50-predictor exposed

検証

  • 次のコマンドを実行して、作成したルートが存在することを確認します。

    $ oc get route -n ai-demo

    出力例

    NAME                      HOST                                               ADMITTED   SERVICE                   TLS
    ovms-resnet50-predictor   ovms-resnet50-predictor-ai-demo.apps.example.com   True       ovms-resnet50-predictor

関連情報

1.11. AI モデルのクエリーについて

API を介してモデルをクエリーすることは、モデル推論とも呼ばれます。モデル推論は、情報の取得、タスクの自動化、予測の作成、データの洞察の提供、アクションの実行に最もよく使用されます。

一般に、クエリーは、使用されている AI モデルと互換性のある形式を使用して構築する必要があります。モデルサービングランタイムは、クエリーを自動的にフォーマットします。モデルは、基礎となるトレーニングとデータに従ってクエリーを処理し、出力を提供します。出力は、回答を提供すること、予測を行うこと、またはタスクを実行することなど、モデル自体の目的と一致することが期待されます。

次の例では、モデルが推論の準備ができていることを確認するための一般的な手順と、サービスランタイムからのクエリー出力に何が期待できるかを説明します。

1.11.1. AI モデルがアクセス可能であることを確認する

API を介してモデルをクエリーする前に、モデルがアクセス可能であり、接続されたデータに基づいて回答を提供する準備ができていることを確認できます。次の例は、OpenVINO Model Server を引き続き使用します。

前提条件

  • AI モデルサービングランタイムを設定している。
  • AI モデルを MicroShift にアップロードしている。
  • MicroShift が実行中である。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンド例に示すように、MicroShift ノードの IP アドレスを取得し、それを IP 変数に割り当てます。

    $ IP=$(oc get nodes -o json | jq -r '.items[0].status.addresses[0].address')
  2. 次のコマンドを実行して、作成したルートの名前を特定します。

    $ oc get route -n ai-test <route_name> -o yaml 
    1
    1
    <route_name> は、実際のルートの名前に置き換えます。
  3. 次のコマンドを実行して、ルートの HOST 値を抽出し、DOMAIN 変数に割り当てます。

    DOMAIN=$(oc get route -n ai-test <route_name> -o=jsonpath="{ .status.ingress[0].host }") 
    1
    1
    <route_name> は、実際のルートの名前に置き換えます。
  4. 次のコマンドを実行して、ルートから MicroShift IP アドレスへのデータ転送を有効にします。

    $ curl -i "${DOMAIN}/v2/models/ovms-resnet50/ready" --connect-to "${DOMAIN}::${IP}:" 
    1
    1
    --connect-to "${DOMAIN}::${IP}:" フラグを使用する代わりに、実際の DNS を使用することも、IP アドレスとドメインを /etc/hosts ファイルに追加することもできます。

    出力例

    HTTP/1.1 200 OK
    content-type: application/json
    date: Wed, 12 Mar 2025 16:01:32 GMT
    content-length: 0
    set-cookie: 56bb4b6df4f80f0b59f56aa0a5a91c1a=4af1408b4a1c40925456f73033d4a7d1; path=/; HttpOnly

  5. 次のコマンドを実行して、モデルのメタデータをクエリーします。

    $ curl "${DOMAIN}/v2/models/ovms-resnet50" --connect-to "${DOMAIN}::${IP}:"

    出力例

    {"name":"ovms-resnet50","versions":["1"],"platform":"OpenVINO","inputs":[{"name":"0","datatype":"FP32","shape":[1,224,224,3]}],"outputs":[{"name":"1463","datatype":"FP32","shape":[1,1000]}]

次のステップ

  • モデルが推論の準備ができていることを確認します。
  • モデルをクエリーします。
  • モデルの応答を検証します。
  • オプション: モデルサーバーのメトリクスを取得します。

1.11.2. AI モデルを推論用に準備する

API を介して AI モデルをクエリーする前に、トレーニングデータに基づいて回答を提供できるようにモデルを準備します。次の例は、OVMS モデルを引き続き使用します。

前提条件

  • MicroShift が実行中である。
  • vim-common パッケージの一部である xxd ユーティリティーがある。
  • モデルサービングランタイムを設定している。
  • AI モデルを MicroShift にアップロードしている。

手順

  1. 次のコマンドを実行して、OpenVINO Model Server の例からハチのイメージをダウンロードします。

    $ curl -O https://raw.githubusercontent.com/openvinotoolkit/model_server/main/demos/common/static/images/bee.jpeg
  2. 次のスクリプトを実行して、リクエストデータを作成します。

    IMAGE=./bee.jpeg
    REQ=./request.json
    
    # Add an inference header
    echo -n '{"inputs" : [{"name": "0", "shape": [1], "datatype": "BYTES"}]}' > "${REQ}"
    # Get the size of the inference header 
    1
    
    HEADER_LEN="$(stat -c %s "${REQ}")"
    # Add size of the data (image) in binary format (4 bytes, little endian) 
    2
    
    printf "%08X" $(stat --format=%s "${IMAGE}") | sed 's/\(..\)/\1\n/g' | tac | tr -d '\n' | xxd -r -p >> "${REQ}"
    # Add the data, that is, append the image to the request file
    cat "${IMAGE}" >> "${REQ}"
    1
    推論ヘッダーサイズは、後で HTTP ヘッダーの形式で OpenVINO Model Server に渡す必要があります。
    2
    OpenVINO Model Server は、リトルエンディアンのバイト順で 4 バイト必要です。

1.11.3. AI モデルのクエリー

ovms-resnet50 モデルを使用している AI モデルサーバーに対して推論リクエストを行います。

前提条件

  • MicroShift が実行中である。
  • モデルサービングランタイムを設定している。
  • AI モデルを MicroShift にアップロードしている。

手順

  • 次のコマンドを実行して、ovms-resnet50 モデルを使用しているモデルサーバーに対して推論リクエストを行います。

    $ curl \
        --data-binary "@./request.json" \
        --header "Inference-Header-Content-Length: ${HEADER_LEN}" \
        "${DOMAIN}/v2/models/ovms-resnet50/infer" \
        --connect-to "${DOMAIN}::${IP}:" > response.json

    response.json に保存された推論出力の例

    {
        "model_name": "ovms-resnet50",
        "model_version": "1",
        "outputs": [{
                "name": "1463",
                "shape": [1, 1000],
                "datatype": "FP32",
                "data": [ ....... ] 
    1
    
            }]
    }

    1
    簡潔にするために、.outputs[0].data の内容は例では省略されています。

検証

  1. モデルの予測を決定するには、次の Python スクリプトを使用して、.outputs[0].data 内の最高要素のインデックスを取得し、モデルの予測値を決定します。

    import json
    with open('response.json') as f:
        response = json.load(f)
    data = response["outputs"][0]["data"]
    argmax = data.index(max(data))
    print(argmax)

    出力例

    309 
    1

    1
    この例では、309 というラベルの付いた要素がモデルの応答です。
  2. 出力を resnet 入力データ に対して検証します。以下に例を示します。

    ../../../../demos/common/static/images/bee.jpeg 309

次のステップ

  • オプション: resnet 入力データで利用可能な他のイメージを使用して AI モデルをクエリーします。

1.11.4. モデルサーバーのメトリクスを取得する

クエリーを実行した後、モデルサーバーのメトリクスを取得して、ボトルネックの特定、リソース割り当ての最適化、そして効率的なインフラ利用の確保を行うことができます。

注記

または、MicroShift の Open Telemetry を設定して、モデルサーバーのメトリクスを取得することもできます。詳細は、「InferenceService カスタムリソースへの Open Telemetry の追加」を参照してください。

前提条件

  • MicroShift が実行中である。
  • 表示したいメトリクスデータを提供するのに十分なクエリーが行われました。

手順

  • 次のコマンドを実行して、/metrics エンドポイントにリクエストを送信し、モデルサーバーの Prometheus 形式のメトリクスを取得します。

    $ curl "${DOMAIN}/metrics" --connect-to "${DOMAIN}::${IP}:"

    部分的な出力例

    # HELP ovms_requests_success Number of successful requests to a model or a DAG.
    # TYPE ovms_requests_success counter
    ovms_requests_success{api="KServe",interface="REST",method="ModelReady",name="ovms-resnet50"} 4
    ovms_requests_success{api="KServe",interface="REST",method="ModelMetadata",name="ovms-resnet50",version="1"} 1

1.12. KServe 設定のオーバーライド

KServe 設定をオーバーライドして、モデルサービング環境をカスタマイズする場合は、ご使用中のオペレーティングシステムに応じた一般的な手順に従ってください。

オプション 1
  1. redhat-ods-applications namespace にある既存の ConfigMap ファイル inferenceservice-config のコピーを作成します。
  2. 変更したい設定を編集します。
  3. 既存の ConfigMap オブジェクトを上書きします。
  4. Pod を削除するか、Deployment Pod パラメーターを 0 にスケールダウンしてから 1 に戻すことで、KServe を再起動します。
オプション 2
  1. ConfigMap ファイル /usr/lib/microshift/manifests.d/010-microshift-ai-model-serving-kserve/inferenceservice-config-microshift-patch.yaml をコピーします。
  2. 変更したい設定を編集します。
  3. ConfigMap オブジェクトを適用します。
  4. Pod を削除するか、Deployment Pod パラメーターを 0 にスケールダウンしてから 1 に戻すことで、KServe を再起動します。
RHEL for Edge および Image Mode for RHEL の場合
  1. redhat-ods-applications namespace の /usr/lib/microshift/manifests.d/010-microshift-ai-model-serving-kserve/inferenceservice-config-microshift-patch.yaml または inferenceservice-config ファイルのいずれかに基づいて、ConfigMap ファイルを使用して新しいマニフェストを作成します。
  2. 新しいマニフェストが /usr/lib/microshift/manifests.d/ ディレクトリーに配置されていることを確認します。マニフェストが /usr/lib/microshift/manifests.d/010-microshift-ai-model-serving-kserve/ ディレクトリーの内容の後に適用されるように、接頭辞 011 で開始することを推奨します。

法律上の通知

Copyright © 2025 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.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る