EKS에서 멀티 노드 Triton + TRT-LLM 배포

EKS에서 멀티 노드 Triton + TRT-LLM 배포 (Multi-Node on EKS)

이 저장소는 EKS(Amazon Elastic Kubernetes Service)에서 LLM을 다중 노드로 배포하는 방법을 안내합니다. EFA 같은 기능을 활성화하는 커스텀 이미지 빌드, Helm 차트, 관련 파이썬 스크립트 등이 포함돼 있어요. 이 배포 흐름은 추론 엔진으로 NVIDIA TensorRT-LLM, 모델 서버로 NVIDIA Triton Inference Server를 사용합니다.

노드당 파드가 1개이므로, 다중 노드를 요구하는 모델을 배포할 때의 핵심 과제는 "모델 인스턴스 하나가 여러 노드, 즉 여러 파드에 걸쳐 있다"는 사실이에요. 따라서 요청을 서빙하기 전에 준비돼야 하는 원자적 단위이자 스케일링 대상도 "파드 그룹"이 됩니다. 이 예시는 이런 문제를 어떻게 우회하는지 보여주고, 다음을 구성하는 코드를 제공해요.

  • LeaderWorkerSet으로 파드 그룹에 Triton+TRT-LLM 실행 — 여러 노드에 걸쳐 트리톤과 TRT-LLM을 실행하려면 MPI로 한 노드가 모델 인스턴스를 이루는 모든 노드(자기 자신 포함)에서 TRT-LLM 프로세스를 실행하게 해요. 그러려면 관련된 모든 노드의 호스트명을 알아야 하므로, 파드 그룹을 만들고 각 그룹이 어떤 모델 인스턴스에 속하는지 파드 라벨로 식별할 수 있어야 해요. 이를 위해 LeaderWorkerSet을 씁니다. LeaderWorkerSet은 "메가파드"를 만드는데, 하나의 리더 파드와 지정된 수의 워커 파드로 구성되고 그룹 소속을 나타내는 파드 라벨을 제공하죠. deployment.yaml과 server.py에서 LeaderWorkerSet을 구성하고 MPI로 Triton+TRT-LLM을 실행합니다.
  • Gang Scheduling — 모델 인스턴스를 이루는 모든 파드가 준비된 뒤에야 Triton+TRT-LLM을 실행하게 하는 것입니다. server.py의 wait_for_workers 함수에서 kubessh를 사용해 이를 구현합니다.
  • 자동 확장 — 기본적으로 HPA(Horizontal Pod Autoscaler)는 개별 파드를 스케일링하지만, LeaderWorkerSet은 각 "메가파드"를 스케일링할 수 있게 해요. 다만 GPU 워크로드라 CPU·호스트 메모리 사용량으로 자동 확장하지 않으려고, Triton 서버가 Prometheus로 노출하는 메트릭을 활용하고 triton-metrics_prometheus-rule.yaml에 GPU 이용률 recording rule을 구성해요. 또 pod-monitor.yaml과 hpa.yaml에서 PodMonitor와 HPA를 올바르게 설정하는 법도 보여줍니다(핵심은 리더 파드에서만 메트릭을 스크레이프하는 것). HPA에 반응해 배포가 동적으로 노드를 추가하도록 Cluster Autoscaler도 구성합니다.
  • LoadBalancer 설정 — 모델 인스턴스의 각 그룹에 여러 파드가 있어도 요청을 받는 파드는 그룹 내 하나뿐이에요. service.yaml에서 외부 클라이언트가 요청을 보낼 수 있도록 LoadBalancer Service를 올바르게 설정하는 방법을 보여줍니다.

출처: 공식문서 - EKS Multinode TRT-LLM

설정과 설치

  • EKS 클러스터 생성
  • EKS 클러스터 구성
  • Triton 배포

이 각각의 자세한 단계는 같은 저장소의 별도 페이지에서 다룹니다. EKS 클러스터를 만들고, GPU 메트릭 노출·Prometheus 구성을 갖춘 환경을 세팅한 뒤, 리더/워커 파드·자동 확장·로드 밸런서가 포함된 트리톤 배포를 진행하면 됩니다.

더 알아보기 (Learn more)