第7章既知の問題

このセクションでは、Red Hat OpenShift AI の既知の問題と、これらの問題を回避する既知の方法を説明します。

RHOAIENG-35623 - ハードウェアプロファイルを使用するとモデルのデプロイメントが失敗します

Red Hat OpenShift AI Operator は、手動での InferenceService リソース作成時に、ハードウェアプロファイルから tolerations、nodeSelector、または identifiers を基礎となる InferenceService に注入しません。そのため、ハードウェアプロファイルを使用するモデルのデプロイメントは失敗します。その結果、モデルデプロイメント Pod を適切なノードにスケジュールすることができず、デプロイメントが準備完了状態になりません。同じハードウェアプロファイルを使用するワークベンチは、引き続き正常にデプロイされます。

回避策: ナレッジベースソリューション Workaround for model deployment failure when using hardware profiles で説明されているように、スクリプトを実行して、tolerations、nodeSelector、または identifiers をハードウェアプロファイルから基礎となる InferenceService に注入します。

RHOAIENG-33995 - Phi および Mistral モデルの推論サービスのデプロイメントが失敗する

{openshift-platform-url} 4.19 を搭載した IBM Power クラスターで vLLM ランタイムを使用して Phi および Mistral モデルの推論サービスを作成すると、CPU バックエンドに関連するエラーが原因で失敗します。その結果、これらのモデルのデプロイメントが影響を受け、推論サービスの作成が失敗します。

回避策: この問題を解決するには、CPU および Phi モデルに対して有効になっている場合は、サービスランタイムで sliding_window メカニズムを無効にします。スライディングウィンドウは現在 V1 ではサポートされていません。

RHOAIENG-33914 - LM-Eval Tier2 タスクテストに失敗する

古いバージョンの trustyai-service-operator を使用している場合、Massive Multitask Language Understanding Symbol Replacement (MMLUSR) タスクが壊れているため、LM-Eval Tier2 タスクテストで失敗する可能性があります。

回避策: trustyai-service-operator の最新バージョンがインストールされていることを確認します。

RHOAIENG-33795 - IBM Z 上の Triton Inference Server の gRPC エンドポイント検証には手動 Route 作成が必要である

gRPC エンドポイントを使用して Triton Inference Server を検証する場合、Route が自動的に作成されません。これは、Operator が現在、デフォルトで REST のみのエッジ終了ルートを作成するために発生します。

回避策

この問題を解決するには、IBM Z 上の Triton Inference Server の gRPC エンドポイント検証用に手動でルートを作成する必要があります。

モデルデプロイメント Pod が起動して実行されている場合、次の内容を含む YAML ファイルでエッジ終了 Route オブジェクトを定義します。

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: <grpc-route-name>                  # e.g. triton-grpc
  namespace: <model-deployment-namespace>  # namespace where your model is deployed
  labels:
    inferenceservice-name: <inference-service-name>
  annotations:
    haproxy.router.openshift.io/timeout: 30s
spec:
  host: <custom-hostname>                  # e.g. triton-grpc.<apps-domain>
  to:
    kind: Service
    name: <service-name>                   # name of the predictor service (e.g. triton-predictor)
    weight: 100
  port:
    targetPort: grpc                       # must match the gRPC port exposed by the service
  tls:
    termination: edge
  wildcardPolicy: None

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: <grpc-route-name>                  # e.g. triton-grpc
  namespace: <model-deployment-namespace>  # namespace where your model is deployed
  labels:
    inferenceservice-name: <inference-service-name>
  annotations:
    haproxy.router.openshift.io/timeout: 30s
spec:
  host: <custom-hostname>                  # e.g. triton-grpc.<apps-domain>
  to:
    kind: Service
    name: <service-name>                   # name of the predictor service (e.g. triton-predictor)
    weight: 100
  port:
    targetPort: grpc                       # must match the gRPC port exposed by the service
  tls:
    termination: edge
  wildcardPolicy: None

Copy to Clipboard

Toggle word wrap

Route オブジェクトを作成します。
```
oc apply -f <route-file-name>.yaml
```
```
oc apply -f <route-file-name>.yaml
```
Copy to Clipboard Toggle word wrap

推論要求を送信するには、次のコマンドを入力します。

