发行注记

您无法从 OpenShift AI 2.25 或任何更早的版本升级到 3.0。OpenShift AI 3.0 引入了重要的技术和组件更改，仅适用于新的安装。要使用 OpenShift AI 3.0，请在运行 OpenShift Container Platform 4.19 或更高版本的集群中安装 Red Hat OpenShift AI Operator，然后选择 fast-3.x 频道。

以后的发行版本中会提供升级的支持，包括从 OpenShift AI 2.25 升级到一个稳定的 3.x 版本。

如需更多信息，请参阅 为什么升级到 OpenShift AI 3.0 知识库文章。

Red Hat OpenShift AI 是人工智能和机器学习(AI/ML)应用程序的数据科学家和开发人员的平台。

OpenShift AI 提供了一个环境，以便在内部或云中开发、培训、服务、测试和监控 AI/ML 模型和应用程序。

对于数据科学家，OpenShift AI 包括 Jupyter 和默认工作台镜像集合，使用模型开发所需的工具和库以及 TensorFlow 和 PyTorch 框架进行优化。部署并托管您的模型、将模型集成到外部应用程序中，并在任何混合云环境中导出模型以托管它们。您可以使用 Docker 容器构建带有 AI 管道的可移植机器学习(ML)工作流来增强 OpenShift AI 上的项目。您还可以使用图形处理单元(GPU)和 Intel Gaudi AI Accelerators 来加快数据科学试验。

对于管理员，OpenShift AI 在现有 Red Hat OpenShift 或 ROSA 环境中启用数据科学工作负载。使用您现有的 OpenShift 身份提供程序来管理用户，并管理可供工作台使用的资源，以确保数据科学家具有创建、培训和主机模型所需的内容。使用加速器降低成本并允许数据科学家使用图形处理单元(GPU)和 Intel Gaudi AI 加速器提高其端到端数据科学工作流的性能。

OpenShift AI 有两个部署选项：

有关 OpenShift AI 支持的软件平台、组件和依赖项的详情，请查看 3.x 支持的配置。

有关 3.0 发行生命周期的详细视图，包括完全支持阶段窗口，请参阅 Red Hat OpenShift AI Self-Managed Life Cycle 知识库文章。

本节介绍 Red Hat OpenShift AI 3.0 中的新功能和增强。

本节论述了对 Red Hat OpenShift AI 中面向用户的功能支持的主要更改。有关 OpenShift AI 支持的软件平台、组件和依赖项的详情，请查看 3.x 支持的配置。

error: error connecting to datastore: Dirty database version {version}. Fix and force version.

在 Red Hat OpenShift AI 3.0 中解决了以下显著问题。Red Hat OpenShift AI 3.0 的安全更新、程序错误修正和增强将会以异步勘误的形式发布。所有 OpenShift AI 勘误公告都发布 在红帽客户门户上。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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。

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

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

修复现有的工作台：

如需更多信息，请参阅迁移指南： 网关 API 迁移指南。

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

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

RHOAIENG-378 42- Ray 工作负载需要 ray.init （），无法触发 OpenShift AI

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

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

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

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

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

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

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

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

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

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

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

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

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

packages_to_install=[
    "transformers==4.57.1",
    "trl==0.24.0"
]

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

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

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

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

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

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

cluster.up()
cluster.wait_ready()

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

在使用 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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

从 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 状态中的模型。这些选项仅在成功部署模型后可用。

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

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

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

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

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

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

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)相关的错误。

由于使用统计目录访问，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'

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

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

当请求的资源超过阈值时，不会显示 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 资源可能会失败。

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

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

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

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

在断开连接的环境中不支持 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 状态，即使在管道执行完成后也是如此。

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

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

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

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

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

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

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

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 端点会返回错误。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 不兼容。

Red Hat OpenShift AI 为数据科学家和集群管理员提供一组丰富的功能。如需更多信息，请参阅 Red Hat OpenShift AI 简介。