第8章 既知の問題
このセクションでは、Red Hat OpenShift AI 3.0 の既知の問題と、これらの問題を回避する既知の方法を説明します。
RHOAIENG-37228 - OpenStack およびプライベートクラウド環境では手動の DNS 設定が必要です
統合外部 DNS のない OpenStack、CodeReady Containers (CRC)、またはその他のプライベートクラウド環境に OpenShift AI 3.0 をデプロイすると、インストール後に、ダッシュボードやワークベンチなどのコンポーネントへの外部アクセスが失敗する可能性があります。これは、動的にプロビジョニングされた LoadBalancer Service が IP アドレスを外部 DNS に自動的に登録しないために発生します。
- 回避策
- アクセスを復元するには、外部 DNS システムに必要な A レコードまたは CNAME レコードを手動で作成します。手順については、ナレッジベースの記事 Configuring External DNS for RHOAI 3.x on OpenStack and Private Clouds を参照してください。
RHOAIENG-38658 - IBM Z (s390x) でのトークン認証によるモデル推論中の TrustyAI サービスで問題が発生します
IBM Z (s390x) アーキテクチャーでは、トークン認証が有効になっている場合、TrustyAI サービスでモデル推論中にエラーが発生します。TrustyAI サービスロガーへのログ記録中に JsonParseException が表示され、バイアス監視プロセスが失敗したり、予期しない動作をしたりします。
- 回避策
- 認証なしで TrustyAI サービスを実行します。この問題は、トークン認証が有効になっている場合にのみ発生します。
RHOAIENG-38333 - Generative AI Playground によって生成されたコードが無効であり、必要なパッケージがワークベンチにありません
Generative AI Playground によって自動的に生成されたコードは、OpenShift AI ワークベンチで実行すると構文エラーが発生する可能性があります。さらに、LlamaStackClient パッケージは現在、標準のワークベンチイメージには含まれていません。
RHOAIENG-38263 - IBM Z の Hugging Face ランタイムにおける Guardrails Detector モデルで断続的に障害が発生します
IBM Z プラットフォームでは、Hugging Face ランタイムで実行されている Guardrails Detector モデルが、同一のリクエストを処理できないことが断続的に発生することがあります。場合によっては、以前は有効な結果を返していたリクエストが、次の例のような解析エラーで失敗することがあります。
Invalid numeric literal at line 1, column 20
Invalid numeric literal at line 1, column 20
このエラーにより、サービング Pod が一時的に CrashLoopBackOff 状態になる可能性がありますが、通常は自動的に回復します。
- 回避策
- なし。Pod は自動的に再起動し、通常の動作を再開します。
RHOAIENG-38253 - Distributed Inference Server with llm-d が Serving Runtimes ページにリストされていません
モデルをデプロイするときに、Distributed Inference Server with llm-d は使用可能なオプションとして表示されますが、Settings セクションの Serving Runtimes ページには記載されていません。
これは、Distributed Inference Server with llm-d が、標準のサービスランタイムを超えた追加コンポーネントを含む複合デプロイメントタイプであるために発生します。したがって、管理者に表示されるサービングランタイムのリストには表示されず、現時点ではエンドユーザーから非表示にすることはできません。
- 回避策
- なし。Distributed Inference Server with llm-d オプションは、引き続きモデルのデプロイメントに使用できますが、Serving Runtimes ページから管理または表示することはできません。
RHOAIENG-38252 - Model Registry Operator は、OpenShift 4.20 の BYOIDC モードで動作しません
Bring Your Own Identity Provider (BYOIDC) モードで設定された OpenShift 4.20 クラスターでは、Model Registry Operator のデプロイが失敗します。
ModelRegistry カスタムリソースを作成しても、available: True 状態になりません。代わりに、リソースには次の例のようなステータスが表示されます。
- 回避策
- なし。
OpenShift 4.20 で BYOIDC モードを使用する場合、Model Registry インスタンスを作成またはデプロイすることはできません。
RHOAIENG-38180 - Feature Store サービスへの Workbench リクエストで証明書エラーが発生します
デフォルト設定を使用する場合、Feature Store (Feast) のデプロイメントに必要な証明書とサービスエンドポイントがありません。その結果、ワークベンチは Feast SDK を使用して Feature Store にリクエストを送信できなくなります。
- 回避策
-
既存の
FeatureStoreカスタムリソース (CR) を削除し、次の設定で新しい FeatureStore カスタムリソースを作成します。
registry:
local:
server:
restAPI: false
registry:
local:
server:
restAPI: false
Feature Store Pod の実行が開始されたら、同じ CR を編集して registry.local.server.restAPI: true を設定し、CR を削除せずに保存します。REST サービスと gRPC サービスの両方が namespace に作成されていることを確認し、Pod が再起動して準備完了になるまで待ちます。
RHOAIENG-37916 - LLM-D でデプロイされたモデルが、Deployments ページで失敗ステータスを表示します
{llm-d} を使用してデプロイされたモデルには、関連付けられている Pod ログにエラーや失敗が報告されていない場合でも、OpenShift AI ダッシュボードの Deployments ページに Failed ステータスが最初に表示されます。
デプロイメントのステータスを確認するには、OpenShift コンソールを使用してプロジェクト内の Pod を監視します。モデルの準備が整うと、OpenShift AI ダッシュボードのステータスが Started に更新されます。
- 回避策
- モデルのステータスが自動的に更新されるまで待つか、OpenShift コンソールで Pod のステータスをチェックして、モデルが正常に起動したことを確認します。
RHOAIENG-37882 - カスタムワークベンチ (AnythingLLM) の読み込みに失敗します
AnythingLLM 1.8.5 などのカスタムワークベンチをデプロイすると、読み込みが完了できない場合があります。OpenShift AI 3.0 以降、すべてのワークベンチは Kubernetes Gateway API のパスをベースにしたルーティングと互換性がある必要があります。この要件をサポートしていないカスタムワークベンチイメージは正しく読み込まれません。
- 回避策
-
${NB_PREFIX}パス (例:/notebook/<namespace>/<workbench-name>) からすべてのコンテンツを提供することで、パスベースのルーティングをサポートするようにカスタムワークベンチイメージを更新します。この接頭辞外のパス (/index.htmlや/api/dataなど) へのリクエストは、ワークベンチコンテナーにルーティングされません。
既存のワークベンチを修正する場合:
-
${NB_PREFIX}/...パスでリクエストを処理するようにアプリケーションを更新します。 -
フレームワークのベースパスを設定します (例:
FastAPI(root_path=os.getenv('NB_PREFIX', '')))。 - リダイレクト内の接頭辞を保持するように nginx を更新します。
-
${NB_PREFIX}/api、${NB_PREFIX}/api/kernels、${NB_PREFIX}/api/terminalsに HTTP 200 を返すヘルスエンドポイントを実装します。 -
相対 URL を使用し、
/menuなどのハードコードされた絶対パスを削除します。
詳細は、移行ガイド ゲートウェイ API 移行ガイド を参照してください。
RHOAIENG-37855 - Model Catalog からのモデルのデプロイメントは、名前の長さ制限により失敗します
Model Catalog から特定のモデルをデプロイすると、デプロイメントがサイレントに失敗し、Starting 状態のままになる場合があります。この問題は、結果のオブジェクト名が 63 文字の制限を超えた場合に、KServe が InferenceService からデプロイメントを作成できないために発生します。
- 例
-
モデル
RedHatAI/Mistral-Small-3.1-24B-Instruct-2503-FP8-dynamicをデプロイしようとすると、KServe はisvc.redhataimistral-small-31-24b-instruct-2503-fp8-dynamic-predictorという名前のデプロイメントを作成しようとしますが、これは 69 文字で、許可されている最大長を超えています。 - 回避策
-
生成されるオブジェクト名が 63 文字の制限内に収まるように、モデル名を短くするか、
InferenceServiceの名前を変更します。
RHOAIENG-37842 - ray.init() を必要とする Ray ワークロードは OpenShift AI の外部ではトリガーできません
ray.init() を必要とする Ray ワークロードは、OpenShift AI 環境の外部ではトリガーできません。これらのワークロードは、OpenShift の OpenShift AI で実行されているワークベンチまたはパイプライン内から送信する必要があります。これらのワークロードを外部で実行することはサポートされておらず、初期化に失敗します。
- 回避策
-
ray.init()を呼び出す Ray ワークロードは、OpenShift AI ワークベンチまたはパイプラインのコンテキスト内でのみ実行します。
RHOAIENG-37743 - ワークベンチの起動時に進行状況バーが表示されません
ワークベンチを起動する際、Workbench Status 画面の Progress タブにステップごとの進行状況が表示されません。代わりに、“Steps may repeat or occur in a different order.” という一般的なメッセージが表示されます。
- 回避策
- 進行状況に関する詳細情報を表示するには、Event Log タブを開くか、OpenShift コンソールを使用して、ワークベンチに関連付けられている Pod の詳細を表示します。
RHOAIENG-37667 - Model-as-a-Service (MaaS) は LLM-D ランタイムでのみ利用可能です
Model-as-a-Service (MaaS) は現在、Distributed Inference Server with llm-d ランタイムを使用してデプロイされたモデルに対してのみサポートされています。vLLM ランタイムでデプロイされたモデルは、現時点では MaaS では提供できません。
- 回避策
-
なし。Model-as-a-Service 機能を必要とするデプロイメントには、
llm-dランタイムを使用します。
RHOAIENG-37561 - バージョン 3.0.0 の IBM Z クラスターで、ダッシュボードコンソールリンクから OpenShift AI にアクセスできません
IBM Z クラスターのコンソールリンクを使用して OpenShift AI 3.0.0 ダッシュボードにアクセスしようとすると、接続に失敗します。
- 回避策
- 次の YAML ファイルを適用して、Gateway リンクへのルートを作成します。
RHOAIENG-37259 - Elyra Pipelines は IBM Z (s390x) ではサポートされていません
Elyra Pipelines は、オーケストレーションと検証用に Data Science Pipelines (DSP) に依存します。DSP は現在 IBM Z では利用できないため、Elyra パイプライン関連の機能とテストはスキップされます。
- 回避策
- なし。DSP サポートが IBM Z で有効化され検証されると、Elyra Pipelines は正常に機能します。
RHOAIENG-37015 - PyTorch 2.8 トレーニングイメージで TensorBoard レポートが失敗します
イメージ registry.redhat.io/rhoai/odh-training-cuda128-torch28-py312-rhel9:rhoai-3.0 で SFTTrainer を使用するトレーニングジョブに TensorBoard レポートを使用する場合、または report_to パラメーターがトレーニング設定から省略されている場合、トレーニングジョブは JSON シリアライゼーションエラーで失敗します。
- 回避策
-
最新バージョンの
transformersとtrlパッケージをインストールし、トレーニング設定でtorch_dtypeパラメーターをdtypeに更新します。
Training Operator SDK を使用している場合は、create_job 関数の packages_to_install パラメーターを使用して、インストールするパッケージを指定できます。
packages_to_install=[
"transformers==4.57.1",
"trl==0.24.0"
]
packages_to_install=[
"transformers==4.57.1",
"trl==0.24.0"
]
RHOAIENG-36757 - 接続が存在しない場合、モデルのデプロイメント時に既存のクラスターストレージのオプションが表示されない
データ接続が定義されていないプロジェクトでモデルデプロイメントを作成する場合、プロジェクトに適切な永続ボリューム要求 (PVC) が存在する場合でも、Existing cluster storage オプションは表示されません。これにより、モデルのデプロイメントに既存の PVC を選択できなくなります。
- 回避策
- Existing cluster storage オプションを表示するには、プロジェクトに URI タイプの接続を少なくとも 1 つ作成します。
RHOAIENG-31071 - Parquet データセットは IBM Z (s390x) ではサポートされていません
arc_easy や arc_challenge などの一部の埋め込み評価タスクでは、Hugging Face が Parquet 形式で提供するデータセットが使用されます。Parquet は IBM Z ではサポートされていません。
- 回避策
- なし。IBM Z でモデルを評価するには、Parquet ではなく、サポートされている形式のデータセットを使用します。
RHAIENG-1795 - CodeFlare と Ray が Gateway で動作しません
次のコマンドを実行すると、出力には Ray クラスターが作成され実行中であることが示されますが、Gateway ルートが正しく応答しないため、セルは完了しません。
cluster.up() cluster.wait_ready()
cluster.up()
cluster.wait_ready()
その結果、Ray クラスターの取得やジョブクライアントの取得などの後続の操作が失敗し、クラスターへのジョブの送信ができなくなります。
- 回避策
- なし。CodeFlare を通じて作成された場合、Ray Dashboard Gateway ルートは正しく機能しません。
RHAIENG-1796 - Kubernetes パイプラインストレージを使用する場合、パイプライン名は DNS に準拠している必要があります
パイプラインのストレージバックエンドとして Kubernetes を使用する場合、Elyra はパイプライン名を DNS 準拠の値に自動的に変換しません。Elyra パイプラインの起動時に DNS に準拠していない名前が使用されると、次のようなエラーが表示されます。
[TIP: did you mean to set 'https://ds-pipeline-dspa-robert-tests.apps.test.rhoai.rh-aiservices-bu.com/pipeline' as the endpoint, take care not to include 's' at end]
[TIP: did you mean to set 'https://ds-pipeline-dspa-robert-tests.apps.test.rhoai.rh-aiservices-bu.com/pipeline' as the endpoint, take care not to include 's' at end]
- 回避策
- Elyra パイプラインを作成または実行する際は、DNS 準拠の名前を使用します。
RHAIENG-1139 - 複数の namespace に同じ名前の LlamaStackDistribution をデプロイできない
異なる namespace に同じ名前の LlamaStackDistribution リソースを 2 つ作成すると、2 番目のリソースの ReplicaSet は Llama Stack Pod の起動に失敗します。Llama Stack Operator は、namespace 全体で重複した名前が使用されている場合、セキュリティー制約を正しく割り当てません。
- 回避策
-
各 namespace 内の各
LlamaStackDistributionに一意の名前を使用します。たとえば、プロジェクト名を含めるか、llama-stack-distribution-209342などの接尾辞を追加します。
RHAIENG-1624 - 非接続クラスターでの Embeddings API タイムアウト
非接続クラスターでは、デフォルトの Llama Stack Distribution イメージに含まれるデフォルトの組み込みモデル (ibm-granite/granite-embedding-125m-english) を使用すると、Embeddings API への呼び出しがタイムアウトになる可能性があります。
- 回避策
組み込みモデルをオフラインで使用するには、
LlamaStackDistributionカスタムリソースに次の環境変数を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
RHOAIENG-34923 - JupyterLab からパイプラインを実行するときにランタイム設定が見つからない
プロジェクトの最初のアクティブなワークベンチからパイプラインを実行すると、ランタイム設定が Elyra パイプラインエディターに表示されないことがあります。これは、ワークベンチの初回セッション時に、設定が正常に入力されないために発生します。
- 回避策
- ワークベンチを再起動します。再起動後、ランタイム設定がパイプライン実行に使用できるようになります。
RHAIENG-35055 - OpenShift AI 2.24 からのアップグレード後にモデルカタログの初期化に失敗する
OpenShift AI 2.24 からアップグレードした後、モデルカタログの初期化とロードに失敗する可能性があります。OpenShift AI ダッシュボードに、Request access to model catalog エラーが表示されます。
- 回避策
次のコマンドを実行して、既存のモデルカタログ ConfigMap とデプロイメントを削除します。
oc delete configmap model-catalog-sources -n rhoai-model-registries --ignore-not-found $ oc delete deployment model-catalog -n rhoai-model-registries --ignore-not-found
$ oc delete configmap model-catalog-sources -n rhoai-model-registries --ignore-not-found $ oc delete deployment model-catalog -n rhoai-model-registries --ignore-not-foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow
RHAIENG-35529 - 外部 Argo Workflows 使用時の Data Science Pipelines Operator のリコンシリエーション問題
既存の外部 Argo Workflows インストールを削除する前に、組み込み Argo Workflows コントローラー (argoWorkflowsControllers: Managed) を有効にすると、ワークフローコントローラーが起動に失敗し、Data Science Pipelines Operator (DSPO) がカスタムリソースを正しくリコンサイルしない可能性があります。
- 回避策
- 組み込み Argo Workflows コントローラーを有効にする前に、クラスターから既存の外部 Argo Workflows インスタンスを削除します。
RHAIENG-36756 - 接続が存在しない場合、モデルのデプロイメント時に既存のクラスターストレージのオプションが表示されない
データ接続が定義されていないプロジェクトでモデルデプロイメントを作成すると、永続ボリューム要求 (PVC) が使用可能な場合でも、既存のクラスターストレージ オプションは表示されません。その結果、モデルの保存に既存の PVC を選択できません。
- 回避策
-
プロジェクト内に
URIタイプの接続を少なくとも 1 つ作成します。その後、既存のクラスターストレージ オプションが使用可能になります。
RHOAIENG-36817 - Model サーバーのサイズが small に設定されていると推論サーバーが失敗する
ダッシュボード経由で推論サービスを作成する際に、Model サーバーサイズとして small を選択すると、後続の推論要求が失敗します。その結果、推論サービス自体のデプロイメントは成功しますが、推論要求はタイムアウトエラーで失敗します。
- 回避策
-
この問題を解決するには、ドロップダウンから Model サーバーのサイズとして
largeを選択します。
RHOAIENG-33995 - Phi および Mistral モデルの推論サービスのデプロイメントが失敗する
openshift-container-platform 4.19 を搭載した IBM Power クラスターで vLLM ランタイムを使用して Phi および Mistral モデルの推論サービスを作成すると、CPU バックエンドに関連するエラーが原因で失敗します。その結果、これらのモデルのデプロイメントが影響を受け、推論サービスの作成が失敗します。
- 回避策
-
この問題を解決するには、CPU および Phi モデルに対して有効になっている場合は、サービスランタイムで
sliding_windowメカニズムを無効にします。スライディングウィンドウは現在 V1 ではサポートされていません。
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オブジェクトを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Routeオブジェクトを作成します。oc apply -f <route-file-name>.yaml
oc apply -f <route-file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 推論要求を送信するには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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-29729 - アップグレード後の再起動ループでモデルレジストリー Operator が実行される
モデルレジストリーコンポーネントを有効にした状態で OpenShift AI バージョン 2.22 以前からバージョン 2.23 以降にアップグレードすると、モデルレジストリー Operator が再起動ループに入る可能性があります。これは model-registry-operator-controller-manager Pod 内のマネージャーコンテナーのメモリー制限が不十分なために発生します。
- 回避策
この問題を解決するには、
model-registry-operator-controller-managerデプロイメントのリコンシリエーションをトリガーする必要があります。デプロイメントにopendatahub.io/managed='true'アノテーションを追加すると、これが実現され、正しいメモリー制限が適用されます。次のコマンドを実行してアノテーションを追加できます。oc annotate deployment model-registry-operator-controller-manager -n redhat-ods-applications opendatahub.io/managed='true' --overwrite
oc annotate deployment model-registry-operator-controller-manager -n redhat-ods-applications opendatahub.io/managed='true' --overwriteCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このコマンドは
model-registry-operator-controller-managerデプロイメント内のカスタム値を上書きします。カスタムデプロイメント値の詳細は、コンポーネントデプロイメントリソースのカスタマイズ を参照してください。デプロイメントが更新され、メモリー制限が 128Mi から 256Mi に増加すると、コンテナーのメモリー使用量が安定し、再起動ループが停止します。
RHOAIENG-31238 - DSCInitialization の作成時に新しい監視スタックが有効になった
DSCInitialization リソースを削除し、OpenShift AI コンソールフォームビューを使用して新しいリソースを作成すると、テクノロジープレビューの可観測性スタックが有効になります。その結果、DSCInitialization リソースを再作成するときに、不要な可観測性スタックがデプロイメントされることになります。
- 回避策
この問題を解決するには、フォームビューを使用して DSCInitiliazation リソースを再作成するときに、"metrics" と "traces" フィールドを手動で削除します。
テクノロジープレビューの監視スタックを使用する場合、これは必要ありません。
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'
- 回避策
-
このエラーを防止し、使用状況統計のロギングを抑制するには、推論サービスのデプロイメントで
VLLM_NO_USAGE_STATS=1環境変数を設定します。これにより、使用状況の自動レポートが無効になり、システムディレクトリーへの書き込み時に権限の問題が発生するのを回避できます。
RHOAIENG-24545 - 初回の起動後にランタイムイメージがワークベンチに存在しない
ランタイムイメージのリストには、namespace で最初に実行されているワークベンチインスタンスが適切に入力されないため、Elyra パイプラインエディターで選択できるイメージが表示されません。
- 回避策
- ワークベンチを再起動します。ワークベンチを再起動すると、ランタイムイメージのリストがワークベンチと Elyra パイプラインエディターの選択ボックスの両方に表示されます。
RHOAIENG-20209 - 要求されたリソースがしきい値を超えても警告メッセージが表示されない
Distributed workloads
- 回避策
- なし。
SRVKS-1301 (以前は RHOAIENG-18590 として文書化されていました) - KServe を無効化にしてから有効化すると、KnativeServing リソースが失敗する
DataScienceCluster で kserve コンポーネントを無効にしてから有効にすると、KnativeServing リソースが失敗する可能性があります。
- 回避策
Knative に関連するすべての
ValidatingWebhookConfigurationおよびMutatingWebhookConfigurationWebhook を削除します。Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knativeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - KServe が無効になっていることを確認します。
Webhook を取得します。
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knativeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Webhook を削除します。
- KServe を有効にします。
-
KServe Pod が正常に生成され、
knative-servingnamespace 内の Pod がアクティブで動作していることを確認します。
RHOAIENG-16247 - OpenShift AI ダッシュボードから実行を開始すると、Elyra パイプラインの実行出力が上書きされる
Elyra からパイプラインを作成して実行すると、パイプラインの実行によって生成された出力が、オブジェクトストレージのフォルダー bucket-name/pipeline-name-timestamp に保存されます。
Elyra からパイプラインを作成し、OpenShift AI ダッシュボードからパイプラインの実行を開始すると、タイムスタンプ値が更新されません。これにより、パイプラインの実行によって、同じパイプラインの以前のパイプライン実行によって作成されたファイルが上書きされる可能性があります。
この問題は、OpenShift AI ダッシュボードを使用してコンパイルおよびインポートされたパイプラインには影響しません。これは、オブジェクトストレージで使用されるフォルダーに runid が常に追加されるためです。AI パイプラインで使用されるストレージの場所の詳細は、パイプラインによるデータの保存 を参照してください。
- 回避策
- Elyra パイプラインにファイルを保存する場合は、パイプライン実行ごとに異なるサブフォルダー名を使用します。
OCPBUGS-49422 - 非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージがサポートされていない
この OpenShift AI リリースでは、非接続環境内の AMD GPU および AMD ROCm ワークベンチイメージはサポートされていません。AMD GPU Operator をインストールするには、GPU ドライバーのコンパイルに必要な依存関係を取得するのにインターネットアクセスが必要であるためです。
- 回避策
- なし。
RHOAIENG-7716 - パイプライン条件グループのステータスが更新されない
ループ (dsl.ParallelFor) または条件グループ (dsl.lf) を含むパイプラインを実行すると、パイプラインの実行が完了した後でも、UI にループとグループの実行ステータスが表示されます。
- 回避策
アクティブな子タスクがないことを確認することで、パイプラインがまだ実行中かどうかを確認できます。
-
OpenShift AI ダッシュボードから、Develop & train
Pipelines Runs をクリックします。 - Project リストから、データサイエンスプロジェクトをクリックします。
- Runs タブから、ステータスを確認する必要があるパイプライン実行をクリックします。
条件グループを展開し、子タスクをクリックします。
子タスクに関する情報を含むパネルが表示されます。
パネルで、Task 詳細タブをクリックします。
Status フィールドに、子タスクの正しいステータスが表示されます。
-
OpenShift AI ダッシュボードから、Develop & train
RHOAIENG-6409 - 実行が成功しても、パイプラインログに Cannot save parameter というエラーが表示される
パイプラインを複数回実行すると、パイプラインの実行が成功した場合、パイプラインログに Cannot save parameter というエラーが表示されます。これらのエラーは無視しても問題ありません。
- 回避策
- なし。
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/ディレクトリーを指定しないでください。
-
OpenShift AI ダッシュボードを使用してモデルをデプロイする場合は、データ接続の Path フィールドで、
-
S3 互換ストレージバケットで、モデルファイルを
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-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
- 回避策
-
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 Notebook の URL がわかっている場合は、これをブラウザーで再度開くことができます。
- 回避策
- OpenShift AI ダッシュボードからログアウトする前に、JupyterLab からログアウトします。
RHODS-7718 - ダッシュボード権限のないユーザーが実行中のワークベンチを無期限に使い続けることができる
Red Hat OpenShift AI 管理者がユーザーの権限を取り消しても、引き続きユーザーは実行中のワークベンチを無期限で使用できます。
- 回避策
- OpenShift AI 管理者がユーザーの権限を取り消す場合、管理者はそのユーザーに対して実行中のワークベンチも停止する必要があります。
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 Copied! Toggle word wrap Toggle overflow
RHODS-4718: Intel® oneAPI AI Analytics Toolkits のクイックスタートが、存在しないサンプルノートブックを参照している
ダッシュボードの Resources ページにある Intel® oneAPI AI アナリティクスツールキットクイックスタートでは、手順の一部としてサンプルノートブックをロードする必要がありますが、関連するリポジトリーに存在しないノートブックを参照しています。
- 回避策
- なし。
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 を手動で設定する場合のサポートについては、Red Hat カスタマーポータル にお問い合わせください。