如何监控vLLM等大模型推理性能？

以自建 DeepSeek 应用为例，可观测需求主要集中在以下几个方面：

1. 性能指标监控

性能是推理应用的核心关注点，包括请求延迟、吞吐量和并发能力等关键指标。例如，用户期望推理应用能够在毫秒级别返回结果，但请求量突然增加时，服务可能会因资源争抢而导致延迟飙升。这种情况下，缺乏细粒度性能监控会导致问题难以定位。

1. 资源使用监控

AI 推理应用通常依赖于 GPU 、 TPU 或 PPU 等高性能计算设备。这些设备的资源利用率监控不仅限于硬件层面，还需要结合模型推理的具体行为进行分析。例如，某些模型可能因为内存分配不合理而导致频繁的显存交换，进而影响整体性能。

1. 模型加载与卸载的开销

DeepSeek 模型和推理运行基础环境镜像都体积庞大，加载和卸载过程耗时较长。如果未对这一过程进行可观测，可能导致服务启动时间过长或资源竞争。

1. 模型行为监控

模型推理过程中可能出现异常输出或错误预测，这些问题往往与输入数据的质量或模型本身的稳定性有关。如果没有对模型行为进行有效观测，可能导致业务风险。

1. 分布式架构监控

在大规模推理场景下，分布式架构成为必然选择。然而，分布式系统中的节点通信 延迟、负载均衡和服务发现等问题都会对推理应用的稳定性产生影响。

面对这些挑战，传统的监控手段显得力不从心。比如仅依赖日志分析无法实时捕捉性能瓶颈，而简单的 CPU/GPU 使用率监控也无法全面反映推理应用的健康状态。AI 推理应用的可观测需求不仅涉及硬件资源和性能指标，还包括模型行为和分布式架构的复杂性。因此，如何通过高效的可观测手段实现对 AI 推理应用的全链路可观测性，已成为当前技术团队亟需解决的问题。本文将深入探讨 AI 推理应用的可观测方案，并基于 Prometheus 规范提供一套完整的指标观测方案，帮助开发者构建稳定、高效的推理应用。

Prometheus 是一个开源的系统监控和报警工具，以其强大的多维数据模型和灵活的查询语言（PromQL）著称。它特别适合用于动态云环境和容器化部署，能够轻松集成到 AI 推理服务的可观测体系中。

Prometheus 的优势包括：

1. 多维数据模型
   Prometheus 支持通过标签（Labels）对指标进行分类和过滤，可以轻松地对不同维度数据进行聚合和分析。例如按 GPU ID、模型名称或请求类型对性能指标进行分组。

2. 高效的拉取机制
   Prometheus 采用主动拉取（Pull）的方式收集指标数据，避免了传统推送模式可能导致的数据丢失或重复问题。

3. 丰富的生态系统
   Prometheus 提供了广泛的 Exporter 和客户端库，能够与各种框架和工具无缝集成。例如 Ray Serve 和 vLLM 等推理框架都可以通过 Exporter 暴露指标。

4. 强大的告警功能
   Prometheus 内置的 Alertmanager 支持基于规则的告警配置，能够及时发现并通知潜在问题。

5. 可视化支持
   Prometheus 可以与 Grafana 等可视化工具结合，构建直观的观测大盘，帮助团队快速掌握服务状态。

最为关键的是，以阿里云 Prometheus 服务为例，通过社区+厂商共同的生态建设，目前已经建设起完善的指标生态：

• IaaS 层智算物理设备，覆盖 GPI/PPU 设备，RDMA 网络，CPFS 存储，CPU和内存等关键性和利用率监控；

• 针对 Kubernetes 编排层的全套指标监控支持，完善的生态能力全量复用；

• 智能 PaaS 平台 PAI 和百炼的上下层结合的指标监控体系；

• 社区常见的训练/推理框架全部支持 Prometheus 指标规范，实现默认指标埋点。

这些使得我们针对 AI 推理的指标观测方案的建设站在了高起点。

Ray Serve 的设计目标是解决传统推理框架在灵活性、性能和可扩展性方面的不足，其具备以下特点：

• 动态伸缩能力

Ray Serve 支持根据实时流量动态调整模型副本数量，从而实现资源的高效利用。这种弹性伸缩机制特别适合处理流量波动较大的在线推理场景。

• 多模型支持

Ray Serve 可以同时部署多个模型，并通过路由规则将请求分发到不同的模型实例。例如，可以将自然语言处理（NLP）模型和图像分类模型部署在同一服务中，并根据请求路径或内容进行区分。

