前言

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

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

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

為什么使用Ray處理LLM工作負(fù)載？

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

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

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

觀測Ray托管的LLM工作負(fù)載的關(guān)鍵指標(biāo)

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

性能指標(biāo)

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

資源利用指標(biāo)

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

操作指標(biāo)

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

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

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

為Ray托管的工作負(fù)載設(shè)置可觀測性機制

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

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

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

使用KubeRay安裝Prometheus：

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

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

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

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

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ī)則允許你預(yù)先計算PromQL表達(dá)式，以加快查詢。比如說，計算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]))
          )
        )

表達(dá)方式解釋：

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

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

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

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"

設(shè)置Grafana儀表板

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

第1步：捕獲默認(rèn)儀表板

從Ray head pod中復(fù)制默認(rèn)儀表板：

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

默認(rèn)登錄憑據(jù)：

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

啟用Ray Serve Pods中的分析

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

?內(nèi)存分析

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

securityContext:
  capabilities:
    add:
    - SYS_PTRACE

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

示例用例：

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

?CPU分析

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

設(shè)置CPU分析機制：

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

示例用例：

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

端到端分析示例

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

• 內(nèi)存使用背后的罪魁禍?zhǔn)资谴笈妮斎霐?shù)據(jù)。
• CPU瓶頸是由于分詞功能效率低下造成的。

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

結(jié)論

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

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