grpcurl -cacert <ca_cert_file>\ 
  -protoset triton_desc.pb \
  -d '{
    "model_name": "<model_name>",
    "inputs": [
      {
        "name": "<input_tensor_name>",
        "shape": [<shape>],
        "datatype": "<data_type>",
        "contents": {
          "<datatype_specific_contents>": [<input_data_values>]
        }
      }
    ],
    "outputs": [
      {
        "name": "<output_tensor_name>"
      }
    ]
  }' \
  <grpc_route_host>:443 \
  inference.GRPCInferenceService/ModelInfer

grpcurl -cacert <ca_cert_file>\


  -protoset triton_desc.pb \
  -d '{
    "model_name": "<model_name>",
    "inputs": [
      {
        "name": "<input_tensor_name>",
        "shape": [<shape>],
        "datatype": "<data_type>",
        "contents": {
          "<datatype_specific_contents>": [<input_data_values>]
        }
      }
    ],
    "outputs": [
      {
        "name": "<output_tensor_name>"
      }
    ]
  }' \
  <grpc_route_host>:443 \
  inference.GRPCInferenceService/ModelInfer

Copy to Clipboard

Toggle word wrap

1: <ca_cert_file> は、クラスタールーターの CA 証明書へのパスです (例: router-ca.crt)。

注記

<triton_protoset_file> は protobuf 記述子ファイルとしてコンパイルされます。protoc -I. --descriptor_set_out=triton_desc.pb --include_imports grpc_service.proto として生成できます。

triton-inference-service GitHub ページから grpc_service.proto および model_config.proto ファイルをダウンロードします。

RHOAIENG-33697 - ステータスが "Started" でない限り、モデルを編集または削除できない

NVIDIA NIM または単一モデルサービングプラットフォームにモデルをデプロイする場合、Starting または Pending 状態のモデルではアクションメニューの Edit および Delete オプションは使用できません。これらのオプションは、モデルが正常にデプロイされた後にのみ使用可能になります。

回避策: モデルを変更したり削除したりするには、モデルが Started 状態になるまで待機します。

RHOAIENG-33645 - LM-Eval Tier1 テストに失敗する

古いバージョンの trustyai-service-operator を使用している場合、ジョブの実行時に confirm_run_unsafe_code が引数として渡されないため、LM-Eval Tier1 テストが失敗する可能性があります。

回避策: 最新バージョンの trustyai-service-operator を使用しており、AllowCodeExecution が有効になっていることを確認してください。

RHOAIENG-32942 - パイプラインストアが Kubernetes に設定されている場合、Elyra パイプラインが失敗する

パイプラインストアが Kubernetes を使用するように設定されている場合、Elyra では REST API でサポートされていない等価 (eq) フィルターが必要になります。このモードでは、サブ文字列フィルターのみがサポートされます。その結果、ワークベンチから Elyra を介して作成および送信されたパイプラインは正常に実行されません。次のエラーが発生し、送信が失敗します。

Invalid input error: Filter eq is not implemented for Kubernetes pipeline store.

Invalid input error: Filter eq is not implemented for Kubernetes pipeline store.

Copy to Clipboard

Toggle word wrap

回避策

パイプラインを保存するために Kubernetes ではなくデータベースを使用するようにパイプラインサーバーを設定します。

パイプラインサーバーを作成するときは、パイプラインストアを database に設定します。
サーバーがすでに作成されている場合は、.spec.pipelineStore を database に設定して、DataSciencePipelinesApplication カスタムリソースを更新します。これにより、dspa Pod が再作成されます。

パイプラインストアを database に切り替えると、Elyra パイプラインをワークベンチから正常に送信できるようになります。

RHOAIENG-32897 - Kubernetes API で定義されたパイプラインと無効な platformSpec が UI に表示されないか実行されない

Kubernetes API で定義されたパイプラインバージョンに、空または無効な spec.platformSpec フィールド (たとえば、{} または kubernetes キーなし) が含まれている場合、システムはそのフィールドをパイプライン仕様として誤って識別します。その結果、REST API は pipelineSpec を省略するため、パイプラインのバージョンが UI に表示されなくなり、実行されなくなります。

回避策: PipelineVersion オブジェクトから spec.platformSpec フィールドを削除します。フィールドを削除すると、パイプラインバージョンが UI に正しく表示され、REST API は期待どおりに pipelineSpec を返します。

RHOAIENG-31386 - authenticationRef を使用した推論サービスのデプロイ中にエラーが発生する

外部メトリクスで authenticationRef を使用して InferenceService をデプロイすると、最初の oc の適用後に authenticationRef フィールドが削除されます。

回避策: フィールドを保持するには、リソースを再適用します。