• 批处理优化

对于高吞吐量的推理任务，Ray Serve 提供了内置的批处理机制，能够将多个请求合并为一个批次进行处理，从而显著提升 GPU 利用率。

• 灵活的服务编排，编辑部署

Ray Serve 支持将模型推理与其他业务逻辑（如数据预处理、后处理等）无缝集成，形成端到端的服务流水线。Ray Serve 可以在单机或多节点环境中快速部署。也可以与 Kubernetes 无缝集成，实现集群化部署。

正因为 Ray Serve 的完善能力，目前其是开源 AI 推理工具集中的明星。推理性能最直接的体现来源于推理框架。Ray Serve 需要从模型加载、推理副本调度、流量路由、推理请求处理性能、Token 输入输出等多个方面建立起完善的观测指标。当然，只需要在 Ray Serve 内置指标集基础之上，根据推理服务的特点选择性自定义性能指标。

Ray Serve 内置完善的指标集

在性能观测方面，Ray Serve 通过 Ray 的监控基础设施暴露的重要系统指标，还可以利用内置的 Ray Serve 指标来更深入地了解应用服务的性能，例如成功和失败请求的数量。默认情况下，这些指标以 Prometheus 格式在每个节点上暴露。

以下是 Ray Serve 暴露的内置指标列表：

更多 Ray System 指标，参考：官方文档https://docs.ray.io/en/latest/ray-observability/reference/system-metrics.html

要查看这些指标的实际效果，首先运行以下命令启动 Ray 并设置指标导出端口：

ray start --head --metrics-export-port=8080采集 RayServe 内置指标

假设我们在 Kubernetes 中通过 KubeRay 部署 RayServe，可以通过配置 PodMonitor 来采集 Head 和 Worker 节点暴露的指标。

apiVersion: monitoring.coreos.com/v1kind: PodMonitormetadata:  name: ray-workers-monitor  namespace: prometheus-system  labels:    # `release: $HELM_RELEASE`: Prometheus can only detect PodMonitor with this label.    release: prometheusspec:  jobLabel: ray-workers  # Only select Kubernetes Pods in the "default" namespace.  namespaceSelector:    matchNames:      - default  # Only select Kubernetes Pods with "matchLabels".  selector:    matchLabels:      ray.io/node-type: worker  # A list of endpoints allowed as part of this PodMonitor.  podMetricsEndpoints:    - port: metrics      relabelings:        - sourceLabels: [__meta_kubernetes_pod_label_ray_io_cluster]          targetLabel: ray_io_cluster---apiVersion: monitoring.coreos.com/v1kind: PodMonitormetadata:  labels:    # `release: $HELM_RELEASE`: Prometheus can only detect PodMonitor with this label.    release: prometheus  name: ray-head-monitor  namespace: prometheus-systemspec:  jobLabel: ray-head  # Only select Kubernetes Pods in the "default" namespace.  namespaceSelector:    matchNames:      - default  # Only select Kubernetes Pods with "matchLabels".  selector:    matchLabels:      ray.io/node-type: head  # A list of endpoints allowed as part of this PodMonitor.  podMetricsEndpoints:    - port: metrics      relabelings:        - action: replace          sourceLabels:            - __meta_kubernetes_pod_label_ray_io_cluster          targetLabel: ray_io_cluster    - port: as-metrics # autoscaler metrics      relabelings:        - action: replace          sourceLabels:            - __meta_kubernetes_pod_label_ray_io_cluster          targetLabel: ray_io_cluster    - port: dash-metrics # dashboard metrics      relabelings:        - action: replace          sourceLabels:            - __meta_kubernetes_pod_label_ray_io_cluster          targetLabel: ray_io_cluster

对于 PodMonitor 配置，在阿里云容器服务 ACK 集群中会自动被阿里云 Prometheus 服务采集。同样地，如果安装了开源 Prometheus Opeartor 组件，配置也将自动生效。

在 RayServe 代码中自定义监控指标

框架内置的指标解决了基础的监控问题，但如果希望根据用户类型、请求内容或优先级来统计请求，按模型版本或输入 Token 数据来统计响应性能，模型全方位评估，模型推理结果准确度，输入数据质量监控等等。需要通过自定义指标埋点来解决。到这里，需要具备 Python 开发能力和掌握 Prometheus 指标模型。这有利于建立最贴近业务的直接监控指标。

