第 8 章 已知问题


本节介绍了 Red Hat OpenShift AI 3.0 中已知的问题,以及所有已知问题的方法。

OpenStack 和私有云环境中所需的 RHOAIENG-37228 - Manual DNS 配置

当在 OpenStack、CodeReady Containers (CRC)或其他没有集成外部 DNS 的私有云环境中部署 OpenShift AI 3.0 时,对组件(如仪表板和工作台)的外部访问可能会在安装后失败。这是因为动态置备的 LoadBalancer 服务不会自动在外部 DNS 中注册其 IP 地址。

临时解决方案
要恢复访问,请在外部 DNS 系统中手动创建所需的 A 或 CNAME 记录。具体步骤请参阅 在 OpenStack 和私有云上为 RHOAI 3.x 配置外部 DNS 知识库文章。

RHOAIENG-38658- TrustyAI 服务在对 IBM Z (s390x)上的令牌身份验证进行模型推测期间,

在 IBM Z (s390x)架构中,当启用令牌身份验证时,TrustyAI 服务会在模型推测期间遇到错误。当登录到 TrustyAI 服务日志记录器时,会显示一个 JsonParseException,从而导致 bias 监控进程意外失败或行为。

临时解决方案
在不进行身份验证的情况下运行 TrustyAI 服务。只有在启用令牌身份验证时,才会出现这个问题。

RHOAIENG-38333 - Code 由 generateive AI Playground 生成的无效,且工作台中缺少所需的软件包

在 OpenShift AI workbench 中运行时,由 generateive AI Playground 自动生成的代码可能会导致语法错误。此外,LlamaStackClient 软件包目前不包含在标准工作台镜像中。

RHOAIENG-38263 - Intermittent 失败,在 IBM Z 的 Hugging Face 运行时上的 Guardrails Detector 模型

在 IBM Z 平台上,在 Hugging Face 运行时上运行的 Guardrails Detector 模型可能会间歇性地处理相同的请求。在某些情况下,之前返回的有效结果的请求会失败,并显示类似以下示例的 parse 错误:

Invalid numeric literal at line 1, column 20
Copy to Clipboard Toggle word wrap

此错误可能会导致服务 Pod 临时进入 CrashLoopBackOff 状态,尽管它通常会自动恢复。

临时解决方案
无。pod 会自动重启并恢复正常操作。

RHOAIENG-38253 - Distributed Inference Server with llm-d not listed in the Serving Runtimes 页

虽然部署模型时 带有 llm-d 的分布式 Inference Server 显示为可用选项,但它不会在 Settings 部分下的 Serving Runtimes 页面中列出。

这是因为 具有 llm-d 的分布式推测服务器 是一个复合部署类型,包括标准服务运行时之外的其他组件。因此,它不会出现在管理员可见的服务运行时列表中,目前无法在最终用户中隐藏。

临时解决方案
无。带有 llm-d 选项的分布式保险服务器 仍然可以用于模型部署,但不能在 Serving Runtimes 页面中管理或查看。

RHOAIENG-38252 - Model Registry Operator 无法用于 OpenShift 4.20 上的 BYOOps 模式

在配置了 Bring Your Own Identity Provider (BYO collaborate)模式的 OpenShift 4.20 集群中,部署 Model Registry Operator 会失败。

当您创建 ModelRegistry 自定义资源时,它无法访问 available: True 状态。相反,资源会显示类似以下示例的状态:

status:
  conditions:
  - lastTransitionTime: "2025-11-06T22:09:04Z"
    message: 'unexpected reconcile error: failed to get API group resources: unable to retrieve the complete list of server APIs: user.openshift.io/v1: the server could not find the requested resource'
    reason: DeploymentUnavailable
    status: "False"
    type: Available
Copy to Clipboard Toggle word wrap
临时解决方案
无。

当在 OpenShift 4.20 中使用 BYO EgressIP 模式时,您无法创建和部署 Model Registry 实例。

RHOAIENG-38 180- Workbench 请求到功能存储服务会导致证书错误

