可觀測性

監控與可觀測性

以高 GPU 使用率為目標

未充分利用的 GPUs 表示配置的 GPU 資源未完全由工作負載利用，導致運算容量浪費。對於 Amazon EKS 上的 AI/ML 工作負載，我們建議監控 GPU 使用率，以鎖定高 GPU 使用率並最佳化資源效率。未充分利用的 GPUs 會浪費運算容量並增加成本，而過度排程可能會導致爭用和效能降低。

我們建議在 Amazon EKS 上設定 Cloudwatch Container Insights，以識別 GPU 使用率指標較低的特定 Pod、節點或工作負載。它可輕鬆與 Amazon EKS 整合，可讓您監控 GPU 使用率，並在使用率低於目標層級時調整 Pod 排程或執行個體類型。或者，如果這不符合您的特定需求（例如進階視覺化），請考慮使用 NVIDIA 的 DCGM-Exporter 搭配 Prometheus 和 Grafana 進行 Kubernetes 原生監控。這兩種方法都提供 GPU 指標的洞見，可讓您在使用率低於目標層級時調整 Pod 排程或執行個體類型。透過 DCGM-Exporter 或 CloudWatch 檢查 NVIDIA 指標，例如 nvidia_smi_utilization_gpu(GPU 運算用量）和 nvidia_smi_utilization_memory(GPU 記憶體用量）。尋找趨勢，例如在特定時間或特定任務的持續低使用率。

Kubernetes 中的靜態資源限制（例如 CPU、記憶體和 GPU 計數）可能會導致過度佈建或利用率不足，尤其是推論等動態 AI/ML 工作負載。我們建議分析使用率趨勢並將工作負載合併到較少的 GPUs，確保在配置新的 GPU 之前充分利用每個 GPU。如果 GPUs 使用率不足，請考慮下列策略來最佳化排程和共用。若要進一步了解，請參閱 EKS Compute and Autoscaling 最佳實務以取得詳細資訊。

可觀測性和指標

使用 AI/ML 工作負載的監控和可觀測性工具

現代 AI/ML 服務在基礎設施、建模和應用程式邏輯的交集處運作。平台工程師會管理基礎設施、可觀測性堆疊，並確保收集、儲存和視覺化指標。AI/ML 工程師定義模型特定的指標，並專注於不同負載和分佈下的效能。應用程式開發人員會使用 api、路由請求和追蹤服務層級指標和使用者互動。成功取決於跨環境建立統一的可觀測性實務，讓所有利益相關者都能了解系統運作狀態和效能。

最佳化 AI/ML 工作負載的 Amazon EKS 叢集帶來獨特的監控挑戰，尤其是 GPU 記憶體管理。如果沒有適當的監控，組織通常會面臨out-of-memory(OOM) 錯誤、資源效率低下和不必要的成本。對於 EKS 客戶，有效監控可確保更好的效能、彈性和降低成本。一種整體方法，結合使用 NVIDIA DCGM Exporter 的精細 GPU 監控（例如，使用的 GPU 記憶體、釋放 GPU 記憶體）、監控和最佳化推論服務，以及使用 Ray、vLLM 等架構的原生指標，以及自訂指標的應用程式層級洞察。

工具和架構

某些工具和架構提供原生out-of-the-box指標來監控 AI/ML 工作負載，無需額外的自訂設定即可輕鬆整合。這些專注於效能層面，例如延遲、輸送量和權杖產生，這對於推論服務和基準測試至關重要。範例包括：

vLLM：適用於大型語言模型 (LLMs) 的高輸送量服務引擎，可提供請求延遲和記憶體用量等原生指標。
Ray：分散式運算架構，可發出可擴展 AI 工作負載的指標，包括任務執行時間和資源使用率。
Hugging Face Text Generation Inference (TGI)：用於部署和服務 LLMs 的工具組，具有內建的推論效能指標。
NVIDIA genai-perf：一種命令列工具，用於基準化生成式 AI 模型、測量輸送量、延遲和 LLM 特定指標，例如在特定時間間隔內完成的請求。

可觀測性方法

我們建議您使用下列其中一種方式實作任何其他可觀測性機制。

CloudWatch Container Insights 如果您的組織偏好設定最少的 AWS 原生工具，我們建議您使用 CloudWatch Container Insights。它與 NVIDIA DCGM Exporter 整合，以收集 GPU 指標，並提供預先建置的儀表板以快速洞察。透過在叢集上安裝 CloudWatch Observability 附加元件來啟用，Container Insights 會部署和管理 NVIDIA DCGM Exporter 的生命週期，從 Nvidia 的驅動程式收集 GPU 指標並將其公開給 CloudWatch。

加入 Container Insights 後，CloudWatch 會自動偵測您環境中的 NVIDIA GPUs、收集 NVIDIA GPUs 的關鍵運作狀態和效能指標做為 CloudWatch 指標，並在精心策劃out-of-the-box儀表板上提供這些指標。此外，Ray 和 vLLM 可以使用統一 CloudWatch 代理程式來傳送指標，與 CloudWatch 整合。 CloudWatch 這可簡化 EKS 環境中的可觀測性，讓團隊專注於效能調校和成本最佳化。

如需詳細資訊，若要檢視可用的指標完整清單，請參閱 Amazon EKS 和 Kubernetes Container Insights 指標。請參閱使用 Amazon CloudWatch Container Insights 取得 NVIDIA GPU 工作負載的操作洞見和最佳化 AI 回應能力：Amazon Bedrock 延遲最佳化推論的實際指南，以取得詳細的實作。

Managed Prometheus 和 Grafana 如果您的組織熟悉開放原始碼工具和自訂儀表板，我們建議您使用 NVIDIA DCGM-Exporter 和 Grafana 部署 Prometheus，以便使用進階視覺化進行 Kubernetes 原生監控。Prometheus 會抓取指標，而 Grafana 會建立進階視覺化。

此外，您可以使用 Ray 和 vLLM 等開放原始碼架構，將指標匯出至 Prometheus （可使用 Grafana 視覺化），也可以連線至 AWS X-Ray 資料來源，然後建置儀表板來查看分析、洞見或追蹤。

如需詳細資訊，請參閱使用 AWS 受管開放原始碼服務在 Amazon EKS 上監控 GPU 工作負載，以取得詳細的實作。

考慮監控核心訓練和微調指標

對於 EKS 上 AI/ML 工作負載的核心訓練指標，請考慮指標的組合，這些指標會指出 Amazon EKS 叢集的運作狀態和效能，以及其上執行的機器學習工作負載。如需詳細實作，請參閱在 Amazon EKS 上觀察機器學習工作負載的簡介。以下將細分建議監控的指標。

資源用量指標：

CPU、記憶體、GPU 和 GPU 記憶體使用量 — 監控 ML 工作負載的這些指標可讓您確保配置的資源足夠，並識別最佳化的機會。例如，追蹤等指標gpu_memory_usage_bytes，您可以識別記憶體消耗模式、偵測尖峰用量，以及計算百分位數，例如第 95 個百分位數 (P95)，以了解訓練期間最高的記憶體需求。這有助於最佳化模型和基礎設施，以避免 OOM 錯誤並降低成本。
節點和 Pod 資源使用率 — 追蹤節點和 Pod 層級的資源使用量，可協助您識別資源爭用和潛在的瓶頸。例如，檢查是否有任何節點過度使用，這可能會影響 Pod 排程。
將資源使用率與請求和限制進行比較 — 這可讓您深入了解叢集是否可以處理目前的工作負載並容納未來的工作負載。例如，將實際記憶體用量與限制進行比較，以避免out-of-memory錯誤。
ML 架構的內部指標 — 從 ML 架構 (TensorFlow、PyTorch) 擷取內部訓練和收斂指標，例如損失曲線、學習率、批次處理時間和訓練步驟持續時間，通常使用 TensorBoard 或類似方式視覺化。

模型效能指標：

準確性、精確度、召回和 F1-score — 這些對於了解 ML 模型的效能至關重要。例如，在訓練之後，計算驗證集上的 F1-score，以評估效能。
業務特定指標和 KPIs — 定義和追蹤直接連結到 AI/ML 計畫商業價值的指標。例如，在建議系統中，追蹤增加的使用者參與度。
追蹤這些指標一段時間 — 這有助於識別模型效能的任何降級。例如，比較跨模型版本的效能指標以找出趨勢。

資料品質和偏離指標：

輸入資料的統計屬性 — 隨著時間監控這些屬性，以偵測可能影響模型效能的資料偏離或異常。例如，追蹤輸入特徵的平均值以偵測輪班。
資料偏離偵測和提醒 — 實作機制，以自動偵測和提醒資料品質問題。例如，使用測試來比較目前資料與訓練資料，並在大幅偏離時發出提醒。

延遲和輸送量指標：

ML 訓練管道的End-to-End延遲 — 監控資料在整個訓練管道中流動所需的時間。例如，測量從資料擷取到模型更新的總時間。
訓練輸送量和處理速率 — 追蹤訓練期間處理的資料量，以確保效率。例如，監控每秒處理的正值和負值樣本。
檢查點還原延遲 – 在繼續任務、從失敗中復原或初始化時，監控從儲存位置 (S3、EFS、FSx 等）將儲存的模型檢查點載入 GPU/CPU 記憶體所需的時間。此指標會直接影響作業復原時間、冷啟動效能和干擾管道的整體效率。在自動擴展推論服務中，緩慢的檢查點載入可能會導致冷啟動延遲和使用者體驗降低。這些相關指標也常用於改善模型檢查點：檢查點停機時間延遲、模型還原序列化時間、檢查點大小和檢查點還原失敗計數。
推論請求持續時間 – 監控完成推論請求所需的時間。這是從收到初始請求到模型完成回應的時間。
權杖輸送量 - 監控權杖處理時間，以衡量模型效能並最佳化擴展決策。處理緩慢可能表示效率低落或資源利用率低，影響成本效益。追蹤每秒中的字符和每秒發出的字符等指標，以及處理時間，有助於識別效能瓶頸、速度變慢和成本驅動因素。
識別效能瓶頸 — 使用這些指標，在訓練程序中找出要最佳化的區域。例如，分析資料載入與模型運算所花費的時間。

錯誤率和失敗：

監控整個 ML 管道的錯誤 — 這包括資料預先處理、模型訓練和推論。例如，在預先處理中記錄錯誤，以快速識別問題。
識別和調查重複錯誤 — 這有助於維護高品質模型並確保一致的效能。例如，分析日誌以尋找模式，例如導致失敗的特定資料。

Kubernetes 和 EKS 特定指標：

Kubernetes 叢集狀態指標 — 監控各種 Kubernetes 物件的運作狀態和狀態，包括 Pod、節點和控制平面。例如，使用之類的工具kubectl來檢查 Pod 狀態。
成功/失敗管道執行 — 追蹤成功/失敗管道執行、任務持續時間、步驟完成時間和協同運作錯誤（例如，使用 Kubeflow/Mlflow/Argo 事件）。
AWS 服務指標 — 追蹤支援 EKS 基礎設施的其他 AWS 服務的指標及其上執行的應用程式。例如，如果使用 Amazon S3，請監控儲存貯體大小以追蹤儲存體用量。
Kubernetes 控制平面指標 — 監控 API 伺服器、排程器、控制器管理員等資料庫是否有效能問題或故障。例如，追蹤 API 伺服器請求延遲以獲得回應能力。

在後續主題中，我們會示範如何收集上述幾個指標的資料。我們將提供兩種 AWS 建議方法的範例：AWS 原生 CloudWatch Container Insights 和開放原始碼 Amazon Managed Prometheus with Amazon Managed Grafana。您可以根據整體可觀測性需求選擇其中一個解決方案。如需 Container Insights 指標的完整清單，請參閱 Amazon EKS 和 Kubernetes Container Insights 指標。

考慮監控即時線上推論指標

在即時系統中，低延遲對於及時回應使用者或其他相依系統至關重要。高延遲可能會降低使用者體驗或違反效能需求。影響推論延遲的元件包括模型載入時間、預先處理時間、實際預測時間、後製處理時間、網路傳輸時間。我們建議監控推論延遲，以確保符合服務層級協議 (SLAs) 的低延遲回應，並為下列項目開發自訂指標。在預期負載下進行測試，包括網路延遲、考慮並行請求，以及使用不同的批次大小進行測試。

首次權杖的時間 (TTFT) — 從使用者提交請求到他們收到回應開始的時間長度（第一個單字、權杖或區塊）。例如，在聊天機器人中，您會檢查使用者提出問題後產生第一段輸出（字符）所需的時間。
End-to-End延遲：這是從收到請求到傳送回回應的總時間。例如，測量從請求到回應的時間。
每秒輸出權杖 (TPS) — 指出模型開始回應後產生新權杖的速度。例如，在聊天機器人中，您可以追蹤基準文字的語言模型產生速度。
錯誤率 — 追蹤失敗的請求，這可能表示效能問題。例如，監控大型文件或特定字元的失敗請求。
輸送量 — 測量系統每單位時間可處理的請求或操作數量。例如，追蹤每秒請求以處理尖峰負載。

K/V （金鑰/值）快取可以是強大的推論延遲最佳化技術，特別是與轉換器型模型相關者。K/V 快取會存放先前轉換器層運算的金鑰和值張量，減少自動迴歸推論期間的備援運算，尤其是大型語言模型 LLMs)。快取效率指標（特別是 K/V 或工作階段快取使用）：

快取命中/遺失率 — 對於利用快取 (K/V 或內嵌快取）的推論設定，測量快取的協助頻率。低命中率可能表示快取組態或工作負載變更不佳，這兩者都可能增加延遲。

追蹤 GPU 記憶體用量

如考慮監控核心訓練和微調指標主題所述，GPU 記憶體用量對於防止out-of-memory(OOM) 錯誤並確保有效率的資源使用率至關重要。下列範例示範如何檢測您的訓練應用程式，以公開自訂長條圖指標 gpu_memory_usage_bytes，並計算 P95 記憶體用量以識別尖峰耗用量。請務必在預備環境中使用範例訓練任務（例如微調轉換器模型）進行測試。

AWS 原生 CloudWatch Container Insights 範例

此範例示範如何使用 AWS 原生方法檢測您的訓練應用程式，以長條圖gpu_memory_usage_bytes的形式公開。請注意，您的 AI/ML 容器必須設定為以 CloudWatch Embedded Metrics Format (EMF) 格式發出結構化日誌。CloudWatch 日誌會剖析 EMF 並發佈指標。在訓練應用程式中使用 aws_embedded_metrics，將 EMF 格式的結構化日誌傳送至擷取 GPU 指標的 CloudWatch Logs。


from aws_embedded_metrics import metric_scope
import torch
import numpy as np

memory_usage = []

@metric_scope
def log_gpu_memory(metrics):
    # Record current GPU memory usage
    mem = torch.cuda.memory_allocated()
    memory_usage.append(mem)

    # Log as histogram metric
    metrics.set_namespace("MLTraining/GPUMemory")
    metrics.put_metric("gpu_memory_usage_bytes", mem, "Bytes", "Histogram")

    # Calculate and log P95 if we have enough data points
    if len(memory_usage) >= 10:
        p95 = np.percentile(memory_usage, 95)
        metrics.put_metric("gpu_memory_p95_bytes", p95, "Bytes")
        print(f"Current memory: {mem} bytes, P95: {p95} bytes")

# Example usage in training loop
for epoch in range(20):
    # Your model training code would go here
    log_gpu_memory()

Prometheus 和 Grafana 範例

此範例示範如何使用 Python 中的 Prometheus 用戶端程式庫，檢測您的訓練應用程式以長條圖gpu_memory_usage_bytes`形式公開。


from prometheus_client import Histogram
from prometheus_client import start_http_server
import pynvml

start_http_server(8080)
memory_usage = Histogram(
    'gpu_memory_usage_bytes',
    'GPU memory usage during training',
    ['gpu_index'],
    buckets=[1e9, 2e9, 4e9, 8e9, 16e9, 32e9]
)

# Function to get GPU memory usage
def get_gpu_memory_usage():
    if torch.cuda.is_available():
        # Get the current GPU device
        device = torch.cuda.current_device()

        # Get memory usage in bytes
        memory_allocated = torch.cuda.memory_allocated(device)
        memory_reserved = torch.cuda.memory_reserved(device)

        # Total memory usage (allocated + reserved)
        total_memory = memory_allocated + memory_reserved

        return device, total_memory
    else:
        return None, 0

# Get GPU memory usage
gpu_index, memory_used = get_gpu_memory_usage()

追蹤即時線上推論的推論請求持續時間

如考慮監控核心訓練和微調指標主題所述，低延遲對於為使用者或其他相依系統提供及時回應至關重要。下列範例示範如何追蹤由推論應用程式inference_request_duration_seconds公開的自訂長條圖指標。計算第 95 個百分位數 (P95) 延遲以專注於最壞情況，在預備環境中使用合成推論請求（例如，透過 Locust) 進行測試，並設定警示閾值（例如，>500 毫秒）以偵測 SLA 違規。

AWS 原生 CloudWatch Container Insights 範例

此範例示範如何使用 AWS CloudWatch Embedded Metric Format 在 inference_request_duration_seconds 的推論應用程式中建立自訂長條圖指標。


import boto3
import time
from aws_embedded_metrics import metric_scope, MetricsLogger

cloudwatch = boto3.client('cloudwatch')

@metric_scope
def log_inference_duration(metrics: MetricsLogger, duration: float):
    metrics.set_namespace("ML/Inference")
    metrics.put_metric("inference_request_duration_seconds", duration, "Seconds", "Histogram")
    metrics.set_property("Buckets", [0.1, 0.5, 1, 2, 5])

@metric_scope
def process_inference_request(metrics: MetricsLogger):
    start_time = time.time()

    # Your inference processing code here
    # For example:
    # result = model.predict(input_data)

    duration = time.time() - start_time
    log_inference_duration(metrics, duration)

    print(f"Inference request processed in {duration} seconds")

# Example usage
process_inference_request()

Prometheus 和 Grafana 範例

此範例示範如何使用 Python 中的 Prometheus 用戶端程式庫，在推論應用程式中為 inference_request_duration_seconds 建立自訂長條圖指標：


from prometheus_client import Histogram
from prometheus_client import start_http_server
import time

start_http_server(8080)
request_duration = Histogram(
    'inference_request_duration_seconds',
    'Inference request latency',
    buckets=[0.1, 0.5, 1, 2, 5]
)
start_time = time.time()
# Process inference request
request_duration.observe(time.time() - start_time)

在 Grafana 中，使用查詢histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod))將 P95 延遲趨勢視覺化。若要進一步了解，請參閱 Prometheus 直方圖文件和 Prometheus 用戶端文件。

追蹤即時線上推論的字符輸送量

如考慮監控核心訓練和微調指標主題所述，我們建議您監控權杖處理時間，以衡量模型效能並最佳化擴展決策。下列範例示範如何追蹤您的推論應用程式token_processing_duration_seconds公開的自訂長條圖指標。計算第 95 個百分位數 (P95) 持續時間以分析處理效率、在非生產叢集中使用模擬請求負載（例如每秒 100 到 1000 個請求）進行測試，以及調整 KEDA 觸發以最佳化擴展。

AWS 原生 CloudWatch Container Insights 範例

此範例示範如何使用 AWS CloudWatch Embedded Metric Format 在 token_processing_duration_seconds 的推論應用程式中建立自訂長條圖指標。它使用維度 (`set_dimension) with a custom `get_duration_bucket 函數將持續時間分類為儲存貯體（例如 "⇐0.01"、">1")。


import boto3
import time
from aws_embedded_metrics import metric_scope, MetricsLogger

cloudwatch = boto3.client('cloudwatch')

@metric_scope
def log_token_processing(metrics: MetricsLogger, duration: float, token_count: int):
    metrics.set_namespace("ML/TokenProcessing")
    metrics.put_metric("token_processing_duration_seconds", duration, "Seconds")
    metrics.set_dimension("ProcessingBucket", get_duration_bucket(duration))
    metrics.set_property("TokenCount", token_count)

def get_duration_bucket(duration):
    buckets = [0.01, 0.05, 0.1, 0.5, 1]
    for bucket in buckets:
        if duration <= bucket:
            return f"<={bucket}"
    return f">{buckets[-1]}"

@metric_scope
def process_tokens(input_text: str, model, tokenizer, metrics: MetricsLogger):
    tokens = tokenizer.encode(input_text)
    token_count = len(tokens)

    start_time = time.time()
    # Process tokens (replace with your actual processing logic)
    output = model(tokens)
    duration = time.time() - start_time

    log_token_processing(metrics, duration, token_count)
    print(f"Processed {token_count} tokens in {duration} seconds")
    return output

Prometheus 和 Grafana 範例

此範例示範如何在推論應用程式中使用 Python 中的 Prometheus 用戶端程式庫為 token_processing_duration_seconds 建立自訂長條圖指標。


from prometheus_client import Histogram
from prometheus_client import start_http_server
import time

start_http_server(8080)
token_duration = Histogram(
    'token_processing_duration_seconds',
    'Token processing time per request',
    buckets=[0.01, 0.05, 0.1, 0.5, 1]
)
start_time = time.time()
# Process tokens
token_duration.observe(time.time() - start_time)

在 Grafana 中，使用查詢histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))`將 P95 處理時間趨勢視覺化。若要進一步了解，請參閱 Prometheus 直方圖文件和 Prometheus 用戶端文件。

測量檢查點還原延遲

如考慮監控核心訓練和微調指標主題所述，檢查點延遲是模型生命週期的多個階段期間的關鍵指標。下列範例示範如何追蹤應用程式checkpoint_restore_duration_seconds`公開的自訂長條圖指標。計算第 95 個百分位數 (P95) 持續時間以監控還原效能、在非生產叢集中使用 Spot 中斷進行測試，並設定警示閾值（例如 <30 秒）以偵測延遲。

AWS 原生 CloudWatch Container Insights 範例

此範例示範如何使用 CloudWatch Insights 檢測批次應用程式，以長條圖的形式公開 checkpoint_restore_duration_seconds：


import boto3
import time
import torch
from aws_embedded_metrics import metric_scope, MetricsLogger

@metric_scope
def log_checkpoint_restore(metrics: MetricsLogger, duration: float):
    metrics.set_namespace("ML/ModelOperations")
    metrics.put_metric("checkpoint_restore_duration_seconds", duration, "Seconds", "Histogram")
    metrics.set_property("Buckets", [1, 5, 10, 30, 60])
    metrics.set_property("CheckpointSource", "s3://my-bucket/checkpoint.pt")

@metric_scope
def load_checkpoint(model, checkpoint_path: str, metrics: MetricsLogger):
    start_time = time.time()

    # Load model checkpoint
    model.load_state_dict(torch.load(checkpoint_path))

    duration = time.time() - start_time
    log_checkpoint_restore(metrics, duration)

    print(f"Checkpoint restored in {duration} seconds")

Prometheus 和 Grafana 範例

此範例示範如何使用 Python 中的 Prometheus 用戶端程式庫來檢測批次應用程式，以長條圖checkpoint_restore_duration_seconds的形式公開：


from prometheus_client import Histogram
from prometheus_client import start_http_server
import torch

start_http_server(8080)
restore_duration = Histogram(
    'checkpoint_restore_duration_seconds',
    'Time to restore checkpoint',
    buckets=[1, 5, 10, 30, 60]
)
with restore_duration.time():
    model.load_state_dict(torch.load("s3://my-bucket/checkpoint.pt"))

在 Grafana 中，使用查詢histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le))將 P95 還原延遲趨勢視覺化。若要進一步了解，請參閱 Prometheus 直方圖文件和 Prometheus 用戶端文件。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

儲存

效能