譯者 | 布加迪
審校 | 重樓
前言
GPT-4、PHI2、BERT和T5等大語言模型（LLM）的出現(xiàn)已徹底改變了自然語言處理，這些模型支持高端應(yīng)用程序，包括聊天機器人、推薦系統(tǒng)和分析。然而，LLM中工作負載的規(guī)模和復(fù)雜性使得保證性能和可靠性成了一大挑戰(zhàn)。在這種情況下，在使用Ray等框架部署工作負載的同時進行監(jiān)控和觀測顯得非常必要。
Ray是一種分布式計算框架，提供了一個強大的平臺，可以跨集群有效地擴展LLM工作負載。因此，它成了托管、管理和觀測LLM的一種出色選擇。利用Ray的內(nèi)置特性，并結(jié)合Prometheus和Grafana觀測關(guān)鍵度量指標，將幫助用戶有效地監(jiān)控、優(yōu)化資源的使用，并快速診斷生產(chǎn)環(huán)境中的問題。
本文探討了Ray托管的LLM工作負載中可觀測性的重要性、需要監(jiān)控的關(guān)鍵度量指標以及使用Prometheus和Grafana搭建可觀測性機制的詳細指南。
為什么使用Ray處理LLM工作負載？
Ray為分布式、可擴展的應(yīng)用程序設(shè)計，因而成為了托管和管理LLM工作負載的理想選擇。讓Ray成為出色選擇的主要特性包括如下：
- 動態(tài)任務(wù)調(diào)度：Ray的細粒度任務(wù)調(diào)度確保了資源的有效利用，特別是在處理LLM推理任務(wù)時，這類任務(wù)的大小和復(fù)雜性可能大有不同。
- 易于集成：Ray與Hugging Face Transformers等框架無縫集成，可以輕松部署預(yù)訓(xùn)練的LLM。
- 自動擴展：Ray的集群自動擴展器可以根據(jù)工作負載的需求動態(tài)調(diào)整資源，確保成本效益和可擴展性。
- 可觀測性支持：Ray提供了與Prometheus兼容的度量指標端點，簡化了分布式系統(tǒng)的監(jiān)控設(shè)置。
這些特性使Ray不僅是一種計算框架，還是用于在實際應(yīng)用程序中運行、監(jiān)控和擴展LLM的基礎(chǔ)工具。
觀測Ray托管的LLM工作負載的關(guān)鍵指標
為了確保Ray托管的LLM工作負載的順利運行，跟蹤一系列性能、資源利用和操作度量指標就至關(guān)重要。以下是主要類別：
性能指標
- 任務(wù)延遲：測量單個Ray任務(wù)完成所需的時間，這對于識別推理管道中的瓶頸至關(guān)重要。
- 吞吐量：跟蹤每秒完成的任務(wù)數(shù)量，反映了系統(tǒng)處理高請求量的能力。
- 詞元處理速率：測量每秒處理的詞元數(shù)量，特別是與GPT-4等基于Transformer的模型相關(guān)。
資源利用指標
- CPU和GPU利用率：監(jiān)控整個集群的資源使用情況，確保工作負載的高效分配。
- 內(nèi)存使用：跟蹤內(nèi)存消耗以防止內(nèi)存不足錯誤，這對于托管大型模型尤其重要。
- 對象存儲利用率：觀測Ray的內(nèi)存中對象存儲的使用情況，以便跨任務(wù)有效地共享數(shù)據(jù)。
操作指標
錯誤率：監(jiān)控任務(wù)失敗率，以快速檢測和解決問題。
節(jié)點可用性：跟蹤Ray集群中節(jié)點的運行狀況，確保可靠性。
隊列長度：衡量掛起任務(wù)的數(shù)量，表明處理過程中的潛在瓶頸。
為Ray托管的工作負載設(shè)置可觀測性機制
Ray中的可觀測性需要使用度量指標來了解系統(tǒng)性能和診斷問題。通過將Ray與Prometheus和Grafana相集成，你就可以深入了解工作負載的行為。
第1步：設(shè)置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和服務(wù)監(jiān)控器
設(shè)置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ī)則允許你預(yù)先計算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天內(nèi)在特定延遲閾值內(nèi)完成的更新的百分比。
第3步：設(shè)置警報規(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"設(shè)置Grafana儀表板
Grafana為度量指標提供了豐富的可視化。下面介紹了如何為Ray設(shè)置儀表板：
第1步：捕獲默認儀表板
從Ray head pod中復(fù)制默認儀表板：
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)控、調(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等工具，以收集詳細的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)。
端到端分析示例
當你集成內(nèi)存分析和CPU分析時，這將為你提供系統(tǒng)性能的總體概況。為了更好地說明這一點，考慮一個有延遲峰值的LLM推理任務(wù)。如果你把內(nèi)存分析和CPU分析關(guān)聯(lián)起來，就會發(fā)現(xiàn)：
- 內(nèi)存使用背后的罪魁禍首是大批的輸入數(shù)據(jù)。
- CPU瓶頸是由于分詞功能效率低下造成的。
如果你優(yōu)化批處理大小并重構(gòu)瓶頸函數(shù)，性能可能會得到很大程度的提高。
結(jié)論
使用Ray的分布式LLM工作負載以及可靠工具的可觀測性將確保團隊從這些系統(tǒng)中獲得性能、可靠性和可擴展性。這篇指南介紹了在Ray上設(shè)置和監(jiān)控LLM工作負載，很實用。適當?shù)目捎^測性將幫助開發(fā)人員和操作人員盡早發(fā)現(xiàn)問題，優(yōu)化資源使用，并進一步改善用戶在使用NLP應(yīng)用程序時獲得的體驗。
原文標題：Observing and monitoring Large Language Model workloads with Ray，作者：Swastik Gour