使用默认配置时,Feature Store (Feast)部署缺少所需的证书和服务端点。因此,工作台无法使用 Feast SDK 将请求发送到 Feature Store。

临时解决方案
删除现有的 FeatureStore 自定义资源(CR),然后使用以下配置创建新资源:
registry:
  local:
    server:
      restAPI: false
Copy to Clipboard Toggle word wrap

在 Feature Store pod 开始运行后,编辑同一 CR 来设置 registry.local.server.restAPI: true,并在不删除 CR 的情况下保存它。验证命名空间中是否同时创建了 REST 和 gRPC 服务,并等待 pod 重启并就绪。

RHOAIENG-37916 - LLM-D 部署模型在 Deployments 页面中显示失败状态

使用 {llm-d} 部署的模型最初在 OpenShift AI 仪表板的 Deployments 页面中显示 Failed 状态,即使关联的 pod 日志没有报告任何错误或失败。

若要确认部署的状态,可使用 OpenShift 控制台监控项目中的容器集。当模型就绪时,OpenShift AI 仪表板将状态更新为 Started

临时解决方案
等待模型状态自动更新,或检查 OpenShift 控制台中的 pod 状态,以验证模型是否已成功启动。

RHOAIENG-37882 - Custom workbench (AnythingLLM)无法加载

部署自定义工作台,如 AnythingLLM 1.8.5 可能无法完成加载。从 OpenShift AI 3.0 开始,所有工作台必须与 Kubernetes 网关 API 的基于路径的路由兼容。不支持此要求的自定义工作台镜像无法正确加载。

临时解决方案
通过从 ${NB_PREFIX} 路径提供所有内容(例如 /notebook/<namespace>/<workbench-name>),来更新您的自定义工作台镜像以支持基于路径的路由。到此前缀之外的路径(如 /index.html/api/data)的请求不会路由到工作台容器。

修复现有的工作台:

  • 更新您的应用程序以在 ${NB_PREFIX}/.. 路径中处理请求。
  • 在框架中配置基本路径,例如: FastAPI (root_path=os.getenv ('NB_PREFIX', ''))
  • 更新 nginx,以在重定向中保留前缀。
  • 实施在以下位置返回 HTTP 200 的健康端点:${NB_PREFIX}/api、 ${NB_PREFIX}/api /kernels${NB_PREFIX}/api/terminals
  • 使用相对 URL 并删除所有硬编码的绝对路径,如 /menu

如需更多信息,请参阅迁移指南: 网关 API 迁移指南

因为名称长度限制,来自 Model Catalog 的 RHOAIENG-378 55- Model 部署会失败

当从 Model Catalog 部署某些模型时,部署可能会静默失败,并处于 Starting 状态。出现这个问题的原因是,当生成的对象名称超过 63 个字符限制时,KServe 无法从 InferenceService 创建部署。

Example
尝试部署模型 RedHatAI/Mistral-Small-3.1-24B-Instruct-2503-FP8-dynamic 会导致 KServe 试图创建名为 isvc.redhataimistral-small-31-24b-instruct-2503-fp8-dynamic-predictor 的部署,其具有 69 个字符并超过允许的最大长度。
临时解决方案
使用较短的模型名称或重命名 InferenceService,以确保生成的对象名称保留在 63 个字符限制中。

RHOAIENG-378 42- Ray 工作负载需要 ray.init (),无法触发 OpenShift AI

需要 ray.init () 的工作负载无法在 OpenShift AI 环境外触发。这些工作负载必须从 OpenShift 中的 OpenShift AI 上运行的工作台或管道内提交。不支持在外部运行这些工作负载,并导致初始化失败。

临时解决方案
仅在 OpenShift AI workbench 或管道上下文中调用 ray.init () 的工作负载。

RHOAIENG-37743 - 启动工作台时没有显示进度条

在启动工作台时,Workbench Status 屏幕中的 Progress 选项卡不会显示逐步进度。相反,它会显示一个通用消息,表示"Steps 可能会以不同顺序重复或发生"。

