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