本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

可觀測性

監控與可觀測性

GPU 指標說明

GPU 使用率指標會顯示 GPU 在範例時段內是否執行任何工作。此指標會擷取 GPU 執行至少一個指令的時間百分比，但不會顯示 GPU 使用其硬體的效率。GPU 包含多個串流多處理器 (SMs)，這是執行指示的平行處理單元。100% 使用率讀數可能表示 GPU 在其所有 SMs 中執行繁重的平行工作負載，也可能表示在範例期間內啟動 GPU 的單一小型指令。若要了解實際使用率，您需要在硬體架構的多個層級檢查 GPU 指標。每個串流多處理器都是由不同的核心類型所建置，而且每個 layer 都會公開不同的效能特性。最上層指標 (GPU 使用率、記憶體使用率、GPU Power 和 GPU 溫度，透過 nvidia-smi 可見） 會顯示裝置是否處於作用中狀態。更深入的指標 (SM 使用率、SM 活動和張量核心使用量） 會顯示 GPU 使用其資源的效率。

以高 GPU 用電量為目標

未充分利用的 GPUs 會浪費運算容量並增加成本，因為工作負載無法同時參與所有 GPU 元件。對於 Amazon EKS 上的 AI/ML 工作負載，請將 GPU 用電量追蹤為代理，以識別實際的 GPU 活動。GPU 使用率會報告 GPU 執行任何核心的時間百分比，但不會顯示串流多處理器、記憶體控制器和張量核心是否同時處於作用中狀態。電力使用會公開此差距，因為完全參與的硬體比執行輕量型核心或任務之間閒置的硬體消耗更多電力。將耗電量與 GPU 的熱設計能力 (TDP) 進行比較，以發現使用率不足，然後調查您的工作負載是否因 CPU 預先處理、網路 I/O 或效率不佳的批次大小而遇到瓶頸。

在 Amazon EKS 上設定 CloudWatch Container Insights，以識別 GPU 耗電量低的 Pod、節點或工作負載。此工具直接與 Amazon EKS 整合，可讓您監控 GPU 耗電量，並在耗電量低於目標層級時調整 Pod 排程或執行個體類型。如果您需要進階視覺化或自訂儀表板，請使用 NVIDIA 的 DCGM-Exporter 搭配 Prometheus 和 Grafana 進行 Kubernetes 原生監控。兩者都接近表面金鑰 NVIDIA 指標，例如 nvidia_smi_power_draw(GPU 耗電量） 和 nvidia_smi_temperature_gpu(GPU 溫度）。如需指標清單，請瀏覽 https：//https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.htm。尋找模式，例如在特定時間或特定任務中持續保持低功耗。這些趨勢可協助您識別合併工作負載或調整資源配置的位置。

Kubernetes 中的靜態資源限制 （例如 CPU、記憶體和 GPU 計數） 通常會導致過度佈建或利用率不足，尤其是在需求波動的推論等動態 AI/ML 工作負載。分析您的使用率趨勢，並將工作負載合併到較少的 GPUs。在配置其他 GPU 之前，請確定每個 GPU 都達到完整的使用率。此方法可減少浪費並降低成本。如需最佳化排程和共用策略的詳細指引，請參閱 EKS Compute and Autoscaling 最佳實務

可觀測性和指標

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

現代 AI/ML 服務需要跨基礎設施、建模和應用程式邏輯進行協調。平台工程師管理基礎設施和可觀測性堆疊。它們收集、存放和視覺化指標。AI/ML 工程師定義模型特定的指標，並在不同的負載和資料分佈下監控效能。應用程式開發人員會使用 APIs、路由請求，以及追蹤服務層級指標和使用者互動。如果沒有統一的可觀測性實務，這些團隊會在孤島中工作，並錯過有關系統運作狀態和效能的關鍵訊號。建立跨環境的共用可見性，可確保所有利益相關者都能及早偵測問題並維持可靠的服務。

最佳化 AI/ML 工作負載的 Amazon EKS 叢集帶來獨特的監控挑戰，尤其是 GPU 記憶體管理。如果沒有適當的監控，組織會面臨out-of-memory(OOM) 錯誤、資源效率低下和不必要的成本。有效的監控可確保 EKS 客戶有更好的效能、彈性並降低成本。使用結合三個監控層的整體方法。首先，使用 NVIDIA DCGM Exporter 監控精細的 GPU 指標，以追蹤 GPU 用電量、GPU 溫度、SM 活動、SM 佔用率和 XID 錯誤。其次，監控 Ray 和 vLLM 等推論服務架構，透過其原生指標取得分散式工作負載洞見。第三，收集應用程式層級的洞見，以追蹤工作負載特定的自訂指標。這種分層方法為您提供從硬體使用率到應用程式效能的可見性。

工具和架構

數個工具和架構提供原生out-of-the-box指標，用於監控 AI/ML 工作負載。這些內建指標可免除自訂檢測的需求，並縮短設定時間。這些指標著重於延遲、輸送量和權杖產生等效能層面，這些層面對於推論服務和基準測試至關重要。使用原生指標可讓您立即開始監控，而無需建置自訂集合管道。

可觀測性方法

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

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

安裝 Container Insights 後，CloudWatch 會自動偵測您環境中的 NVIDIA GPUs，並收集重要的運作狀態和效能指標。這些指標會出現在已整理out-of-the-box儀表板上。您也可以使用統一 CloudWatch Agent 將 Ray 和 vLLM 與 CloudWatch 整合，以傳送其原生指標。 CloudWatch 這種統一的方法簡化了 EKS 環境中的可觀測性，並讓團隊專注於效能調校和成本最佳化，而不是建置監控基礎設施。

如需可用指標的完整清單，請參閱 Amazon EKS 和 Kubernetes Container Insights 指標。如需實作 GPU step-by-step指引，請參閱使用 Amazon CloudWatch Container Insights 取得 NVIDIA GPU 工作負載的操作洞見。如需最佳化推論延遲的實際範例，請參閱最佳化 AI 回應能力：Amazon Bedrock 延遲最佳化推論的實際指南。

受管 Prometheus 和 Grafana 如果您的組織需要自訂儀表板和進階視覺化功能，請使用 NVIDIA DCGM-Exporter 和 Grafana 部署 Prometheus 以進行 Kubernetes 原生監控。Prometheus 會從 DCGM-Exporter 抓取和存放 GPU 指標，而 Grafana 則提供靈活的視覺化和提醒功能。相較於 CloudWatch Container Insights，此方法可讓您更能控制儀表板設計和指標保留。

您可以整合 Ray、vLLM Ray 和 vLLM 等開放原始碼架構，將原生指標匯出至 Prometheus，以擴展此監控堆疊。您也可以將 Grafana 連線至 AWS X-Ray 資料來源，以視覺化分散式追蹤，並識別推論管道的效能瓶頸。此組合透過應用程式層級請求流程，提供 GPU 層級指標end-to-end可見性。

如需部署此監控堆疊的step-by-step指引，請參閱使用 AWS 受管開放原始碼服務在 Amazon EKS 上監控 GPU 工作負載。

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

監控核心訓練指標，以追蹤 Amazon EKS 叢集的運作狀態和效能，以及其上執行的機器學習工作負載。訓練工作負載與推論工作負載具有不同的監控需求，因為它們會長時間執行、以不同的方式使用資源，而且需要模型收斂和資料管道效率的可見性。以下指標可協助您識別瓶頸、最佳化資源配置，並確保訓練任務成功完成。如需實作此監控方法step-by-step指引，請參閱在 Amazon EKS 上觀察機器學習工作負載的簡介。

資源用量指標

監控資源用量指標，以驗證您的資源是否正確使用。這些指標可協助您識別瓶頸和根本原因效能問題。

模型效能指標

監控模型效能指標，以驗證您的訓練程序是否產生符合準確性和業務需求的模型。這些指標可協助您判斷何時停止訓練、比較模型版本，以及識別效能降低。

資料品質和偏離指標

監控資料品質和偏離指標，以確保您的訓練資料保持一致且具代表性。資料偏離可能會導致模型效能隨著時間降低，而資料品質問題可能會阻止模型收斂或產生不可靠的結果。

延遲和輸送量指標

監控延遲和輸送量指標，以識別訓練管道中的瓶頸，並最佳化資源使用率。這些指標可協助您了解在訓練期間花費的時間，以及專注於最佳化工作的位置。

錯誤率和失敗

監控整個訓練管道的錯誤率和故障，以維持可靠性並防止運算資源浪費。未偵測到的錯誤可能會導致訓練任務無提示地失敗、產生無效的模型，或在發現問題之前浪費數小時的 GPU 時間。

Kubernetes 和 EKS 特定指標

監控 Kubernetes 和 EKS 指標，以確保您的叢集基礎設施正常運作，並可支援您的訓練工作負載。這些指標可協助您在基礎設施問題導致訓練任務失敗或效能降低之前對其進行偵測。

應用程式和執行個體日誌

收集和分析應用程式和執行個體日誌，以診斷指標本身無法解釋的問題。日誌提供有關錯誤、狀態變更和系統事件的詳細內容，協助您了解訓練任務失敗或效能不佳的原因。將日誌與指標建立關聯可讓您更快地找出根本原因。

下列各節說明如何使用兩種 AWS 建議的方法收集上述指標：CloudWatch Container Insights 和 Amazon Managed Prometheus 與 Amazon Managed Grafana。 https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html如果您偏好具有最少設定和預先建置儀表板的 AWS 原生工具，請選擇 CloudWatch Container Insights。如果您需要自訂儀表板、進階視覺化功能，或想要與現有的 Prometheus 型監控基礎設施整合，請選擇 Amazon Managed Prometheus with Amazon Managed Grafana。如需可用 Container Insights 指標的完整清單，請參閱 Amazon EKS 和 Kubernetes Container Insights 指標。

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

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

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

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

追蹤 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 用戶端文件。