临时解决方案
要查看详细进度信息,请打开 Event Log 选项卡,或使用 OpenShift 控制台查看与工作台关联的 pod 详情。

RHOAIENG-37667 - Model-as-Service (MaaS)仅适用于 LLM-D 运行时

目前,模型即服务(MaaS)仅支持通过 分布式推测服务器(llm-d runtime)部署的模型。使用 vLLM 运行时部署的模型目前无法由 MaaS 提供。

临时解决方案
无。将 llm-d 运行时用于需要 Model-as-a-Service 功能的部署。

RHOAIENG-37561 - Dashboard 控制台链接无法访问 3.0.0 中的 IBM Z 集群的 OpenShift AI

当尝试使用 IBM Z 集群上的控制台链接访问 OpenShift AI 3.0.0 仪表板时,连接会失败。

临时解决方案
通过应用以下 YAML 文件来创建到网关链接的路由:
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: data-science-gateway-data-science-gateway-class
  namespace: openshift-ingress
spec:
  host: data-science-gateway.apps.<baseurl>
  port:
    targetPort: https
  tls:
    termination: passthrough
  to:
    kind: Service
    name: data-science-gateway-data-science-gateway-class
    weight: 100
  wildcardPolicy: None
Copy to Clipboard Toggle word wrap

RHOAIENG-37259 - IBM Z (s390x)不支持 Elyra Pipelines

Elyra Pipelines 依赖于 Data Science Pipelines (DSP)进行编配和验证。因为 IBM Z 上目前不提供 DSP,所以会跳过与 Elyra 管道相关的功能和测试。

临时解决方案
无。当在 IBM Z 上启用并验证 DSP 支持后,Elyra Pipelines 可以正常工作。

RHOAIENG-37015- TensorBoard 报告在 PyTorch 2.8 培训镜像中失败

当使用 TensorBoard 报告使用 SFTTrainer 和镜像 registry.redhat.io/rhoai/odh-training-cuda128-torch28-py312-rhel9:rhoai-3.0,或者在培训配置中省略 report_to 参数时,培训作业会失败,并显示 JSON 序列化错误。

临时解决方案
安装最新版本的 转换器trl 软件包,并在培训配置中将 torch_dtype 参数更新为 dtype

如果使用 Training Operator SDK,您可以使用 create_job 函数中的 packages_to_install 参数指定要安装的软件包:

packages_to_install=[
    "transformers==4.57.1",
    "trl==0.24.0"
]
Copy to Clipboard Toggle word wrap

当没有连接时,在模型部署中缺少 RHOAIENG-36757 - 现有集群存储选项

当在没有定义数据连接的项目中创建模型部署时,不会显示 Existing cluster storage 选项,即使项目中存在适当的持久性卷声明(PVC)。这可防止您为模型部署选择现有 PVC。

临时解决方案
在项目中创建类型为 URI 的一个连接,使 现有集群存储选项 出现。

RHOAIENG-310 71- Parquet datasets 不支持 IBM Z (s390x)

某些内置评估任务,如 arc_easyarc_challenge,使用 Hugging Face 以 Parquet 格式提供的数据集。IBM Z 不支持 Parquet。

临时解决方案
无。要评估 IBM Z 上的模型,请使用支持格式而不是 Parquet 的数据集。

RHAIENG-1795 - 带有 Ray 的 CodeFlare 无法使用网关

当运行以下命令时,输出表示 Ray 集群已创建并正在运行,但单元永远不会完成,因为网关路由无法正确响应:

cluster.up()
cluster.wait_ready()
Copy to Clipboard Toggle word wrap

因此,获取 Ray 集群或获取作业客户端等后续操作会失败,从而导致作业提交至集群。

临时解决方案
无。当通过 CodeFlare 创建时,Ray Dashboard 网关路由无法正常工作。

在使用 Kubernetes 管道存储时,RHAIENG-1796 - Pipeline 名称必须是与 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]
Copy to Clipboard Toggle word wrap
临时解决方案
在创建或运行 Elyra 管道时,请使用与 DNS 兼容的名称。

RHAIENG-11 39-Cannot deploy LlamaStackDistribution,在多个命名空间中具有相同名称

