前言

GPT-4、PHI2、BERT和T5等大語言模型（LLM）的出現(xiàn)已徹底改變了自然語言處理，這些模型支持高端應用程序，包括聊天機器人、推薦系統(tǒng)和分析。然而，LLM中工作負載的規(guī)模和復雜性使得保證性能和可靠性成了一大挑戰(zhàn)。在這種情況下，在使用Ray等框架部署工作負載的同時進行監(jiān)控和觀測顯得非常必要。

Ray是一種分布式計算框架，提供了一個強大的平臺，可以跨集群有效地擴展LLM工作負載。因此，它成了托管、管理和觀測LLM的一種出色選擇。利用Ray的內置特性，并結合Prometheus和Grafana觀測關鍵度量指標，將幫助用戶有效地監(jiān)控、優(yōu)化資源的使用，并快速診斷生產(chǎn)環(huán)境中的問題。

本文探討了Ray托管的LLM工作負載中可觀測性的重要性、需要監(jiān)控的關鍵度量指標以及使用Prometheus和Grafana搭建可觀測性機制的詳細指南。

為什么使用Ray處理LLM工作負載？

Ray為分布式、可擴展的應用程序設計，因而成為了托管和管理LLM工作負載的理想選擇。讓Ray成為出色選擇的主要特性包括如下：

• 動態(tài)任務調度：Ray的細粒度任務調度確保了資源的有效利用，特別是在處理LLM推理任務時，這類任務的大小和復雜性可能大有不同。
• 易于集成：Ray與Hugging Face Transformers等框架無縫集成，可以輕松部署預訓練的LLM。
• 自動擴展：Ray的集群自動擴展器可以根據(jù)工作負載的需求動態(tài)調整資源，確保成本效益和可擴展性。
• 可觀測性支持：Ray提供了與Prometheus兼容的度量指標端點，簡化了分布式系統(tǒng)的監(jiān)控設置。

這些特性使Ray不僅是一種計算框架，還是用于在實際應用程序中運行、監(jiān)控和擴展LLM的基礎工具。

觀測Ray托管的LLM工作負載的關鍵指標

為了確保Ray托管的LLM工作負載的順利運行，跟蹤一系列性能、資源利用和操作度量指標就至關重要。以下是主要類別：

性能指標

• 任務延遲：測量單個Ray任務完成所需的時間，這對于識別推理管道中的瓶頸至關重要。
• 吞吐量：跟蹤每秒完成的任務數(shù)量，反映了系統(tǒng)處理高請求量的能力。
• 詞元處理速率：測量每秒處理的詞元數(shù)量，特別是與GPT-4等基于Transformer的模型相關。

資源利用指標

• CPU和GPU利用率：監(jiān)控整個集群的資源使用情況，確保工作負載的高效分配。
• 內存使用：跟蹤內存消耗以防止內存不足錯誤，這對于托管大型模型尤其重要。
• 對象存儲利用率：觀測Ray的內存中對象存儲的使用情況，以便跨任務有效地共享數(shù)據(jù)。

操作指標

錯誤率：監(jiān)控任務失敗率，以快速檢測和解決問題。

節(jié)點可用性：跟蹤Ray集群中節(jié)點的運行狀況，確保可靠性。

隊列長度：衡量掛起任務的數(shù)量，表明處理過程中的潛在瓶頸。

為Ray托管的工作負載設置可觀測性機制

Ray中的可觀測性需要使用度量指標來了解系統(tǒng)性能和診斷問題。通過將Ray與Prometheus和Grafana相集成，你就可以深入了解工作負載的行為。

第1步：設置Prometheus監(jiān)控

Prometheus是一個開源監(jiān)控系統(tǒng)，可以從Ray的端點收集度量指標。按照下面的指南在Kubernetes上搭建Prometheus和Ray。

使用KubeRay安裝Prometheus：

# Path: kuberay/
./install/prometheus/install.sh

# Check the installation
kubectl get all -n prometheus-system

配置Pod和服務監(jiān)控器

設置PodMonitor和ServiceMonitor資源，從Ray head節(jié)點和worker節(jié)點中抓取度量指標：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: ray-workers-monitor
  namespace: prometheus-system
  labels:
    release: prometheus
    ray.io/cluster: rayservice-sample-raycluster-bpkgv
spec:
  jobLabel: ray-workers
  namespaceSelector:
    matchNames:
      - raysvc
  selector:
    matchLabels:
      ray.io/node-type: worker
  podMetricsEndpoints:
    - port: metrics
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: resume-analyzer-monitor
  namespace: prometheus-system
  labels:
    release: prometheus
spec:
  jobLabel: resume-analyzer
  namespaceSelector:
    matchNames:
      - raysvc
  selector:
    matchLabels:
      ray.io/node-type: head
    endpoints:
      - port: metrics
    targetLabels:
      - ray.io/cluster

