View a markdown version of this page

Amazon EKS를 사용하여 GPU에서 AI 모델 추론 오토 스케일링 - Amazon EKS
Karpenter를 사용한 GPU 노드 프로비저닝GPU 및 CPU 오토 스케일링규모 조정 지표 선택이 모든 것을 실제로 적용

이 페이지 개선에 도움 주기

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.

Amazon EKS를 사용하여 GPU에서 AI 모델 추론 오토 스케일링

작은 정보

향후 예정된 Amazon EKS AI/ML 워크숍에 등록합니다.

이 섹션에서는 Amazon EKS를 사용하여 GPU에서 AI 추론 워크로드를 오토 스케일링하기 위한 개념 및 절차를 다룹니다.

이전 모델 로드 및 제공 섹션에서 배포한 단일 vLLM 모델 복제본은 새 요청이 대기를 시작하기 전에 제한된 수의 동시 요청을 처리할 수 있으므로 지연 시간이 증가하고 요청 시간 초과가 발생할 수 있습니다. 트래픽에 보조를 맞추기 위해 배포를 수평으로 오토 스케일링할 수 있습니다. 오토 스케일링은 수요가 증가하면 워크로드 복제본을 추가하고 수요가 감소하면 제거합니다. 따라서 GPU 용량 과잉 프로비저닝을 방지할 수 있습니다.

추론 오토 스케일링은 두 단계로 이루어집니다.

  • 노드 규모 조정 - Kubernetes 스케줄러에서 기존 노드에 새 포드를 배치할 여유가 없는 경우 포드는 Pending 상태를 유지합니다. Karpenter는 Pending 포드에 맞게 GPU 노드를 프로비저닝하여 응답하고, 워크로드 복제본이 다시 스케일 다운될 때 노드를 제거합니다.

  • 포드 규모 조정 - Horizontal Pod Autoscaler(HPA)가 구성된 지표를 감시합니다. 해당 지표가 구성된 임곗값을 초과하면 HPA는 워크로드 복제본 수를 늘리고 새 vLLM 포드가 생성됩니다.

노드 규모 조정 단계는 워크로드 복제본을 실행하는 데 필요한 GPU 용량을 제공합니다. 포드 규모 조정 단계는 선택한 지표를 해당 목표에 가깝게 유지하기 위해 워크로드 복제본 수를 조정합니다.

Karpenter를 사용한 GPU 노드 프로비저닝

Karpenter는 노드 수명 주기를 관리하여 워크로드에 필요할 때 노드를 프로비저닝하고 필요하지 않을 때 노드를 통합하거나 제거합니다. Karpenter는 Kubernetes 스케줄러를 대체한다기보다는 함께 작동합니다. 스케줄러는 포드를 노드에 배치합니다. Karpenter는 스케줄러가 맞출 수 없는 포드의 용량을 프로비저닝한 다음 노드가 Ready 상태가 되면 스케줄러가 포드를 바인딩하도록 허용합니다.

Karpenter는 GPU 노드를 CPU 노드 플릿과는 다르게 처리합니다.

GPU는 전체 단위로 요청됩니다.

시간 분할 또는 MIG와 같은 GPU 공유 기술을 사용하지 않는 한, 포드는 CPU 또는 메모리처럼 일부만 할당받는 것이 아니라 하나 이상의 전체 GPU를 얻습니다. 각 GPU에는 전용 메모리가 있으므로 동일한 노드의 복제본이 GPU 메모리를 공유하지 않습니다. GPU가 노드에 매핑되는 방법은 인스턴스 유형에 따라 다릅니다.

  • 단일 GPU 인스턴스(예: g6.xlarge) - 노드에 정확히 하나의 복제본이 들어 있습니다. 복제본, GPU, 노드는 일대일로 규모가 조정되며 각 복제본은 자체 인스턴스에서 격리됩니다.

  • 다중 GPU 인스턴스(예: GPU 4개가 있는 g6.12xlarge) - 디바이스 플러그인은 전체 GPU 수를 광고하므로 Karpenter는 GPU당 하나씩 여러 복제본을 노드 하나로 패킹할 수 있습니다.

  • 다중 GPU 포드 - 포드는 둘 이상의 GPU를 요청할 수 있습니다. 예를 들어, 대규모 모델을 2개의 GPU에 샤딩하도록 nvidia.com/gpu: 2를 설정하면 Karpenter는 해당 수만큼의 여유 GPU가 있는 노드에 포드를 배치합니다.