如果您在不同命名空间中创建两个 LlamaStackDistribution 资源,则第二个资源的 ReplicaSet 无法启动 Llama Stack pod。当在命名空间间使用重复名称时,Llama Stack Operator 无法正确分配安全限制。

临时解决方案
在每个命名空间中为每个 LlamaStackDistribution 使用唯一名称。例如,包含项目名称或添加后缀,如 llama-stack-distribution-209342

RHAIENG-16 24- 在断开连接的集群中嵌入 API 超时

在断开连接的集群中,使用默认嵌入模型(ibm-granite/granite-embedding-125m-english)时,对嵌入 API 的调用可能会超时。

临时解决方案

LlamaStackDistribution 自定义资源中添加以下环境变量,以离线使用嵌入模型:

- name: SENTENCE_TRANSFORMERS_HOME
  value: /opt/app-root/src/.cache/huggingface/hub
- name: HF_HUB_OFFLINE
  value: "1"
- name: TRANSFORMERS_OFFLINE
  value: "1"
- name: HF_DATASETS_OFFLINE
  value: "1"
Copy to Clipboard Toggle word wrap

从 JupyterLab 运行管道时,RHOAIENG-349 23- Runtime 配置缺失

当您从项目中的第一个活跃工作台运行管道时,运行时配置可能不会出现在 Elyra pipeline 编辑器中。这是因为配置无法为初始工作台会话填充。

临时解决方案
重启工作台。重启后,运行时配置将可用于管道执行。

从 OpenShift AI 2.24 升级后,RHAIENG-350 55- Model 目录无法初始化

从 OpenShift AI 2.24 升级后,模型目录可能无法初始化和加载。OpenShift AI 仪表板显示 对模型目录错误的 Request 访问

临时解决方案

运行以下命令来删除现有模型目录 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
Copy to Clipboard Toggle word wrap

使用外部 Argo 工作流时,Data Science Pipelines Operator 中的 RHAIENG-35529 - Reconciliation 问题

如果您在删除现有外部 Argo 工作流安装前启用嵌入的 Argo Workflows 控制器(rgoWorkflowsControllers: Managed),工作流控制器可能无法启动,并且 Data Science Pipelines Operator (DSPO)可能无法正确协调其自定义资源。

临时解决方案
在启用嵌入的 Argo Workflows 控制器前,从集群中删除任何现有的外部 Argo 工作流实例。

当没有连接时,在模型部署中缺少 RHAIENG-36756 - 现有集群存储选项

当在没有定义数据连接的项目中创建模型部署时,不会出现现有集群存储选项,即使 PVC 可用。因此,您无法为模型存储选择现有 PVC。

临时解决方案
在项目中至少创建一个类型为 URI 的连接。之后 ,现有集群存储选项 将变为可用。

当模型服务器大小设置为 small时,RHOAIENG-36817 - Inference 服务器会失败

当通过控制面板创建 inference 服务时,选择 模型服务器大小会导致后续不误请求失败。因此,对 inference 服务本身的部署成功,但推断请求会失败,并显示超时错误。

临时解决方案
要解决这个问题,请从下拉菜单中选择 Model server size as large

RHOAIENG-33995 - 部署 Phi 和 Mistral 模型的 inference 服务失败

在带有 openshift-container-platform 4.19 的 IBM Power 集群中使用 vLLM 运行时为 Phi 和 Mistral 模型创建 inference 服务会失败,因为与 CPU 后端相关的错误。因此,部署这些模型会受到影响,从而导致服务创建失败。

临时解决方案
要解决这个问题,如果为 CPU 和 Phi 模型启用了,在服务运行时中禁用 sliding_window 机制。V1 目前不支持 sliding 窗口。

RHOAIENG-33795 - 为 IBM Z 上的 Triton Inference Server 的 gRPC 端点验证需要手动路由创建

当验证带有 gRPC 端点的 Triton Inference Server 时,路由不会自动创建。这是因为 Operator 目前默认为 REST 创建边缘终止路由。

临时解决方案