RHOAIENG-30493 - Kueue 対応プロジェクトでワークベンチを作成するときにエラーが発生する

ダッシュボードを使用して Kueue 対応プロジェクトでワークベンチを作成する場合、クラスターで Kueue が無効になっているか、選択したハードウェアプロファイルが LocalQueue に関連付けられていない場合は、作成に失敗します。この場合、必要な LocalQueue を参照できず、アドミッション Webhook の検証が失敗し、次のエラーメッセージが表示されます。

Error creating workbench
admission webhook "kubeflow-kueuelabels-validator.opendatahub.io" denied the request: Kueue label validation failed: missing required label "kueue.x-k8s.io/queue-name"

Error creating workbench
admission webhook "kubeflow-kueuelabels-validator.opendatahub.io" denied the request: Kueue label validation failed: missing required label "kueue.x-k8s.io/queue-name"

Copy to Clipboard

Toggle word wrap

回避策

cluster-admin 権限を持つユーザーとして、クラスター上で Kueue とハードウェアプロファイルを有効にします。

oc クライアントを使用して、クラスターにログインします。
次のコマンドを実行して、redhat-ods-applications namespace の OdhDashboardConfig カスタムリソースにパッチを適用します。

oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"disableKueue": false, "disableHardwareProfiles": false}}}'

oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"disableKueue": false, "disableHardwareProfiles": false}}}'

Copy to Clipboard

Toggle word wrap

RHOAIENG-31238 - DSCInitialization の作成時に新しい監視スタックが有効になった

DSCInitialization リソースを削除し、OpenShift AI コンソールフォームビューを使用して新しいリソースを作成すると、テクノロジープレビューの可観測性スタックが有効になります。その結果、DSCInitialization リソースを再作成するときに、不要な可観測性スタックがデプロイメントされることになります。

回避策

この問題を解決するには、フォームビューを使用して DSCInitiliazation リソースを再作成するときに、"metrics" と "traces" フィールドを手動で削除します。

テクノロジープレビューの監視スタックを使用する場合、これは必要ありません。

RHOAIENG-32145 - OpenShift バージョン 4.17 より前のバージョンで Llama Stack Operator のデプロイメントに失敗する

4.17 より前のバージョンを実行している OpenShift クラスターに OpenShift AI をインストールすると、統合された Llama Stack Operator (llamastackoperator) のデプロイに失敗する可能性があります。

Llama Stack Operator には Kubernetes バージョン 1.32 以降が必要ですが、OpenShift 4.15 では Kubernetes 1.28 が使用されます。このバージョンの違いにより、Kubernetes 1.32 で導入され、未対応の選択肢付きフィールドが原因で、LlamaStackDistribution カスタムリソース定義 (CRD) を適用するときにスキーマ検証が失敗する可能性があります。

回避策: バージョン 4.17 以降を実行している OpenShift クラスターに OpenShift AI をインストールします。

RHOAIENG-32242 - OpenShift バージョン 4.15 および 4.16 の NetworkPolicies の作成に失敗する

バージョン 4.15 または 4.16 を実行している OpenShift クラスターに OpenShift AI をインストールすると、特定の NetworkPolicy リソースのデプロイメントが失敗する可能性があります。これは、llamastackoperator または関連コンポーネントが redhat-ods-applications などの保護された namespace に NetworkPolicy を作成しようとしたときに発生する可能性があります。このリクエストは、アドミッション webhook networkpolicies-validation.managed.openshift.io によってブロックされる可能性があります。これにより、cluster-admin ユーザーであっても、特定の namespace とリソースへの変更が制限されます。この制限は、self-managed 環境と Red Hat 管理の OpenShift 環境の両方に適用されます。

回避策: バージョン 4.17 以降を実行している OpenShift クラスターに OpenShift AI をデプロイします。webhook の制限が適用されているクラスターの場合は、OpenShift 管理者または Red Hat サポートに連絡して、代わりのデプロイメントパターン、または影響を受ける namespace に対して承認されている変更が何かを判断してください。

RHOAIENG-32599 - IBM Z クラスターで推論サービスの作成が失敗する

IBM Z クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、ValueError: 'aimv2' is already used by a Transformers config, pick another name エラーが発生して失敗します。

回避策: なし。

RHOAIENG-29731 - OpenShift 4.19 を使用した IBM Power クラスターで推論サービスの作成が失敗する

OpenShift Container Platform バージョン 4.19 上の IBM Power クラスターで vLLM ランタイムを使用して推論サービスを作成しようとすると、Non-Uniform Memory Access (NUMA) に関連するエラーが原因で失敗します。

