기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

관찰성

모니터링 및 관찰성

GPU 지표 설명

GPU 사용률 지표는 샘플 기간 동안 GPU가 작업을 실행했는지 여부를 보여줍니다. 이 지표는 GPU가 하나 이상의 명령을 실행한 시간의 백분율을 캡처하지만 GPU가 하드웨어를 얼마나 효율적으로 사용했는지는 나타내지 않습니다. GPU에는 명령을 실행하는 병렬 처리 장치인 여러 스트리밍 멀티프로세서(SMs)가 포함되어 있습니다. 100% 사용률 판독값은 GPU가 모든 SMs에서 과중한 병렬 워크로드를 실행했음을 의미하거나 샘플 기간 동안 작은 명령 하나로 GPU를 활성화했음을 의미할 수 있습니다. 실제 사용률을 이해하려면 하드웨어 아키텍처의 여러 수준에서 GPU 지표를 검사해야 합니다. 각 스트리밍 멀티프로세서는 서로 다른 코어 유형으로 빌드되며 각 계층은 서로 다른 성능 특성을 노출합니다. 최상위 지표(GPU 사용률, 메모리 사용률, GPU 전력 및 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 전력 소비가 적은 포드, 노드 또는 워크로드를 식별합니다. 이 도구는 Amazon EKS와 직접 통합되어 GPU 전력 소비를 모니터링하고 전력 사용량이 목표 수준 아래로 떨어질 때 포드 스케줄링 또는 인스턴스 유형을 조정할 수 있습니다. 고급 시각화 또는 사용자 지정 대시보드가 필요한 경우 Kubernetes 네이티브 모니터링을 위해 Prometheus 및 Grafana와 함께 NVIDIA의 DCGM-Exporter를 사용합니다. 두 지표 모두 nvidia_smi_power_draw (GPU 전력 소비) 및 nvidia_smi_temperature_gpu (GPU 온도)와 같은 주요 NVIDIA 지표에 접근합니다. 지표 목록은 https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.htm 참조하십시오. 특정 시간 동안 지속적으로 낮은 전력 사용량 또는 특정 작업과 같은 패턴을 찾습니다. 이러한 추세는 워크로드를 통합하거나 리소스 할당을 조정할 위치를 식별하는 데 도움이 됩니다.

Kubernetes의 정적 리소스 제한(예: CPU, 메모리 및 GPU 수)은 특히 수요가 변동하는 추론과 같은 동적 AI/ML 워크로드의 경우 과다 프로비저닝 또는 과소 사용으로 이어지는 경우가 많습니다. 사용률 추세를 분석하고 워크로드를 더 적은 수의 GPUs. 추가 GPU를 할당하기 전에 각 GPU가 전체 사용률에 도달했는지 확인합니다. 이 접근 방식은 낭비를 줄이고 비용을 절감합니다. 예약 및 공유 전략 최적화에 대한 자세한 지침은 EKS 컴퓨팅 및 오토 스케일링 모범 사례를 참조하세요.

관찰성 및 지표

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과 같은 추론 서비스 프레임워크를 모니터링하여 네이티브 지표를 통해 분산 워크로드 인사이트를 얻습니다. 셋째, 애플리케이션 수준 인사이트를 수집하여 워크로드와 관련된 사용자 지정 지표를 추적합니다. 이 계층화된 접근 방식을 사용하면 하드웨어 사용률부터 애플리케이션 성능까지 파악할 수 있습니다.

도구 및 프레임워크

여러 도구와 프레임워크는 AI/ML 워크로드를 모니터링하기 위한 기본 out-of-the-box 지표를 제공합니다. 이러한 기본 제공 지표를 사용하면 사용자 지정 계측이 필요하지 않으며 설정 시간이 단축됩니다. 지표는 추론 서비스 및 벤치마킹에 중요한 지연 시간, 처리량 및 토큰 생성과 같은 성능 측면에 중점을 둡니다. 네이티브 지표를 사용하면 사용자 지정 컬렉션 파이프라인을 빌드하지 않고도 즉시 모니터링을 시작할 수 있습니다.

관찰성 방법

다음 방법 중 하나로 추가 관찰성 메커니즘을 구현하는 것이 좋습니다.

CloudWatch Container Insights 조직에서 최소한의 설정으로 AWS 네이티브 도구를 선호하는 경우 CloudWatch Container Insights를 사용하는 것이 좋습니다. NVIDIA DCGM Exporter와 통합되어 GPU 지표를 수집하고 빠른 인사이트를 위한 사전 구축된 대시보드를 제공합니다. 클러스터에 CloudWatch Observability 추가 기능을 설치하여 활성화되는 Container Insights는 Nvidia 드라이버에서 GPU 지표를 수집하여 CloudWatch에 노출하는 NVIDIA DCGM Exporter의 수명 주기를 배포하고 관리합니다.

Container Insights를 설치한 후 CloudWatch는 환경에서 NVIDIA GPUs 자동으로 감지하고 중요한 상태 및 성능 지표를 수집합니다. 이러한 지표는 큐레이션된 out-of-the-box 대시보드에 표시됩니다. 통합 CloudWatch 에이전트를 사용하여 Ray 및 vLLM을 CloudWatch와 통합하여 기본 지표를 전송할 수도 있습니다. CloudWatch 이 통합 접근 방식은 EKS 환경의 관찰성을 간소화하고 팀이 모니터링 인프라를 구축하는 대신 성능 튜닝 및 비용 최적화에 집중할 수 있도록 합니다.

사용 가능한 지표의 전체 목록은 Amazon EKS 및 Kubernetes Container Insights 지표를 참조하세요. GPU 모니터링 구현에 대한 step-by-step 지침은 Amazon CloudWatch Container Insights를 사용하여 NVIDIA GPU 워크로드에 대한 운영 인사이트 얻기를 참조하세요. 추론 지연 시간 최적화의 실제 예는 AI 응답성 최적화: Amazon Bedrock 지연 시간 최적화 추론에 대한 실제 가이드를 참조하세요.

Managed Prometheus 및 Grafana 조직에서 사용자 지정 대시보드와 고급 시각화 기능이 필요한 경우 Kubernetes용 NVIDIA DCGM-Exporter 및 Grafana 네이티브 모니터링을 사용하여 Prometheus를 배포합니다. Prometheus는 DCGM-Exporter에서 GPU 지표를 스크레이프하고 저장하는 반면, Grafana는 유연한 시각화 및 알림 기능을 제공합니다. 이 접근 방식을 사용하면 CloudWatch Container Insights에 비해 대시보드 설계 및 지표 보존을 더 잘 제어할 수 있습니다.

Ray 및 vLLM Ray 및 vLLM과 같은 오픈 소스 프레임워크를 통합하여 기본 지표https://awslabs.github.io/ai-on-eks/docs/blueprints/inference/GPUs/vLLM-rayserve를 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 지표를 모니터링하여 클러스터 인프라가 정상 상태를 유지하고 훈련 워크로드를 지원할 수 있는지 확인합니다. 이러한 지표는 훈련 작업 실패 또는 성능 저하를 유발하기 전에 인프라 문제를 감지하는 데 도움이 됩니다.

애플리케이션 및 인스턴스 로그

애플리케이션 및 인스턴스 로그를 수집하고 분석하여 지표만으로는 설명할 수 없는 문제를 진단합니다. 로그는 오류, 상태 변경 및 시스템 이벤트에 대한 자세한 컨텍스트를 제공하여 훈련 작업이 실패하거나 제대로 수행되지 않는 이유를 이해하는 데 도움이 됩니다. 로그를 지표와 연결하면 근본 원인을 더 빠르게 파악할 수 있습니다.

다음 섹션에서는 CloudWatch Container Insights 및 Amazon Managed Prometheus와 Amazon Managed Grafana의 두 가지 AWS 권장 접근 방식을 사용하여 위에서 설명한 지표를 수집하는 방법을 보여줍니다. 최소한의 설정 및 사전 구축된 대시보드로 AWS 네이티브 도구를 선호하는 경우 CloudWatch Container Insights를 선택합니다. 사용자 지정 대시보드, 고급 시각화 기능이 필요하거나 기존 Prometheus 기반 모니터링 인프라와 통합하려는 경우 Amazon Managed Grafana에서 Amazon Managed Prometheus를 선택합니다. 사용 가능한 Container Insights 지표의 전체 목록은 Amazon EKS 및 Kubernetes Container Insights 지표를 참조하세요.

실시간 온라인 추론 지표 모니터링 고려

실시간 시스템에서는 사용자 또는 기타 종속 시스템에 적시에 응답을 제공하려면 짧은 지연 시간이 중요합니다. 지연 시간이 길면 사용자 경험이 저하되거나 성능 요구 사항을 위반할 수 있습니다. 추론 지연 시간에 영향을 미치는 구성 요소에는 모델 로드 시간, 사전 처리 시간, 실제 예측 시간, 사후 처리 시간, 네트워크 전송 시간이 포함됩니다. 추론 지연 시간을 모니터링하여 서비스 수준 계약(SLAs)을 충족하는 지연 시간이 짧은 응답을 보장하고 다음에 대한 사용자 지정 지표를 개발하는 것이 좋습니다. 예상 로드 상태에서 테스트하고, 네트워크 지연 시간을 포함하고, 동시 요청을 고려하고, 다양한 배치 크기로 테스트합니다.

K/V(Key/Value) 캐시는 추론 지연 시간, 특히 변환기 기반 모델과 관련된 강력한 최적화 기술일 수 있습니다. K/V 캐시는 이전 변환기 계층 계산의 키 및 값 텐서를 저장하여 자동 회귀 추론, 특히 대규모 언어 모델(LLMs)에서 중복 계산을 줄입니다. 캐시 효율성 지표(특히 K/V 또는 세션 캐시 사용):

이후 주제에서는 위에서 언급한 몇 가지 지표에 대한 데이터 수집을 보여줍니다. AWS 네이티브 CloudWatch Container Insights와 Amazon Managed Grafana를 사용하는 오픈 소스 Amazon Managed Prometheus라는 두 가지 AWS 권장 접근 방식이 포함된 예제를 제공합니다. https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html 전반적인 관찰성 요구 사항에 따라 이러한 솔루션 중 하나를 선택합니다. Container Insights 지표의 전체 목록은 Amazon EKS 및 Kubernetes Container Insights 지표를 참조하세요.

GPU 메모리 사용량 추적

코어 훈련 모니터링 및 지표 미세 조정 고려 주제에서 설명한 것처럼 out-of-memory(OOM) 오류를 방지하고 효율적인 리소스 사용률을 보장하려면 GPU 메모리 사용이 필수적입니다. 다음 예제에서는 사용자 지정 히스토그램 지표를 노출하도록 훈련 애플리케이션을 계측gpu_memory_usage_bytes하고 P95 메모리 사용량을 계산하여 최대 소비를 식별하는 방법을 보여줍니다. 스테이징 환경에서 샘플 훈련 작업(예: 변환기 모델 미세 조정)을 사용하여 테스트해야 합니다.

AWS-Native CloudWatch Container Insights 예제

이 샘플은 AWS 네이티브 접근 방식을 사용하여 훈련 애플리케이션을 히스토그램gpu_memory_usage_bytes으로 노출하도록 계측하는 방법을 보여줍니다. CloudWatch 임베디드 지표 형식(EMF) 형식으로 구조화된 로그를 내보내도록 AI/ML 컨테이너를 구성해야 합니다. CloudWatch 로그는 EMF를 구문 분석하고 지표를 게시합니다. 훈련 애플리케이션에서 aws_embedded_metrics를 사용하여 EMF 형식의 구조화된 로그를 CloudWatch Logs로 전송하여 GPU 지표를 추출합니다.

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를 통해)으로 테스트하고, SLA 위반을 감지하기 위해 알림 임계값(예: >500ms)을 설정합니다.