要解决这个问题,在 IBM Z 上为 Triton Inference Server 的 gRPC 端点验证需要手动路由创建。

  1. 当模型部署 pod 启动并运行时,在 YAML 文件中定义带有以下内容的 edge-terminated 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
    Copy to Clipboard Toggle word wrap
  2. 创建 Route 对象:

    oc apply -f <route-file-name>.yaml
    Copy to Clipboard Toggle word wrap
  3. 要发送 inference 请求,请输入以下命令:

    grpcurl -cacert <ca_cert_file>\ 
    1
    
      -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.protomodel_config.proto 文件。

RHOAIENG-3369 7- Unable to Edit or Delete model,除非状态为"Started"

当您在 NVIDIA NIM 或单型号服务平台上部署模型时,操作菜单中的 EditDelete 选项不适用于 StartingPending 状态中的模型。这些选项仅在成功部署模型后可用。

临时解决方案
等待模型处于 Started 状态,以便进行任何更改或删除模型。

RHOAIENG-336 45- LM-Eval Tier1 测试失败

LM-Eval Tier1 测试可能会失败,因为在运行作业时不会作为参数传递 confirm_run_unsafe_code,如果您使用 trustyai-service-operator 的旧版本。

临时解决方案
确保您使用最新版本的 trustyai-service-operator,并且启用了 AllowCodeExecution

升级后,在重启循环中 RHOAIENG-29729 - Model registry Operator

从 OpenShift AI 版本 2.22 或更早版本升级到启用了模型 registry 组件的 2.23 或更高版本后,模型 registry Operator 可能会进入重启循环。这是因为 model-registry-operator-controller-manager pod 中 manager 容器的内存限值不足。

临时解决方案

要解决这个问题,您必须为 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
Copy to Clipboard Toggle word wrap
注意

此命令覆盖 model-registry-operator-controller-manager 部署中的自定义值。有关自定义部署值的更多信息,请参阅自定义组件部署资源

在部署更新后,内存限制从 128Mi 增加到 256Mi,容器内存用量将稳定,重启循环将停止。

创建 DSCInitialization 时启用 RHOAIENG -31238- New observability 堆栈

当您删除 DSCInitialization 资源并使用 OpenShift AI 控制台表单视图创建新资源时,它启用了技术预览可观察性堆栈。这会导致在重新创建 DSCInitialization 资源时部署不需要的可观察性堆栈。

临时解决方案

要解决这个问题,请使用表单视图重新创建 DSCInitiliazation 资源时手动删除 "metrics" 和 "traces" 字段。

如果要使用技术预览可观察性堆栈,则不需要此项。

RHOAIENG-32599 - 在 IBM Z 集群上创建服务失败

当您试图在 IBM Z 集群上使用 vLLM 运行时创建 inference 服务时,会失败并显示以下错误:ValueError : 'aimv2' 已被 Transformers 配置使用,选择另一个名称

临时解决方案
无。

RHOAIENG-29731 - Inference 服务创建在带有 OpenShift 4.19 的 IBM Power 集群上失败

当您试图在 OpenShift Container Platform 版本 4.19 上的 IBM Power 集群上使用 vLLM 运行时创建 inference 服务时,它会失败,因为与 Non-Uniform Memory Access (NUMA)相关的错误。

临时解决方案
当您创建 inference 服务时,请将环境变量 VLLM_CPU_OMP_THREADS_BIND 设置为 所有

由于使用统计目录访问,RHOAIENG-29292 - vLLM 会在 IBM Z 上记录权限错误