回避策: 推論サービスを作成するときに、環境変数 VLLM_CPU_OMP_THREADS_BIND を all に設定します。

RHOAIENG-29292 - IBM Z 上で、使用状況統計ディレクトリーへのアクセスが原因で、vLLM が権限エラーをログに記録する

IBM Z アーキテクチャーで vLLM を実行すると、推論サービスは正常に起動しますが、使用状況統計レポートに関連するバックグラウンドスレッドにエラーが記録されます。これは、サービスがアクセス権限のない制限された場所 (/.config) に使用状況データを書き込もうとするために発生します。

以下のエラーがログに記録されます。

Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
 ...
PermissionError: [Error 13] Permission denied: '/.config'

Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
 ...
PermissionError: [Error 13] Permission denied: '/.config'

Copy to Clipboard

Toggle word wrap

回避策: このエラーを防止し、使用状況統計のロギングを抑制するには、推論サービスのデプロイメントで VLLM_NO_USAGE_STATS=1 環境変数を設定します。これにより、使用状況の自動レポートが無効になり、システムディレクトリーへの書き込み時に権限の問題が発生するのを回避できます。

RHOAIENG-28910 - 2.16 から 2.19 以降にアップグレードすると、Unmanaged 状態の KServe リソースが削除される

OpenShift AI 2.16 から 1 へのアップグレード中に、関連する KServe 関連リソースから所有者参照が完全に削除される前に、FeatureTracker カスタムリソース (CR) が削除されます。その結果、Red Hat OpenShift AI Operator によって最初に Managed 状態で作成され、その後 DataScienceCluster (DSC) カスタムリソース (CR) で Unmanaged に変更されたリソースが、意図せず削除される可能性があります。この問題により、リソースが手動で復元されるまでモデルサービング機能が停止する可能性があります。

次のリソースは、2.16 で Unmanaged に変更された場合、1 で削除される可能性があります。

Expand

種類	namespace	名前
`KnativeServing`	`knative-serving`	`knative-serving`
`ServiceMeshMember`	`knative-serving`	`default`
`Gateway`	`istio-system`	`kserve-local-gateway`
`Gateway`	`knative-serving`	`knative-ingress-gateway`
`Gateway`	`knative-serving`	`knative-local-gateway`

回避策

OpenShift AI 2.16 から 1 にすでにアップグレード済みの場合は、次のいずれかの操作を実行してください。

既存のバックアップがある場合は、FeatureTracker CR への所有者参照なしで削除されたリソースを手動で再作成します。
既存のバックアップがない場合は、Operator を使用して、削除されたリソースを再作成できます。
1. 再作成済みのリソースをバックアップします。
2. DSC で、spec.components.kserve.serving.managementState を Managed に設定し、変更を保存して、Operator がリソースを再作成できるようにします。
  Operator がリソースを再作成するまで待機します。
3. DSC で、spec.components.kserve.serving.managementState を Unmanaged に戻し、変更を保存します。
4. 再作成された KnativeServing、ServiceMeshMember、および Gateway CR リソースに以前のカスタムの変更を再適用します。

まだアップグレードしていない場合は、この問題を防ぐために、アップグレードする前に次の操作を実行してください。

DSC で、spec.components.kserve.serving.managementState を Unmanaged に設定します。
上記の表にリストされている影響を受ける KnativeServing、ServiceMeshMember、および Gateway リソースごとに、FeatureTracker の所有者参照を削除して CR を編集します。この編集により、FeatureTracker に対するリソースの依存関係が削除され、アップグレードプロセス中にリソースが削除されなくなります。

RHOAIENG-24545 - 初回の起動後にランタイムイメージがワークベンチに存在しない

ランタイムイメージのリストには、namespace で最初に実行されているワークベンチインスタンスが適切に入力されないため、Elyra パイプラインエディターで選択できるイメージが表示されません。

回避策: ワークベンチを再起動します。ワークベンチを再起動すると、ランタイムイメージのリストがワークベンチと Elyra パイプラインエディターの選択ボックスの両方に表示されます。

RHOAIENG-25090 - モデル登録オプションが無効になっていると、InstructLab の prerequisites-check-op タスクが失敗する

Add model to <model registry name> チェックボックスを選択せずに LAB-tuning 実行を開始すると、InstructLab パイプラインは開始されますが、prerequisites-check-op タスクは失敗し、Pod ログに次のエラーが記録されます。

