如何监控vLLM等大模型推理性能？ - 53AI-AI生产力的卓越领导者（大模型知识库|大模型训练|智能体开发）

本文将深入探讨 AI 推理应用的可观测方案，并基于 Prometheus 规范提供一套完整的指标观测方案，帮助开发者构建稳定、高效的推理应用。

近两年来，随着大语言模型（LLM）的快速普及，AI 推理应用的需求呈指数级增长。以 DeepSeek 为代表的开源大模型凭借其卓越的推理性能和准确性，在开发者社区中迅速走红。无论是企业级应用还是个人项目，DeepSeek 都成为了构建智能对话系统、内容生成工具以及复杂决策支持的核心引擎。然而，随着模型规模的扩大和推理请求量的激增，无论是 DeepSeek 官方服务还是各云厂商推出的推理应用，都逐渐暴露出一系列性能瓶颈问题。

一、AI 推理应用的可观测需求与痛点

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

性能指标监控

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

资源使用监控

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

模型加载与卸载的开销

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

模型行为监控

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

分布式架构监控

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

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

二、基于 Prometheus 的完整解决方案

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

Prometheus 的优势包括：

多维数据模型
Prometheus 支持通过标签（Labels）对指标进行分类和过滤，可以轻松地对不同维度数据进行聚合和分析。例如按 GPU ID、模型名称或请求类型对性能指标进行分组。
高效的拉取机制
Prometheus 采用主动拉取（Pull）的方式收集指标数据，避免了传统推送模式可能导致的数据丢失或重复问题。
丰富的生态系统
Prometheus 提供了广泛的 Exporter 和客户端库，能够与各种框架和工具无缝集成。例如 Ray Serve 和 vLLM 等推理框架都可以通过 Exporter 暴露指标。
强大的告警功能
Prometheus 内置的 Alertmanager 支持基于规则的告警配置，能够及时发现并通知潜在问题。
可视化支持
Prometheus 可以与 Grafana 等可视化工具结合，构建直观的观测大盘，帮助团队快速掌握服务状态。

阿里云 AI Stack 可观测解决方案

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

IaaS 层智算物理设备，覆盖 GPI/PPU 设备，RDMA 网络，CPFS 存储，CPU和内存等关键性和利用率监控；
针对 Kubernetes 编排层的全套指标监控支持，完善的生态能力全量复用；
智能 PaaS 平台 PAI 和百炼的上下层结合的指标监控体系；
社区常见的训练/推理框架全部支持 Prometheus 指标规范，实现默认指标埋点。

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

三、推理应用全链路观测实践

（一）推理框架 Ray Serve

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_serve_deployment_request_counter_total [**]	deployment, replica, route, application	此副本已处理的查询数量。
ray_serve_deployment_error_counter_total [**]	deployment, replica, route, application	部署中发生的异常数量。
ray_serve_deployment_replica_starts_total [**]	deployment, replica, application	由于故障此副本被重启的次数。

更多 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

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

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

vLLM 内置指标说明

1. 系统状态相关指标

指标名称	默认标签	指标说明
vllm:num_requests_running	labelnames	当前在 GPU 上运行的请求数量。
vllm:num_requests_waiting	labelnames	等待处理的请求数量。
vllm:lora_requests_info	[labelname_running_lora_adapters, labelname_max_lora, labelname_waiting_lora_adapters]	LoRA 请求的相关统计信息，包括正在运行的 LoRA 适配器数量、最大 LoRA 数量和等待中的 LoRA 适配器数量。
vllm:num_requests_swapped	labelnames	被交换到 CPU 的请求数量。
vllm:gpu_cache_usage_perc	labelnames	GPU KV 缓存的使用率（1 表示 100% 使用）。
vllm:cpu_cache_usage_perc	labelnames	CPU KV 缓存的使用率（1 表示 100% 使用）。
vllm:cpu_prefix_cache_hit_rate	labelnames	CPU 前缀缓存的命中率。
vllm:gpu_prefix_cache_hit_rate	labelnames	GPU 前缀缓存的命中率。

2. 迭代统计相关指标

指标名称	默认标签	指标说明
vllm:num_preemptions_total	labelnames	引擎中累计的抢占次数。
vllm:prompt_tokens_total	labelnames	预填充阶段处理的 token 总数。
vllm:generation_tokens_total	labelnames	生成阶段处理的 token 总数。
vllm:tokens_total	labelnames	预填充阶段与生成阶段处理的 token 总数之和。
vllm:iteration_tokens_total	labelnames	每次引擎步长中处理的 token 数量分布直方图。
vllm:time_to_first_token_seconds	labelnames	生成第一个 token 所需时间的分布直方图（单位：秒）。
vllm:time_per_output_token_seconds	labelnames	每个输出 token 的生成时间分布直方图（单位：秒）。