在 IBM Z 架构上运行 vLLM 时,inference 服务可以成功启动,但在与用量统计报告相关的后台线程中记录错误。这是因为服务试图将使用量数据写入一个受限位置(/.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
临时解决方案
要防止这个错误并阻止使用统计日志记录,请在 inference 服务部署中设置 VLLM_NO_USAGE_STATS=1 环境变量。这会禁用自动使用报告,避免在写入系统目录时的权限问题。

RHOAIENG-24545 - Runtime 镜像在第一次启动后不会出现在工作台中

运行时镜像列表无法正确填充命名空间中的第一个运行工作台实例,因此 Elyra pipeline 编辑器中没有显示镜像进行选择。

临时解决方案
重启工作台。重启工作台后,运行时镜像列表会填充工作台和 Elyra 管道编辑器的选择框。

当请求的资源超过阈值时,不会显示 RHOAIENG-2020 9- Warning 信息

当您点 Distributed workloads Project metrics 并查看 Requested resources 部分时,图表会显示请求的资源值以及每个资源(CPU 和内存)的总共享配额值。但是,当 Requested by all projects 值超过该资源的 Warning 阈值时,不会显示预期的警告信息。

临时解决方案
无。

SRVKS-1301 (以前称为 RHOAIENG-18590)- KnativeServing 资源在禁用并启用 KServe 后会失败

在 DataScienceCluster 中禁用并启用 kserve 组件后,KnativeServing 资源可能会失败。

临时解决方案

删除所有与 Knative 相关的 ValidatingWebhookConfigurationMutatingWebhookConfiguration Webhook:

  1. 获取 Webhook:

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
    Copy to Clipboard Toggle word wrap
  2. 确保禁用 KServe。
  3. 获取 Webhook:

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
    Copy to Clipboard Toggle word wrap
  4. 删除 webhook。
  5. 启用 KServe。
  6. 验证 KServe pod 可以成功生成,并且 knative-serving 命名空间中的 pod 是否活跃且可操作。

从 OpenShift AI 仪表板启动时,RHOAIENG-16247 - Elyra pipeline run 输出会被覆盖

当管道创建并从 Elyra 运行时,管道运行生成的输出存储在对象存储的文件夹 bucket-name/pipeline-name-timestamp 中。

当从 Elyra 创建管道并且管道运行从 OpenShift AI 仪表板启动时,不会更新时间戳值。这可能导致管道运行覆盖之前同一管道运行创建的文件。

此问题不会影响使用 OpenShift AI 仪表板编译和导入的管道,因为 runid 始终添加到对象存储中使用的文件夹中。有关 AI 管道中使用的存储位置的更多信息,请参阅使用管道存储数据

临时解决方案
将文件存储在 Elyra 管道中时,在每个管道运行上使用不同的子文件夹名称。

在断开连接的环境中不支持 OCPBUGS-49422 - AMD GPU 和 AMD ROCm workbench 镜像

此 OpenShift AI 发行版本不支持在断开连接的环境中的 AMD GPU 和 AMD ROCm workbench 镜像,因为安装 AMD GPU Operator 需要访问互联网来获取编译 GPU 驱动程序所需的依赖项。

临时解决方案
无。

RHOAIENG-7716 - Pipeline 条件组状态不会更新

当您运行具有循环(dsl.ParallelFor)或条件组(dsl.lf)的管道时,UI 会为循环和组显示一个 Running 状态,即使在管道执行完成后也是如此。

临时解决方案

您可以通过检查没有子任务保持活动状态来确认管道是否仍在运行。

  1. 从 OpenShift AI 仪表板,点 Development & training Pipelines Runs
  2. Project 列表中点击您的数据科学项目。
  3. Runs 选项卡中,点您要检查状态的管道运行。
  4. 展开 condition 组,再单击子任务。

    此时会显示包含子任务信息的面板

  5. 在面板中点 Task details 选项卡。

    Status 字段显示子任务的正确状态。

RHOAIENG-6409 - Cannot save 参数 错误会出现在管道日志中成功运行

当您多次运行管道时,Cannot save 参数 错误会出现在管道日志中成功运行。您可以安全地忽略这些错误。

临时解决方案
无。

RHOAIENG-3025 - OVMS 预期目录布局与 KServe StoragePuller 布局冲突

当您使用 OpenVINO 模型服务器(OVMS)运行时在单模式服务平台(使用 KServe)上部署模型时,OVMS 预期的目录布局与 KServe 使用的目录布局之间不匹配。具体来说,OVMS 要求模型文件位于 /< mnt>/models/1/ 目录中,而 KServe 则将它们放置在 /< mnt>/models/ 目录中。

临时解决方案

执行以下操作:

  1. 在 S3 兼容存储桶中,将您的模型文件放在名为 1/ 的目录中,例如 /< s3_storage_bucket>/models/1/<model_files >。
  2. 要使用 OVMS 运行时在单型号服务平台上部署模型,请选择以下选项之一来指定模型文件的路径:

    • 如果您使用 OpenShift AI 仪表板来部署模型,在数据连接的 Path 字段中,使用 /< s3_storage_bucket>/models/ 格式来指定模型文件的路径。不要将 1/ 目录指定为路径的一部分。
    • 如果您要创建自己的 InferenceService 自定义资源来部署模型,请将 storageURI 字段的值配置为 /< s3_storage_bucket>/models/。不要将 1/ 目录指定为路径的一部分。

KServe 从您指定的路径中的子目录拉取模型文件。在这种情况下,KServe 可以正确地从 S3 兼容存储中的 /& lt;s3_storage_bucket>/models/1/ 目录中拉取模型文件。

KServe 上的 RHOAIENG-30 18- OVMS 在仪表板中不会公开正确的端点

当您使用 OpenVINO 模型服务器(OVMS)运行时在单模式服务平台上部署模型时,部署模型的 Inference endpoint 字段中显示的 URL 不完整。

临时解决方案
要将查询发送到模型,您必须将 /v2/models/_<model-name>_/infer 字符串添加到 URL 的末尾。将 _<model-name>_ 替换为部署的模型的名称。

RHOAIENG-222 8- 当间隔设置为 15 秒时,性能指标图会持续变化

在模型指标屏幕的 Endpoint 性能 选项卡中,如果您将 Refresh interval 设为 15 秒,且 Time range 设为 1 小时,则图形结果会持续更改。

临时解决方案
无。

RHOAIENG-2183 - Endpoint 性能图可能会显示不正确的标签

在模型指标屏幕的 Endpoint 性能 选项卡中,图形工具提示可能会显示不正确的标签。

临时解决方案
无。

在 InferenceService 报告为 Loaded 后,RHOAIENG-131 - gRPC 端点没有正确响应

当生成了大量 InferenceService 实例时,Service Mesh Control Plane (SMCP)将变为无响应。InferenceService 实例的状态为 Loaded,但调用 gRPC 端点会返回错误。

临时解决方案
编辑 ServiceMeshControlPlane 自定义资源(CR)以增加 Istio egress 和 ingress pod 的内存限值。

RHOAIENG-1619 (以前称为 DATA-SCIENCE-PIPELINES-165))- S3 存储桶不可写入时的 Poor 错误消息

