관찰성

모니터링 및 관찰성

높은 GPU 사용률 목표

사용률이 낮은 GPUs 할당된 GPU 리소스가 워크로드에서 완전히 활용되지 않아 컴퓨팅 용량이 낭비되고 있음을 나타냅니다. Amazon EKS의 AI/ML 워크로드의 경우 높은 GPU 사용량을 대상으로 하고 리소스 효율성을 최적화하기 위해 GPU 사용률을 모니터링하는 것이 좋습니다. 사용률이 낮은 GPUs 컴퓨팅 용량을 낭비하고 비용을 늘리는 반면, 과도하게 예약하면 경합과 성능 저하가 발생할 수 있습니다.

GPU 사용률 지표가 낮은 특정 포드, 노드 또는 워크로드를 식별하려면 Amazon EKS에서 Cloudwatch Container Insights를 설정하는 것이 좋습니다. Amazon EKS와 쉽게 통합되어 GPU 사용률을 모니터링하고 사용률이 목표 수준 아래로 떨어질 경우 포드 스케줄링 또는 인스턴스 유형을 조정할 수 있습니다. 또는 특정 요구 사항(예: 고급 시각화)을 충족하지 않는 경우 Kubernetes 네이티브 모니터링을 위해 Prometheus 및 Grafana와 함께 NVIDIA의 DCGM-Exporter를 사용하는 것이 좋습니다. 두 접근 방식 모두 GPU 지표에 대한 인사이트를 제공하므로 사용률이 목표 수준 아래로 떨어질 경우 포드 예약 또는 인스턴스 유형을 조정할 수 있습니다. DCGM-Exporter 또는 CloudWatch를 통해 nvidia_smi_utilization_gpu (GPU 컴퓨팅 사용량) 및 nvidia_smi_utilization_memory (GPU 메모리 사용량)과 같은 NVIDIA 지표를 확인합니다. 특정 시간 동안 또는 특정 작업에 대해 지속적으로 낮은 사용률과 같은 추세를 찾습니다.

Kubernetes의 정적 리소스 제한(예: CPU, 메모리 및 GPU 수)은 특히 추론과 같은 동적 AI/ML 워크로드의 경우 과다 프로비저닝 또는 사용 부족으로 이어질 수 있습니다. 사용률 추세를 분석하고 워크로드를 더 적은 GPUs로 통합하여 새 GPU를 할당하기 전에 각 GPU가 완전히 활용되도록 하는 것이 좋습니다. GPUs 사용률이 낮은 경우 예약 및 공유를 최적화하기 위해 다음 전략을 고려하세요. 자세한 내용은 EKS 컴퓨팅 및 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 및 사용자 지정 지표에 대한 애플리케이션 수준 인사이트와 같은 프레임워크를 사용하여 분산 워크로드 인사이트에 대한 추론 제공을 모니터링하고 최적화하는 총체적 접근 방식입니다.

도구 및 프레임워크

특정 도구 및 프레임워크는 AI/ML 워크로드를 모니터링하기 위한 기본 지표out-of-the-box 제공하므로 추가 사용자 지정 설정 없이 더 쉽게 통합할 수 있습니다. 이는 추론 서비스 및 벤치마킹에 중요한 지연 시간, 처리량 및 토큰 생성과 같은 성능 측면에 중점을 둡니다. 그러한 예는 다음과 같습니다.

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 대시보드에서 사용할 수 있도록 합니다. 또한 통합 CloudWatch 에이전트를 사용하여 Ray 및 vLLM을 CloudWatch와 통합하여 지표를 전송할 수 있습니다. CloudWatch 이렇게 하면 EKS 환경에서의 관찰성이 간소화되어 팀이 성능 튜닝 및 비용 최적화에 집중할 수 있습니다.

자세한 내용은 Amazon EKS 및 Kubernetes Container Insights 지표를 참조하세요. Amazon CloudWatch Container Insights 및 AI 응답성 최적화를 사용하여 NVIDIA GPU 워크로드에 대한 운영 인사이트 얻 기: 자세한 구현을 위한 Amazon Bedrock 지연 시간 최적화 추론에 대한 실용적인 가이드를 참조하세요.