3. 请求统计相关指标

(1) 延迟相关

指标名称	默认标签	指标说明
vllm:e2e_request_latency_seconds	labelnames	请求端到端延迟的分布直方图（单位：秒）。
vllm:request_queue_time_seconds	labelnames	请求在等待队列中的时间分布直方图（单位：秒）。
vllm:request_inference_time_seconds	labelnames	请求在推理阶段的时间分布直方图（单位：秒）。
vllm:request_prefill_time_seconds	labelnames	请求在预填充阶段的时间分布直方图（单位：秒）。
vllm:request_decode_time_seconds	labelnames	请求在解码阶段的时间分布直方图（单位：秒）。
vllm:time_in_queue_requests	labelnames	请求在队列中花费的时间分布直方图（单位：秒）。

(2) 模型执行时间

指标名称	默认标签	指标说明
vllm:model_forward_time_milliseconds	labelnames	模型前向传播的时间分布直方图（单位：毫秒）。
vllm:model_execute_time_milliseconds	labelnames	模型执行函数的时间分布直方图（单位：毫秒）。

(3) Token 处理

指标名称	默认标签	指标说明
vllm:request_prompt_tokens	labelnames	请求中预填充阶段处理的 token 数量分布直方图。
vllm:request_generation_tokens	labelnames	请求中生成阶段处理的 token 数量分布直方图。
vllm:request_max_num_generation_tokens	labelnames	请求中最大生成 token 数量分布直方图。

(4) 请求参数

指标名称	默认标签	指标说明
vllm:request_params_n	labelnames	请求参数 n 的分布直方图。
vllm:request_params_max_tokens	labelnames	请求参数 max_tokens 的分布直方图。

(5) 请求成功率

指标名称	默认标签	指标说明
vllm:request_success_total	labelnames + [Metrics.labelname_finish_reason]	成功处理的请求数量计数器，按完成原因分类。

4. 推测解码（Speculative Decoding）相关指标

指标名称	默认标签	指标说明
vllm:spec_decode_draft_acceptance_rate	labelnames	推测解码中草稿 token 的接受率（Gauge 类型）。
vllm:spec_decode_efficiency	labelnames	推测解码系统的效率（Gauge 类型）。
vllm:spec_decode_num_accepted_tokens_total	labelnames	被接受的推测 token 总数计数器。
vllm:spec_decode_num_draft_tokens_total	labelnames	生成的草稿 token 总数计数器。
vllm:spec_decode_num_emitted_tokens_total	labelnames	发出的推测 token 总数计数器。

5. 默认标签说明

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...

如果 vLLM 服务部署到 Kubernetes 中，同样可以通过 PodMonitor 配置来采集它们，下面给出一个简单配置用例。要求 vLLM 的 Deployment 中需要给 Pod 配置标签app: vllm-server。

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

自定义指标的实现

自定义指标有两种方案：

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

from ray.util import metrics as ray_metrics

直接使用 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

（三）IaaS 计算层监控

GPU 设备监控

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

GPU设备部分监控指标

计算节点监控

监控重点：高性能网络，基础网络，CPU 使用率、内存使用率、磁盘 I/O。这些指标反映计算节点整体性能。
难题：计算节点数量众多，且可能存在异构环境，监控数据量大且复杂。
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 监控方案天然集成，重点监控以下几个维度：

集群管控服务能力，包括 API Server，Scheduler，Controller 等组件的性能和容量。从 Node 和 Pod 维度监控弹性响应能力。
从节点 Node 和 Container 维度监控服务 Pod 级别的算力、流量带宽消耗、磁盘 I/O。当然包括上文提到的 GPU 算力，精确到 Pod 级别。
基于 eBPF 技术分析 Pod 之间或节点之间的网络通信，是否存在网络 I/O 瓶颈，异常网络通信等。通常推理服务加载模型有两种模式，直接容器镜像加载或通过 NAS/OSS 加载，加载速度跟网络 I/O 强相关。

（五）PaaS 平台层

阿里云 AI 网关监控

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

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

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

阿里云 PAI EAS 监控

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

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

PAI EAS 部分指标监控

四、总结与畅想

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

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