当您设置数据连接时,且 S3 存储桶不可写入,而您尝试上传管道时,错误消息 Failed to store pipelines 并不有用。

临时解决方案
验证您的数据连接凭证是否正确,并且您具有对您指定的存储桶的写权限。

RHOAIENG-1207 (以前称为 ODH-DASHBOARD-1758)- 多次复制 OOTB 自定义服务运行时错误

如果您多次重复模型保留运行时,重复会失败,并显示 Serving 运行时名称 "<name>" already exists 错误信息。

临时解决方案
metadata.name 字段更改为一个唯一值。

RHOAIENG-133 - 现有工作台无法在工作台重启后运行 Elyra 管道

如果您使用 Elyra JupyterLab 扩展在 JupyterLab 中创建并运行管道,并在创建工作台 配置管道服务器,并在工作台中指定工作台镜像后,您无法执行管道,即使在重启工作台后也无法执行管道。

临时解决方案
  1. 停止正在运行的工作台。
  2. 编辑工作台以进行小修改。例如,添加新的 dummy 环境变量,或删除现有的不必要的环境变量。保存您的更改。
  3. 重启工作台。
  4. 在 JupyterLab 左侧边栏中,单击 Runtimes
  5. 确认选择了默认运行时。

RHODS-12798 - Pod 失败并显示 "unable to init seccomp" 错误

