管理和监控模型
在 Red Hat OpenShift AI Cloud Service 中管理和监控模型
摘要
第 1 章 管理模型运行时 复制链接链接已复制到粘贴板!
作为集群管理员,您可以创建一个自定义模型运行时,并为 OpenShift AI 中部署模型编辑 inference 服务。
1.1. 为单模型服务平台添加自定义模型运行时 复制链接链接已复制到粘贴板!
模型运行时增加了对指定模型框架和这些框架支持的模型格式的支持。您可以使用 OpenShift AI 中包含的 预安装运行时。如果默认运行时不满足您的需要,您还可以添加自己的自定义运行时。
作为管理员,您可以使用 OpenShift AI 接口来添加和启用自定义模型运行时。然后,您可以在单模式服务平台上部署模型时选择自定义运行时。
红帽不提供对自定义运行时的支持。您需要确保获得许可来使用您添加的任何自定义运行时,以及正确配置和维护它们。
先决条件
- 您已以具有 OpenShift AI 管理员特权的用户身份登录到 OpenShift AI。
- 您已构建自定义运行时,并将镜像添加到容器镜像存储库中,如 Quay。
流程
在 OpenShift AI 仪表板中点 Settings → Serving runtime。
Serving 运行时 页面将打开,并显示已安装和启用的模型服务运行时。
要添加自定义运行时,请选择以下选项之一:
- 要使用现有运行时(例如,vLLM NVIDIA GPU ServingRuntime for KServe)启动,请点现有运行时旁的操作菜单(WWN),然后点 Duplicate。
- 要添加新的自定义运行时,请点 Add serving runtime。
- 在 Select the model service platform this runtime support 列表中,选择 Single-model serving platform。
- 在 Select the API 协议中,这个运行时支持 列表,选择 REST 或 gRPC。
可选:如果您启动一个新的运行时(而不是复制现有运行时),请选择以下选项之一来添加代码:
上传 YAML 文件
- 点 Upload files。
在文件浏览器中,选择计算机上的 YAML 文件。
嵌入的 YAML 编辑器将打开,并显示您上传的文件内容。
在编辑器中直接输入 YAML 代码
- 点 Start from scratch。
- 在嵌入式编辑器中直接输入或粘贴 YAML 代码。
注意在很多情况下,创建自定义运行时需要在
ServingRuntime规格的env部分中添加新或自定义参数。点击 Add。
Serving 运行时页面将打开,并显示所安装的运行时的更新列表。观察您添加的自定义运行时会自动启用。显示您在创建运行时时指定的 API 协议。
- 可选: 要编辑自定义运行时,点操作菜单(需要)并选择 Edit。
验证
- 您添加的自定义模型运行时显示在 Serving 运行时 页面中的 enabled 状态。
第 2 章 在单模型服务平台上管理和监控模型 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在单模式服务平台上管理和监控模型。您可以为单模型服务平台配置监控,在多个 GPU 节点部署模型,并设置 Grafana 仪表板来视觉化实时指标以及其他任务。
2.1. 为 KServe 设置超时 复制链接链接已复制到粘贴板!
当部署大型模型或使用 KServe 的节点自动扩展时,操作可能会在部署模型前超时,因为 KNative Serving 集的默认 progress-deadline 为 10 分钟。
如果部署使用 KNative Serving 的 pod 需要的时间超过 10 分钟,则 pod 可能会自动标记为失败。如果您部署的大型模型需要超过 10 分钟才能从 S3 兼容对象存储中提取,或者使用节点自动扩展来减少 GPU 节点的消耗,会出现这种情况。
要解决这个问题,您可以在应用程序的 KServe InferenceService 中设置自定义 progress-deadline。
先决条件
- 具有 OpenShift 集群的命名空间编辑访问权限。
流程
- 以集群管理员身份登录 OpenShift 控制台。
- 选择部署模型的项目。
- 在 Administrator 视角中,点击 Home → Search。
-
从 资源 下拉菜单中,搜索
InferenceService。 在
spec.predictor.annotations下,使用新超时修改service.knative.dev/progress-deadline:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意确保在
spec.predictor.annotations级别上设置progress-deadline,以便 KServeInferenceService可以将progress-deadline复制到 KNative Service 对象。
2.2. 使用多个 GPU 节点部署模型 复制链接链接已复制到粘贴板!
在多个 GPU 节点间部署模型以处理大型模型,如大型语言模型(LLM)。
您可以使用 vLLM 服务框架在多个 GPU 节点上提供 Red Hat OpenShift AI 的模型。多节点 inferencing 使用 vllm-multinode-runtime 自定义运行时,它使用与 vLLM NVIDIA GPU ServingRuntime for KServe 运行时相同的镜像,还包括多 GPU 推断所需的信息。
您可以从持久性卷声明(PVC)或开放容器项目(OCI)容器镜像部署模型。
目前,Red Hat OpenShift AI 作为技术预览功能通过多个 GPU 节点部署模型。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围
先决条件
- 具有集群管理员特权。
- 您已下载并安装 OpenShift 命令行界面 (CLI)。如需更多信息,请参阅安装 OpenShift CLI (Red Hat OpenShift Dedicated)或 安装 OpenShift CLI (Red Hat OpenShift Service on AWS)。
您已为 GPU 类型启用了 Operator,如 Node Feature Discovery Operator、Nvidia GPU Operator。有关启用加速器的更多信息,请参阅启用加速器。
-
您使用 NVIDIA GPU (
nvidia.com/gpu)。 -
您已通过
ServingRuntime或InferenceService指定 GPU 类型。如果ServingRuntime中指定的 GPU 类型与InferenceService中设置的不同,则两个 GPU 类型都会分配给资源,并可能导致错误。
-
您使用 NVIDIA GPU (
- 您已在集群中启用了 KServe。
-
您设置中只有一个 head pod。不要在
InferenceService中使用min_replicas或max_replicas设置来调整副本数。创建其他 head pod 可能会导致它们排除在 Ray 集群中。 - 要从 PVC 部署 :您为 ReadWriteMany (RWX)访问模式设置并配置了持久性卷声明(PVC)。
从 OCI 容器镜像部署 :
- 您已在 OCI 容器镜像中存储了一个模型。
- 如果模型存储在私有 OCI 存储库中,则代表您配置了镜像 pull secret。
流程
在一个终端窗口中,如果您还没有以集群管理员登录到 OpenShift 集群,请登录 OpenShift CLI,如下例所示:
oc login <openshift_cluster_url> -u <admin_username> -p <password>
$ oc login <openshift_cluster_url> -u <admin_username> -p <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 选择或创建用于部署模型的命名空间。例如,运行以下命令来创建
kserve-demo命名空间:oc new-project kserve-demo
oc new-project kserve-demoCopy to Clipboard Copied! Toggle word wrap Toggle overflow (仅从 PVC 部署模型) 在要部署模型的命名空间中为模型存储创建一个 PVC。使用
Filesystem volumeMode创建存储类,并将这个存储类用于 PVC。存储大小必须大于磁盘上模型文件的大小。例如:注意如果您已经配置了 PVC 或从 OCI 容器镜像部署模型,您可以跳过此步骤。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 pod,将模型下载到您创建的 PVC。使用存储桶名称、模型路径和凭证更新示例 YAML:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 只有在 pod 以 root 用户身份运行时,才允许
chmod操作。如果您没有以 root 身份运行 pod,请从参数中删除'chmod -R 777'。 - 2 7
- 指定到模型的路径。
- 3
containers.image的值,位于您的InferenceService中。要访问这个值,请运行以下命令:oc get configmap inferenceservice-config -n redhat-ods-operator -oyaml | grep kserve-storage-initializer:- 4
- S3 存储桶的访问密钥 ID。
- 5
- S3 存储桶的 secret 访问密钥。
- 6
- S3 存储桶的名称。
- 8
- S3 存储桶的端点。
- 9
- 如果使用 AWS S3 存储桶,则 S3 存储桶的区域。如果使用其他 S3 兼容存储,如 ODF 或 Minio,您可以删除
AWS_DEFAULT_REGION环境变量。 - 10
- 如果您遇到 SSL 错误,请将
S3_VERIFY_SSL更改为false。
在项目命名空间中创建
vllm-multinode-runtime自定义运行时:oc process vllm-multinode-runtime-template -n redhat-ods-applications|oc apply -n kserve-demo -f -
oc process vllm-multinode-runtime-template -n redhat-ods-applications|oc apply -n kserve-demo -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下
InferenceService配置部署模型:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 根据您的部署方法指定模型的路径:
-
对于 PVC:
pvc://<pvc_name>/<model_path> -
对于 OCI 容器镜像 :
oci://<registry_host>/<org_or_username>/<repository_name><tag_or_digest>
-
对于 PVC:
- 2
- 以下配置可以添加到
InferenceService中:-
workerSpec.tensorParallelSize:确定每个节点使用多少个 GPU。head 和 worker 节点部署资源中的 GPU 类型计数会自动更新。确保workerSpec.tensorParallelSize的值至少为1。 workerSpec.pipelineParallelSize: 确定使用多少个节点来平衡部署中的模型。此变量代表节点总数,包括头和 worker 节点。确保workerSpec.pipelineParallelSize的值至少为2。不要在生产环境中修改这个值。注意根据环境和模型大小,您可能需要指定其他参数。
-
通过应用
InferenceService配置来部署模型:oc apply -f <inference-service-file.yaml>
oc apply -f <inference-service-file.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要确认您已将环境设置为在多个 GPU 节点上部署模型,请检查 GPU 资源状态、InferenceService 状态、Ray 集群状态,并将请求发送到模型。
检查 GPU 资源状态:
检索 head 和 worker 节点的 pod 名称:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 响应示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过检查 <1> 和 <2> 的值来确认模型是否已正确加载。如果模型没有加载,则这些字段的值为
0MiB。
使用以下命令验证
InferenceService的状态: 注意:在技术预览中,您只能使用端口转发来推断。oc wait --for=condition=ready pod/${podName} -n $DEMO_NAMESPACE --timeout=300s export MODEL_NAME=granite-8b-code-base-pvcoc wait --for=condition=ready pod/${podName} -n $DEMO_NAMESPACE --timeout=300s export MODEL_NAME=granite-8b-code-base-pvcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 响应示例
NAME URL READY PREV LATEST PREVROLLEDOUTREVISION LATESTREADYREVISION AGE granite-8b-code-base-pvc http://granite-8b-code-base-pvc.default.example.com
NAME URL READY PREV LATEST PREVROLLEDOUTREVISION LATESTREADYREVISION AGE granite-8b-code-base-pvc http://granite-8b-code-base-pvc.default.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 向模型发送请求,以确认模型可用于推测:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. 为 Kueue 配置 inference 服务 复制链接链接已复制到粘贴板!
要排队您的 inference 服务工作负载并管理其资源,请将 kueue.x-k8s.io/queue-name 标签添加到服务的元数据中。此标签将工作负载定向到特定的 LocalQueue 管理,只有在项目为 Kueue 启用了时才需要。如需更多信息,请参阅使用 Kueue 管理工作负载。
先决条件
- 您有编辑部署模型项目中的资源的权限。
- 作为集群管理员,您已安装并激活了红帽构建的 Kue Operator,如 使用 Kue 配置工作负载管理 中所述。
流程
要配置 inference 服务,请完成以下步骤:
- 登录 OpenShift 控制台。
-
在 Administrator 视角中,导航到您的项目并找到您的模型的
InferenceService资源。 - 点 InferenceService 的名称查看其详情。
- 选择 YAML 选项卡以打开编辑器。
在
metadata部分中,在标签 下添加kueue.x-k8s.io/queue-name标签。将 <local-queue-name> 替换为目标LocalQueue的名称。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 点击 Save。
验证
-
工作负载提交到
kue.x-k8s.io/queue-name标签中指定的LocalQueue。 - 当所需的集群资源可用时,工作负载会启动,并由队列接受。
可选: 要验证,请运行以下命令并查看
Admitted Workloads部分:oc describe localqueue <local-queue-name> -n <project-namespace>
$ oc describe localqueue <local-queue-name> -n <project-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. 优化性能和调整 复制链接链接已复制到粘贴板!
您可以优化并调优部署的模型,以平衡速度、效率以及不同用例的成本。
要评估模型的 inference 性能,请考虑以下关键指标:
- latency :生成响应所需的时间,对于实时应用程序至关重要。这包括 HEKETITime-to-First-Token (TTFT)和 Inter-Token Latency (ITL)。
- 吞吐量:模型服务器的整体效率,以每秒(TPS)或请求每秒(RPS)来衡量。
- 每百万令牌的成本:模型推测的经济性。
根据模型大小、可用 GPU 内存和输入序列长度等因素影响性能,特别是对于文本恢复和检索生成(RAG)等应用程序。要满足性能要求,您可以使用量化等技术来减少内存要求或并行性来在多个 GPU 之间分发非常大的模型。
2.4.1. 确定 LLM 支持的应用程序的 GPU 要求 复制链接链接已复制到粘贴板!
在为由 OpenShift AI 上托管的 Large Language Model (LLM)支持的应用程序选择 GPU 时需要考虑以下因素。
以下指南可帮助您根据模型的大小和预期使用,确定应用程序的硬件要求。
-
估算内存需要 :一般的 thumb 规则是 16 位精度中带有
N参数的模型需要大约2N字节。例如,一个 8-billion-parameter 模型需要大约 16GB 的 GPU 内存,而 70-billion-parameter 模型则需要大约 140GB。 Quantization :要减少内存要求并可能提高吞吐量,您可以使用量化来加载或以较低精度格式(如 INT8、FP8 或 INT4)加载或运行模型。这可减少内存占用量,以牺牲模型准确性的降低。
注意KServe 模型服务运行时的 vLLM ServingRuntime 支持多种量化方法。有关支持的实现和兼容硬件的更多信息,请参阅支持的硬件来量化内核。
- 键值缓存的额外内存 :除了模型权重外,还需要 GPU 内存来存储注意的键值(KV)缓存,这会随着请求数量和每个请求的序列长度增加。这可能会影响实时应用程序的性能,特别是对于大型模型。
推荐的 GPU 配置 :
- 小模型(1B-8B 参数) :对于范围内的模型,带有 24GB 内存的 GPU 通常足以支持少量并发用户。
Medium Models (10B-34B 参数) :
- 20B 参数下的模型需要至少 48GB 的 GPU 内存。
- 20B 间的模型 - 34B 参数在单个 GPU 中至少需要 80GB 或更多内存。
- 大型模型(70B 参数) :此范围内的模型可能需要使用 10sor parallelism 技术在多个 GPU 之间分发。Tensor parallelism 允许模型跨越多个 GPU,通过释放 KV 缓存的额外内存来提高内部令牌延迟并增加最大批处理大小。当 GPU 具有快速互连(如 NVLink)时,Tensor parallelism 可以正常工作。
- 超大 模型(405B 参数): 对于非常大的模型,建议量化来减少内存需求。您还可以在多个 GPU 中使用管道并行分发模型,甚至在两个服务器间分发。这种方法允许您扩展单个服务器的内存限制,但为了获得最佳性能,需要仔细管理服务器间的通信。
为获得最佳结果,从较小的模型开始,然后根据需要扩展到更大的模型,使用并行和量化等技术以满足您的性能和内存要求。
2.4.2. 文本恢复和检索生成(RAG)应用程序的性能注意事项 复制链接链接已复制到粘贴板!
还有额外的因素,需要考虑文本恢复和 RAG 应用,以及处理用户上传的大型文档的 LLM 支持的服务。
- 较长的输入 序列:如果每个用户查询包含大型提示或大量上下文,则输入序列长度可能比典型的聊天应用程序要长得多。较长的输入序列长度会增加 填充时间,模型在生成响应前处理初始输入序列所需的时间,然后可能导致更高的 生存时间(TTFT)。较长的 TTFT 可能会影响应用程序的响应。最小化这个延迟以获得最佳用户体验。
- KV Cache Usage: Longer sequences 需要更多 GPU 内存用于 键值(KV)缓存。KV 缓存存储中间关注数据,以便在生成期间提高模型性能。每个请求的高 KV 缓存利用率需要有足够 GPU 内存的硬件设置。如果多个用户同时查询模型,这尤其重要,因为每个请求都会添加到总内存负载中。
- 最佳硬件配置 :为了保持响应速度并避免内存瓶颈,请选择具有足够内存的 GPU 配置。例如,无需在单个 24GB GPU 上运行 8B 模型,在更大的 GPU (如 48GB 或 80GB)上部署它,或通过为 KV 缓存提供更多内存空间并降低令牌延迟来提高性能。带有十个并行性的多GPU设置也可以帮助管理内存需求,并提高更大输入序列的效率。
总之,要确保基于文档的应用程序的最佳响应性和可扩展性,您必须优先选择具有高 GPU 内存容量的硬件,并考虑多 GPU 配置,以处理长输入序列和 KV 缓存增加的内存要求。
2.4.3. inference 性能指标 复制链接链接已复制到粘贴板!
延迟、吞吐量 和成本每百万令牌是 评估模型在推断过程中的响应生成效率时需要考虑的关键指标。这些指标提供了模型推测性能的综合视图,有助于平衡不同用例的速度、效率和成本。
2.4.3.1. latency 复制链接链接已复制到粘贴板!
对交互式或实时用例 的延迟 至关重要,并使用以下指标来测量:
- time-to-First-Token (TTFT) :初始请求和第一个令牌的生成之间的延迟(毫秒)。此指标对于流响应非常重要。
- Inter-Token Latency (ITL) :在第一个令牌后生成每个后续令牌所需的时间(以毫秒为单位),也与流相关。
- time -Per-Output-Token (TPOT): 对于非流请求,在输出序列中生成每个令牌的平均时间(毫秒)。
2.4.3.2. 吞吐量 复制链接链接已复制到粘贴板!
吞吐量 测量模型服务器的整体效率,并使用以下指标表示:
- Token per Second (TPS) :在所有活跃请求之间每秒生成的令牌总数。
- 每秒请求数(RPS) :每秒处理的请求数。RPS 与响应时间一样,对序列长度非常敏感。
2.4.3.3. 每百万令牌的成本 复制链接链接已复制到粘贴板!
每 Million 令牌的成本测量模型推测的经济性,表明了每百万个令牌所产生的成本。该指标有助于评估部署模型的经济可行性和可扩展性。
2.4.4. 配置基于指标的自动扩展 复制链接链接已复制到粘贴板!
基于指标的自动缩放目前在 Red Hat OpenShift AI 中作为技术预览功能提供。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
基于 Knative 的自动扩展在标准部署模式中不可用。但是,您可以在标准部署模式中为 inference 服务启用基于指标的自动扩展。基于指标的自动扩展可帮助您有效地管理加速器资源、操作成本并确保您的 inference 服务满足性能要求。
要在标准部署中为您的 inference 服务设置自动扩展,请安装和配置基于 Kubernetes 事件驱动的自动扩展(KEDA)的 OpenShift 自定义 Metrics Autoscaler (CMA)。然后,您可以使用 OpenShift Monitoring 中的各种模型运行时指标来触发对 inference 服务的自动扩展,如 KVCache 使用率、到第一个令牌(TTFT)和 Concurrency。
先决条件
- 具有集群管理员特权。
在集群中安装了 CMA Operator。如需更多信息 ,请参阅安装自定义指标自动扩展。
注意-
安装 CMA operator 后,您必须配置
KedaController资源。 -
odh-controller会自动创建TriggerAuthentication,ServiceAccount, Role ,Role,RoleBinding, 和Secret资源,以允许 CMA 访问 OpenShift Monitoring 指标。
-
安装 CMA operator 后,您必须配置
- 您已为集群启用了用户工作负载监控(UWM)。如需更多信息,请参阅配置用户工作负载监控。
- 您已在标准部署模式中以单模式服务平台部署了模型。
流程
- 以集群管理员身份登录 OpenShift 控制台。
- 在 Administrator 视角中,点击 Home → Search。
- 选择部署模型的项目。
- 从 资源 下拉菜单中,选择 InferenceService。
-
单击您部署的模型的
InferenceService,然后单击 YAML。 在
spec.predictor下,定义基于指标的自动扩展策略,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 示例配置将 inference 服务设置为根据等待处理的请求数在 1 到 5 个副本之间自动扩展,如
vllm:num_requests_waiting指标所示。- 点击 Save。
验证
确认 KEDA
ScaledObject资源已创建:oc get scaledobject -n <namespace>
oc get scaledobject -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.5. 基于指标的自动扩展指南 复制链接链接已复制到粘贴板!
您可以使用基于指标的自动扩展来根据延迟或以吞吐量为中心的服务级别目标(SLO)来扩展 AI 工作负载,而不是传统的请求并发。基于指标的自动扩展基于 Kubernetes 事件驱动的自动扩展(KEDA)。
传统的扩展方法取决于请求并发、请求率或 CPU 使用率等因素不适用于扩展 GPU 的 LLM inference 服务器。相反,vLLM 容量由 GPU 的大小以及同时处理的令牌总数决定。您可以使用自定义指标来帮助自动扩展决策来满足 SLO。
以下准则可帮助您自动扩展 AI inference 工作负载,包括选择指标、定义分片窗口、配置 HPA 缩减设置,以及采用模型大小来获得最佳性能。
2.4.5.1. 为延迟和吞吐量优化扩展选择指标 复制链接链接已复制到粘贴板!
对于对延迟敏感的应用程序,请选择扩展指标,具体取决于请求的特性:
- 当序列长度不同时,请使用服务级别目标(SLO)用于到第一个令牌(TTFT)和 Inter-Token Latency (ITL)。这些指标提供更多的缩放信号,因为它们会受到一定程度的变化的影响。
-
当请求有类似的序列长度时,使用
端到端请求延迟来触发自动扩展。
端到端(e2e)请求延迟取决于序列长度,在输入/输出令牌计数中造成大量用例的挑战。10 令牌完成和 2000 个令牌完成将具有大量不同的延迟,即使在相同的系统条件下也是如此。要在没有延迟限制的情况下最大化吞吐量,请使用 vllm:num_requests_waiting > 0.1 metric (KEDA scaledObject not support a threshold 0)来扩展您的工作负载。此指标在请求排队后立即扩展系统,从而最大化利用率并防止积压。当输入和输出序列长度一致时,此策略最适合。
要构建有效的基于指标的自动扩展功能,请遵循以下最佳实践:
选择正确的指标:
- 分析您的负载模式,以确定序列长度差异。
- 为高变量工作负载选择 TTFT/ITL,为统一工作负载选择 E2E 延迟。
- 通过不同优先级实施多个指标,实现强大的扩展决策。
逐渐调优配置:
- 从保守阈值和较长的窗口开始。
- 监控一段时间内的扩展行为和 SLO 合规性。
- 根据观察到的模式和业务需求优化配置。
通过测试验证行为:
- 使用真实序列长度分布运行负载测试。
- 验证各种流量模式下的扩展。
- 测试边缘情况,如流量激增和逐步负载增加。
2.4.5.2. 选择右滑窗口 复制链接链接已复制到粘贴板!
sliding 窗口长度是聚合或评估指标以做出缩放决策的时间周期。滑动窗口长度的长度会影响到扩展响应性和稳定性。
理想的窗口长度取决于您使用的指标:
- 对于第一个令牌(TTFT)和 Inter-Token Latency (ITL)指标的时间,您可以使用较短的窗口(1-2 分钟),因为它们不太不确定。
- 对于端到端延迟指标,您需要较长的窗口(4 到 5 分钟)以序列长度考虑变化。
| 窗口长度 | 特性 | 最适合 |
|---|---|---|
| 短(表示 30 秒以上) | 如果指标提取间隔太长,则不会有效地触发自动扩展。 | 不建议。 |
| 中(60 秒) | 快速响应负载变化,但可能会导致成本更高。可能会导致快速扩展和缩减,也称为 thrashing。 | 具有 sharp, 不可预测的工作负载。 |
| 长(覆盖 4 分钟) | 平衡响应性和稳定性,同时减少不必要的扩展。可能会造成短暂的激增,并缓慢地适应负载变化。 | 具有中等差异的生产工作负载。 |
2.4.5.3. 优化 HPA 缩减配置 复制链接链接已复制到粘贴板!
有效的缩减配置对于成本优化和资源效率至关重要。它需要平衡需要快速终止空闲的 pod 以减少集群负载,并考虑维护它们以避免冷启动时间。用于缩减 Pod 的 Horizontal Pod 配置在及时删除空闲 pod 时扮演重要角色,并防止不必要的资源使用量。
您可以通过管理 KEDA scaledObject 自定义资源(CR)来控制 HPA 缩减行为。此自定义资源(CR)为特定工作负载启用事件驱动的自动扩展。
要设置 HPA 在缩减前等待的时间,请调整 stabilizationWindowSeconds 字段,如下例所示:
2.4.5.4. 为优化扩展考虑模型大小 复制链接链接已复制到粘贴板!
模型大小会影响自动扩展行为和资源使用。下表描述了不同模型大小的典型特征,并描述了为 AI inference 工作负载实施基于指标自动扩展时选择的扩展策略。
| 模型大小 | 内存占用 | 扩展策略 | 冷开始时间 |
|---|---|---|---|
| 小(Less 大于 3B) | 小于 6 GiB | 使用低资源缓冲区的主动扩展。 | 最多 10 分钟可下载 30 秒以加载。 |
| Medium (3B-10B) | 6-20 GiB | 使用更保守的扩展策略。 | 最多 30 分钟可以下载和 1 分钟以加载。 |
| Large (Greater than 10B) | 大于 20 GiB | 可能需要模型分片或量化。 | 最多需要几小时时间下载和分钟以加载。 |
对于少于 3 亿参数的模型,您可以使用以下策略减少冷启动延迟:
- 通过将模型直接嵌入到镜像中,而不是在运行时下载它们来优化容器镜像。您还可以使用多阶段构建来减少最终镜像大小,并使用镜像层缓存更快地拉取容器。
- 持久性卷声明(PVC)上的缓存模型,用于在副本间共享存储。将您的 inference 服务配置为使用 PVC 来访问缓存的模型。
2.5. 使用 Grafana 监控模型性能 复制链接链接已复制到粘贴板!
您可以部署 Grafana 指标仪表板来监控模型的性能和资源使用情况。指标仪表板可帮助您视觉化您的模型运行时和硬件加速器的关键指标。
2.5.1. 部署 Grafana 指标仪表板 复制链接链接已复制到粘贴板!
您可以为用户工作负载监控(UWM)部署 Grafana 指标仪表板,以监控单模型服务平台上部署的模型的性能和资源使用指标。
您可以创建 Kustomize 覆盖,如下例所示。使用覆盖为通过 OpenVino Model Server (OVMS)和 vLLM 部署的模型部署预配置指标仪表板。
先决条件
- 具有 OpenShift 集群的集群 admin 特权。
- 已安装 OpenShift 命令行界面(CLI)。如需更多信息,请参阅安装 OpenShift CLI (OpenShift Dedicated) 或 安装 OpenShift CLI (Red Hat OpenShift Service on AWS)。
您已创建了覆盖来部署 Grafana 实例,如下例所示。
注意要查看 GPU 指标,您必须启用 NVIDIA GPU 监控仪表板,如 启用 GPU 监控仪表板 中所述。GPU 监控仪表板提供对 GPU 使用率、内存用量和其他 GPU 节点的指标的全面视图。
流程
- 在终端窗口中,以集群管理员身份登录 OpenShift CLI。
- 如果您还没有创建覆盖来安装 Grafana operator 和指标仪表板,请参阅 RHOAI UWM 存储库 来创建它。
使用您创建的覆盖在 OpenShift 集群上安装 Grafana 实例和指标仪表板。将
<overlay-name> 替换为覆盖的名称。oc apply -k overlays/<overlay-name>
oc apply -k overlays/<overlay-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检索 Grafana 实例的 URL。将
<namespace> 替换为包含 Grafana 实例的命名空间。oc get route -n <namespace> grafana-route -o jsonpath='{.spec.host}'oc get route -n <namespace> grafana-route -o jsonpath='{.spec.host}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用 URL 访问 Grafana 实例:
grafana-<namespace>.apps.example-openshift.com
grafana-<namespace>.apps.example-openshift.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
- 您可以访问 Grafana 实例上 KServe、vLLM 和 OVMS 的预配置仪表板。
2.5.2. 在 Grafana 实例上部署 vLLM/GPU 指标仪表板 复制链接链接已复制到粘贴板!
部署 Grafana 板以监控加速器和 vLLM 性能指标。
先决条件
- 您已部署了 Grafana 指标仪表板,如 部署 Grafana 指标仪表板 中所述。
- 您可以访问 Grafana 实例。
-
您已安装了
envsubst,这是用于替换配置文件中的环境变量的命令行工具。如需更多信息,请参阅 GNUgettext文档。
流程
在
YAML文件中定义 GrafanaDashboard 对象,如下例所示:-
要监控 NVIDIA 加速器指标,请参阅
nvidia-vllm-dashboard.yaml。 -
要监控 AMD 加速器指标,请参阅
amd-vllm-dashboard.yaml。 -
要监控 Intel 加速器指标,请参阅
gaudi-vllm-dashboard.yaml。 -
要监控 vLLM 指标,请参阅
grafana-vllm-dashboard.yaml。
-
要监控 NVIDIA 加速器指标,请参阅
创建一个类似以下示例的
inputs.env文件。将NAMESPACE和MODEL_NAME参数替换为您自己的值:NAMESPACE=<namespace> MODEL_NAME=<model-name>
NAMESPACE=<namespace>1 MODEL_NAME=<model-name>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过执行以下操作,将 YAML 文件中的
NAMESPACE和MODEL_NAME参数替换为inputs.env文件中的值:将
inputs.env中所述的参数导出为环境变量:export $(cat inputs.env | xargs)
export $(cat inputs.env | xargs)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新以下 YAML 文件,将
${NAMESPACE}和${MODEL_NAME}变量替换为您之前创建的GrafanaDashboard对象 YAML 变量的值,将dashboard_template.yaml替换为之前创建的 GrafanaDashboard 对象 YAML 文件的名称:envsubst '${NAMESPACE} ${MODEL_NAME}' < dashboard_template.yaml > dashboard_template-replaced.yamlenvsubst '${NAMESPACE} ${MODEL_NAME}' < dashboard_template.yaml > dashboard_template-replaced.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 确认 YAML 文件包含更新的值。
部署仪表板对象:
oc create -f dashboard_template-replaced.yaml
oc create -f dashboard_template-replaced.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
您可以在 Grafana 实例上看到加速器和 vLLM 指标仪表板。
2.5.3. Grafana 指标 复制链接链接已复制到粘贴板!
您可以使用 Grafana 板来监控加速器和 vLLM 性能指标。数据源、instance 和 gpu 是板内定义的变量。
2.5.3.1. 加速器指标 复制链接链接已复制到粘贴板!
跟踪加速器的指标,以确保硬件的健康状况。
- NVIDIA GPU 使用率
跟踪 GPU 主动处理任务的时间百分比,指示 GPU 工作负载级别。
查询
DCGM_FI_DEV_GPU_UTIL{instance=~"$instance", gpu=~"$gpu"}
DCGM_FI_DEV_GPU_UTIL{instance=~"$instance", gpu=~"$gpu"}
- NVIDIA GPU 内存使用率
将内存用量与可用内存进行比较,这对于识别 GPU 密集型工作负载中的内存瓶颈至关重要。
查询
DCGM_FI_DEV_POWER_USAGE{instance=~"$instance", gpu=~"$gpu"}
DCGM_FI_DEV_POWER_USAGE{instance=~"$instance", gpu=~"$gpu"}
sum
sum(DCGM_FI_DEV_POWER_USAGE{instance=~"$instance", gpu=~"$gpu"})
sum(DCGM_FI_DEV_POWER_USAGE{instance=~"$instance", gpu=~"$gpu"})
- NVIDIA GPU 温度
确保 GPU 在安全限制内运行,以防止硬件降级。
查询
DCGM_FI_DEV_GPU_TEMP{instance=~"$instance", gpu=~"$gpu"}
DCGM_FI_DEV_GPU_TEMP{instance=~"$instance", gpu=~"$gpu"}
avg
avg(DCGM_FI_DEV_GPU_TEMP{instance=~"$instance", gpu=~"$gpu"})
avg(DCGM_FI_DEV_GPU_TEMP{instance=~"$instance", gpu=~"$gpu"})
- NVIDIA GPU 节流
GPU 节流会在 GPU 自动减少时钟时发生,以避免出现过量问题的问题。
您可以访问以下指标来识别 GPU 节流:
- GPU 温度 :监控 GPU 温度。当 GPU 达到特定温度时,节流通常会发生,例如 85-90°C。
- Osm clock speed: 监控核心时钟速度。当 GPU 处于 load 表示节流时,时钟速度显著下降。
2.5.3.2. CPU 指标 复制链接链接已复制到粘贴板!
您可以跟踪 CPU 上的指标,以确保硬件的健康状况。
- CPU 使用率
跟踪 CPU 使用量以识别 CPU 密集型工作负载。
查询
sum(rate(container_cpu_usage_seconds_total{namespace="$namespace", pod=~"$model_name.*"}[5m])) by (namespace)
sum(rate(container_cpu_usage_seconds_total{namespace="$namespace", pod=~"$model_name.*"}[5m])) by (namespace)
- CPU-GPU 瓶颈
CPU 节流和 GPU 使用指标的组合来识别资源分配无效。下表概述了 CPU 节流和 GPU 利用率的组合,以及您的环境的含义:
| CPU 节流 | GPU 使用率 | 含义 |
|---|---|---|
| 低 | High | 系统经过平衡。在没有 CPU 约束的情况下,会完全使用 GPU。 |
| High | 低 | CPU 资源受限制。CPU 无法跟上 GPU 的处理需求,并且 GPU 可能被使用。 |
| High | High | CPU 和 GPU 的工作负载正在增加,您可能需要扩展资源。 |
查询
sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace", pod=~"$model_name.*"}[5m])) by (namespace)
avg_over_time(DCGM_FI_DEV_GPU_UTIL{instance=~"$instance", gpu=~"$gpu"}[5m])
sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace", pod=~"$model_name.*"}[5m])) by (namespace)
avg_over_time(DCGM_FI_DEV_GPU_UTIL{instance=~"$instance", gpu=~"$gpu"}[5m])
2.5.3.3. vLLM metrics 复制链接链接已复制到粘贴板!
您可以跟踪与 vLLM 模型相关的指标。
- GPU 和 CPU 缓存使用率
跟踪 vLLM 模型使用的 GPU 内存百分比,提供有关内存效率的见解。
查询
sum_over_time(vllm:gpu_cache_usage_perc{namespace="${namespace}",pod=~"$model_name.*"}[24h])
sum_over_time(vllm:gpu_cache_usage_perc{namespace="${namespace}",pod=~"$model_name.*"}[24h])
- 运行请求
主动处理的请求数。帮助监控工作负载并发。
num_requests_running{namespace="$namespace", pod=~"$model_name.*"}
num_requests_running{namespace="$namespace", pod=~"$model_name.*"}
- 等待请求
跟踪队列中的请求,表示系统饱和。
num_requests_waiting{namespace="$namespace", pod=~"$model_name.*"}
num_requests_waiting{namespace="$namespace", pod=~"$model_name.*"}
- 前缀缓存命中率
高命中率意味着有效地重复使用缓存的计算,从而优化资源使用量。
查询
vllm:gpu_cache_usage_perc{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
vllm:cpu_cache_usage_perc{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
vllm:gpu_cache_usage_perc{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
vllm:cpu_cache_usage_perc{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
- 请求总数
查询
vllm:request_success_total{finished_reason="length",namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
vllm:request_success_total{finished_reason="length",namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
请求终止,因为它达到模型 inference 设置的最大令牌限制。
查询
vllm:request_success_total{finished_reason="stop",namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
vllm:request_success_total{finished_reason="stop",namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}
请求根据模型的输出或停止条件而自然完成,例如,句子或令牌完成结束。
- 端到端延迟
- 测量处理请求以获得最佳用户体验的总体时间。
直方查询
- 第一次令牌(TTFT)延迟的时间
在响应中生成第一个令牌所需的时间。
直方查询
- 每个输出令牌(TPOT)延迟的时间
生成每个输出令牌的平均时间。
直方查询
- 提示令牌吞吐量和生成吞吐量
跟踪处理提示令牌的速度,以进行 LLM 优化。
查询
rate(vllm:prompt_tokens_total{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}[5m])
rate(vllm:generation_tokens_total{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}[5m])
rate(vllm:prompt_tokens_total{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}[5m])
rate(vllm:generation_tokens_total{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"}[5m])
- 生成的令牌总数
- 测量生成响应令牌的效率,对于实时应用至关重要。
查询
sum(vllm:generation_tokens_total{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"})
sum(vllm:generation_tokens_total{namespace="$namespace", pod=~"$model_name.*", model_name="$model_name"})
第 3 章 在 NVIDIA NIM 模型服务平台上管理和监控模型 复制链接链接已复制到粘贴板!
作为集群管理员,您可以在 NVIDIA NIM 模型服务平台上管理和监控模型。您可以自定义 NVIDIA NIM 模型选择选项,并为 NIM 模型启用指标,以及其他任务。
3.1. 为 NVIDIA NIM 模型服务平台自定义模型选择选项 复制链接链接已复制到粘贴板!
NVIDIA NIM 模型服务平台提供对 NVIDIA GPU Cloud (NGC)中所有可用 NVIDIA NIM 模型的访问。您可以通过从 Deploy model 对话框中的 NVIDIA NIM 列表中选择它来部署 NIM 模型。要自定义列表中出现的模型,您可以创建一个指定您首选的模型的 ConfigMap 对象。
先决条件
- 具有集群管理员特权。
- 您有一个 NVIDIA Cloud Account (NCA),并可以访问 NVIDIA GPU Cloud (NGC)门户。
您知道要在 NVIDIA NIM 模型服务平台上选择的 NVIDIA NIM 模型的 ID。
注意- 您可以从 NGC Catalog 找到模型 ID。ID 通常是 URL 路径的一部分。
- 您还可以使用 NGC CLI 找到模型 ID。如需更多信息,请参阅 NGC CLI 参考。
-
您知道
帐户自定义资源(CR)的名称和命名空间。
流程
在一个终端窗口中,以集群管理员身份登录到 OpenShift CLI,如下例所示:
oc login <openshift_cluster_url> -u <admin_username> -p <password>
oc login <openshift_cluster_url> -u <admin_username> -p <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 YAML 文件中定义
ConfigMap对象,类似于以下示例中的 ConfigMap 对象,其中包含您要在 NVIDIA NIM 模型服务平台上选择的模型 ID:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确认
帐户 CR 的名称和命名空间:oc get account -A
oc get account -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 您会看到类似以下示例的输出:
NAMESPACE NAME TEMPLATE CONFIGMAP SECRET redhat-ods-applications odh-nim-account
NAMESPACE NAME TEMPLATE CONFIGMAP SECRET redhat-ods-applications odh-nim-accountCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在与您的帐户 CR 相同的命名空间中部署
ConfigMap对象:oc apply -f <configmap-name> -n <namespace>
oc apply -f <configmap-name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 <configmap-name > 替换为您的 YAML 文件的名称,将 & lt;namespace > 替换为您的
帐户CR 的命名空间。将之前创建的
ConfigMap对象添加到AccountCR 的spec.modelListConfig部分:oc patch account <account-name> \ --type='merge' \ -p '{"spec": {"modelListConfig": {"name": "<configmap-name>"}}}'oc patch account <account-name> \ --type='merge' \ -p '{"spec": {"modelListConfig": {"name": "<configmap-name>"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 <account-name > 替换为
帐户CR 的名称,将 & lt;configmap-name& gt; 替换为您的ConfigMap对象。确认
ConfigMap对象已添加到您的帐户 CR中:oc get account <account-name> -o yaml
oc get account <account-name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以在
AccountCR 的spec.modelListConfig部分看到ConfigMap对象,类似于以下输出:spec: enabledModelsConfig: modelListConfig: name: <configmap-name>
spec: enabledModelsConfig: modelListConfig: name: <configmap-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
- 按照以下步骤部署模型,如在 NVIDIA NIM 模型服务平台上部署模型 中所述,以部署 NIM 模型。您会看到 Deploy model 对话框中的 NVIDIA NIM 列表显示您首选的模型列表,而不是 NGC 目录中所有可用的型号。
3.2. 为现有 NIM 部署启用 NVIDIA NIM 指标 复制链接链接已复制到粘贴板!
如果您之前在 OpenShift AI 中部署了 NIM 模型,然后升级到最新版本,则必须通过添加注解启用指标集合和图形生成来手动为现有部署启用 NIM 指标。
最新版本的 OpenShift AI 中的新部署会自动启用 NIM 指标和图形。
3.2.1. 为现有 NIM 部署启用图形生成 复制链接链接已复制到粘贴板!
以下流程描述了如何为现有 NIM 部署启用图形生成。
先决条件
- 具有集群管理员特权。
- 您已下载并安装 OpenShift 命令行界面 (CLI)。如需更多信息,请参阅安装 OpenShift CLI (Red Hat OpenShift Dedicated)或 安装 OpenShift CLI (Red Hat OpenShift Service on AWS)。
- 在 OpenShift AI 中已有 NIM 部署。
流程
- 在一个终端窗口中,如果您还没有以集群管理员身份登录到 OpenShift 集群,请登录 OpenShift CLI。
确认与 NIM 部署关联的
ServingRuntime的名称:oc get servingruntime -n <namespace>
oc get servingruntime -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<namespace> 替换为部署 NIM 模型的项目的命名空间。检查
ServingRuntime配置中现有的metadata.annotations部分:oc get servingruntime -n <namespace> <servingruntime-name> -o json | jq '.metadata.annotations'
oc get servingruntime -n <namespace> <servingruntime-name> -o json | jq '.metadata.annotations'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 <servingruntime-name> 替换为上一步中的
ServingRuntime的名称。执行以下操作之一:
如果配置中没有
metadata.annotations部分,请使用所需注解添加部分:oc patch servingruntime -n <namespace> <servingruntime-name> --type json --patch \ '[{"op": "add", "path": "/metadata/annotations", "value": {"runtimes.opendatahub.io/nvidia-nim": "true"}}]'oc patch servingruntime -n <namespace> <servingruntime-name> --type json --patch \ '[{"op": "add", "path": "/metadata/annotations", "value": {"runtimes.opendatahub.io/nvidia-nim": "true"}}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您会看到类似如下的输出:
servingruntime.serving.kserve.io/nim-serving-runtime patched
servingruntime.serving.kserve.io/nim-serving-runtime patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果已存在
metadata.annotations部分,请将所需的注解添加到部分中:oc patch servingruntime -n <project-namespace> <runtime-name> --type json --patch \ '[{"op": "add", "path": "/metadata/annotations/runtimes.opendatahub.io~1nvidia-nim", "value": "true"}]'oc patch servingruntime -n <project-namespace> <runtime-name> --type json --patch \ '[{"op": "add", "path": "/metadata/annotations/runtimes.opendatahub.io~1nvidia-nim", "value": "true"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您会看到类似如下的输出:
servingruntime.serving.kserve.io/nim-serving-runtime patched
servingruntime.serving.kserve.io/nim-serving-runtime patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
确认注解已添加到现有 NIM 部署的
ServingRuntime中。oc get servingruntime -n <namespace> <servingruntime-name> -o json | jq '.metadata.annotations'
oc get servingruntime -n <namespace> <servingruntime-name> -o json | jq '.metadata.annotations'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您添加的注解会显示在输出中:
... "runtimes.opendatahub.io/nvidia-nim": "true"
... "runtimes.opendatahub.io/nvidia-nim": "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意要使指标可用于图形生成,还必须为您的部署启用指标集合。请参阅 为现有 NIM 部署启用指标集合。
3.2.2. 为现有 NIM 部署启用指标集合 复制链接链接已复制到粘贴板!
要为现有 NIM 部署启用指标集合,您必须手动将 Prometheus 端点和端口注解添加到部署的 InferenceService 中。
以下流程描述了如何将所需的 Prometheus 注解添加到 NIM 部署的 InferenceService 中。
先决条件
- 具有集群管理员特权。
- 您已下载并安装 OpenShift 命令行界面 (CLI)。如需更多信息,请参阅安装 OpenShift CLI (Red Hat OpenShift Dedicated)或 安装 OpenShift CLI (Red Hat OpenShift Service on AWS)。
- 在 OpenShift AI 中已有 NIM 部署。
流程
- 在一个终端窗口中,如果您还没有以集群管理员身份登录到 OpenShift 集群,请登录 OpenShift CLI。
确认与 NIM 部署关联的
InferenceService的名称:oc get inferenceservice -n <namespace>
oc get inferenceservice -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<namespace> 替换为部署 NIM 模型的项目的命名空间。检查
InferenceService配置中是否存在现有的spec.predictor.annotations部分:oc get inferenceservice -n <namespace> <inferenceservice-name> -o json | jq '.spec.predictor.annotations'
oc get inferenceservice -n <namespace> <inferenceservice-name> -o json | jq '.spec.predictor.annotations'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 <inferenceservice-name> 替换为上一步中的
InferenceService的名称。执行以下操作之一:
如果配置中不存在
spec.predictor.annotations部分,请添加这个部分和所需的注解:oc patch inferenceservice -n <namespace> <inference-name> --type json --patch \ '[{"op": "add", "path": "/spec/predictor/annotations", "value": {"prometheus.io/path": "/metrics", "prometheus.io/port": "8000"}}]'oc patch inferenceservice -n <namespace> <inference-name> --type json --patch \ '[{"op": "add", "path": "/spec/predictor/annotations", "value": {"prometheus.io/path": "/metrics", "prometheus.io/port": "8000"}}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您添加的注解会显示在输出中:
inferenceservice.serving.kserve.io/nim-serving-runtime patched
inferenceservice.serving.kserve.io/nim-serving-runtime patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果已存在
spec.predictor.annotations部分,请将 Prometheus 注解添加到部分中:oc patch inferenceservice -n <namespace> <inference-service-name> --type json --patch \ '[{"op": "add", "path": "/spec/predictor/annotations/prometheus.io~1path", "value": "/metrics"}, {"op": "add", "path": "/spec/predictor/annotations/prometheus.io~1port", "value": "8000"}]'oc patch inferenceservice -n <namespace> <inference-service-name> --type json --patch \ '[{"op": "add", "path": "/spec/predictor/annotations/prometheus.io~1path", "value": "/metrics"}, {"op": "add", "path": "/spec/predictor/annotations/prometheus.io~1port", "value": "8000"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您添加的注解会显示在输出中:
inferenceservice.serving.kserve.io/nim-serving-runtime patched
inferenceservice.serving.kserve.io/nim-serving-runtime patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
确认注解已添加到
InferenceService中。oc get inferenceservice -n <namespace> <inferenceservice-name> -o json | jq '.spec.predictor.annotations'
oc get inferenceservice -n <namespace> <inferenceservice-name> -o json | jq '.spec.predictor.annotations'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您会看到您在输出中添加的注解:
{ "prometheus.io/path": "/metrics", "prometheus.io/port": "8000" }{ "prometheus.io/path": "/metrics", "prometheus.io/port": "8000" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow