如何监控vLLM等大模型推理性能？_阿里开发者的专栏文章_微信文章

阿里妹导读

本文将深入探讨 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	labelname s	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	labelnam es	每次引擎步长中处理的 token 数量分布直方图。
vllm:time_to_first_token_seconds	labelnames	生成第一个 token 所需时间的分布直方图（单位：秒）。
vllm:time_per_output_token_seconds	labelnames	每个输出 token 的生成时间分布直方图（单位：秒）。

3. 请求统计相关指标

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

正文

Ray Serve 内置完善的指标集

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

vLLM 内置指标说明

请到「今天看啥」查看全文