AWS-Native CloudWatch Container Insights 예제

이 샘플은 AWS CloudWatch 임베디드 지표 형식을 사용하여 추론 애플리케이션에서 추론_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 클라이언트 라이브러리를 사용하여 추론 애플리케이션에서 추론_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에서 쿼리를 사용하여 P95 지연 시간 추세histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod))를 시각화합니다. 자세한 내용은 Prometheus 히스토그램 설명서 및 Prometheus 클라이언트 설명서를 참조하세요.

실시간 온라인 추론을 위한 토큰 처리량 추적

코어 훈련 모니터링 및 지표 미세 조정 고려 주제에서 설명한 대로 토큰 처리 시간을 모니터링하여 모델 성능을 측정하고 조정 결정을 최적화하는 것이 좋습니다. 다음 예제에서는 추론 애플리케이션에서 노출되는 사용자 지정 히스토그램 지표 token_processing_duration_seconds를 추적하는 방법을 보여줍니다. 95번째 백분위수(P95) 지속 시간을 계산하여 처리 효율성을 분석하고, 비프로덕션 클러스터에서 시뮬레이션된 요청 로드(예: 초당 100~1,000개의 요청)로 테스트하고, 조정을 최적화하도록 KEDA 트리거를 조정합니다.

AWS-Native CloudWatch Container Insights 예제

이 샘플은 AWS CloudWatch 임베디드 지표 형식을 사용하여 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에서 쿼리를 사용하여 P95 처리 시간 추세histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))`를 시각화합니다. 자세한 내용은 Prometheus 히스토그램 설명서 및 Prometheus 클라이언트 설명서를 참조하세요.

체크포인트 복원 지연 시간 측정

코어 훈련 모니터링 및 지표 미세 조정 고려 주제에서 설명한 것처럼 체크포인트 지연 시간은 모델 수명 주기의 여러 단계에서 중요한 지표입니다. 다음 예제에서는 애플리케이션에서 checkpoint_restore_duration_seconds`노출되는 사용자 지정 히스토그램 지표를 추적하는 방법을 보여줍니다. 95번째 백분위수(P95) 지속 시간을 계산하여 복원 성능을 모니터링하고, 비프로덕션 클러스터에서 스팟 중단을 테스트하고, 알림 임계값(예: <30초)을 설정하여 지연을 감지합니다.

AWS-Native 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에서 쿼리를 사용하여 P95 복원 지연 시간 추세histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le))를 시각화합니다. 자세한 내용은 Prometheus 히스토그램 설명서 및 Prometheus 클라이언트 설명서를 참조하세요.