Pod 会失败,并显示 CreateContainerError 状态或 Pending 状态而不是 Running 状态,因为已知内核错误引入了 seccomp 内存泄漏。当您检查 pod 失败的命名空间中的事件时,或运行 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
Copy to Clipboard Toggle word wrap
临时解决方案
增加 net.core.bpf_jit_limit 的值,如红帽知识库解决方案 Pod 失败,并将 seccomp 过滤器错误加载到 OpenShift 4 中的 kernel: errno 524

KUBEFLOW-177 - Bearer 令牌来自没有由 OAuth-proxy 转发的应用程序

如果应用程序基于 bearer 令牌,则无法将应用程序用作自定义工作台镜像。OAuth-proxy 配置从标头中删除 bearer 令牌,应用程序无法正常工作。

临时解决方案
无。

如果您已经从 OpenShift AI 仪表板注销,KUBEFLOW-157 - logging out of JupyterLab 无法正常工作

如果您在从 JupyterLab 注销前注销 OpenShift AI 仪表板,则注销 JupyterLab 将无法成功。例如,如果您知道 Jupyter 笔记本的 URL,您可以在浏览器中再次打开它。

临时解决方案
在从 OpenShift AI 仪表板注销前,先从 JupyterLab 注销。

RHODS- 7718- 没有仪表板权限的用户可以无限期地使用其正在运行的工作台

当 Red Hat OpenShift AI 管理员撤销用户权限时,用户可以无限期地继续使用其正在运行的工作台。

临时解决方案
当 OpenShift AI 管理员撤销用户权限时,管理员还应停止该用户的任何正在运行的工作台。

RHODS-554 3- 使用 NVIDIA GPU Operator 时,Node Autoscaler 创建的节点数量要多

当因为可用资源不足而无法调度 pod 时,Node Autoscaler 将创建一个新节点。在新创建的节点接收相关 GPU 工作负载前会有一个延迟。因此,pod 无法调度,Node Autoscaler 会不断创建额外的新节点,直到其中一个节点准备好接收 GPU 工作负载。有关此问题的更多信息,请参阅红帽知识库解决方案 使用 NVIDIA GPU Operator 时,超过 Node Autoscaler 创建的节点数量

临时解决方案
machineset.spec.template.spec.metadata 中应用 cluster-api/accelerator 标签。这会导致自动扩展将这些节点视为未就绪,直到部署了 GPU 驱动程序。

RHODS-4799 - Tensorboard 需要手动步骤才能查看

当用户有 TensorFlow 或 PyTorch workbench 镜像,并希望使用 TensorBoard 显示数据,需要手动步骤在工作台环境中包含环境变量,并在您的代码中导入这些变量。

临时解决方案

当您启动基本工作台时,使用以下代码来设置 TENSORBOARD_PROXY_URL 环境变量的值,以使用您的 OpenShift AI 用户 ID。

import os
os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"
Copy to Clipboard Toggle word wrap

RHODS-47 18- Intel® oneAPI AI Analytics Toolkits 快速开始引用不存在的示例笔记本

Intel® OneAPI AI Analytics Toolkits 快速开始(位于仪表板上的 Resources 页面中),要求用户以指令步骤的一部分加载示例笔记本,但引用相关存储库中不存在的笔记本。

临时解决方案
无。

RHOAING-1147 (以前称为 RHODS-2881)- 在仪表板上的操作没有明确可见

仪表板操作重新验证禁用的应用程序许可证,并删除禁用的应用程序标题对用户没有明确可见。当用户点击应用程序标题的 Disabled 标签时,会出现这些操作。因此,预期的工作流可能对用户并不明确。

临时解决方案
无。

RHODS-2096 - IBM Watson Studio 不在 OpenShift AI

当在 OpenShift Dedicated 4.9 或更高版本上安装 OpenShift AI 时,IBM Watson Studio 不可用,因为它与这些版本的 OpenShift Dedicated 不兼容。

临时解决方案
联系 红帽客户门户 以获取在 OpenShift Dedicated 4.9 及更高版本上手动配置 Watson Studio 的帮助。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat