이번 게시글에서는 EKS 워크샵 스터디 제 9주차 내용을 작성합니다.

이 글은 3부로 나누어집니다.

1. 9주차 - EKS 위 AI/ML 워크로드 Part 1 - EKSworkshop AI/ML로 Neuron 기반 다지기
2. 9주차 - EKS 위 AI/ML 워크로드 Part 2 - GenAI on EKS로 추론 서빙 운영하기 (현재 보고 계신 글)
3. 9주차 - EKS 위 AI/ML 워크로드 Part 3 - Agentic AI Platform으로 멀티 에이전트 플랫폼 구축하기

코드 살펴보기

들어가며

이번 편에서 다루는 워크샵은 다음과 같습니다.

• 생성형 AI on EKS

워크샵 페이지(catalog.workshops.aws/genai-on-eks/ko-KR)의 워크샵 내용은 실제 코드와 청사진은 awslabs/ai-on-eks 공개 리포지터리의 infra/workshops/genai-on-eks 디렉터리를 참고하여 쫓아가면 됩니다. 여기서는 공식 docs 사이트를 기준으로 정리했습니다.

Part 1에서 EKSworkshop AI/ML 트랙이 AWS Neuron 가속기로 가는 흐름을 따라갔다면, 이번 편은 NVIDIA GPU를 전제로 한 GenAI 추론 서빙 전 과정을 다룹니다. 동시에 Part 1과 가장 크게 달라지는 운영 포인트가 둘 있습니다. 노드 프로비저닝이 수동 Karpenter NodePool이 아니라 EKS Auto Mode로 추상화된다는 점, 그리고 추론이 vLLM 단독이 아니라 Ray Serve로 감싸진 분산 서빙이라는 점입니다.

GenAI on EKS 워크샵 개요

워크샵의 실제 구성을 infra/workshops/genai-on-eks/README.md 기준으로 정리하면 다음과 같습니다.

워크샵이 인트로에서 보여주는 초기 아키텍처는 다음과 같습니다. 위 표의 구성요소들이 어떻게 연결되는지 한 장으로 정리됩니다.

사전 도구 버전

README가 명시한 도구 요구는 다음과 같습니다.

리전·인스턴스 쿼터는 README에 명시되어 있지 않지만, GPU 노드를 띄우는 워크샵 특성상 g5/g6 패밀리 쿼터 사전 신청은 사실상 필수입니다. Auto Mode가 노드 그룹을 직접 잡지 않더라도 EC2 쿼터는 같은 한도를 따라가기 때문입니다.

인프라: EKS Auto Mode 위에 Terraform으로 올리기

워크샵 폴더는 다음과 같이 구성되어 있습니다.

infra/workshops/genai-on-eks/
├── README.md
├── genai-workshop-architecture.png
├── install.sh
└── terraform/
    ├── blueprint.tfvars
    ├── grafana-dashboards/
    ├── grafana.tf
    ├── pull.tf
    └── s3-workshop.tf

install.sh는 ai-on-eks 리포의 베이스 Terraform 모듈을 terraform/_LOCAL/로 복사한 뒤, 워크샵 전용 설정(blueprint.tfvars, grafana.tf, pull.tf, s3-workshop.tf)을 얹어 terraform apply를 실행합니다. 즉, 워크샵은 베이스 인프라 모듈을 재활용하면서 GenAI 특화 구성을 오버레이로 얹는 구조입니다. 각 파일이 정확히 무엇을 배포하는지, 베이스 install.sh가 어떤 순서로 모듈을 적용하는지에 대한 상세는 코드 살펴보기 문서에서 별도로 정리했습니다.

Auto Mode가 GPU 워크로드에서 의미하는 것

Part 1의 EKSworkshop AI/ML 트랙이 neuron·aiml 같은 Karpenter NodePool을 직접 선언했던 것과 정반대로, 이번 워크샵은 Auto Mode를 켜고 노드 정의를 EKS에 위임합니다. 운영 관점에서 변화는 두 가지로 정리됩니다.

Auto Mode는 단순화 효과가 크지만, "어떤 GPU 인스턴스가 떴는지 사후에 확인해야 한다" 는 비대칭이 생깁니다. NodePool requirement처럼 사전 제약이 명확하지 않으므로 비용 알람과 인스턴스 사용 리포트가 함께 굴러가야 합니다.

추론: vLLM on Ray Serve

추론 스택은 단순한 vLLM 단독 배포가 아니라 Ray Serve로 감싼 분산 서빙 구조입니다.

왜 vLLM 단독이 아니라 Ray Serve인가

vLLM은 단일 프로세스 안에서 PagedAttention·KV cache·연속 배칭으로 처리량을 극대화하는 추론 엔진이지만, 그 자체로는 다음을 직접 제공하지 않습니다.

• 복수 복제본에 걸친 요청 라우팅과 백프레셔
• 모델 워커 단위의 헬스체크와 재시작 격리
• 다중 모델·다중 버전 호스팅
• HPA가 부적합한 GPU 자원에서의 스케일링 결정

Ray Serve는 이 위에 deployment/replica 추상과 라우터를 얹어 위 항목들을 메꿉니다. 추론 요청은 Ray Serve 라우터에 도달하고, 라우터가 vLLM 워커 복제본 중 하나로 요청을 흘려보내는 구조입니다.

모델: Ministral-3-8B-Instruct-2512

