애플리케이션 조정 및 성능 - Amazon EKS
ML 아티팩트, 서비스 프레임워크 및 시작 최적화 관리컨테이너 이미지 사전 캐싱kubelet 및 컨테이너형 스토리지에 NVMe 사용

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

애플리케이션 조정 및 성능

ML 아티팩트, 서비스 프레임워크 및 시작 최적화 관리

Amazon EKS에 기계 학습(ML) 모델을 배포하려면 모델을 컨테이너 이미지 및 런타임 환경에 통합하는 방법을 신중하게 고려해야 합니다. 이렇게 하면 확장성, 재현성 및 효율적인 리소스 사용률이 보장됩니다. 이 주제에서는 ML 모델 아티팩트를 처리하고, 프레임워크 제공을 선택하고, 사전 캐싱과 같은 기술을 통해 컨테이너 시작 시간을 최적화하는 다양한 접근 방식을 설명합니다.이 모든 방법은 컨테이너 시작 시간을 줄이도록 조정되었습니다.

컨테이너 이미지 크기 줄이기

시작 시 컨테이너 이미지 크기를 줄이는 것은 이미지를 더 작게 만드는 또 다른 방법입니다. 컨테이너 이미지 빌드 프로세스의 모든 단계에서 줄일 수 있습니다. 시작하려면 필요한 종속성 수가 가장 적은 기본 이미지를 선택합니다. 이미지 빌드 중에는 필요한 필수 라이브러리와 아티팩트만 포함합니다. 이미지를 빌드할 때 여러 RUN 또는 COPY 명령을 결합하여 더 많은 수의 더 큰 계층을 생성해 보세요. AI/ML 프레임워크의 경우 다단계 빌드를 사용하여 빌드와 런타임을 분리하고, 필요한 아티팩트만 복사하고(예: 레지스트리 또는 로컬 컨텍스트COPY —from=의 경우를 통해), 런타임 전용 이미지와 같은 변형을 선택합니다(예: 3.03GBpytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime에서 대 6.66GB에서 개발). 자세한 내용은 AI on EKS 워크숍의 컨테이너 이미지 크기 줄이기를 참조하세요.

배포에서 ML 모델 아티팩트 처리

핵심 결정은 ML 모델 아티팩트(예: 가중치 및 구성)를 직접 처리하는 방법입니다. 선택 사항은 이미지 크기, 배포 속도, 모델 업데이트 빈도 및 운영 오버헤드에 영향을 미칩니다. "모델" 저장을 참조할 때는 모델 아티팩트(예: 훈련된 파라미터 및 모델 가중치)를 참조합니다. Amazon EKS에서 ML 모델 아티팩트를 처리하는 방법에는 여러 가지가 있습니다. 각 에는 장단점이 있으며, 최상의 장단점은 모델의 크기, 업데이트 주기 및 인프라 요구 사항에 따라 달라집니다. 가장 적게 권장되는 것부터 가장 권장되는 것까지 다음과 같은 접근 방식을 고려하세요.

  • 모델을 컨테이너 이미지로 베이킹: 이미지 빌드 중에 모델 파일(예: .safetensors, .pth, .h5)을 컨테이너 이미지(예: Dockerfile)에 복사합니다. 모델은 변경 불가능한 이미지의 일부입니다. 업데이트 빈도가 낮은 소형 모델의 경우이 접근 방식을 사용하는 것이 좋습니다. 이렇게 하면 일관성과 재현성이 보장되고, 로드 지연이 없으며, 종속성 관리를 간소화할 수 있지만 이미지 크기가 커져 빌드 및 푸시 속도가 느려지고, 모델 업데이트를 위해 재구축 및 재배포가 필요하며, 레지스트리 풀 처리량으로 인해 대규모 모델에 적합하지 않습니다.

  • 런타임 시 모델 다운로드: 컨테이너 시작 시 애플리케이션은 init 컨테이너 또는 진입점의 스크립트를 통해 외부 스토리지(예: Mountpoint for S3 CSI 드라이버, Amazon S3 S3)에서 모델을 다운로드합니다. S3 업데이트가 빈번한 대규모 모델의 경우이 접근 방식부터 시작하는 것이 좋습니다. 이렇게 하면 컨테이너 이미지가 코드/런타임에 초점을 맞추고, 재구축 없이 모델을 쉽게 업데이트할 수 있으며, 스토리지 메타데이터를 통한 버전 관리를 지원하지만, 인증 및 캐싱이 필요한 잠재적 네트워크 장애(재시도 로직 필요)가 발생합니다.

자세한 내용은 AI on EKS 워크숍의 풀 프로세스 가속화를 참조하세요.

