Inference Optimization on EKS

📅2026-04-03 작성·🔄2026-07-17 수정·⏱14분 읽기

개요

프로덕션 LLM 서비스에서 Inference 비용은 전체 AI 운영 비용의 80-90% 를 차지합니다 (AWS 공식 문구 "up to 90% of overall operational costs for machine learning initiatives"). 학습은 1회성이지만 추론은 서비스가 살아있는 한 24/7 지속되기 때문입니다. GPU 시간이 곧 비용이며, p5.48xlarge(H100×8) 한 대의 On-Demand 가격은 2025년 6월 가격 인하 후 시간당 $55.04입니다. 월 2대 운영 시 약 $79,258에 달합니다.

이 문서는 통신사 Agentic AI 플랫폼 구축 과정에서 축적된 교훈과 GLM-5(744B), Kimi K2.5(1T) 등 대형 MoE 모델 배포 사례를 기반으로, EKS 위에서 LLM Inference 성능을 극대화하는 아키텍처 패턴을 정리합니다.

다루는 내용

본 카테고리는 추론 최적화 심화 문서와 게이트웨이 라우팅 문서로 구성됩니다. 전체 구조와 계층별 튜닝 레버의 지도는 추론 인프라 개요를 먼저 참조하세요.

📄️ KV Cache 최적화 (vLLM Deep Dive + Cache-Aware Routing)

vLLM PagedAttention·Continuous Batching·FP8 KV Cache 등 핵심 기술과 llm-d/Dynamo의 KV Cache-Aware Routing 비교

📄️ Disaggregated Serving + LWS 멀티노드

Prefill/Decode 분리 아키텍처, NIXL KV 전송, LeaderWorkerSet 기반 700B+ 대형 모델 멀티노드 배포

📄️ LMCache: KV 캐시 오프로딩과 공유

GPU 메모리 너머 CPU·디스크로 KV 캐시를 오프로딩하고 인스턴스 간 공유하는 KV 캐시 계층, vLLM·NIXL·kvaware 라우팅과의 관계

📄️ 캐시 히트 전략

KV/Prefix·Prompt·Semantic 3계층 캐시를 하나의 의사결정 프레임으로 통합, 계층별 히트율 목표와 측정 지점

📄️ Semantic Caching 전략

LLM Gateway 레벨 의미 기반 캐싱 설계 원칙 — 유사도 임계값, 캐시 키 설계, 멀티테넌시, 관측성

📄️ 티어드 게이트웨이 아키텍처

Tier 1 Ingress, Tier 2 추론 라우팅·LLM API 게이트웨이, Agent Data Plane의 역할 구분과 채움 전략

📄️ 라우팅 전략 (Cascade·Semantic·Inference Extension)

kgateway·Bifrost·LiteLLM 비교, Request Cascading 지능형 모델 라우팅, Gateway API Inference Extension(EPP)

📄️ GPU 오토스케일링과 대형 모델 배포 운영

2-Tier 오토스케일링(KEDA·Karpenter), DRA 호환성, 대형 MoE(GLM-5·Kimi K2.5) 배포 실전 교훈

문서별 핵심 주제

1. EKS GPU 인프라 전략 — Auto Mode vs Karpenter vs MNG 선택 기준 (본 문서)
2. 모델 서빙 엔진 — vLLM 핵심 기술과 GPU 메모리 설계 (KV Cache 최적화)
3. KV Cache-Aware Routing — llm-d와 NVIDIA Dynamo 비교 (KV Cache 최적화)
4. Disaggregated Serving — Prefill/Decode 분리 아키텍처 (Disaggregated Serving)
5. LWS 멀티노드 서빙 — LeaderWorkerSet 기반 700B+ 모델 배포 (Disaggregated Serving)
6. GPU 오토스케일링 — 2-Tier 스케일링(KEDA·Karpenter)과 DRA 호환성 (오토스케일링 & 배포 운영)
7. 대형 모델 배포 실전 교훈 — 모델 다운로드 실패 대응, MoE 배포 함정 (오토스케일링 & 배포 운영)

핵심 성능 지표

지표	설명	최적화 목표
TTFT (Time to First Token)	첫 토큰 생성까지의 시간	< 2초 (대화형), < 5초 (배치)
TPS (Tokens per Second)	초당 토큰 생성 속도	모델별 상이
GPU Utilization	GPU 연산 활용률	> 70%
KV Cache Hit Rate	KV 캐시 재사용 비율	> 60% (공유 프롬프트)
P99 Latency	99 퍼센타일 응답 시간	SLO 기준 준수

EKS GPU 인프라 전략

3가지 배포 모델 비교

EKS에서 GPU 워크로드를 운영할 때, 노드 관리 방식에 따라 기능과 운영 복잡도가 크게 달라집니다.

기준	EKS Auto Mode	Karpenter + GPU Operator	MNG + Cluster Autoscaler
GPU 드라이버 관리	AWS 자동 관리	AMI 사전 설치	AMI 사전 설치
MIG / Time-Slicing	불가	가능	가능
DRA 호환	미지원	미지원	유일한 선택지
DCGM 모니터링	GPU Operator 설치 시 가능	완전 지원	완전 지원
운영 복잡도	낮음	중간	중간
적합 모델 크기	70B+ (GPU 전체 활용)	7B~700B+ (MIG 분할 가능)	DRA 필요 워크로드