Karpenter는 GPU 가용성 및 비용을 최적화합니다.

Karpenter는 부족한 GPU 용량 확보와 비용 효율적인 운영 사이의 균형을 맞춥니다.

  • 인스턴스 선택 - 유연한 NodePool이 설정된 경우 Karpenter는 Pending 포드에 맞는 가장 저렴한 인스턴스 유형을 선택합니다. 시작 시 용량 부족 문제가 발생하면 다른 인스턴스 유형 및 가용 영역을 자동으로 재시도하여 GPU 용량 확보 가능성을 높입니다.

  • 통합 - 수요가 감소하고 복제본이 스케일 인되면 Karpenter는 해제된 노드를 회수합니다. WhenEmptyOrUnderutilized는 빈 노드를 제거하고 더 적은 노드로 복제본을 다시 패킹하는 반면, WhenEmpty는 예약된 항목이 없는 경우에만 노드를 회수합니다.

  • 진행 중인 포드 보호 - 통합 중에 포드가 중단되지 않도록 하려면 karpenter.sh/do-not-disrupt 주석을 추가하거나, PodDisruptionBudget을 설정하거나, consolidateAfter 설정을 사용하여 통합을 지연시킵니다.

Karpenter가 GPU 용량을 확보하면 포드 규모 조정 단계가 인계됩니다. HPA는 구성한 지표를 기반으로 복제본을 추가 또는 제거합니다. 이 섹션의 나머지 부분에서는 추론 워크로드에 대해 해당 규모 조정 지표를 선택하는 방법을 다룹니다.

GPU 및 CPU 오토 스케일링

Kubernetes에서 기존 CPU 기반 워크로드는 별도의 설정 없이 오토 스케일링되지만 GPU 기반 추론은 그렇지 않습니다. 세 가지 주요 차이점이 있습니다.

오토 스케일링 지표 가용성

Kubernetes는 HPA에 CPU 및 메모리 지표를 기본으로 제공합니다.

각 노드의 kubelet은 CPU 및 메모리 사용량을 Kubernetes 지표 API에 보고하므로 HPA는 추가 구성 요소 없이 이러한 값을 직접 읽고 워크로드를 규모 조정할 수 있습니다.

가속 워크로드에는 추가 지표 설정, 내보내기 및 어댑터가 필요합니다.

kubelet은 GPU 또는 추론 지표를 보고하지 않습니다. GPU 기반 추론을 규모 조정하려면 DCGM Exporter의 vLLM 애플리케이션 지표 및 GPU 지표와 같은 관련 신호를 게시하는 익스포터와 이러한 지표를 HPA에 노출하는 어댑터를 추가해야 합니다.

리소스 할당 및 공유

기존 워크로드는 CPU와 메모리를 소수 단위로 공유합니다.

Linux cgroup은 CPU 및 메모리를 소수 단위의 리소스로 분할하므로 여러 포드가 동일한 노드를 공유할 수 있습니다. 포드는 100밀리코어의 CPU 또는 512MiB의 메모리와 같이 노드 용량의 일부를 요청할 수 있습니다.

가속 워크로드는 GPU 할당 프레임워크를 통해 GPU를 할당 및 공유합니다.