ML 모델 제공

Amazon EKS에서 기계 학습(ML) 모델을 배포하고 제공하려면 지연 시간, 처리량, 확장성 및 운영 간소화를 최적화하는 적절한 모델 제공 접근 방식을 선택해야 합니다. 선택은 모델 유형(예: 언어, 비전 모델), 워크로드 요구 사항(예: 실시간 추론) 및 팀 전문 지식에 따라 달라집니다. 일반적인 접근 방식에는 프로토타이핑을 위한 Python 기반 설정, 프로덕션급 기능을 위한 전용 모델 서버, 고성능 및 효율성을 위한 특수 추론 엔진이 포함됩니다. 각 방법에는 설정 복잡성, 성능 및 리소스 사용률의 장단점이 포함됩니다. 제공 프레임워크는 종속성으로 인해 컨테이너 이미지 크기(여러 GBs 늘릴 수 있으며, 이는 시작 시간에 영향을 미칠 수 있습니다. 이를 완화하기 위해 아티팩트 처리 기술을 사용한 분리를 고려하세요. 옵션은 최소 권장부터 가장 권장까지 나열됩니다.

Python 프레임워크 사용(예: FastAPI, PyTorch를 사용하는 HuggingFace 변환기) 컨테이너화된 노드 설정 내에 모델 파일(가중치, 구성, 토큰화기)을 포함하는 Python 프레임워크를 사용하여 사용자 지정 애플리케이션을 개발합니다.

  • 장점: 간편한 프로토타이핑, 추가 인프라 없이 Python 전용, 모든 HuggingFace 모델과 호환, 간단한 Kubernetes 배포.

  • 단점: 단일 요청/단순 일괄 처리, 느린 토큰 생성(최적화된 커널 없음), 메모리 비효율성, 규모 조정/모니터링 부족, 긴 시작 시간으로 제한합니다.

  • 권장 사항: 사용자 지정 로직 통합이 필요한 초기 프로토타이핑 또는 단일 노드 작업에 사용합니다.

전용 모델 서비스 프레임워크(예: TensorRT-LLM, TGI) 사용 ML 추론을 위해 TensorRT-LLM 또는 TGI와 같은 특수 서버를 채택하고 모델 로드, 라우팅 및 최적화를 관리합니다. 이러한는 선택 사항인 컴파일 또는 플러그인을 사용하여 Safetensor와 같은 형식을 지원합니다.

  • 장점: 일괄 처리(정적/진행 중 또는 연속), 양자화(INT8, FP8, GPTQ), 하드웨어 최적화(NVIDIA, AMD, Intel, Inferentia) 및 다중 GPU 지원(Tensor/Pipeline Parallelism)을 제공합니다. TensorRT-LLM은 다양한 모델(LLMs, Encoder-Decoder)을 지원하는 반면, TGI는 HuggingFace 통합을 활용합니다.

  • 단점: TensorRT-LLM은 컴파일이 필요하며 NVIDIA 전용입니다. TGI는 일괄 처리에서 덜 효율적일 수 있습니다. 둘 다 구성 오버헤드를 추가하고 일부 모델 유형(예: 비변환기)에 맞지 않을 수 있습니다.

  • 권장 사항: A/B 테스트 또는 호환 하드웨어를 사용한 높은 처리량과 같은 프로덕션 기능이 필요한 PyTorch/TensorFlow 모델에 적합합니다.

특수한 고처리량 추론 엔진(예: vLLM) 사용 vLLM과 같은 고급 추론 엔진을 활용하여 PagedAttention을 사용한 LLM 서비스, 진행 중인 배치 및 양자화(INT8, FP8-KV, AWQ)를 최적화하고 EKS Auto Scaling과 통합 가능합니다.

  • 장점: 높은 처리량 및 메모리 효율성(40~60% VRAM 절감), 동적 요청 처리, 토큰 스트리밍, 단일 노드 Tensor 병렬 다중 GPU 지원, 광범위한 하드웨어 호환성.

  • 단점: 디코더 전용 변환기(예: LLaMA)에 최적화되어 있고 비변환기 모델에 덜 효과적이므로 호환되는 하드웨어(예: NVIDIA GPUs)와 설정 작업이 필요합니다.

  • 권장 사항: EKS에서 지연 시간이 짧은 대용량 LLM 추론을 위한 최고의 선택으로 확장성과 성능을 극대화합니다.

컨테이너 이미지 사전 캐싱

대용량 컨테이너 이미지(예: PyTorch와 같은 모델이 포함된 이미지)는 콜드 스타트 지연을 일으켜 지연 시간에 영향을 미칠 수 있습니다. 가로로 확장되는 실시간 추론 워크로드와 같이 지연 시간에 민감한 워크로드의 경우 빠른 포드 시작이 중요하므로 초기화 지연을 최소화하기 위해 컨테이너 이미지를 미리 로드하는 것이 좋습니다. 가장 적게 권장되는 것부터 가장 권장되는 것까지 다음과 같은 접근 방식을 고려하세요.

SOCI 스냅샷 생성기를 사용하여 이미지 미리 가져오기

쉽게 최소화할 수 없는 매우 큰 이미지의 경우 병렬 풀 및 언패킹 모드로 구성된 오픈 소스 SOCI(Seekable OCI) 스냅샷 생성기를 사용할 수 있습니다. 이 솔루션을 사용하면 빌드 파이프라인을 재구축하거나 수정하지 않고도 기존 이미지를 사용할 수 있습니다. 이 옵션은 매우 큰 이미지가 있는 워크로드를 고성능 EC2 컴퓨팅 인스턴스에 배포할 때 특히 효과적입니다. 대규모 AI/ML 워크로드와 마찬가지로 처리량이 많은 네트워킹 및 고성능 스토리지 구성에서도 잘 작동합니다.

SOCI 병렬 풀/언팩 모드는 구성 가능한 병렬화 전략을 통해 end-to-end 이미지 풀 성능을 개선합니다. 이미지 가져오기 및 준비 속도가 빨라지면 새 워크로드를 배포하고 클러스터를 효율적으로 확장할 수 있는 속도에 직접적인 영향을 미칩니다. 이미지 풀에는 두 가지 주요 단계가 있습니다.

1: 레지스트리에서 노드로 계층 가져오기

계층 가져오기 최적화를 위해 SOCI는 계층당 여러 동시 HTTP 연결을 생성하여 단일 연결 제한을 초과하는 다운로드 처리량을 곱합니다. 큰 계층을 청크로 분할하고 여러 연결에서 동시에 다운로드합니다. 이 접근 방식은 사용 가능한 네트워크 대역폭을 포화시키고 다운로드 시간을 크게 줄이는 데 도움이 됩니다. 이는 단일 계층이 몇 기가바이트일 수 있는 AI/ML 워크로드에 특히 유용합니다.

2. 컨테이너를 생성하기 위해 해당 계층의 압축을 풀고 준비

계층 언패킹 최적화를 위해 SOCI는 여러 계층을 동시에 처리합니다. 다음 단계를 시작하기 전에 각 계층의 압축이 완전히 풀릴 때까지 기다리는 대신 사용 가능한 CPU 코어를 사용하여 여러 계층의 압축을 풀고 동시에 추출합니다. 이 병렬 처리는 기존의 I/O 바운드 언패킹 단계를 사용 가능한 코어에 따라 확장되는 CPU 최적화 작업으로 변환합니다. 시스템은이 병렬화를 신중하게 오케스트레이션하여 파일 시스템 일관성을 유지하면서 처리량을 극대화합니다.

SOCI 병렬 풀 모드는 동시성 다운로드와 병렬성 압축 해제 모두에 대해 구성 가능한 파라미터가 있는 이중 임계값 제어 시스템을 사용합니다. 이 세분화된 제어를 사용하면 특정 성능 요구 사항 및 환경 조건을 충족하도록 SOCI의 동작을 미세 조정할 수 있습니다. 이러한 파라미터를 이해하면 최상의 풀 성능을 위해 런타임을 최적화하는 데 도움이 됩니다.

참조

EBS 스냅샷을 사용하여 이미지 미리 가져오기

캐시된 컨테이너 이미지의 Amazon Elastic Block Store(EBS) 스냅샷을 만들고이 스냅샷을 EKS 작업자 노드에 재사용할 수 있습니다. 이렇게 하면 노드 시작 시 로컬에서 이미지를 미리 가져와 포드 초기화 시간을 줄일 수 있습니다. 관리형 노드 그룹용 Karpenter 및 EKS Terraform 블루프린트를 사용한 자세한 내용은 Bottlerocket 데이터 볼륨을 사용하여 Amazon EKS에서 컨테이너 시작 시간 단축을 참조하세요. https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/machine-learning/ml-container-cache/

자세한 내용은 AI on EKS 워크숍의 컨테이너 스냅샷 생성기 사용 및 EBS 스냅샷을 사용하여 Bottlerocket 데이터 볼륨에 컨테이너 이미지 사전 로드를 참조하세요. https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process/prefecthing-images-on-br

컨테이너 런타임 캐시를 사용하여 이미지 미리 가져오기

Kubernetes 리소스(예: DaemonSet 또는 배포)를 사용하여 노드에 컨테이너 이미지를 미리 가져와 노드의 컨테이너 런타임 캐시를 채울 수 있습니다. 컨테이너 런타임 캐시는 컨테이너 런타임에서 관리하는 로컬 스토리지입니다(예: 레지스트리에서 가져온 후 이미지가 저장되는 컨테이너형 스토리지입니다. 사전 풀링을 통해 로컬에서 이미지를 사용할 수 있으므로 포드 시작 중에 다운로드 지연이 발생하지 않습니다. 이 접근 방식은 이미지가 자주 변경되거나(예: 자주 업데이트), EBS 스냅샷이 미리 구성되지 않거나, EBS 볼륨을 빌드하는 데 컨테이너 레지스트리에서 직접 가져오는 것보다 시간이 더 많이 걸리거나, 노드가 이미 클러스터에 있고 여러 가능한 이미지 중 하나를 사용하여 온디맨드로 포드를 가동해야 하는 경우에 특히 유용합니다.

모든 변형을 미리 풀링하면 필요한 이미지에 관계없이 빠르게 시작할 수 있습니다. 예를 들어 10가지 기술을 사용하여 구축된 100,000개의 소형 모델이 필요한 대량 병렬 ML 워크로드에서 대규모 클러스터(예: 수천 개의 노드)에서 DaemonSet를 통해 10개의 이미지를 미리 풀링하면 포드 시작 시간이 최소화되어 온디맨드 풀을 방지하여 10초 이내에 완료할 수 있습니다. 컨테이너 런타임 캐시 접근 방식을 사용하면 EBS 스냅샷을 관리할 필요가 없으며, 항상 DaemonSets를 사용하여 최신 컨테이너 이미지 버전을 얻을 수 있지만 노드가 스케일 인/아웃되는 실시간 추론 워크로드의 경우 Cluster Autoscaler와 같은 도구가 추가한 새 노드는 미리 풀링된 DaemonSet가 이미지 풀링을 완료하기 전에 워크로드 포드를 예약할 수 있습니다. 이로 인해 새 노드의 초기 포드가 풀을 트리거하여 시작이 지연되고 지연 시간이 짧은 요구 사항에 영향을 미칠 수 있습니다. 또한 kubelet 이미지 가비지 수집은 디스크 사용량이 특정 임계값을 초과하거나 구성된 최대 미사용 기간을 초과하는 경우 미사용 이미지를 제거하여 미리 풀링된 이미지에 영향을 미칠 수 있습니다. 스케일 인/아웃 패턴에서는 유휴 노드에서 이미지를 제거할 수 있으므로 후속 스케일 업 중에 다시 풀링하고 버스트 워크로드에 대한 캐시의 신뢰성을 줄여야 합니다.

컨테이너 런타임 캐시로 이미지를 미리 풀링하는 예제는 AWS GitHub 리포지토리를 참조하세요.

kubelet 및 컨테이너형 스토리지에 NVMe 사용

디스크 성능을 높이기 containerd 위해 임시 NVMe 인스턴스 스토리지 디스크를 사용하도록 kubelet 및를 구성하는 것이 좋습니다. 컨테이너 풀 프로세스에는 레지스트리에서 컨테이너 이미지를 다운로드하고 해당 계층을 사용 가능한 형식으로 압축 해제하는 작업이 포함됩니다. 압축 해제 중에 I/O 작업을 최적화하려면 컨테이너 호스트의 인스턴스 유형에 더 높은 수준의 I/O 성능과 처리량, 즉 로컬 스토리지가 있는 NVMe 지원 인스턴스와 EBS 볼륨 IOPS/처리량을 제공하는 항목을 평가해야 합니다. NVMe 로컬 스토리지가 있는 EC2 인스턴스의 경우 더 높은 수준의 I/O 성능과 처리량을 위해 임시 NVMe 인스턴스 스토리지 디스크를 사용하도록 노드의 기본 파일 시스템을 kubelet(/var/lib/kubelet), containerd(/var/lib/containerd) 및 Pod 로그(/var/log/pods)로 구성하는 것이 좋습니다.

노드에 다운로드되는 임시 스토리지 및 컨테이너 이미지를 요청하는 포드 간에 노드의 임시 스토리지를 공유할 수 있습니다. Bottlerocket 또는 AL2023 EKS 최적화 AMIs와 함께 Karpenter를 사용하는 경우 instanceStorePolicy를 RAID0으로 설정하거나 관리형 노드 그룹을 사용하는 경우 NodeConfig의 localStoragePolicy를 사용자 데이터의 일부로 설정하여 EC2NodeClass에서 구성할 수 있습니다. NodeConfig