워크샵은 Mistral AI의 Ministral 계열 8B 인스트럭트 모델을 사용합니다. 8B 규모는 단일 g5.2xlarge/g6.xlarge 수준의 A10G·L4 GPU 한 장에서도 동작 가능한 크기라, 워크샵 데모용으로는 비용·성능 균형이 잘 잡힌 선택입니다.

모델 다운로드는 install.sh가 아니라 클러스터 프로비저닝 이후 워크로드 단계에서 진행됩니다. Terraform apply로 클러스터·관측 스택이 다 올라온 다음, vLLM Pod가 init 단계에서 Hugging Face로부터 가중치를 받아오는 흐름입니다. 이 분리는 의미가 큽니다. 인프라 코드가 모델 라이프사이클과 결합되지 않아야 모델 교체 시 Terraform을 다시 돌리는 일이 없습니다.

인터페이스: OpenAI 호환

Ray Serve로 감쌌어도 외부에 노출되는 인터페이스는 vLLM이 제공하는 OpenAI 호환 엔드포인트입니다. 클라이언트 입장에서 openai SDK를 그대로 쓰고 base_url만 워크샵 서비스로 바꾸면 됩니다. 이 점은 Part 1의 vLLM on Neuron과도 일치하며, vLLM 인터페이스의 가속기 무관성이 다시 확인되는 지점입니다.

관측: AMP + Grafana + kube-prometheus-stack

워크샵의 관측 스택은 세 층으로 분리되어 있습니다.

grafana-dashboards/ 폴더에 워크샵 전용 대시보드 JSON이 미리 들어 있어, install.sh 적용 후 별도 작업 없이 Grafana에 바로 떠 있는 상태로 시작합니다.

AMP를 쓰는 이유

워크샵은 굳이 셀프호스트 Prometheus를 영구 스토리지까지 확장하지 않고 AMP로 원격 쓰기를 합니다. 운영 관점에서 AMP는 다음 두 가지를 가장 크게 해결해 줍니다.

• 노드 재시작/이전과 무관한 메트릭 보존 (Prometheus를 EBS에 묶지 않아도 됨)
• 여러 클러스터를 한 워크스페이스에 모아 보는 글로벌 쿼리 (멀티 클러스터 운영에서 진가가 드러남)

GPU 메트릭

GPU 관측은 일반적으로 NVIDIA DCGM Exporter를 통해 Prometheus가 GPU 사용률·메모리·온도·전력 메트릭을 수집하는 경로를 따릅니다. 워크샵의 grafana-dashboards/에 GPU 패널이 포함되어 있다면 이 경로가 활성화되어 있다는 신호입니다. 실제 도입 시점에는 vLLM 자체 메트릭(요청 큐 길이, 토큰 처리량)과 DCGM 메트릭을 한 대시보드에 묶어두는 것이 "GPU가 한가한데 큐가 길다" 같은 패턴을 빠르게 잡는 데 효과적입니다.

확장 청사진: ai-on-eks 리포가 함께 들고 있는 것

워크샵 외에도 awslabs/ai-on-eks 리포는 운영 환경에서 골라 쓸 수 있는 청사진을 다수 보유합니다. 한 줄 요약과 함께 도입 시점을 정리하면 다음과 같습니다.

GenAI on EKS 워크샵 자체는 vLLM + Ray Serve를 깊게 보여주지만, 실 운영 환경에서는 트래픽 패턴(단일 모델 vs 다중 모델, 분산 vs 단일 노드)에 따라 위 청사진 중 하나를 선택하게 됩니다.

워크샵을 따라가며 느낀 포인트

• Auto Mode가 GPU 워크로드 운영의 진입 장벽을 크게 낮춥니다. Part 1처럼 NodePool requirement를 신중하게 잡는 단계 자체가 없어집니다. 다만 사전 제약이 약한 만큼 사후 비용 알람과 인스턴스 사용 리포트의 무게가 커집니다.
• Ray Serve + vLLM 조합은 단일 노드 데모에서도 의미가 있습니다. 한 복제본만 띄우더라도 추후 복제본 추가·라우팅·헬스체크가 라이브러리 수준에서 정리되므로, 처음부터 이 조합으로 시작하는 편이 단순 vLLM serve 명령으로 시작해 나중에 옮기는 것보다 마찰이 적습니다.
• 관측은 처음부터 AMP 원격 쓰기로 잡혀 있어야 합니다. 모델·추론 엔진·GPU 메트릭을 며칠치만 들고 있어도 디버깅에 부족할 때가 많은데, Prometheus를 EBS에 묶어 두면 같은 문제가 클러스터 재시작마다 반복됩니다.
• 모델 라이프사이클을 Terraform 바깥에 두는 패턴은 그대로 가져갈 만합니다. 인프라와 가중치 다운로드를 분리해 두면 모델 교체가 Pod 롤링 한 번으로 끝납니다.

마치며

이번 편에서는 GenAI on EKS 워크샵을 따라가며 EKS 위 GPU 기반 LLM 추론 서빙을 정리했습니다. EKS Auto Mode 위에 vLLM·Ray Serve·AMP/Grafana를 얹는 한 흐름이 그 골격입니다.

Part 3: Agentic AI Platform으로 멀티 에이전트 플랫폼 구축하기에서는 이번 편에서 만든 추론 엔드포인트가 단순 API 소비 대상이 아니라, 에이전트가 호출하는 모델 백엔드로 들어가는 한 단계 위 구조를 다룹니다.