Managed Prometheus 및 Grafana 조직이 오픈 소스 도구와 사용자 지정 대시보드에 익숙하다면 고급 시각화를 통한 Kubernetes용 NVIDIA DCGM-Exporter 및 Grafana 네이티브 모니터링을 사용하여 Prometheus를 배포하는 것이 좋습니다. 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 오류를 방지하고 비용을 절감할 수 있습니다.
노드 및 포드 리소스 사용률 - 노드 및 포드 수준에서 리소스 사용량을 추적하면 리소스 경합과 잠재적 병목 현상을 식별하는 데 도움이 됩니다. 예를 들어 노드가 과도하게 사용되어 포드 예약에 영향을 미칠 수 있는지 확인합니다.
리소스 사용률과 요청 및 한도 비교 - 이를 통해 클러스터가 현재 워크로드를 처리하고 향후 워크로드를 수용할 수 있는지 여부를 파악할 수 있습니다. 예를 들어 실제 메모리 사용량을 한도와 비교하여 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 메모리로 다시 로드하는 데 걸리는 시간을 모니터링합니다. 이 지표는 작업 복구 시간, 콜드 스타트 성능 및 간섭 파이프라인의 전반적인 효율성에 직접적인 영향을 미칩니다. Auto Scaling 추론 서비스에서 체크포인트 로드 속도가 느리면 콜드 스타트 지연이 발생하고 사용자 경험이 저하될 수 있습니다. 또한 이러한 관련 지표는 일반적으로 체크포인트 가동 중지 시간, 모델 역직렬화 시간, 체크포인트 크기 및 체크포인트 복원 실패 수와 같은 모델 체크포인트를 개선하는 데 사용됩니다.
추론 요청 기간 - 추론 요청을 완료하는 데 걸리는 시간을 모니터링합니다. 이는 최초 요청 수신부터 모델로부터 완료된 응답까지의 시간입니다.
토큰 처리량 - 토큰 처리 시간을 모니터링하여 모델 성능을 측정하고 조정 결정을 최적화합니다. 처리 속도가 느리면 비효율적이거나 리소스 활용도가 낮아 비용 효율성에 영향을 미칠 수 있습니다. 처리 시간과 함께 초당의 토큰 및 초당 토큰 아웃과 같은 지표를 추적하면 성능 병목 현상, 속도 저하 및 비용 동인을 식별하는 데 도움이 될 수 있습니다.
성능 병목 현상 식별 - 이러한 지표를 사용하여 훈련 프로세스에서 최적화할 영역을 정확히 찾아냅니다. 예를 들어, 데이터 로드와 모델 계산에 소요된 시간을 분석합니다.

오류 발생률 및 실패:

ML 파이프라인 전반의 오류 모니터링 - 여기에는 데이터 사전 처리, 모델 훈련 및 추론이 포함됩니다. 예를 들어 사전 처리 오류를 기록하여 문제를 빠르게 식별합니다.
반복되는 오류 식별 및 조사 - 이를 통해 고품질 모델을 유지하고 일관된 성능을 보장할 수 있습니다. 예를 들어 로그를 분석하여 실패를 일으키는 특정 데이터와 같은 패턴을 찾습니다.

Kubernetes 및 EKS 특정 지표:

Kubernetes 클러스터 상태 지표 - 포드, 노드 및 컨트롤 플레인을 포함한 다양한 Kubernetes 객체의 상태와 상태를 모니터링합니다. 예를 들어와 같은 도구를 사용하여 포드 상태를 kubectl 확인합니다.
성공/실패한 파이프라인 실행 - 성공/실패한 파이프라인 실행, 작업 기간, 단계 완료 시간 및 오케스트레이션 오류(예: Kubeflow/Mlflow/Argo 이벤트 사용)를 추적합니다.
AWS 서비스 지표 - EKS 인프라와 해당 인프라에서 실행되는 애플리케이션을 지원하는 다른 AWS 서비스에 대한 지표를 추적합니다. 예를 들어 Amazon S3를 사용하는 경우 버킷 크기를 모니터링하여 스토리지 사용량을 추적합니다.
Kubernetes 컨트롤 플레인 지표 - API 서버, 스케줄러, 컨트롤러 관리자 및 기타 데이터베이스에서 성능 문제 또는 장애를 모니터링합니다. 예를 들어 응답성을 위해 API 서버 요청 지연 시간을 추적합니다.

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

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

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

첫 번째 토큰까지의 시간(TTFT) - 사용자가 요청을 제출한 시점부터 응답의 시작(첫 번째 단어, 토큰 또는 청크)을 수신할 때까지의 시간입니다. 예를 들어 챗봇에서는 사용자가 질문을 한 후 첫 번째 출력(토큰)을 생성하는 데 걸리는 시간을 확인합니다.
End-to-End 지연 시간 - 요청이 수신된 시점부터 응답이 다시 전송된 시점까지의 총 시간입니다. 예를 들어 요청에서 응답까지의 시간을 측정합니다.
초당 출력 토큰(TPS) - 모델이 응답을 시작한 후 새 토큰을 생성하는 속도를 나타냅니다. 예를 들어 챗봇에서는 기준 텍스트에 대한 언어 모델의 생성 속도를 추적합니다.
오류율 - 성능 문제를 나타낼 수 있는 실패한 요청을 추적합니다. 예를 들어 대용량 문서 또는 특정 문자에 대한 실패한 요청을 모니터링합니다.
처리량 - 시스템이 시간 단위당 처리할 수 있는 요청 또는 작업 수를 측정합니다. 예를 들어 최대 부하를 처리하기 위해 초당 요청을 추적합니다.

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

캐시 적중률/누락률 - 캐싱(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 형식의 구조화된 로그를 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를 통해)으로 테스트하고, SLA 위반을 감지하기 위해 알림 임계값(예: >500ms)을 설정합니다.

AWS-Native CloudWatch Container Insights 예제

이 샘플은 AWS CloudWatch 임베디드 지표 형식을 사용하여 추론 애플리케이션에서 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 클라이언트 라이브러리를 사용하여 추론 애플리케이션에서 추론_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~1000개의 요청)로 테스트하고, 조정을 최적화하도록 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 클라이언트 설명서를 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

스토리지

성능