如何監控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-monitornamespace: 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-monitornamespace: 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 metricsimport timeimport requests@serve.deploymentclassMyDeployment: 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 += 1if 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-monitornamespace: 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-definitionsclassMetrics:""" 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 推理服務的規模化部署提供更強有力的支援。

AI編碼，十倍提速，通義靈碼引領研發新正規化

本方案提出以通義靈碼為核心的智慧開發流程。通義靈碼在程式碼生成、註釋新增及單元測試方面實現快速生成，雲效則作為程式碼管理和持續整合平臺，最終將應用程式部署到函式計算 FC 平臺。

點選閱讀原文檢視詳情。