GPU는 CPU 및 메모리와 달리 cgroup을 통해 공유되지 않습니다. 오늘날 가장 일반적인 Kubernetes 설정은 포드에 전체 GPU를 할당하는 NVIDIA 디바이스 플러그인을 사용합니다(예: nvidia.com/gpu: 1). 동적 리소스 할당(DRA)은 리소스 클레임을 통해 GPU를 할당하는 최신 Kubernetes API로, 보다 유연한 예약 및 리소스 관리를 제공합니다. 디바이스 플러그인과 DRA 모두 GPU 공유 기술을 지원할 수 있습니다. 시간 분할을 사용하면 시간이 지남에 따라 액세스를 인터리브하여 여러 포드가 GPU를 공유할 수 있는 반면, 다중 인스턴스 GPU(MIG)는 NVIDIA A100 및 H100과 같은 지원되는 GPU를 하드웨어 격리 GPU 인스턴스로 분할합니다.

규모 조정 신호

기존 워크로드는 일반적으로 CPU 및 메모리 사용률에 따라 규모 조정됩니다.

사용률은 CPU 및 메모리 워크로드에 대한 표준 오토 스케일링 신호입니다. 사용률은 워크로드가 이미 과부하 상태여야 증가하기 때문에 지연 지표이지만, 기존 애플리케이션의 경우 대부분 규모 조정 결정을 내리는 데 충분합니다.

가속 워크로드는 GPU 사용률이 아닌 선행 지표에 따라 규모 조정되어야 합니다.

GPU 사용률(DCGM_FI_DEV_GPU_UTIL)은 GPU가 얼마나 사용되고 있는지가 아니라 사용되고 있는지 여부를 보여줍니다. vLLM과 같은 추론 서버는 다양한 수신 요청에서 100% 가깝게 유지될 수 있으므로 사용률은 신뢰할 수 없는 오토 스케일링 신호입니다. 요청 대기열 깊이, 첫 번째 토큰까지의 시간(TTFT), 요청 지연 시간과 같이 수요가 용량에 가까워지면 증가하는 선행 지표를 기반으로 규모를 조정해야 합니다.

위에서 다룬 세 가지 차이점 중에서 규모 조정 신호를 신중하게 고려하세요. GPU 사용률은 남은 추론 용량에 대한 신뢰도 높은 신호가 아니므로 모델 추론 서버의 실제 수요를 추적하는 신호를 식별하고 수집해야 합니다.

다음 섹션에서는 규모 조정 지표로 사용할 신호 및 이러한 신호가 함께 작동하는 방식을 다룹니다.

규모 조정 지표 선택

모델 추론 복제본을 규모 조정할 시기를 알려주는 단일 지표는 없으므로 추론 서버의 신호 조합을 기반으로 규모를 조정합니다. 이러한 신호는 함께 작동하며, 각 신호는 이전 신호를 기반으로 단일 지표보다 더 빠르고 안정적으로 수요를 포착합니다.

신호 지표 규모 조정에서의 역할

대기열

요청 대기열 깊이(처리 대기 중인 요청 수)

수요가 용량을 초과하는 순간 대기열이 형성되기 때문에 선행 지표이자 최상의 기본 트리거입니다.

Latency

요청 지연 시간(p95 지연 시간 또는 TTFT)

대기열이 아직 형성되지 않은 경우에도 응답이 느려지면 규모 조정을 트리거하여 사용자 대면 지연 시간을 목표 범위 내로 유지합니다.

GPU 메모리

KV 캐시 사용률(GPU의 요청 메모리가 가득 찬 정도)

GPU 메모리 부족으로부터 보호합니다. 제한에 가까워지면 서버가 요청을 거부하거나 대기열에 추가하기 시작합니다.

이들은 함께 방어 계층을 형성합니다. 요청 대기열 깊이는 수요가 용량을 능가하는 순간 발동하는 기본 트리거이고, 요청 지연 시간은 대기열이 형성되기 전에 느린 응답에 대한 검사를 추가하며, KV 캐시 사용률은 GPU 메모리 부족을 방지하는 최후 방어선입니다.

이 모든 것을 실제로 적용

다음 하위 섹션에서는 이러한 신호를 특정 오토스케일러와 함께 활용하는 방법을 보여줍니다.