AI モデルの使用
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 を使用して保護する必要があります。
-
ClusterServingRuntimesCRD は Red Hat OpenShift AI Self-Managed ではサポートされていないため、microshift-ai-model-servingRPM に同梱されているServingRuntimeCR をワークロード 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-servingRPM パッケージをインストールします。 - MicroShift の実行中に RPM を追加する場合は、MicroShift を再起動します。
-
- デプロイの準備
- AI モデルを OCI イメージ (ModelCar 形式とも呼ばれます) にパッケージ化します。S3 互換ストレージまたは永続ボリューム要求がすでにセットアップされている場合は、この手順をスキップできますが、MicroShift では ModelCar 形式のみがテストされ、サポートされています。
モデルサーバーとして機能するモデルサービングランタイムを選択します。サービングランタイムと推論サービスを使用して、ランタイムを設定します。
-
ServingRuntimeカスタムリソース (CR) をデフォルトのredhat-ods-applicationsnamespace から独自の namespace にコピーします。 -
InferenceServiceCR を作成します。
-
-
オプション: モデルがノードの外部に接続できるように、
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 モデルをいつでも使用できる。
手順
次のコマンドを実行して、MicroShift AI-model-serving RPM パッケージをインストールします。
$ sudo dnf install microshift-ai-model-servingroot ユーザーとして、次のコマンドを入力して MicroShift サービスを再起動します。
$ sudo systemctl restart microshiftオプション: 次のコマンドを実行して、リリース情報パッケージをインストールします。
$ sudo dnf install microshift-ai-model-serving-release-info注記microshift-ai-model-serving-release-infoRPM には、オフラインでの手順や、bootc イメージビルド中にServingRuntimeカスタムリソースのコピーを namespace にデプロイする際に役立つイメージ参照が含まれる JSON ファイルが格納されています。
検証
次のコマンドを入力して、
kservePod がredhat-ods-applicationsnamespace で実行されていることを確認します。$ 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 では通常、追加のハードウェアアクセラレーターは必要ありません。
手順
互換性のあるモデルとモデルサーバーを備えた 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次のコマンドを実行して、
IMAGE_REF環境変数を設定し、プロセスを簡素化します。$ IMAGE_REF=<ovms-resnet50:test>1 - 1
<ovms-resnet50:test>は、イメージ参照の名前に置き換えます。この例では、<repo:tag>形式が使用されています。イメージ参照名はユースケースに固有です。
次のコマンドを実行して Containerfile をビルドします。
$ sudo podman build -t $IMAGE_REF1 - 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オプション: 次のコマンドを実行して、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カスタムリソース-
ServingRuntimeCR は、AI モデル形式を動的にロードおよびアンロードできる Pod のテンプレートを定義し、API を介してモデルをクエリーするためのサービスエンドポイントを公開する YAML ファイルです。各ServingRuntimeCR には、ランタイムのコンテナーイメージや、モデルサービングランタイムがサポートするモデル形式のリストなど、AI モデルの実行に必要な情報が含まれています。モデルサービングランタイムのその他の設定は、コンテナー仕様で定義された環境変数を使用して設定できます。 InferenceServiceカスタムリソース-
InferenceServiceCR は、推論クエリーを処理し、それをモデルに渡して、推論出力を返すサーバーまたは推論サービスを作成する YAML ファイルです。MicroShift では、出力は CLI で返されます。この推論サービス設定ファイルには、ハードウェアアクセラレーターの指定など、他の多くのオプションも含めることができます。
MicroShift はシングルノードの Kubernetes ディストリビューションであるため、マルチモデルのデプロイメントをサポートしません。シングルモデルサービングプラットフォームを使用する必要があります。MicroShift の各デプロイメントでは、1 つの AI モデルを使用できますが、複数のモデルランタイムを使用する可能性もあります。
- モデルサービングランタイムを設定するためのワークフロー
- AI モデルの形式をサポートするモデルサービングランタイムを選択します。
-
ワークロード namespace に
ServingRuntimeCR を作成します。 -
MicroShift ノードがすでに実行されている場合は、必要な
ServingRuntimeCR をファイルにエクスポートして編集できます。 -
MicroShift ノードが実行されていない場合、またはマニフェストを手動で準備する場合は、
microshift-ai-model-servingRPM の一部であるディスク上の元の定義を使用できます。 -
ワークロード namespace に
InferenceServiceCR を作成します。
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-servingRPM とmicroshift-ai-model-serving-release-infoRPM の両方がインストールされている。 - マシンへの root ユーザーアクセス権がある。
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、MicroShift リリース情報ファイルから、使用する
ServingRuntimeCR のイメージ参照を抽出します。$ 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 モデルサービングランタイムのイメージ参照が抽出されます。
次のコマンドを実行して、元の
ServingRuntimeYAML ファイルをコピーします。$ cp /usr/lib/microshift/manifests.d/050-microshift-ai-model-serving-runtimes/ovms-kserve.yaml ./ovms-kserve.yaml次のコマンドを実行して、
ServingRuntimeYAML のimage:パラメーターフィールド値に実際のイメージ参照を追加します。$ sed -i "s,image: ovms-image,image: ${OVMS_IMAGE}," ./ovms-kserve.yaml次のコマンドを実行し、YAML ファイルを使用してカスタム namespace に
ServingRuntimeオブジェクトを作成します。$ oc create -n <ai_demo> -f ./ovms-kserve.yaml1 - 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 を使用します。
前提条件
-
ServingRuntimesCR を設定している。 - マシンへの root ユーザーアクセス権がある。
-
OpenShift CLI (
oc) がインストールされている。
手順
InferenceServiceCR を作成します。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:NCHW1 - 1
- OpenVINO Model Server (OVMS) が、モデルが元々エクスポートされたレイアウトとは異なるレイアウトで、要求入力データを受け入れるようにするための追加の引数。追加の引数は OVMS コンテナーに渡されます。
InferenceServiceの例をファイルに保存してから、次のコマンドを実行してクラスター上に作成します。$ oc create -n <ai_demo> -f ./FILE.yaml1 - 1
- <ai_demo> は、namespace 名に置き換えます。
出力例
inferenceservice.serving.kserve.io/ovms-resnet50 created注記デプロイメントと Pod は、指定された namespace に表示されることが予想されます。
ServingRuntimeCR で指定されたイメージのサイズと ModelCar OCI イメージのサイズによっては、Pod の準備が完了するまでに数分かかる場合があります。
次のステップ
- モデルサービングランタイムの準備ができていることを確認します。
1.8.1. Open Telemetry を使用してモデルサーバーメトリクスをエクスポートする リンクのコピーリンクがクリップボードにコピーされました!
MicroShift 用の microshift-observability RPM をインストールした場合は、Open Telemetry を使用してモデルサーバーメトリクスをエクスポートできます。
または、/metrics エンドポイントでリクエストすることで、モデルサーバーの Prometheus 形式のメトリクスを取得することもできます。詳細は、「モデルサーバーのメトリクスを取得する」を参照してください。
前提条件
-
ServingRuntimesCR を設定している。 - マシンへの root ユーザーアクセス権がある。
-
OpenShift CLI (
oc) がインストールされている。 -
microshift-observabilityRPM をインストールしている。 - 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. モデルサービングランタイムの準備ができていることを確認する リンクのコピーリンクがクリップボードにコピーされました!
ダウンストリームの生成アクティビティーが完了していることを確認し、モデルサービングランタイムが使用できる状態であることを確認します。
前提条件
-
ServingRuntimesCR を設定している。 -
InferenceServiceCR を作成している。 - マシンへの root ユーザーアクセス権がある。
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、AI モデルがカスタム namespace にデプロイされていることを確認します。
$ oc get -n ai-demo deployment出力例
NAME READY UP-TO-DATE AVAILABLE AGE ovms-resnet50-predictor 1/1 1 1 72s次のコマンドを実行して、デプロイメントが進行中であることを確認します。
$ oc rollout status -n ai-demo deployment ovms-resnet50-predictor出力例
deployment "ovms-resnet50-predictor" successfully rolled out次のコマンドを実行して、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次のコマンドを実行して、作成されたサービス 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オブジェクトを作成します。
関連情報
- InferenceService (Red Hat OpenShift AI ドキュメント)
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) がインストールされている。
手順
次のコマンド例に示すように、MicroShift ノードの IP アドレスを取得し、それを
IP変数に割り当てます。$ IP=$(oc get nodes -o json | jq -r '.items[0].status.addresses[0].address')次のコマンドを実行して、作成したルートの名前を特定します。
$ oc get route -n ai-test <route_name> -o yaml1 - 1
<route_name>は、実際のルートの名前に置き換えます。
次のコマンドを実行して、ルートの
HOST値を抽出し、DOMAIN変数に割り当てます。DOMAIN=$(oc get route -n ai-test <route_name> -o=jsonpath="{ .status.ingress[0].host }")1 - 1
<route_name>は、実際のルートの名前に置き換えます。
次のコマンドを実行して、ルートから 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次のコマンドを実行して、モデルのメタデータをクエリーします。
$ 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 にアップロードしている。
手順
次のコマンドを実行して、OpenVINO Model Server の例からハチのイメージをダウンロードします。
$ curl -O https://raw.githubusercontent.com/openvinotoolkit/model_server/main/demos/common/static/images/bee.jpeg次のスクリプトを実行して、リクエストデータを作成します。
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 header1 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.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.jsonresponse.jsonに保存された推論出力の例{ "model_name": "ovms-resnet50", "model_version": "1", "outputs": [{ "name": "1463", "shape": [1, 1000], "datatype": "FP32", "data": [ ....... ]1 }] }- 1
- 簡潔にするために、
.outputs[0].dataの内容は例では省略されています。
検証
モデルの予測を決定するには、次の 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)出力例
3091 - 1
- この例では、
309というラベルの付いた要素がモデルの応答です。
出力を 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
-
redhat-ods-applicationsnamespace にある既存のConfigMapファイルinferenceservice-configのコピーを作成します。 - 変更したい設定を編集します。
-
既存の
ConfigMapオブジェクトを上書きします。 -
Pod を削除するか、
DeploymentPod パラメーターを0にスケールダウンしてから1に戻すことで、KServe を再起動します。
-
- オプション 2
-
ConfigMapファイル/usr/lib/microshift/manifests.d/010-microshift-ai-model-serving-kserve/inferenceservice-config-microshift-patch.yamlをコピーします。 - 変更したい設定を編集します。
-
ConfigMapオブジェクトを適用します。 -
Pod を削除するか、
DeploymentPod パラメーターを0にスケールダウンしてから1に戻すことで、KServe を再起動します。
-
- RHEL for Edge および Image Mode for RHEL の場合
-
redhat-ods-applicationsnamespace の/usr/lib/microshift/manifests.d/010-microshift-ai-model-serving-kserve/inferenceservice-config-microshift-patch.yamlまたはinferenceservice-configファイルのいずれかに基づいて、ConfigMapファイルを使用して新しいマニフェストを作成します。 -
新しいマニフェストが
/usr/lib/microshift/manifests.d/ディレクトリーに配置されていることを確認します。マニフェストが/usr/lib/microshift/manifests.d/010-microshift-ai-model-serving-kserve/ディレクトリーの内容の後に適用されるように、接頭辞011で開始することを推奨します。
-