第 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
Invalid numeric literal at line 1, column 20
此错误可能会导致服务 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 状态。相反,资源会显示类似以下示例的状态:
- 临时解决方案
- 无。
当在 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
registry:
local:
server:
restAPI: false
在 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 文件来创建到网关链接的路由:
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"
]
packages_to_install=[
"transformers==4.57.1",
"trl==0.24.0"
]
当没有连接时,在模型部署中缺少 RHOAIENG-36757 - 现有集群存储选项
当在没有定义数据连接的项目中创建模型部署时,不会显示 Existing cluster storage 选项,即使项目中存在适当的持久性卷声明(PVC)。这可防止您为模型部署选择现有 PVC。
- 临时解决方案
- 在项目中创建类型为 URI 的一个连接,使 现有集群存储选项 出现。
RHOAIENG-310 71- Parquet datasets 不支持 IBM Z (s390x)
某些内置评估任务,如 arc_easy 和 arc_challenge,使用 Hugging Face 以 Parquet 格式提供的数据集。IBM Z 不支持 Parquet。
- 临时解决方案
- 无。要评估 IBM Z 上的模型,请使用支持格式而不是 Parquet 的数据集。
RHAIENG-1795 - 带有 Ray 的 CodeFlare 无法使用网关
当运行以下命令时,输出表示 Ray 集群已创建并正在运行,但单元永远不会完成,因为网关路由无法正确响应:
cluster.up() cluster.wait_ready()
cluster.up()
cluster.wait_ready()
因此,获取 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]
[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-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自定义资源中添加以下环境变量,以离线使用嵌入模型:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
从 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
$ 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
使用外部 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 端点验证需要手动路由创建。
当模型部署 pod 启动并运行时,在 YAML 文件中定义带有以下内容的 edge-terminated
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 要发送 inference 请求,请输入以下命令:
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-3369 7- Unable to Edit or Delete model,除非状态为"Started"
当您在 NVIDIA NIM 或单型号服务平台上部署模型时,操作菜单中的 Edit 和 Delete 选项不适用于 Starting 或 Pending 状态中的模型。这些选项仅在成功部署模型后可用。
- 临时解决方案
- 等待模型处于 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
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,容器内存用量将稳定,重启循环将停止。
创建 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'
Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
...
PermissionError: [Error 13] Permission denied: '/.config'
- 临时解决方案
-
要防止这个错误并阻止使用统计日志记录,请在 inference 服务部署中设置
VLLM_NO_USAGE_STATS=1环境变量。这会禁用自动使用报告,避免在写入系统目录时的权限问题。
RHOAIENG-24545 - Runtime 镜像在第一次启动后不会出现在工作台中
运行时镜像列表无法正确填充命名空间中的第一个运行工作台实例,因此 Elyra pipeline 编辑器中没有显示镜像进行选择。
- 临时解决方案
- 重启工作台。重启工作台后,运行时镜像列表会填充工作台和 Elyra 管道编辑器的选择框。
当请求的资源超过阈值时,不会显示 RHOAIENG-2020 9- Warning 信息
当您点 Distributed workloads
- 临时解决方案
- 无。
SRVKS-1301 (以前称为 RHOAIENG-18590)- KnativeServing 资源在禁用并启用 KServe 后会失败
在 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-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 状态,即使在管道执行完成后也是如此。
- 临时解决方案
您可以通过检查没有子任务保持活动状态来确认管道是否仍在运行。
-
从 OpenShift AI 仪表板,点 Development & training
Pipelines Runs。 - 在 Project 列表中点击您的数据科学项目。
- 在 Runs 选项卡中,点您要检查状态的管道运行。
展开 condition 组,再单击子任务。
此时会显示包含子任务信息的面板
在面板中点 Task details 选项卡。
Status 字段显示子任务的正确状态。
-
从 OpenShift AI 仪表板,点 Development & training
RHOAIENG-6409 - Cannot save 参数 错误会出现在管道日志中成功运行
当您多次运行管道时,Cannot save 参数 错误会出现在管道日志中成功运行。您可以安全地忽略这些错误。
- 临时解决方案
- 无。
RHOAIENG-3025 - OVMS 预期目录布局与 KServe StoragePuller 布局冲突
当您使用 OpenVINO 模型服务器(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 兼容存储中的 /& 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 中创建并运行管道,并在创建工作台 后 配置管道服务器,并在工作台中指定工作台镜像后,您无法执行管道,即使在重启工作台后也无法执行管道。
- 临时解决方案
- 停止正在运行的工作台。
- 编辑工作台以进行小修改。例如,添加新的 dummy 环境变量,或删除现有的不必要的环境变量。保存您的更改。
- 重启工作台。
- 在 JupyterLab 左侧边栏中,单击 Runtimes。
- 确认选择了默认运行时。
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
runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524
- 临时解决方案
-
增加
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/"
import os os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 的帮助。