failed: failed to resolve inputs: the resolved input parameter is null: output_model_name

failed: failed to resolve inputs: the resolved input parameter is null: output_model_name

Copy to Clipboard

Toggle word wrap

回避策: LAB-tuning 実行を設定するときに Add model to <model registry name> チェックボックスをオンにします。

RHOAIENG-20209 - 要求されたリソースがしきい値を超えても警告メッセージが表示されない

Distributed workloads Project metrics をクリックし、Requested resources セクションを表示すると、チャートには要求されたリソースの値と各リソースの合計共有クォータ値 (CPU および メモリー) が表示されます。ただし、Requested by all projects の値が、そのリソースの Warning threshold の値を超えると、予想される警告メッセージは表示されません。

回避策: なし。

SRVKS-1301 (以前は RHOAIENG-18590 として文書化されていました) - KServe を無効化にしてから有効化すると、KnativeServing リソースが失敗する

DataScienceCluster で kserve コンポーネントを無効にしてから有効にすると、KnativeServing リソースが失敗する可能性があります。

回避策

Knative に関連するすべての ValidatingWebhookConfiguration および MutatingWebhookConfiguration Webhook を削除します。

Webhook を取得します。

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

Copy to Clipboard

Toggle word wrap

KServe が無効になっていることを確認します。

Webhook を取得します。

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative

Copy to Clipboard

Toggle word wrap

Webhook を削除します。
KServe を有効にします。
KServe Pod が正常に生成され、knative-serving namespace 内の Pod がアクティブで動作していることを確認します。

RHOAIENG-16247 - OpenShift AI ダッシュボードから実行を開始すると、Elyra パイプラインの実行出力が上書きされる

Elyra からパイプラインを作成して実行すると、パイプラインの実行によって生成された出力が、オブジェクトストレージのフォルダー bucket-name/pipeline-name-timestamp に保存されます。

Elyra からパイプラインを作成し、OpenShift AI ダッシュボードからパイプラインの実行を開始すると、タイムスタンプ値が更新されません。これにより、パイプラインの実行によって、同じパイプラインの以前のパイプライン実行によって作成されたファイルが上書きされる可能性があります。

この問題は、OpenShift AI ダッシュボードを使用してコンパイルおよびインポートされたパイプラインには影響しません。これは、オブジェクトストレージで使用されるフォルダーに runid が常に追加されるためです。データサイエンスパイプラインで使用されるストレージの場所の詳細は、データサイエンスパイプラインのデータの保存を参照してください。

回避策: Elyra パイプラインにファイルを保存する場合は、パイプライン実行ごとに異なるサブフォルダー名を使用します。

RHOAIENG-8294 - OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードするときに CodeFlare エラーが発生する

OpenShift AI 2.8 をバージョン 2.10 以降にアップグレードしようとすると、AppWrapper カスタムリソース定義 (CRD) バージョンとの不一致により、CodeFlare コンポーネントに関する次のエラーメッセージが表示されます。

ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions

ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions

Copy to Clipboard

Toggle word wrap

回避策

既存の AppWrapper CRD を削除します。
```
oc delete crd appwrappers.workload.codeflare.dev
```
```
$ oc delete crd appwrappers.workload.codeflare.dev
```
Copy to Clipboard Toggle word wrap

約 20 秒待ってから、次の例に示すように、新しい AppWrapper CRD が自動的に適用されることを確認します。

oc get crd appwrappers.workload.codeflare.dev

$ oc get crd appwrappers.workload.codeflare.dev
NAME                                 CREATED AT
appwrappers.workload.codeflare.dev   2024-11-22T18:35:04Z

Copy to Clipboard

Toggle word wrap

RHOAIENG-7716 - パイプライン条件グループのステータスが更新されない

ループ (dsl.ParallelFor) または条件グループ (dsl.lf) を含むパイプラインを実行すると、パイプラインの実行が完了した後でも、UI にループとグループの実行ステータスが表示されます。

回避策

アクティブな子タスクがないことを確認することで、パイプラインがまだ実行中かどうかを確認できます。

OpenShift AI ダッシュボードから、Data Science Pipelines Runs をクリックします。
Project リストから、データサイエンスプロジェクトをクリックします。
Runs タブから、ステータスを確認する必要があるパイプライン実行をクリックします。
条件グループを展開し、子タスクをクリックします。
子タスクに関する情報を含むパネルが表示されます。
パネルで、Task 詳細タブをクリックします。
Status フィールドに、子タスクの正しいステータスが表示されます。

RHOAIENG-6409 - 実行が成功しても、パイプラインログに Cannot save parameter というエラーが表示される

Data Science Pipelines 2.0 を使用してパイプラインを複数回実行すると、パイプラインの実行が成功してもパイプラインログに Cannot save parameter エラーが表示されます。これらのエラーは無視しても問題ありません。

回避策: なし。

RHOAIENG-12294 (以前は RHOAIENG-4812 として文書化されていました) - 分散ワークロードメトリクスから GPU メトリクスが除外される

この OpenShift AI リリースでは、分散ワークロードメトリクスから GPU メトリクスが除外されます。

回避策: なし。

RHOAIENG-4570 - 既存の Argo Workflows インストールがインストールまたはアップグレードと競合する

Data Science Pipelines 2.0 には、Argo Workflows のインストールが含まれています。Red Hat では、Argo Workflows に含まれるこのインスタンスを直接使用することはサポートしていません。Data Science Pipelines 2.0 を備えた OpenShift AI をインストールまたはアップグレードするには、クラスターに Argo Workflows がインストールされていないことを確認してください。詳細は、Data Science Pipelines 2.0 への移行を参照してください。

回避策: 既存の Argo Workflows インストールを削除するか、datasciencepipelines を Removed に設定してから、インストールまたはアップグレードを続行します。

RHOAIENG-3025 - OVMS が要求するディレクトリーレイアウトが KServe StoragePuller レイアウトと競合する

OpenVINO Model Server (OVMS) ランタイムを使用してシングルモデルサービングプラットフォーム (KServe を使用) にモデルをデプロイすると、OVMS が要求するディレクトリーレイアウトと KServe で使用されるモデル取得ロジックのレイアウトの間に不一致が生じます。具体的には、OVMS はモデルファイルを /<mnt>/models/1/ ディレクトリーに配置することを要求しますが、KServe はモデルファイルを /<mnt>/models/ ディレクトリーに配置します。

回避策

次の操作を実行します。

S3 互換ストレージバケットで、モデルファイルを 1/ というディレクトリーに置きます (例: /<s3_storage_bucket>/models/1/<model_files>)。
OVMS ランタイムを使用してシングルモデルサービングプラットフォームにモデルをデプロイするには、次のいずれかの方法を選択して、モデルファイルへのパスを指定します。
- OpenShift AI ダッシュボードを使用してモデルをデプロイする場合は、データ接続の Path フィールドで、/<s3_storage_bucket>/models/ 形式を使用してモデルファイルへのパスを指定します。パスの一部として 1/ ディレクトリーを指定しないでください。
- 独自の InferenceService カスタムリソースを作成してモデルをデプロイする場合は、storageURI フィールドの値を /<s3_storage_bucket>/models/ に設定します。パスの一部として 1/ ディレクトリーを指定しないでください。

KServe は、指定したパスのサブディレクトリーからモデルファイルを取得します。この場合、KServe は S3 互換ストレージの /<s3_storage_bucket>/models/1/ ディレクトリーからモデルファイルを正しく取得します。

RHOAIENG-3018 - KServe 上の OVMS がダッシュボードに正しいエンドポイントを公開しない

OpenVINO Model Server (OVMS) ランタイムを使用してシングルモデルサービングプラットフォームにモデルをデプロイした場合、デプロイしたモデルの Inference endpoint フィールドに表示される URL が不完全なものになります。

回避策: モデルにクエリーを送信するには、URL の末尾に /v2/models/_<model-name>_/infer 文字列を追加する必要があります。_<model-name>_ は、デプロイしたモデルの名前に置き換えてください。

RHOAIENG-2602 - ModelMesh Pod の再起動により、"平均応答時間" のサーバーメトリクスグラフに複数の行が表示される

ModelMesh Pod が再起動されると、平均応答時間 のサーバーメトリクスグラフに複数の行が表示されます。

回避策: なし。

RHOAIENG-2228 - 間隔が 15 秒に設定されている場合、パフォーマンスメトリクスグラフが絶えず変化する

モデルメトリクス画面の Endpoint performance タブで、Refresh interval を 15 秒に、Time range を 1 時間に設定すると、グラフの結果は連続的に変化します。

回避策: なし。

RHOAIENG-2183 - エンドポイントのパフォーマンスグラフに間違ったラベルが表示される場合がある

モデルメトリクス画面の Endpoint performance タブで、グラフツールチップに誤ったラベルが表示される場合があります。