第2步：配置錄制規(guī)則

錄制規(guī)則允許你預先計算PromQL表達式，以加快查詢。比如說，計算Ray全局控制存儲（GCS）的可用性：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ray-cluster-gcs-rules
  namespace: prometheus-system
  labels:
    release: prometheus
spec:
  groups:
  - name: ray-cluster-main-staging-gcs.rules
    interval: 30s
    rules:
    - record: ray_gcs_availability_30d
      expr: |
        (
          100 * (
            sum(rate(ray_gcs_update_resource_usage_time_bucket{container="ray-head", le="20.0"}[30d]))
            /
            sum(rate(ray_gcs_update_resource_usage_time_count{container="ray-head"}[30d]))
          )
        )

表達方式解釋：

• ray_gcs_update_resource_usage_time_bucket：跟蹤資源使用更新的延遲時間。
• ray_gcs_update_resource_usage_time_count：統(tǒng)計更新總次數(shù)。
• 該表達式計算過去30天內在特定延遲閾值內完成的更新的百分比。

第3步：設置警報規(guī)則

警報規(guī)則有助于主動識別問題。比如說，檢測缺失的GCS度量指標：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ray-cluster-gcs-rules
  namespace: prometheus-system
  labels:
    release: prometheus
spec:
  groups:
  - name: ray-cluster-main-staging-gcs.rules
    interval: 30s
    rules:
    - alert: MissingMetricRayGlobalControlStore
      expr: |
        absent(ray_gcs_update_resource_usage_time_count)
      for: 1m
      labels:
        severity: warning
      annotations:
        summary: "Missing Ray GCS metrics"

設置Grafana儀表板

Grafana為度量指標提供了豐富的可視化。下面介紹了如何為Ray設置儀表板：

第1步：捕獲默認儀表板

從Ray head pod中復制默認儀表板：

kubectl cp <head-pod>:/tmp/ray/session_latest/metrics/grafana/dashboards/ ./dashboards

第2步：訪問Grafana儀表板

kubectl port-forward deployment/prometheus-grafana -n prometheus-system 3000:3000

默認登錄憑據(jù)：

• 用戶名：admin
• 密碼：prom-operator

啟用Ray Serve Pods中的分析

分析推理工作負載依賴用于監(jiān)控、調試和優(yōu)化性能的復雜技術。本節(jié)將深入介紹特定的工具、配置和場景，以增強你的分析能力。

?內存分析

內存分析對于內存泄漏檢測和使用優(yōu)化至關重要。比如說，借助Memray，可以跟蹤內存分配，并了解推理任務的行為。若要啟用Ray Serve Pod中的內存分析，更新容器的安全上下文以允許跟蹤：

securityContext:
  capabilities:
    add:
    - SYS_PTRACE

一旦配置完成，Memray就可以用來生成內存使用報告，這有助于識別系統(tǒng)中內存消耗高的任務或瓶頸。

示例用例：

在批處理推理任務期間分析大型Transformer模型的內存使用情況，以優(yōu)化批處理大小，并減少內存開銷。

?CPU分析

針對CPU分析，可以在worker pod中安裝gdb、lldb或py-spy等工具，以收集詳細的CPU使用數(shù)據(jù)。這些工具允許你監(jiān)控哪些函數(shù)消耗最多的CPU時間，從而實現(xiàn)有針對性的優(yōu)化。

設置CPU分析機制：

• 在ray worker pod中安裝gdb或lldb。
• 使用分析腳本或工具在推理任務期間捕獲CPU使用快照。

示例用例：

• 在預處理管道中識別需要CPU資源的操作，將其卸載到GPU或優(yōu)化其實現(xiàn)。

端到端分析示例

當你集成內存分析和CPU分析時，這將為你提供系統(tǒng)性能的總體概況。為了更好地說明這一點，考慮一個有延遲峰值的LLM推理任務。如果你把內存分析和CPU分析關聯(lián)起來，就會發(fā)現(xiàn)：

• 內存使用背后的罪魁禍首是大批的輸入數(shù)據(jù)。
• CPU瓶頸是由于分詞功能效率低下造成的。

如果你優(yōu)化批處理大小并重構瓶頸函數(shù)，性能可能會得到很大程度的提高。

結論

使用Ray的分布式LLM工作負載以及可靠工具的可觀測性將確保團隊從這些系統(tǒng)中獲得性能、可靠性和可擴展性。這篇指南介紹了在Ray上設置和監(jiān)控LLM工作負載，很實用。適當?shù)目捎^測性將幫助開發(fā)人員和操作人員盡早發(fā)現(xiàn)問題，優(yōu)化資源使用，并進一步改善用戶在使用NLP應用程序時獲得的體驗。

原文標題：??Observing and monitoring Large Language Model workloads with Ray??，作者：Swastik Gour