선택 가이드

• 빠른 시작 / PoC: Auto Mode — GPU 드라이버, Device Plugin 자동 관리
• 프로덕션 (GPU 세밀 제어): Karpenter + GPU Operator — MIG, Custom AMI 지원
• DRA 필요 시: MNG + Cluster Autoscaler — Karpenter/Auto Mode에서 DRA Pod를 skip하는 아키텍처적 한계

GPU 인스턴스 선택 매트릭스

인스턴스	GPU	GPU 메모리 (총합)	적합 모델 크기	시간당 비용 (On-Demand)
g5.xlarge~48xlarge	A10G	24~192GB	7B 이하	$1.01~$16.29
g6e.xlarge~48xlarge	L40S	48~384GB	13B~70B	비용 효율적
p4d.24xlarge	A100 40GB × 8	320GB	13B~70B	$21.96
p5.48xlarge	H100 80GB × 8	640GB	70B~700B+	$55.04
p5e.48xlarge	H200 141GB × 8	1,128GB	100B+	최대 메모리
p6-b200.48xlarge	B200 180GB × 8	1,440GB	700B+	TBD

Auto Mode GPU Operator 하이브리드 구성

Auto Mode에서도 GPU Operator를 설치할 수 있습니다. Device Plugin만 노드 레이블로 비활성화하고, DCGM Exporter, NFD, GFD는 정상 동작합니다.

# GPU Operator 설치 (Auto Mode 호환)
helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator --create-namespace \
  --set driver.enabled=false \
  --set toolkit.enabled=false

# NodePool에 Device Plugin 비활성화 레이블 추가
# nvidia.com/gpu.deploy.device-plugin: "false"

이를 통해 Auto Mode의 편의성을 유지하면서 DCGM 세밀 메트릭(SM 활용률, NVLink 대역폭)을 수집할 수 있습니다. KAI Scheduler 등 ClusterPolicy 의존 프로젝트도 사용 가능합니다.

GPU Operator + Auto Mode 주의사항

devicePlugin.enabled=true로 설치하면 Auto Mode 내장 Device Plugin과 충돌하여 allocatable=0이 됩니다. 반드시 devicePlugin.enabled=false 또는 노드 레이블로 비활성화해야 합니다.

모델 규모별 권장 아키텍처

의사결정 플로우

3-Tier 권장 구성

Tier	모델 규모	인프라	서빙 엔진	라우팅	예시
Tier 1	≤32B	Auto Mode, g6e/p5	vLLM (단일 GPU)	Round-Robin	Qwen3-32B FP8
Tier 2	70B~200B	Karpenter + GPU Operator	vLLM TP=4~8	llm-d KV Cache-aware	Llama-3.3-70B
Tier 3	700B+ MoE	MNG 또는 Karpenter + LWS	vLLM/SGLang PP+TP	Disaggregated + NIXL	GLM-5, Kimi K2.5

모든 Tier 공통: Bifrost Cascade Routing으로 Bedrock 폴백 구성 권장 (GPU 장애/Spot 중단 시 무중단 서비스)

하이브리드 아키텍처: 전체 그림

마이그레이션 경로

단계별 전환으로 운영 리스크를 최소화하면서 점진적으로 성능을 향상시킬 수 있습니다.

Phase 1: Auto Mode + vLLM + Bifrost→Bedrock 폴백 → PoC, 개발 환경

Phase 1.5: Auto Mode + GPU Operator + llm-d → 모니터링 강화, KV Cache 라우팅

Phase 2: Karpenter + llm-d Disaggregated + LWS 멀티노드 → MIG, Prefill/Decode 분리

Phase 3: Karpenter + Dynamo + Hybrid Node → 온프레미스 통합, 3-Tier Cascade

Phase 4: 전체 통합 → On-Prem→Cloud→Bedrock Cascade, SLO 기반 오토스케일링

참고 자료

공식 문서

• Amazon EKS User Guide — EKS 클러스터 및 노드 관리
• EKS Hybrid Nodes — 온프레미스 GPU 서버 EKS 통합
• Amazon Bedrock Documentation — 관리형 FM 서비스 (Cascade Fallback 대상)
• SOCI (Seekable OCI) — 컨테이너 이미지 lazy-loading

논문·기술 블로그

• a16z "The Economics of AI" — AI 인프라 비용 구조
• GenAI on EKS Starter Kit — Bifrost, vLLM, Langfuse 배포 자동화
• Scalable Model Inference on Amazon EKS — llm-d, Karpenter, RAG 종합 아키텍처

관련 문서

• EKS GPU 노드 전략 — Auto Mode, Karpenter, Hybrid Node 비교
• GPU 리소스 관리 — GPU 스케일링, DRA, 비용 최적화
• NVIDIA GPU 소프트웨어 스택 — GPU Operator, DCGM, MIG, Dynamo
• vLLM 기반 FM 배포 및 성능 최적화 — vLLM 상세 가이드
• llm-d 기반 EKS 분산 추론 — llm-d 배포 가이드
• MoE 모델 서빙 가이드 — MoE 모델 배포