回避策: なし。

RHOAIENG-131 - InferenceService が Loaded と報告した後、gRPC エンドポイントが適切に応答しない

多数の InferenceService インスタンスが生成され、リクエストがダイレクトされると、Service Mesh Control Plane (SMCP) が応答しなくなります。InferenceService インスタンスのステータスは Loaded ですが、gRPC エンドポイントへの呼び出しはエラーとともに返されます。

回避策: ServiceMeshControlPlane カスタムリソース (CR) を編集して、Istio Egress Pod と Ingress Pod のメモリー制限を増やします。

RHOAIENG-1619 (以前は DATA-SCIENCE-PIPELINES-165 として記録されていた問題) - S3 バケットが書き込み可能でない場合の不適切なエラーメッセージ

データ接続を設定し、S3 バケットが書き込み可能でない場合にパイプラインをアップロードしようとすると、Failed to store pipelines というエラーメッセージが表示されますが、有用ではありません。

回避策: データ接続の認証情報が正しいこと、および指定したバケットへの書き込みアクセス権があることを確認してください。

RHOAIENG-1207 (以前は ODH-DASHBOARD-1758 として記録されていた問題) - OOTB カスタムサービングランタイムを数回複製するときにエラーが発生する

モデルサービングランタイムを複数回複製すると、複製が失敗し、Serving runtime name "<name>" already exists というエラーメッセージが表示されます。

回避策: metadata.name フィールドを一意の値に変更します。

RHOAIENG-133 - 既存のワークベンチは、ワークベンチの再起動後に Elyra パイプラインを実行できない

Elyra JupyterLab エクステンションを使用して JupyterLab 内でデータサイエンスパイプラインを作成および実行し、ワークベンチを作成してワークベンチ内でワークベンチイメージを指定した後にパイプラインサーバーを設定すると、ワークベンチを再起動した後でもパイプラインを実行できません。

回避策

実行中のワークベンチを停止します。
ワークベンチを編集して小さな変更を加えます。たとえば、新しいダミー環境変数を追加したり、既存の不要な環境変数を削除したりします。変更を保存します。
ワークベンチを再起動します。
JupyterLab の左側のサイドバーで、Runtimes をクリックします。
デフォルトのランタイムが選択されていることを確認します。

RHODS-12798 - Pod が "unable to init seccomp" エラーで失敗する

seccomp メモリーリークを引き起こす既知のカーネルバグが原因で、Pod は Running のステータスではなく CreateContainerError ステータスまたは Pending ステータスで失敗します。Pod が失敗した namespace でイベントをチェックするか、oc describe pod コマンドを実行すると、以下のエラーが表示されます。

runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524

runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524

Copy to Clipboard

Toggle word wrap

回避策: Red Hat ナレッジベースのソリューション記事 Pods failing with error loading seccomp filter into kernel: errno 524 in OpenShift 4 の説明に従って、net.core.bpf_jit_limit の値を増やします。

KUBEFLOW-177 - OAuth-proxy で転送されないアプリケーションのベアラートークン

アプリケーションの内部認証メカニズムがベアラートークンに基づいている場合、アプリケーションをカスタムワークベンチイメージとして使用できません。OAuth プロキシー設定によりヘッダーからベアラートークンが削除されるため、アプリケーションは適切に動作できなくなります。

回避策: なし。

KUBEFLOW-157: OpenShift AI ダッシュボードからすでにログアウトしている場合、JupyterLab からのログアウトが機能しない

JupyterLab からログアウトする前に OpenShift AI ダッシュボードからログアウトすると、JupyterLab から正常にログアウトされません。たとえば、Jupyter ノートブックの URL がわかっている場合は、これをブラウザーで再度開くことができます。

回避策: OpenShift AI ダッシュボードからログアウトする前に、JupyterLab からログアウトします。

RHODS-7718 - ダッシュボード権限のないユーザーが実行中のワークベンチを無期限に使い続けることができる

Red Hat OpenShift AI 管理者がユーザーの権限を取り消しても、引き続きユーザーは実行中のワークベンチを無期限で使用できます。

回避策: OpenShift AI 管理者がユーザーの権限を取り消す場合、管理者はそのユーザーに対して実行中のワークベンチも停止する必要があります。

RHOAIENG-1152 (以前は RHODS-6356 として記録されていた問題) - ダッシュボードにログインしたことがないユーザーの basic-workbench 作成プロセスが失敗する