下面是一个借助 ray.serve.metrics类库来实现自定义指标埋点的用例。

from ray import servefrom ray.serve import metrics
import timeimport requests

@serve.deploymentclass MyDeployment:    def __init__(self):        self.num_requests = 0        self.my_counter = metrics.Counter(            "my_counter",            description=("The number of odd-numbered requests to this deployment."),            tag_keys=("model",),        )        self.my_counter.set_default_tags({"model": "123"})
    def __call__(self):        self.num_requests += 1        if self.num_requests % 2 == 1:            self.my_counter.inc()

my_deployment = MyDeployment.bind()serve.run(my_deployment)
while True:    requests.get("http://localhost:8000/")    time.sleep(1)

KubeRay 基础监控

RayCluster 基础监控

vLLM 作为专注于大规模语言模型（LLM）推理的高性能框架，旨在解决大模型在推理过程中面临的性能瓶颈问题，提供高效的批处理机制、显存优化和分布式推理支持，适合处理高并发和长序列输入场景。生产部署基于 DeepSeek 推理应用，多半会在选 Ray 的同时，选择 vLLM 框架。

vLLM 更贴近模型推理过程，通常基于 vLLM 来将大模型切分为多个 Block 分布式允许。因此 vLLM 也可以为我们提供更细分的推理性能监控指标。

vLLM 内置指标说明

1. 系统状态相关指标

(1) 延迟相关

• labelnames: 动态字段，表示指标的标签维度，例如模型名称、请求路径等。

• Metrics.labelname_finish_reason: 表示请求完成的原因（如成功、失败等）。

• Metrics.labelname_waiting_lora_adapters: 表示等待中的 LoRA 适配器数量。

• Metrics.labelname_running_lora_adapters: 表示正在运行的 LoRA 适配器数量。

• Metrics.labelname_max_lora: 表示最大 LoRA 数量。

采集 vLLM 服务指标

vLLM 通过 OpenAI 兼容 API 服务上的  /metrics 指标端点公开指标，下面是一个用例：

$ curl http://0.0.0.0:8000/metrics
# HELP vllm:iteration_tokens_total Histogram of number of tokens per engine_step.# TYPE vllm:iteration_tokens_total histogramvllm:iteration_tokens_total_sum{model_name="unsloth/Llama-3.2-1B-Instruct"} 0.0vllm:iteration_tokens_total_bucket{le="1.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0vllm:iteration_tokens_total_bucket{le="8.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0vllm:iteration_tokens_total_bucket{le="16.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0vllm:iteration_tokens_total_bucket{le="32.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0vllm:iteration_tokens_total_bucket{le="64.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0vllm:iteration_tokens_total_bucket{le="128.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0vllm:iteration_tokens_total_bucket{le="256.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0vllm:iteration_tokens_total_bucket{le="512.0",model_name="unsloth/Llama-3.2-1B-Instruct"} 3.0...

apiVersion: monitoring.coreos.com/v1kind: PodMonitormetadata:  name: vllm-monitor  namespace: vllm-demo  labels:    release: prometheusspec:  jobLabel: vllm-monitor  # Only select Kubernetes Pods in the "default" namespace.  namespaceSelector:    matchNames:      - default  # Only select Kubernetes Pods with "matchLabels".  selector:    matchLabels:      app: vllm-server

自定义指标的实现

自定义指标有两种方案：

1. 如果将 vLLM 结合 Ray 使用，那么可以直接使用 Ray 的相关工具类。例如：

from ray.util import metrics as ray_metrics

1. 直接使用 Prometheus Python SDK。

# begin-metrics-definitionsclass Metrics:    """    vLLM uses a multiprocessing-based frontend for the OpenAI server.    This means that we need to run prometheus_client in multiprocessing mode    See https://prometheus.github.io/client_python/multiprocess/ for more    details on limitations.    """

直接参考 vLLM 内置指标的实现代码：

https://github.com/vllm-project/vllm/blob/main/vllm/engine/metrics.py

GPU 设备监控

监控重点：GPU 利用率、显存使用情况、GPU 温度。GPU 利用率直接影响推理性能，显存不足会导致推理失败，而过高的温度可能损坏硬件。以阿里云为例，提供 GPU 算力的服务包括灵骏计算、ECS GPU 主机、PAI 等，取决于推理服务部署方式的不同，需要统一将 GPU 设备的监控指标进行统一的采集。

GPU设备部分监控指标

计算节点监控

1. 监控重点：高性能网络，基础网络，CPU 使用率、内存使用率、磁盘 I/O。这些指标反映计算节点整体性能。

2. 难题：计算节点数量众多，且可能存在异构环境，监控数据量大且复杂。

3. Prometheus 解决方案：利用 Prometheus 的节点自动发现机制，动态发现新的计算节点并安装全套的数据采集探针，采集全套的性能指标，通过标签对不同节点进行分类管理。

Kubernetes 容器服务

将 Ray Serve 和 vLLM 结合部署在 Kubernetes（K8s）环境中，可以充分发挥两者的技术优势，同时利用 Kubernetes 的强大编排能力，构建一个高性能、弹性伸缩且易于管理的 AI 推理服务架构。以下是这种组合在 Kubernetes 部署中的主要优势：

(1) Ray Serve 的动态伸缩能力

• 按需扩展副本：Ray Serve 支持根据实时流量动态调整模型副本数量，从而避免资源浪费或性能瓶颈。

• 细粒度资源分配： 在 Kubernetes 中，可以通过 Ray 的资源调度器为每个副本分配特定的 CPU/GPU 资源，确保资源利用率最大化。

(2) vLLM 的高性能推理

• GPU 利用率提升：vLLM 的批处理机制和显存优化技术能够高效利用 GPU 资源，在高并发场景下显著降低延迟并提高吞吐量。

• 分布式推理支持： 对于超大规模模型，vLLM 可以通过分布式推理切分模型并在多个 GPU 上运行，而 Kubernetes 提供了跨节点的 GPU 资源管理能力。

(3) Kubernetes 的 HPA（Horizontal Pod Autoscaler）

• Kubernetes 的 HPA 可以与 Ray Serve 的动态伸缩功能结合使用，根据请求负载自动扩展或缩减推理服务的实例数量，进一步增强弹性。

对于 Kubernetes 集群来说，Prometheus 监控方案天然集成，重点监控以下几个维度：

1. 集群管控服务能力，包括 API Server，Scheduler，Controller 等组件的性能和容量。从 Node 和 Pod 维度监控弹性响应能力。

2. 从节点 Node 和 Container 维度监控服务 Pod 级别的算力、流量带宽消耗、磁盘 I/O。当然包括上文提到的 GPU 算力，精确到 Pod 级别。

3. 基于 eBPF 技术分析 Pod 之间或节点之间的网络通信，是否存在网络 I/O 瓶颈，异常网络通信等。通常推理服务加载模型有两种模式，直接容器镜像加载或通过 NAS/OSS 加载，加载速度跟网络 I/O 强相关。

阿里云 AI 网关监控

监控重点：网关的请求吞吐量、请求延迟、错误率。AI 网关作为推理服务入口，其性能直接影响用户体验。

AI 推理服务目前通常是流式请求，每一个推理请求的响应持续时间长，一旦出现大并发访问，容量压力很大，全访问监控对于服务稳定性至关重要。

阿里云 Prometheus 服务与 阿里云 AI 网关产品深度集成，全方位监控数据无缝集成到 Prometheus 服务。

阿里云 PAI EAS 监控

很多企业会选择直接使用 PAI EAS 来部署推理服务。PAI EAS 是阿里云提供的弹性推理服务，可以直接获取服务实例的运行状态、资源利用率、任务队列长度等一系列监控指标，这些指标反映服务的运行健康状况。

阿里云 Prometheus 服务与 PAI 平台深度集成，全方位监控数据无缝集成到 Prometheus 服务。

PAI EAS 部分指标监控

AI 推理服务的全链路监控需要覆盖从流量入口到算力资源的完整路径，包括防火墙、网关、PaaS 平台、中间件服务以及最终核心— GPU 算力。Prometheus 指标监控方案凭借其灵活的数据采集能力和对多种技术架构的良好适配性，展现出卓越的跨技术栈兼容能力，为全链路监控提供了可靠的基础。基于全套的监控数据，在推理服务允许期间实现有效监控，对比分析，从而保障稳定性的同时优化应用全链路性能。

随着 AI 推理技术的快速演进，监控方案也需要与时俱进。未来，通过引入 AI 技术对监控数据流进行智能分析，可以实现性能瓶颈的自动识别与优化策略的自动执行，从而推动推理服务向自我优化的方向迈进。这不仅能够提升系统的稳定性和效率，还将大幅降低运维复杂度，为 AI 推理服务的规模化部署提供更强有力的支持。