ダッシュボードの基本ワークベンチの Administration ページには、OpenShift のユーザーグループと管理者グループに属するユーザーが表示されます。ただし、管理者がダッシュボードにログインしたことのないユーザーに代わって基本ワークベンチを起動しようとすると、基本ワークベンチの作成プロセスは失敗し、次のエラーメッセージが表示されます。

Request invalid against a username that does not exist.

Request invalid against a username that does not exist.

Copy to Clipboard

Toggle word wrap

回避策: 該当するユーザーにダッシュボードへのログインを依頼します。

RHODS-5543: NVIDIA GPU Operator を使用すると、Node Autoscaler によって必要以上のノードが作成される

使用可能なリソースが不十分なために Pod をスケジュールできないと、Node Autoscaler は新しいノードを作成します。新しく作成されたノードが関連する GPU ワークロードを受け取るまで、遅延があります。したがって、Pod をスケジュールすることはできず、Node Autoscaler は、ノードの 1 つが GPU ワークロードを受け取る準備ができるまで、追加の新しいノードを継続的に作成します。この問題の詳細は、Red Hat ナレッジベースのソリューション記事 NVIDIA GPU Operator を使用すると、Node Autoscaler によって必要以上のノードが作成されるを参照してください。

回避策: machineset.spec.template.spec.metadata で cluster-api/accelerator ラベルを適用します。これにより、オートスケーラーは、GPU ドライバーがデプロイされるまで、これらのノードを準備ができていないと見なします。

RHODS-4799: Tensorboard を表示するには手動の手順が必要

TensorFlow または PyTorch ワークベンチイメージを使用しており、TensorBoard を使用してデータを表示する場合に、ワークベンチ環境に環境変数を追加して、独自のコードで使用する環境変数をインポートするといった手作業の手順が必要です。

回避策

基本ワークベンチを起動するときに、次のコードを使用して TENSORBOARD_PROXY_URL 環境変数の値を設定し、OpenShift AI ユーザー ID を使用します。

import os
os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"

import os
os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"

Copy to Clipboard

Toggle word wrap

RHODS-4718: Intel® oneAPI AI Analytics Toolkits のクイックスタートが、存在しないサンプルノートブックを参照している

ダッシュボードの Resources ページにある Intel® oneAPI AI アナリティクスツールキットクイックスタートでは、手順の一部としてサンプルノートブックをロードする必要がありますが、関連するリポジトリーに存在しないノートブックを参照しています。

回避策: なし。

RHODS-3984: ノートブックの選択時に誤ったパッケージバージョンが表示される

OpenShift AI インターフェイスで、Start a notebook server ページに、oneAPI AI Analytics Toolkit ノートブックイメージに含まれる JupyterLab パッケージおよび Notebook パッケージの誤ったバージョン番号が表示されます。このページには、このイメージが使用する Python バージョンの誤った値が表示される場合もあります。

回避策: oneAPI AI Analytics Toolkit ノートブックサーバーを起動するときに、ノートブックセルで !pip list コマンドを実行すると、ノートブックサーバーにインストールされている Python パッケージと、所有しているパッケージのバージョンを確認できます。

RHOAING-1147 (以前は RHODS-2881 として記録されていた問題) - ダッシュボード上のアクションが明確に表示されない

無効になったアプリケーションのライセンスを再検証し、無効になったアプリケーションのタイルを削除するダッシュボードアクションは、ユーザーには明確に表示されません。これらのアクションは、ユーザーがアプリケーションタイルの Disabled ラベルをクリックすると表示されます。その結果、意図したワークフローがユーザーにとって明確でない場合があります。

回避策: なし。

RHODS-2096 - IBM Watson Studio は OpenShift AI で利用できない

IBM Watson Studio は、OpenShift AI が OpenShift Dedicated 4.9 以降にインストールされている場合は使用できません。これは、OpenShift Dedicated のこれらのバージョンと互換性がないためです。

回避策: OpenShift Dedicated 4.9 以降で Watson Studio を手動で設定する方法は、Marketplace サポートにお問い合わせください。

RHODS-1888 - アンインストール後も OpenShift AI ハイパーリンクが表示される

OpenShift AI アドオンが OpenShift Dedicated クラスターからアンインストールされても、OpenShift AI インターフェイスへのリンクはアプリケーション起動メニューに表示されたままになります。OpenShift AI は利用できなくなっているため、このリンクをクリックすると "Page Not Found" エラーが発生します。

回避策: なし。

第7章既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第7章 既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第7章既知の問題